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.
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.
> spent some time hunting the Domain Controller
The DC address(es) are trivial to find.
You have a GPO that turns on command and ps logging. Ok, so if you type those commands, you alert script logging engines.
And then you search how to find the DC: https://serverfault.com/questions/78089/find-name-of-active-...
It's all PS or cmd. Trapped.
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.
Explorer address bar (or start>run) > %logonserver%
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.
See https://blogs.msdn.microsoft.com/servergeeks/2014/07/12/dns-...
[edit: I see the SO link mentions SRV. Still]
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.
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 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.
Or don't jam the door open in the first place.