In this entry we continue with domain fronting; on this occasion we will explore how to implement a simple PoC of a command and control and exfiltration server on Google App Engine (GAE), and we will see how to do the domain fronting from Windows, with a VBS or PowerShell script, to hide interactions with the C2 server.
When we have everything ready, we will have a webservice at myc2server.appspot.com which we can use from a compromised Windows machine in the following way; we will have a command and control channel (on the path /e2e7765b71c1, as an authenticator):
Exfiltration channel (against another path, /858e6f3e2b7b):
And finally, a query channel (to use by the attacker to obtain the exfiltrated info, against the path /cf0a5906cadb):
As we can see, all interactions with the server are camouflaged with domain fronting as encrypted queries against www.google.es.
Google App Engine for pentesters
First we will create the app in GAE, going to the following URL while logged in with our Google account:
It’s important to specify myc2server as both the name of the app and its ProjectID; otherwise Google will assign a random ID.
To develop and deploy the app on Linux we downloaded the GAE SDK (we have chosen to use Python, although it is possible to use other languages like Golang, PHP, Java …):
After that, we dropped it on our home, executing the install.sh script, which modifies the PATH and other necessary elements. Next, we need to associate the SDK installation with our Google account. This is done by running the command:
When we run it, the web browser opens and we are be able to login and give Google App Engine the necessary permissions for our Google account, after which we will be able to list the active projects (myc2server among them):
Our very simple app will consist of two files: app.yaml (YAML app descriptor) and main.py (Python source code):
As we can see in the file app.yaml, we delegate all the code to the main.py file, which will handle all URLs. As for the code itself, we can use different development frameworks for Python, such as Django, but for this simple PoC we have used webapp2, which comes by default with GAE.
The following code defines URL routing to the different classes:
We have therefore three classes that will deal with the three channels (command and control, exfiltration and listing) mentioned before. The “(.+)” in the exfiltration URL tells webapp2 that it takes a GET parameter (the info to exiltrate itself).
The CommandControl class simply provides text-mode instructions (you could also provide encoded binaries or scripts to execute, or anything else; we could parametrize everything to make it comfortable for the command and control operator to add new instructions or artifacts):
For the exfiltration part, we have chosen to use one of the GAE storage mechanisms: Google Cloud Datastore, which is a kind of weakly typed datastore.
Another option, which might be more convenient to store binary blobs with the exfiltrated info (for example, whole files), would be Google Cloud Storage, but it’s a bit harder to use, so we kept things simple for the PoC.
The first step is to define the entities that will store the information; in our case just an object with the date and the exfiltrated data:
To store the information, we simply instantiate the class, fill it with the information that comes to us via the GET parameter and invoke the put() method:
We will be able to access the exfiltrated data directly through the Google App Engine development console:
To obtain it with code, we use the ExfiltratedData.query().Fetch() method, iterating over the results and displaying them in text mode:
To deploy the GAE app, we cd to the directory where we have left the app.yaml and main.py files and we run:
Domain fronting from Windows
To use the C2 webservice with domain fronting from a compromised Windows machine we could simply use the wget binary for Windows, but maybe we better use something like VBS script or PowerShell; they come by default on Windows and we can execute from memory, evading AV and leaving small footpring, among another advantages.
After several tests, one way to implement domain fronting is to use the method navigate() of the InternetExplorer.Application COM component. This has the added advantage that as we are actually instrumenting a complete Internet Explorer, all client fingerprints will be the same. For example, to get the instructions from the C2 server, we would write the following VBS script code:
The key of the matter is in the fifth parameter of the navigate() method, where we can put additional HTTP headers (in this case we modify the Host header to achieve the domain fronting). We could implement the same thing in PowerShell with similar code.
I performed other tests, for example using the .NET WebRequest class, but it only supports setting a custom Host header in recent versions of PowerShell (it seems not under version 2.0).
The same goes for functions like Invoke-WebRequest. There are other libraries and COM components with which it is possible to make web requests, such as msxml2; I have not researched yet whether or not they would allow domain fronting.
The VBS exfiltration code is very similar:
In either case, all you see is HTTPS traffic to and from www.google.com and its corresponding DNS resolution:
It might be interesting to implement domain fronting for some of the features of PowerShell frameworks for pentesting, such as nishang; for example:
- In the Client cmdlets, for artifact dropping via a frontal domain.
- In the Do-Exfiltration cmdlet.
- In cmdlets such as Download-Execute-PS, to download the PowerShell scripts to download and execute using domain fronting.