Reflective injection has always been the core of cyber security attacks. As part of our Active Defense solution we have been involved in several incident response assessments where almost every attacker uses Cobalt Strike or a Customized C2 to leverage these injection techniques along with hiding their command and control server using legitimate business-purpose domains. On the flip side, our offensive team at LMNTRIX takes this one step further, by leveraging these techniques to simulate different APT groups as much as possible during Red Team and Adversary Simulation Assessments. In this article we share how we go about doing just that.
How Domain Fronting Works?
Domain fronting uses trusted servers to hide the C2 behind these servers. This helps the attackers to use any random website for their C2. This way, since most of the CDN providers have their Domains categorized, the proxy won’t block the C2 traffic. When a defender looks at the proxy logs, he/she will only see the traffic going to a legitimate domain. This legitimate domain will then forward our traffic to our actual domain (known as origin host). The below figure should explain this more clearly:
Fronting Your Domain
We will be hosting our C2 on the domain ec2-3-1-102-85.ap-southeast-1.compute.amazonaws.com hosted on AWS. We will create a CDN endpoint named labs.azureedge.net on Azure. When our payload executes, it will connect to the CDN which is ajax.microsoft.com. The CDN will check the host header received from the payload’s GET/POST request which will be the endpoint’s domain i.e. labs.azureedge.net. The CDN will forward the data received from our payload to the ‘origin host’ of the endpoint. We will set the origin host on Azure to ec2-3-1-102-85.ap-southeast-1.compute.amazonaws.com.
We will be using our in-house Command and Control Server that we use for Red Team Engagements to demonstrate reflective memory injection with shellcode-based payload which will connect to our C2 Infra hosted on AWS. This C2 infra will have a fronting domain which we will setup using Azure since AWS does not support Domain fronting or CDNs anymore. Other CDN providers would be Cloudfront or Aliyun (Alibaba Cloud).
We will first create an origin host for our CDN. We will use the default AWS domain that we get from AWS EC2 which we mentioned above. To Create a CDN endpoint:
- Navigate to Azure Dashboard
- Select ‘Create a Resource’ option
- Select ‘Web’ from the Resources list and then select ‘CDN’ from the Web resources’ Menu.
- Here, you can name anything to the CDN profile. You can use any Pricing tier, but select the checkbox ‘Create a new CDN endpoint now’
- In the CDN endpoint name, set the subdomain for azureedget.net that you want. We will be using the name ‘labs’. So, our endpoint becomes labs.azureedget.net
- And the custom origin will be the Origin hostname which would be our EC2 host.
Once a CDN endpoint is created, it should look like this:
Weaponizing The Payload
Once we have the CDN ready, we will create a payload with shellcode using our in-house C2 and put it inside an unsigned char variable since the shellcode will be in hex. However, you can simulate this using Metasploit or Cobalt Strike’s ‘Raw’ payload too. Remember that when you create the shellcode, the payload configuration should contain the host header for our Azure CDN. We will be using a CDN named “labs.azureedge.net” for our current test. The generated shellcode should look like this:
We will perform the below steps to inject this shellcode into memory.
- We will create a new process with the CreateProcessA WinAPI with the CREATE_SUSPEND flag. This process can be any executable, but we will use a very common executable from C:\Windows\System32 directory so that it looks normal in the Task Manager. For eg.: runtimebroker.exe.
- We will Allocate memory in the new process using VirtualAllocEx WinAPI with the size of the shellcode.
- We will write our Shellcode to the Virtually Allocated memory within the new process using WriteProcessMemory
- And finally, we will call the written buffer using CreateRemoteThread
Once we run the above payload, it should copy the shellcode seen in Figure 6, and run it inside the RuntimBroker.exe process. We can see on our C2 that we have received a beacon connection from the Azure’s IP (152.195.209.118) since for our C2, this request was received from ajax.microsoft.com(forwarded).
The Aftermath
Remember that this was injected to a Microsoft Signed Executable. So, this will look like a legitimate process to a normal eye. However, for a defender, he/she can use Process Hacker to check the memory written to this process by searching for memory regions containing RWX permissions which we allocated earlier using VirtualAllocEx.
And as you can see in the image above, this memory region contains the same hex op code as our shellcode we see in Figure 6.
Playing Defense
One of the few ways organizations can detect domain fronting traffic is by using an HTTPS proxy as part of a man-in-the-middle campaign. This allows you to decrypt all encrypted traffic and inspect it, but it does come with risks.
Some domains use HSTS, a security protocol that forces all users to communicate through HTTPS only. As a result, only some firms can decrypt SSL traffic that targets those domains.
Another approach is for organizations to use an HTTPS proxy with SSL termination. This allows them to spot a mismatch between the host header and request uniform resource locator (URI).
LMNTRIX’s approach towards Red Team is based on realistic scenarios that we have seen APTs actively using in the wild. Our Red Team and CDC work closely to make sure these attacks and techniques are actively discovered using the LMTRIX Active Defense.
Head over to our website for more information at lmntrix.com
