Recently, on an assessment, I was working on trying to bypass AMSI+EDR in order to get our lovely Cobalt Strike beacon to phone home. After assessing the target environment, I found that most domain categories were blocked by NetSkope. NetSkope requires you to be a customer in order to submit category changes, our usual way of getting Command-and-Control domains allowed.
CloudFront
In order to bypass this, I decided to use an AWS CloudFront distribution to proxy the traffic. This allows me to send all of my Command-and-Control traffic to legitimate and already approved CloudFront domains. The following diagram shows how the victim connects to the CloudFront distribution, where CloudFront continues the connection on behalf of the user. This has the benefit of never disclosing the backend Command and Control server’s IP address or hostname to the victim.
After implementing the infrastructure, I hosted a test “Hello World” page on the Command-and-Control server to ensure that full network connectivity was established.
Once connectivity was verified, I executed my payload, which was a combination of an AMSI Bypass and Shellcode Injection technique. However, after executing it, I noticed that the process simply hung. It didn’t terminate, so EDR hadn’t killed it. I was a bit baffled.
Perks Of Purple Team
Eventually, since this was a purple team, I talked with my client. I explained that it was a good thing that the payload was blocked; however, they said they didn’t have any alerts or indications of why it was blocked. Part of a good purple team engagement is ensuring that organizations have visibility into alerts, so I dug deeper with them to identify what was blocking the payload so they could ensure that telemetry was present in their SIEM.
User Agent Issue
After a bit of back and forth, we found the problem. The Command-and-Control traffic profile being used was an old USER-AGENT. It was using an Internet Explorer user agent and their policies blocked all traffic from Internet Explorer.
This isn’t a bad configuration to have because if out of date installations of Internet Explorer exist in the organization, they won’t be able to visit potentially malicious exploit kit sites and compromise the endpoint.
After updating my USER-AGENT to the latest Chrome variant in my traffic profile, and regenerating my Shellcode, I was in luck. The moral of this story? As time goes on, some of the code we had used in the past, even if it works, may need to be updated to present configurations. Had this been a Red Team instead of a Purple Team, I may not have been able to figure this out in the time allotted. I was thinking that the issue had to do with the traffic profile being used, but it was more likely that other headers had been flagged as “commonly used” and were being blocked. Something as trivial as a USER-AGENT was caught and delayed the project by 75% of a day. Now, it’s time for some Post-Exploitation!