NETRESEC Network Security Blog - Tag : CyberChef

rss Google News

Open .ETL Files with NetworkMiner and CapLoader

NetTrace.ETL in CapLoader 1.9.3 and NetworkMiner 2.7.2

Windows event tracing .etl files can now be read by NetworkMiner and CapLoader without having to first convert them to .pcap or .pcapng. The ETL support is included in NetworkMiner 2.7.2 and CapLoader 1.9.3, which were both released this morning.

What is an ETL Trace File?

ETL is short for Event Trace Log, which is ETW session data that has been logged to a file. You can, for example, extract EVTX logs from ETL files. But in this blog post we're gonna focus on network traffic that has been captured to an ETL file with a command like:

netsh trace start capture=yes report=no tracefile=packets.etl
...wait while packets are being captured...
netsh trace stop

Pro-tip: You can specify a capture NIC explicitly with "CaptureInterface=<GUID>"

NetworkMiner and CapLoader can also read packets in Pktmon ETL files, which actually are different from those created with netsh. Capturing packets to an ETL file with Pktmon is very simple:

pktmon start --capture --pkt-size 0 -f packets.etl
...wait while packets are being captured...
pktmon stop

Pro-tip: You can specify capture filters with "pktmon filter add"

You can also capture packets to ETL files with PowerShell:

New-NetEventSession -Name sniffer -LocalFilePath C:\packets.etl
Add-NetEventPacketCaptureProvider -SessionName sniffer -TruncationLength 2000
Start-NetEventSession -Name sniffer
...wait while packets are being captured...
Stop-NetEventSession -Name sniffer
Remove-NetEventSession -Name sniffer

Pro-tip: You capture packets on a remote PC by specifying a CimSession

Advantages

The built-in support for ETL files in NetworkMiner and CapLoader makes it easy to work with ETL files. Not only will you no longer need to go through the extra step of converting the ETL file to PCAP using etl2pcapng or Microsoft Message Analyzer (which was retired in 2019), the analysis will also be faster because both CapLoader and NetworkMiner read ETL files faster compared to etl2pcapng and MMA.

Limitations

The primary limitation with NetworkMiner and CapLoader's ETL support is that it only works in Windows. This means that you will not be able to open ETL files when running NetworkMiner in Linux or macOS.

Another limitation is that both NetworkMiner and CapLoader might fail to parse logged packets if the event trace was created on an OS version with an event manifest that is incompatible with the OS version on which the ETL file is opened.

Under the Hood

Both NetworkMiner and CapLoader leverage Windows specific API calls to read packets from ETL files. An ETL file opened in CapLoader first get converted to PcapNG, then CapLoader parses that PcapNG file. NetworkMiner, on the other hand, parses the packets in the ETL file directly to extract artifacts like files, images and parameters. NetworkMiner's approach is both simpler and quicker, but by converting the ETL file to PcapNG CapLoader can utilize its packet indexing feature to rapidly extract any subset of the captured traffic upon request by the user.

CapLoader's approach is also useful for users who are wondering how to open ETL files in Wireshark, since the packets from an ETL file can be opened in Wireshark by dragging the PcapNG file from the CapLoader GUI onto Wireshark.

Drag-and-drop NetTrace.pcapng from CapLoader to Wireshark
Image: NetTrace.etl converted to PcapNG in CapLoader can be drag-and-dropped onto Wireshark.

Additional Updates in NetworkMiner

The ETL support is not the only new feature in NetworkMiner 2.7.2 though. We have also added support for the ERSPAN protocol. The FTP parser has also been improved to support additional commands, such as AUTH (RFC2228).

We've also added a useful little feature to the context menu of the Parameter's tab, which allows users to send extracted parameters to CyberChef (on gchq.github.io) for decoding.

Submit Parameter value from NetworkMiner to CyberChef
Image: Right-clicking a parameter brings up a context menu with "Submit to CyberChef" option.

Additional Updates in CapLoader

The only major improvement in CapLoader 1.9.3, apart from the built-in ETL-to-PcapNG converter, is that the protocol identification speed and precision has been improved. We've also separated the identification of SSL (version 2.0 to 3.0) and TLS (SSL 3.1 and later) as two separate protocols in this version, whereas they previously both were fingerprinted as "SSL".

Credits

We'd like to thank Dick Svensson and Glenn Larsson for their input on reading ETL files. We also want to thank Markus Schewe for recommending us to add ERSPAN support to NetworkMiner!

Posted by Erik Hjelmvik on Tuesday, 02 November 2021 07:15:00 (UTC/GMT)

Tags: #PowerShell#CapLoader#NetworkMiner#PcapNG#Windows#Wireshark#PCAP#CyberChef

Short URL: https://netresec.com/?b=21B0d0e


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#backdoor#SUNBURST#Solorigate#FireEye#Microsoft#CNAME#STAGE2#Stage 2#DNS#avsvmcloud.com#C2#CyberChef#ASCII-art

Short URL: https://netresec.com/?b=212a6ad

X / twitter

X / Twitter: @netresec


Bluesky

Bluesky: @netresec.com


Mastodon

Mastodon: @netresec@infosec.exchange