JUNE, 2018
Data Exfiltration
Once an attacker is inside your network and has access to your data they face one major challenge, data exfiltration. Malicious actors are more and more frequently turning to built-in resources to achieve data exfiltration.

This blog post will demonstrate just how easy it is for attackers to utilise this tactic and show defenders the best methods for detection and remediation.

A common tactic, used by malicious actors for many years, has been to post data to a web server within their victim’s network and simply download it from there. However, techniques to identify and defend against this tactic are relatively straightforward…

A defender can utilise the web server’s logs to identify partial downloads of files (this will appear as an HTTP 206 code). All the 206 log events identified can then be added up to fully understand what has been extracted and determine the location where it has been exfiltrated.

As such, malicious actors have evolved their techniques. We are now seeing examples of actors utilising the inbuilt programming capabilities of Windows systems to create simple web servers on networks where they already have a Remote Administration Tool (RAT). Once a RAT exists on a host, an attacker will move laterally to another host. Here, they will create their impromptu web server.

A port redirection or potentially a connection proxy (such as the favoured “HUCS proxy” or even MSDTC – a built-in utility in windows) can be configured on the web serving host, so that it is addressable from the outside of the local network (whether via other integrated routes such as RAT-controlled hosts or through poorly maintained network perimeters). Then data can be sent from different hosts to the web server, and finally downloaded at will by the interested APT actors.

tactic demonstration

Data exfiltration using built-in resources

Building a web server, using PowerShell or Python, for example, is incredibly simple. Both languages have standard libraries that, with minimum effort, allow a developer to build a basic web server that can handle standard HTTP Get and Post requests. PowerShell and the .Net framework are available on every windows system by default. Together, they provide a powerful scripting language with a large set of libraries providing powerful functionalities. As a result, if not controlled carefully, PowerShell is one of the most dangerous resources an attacker can abuse on a compromised endpoint. And while not installed by default, Python is another widespread resource that can be, and is, abused if proper controls are not in place.

The simple and relatively compact examples we developed in Python and PowerShell demonstrate just how easy it can be.


Our PowerShell script is relatively lightweight, providing HTTP Get and Post handling. The basis of our web server is the ‘System.Net.HttpListener’ class. Once we have instantiated a listener, all we have to do with it is provide an IP address and port binding. We then start the listener, and it should observe all HTTP traffic to the address and port we have specified.

Our script then specifies how to handle various requests based on the request type identified in the HTTP header. In general, for a ‘Post request’, the listener will split the header from the file data, identify the specified location and write the file to the system. For a ‘Get request’, the requested resource is identified in the header; the file is located and written to the response which is then sent to the requesting host.


The Python script is even more compact. Python has a built-in HTTP server, the SimpleHTTPServer class which provides half the functionality we need, handling only ‘Get requests’.

To be able to send and receive files, all we have to do is extend this class and implement handling of POST requests. This is done identically to how we did it with our PowerShell script. The header is split from the file data, the filename is identified, and the file is written to the target location.

The image depicts the basic network layout used for this demonstration. We have three endpoints, both running Windows 10.  The host labelled RAT is patient zero for the network compromise. At some point, a RAT has been downloaded and installed on this host, giving the attacker remote access to this endpoint.

The attacker has then moved laterally and gained control of a local admin on Endpoint B. At this stage; they set up their web server (using PowerShell as this is available on every Windows system by default) on the Endpoint as a drop-off point for data. They have then continued moving through the network to Endpoint C where they have found confidential business data that they want to exfiltrate from the network.

Finally, attached to the same switch, we have a Windows machine running Wireshark acting as a network sniffer. The port it has been attached to is set up as a port mirror to deliver all traffic on the switch to the sniffer. This element will come into play when we look at methods of detection and remediation.


There are two prerequisites that the attacker must meet before they can run the web server they have written in PowerShell.

Local Admin Credentials

First, the web server must be run with at least local admin credentials. Without this, the web server will only be able to bind to the local host and not to that endpoints actual IP address. For the attacker, as they are already a local admin, this is as simple as starting an elevated command prompt and beginning the process.

Inbound Traffic Rule

Secondly, a rule must be put in place to allow inbound TCP traffic over the desired port, otherwise, the web server will not be able to receive connections. This can be done via a command prompt with the command:

netsh advfirewall firewall add rule name=”Powershell Webserver” dir=in action=allow protocol=TCP localport=8080

Simply put, this specifies that we are adding a windows firewall rule that allows inbound TCP traffic that is being received on port 8080.

With these requirements fulfilled, the web server can be started on the compromised endpoint (Endpoint B) to listen on the host IP and the specified port. The attacker can then continue to move laterally to other devices within the network that might have confidential data.

Once the malicious actors have located an endpoint (Endpoint C) with confidential data that they wish to exfiltrate they simply POST it back to the web server. This does not require any extra tools and can be done with PowerShell or Python.

The PowerShell example used in this demonstration is only 4 lines of code. The attacker would simply instantiate a ‘System.Net.WebClient’ object and call its upload file method with an address and source file to successfully post data back to the web server.
The confidential data from Endpoint C is now sitting in a folder on the web server on Endpoint B waiting to be exfiltrated out of the network. If the attacker has used a RAT to compromise the network, this document could then be extracted via the RATs link with its controller. Even without a RAT, the malicious actor can still exfiltrate the data from the network itself using the web server. If a port forward, for example, could be created to expose the host with the web server to the internet, any attacker could issue a simple GET request to download anything from the compromised host.


Data exfiltration using built-in resources is not an easy technique for defenders to fight against. In a standard web server, there are built-in logging capabilities that provide detail on who’s connecting from where and doing what. With an impromptu web server like the one demonstrated above, this is not available. However, there are still a few ways we can detect this behaviour.

Live Detection

From a wider network perspective, we could use a network sniffer. If set up properly, a network sniffer could provide visibility of all network traffic, and with a bit of analysis, we can identify suspicious traffic.

In the case of this demonstration, suspicious traffic would be HTTP traffic that exists only within the internal network or GET requests from an external source hitting an endpoint that should not be serving resources to the internet. On an internal network, we generally would only expect to see HTTP traffic that goes endpoint to server, or vice versa, we would not expect to see a great deal of HTTP traffic between two endpoints.

In the demonstration network we already have a network sniffer setup to provide visibility into the traffic crossing the switch. This box runs Wireshark in promiscuous mode to enable it to sniff all the traffic it receives from the port mirror.  However, this is far too much traffic to easily sort through.
Wireshark’s display filters allow us to sort through the traffic and see only the flows that are relevant. Firstly, we filter specifically for HTTP traffic as we are looking for any traffic to and from web servers.

http && ip.src == && ip.dst ==

Next, we filter so that the source and destination IP’s are equal to any in the specific subnet we are looking at. Altogether, this heavily reduces the traffic we have to analyse and lets us identify the anomalous HTTP flows that are heading to locations they shouldn’t be.

With the display filter applied, we have managed to filter down our traffic from 35,000 packets to just the 6.

The traffic we can now see is an instant red flag of suspicious activity. The host .21 and .29 are both normal endpoints, they should not be sending files to each other via HTTP. Drilling further down into the packet details we can confirm our suspicions about the odd activity.

The packet headers show that a file by the name of secretdoc.docx has been attached to the packet. Wireshark can extract files from network flows and an inspection of the file shows us a confidential business document.

We can clearly see business data is being transferred in an unexpected manner between endpoints that should not be communicating in this fashion. Even without the data leaving the network this presents risk and could be evidence of network compromise.
But what if the network administrator doesn’t have the resources to set up a dedicated network sniffer?

In this case, they can utilise Windows’ built-in network capture facility. Netsh is a command line tool available in all versions since Windows 7. Starting a network capture is incredibly simple, open an elevated command prompt and then type:

Netsh trace start capture=yes tracefile=C:\\trace.etl

This simply says, start a trace, capture packets and output the tracefile to the specified directory. If done correctly it should initialise as shown in the image.

To stop the capture simply type:

netsh trace stop

Once we have the trace file, we can then use a tool like Microsoft Network Monitor to analyse it in the same way we did in Wireshark.

It must be noted, however, that there are some limitations to using netsh for traffic capture. Unlike Wireshark, netsh traces cannot be run in promiscuous mode. This means that it will only provide visibility of traffic sent directly to the endpoint it is being run on.

Audit Detection

It is definitely easiest to catch this kind of attack when you can identify the attacker in the act of transferring data. However, this is not always possible, and it becomes necessary to identify IoC’s in audit results.
Event logs provide a key source of information for detection of this behaviour after the event. Security log event 5156 is created whenever a connection is allowed on the system, this can be either inbound or outbound connections. With a quick PowerShell query, we can filter for the events we want and turn them into a more comprehendible CSV format.

Get-WinEvent -FilterHashtable @{logname=’Security’;ID=5156} | Select TimeCreated, ProviderName, Id, MachineName, Message | Export-Csv “C:\Users\jsmith\log.csv” 

Once the CSV has processed, we can search for suspicious indicators quickly and easily. As we did with Wireshark, identifying internal connections with destination ports of 80 or 8080 is a good first step. Checking the application is also helpful; any internal HTTP connections originating from PowerShell or similar should be investigated.
Even when a web server is not actively receiving connections it can still be identified. An active web server will need to listen on its specified ports, so it can receive connections. With the Netstat utility, it is possible to identify all processes that are listening on different ports.
In the example, we have started netstat with the “-ano” flags set. “a” gives us all the connections and listening ports, “n” forces all addresses and ports into a numerical format and “o” provides us with the PID of the process behind the connection.

In the image, we can clearly see at the bottom that a process is listening on port 8080 on all IP addresses of the endpoint. If a process is listening on port 80 or 8080 on a standard endpoint this is suspicious. By convention, normally only HTTP servers listen on port 80 or 8080. As a result, seeing an endpoint with no hosting responsibilities listening on one of these ports could be concerning and worth investigating further.

We could also then pivot off the PID and find out exactly what process is listening here. Using the tasklist command we can identify PID 4 as the system process.

This implies that the listening process is running with high privileges and conveniently leads us to our next detection step.

An attacker will likely want to create some form of persistence method for their web server. Without one they will have to manually access the device and start it every time the host restarts. As we have identified, the web server listening through the System process implies some form of persistence method has been installed.

Identifying persistence is slightly trickier than anything else we have discussed so far, simply because of the fact there are many ways to do it. These include scheduled tasks, startups, runkeys, services and various other methods. For the purpose of this blog, we are just going to demonstrate identifying a scheduled task.

The schtasks utility is a command line tool on all windows systems for managing scheduled tasks. Using the “/ query” command displays all scheduled tasks setup on the system.
The folder we are interested in is the base folder, this is normally where user setup scheduled tasks will be created. In this example, the Powershell Web Server task is what we are interested in. In real life it won’t be as easy as this, an attacker will almost definitely try to hide the purpose of their task, possibly by giving it a random name or the name of a legitimate application. However, this is a good start for identifying persistence via a scheduled task.

Remediation and Prevention

Due to the nature of this tactic, utilising inherent programming capabilities, there is no clear-cut solution for prevention. We could suggest removing PowerShell or other programming resources from every endpoint where it is absolutely not essential. Obviously, this is not practical, many estates rely on PowerShell for administration of endpoints. However, there are some less obstructive controls that we could implement.

The PowerShell web server could not receive connections without a Windows firewall rule in place to allow TCP traffic through on its designated port. As such, tightly controlling Windows firewall rules to ensure only sanctioned ports are opened is a must. If you have a SIEM or log monitoring capability you could then watch the “Windows Firewall With Advanced Security – Firewall” log for event 2004 (New firewall rule created) for a live identification of potentially suspicious rules being created.
The second recommended control is very basic but incredibly vital to security in general. Ensure you maintain your hygiene properly across your estate. To bind the web server to anything but the local host, an attacker requires some form of elevated privilege on the endpoint. There are many ways in which an attacker could achieve this, but we shouldn’t be making it easy for them. Maintaining your hygiene, by removing local admin accounts and ensuring credentials aren’t left behind where they shouldn’t be, makes it more difficult for an attacker to escalate privileges to a point where they can conduct this attack.
Finally, at the end of the day, it is always going to be very difficult to prevent a determined advanced attacker from getting a foothold into the network. Because of this, it is essential that we monitor the network infrastructure and alert on any suspicious activity resembling this behaviour. Use some form of network visibility tool and watch for internal HTTP traffic where both ends of the connections are endpoints.

Edward Russell

Forensic Analyst

Ed is a Cyber Security Analyst at Secrutiny. Prior to this, he studied for a Masters in Computer Science at the University of Kent where he achieved a Distinction.

Currently, Ed’s primary focus is in digital forensics but his interests also include malware analysis and penetration testing.

Keep Up To Date

Join our mailing list to receive the latest news and updates from Secrutiny.


Keeping you up-to-date

*We’d love to keep you up to date with security alerts, free tools & techniques, event invites and company updates. We’ll always treat your details with the utmost care and will never sell them to other companies for marketing purposes. Remember you can change your preferences and opt-out at any time.