Great story, but I wouldn't call it "failed" because it showed that the company has really good security procedures. I don't know many companies that could have resisted this sort of internal threat.
I've had pentests that found nothing before but I had logs full of attempts to compromise the app, including in some ways I'd never even heard of before. I didn't consider them to be failures either.
The author did find a weakness with Pam giving out her MFA token over the phone. It didn't yield anything beneficial in this scenario, but it was still a point of weakness.
Also, while its good that they busted him based on the powershell use, I'm surprised that they didn't install the listener on an IT system, since he had a short window in their office. If the author disguised as a cleaner, they most likely could have talked their way out if they were caught.
Years ago an office I was working in was 'broken into' by a former locksmith that had since taken a job with our main competitor. I knew something was fishy based on the specific towers that were stolen (yes, they stole complete hardware...) -- one from payroll, another from sales, etc. The systems were spread out across the office, so it wasn't a simple snatch and grab.
At first glance it looked like the server room door had been picked or kicked, but looking at the damage itself, the damage was completely superficial, if not lazy. I even Hollywood kicked the door myself to see if it opened, and nothing.
After checking some security footage, someone recognized the locksmith -- which later revealed that he quit a few weeks earlier and had been working for the competitor.
Let's be honest. No company would have resisted this sort of internal threat. This is either fiction (which it sounds like it is) or this is just a lack of time. The difference between pentesters vs real hackers are that hackers have as much time as they want.
The author is a well-known (on the twitter-sphere) pen-tester. Despite the childish gif memes and dramatic trimming, I don't think he made it up.
But I agree, it seems strange that he didn't succeed.
When corporations hire pen-testers, the set-up is that their CIO/CSO has full knowledge of what is going down and when so that they're prepared to intervene in the unlikely scenario of the pen-tester getting caught.
Knowing the mentality that is common amongst c-level suits, however, it would not be surprising if the suit tipped-off his IT guy in advance. After all, wouldn't catching the well-paid pen-tester look better to the other suits than being utterly pwned and paying for privilege?
The CIO might have successfully "kobiashi-maru'd" the whole exercise. Not saying that happened here, but if large corporations are capable of horrific security breaches, I think they're also capable of trying game the system to avoid things going sideways.
I can't tell you for sure that this is truth or fiction, but I've worked in information security for seven years (three as a consultant), and the story is 100% believable. The writing style is also consistent with the way about half of the pen testers I know write when they're not writing a formal report.
I specialize in the remote version of the kind of test the author describes. I'd be happy to do it in-person too, but usually the clients were less interested in that.
I agree this reads like fiction. Strange capitalization, and no technical person I know or know of would write this way; it all seems very cavalier and not the careful writing of someone who actually does this for a living. Not that I know better.
You might find the DC listed in the registry if you look for key "DCname". However again, that's another thing you'd use app whitelisting for, and catch every invocation of regedit. A lot of unattended driveby attacks attempt to do bad things here, so you catch/trap them.
Again, dead end.
So, I'd love to see a good walkthrough how to find the DC if these avenues don't work.
When you get to larger orgs, the DC doesnt always have to be the logon server. In fact, you're liable to see a slew of logon kerb redirectors talking to a few ldap backends running as pri and secondary AD.
I have to admit I’m not familiar with anything in your comment. Is this different terminology for a RODCs? I was also under the impression that AD didn’t have a primary DC, the only vestige of that is the PDC Emulator FSMO role.
It seems like fiction. I run a small but specialized computer security consultancy and most customers are not interested in throwing away money at "pentests" that don't involve breaking code.
When we gain access to a customer's internal network, we do try lateral movement on the network and give recommendations for how to isolate different parts.
From the perspective of a onbtestee, if you didn’t get the goods it failed. There is little more frustrating than getting a gooose egg in a pentest. Blue team, not so much
Most security cameras aren't monitored 24/7. It's just not practical. I'm sure they would have gone back and checked the tapes eventually, but as it happens they caught him before reaching that point.
They don’t need to be monitored by a person 24/7. All you need is a decent video analytics; most are even built-in IP cameras these days. A simple one that’s effective just detects motion within a zone during certain hours
This is starting to sound more fiddly than is reasonable for inside security on a corporate office. The real failure here is just that someone left the door propped open. That's easily addressable, and as it turned out, they caught the attacker anyway.
I've had pentests that found nothing before but I had logs full of attempts to compromise the app, including in some ways I'd never even heard of before. I didn't consider them to be failures either.