Choose Your Own Red Team Adventure: Password Prompt
This is a continuation of a Choose Your Own Red Team Adventure series. If you don’t know how you got here, start at the beginning. Otherwise, continue reading …
You saw a nifty tool the other day on a blog. It generates a dialog box that looks similar to the Windows security UI, prompting for passwords. You decided to use it. It’s convenient and executes as in-memory PowerShell.
You copy the PowerShell, paste it into your Command and Control server’s console, and wait.
The response came back: empty string. No password. What happened?
Try it again.
After waiting, the response is another empty string. Argh!
You try on your VM. After a few minutes, you think you figured it out: if the user clicks the “x” it just exits and returns an empty string password. You go look at the source code. You’re a great Googler. A few minutes later, you found a Stack Overflow article showing you how to disable the “x” button. You repackage your payload with the fix and send it in.
This time you get a response: “qwerty”
No way that’s the password. You attempt to verify it. Result: authentication failure.
You go back to the source code. A few more Stack Overflow articles and you have a version of the password prompt that won’t exit until it gets a password that successfully authenticates.
Send the new one. Wait for it … Got a result. This one looks real. Finally!
You attempt to verify it. Result: authentication success! It’s legit! Your code works!
Now, what to do with it?
You didn’t notice the user wasn’t an admin. There are no lateral movement opportunities with that credential. You consider modifying your code again to prompt for an admin, looping until you get actual admin access.
Then …
You noticed your shell stopped calling home.
You try sending your phish to another target. It never arrives.
Maybe it’s your hosting provider? You swap and try again. Still never arrives.
You run out of time.
GAME OVER.
Post Analysis
You didn’t look where you landed or what was running. You didn’t notice the EDR product running or the fact that it was PowerShell v5 with central logging turned on.
All PowerShell logs to a central source, where every 120 minutes (they can only do it periodically for performance reasons), the Hunt Team has a query against all executed PowerShell in the environment for the presence of base64 encoded payloads, certain namespaces, and attempts for obfuscation.
That means on average you have a one-hour window (120 / 2) before a PowerShell encoded command pops up on the glass of a security analyst. Fortunately for you, your payload landed 12 minutes after the last query, so you had 108 minutes before it percolated into an analyst’s queue — way better than average.
It was also a busy day at the SOC. They were short-handed, and it was lunchtime, so you got a few extra bonus minutes before eyes were on the alert. They wanted to just block all non-IT endpoints from executing PowerShell, but had friction from an IT support group internally about making such a policy.
Your PowerShell was eventually analyzed 142 minutes after your phish landed. It was then correlated with the failed authentication attempts at the 153-minute mark. Incident Responders began triaging the host you landed on, when the Helpdesk escalated a support ticket from the affected user complaining about the 18 password prompts she received today (yes, she apparently counted them!).
The Incident Response team finishes a quick check to ensure no other machines on the network are talking to your Command and Control domain. The domain is over a year old and properly categorized, but when reviewing traffic history inside the target network, it stands out like a sore thumb — nobody else is talking to it, except the phished user’s computer.
So, your domain was blocked from new connections approximately 172 minutes after initial execution, but the egress technology stack allows established connections even after a policy change. The IR team finally cut off your connection after 188 minutes. Not bad, considering the number of teams, moving pieces involved, and the fact that you failed to exfiltrate anything of value. It also helps that nobody in accounting ever runs PowerShell, which the CISO finally used as justification to block PowerShell for everyone outside of IT. The new policy took effect immediately. Since they had rolled out a temporary block as part of their response, they just left it permanently in place as the new status quo.
Any future phishes would have died, because all of your post-exploitation kit relies on PowerShell. But, for completeness, the ingress security team immediately drafted a YARA rule for the initial phish. That took them some time, but they had it in place by the 200-minute mark, which explains why switching your attack infrastructure didn’t matter. The Security Operations Center did notice all of the future attempts coming inbound, though. They created a special triage queue for them. They observed some tweaks you made to the payloads, and they tweaked their YARA rules as well.
Red Teaming can be hard.
That’s ok, this isn’t a complete failure. It helped your client improve processes, policy, and detections. But you didn’t hit your objective. Not even close.
There’s always next time.
