Choose Your Own Red Team Adventure: Processes from VBA Macro

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 remember the day your technical leads had the long drawn out philosophical debate about this. Everyone HATES visual basic, the language VBA macros are written in. But most malicious documents rely on VBA to serve as the launcher for the actual malware. Even if they transition to PowerShell, WMI, or some live off the land executable to initiate the next stage, it has to start in VBA.

“Processes are expensive,” your tech lead said.

“Yes, agreed. That’s why we wrote our own implant that stays inside a single process,” says another teammate.

“But that implant has to get bootstrapped from VBA. It’s created as a new process. It’s not free — it’s also expensive,” you recall your tech lead bordered on pedantic as he continued. “We fought hard to get execution and the first stage is VBA, so we need to our first host recon from that point — in VBA.”

Your team made it your SOP and wrote up a playbook for it. Here you are, a year later, and you’re just following that playbook.

You’ve already sent a first round “recon phish” that appeared to be a generic marketing email nobody remembers. You’ve got your egress IPs set. You’ve determined expected device types from user agent strings. It’s time for your next phish. It’s basically a tiny little malware drone whose purpose in life is get opened, grab some telemetry around what processes, services, and drivers are running, then send that result set back to a staging URL. From there, the server will quickly analyze for the presence of security products on the host. If it thinks it’s safe — it will serve up the next stage and directions to use one of 4 ways to initiate execution. The only flaw is if there is a new EDR product your team has never seen before, and you don’t know what its capabilities are. “Oh well, that’s what debriefs are for,” you say to yourself.

You watch your console when an audible beep wakes you up from your daydream to inform you the first stage has been successfully opened. The safety checks were about to run, and soon you’d know if all of that R&D time would pay off in this organization.

It did.

Three EDR products were recognized. Your team has been up against them all before. One time you flat out stole the installer and license key for one of the products from the target network you were engaged in at the time (this was allowed in the rules of engagement), so you could test it offline in a lab and discover how it worked.

The staging server instructs the VBA stager to use a certain injection technique which is not monitored by the EDR product, according to the last time your team tested it, and to inject a DLL version of your implant into a browser process that was running. “That’s brilliant,” you thought the first time you tested it. “EDR products that note HTTPS traffic coming from non-browser processes won’t think twice about this.”

Now your full implant is executing and calling back to the final C2 server. After a little more analysis and peer review with a teammate, you settle in on a low-and-slow persistence technique, then move on to deploy a second short haul C2 to do all your “work” from, in case your actions on target result in detections.

Fast forward: you demonstrated full control of the accounts payable system, which was your primary objective. You wrote a hundred-plus page report (that nobody will likely ever read), but you did have some very engaging debrief discussions with SOC engineers, who crafted several new detections as a result. You gave them a sample payload they can run to test the injection technique you used, and it pops every time now. They thank you for your time, deploy the detection to the rest of the enterprise, and tell their CISO they can’t wait for the next engagement with them. You know it will be much harder next time. Your stomach churns with anxiety for a few moments while you ponder that, but you recall you have plenty of time to come up with something new, and remind yourself this is what it’s all about anyway.

THE END

EPILOGUE

Yes, this is the path in this particular storyline that achieves the outcome the Red Team wanted to achieve. It is not a prescription of exactly how you should structure all of your engagements. So many details have to be right.

What if the organization didn’t allow macros at all? Then the VBA analysis of what was running would have failed.

What if the organization had better YARA rules for the types of checks the VBA code was doing? Then the phish probably would not have landed at all.

What if “actions on target” that were so conveniently glossed over for brevity generated a detectable event? Actually, that’s highly likely. Cat and mouse games after that point are very common for tough organizations.

What if the defending organization simply blocked all DNS domains that it hasn’t seen before? Ouch, painful, but definitely would have prevented full C2 traffic.

What if more what if questions keep coming? Well, there are so many details that could have wrecked the storyline.

Bottom line: hopefully this challenged the way you think about active defense and helped you to develop a whole new respect for the toughest defenders. They set the bar for us all. If it wasn’t for them, we’d all still be playing the same game, over and over again, on novice level. Who wants to do that? Not you.

THE END