NETRESEC Network Security Blog - Tag : PowerShell

rss Google News

IcedID BackConnect Protocol

This is a follow-up to my Hunting for C2 Traffic video. But I didn't have time to record a short video this time, so I wrote a long blog post instead.

UPDATE 2022-11-02

Brad Duncan has released a new pcap file on malware-traffic-analysis.net, which contains an additional C2 command (0x12). Our analysis indicates that this command launches a file manager. This blog post has now been updated with details about this finding.

UPDATE 2022-11-09

Lenny Hansson has released IDS signatures that detect IcedID BackConnect traffic. More details further down in this blog post.

IcedID BackConnect C2 Packet Structure

The IcedID BackConnect (BC) module uses a proprietary command-and-control (C2) protocol that is pretty straight forward. Both client (bot) and the C2 server typically send commands and responses as 13 byte packets using the following structure:

  • Auth: 4 bytes
  • Command: 1 byte
  • Params: 4 bytes
  • ID: 4 bytes

Auth Field

The "Auth" field is presumably used by the bot and C2 server to verify that the other party is communicating using the same protocol and version.

As mentioned by Group-IB and xors the Auth field is typically 0x974F014A (little endian), but we prefer to use the network byte order representation "4a 01 4f 97".

In their IcedID blog post from 2020 Group-IB say:

the auth field that has not changed since at least version 5 of the IcedID core is the constant 0x974F014A

Nevertheless, we recently noticed another IcedID Auth field being used in the wild. But more on that later.

Commands

The following list of IcedID BackConnect C2 commands has been compiled by combining those mentioned by Group-IB with our own analysis of the IcedID BackConnect protocol:

  • 0x00 = Bot queries for a task
  • 0x01 = Set sleep timer
  • 0x02 = Bot error
  • 0x03 = Reconnect
  • 0x04 = Start SOCKS
  • 0x05 = Start VNC

We've also discovered these additional commands in IcedID BackConnect C2 traffic that uses the Auth value "1f 8b 08 08":

  • 0x11 = Start VNC
  • 0x12 = Start file manager
  • 0x13 = Start reverse shell

Commands 0x04, 0x05, 0x11, 0x12 and 0x13 all cause the bot to connect back to the C2 server using a new BackConnect session, which will be used to wrap either SOCKS, VNC, file manager or reverse shell traffic.

Command 0x01: Set Sleep Timer

The set sleep timer command is issued by the C2 server to instruct the bot to sleep for a certain amount of time before requesting a new task from the C2 server again. The sleep time is defined in the four bytes following directly after the 0x01 command. This value is a 32-bit little endian value indicating the number of seconds the bot should sleep, i.e. "3c 00 00 00" = 0x0000003c = 60 seconds. The most common sleep value seems to be 60 seconds, which is why you'll often see byte sequences like this in IcedID C2 sessions:

zz zz zz zz 01 3c 00 00 00 xx xx xx xx

The following Wireshark display filter will show IcedID C2 packets, where the bot is configured to sleep for 60 seconds before querying the C2 server for a new command:

tcp.len == 13 and tcp.payload[4:5] == 01:3c:00:00:00

Command 0x04: Start SOCKS

The SOCKS command (0x04) instructs the bot to start the SOCKS module. As an example, the following byte sequence was sent by the IcedID C2 server 91.238.50.80:8080 in Brad Duncan's 2022-06-28 TA578 IcedID pcap on malware-traffic-analysis.net (see frame #10231):

4a 01 4f 97 04 09 00 00 00 8c a2 b1 09

The first four bytes are the auth value, followed by the Start SOCKS command (04).

After receiving this command the bot established a new TCP connection back to the C2 server, where it echoed back the server's "Start SOCKS" command and then started acting like a SOCKS server.

Except for initially echoing the IcedID Start SOCKS command the SOCKS module actually seems to be compliant with RFC1928, which defines the SOCKS5 protocol. This means that the C2 server can supply an IP address and port number to the bot's SOCKS proxy in order to relay a connection to that host through the bot.

SOCKS packet from IcedID in Wireshark

Image: C2 server instructs bot to relay a connection to 188.40.30.100:80

After receiving a Start SOCKS command an IcedID bot immediately establishes a new TCP connection to the specified IP and port, and relays the application layer data back to the C2 server through the SOCKS connection.

Update check of Advanced Port Scanner

Image: Update check of Advanced Port Scanner relayed through the infected machine

In the 2022-06-28 TA578 IcedID pcap the attacker used multiple SOCKS connections to scan the 10.6.21.0/24 network for services running on TCP ports 21, 80, 445 and 4899. That last port (TCP 4899) is typically used by Radmin VPN, which just so happens to be created by the outfit "Famatech" who also develop the "Advanced Port Scanner". The attacker also used the SOCKS module to make several HTTPS connections to servers like 18.204.62.252 (tlx.3lift[.]com), 23.94.138.115 (cmd5[.]org) and 74.119.118.137 (cat.da.us.criteo[.]com). The attacker also proxied connections to 40.97.120.242 and 52.96.182.162 (outlook.live.com) through the infected bot.

NetworkMiner Hosts tab

NetworkMiner showing hosts that the bot proxied TLS traffic to

JA3 Fingerprints from Proxied Traffic

Since the SOCKS proxy doesn't touch the application layer data we know that the client TLS handshake packets are coming from the C2 server rather than from the bot that's running the SOCKS proxy. This means that we can fingerprint the actual TLS client using JA3.

JA3 hashes in CapLoader

As you can see in the CapLoader screenshot above, most proxied TLS sessions use the cd08e31494f9531f560d64c695473da9 JA3 hash, but two of them use the rare JA3 hash 598872011444709307b861ae817a4b60. That rare JA3 hash was used only when connecting to outlook.live.com.

Command 0x05 or 0x11: VNC

Brad Duncan's 2022-06-28 TA578 IcedID pcap also contains the "Start VNC" command 0x05.

Flow transcript of Start VNC command

Image: Flow transcript of Start VNC command

As can be seen in the CapLoader screenshot above, Start VNC commands were sent at 16:33:33 and 16:34:06 UTC. And just like the SOCKS command, this caused the bot to establish a new connection back to the C2 server, echo the "Start VNC" command and then proceed with the VNC traffic.

Flow transcript of IcedID VNC traffic in ASCII encoding

Image: Flow transcript of IcedID VNC traffic in ASCII encoding

Command 0x13: Reverse Shell

Brad posted a new capture file with network traffic from another IcedID infection last week (2022-10-04). He also noted that the traffic to 51.89.201.236:8080 was different from normal IcedID post-infection traffic.

I've sometimes seen DarkVNC over TCP port 8080 with IcedID infections, but this traffic definitely is -not- DarkVNC

After looking at this C2 traffic I discovered that it was in fact using the IcedID BackConnect protocol outlined in this blog post, but the Auth field "4a 01 4f 97" had been replaced with "1f 8b 08 08".

That exact byte sequence is a common file header for gzip compressed files (RFC1952), where

  • 1f 8b = GZIP magic
  • 08 = DEFLATE compression
  • 08 = Original file name header present

IcedID has previously been seen using fake gzip file headers in payloads, but this time even the C2 packets include the gzip header!

Transcript of TCP session to 51.89.201.236:8080

Image: Transcript of TCP session to 51.89.201.236:8080

The C2 traffic also contained the command 0x13, which I hadn't seen before. Just like the SOCKS and VNC commands, this one triggered the bot to establish a new connection back to the C2 server. But the bot sent a task query command (00) this time, instead of echoing the C2 server's command (0x13). The new TCP session then transitioned into what looks like a reverse shell session.

PowerShell download from https://aicsoftware[.]com:757/coin

Image: Transcript of reverse shell traffic from IcedID BackConnect session

The reverse shell traffic reveals that the attackers retrieved a list of domain admin users and then executed a PowerShell script from aicsoftware[.]com. This PowerShell script was used to install CobaltStrike beacon on the victim's PC.

Command 0x12: File Manager

We discovered the file manager command after this blog post was published. This section has therefore been added after the original publication of this blog post.

The following Wireshark display filter can be used to find file manager commands (0x12) in IcedID C2 traffic that uses the "1f 8b 08 08" auth value:

tcp.len == 13 and tcp.payload[0:5] == 1f:8b:08:08:12

Wireshark display filter to identify IcedID C2 file manager commands

Image: File manager commands in IcedID BackConnect C2

The screenshot above shows that the file manager command was issued three times in 2022-10-31-IcedID-with-DarkVNC-and-Cobalt-Strike-full-pcap-raw.pcap.

IcedID File Manager sessions in CapLoader's Flows view

Image: IcedID TCP sessions in CapLoader's Flows view

As you can see in the two screenshots above, each time a file manager command was issued in the C2 session (Wireshark screenshot) the bot established a new TCP connection back to the C2 server (CapLoader screenshot).

The file manager sessions use a proprietary protocol to perform tasks such as listing disks, changing directory and uploading files.

IcedID File Manager session in CapLoader's Flows Transcript

We've identified the following file manager commands:

  • DISK = List drives
  • CDDIR <path> = Change directory
  • PWD = Show current directory
  • DIR = List current directory
  • PUT <path> = Upload file

IDS Signatures

Lenny Hansson has released IDS signatures that can detect IcedID BackConnect traffic. I'd like to highlight three of Lenny's signatures here.

Alert on "sleep 60 seconds" C2 command, regardless of Auth value:

alert tcp $EXTERNAL_NET 8080 -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Wait Command"; flow:established; flags:AP; dsize:13; content:"|01 3c 00 00 00|"; offset:4; depth:5; reference:url,networkforensic.dk; metadata:02112022; classtype:trojan-activity; sid:5006006; rev:2;)

Alert on "start VNC" C2 command with "4a 01 4f 97" Auth:

alert tcp $EXTERNAL_NET 8080 -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Start VNC command"; flow:established; flags:AP; dsize:13; content:"|4a 01 4f 97 05 00|"; offset:0; depth:6; reference:url,networkforensic.dk; metadata:03112022; classtype:trojan-activity; sid:5006007; rev:1;)

Alert on "start file manager" C2 command with "1f 8b 08 08" Auth:

alert tcp $EXTERNAL_NET 8080 -> $HOME_NET 1024: (msg:"NF - Malware IcedID BackConnect - Start file manager command"; flow:established; flags:AP; dsize:13; content:"|1f 8b 08 08 12|"; offset:0; depth:5; reference:url,networkforensic.dk; metadata:03112022; classtype:trojan-activity; sid:5006008; rev:1;)

These IDS rules all specify 8080 as the C2 port. You might want to change "8080" into "any" or "[443,8080]" in order to identify IcedID BackConnect C2 traffic on ports other than 8080.

A zip file containing Lenny's Snort rules can be downloaded from networkforensic.dk.

Questions and Answers

Allright, that's all I had to say about the IcedID BackConnect C2 protocol. I'm now ready to take your questions.

Q: Is IcedID's BackConnect VNC traffic the same thing as DarkVNC?

No, DarkVNC traffic doesn't use the IcedID BackConnect C2 Packet Structure described in this blog post. Also, one characteristic behavior DarkVNC is that the first C2 packet contains a string that looks like one of these:

  • (COMPUTERNAME)_ADDITIONAL_ID-DARKVNC
  • BOT-COMPUTERNAME(USERNAME)_ID-REFnnn
  • USR-COMPUTERNAME(USERNAME)_ID-REFnnn
Additionally, the first four bytes in the DarkVNC packets containing one of the strings above is a 32 bit little endian length field. For more details on DarkVNC, see the archived blog post A short journey into DarkVNC attack chain from REAQTA.

Q: Is IcedID's BackConnect VNC traffic the same thing as hVNC?

Almost. hVNC means "hidden VNC" and includes any type of malicious VNC server running on a victim's PC, including IcedID's VNC module as well as DarkVNC.

Q: How did you get Wireshark to decode the SOCKS traffic from IcedID BackConnect?

  1. Open the pcap file from 2022-06-28 TA578 IcedID
  2. Apply display filter: tcp.port eq 8080
  3. Right-click, Decode As, TCP port 8080 = SOCKS
  4. Display filter: tcp.dstport eq 8080 and tcp.len eq 13 and tcp.payload[0:5] eq 4a:01:4f:97:04
  5. Select all packets (Ctrl+A)
  6. Edit, Ignore Packets (Ctrl+D)
  7. Display filter: socks.dst

Q: Can CapLoader's Protocol Identification feature detect the IcedID BackConnect protocol?

The current version (1.9.4) doesn't have a protocol model for the BackConnect protocol, but the next CapLoader release will be able to identify this type if IcedID C2 traffic.

Posted by Erik Hjelmvik on Wednesday, 12 October 2022 18:24:00 (UTC/GMT)

Tags: #IcedID#TA578#SOCKS#SOCKS5#JA3#gzip#PowerShell

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=22A38f9


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

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=21B0d0e


Remote Packet Dumps from PacketCache

PacketCache logo

This blog post describes how to dump a packet capture (pcap file) on a remote computer, which runs the PacketCache service, and retrieve that pcap file using only PowerShell.

PacketCache is a free Windows service that continously sniffs network traffic on all interfaces (Ethernet, WiFi, 3G, LTE etc) and maintains a cache of the most recent traffic in RAM. This enables incident responders to read PCAP data out of a PC's PacketCache, for example when an IDS or anti-virus alerts on something potentially malicious. Unfortunately, there is no central management tool for PacketCache, which means that the PCAP data has to be dumped locally at the PC that triggered the IDS or AV alert.

There are a few workarounds "hacks" available to solve this problem, but the most elegant solution is to leverage PowerShell Remoting / WinRM in order to trigger a remote PacketCache instance to create a PCAP file and then copy the PCAP file through the same PowerShell session. To make things even simpler we've created a PowerShell script that can be used to download a PCAP file from any machine running PacketCache. Okay, maybe not *any* machine, the script only works on PCs that you have admin credentails for. Nevertheless, here's how you run the script from a PowerShell prompt:

PS C:\> .\ReadRemotePacketCache.ps1 DESKTOP-LT4711 Administrator
[*] Dumping PacketCache at DESKTOP-LT4711
[*] Copying PCAP dump from DESKTOP-LT4711
[*] Remote PacketCache data saved to DESKTOP-LT4711_181112_1337.pcap
PS C:\>

The ReadRemotePacketCache.ps1 script can be downloaded from the PacketCache product page.


Configuring Hosts for PowerShell Remoting

If you have not previously set up your environment for PowerShell remoting, then you will need to follow these steps before invoking the "ReadRemotePacketCache.ps1" script as above.

On the remote PC, start PowerShell as administrator and enable PowerShell remoting with the "Enable-PSRemoting" command as shown here:

PS C:\> Enable-PSRemoting -SkipNetworkProfileCheck -Force
WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.

WinRM has been updated for remote management.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely
to local users.

PS C:\>

Configuring TrustedHosts for Workgroups

You will also need to set up a trust relationship between the local and remote host. If the remote PC is member of an Active Directory domain, then this trust is already in place. However, if you're in a workgroup or the computers are not in the same domain, then you will need to set the TrustedHosts item like this on both the local PC and the remote PC:

PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts [IP or Hostname of the other PC]
PS C:\> Get-Item WSMan:\localhost\Client\TrustedHosts
PS C:\> Restart-Service WinRM

Note: if you need to dump PacketCache data from several remote hosts, then you can replace the IP/hostname with '*' to trust any PC or supply a comma separated list of individual hostnames or IPs to trust.

If you've configured TrustedHosts correctly, then you should be able to run the "ReadRemotePacketCache.ps1" script as shown previously. However, if the remote PC isn't in TrustedHosts, then you'll most likely get an error message like this:

PS C:\> .\ReadRemotePacketCache.ps1 10.0.13.37 Administrator
New-PSSession : [10.0.13.37] Connecting to remote server 10.0.13.37 failed with the following error message : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

Automating Remote Artifact Collection

With PowerShell remoting in place you're not limited to just dumping packets from a remote PacketCache service, you can also dump the RAM or copy individual files from the remote computer. This comes in handy in order to implement an automated evidence/artifact collection, for example when a high-severity alert is received by your SIEM.

There are frameworks in place that can help with aquisition of memory and files, such as Matthew Green's Invoke-LiveResponse tool, which can dump memory with WinPMEM and leverage PowerForensics to enable remote raw disk access. Some organizations even start sniffing packets at events like this, but this will only capture the traffic from after a potential compromize. This is where PacketCache comes in, since it can allow you to retrieve packets ranging back as far as a couple of days before the alert.


Credential Theft

It is recommended to use unique passwords for each local account with administrator rights. This practice is extra important if you plan to log into a potentially compromized host using administrator credentails, as described in this blog post. You might also want to lock down the local admin accounts even further in order to minimize the consequences of the admin credentials falling into the wrong hands. See Microsoft's articles on "Local Accounts" and "Attractive Accounts for Credential Theft" for more recommendations regarding how to secure local admin accounts.


PacketCache is Free

CC BY-ND PacketCache is free to use, even commercially. It is released under a Creative Commons Attribution-NoDerivatives 4.0 International License, which means that you can copy and redistribute PacketCache in any medium or format for any purpose. You can download PacketCache here:

https://www.netresec.com/?page=PacketCache

The PowerShell script presented in this blog post is also shared under the same CC license and can be downloaded from the PacketCache product page.


Credits

I'd like to thank Dick Svensson for suggesting the use of PowerShell Remoting to read PacketCache data remotely!

Posted by Erik Hjelmvik on Wednesday, 14 November 2018 08:00:00 (UTC/GMT)

Tags: #Netresec#PCAP#PowerShell#PacketCache#Windows

Share: Facebook   Twitter   Reddit   Hacker News Short URL: https://netresec.com/?b=18B9747

Mastodon

NETRESEC on Mastodon: @netresec@infosec.exchange

twitter

NETRESEC on Twitter: @netresec