This video covers a life cycle of an Emotet infection, including initial infection, command-and-control traffic,
and spambot activity sending emails with malicious spreadsheet attachments to infect new victims.
The video was recorded in a Windows Sandbox in order to avoid accidentally infecting my Windows PC with malware.
Initial Infection
Palo Alto's Unit 42 sent out a
tweet with screenshots and IOCs from an Emotet infection in early March.
A follow-up tweet by Brad Duncan linked to a PCAP file containing
network traffic from the infection on Malware-Traffic-Analysis.net.
Image: Screenshot of original infection email from Unit 42
Attachment MD5: 825e8ea8a9936eb9459344b941df741a
Emotet Download
The PCAP from Malware-Traffic-Analysis.net shows that the Excel spreadsheet attachment caused the download of a DLL file
classified as Emotet.
The victim PC eventually started sending out spam emails.
The spam bot used TLS encryption when possible, either through SMTPS (implicit TLS) or with help of STARTTLS (explicit TLS).
Below is a spam email sent from the victim PC without TLS encryption.
The attached zip file contains a malicious Excel spreadsheet,
which is designed to infect new victims with Emotet.
Image: Spam email extracted from Emotet PCAP with NetworkMiner
My lightning talk from the SEC-T 0x0D conference has now been
published on YouTube.
This 13 minute talk covers tactics and techniques that the SolarWinds hackers used
in order to avoid being detected.
Some of these tactics included using DNS based command-and-control (C2) that mimicked Amazon AWS DNS traffic, blending in with SolarWind’s legitimate source code and handpicking only a small number of targets.
One thing I forgot to mention in my SEC-T talk though, was the speed at which the attackers were working to analyze incoming data from the trojanized installs and selecting organizations to
target for stage two operations.
For example, just during June 2020 the attackers got more than 1300 new organizations that started beaconing in using the DNS-based C2.
The beaconed data only included the organizations’ Active Directory domain name and a list of
installed security applications.
Based on this information the attackers had to decide whether or not they wanted to target the organization.
We have previously estimated that less than 1% of the organizations were targeted, while the malicious backdoor was disabled for all the other 99% who had installed the trojanized SolarWinds Orion update.
The attackers typically decided whether or not to target an organization within one week from when they started beaconing.
This means that the attackers probably had several hundred organizations in queue for a targeting decision on any given week between April and August 2020.
That's a significant workload!
Posted by Erik Hjelmvik on Monday, 18 October 2021 10:30:00 (UTC/GMT)
In this video I demonstrate that text typed into the Windows 10 start menu gets sent to Microsoft and how
that traffic can be intercepted, decrypted and parsed.
What Was Sent?
The XML files shown in the video were sent by Cortana's "SmartSearch" app to https://www.bing.com/threshold/xls.aspx in HTTP/2 POST requests.
As shown in the video, the POST'ed keystrokes can be found inside requestInfo XML tags that have a "RawQuery" key.
The following tcpdump and grep commands can be used to list the RawQuery data sent to Bing in these HTTP/2 requests:
tcpdump -A -r proxy-210927-134557.pcap | grep -a -o 'key="RawQuery" value="[^"]*"'
Running that command on the PolarProxy PCAP file from the video gives the following output:
The same data also gets sent in the query string variable "qry" of GET requests for
https://www.bing.com/AS/API/WindowsCortanaPane/V2/Suggestions, as shown in this NetworkMiner screenshot.
Image: NetworkMiner's Parameters tab with filter "qry" on "Parameter name" column
How to Intercept, Decrypt and Decode HTTPS Traffic
The following section presents the technical details regarding my setup,
so that others can reproduce and verify these findings.
My first step was to install PolarProxy on a Linux machine on the local network.
PolarProxy is a TLS proxy, which can intercept and decrypt TLS traffic.
This TLS proxy is primarily designed to decrypt traffic from malware and hackers,
but can also be used to decrypt legitimate traffic when needed.
PolarProxy was configured to listen for incoming TLS connections on TCP port 443
and output PCAP data with the decrypted traffic as if it had been transmitted over TCP 80.
The decrypted traffic was accessible as a real-time stream through a
PCAP-over-IP service running on port 57012.
Here's the full command that was used to start PolarProxy:
In the video I showed the Windows 10 client's modified hosts file, which included an entry for www.bing.com pointing to the PolarProxy machine.
What was not shown in the video though, is that PolarProxy's own CA certificate had been added to the Win10 machine's list of trusted root CA's,
as explained in the "Trusting the PolarProxy root CA" section of the PolarProxy installation instructions.
With these two changes in place all HTTPS requests for www.bing.com from the Win10 PC got diverted through the PolarProxy TLS inspection service,
which then decrypted and re-encrypted the traffic before forwarding it to Bing.
The decrypted Bing requests could be accessed either locally on the Linux machine,
or remotely using the PCAP-over-IP service on TCP port 57012.
I used NetworkMiner to read the live PCAP stream with decrypted traffic from port 57012 and extract all files being sent and received in real-time.
As part of delivering Windows 10 as a service, updates may be delivered to provide ongoing new features to Bing search, such as new visual layouts, styles and search code.
No query or search usage data is sent to Microsoft, in accordance with the customer's chosen privacy settings.
There are plenty of how-to guides online with instructions on how the Cortana search feature can be disabled.
Most of these guides suggest disabling the AllowCortana setting in group policies or in the registry.
We've tried several of the settings suggested in these how-to guides, but none of them seem to prevent Windows from sending keystrokes to Bing.
If you know how to successfully disable Cortana's Bing searches,
then please feel free to reach out to us so that we can update this blog post.
UPDATE 210928 - How to Actually Disable Cortana Search
Twitter user @GeorgeProfonde3 reached out
to suggest a fix that might prevent the start menu from sending data to Bing.
We have now verified this fix and we're happy to announce that it works (at least for us).
Start regedit.exe
Open the following registry key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Search
Ensure that the value for CortanaConsent is set to 0
Create a new DWORD registry entry called "BingSearchEnabled" with value 0
You should no longer see any connections to www.bing.com when interacting with the start menu after implementing this fix.
UPDATE 211015 - Another way to Disable Cortana Search
You may need to use a different method to disable the start meny search, depending on your Windows version and build.
Kimberly (@StopMalvertisin) suggested the following method, which seems to work on Windows 11:
Start regedit.exe
Create a registry key for: HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Explorer
Create a new DWORD registry entry called "DisableSearchBoxSuggestions" with value 1
Disabling Start Menu Search from Group Policy
There are also a few different methods for disabling start menu searches using GPO.
However, please note that your success will vary depending on your Windows version and build.
GPO Method #1
Start gpedit.msc
Open the following branch: User configuration\Administrative templates\Windows components\File Explorer
Enable the following group policy:
"Turn off display of recent search entries in the File Explorer search box"
GPO Method #2
Start gpedit.msc
Open the following branch: User Configuration\Administrative Templates\Start Menu and Taskbar
Enable the following group policy:
"Do not search communications"
Posted by Erik Hjelmvik on Tuesday, 28 September 2021 08:24:00 (UTC/GMT)
I recently came across a fantastic digital forensics dataset at dfirmadness.com,
which was created by James Smith.
There is a case called The Stolen Szechuan Sauce
on this website that includes forensic artifacts like disk images, memory dumps and a PCAP file (well, pcap-ng actually).
In this video I demonstrate how I analyzed the capture file case001.pcap from this case.
Follow Along in the Analysis
Please feel free to follow along in the analysis performed in the video.
You should be able to use the free trial version of CapLoader
and the free open source version of NetworkMiner
to perform most of the tasks I did in the video.
Here are some of the BPF and Column Criteria filters that I used in the video, so that you can copy/paste them into CapLoader.
net 10.0.0.0/8
Umbrella_Domain =
not ip6 and not net 224.0.0.0/4
host 194.61.24.102 or host 203.78.103.109 or port 3389
This video shows how Cobalt Strike and Hancitor C2 traffic can be detected using CapLoader.
I bet you’re going:
😱 OMG he’s analyzing Windows malware on a Windows PC!!!
Relax, I know what I’m doing. I have also taken the precaution of analyzing the PCAP file in a
Windows Sandbox, which just takes a couple of seconds to deploy and run.
CapLoader’s Services tab shows us that the connections to TCP 80 and 443 on 103.207.42.11 are very periodic, with a detected period of exactly 1 minute.
CapLoader successfully identifies the protocols for these two services as Cobalt Strike over HTTP and Cobalt Strike over SSL, respectively.
The third service in this list is also very periodic, that’s the Hancitor trojan beaconing to its C2 server every two minutes.
CapLoader uses machine learning to identify the application layer protocol based on the behavior of the traffic, not the port number.
This means that there can be false positives, i.e. the protocol classification that CapLoader gives a flow or service might be wrong.
It is more common, however, for CapLoader to yield false negatives, which means that it can't identify the protocol.
The detection of Cobalt Strike inside of HTTP and SSL traffic was recently introduced in the latest
1.9 release of CapLoader.
I expected this feature to detect Cobalt Strike traffic in HTTP, but I was delighted to see that CapLoader often detects even TLS encrypted Cobalt Strike beaconing with really good precision!
As shown in the video, the Cobalt Strike beacon config can easily be extracted from the network traffic using
NetworkMiner and Didier Stevens’
1768 K python script.
The output from Didier’s 7868.py tool looks something like this:
As you can see, it uses HTTP for transport with a “sleeptime” of 1 minute (60000 ms) and 0% jitter.
This means that a new connection will be made to the Cobalt Strike C2 server every minute.
The fact that there was no jitter is what gives this service such a high value in CapLoader’s “Periodicity” column.
Network Forensics Training
Are you interested in learning more about how to analyze network traffic from Cobalt Strike and other backdoors, malware and hacker tools?
Then take a look at the live online network forensics classes I will be teaching in September and October!
Posted by Erik Hjelmvik on Monday, 31 May 2021 08:30:00 (UTC/GMT)
Modern malware and botnet C2 protocols use TLS encryption in order to blend in with "normal" web traffic,
sometimes even using legitimate services like
Twitter or
Instagram.
I did a live demo at the CS3Sthlm conference last year, titled
"TLS Interception and Decryption",
where I showed how TLS interception can be used to decrypt and analyze malicious HTTPS network traffic.
During the demo I used DNS-over-HTTPS (DoH) and posted messages to Pastebin and Twitter,
pretending to be a malware or malicious actor.
The HTTPS network traffic was decrypted and analyzed live as part of my demo.
The CS3Sthlm organizers have posted a
video recording of the live demo
on YouTube.
Image: Erik demoing TLS Interception and Decryption at CS3Sthlm 2019
We are now releasing a PCAP file with the decrypted network traffic captured during this live demo here:
This blog post provides a step-by-step walk-through of the decrypted HTTPS traffic in the released capture file.
The TLS decryption was performed by connecting a laptop to a custom WiFi access point,
which was a Raspberry Pi configured as in our
"Raspberry Pi WiFi Access Point with TLS Inspection"
blog post.
I additionally enabled the
PCAP-over-IP feature in PolarProxy
by starting it with the "--pcapoverip 57012" option.
This allowed me to connect with Wireshark and
NetworkMiner to TCP port 57012 on the TLS proxy and stream the decrypted traffic in order to perform live network traffic analysis.
Image: Live demo network with Laptop (Browser, NetworkMiner, Wireshark), Raspberry Pi (PolarProxy) and the Internet.
Below follows a breakdown of various significant events of my demo and where you can find these events in the released capture file.
DNS lookup of "www.google.com" using DoH
Frame: 833
Protocol: DoH using HTTP/2 POST
Five tuple: 192.168.4.20:52694 104.16.248.249:80 TCP
Google search for "tibetan fox psbattle"
Frame: 2292
Protocol: HTTP/2
Five tuple: 192.168.4.20:52716 216.58.211.4:80 TCP
Tibetan Fox image downloaded from reddit
Frame: 3457
Protocol: HTTP/2
Five tuple: 192.168.4.20:52728 151.101.85.140:80 TCP
Five tuple: 192.168.4.20:52769 151.101.84.193:80 TCP
DNS Lookup of "cs3sthlm.se"
Frame: 13494
Protocol: DoH using HTTP/2 POST
Five tuple: 192.168.4.20:52699 104.16.249.249:80 TCP
Images downloaded from CS3Sthlm's website
Frame: 14134
Protocol: HTTP/1.1
Five tuple: 192.168.4.20:52896 192.195.142.160:80 TCP
Data sent in HTTP/2 POST to Pastebin
Frame: 18572
Protocol: HTTP/2 POST
Five tuple: 192.168.4.20:52904 104.22.2.84:80 TCP
The file "post.php.form-data" contains the data sent to Pastebin in the HTTP/2 POST request.
Here are the reassembled contents of that file, including the "hello cs3 I am a malware" message:
Five tuple: 192.168.4.20:53210 104.244.42.65:80 TCP
Mallory80756920 posts a Tweet
Frame: 26993
Protocol: HTTP/2 POST
Five tuple: 192.168.4.20:53251 104.244.42.66:80 TCP
Mallory80756920 tweeted "Hello CS3! I'm in you!". The data was sent to twitter using an HTTP/2 POST request.
Conclusions
A great deal of the interesting TLS traffic in the analyzed capture file is using the HTTP/2 protocol.
This doesn't come as a surprise since more than half of all HTTPS traffic is using HTTP/2 nowadays
(sources: server protocol statistics,
client protocol statistics).
It is therefore essential to be able to analyze HTTP/2 traffic if you have a TLS inspection (TLSI) solution in place.
Unfortunately many TLSI products don't yet support the HTTP/2 protocol.
Wireshark was one of the first network traffic analysis tools to implement HTTP/2 support,
much thanks to Alexis La Goutte.
However, Wireshark's excellent "File > Export Objects" doesn't yet support extraction of files from HTTP/2 traffic.
There are other ways to extract HTTP/2 file transfers with Wireshark,
but they require a few additional steps in order to carve out the file to disk.
Luckily NetworkMiner extracts files from HTTP/2 as of version 2.5.
In fact, we believe NetworkMiner is the first open source tool to support automatic HTTP/2 file extraction from PCAP.
Finally, I'd like to stress the point that modern malware use HTTPS, so you need to have a TLSI solution in place to analyze the malicious traffic.
As the majority of all HTTPS traffic is using HTTP/2 you also need to ensure that you're able to analyze HTTP/2 traffic passing through your TLSI solution.
Posted by Erik Hjelmvik on Monday, 13 January 2020 12:45:00 (UTC/GMT)
This video tutorial is a walkthrough of how you can analyze the PCAP file
UISGCON-traffic-analysis-task-pcap-2-of-2.pcap
(created by Brad Duncan).
The capture file contains a malicious Word Document (macro downloader), Emotet (banking trojan),
TrickBot/Trickster (banking trojan) and an EternalChampion (CVE-2017-0146)
exploit used to perform lateral movement.
Wanna improve your network forensics skills? Take a look at our
trainings,
the next scheduled class is on March 18-19 at the
TROOPERS conference in Germany.
Posted by Erik Hjelmvik on Wednesday, 23 January 2019 14:00:00 (UTC/GMT)
This short video demonstrates how you can search through PCAP files with regular expressions (regex) using
CapLoader and how this can be leveraged in order to
improve IDS signatures.
The EmergingThreats snort/suricata rule mentioned in the video is
SID 2014411
“ET TROJAN Fareit/Pony Downloader Checkin 2”.
The header accept-encoding header with quality factor 0 used by the Pony malware is: Accept-Encoding: identity, *;q=0
And here is the regular expression used to search for that exact header:
\r\nAccept-Encoding: identity, \*;q=0\r\n
After recording the video I noticed that the leaked source code for Pony 2.0 actually contains this accept-encoding header as a
hard-coded string. Have a look in the
redirect.php file, where they set
curl’s CURLOPT_HTTPHEADER to this specific string.
Wanna learn more about the intended use of quality factors in HTTP accept headers?
Then have a look at section 14.1 of RFC 2616section 5.3.4 of RFC 7231, which defines how to use qvalues (i.e. quality factors) in the Accept-Encoding header.
