In this video I take a look at a cryptojacking attack against a Kubernetes honeypot.
The attackers were surprisingly quick to discover this unsecured Kubernetes deployment and use it to mine Monero for them.
The capture files named "proxy-", such as the analyzed proxy-220404-162837.pcap, were generated by PolarProxy and contain the decrypted Kubernetes API traffic to the master node.
This traffic was actually TLS encrypted, but since PolarProxy was used as a TLS interception proxy we can see the Kubernetes API traffic in decrypted form.
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 our upcoming network forensics classes!
Posted by Erik Hjelmvik on Thursday, 04 January 2024 10:12:00 (UTC/GMT)
In this video I analyze network traffic from a QakBot (QBot) infection in order to identify the Command-and-Control (C2) traffic.
The analyzed PCAP file is from malware-traffic-analysis.net.
Note: This video was recorded in a Windows Sandbox to minimize the risk of infecting the host PC in case of accidental execution of a malicious payload from the network traffic.
As I have previously pointed out, IcedID sends beacons to the C2 server with a 5 minute interval. According to Kai Lu’s blog post A Deep Dive Into IcedID Malware: Part 2, this 5 minute interval is caused by a call to WaitForSingleObject with a millisecond timeout parameter of 0x493e0 (300,000), which is exactly 5 minutes.
UPDATE 2023-03-22
In the research paper
Thawing the permafrost of ICEDID
Elastic Security Labs confirm that IcedID's default polling interval is 5 minutes. They also mention that this interval is configurable:
Once initialized, ICEDID starts its C2 polling thread for retrieving new commands to execute
from one of its C2 domains.
The polling loop checks for a new command every N seconds as defined by the
g_c2_polling_interval_seconds global variable. By default this interval is 5 minutes, but one of
the C2 commands can modify this variable.
The IcedID trojan uses a custom BackConnect protocol in order to interact with victim computers through VNC, a file manager or by establishing a reverse shell.
There was no IcedID BackConnect traffic in this particular PCAP file though, but
severalother IcedID capture files published on malware-traffic-analysis.net do contain IcedID BackConnect traffic.
For more information on this proprietary protocol, please see our blog post IcedID BackConnect Protocol.
Check out our upcoming live network forensics classes for more hands-on network forensic analysis. Our current class material doesn’t include any IcedID traffic though, instead you’ll get to investigate C2 traffic from Cobalt Strike, TrickBot, njRAT, Meterpreter and a few others.
Posted by Erik Hjelmvik on Wednesday, 15 February 2023 10:52:00 (UTC/GMT)
The most important addition in the 1.9.5 release is the new Alerts tab, in which CapLoader warns about malicious network traffic such as command-and-control protocols. The alerts tab also shows information about network anomalies that often are related to malicious traffic, such as periodic connections to a particular service or long running sessions.
Other additions in this new version are:
BPF support for “vlan” keyword, for example “vlan”, “not vlan” or “vlan 121”
Support for nanosecond PCAP files (magic 0xa1b23c4d)
Support for FRITZ!Box PCAP files (magic 0xa1b2cd34)
Decapsulation of CAPWAP protocol, so that flows inside CAPWAP can be viewed and filtered on
Domain names extracted from TLS SNI extensions
Alerts for Malicious Network Traffic
As you can see in the video at the end of this blog post, the Alert tab is a fantastic addition for everyone who wants to detect malicious activity in network traffic. Not only can it alert on over 30 different malicious command-and-control (C2) protocols — including
Cerber,
Gozi ISFB,
IcedID, RedLine Stealer,
njRAT and QakBot — it also alerts on generic behavior that is typically seen in malware traffic.
Examples of such generic behavior are periodic connections to a C2 server or long running TCP connections. This type of behavioral analysis can be used to detect C2 and backdoor traffic even when the protocol is unknown. There are also signatures that detect “normal” protocols, such as HTTP, TLS or SSH running on non-standard ports as well as the reverse, where a standard port like TCP 443 is carrying a protocol that isn’t TLS.
Many of CapLoader’s alert signatures are modeled after threat hunting techniques, which can be used to detect malicious activities that traditional alerting mechanisms like antivirus, EDR’s and IDS’s might have missed. By converting the logic involved in such threat hunting tasks into signatures a great deal of the analysts’ time can be saved. In this sense part of CapLoader’s alerting mechanism is a form of automated threat hunting, which saves several steps in the process of finding malicious network traffic in a packet haystack.
Watch my Hunting for C2 Traffic video for a demonstration on the steps required to perform manual network based threat hunting without CapLoader's alerts tab. In that video I identify TLS traffic to a non-TLS port (TCP 2222) as well as non-TLS traffic to TCP port 443. As of version 1.9.5 CapLoader automatically generates alerts for that type of traffic. More specifically, the alert types will be Protocol-port mismatch (TLS on TCP 2222) and Port-protocol mismatch (non-TLS on TCP 443).
Below is a screenshot of CapLoader’s new Alerts tab after having loaded the capture files analyzed in the Hunting for C2 Traffic video.
Image: Alerts for malicious traffic in CapLoader 1.9.5.
Video Demonstration of CapLoader's Alerts Tab
The best way to explain the power of CapLoader’s Alerts tab is probably by showing it in action. I have therefore recorded the following video demonstration.
This capture file is a small snippet of the network traffic analyzed in one of my old network forensics classes. It contains malicious traffic from njRAT and Kovter mixed with a great deal of legitimate web traffic.
Posted by Erik Hjelmvik on Thursday, 09 February 2023 14:30:00 (UTC/GMT)
In this video I look for C2 traffic by doing something I call Rinse-Repeat Threat Hunting,
which is a method for removing "normal" traffic in order to look closer at what isn't normal.
The video was recorded in a Windows Sandbox in order to avoid accidentally infecting my Windows PC with malware.
This video covers a life cycle of an Emotet infection, including initial infection, command-and-control traffic,
and spambot activity sending emails with malicious spreadsheet attachments to infect new victims.
The video was recorded in a Windows Sandbox in order to avoid accidentally infecting my Windows PC with malware.
Initial Infection
Palo Alto's Unit 42 sent out a
tweet with screenshots and IOCs from an Emotet infection in early March.
A follow-up tweet by Brad Duncan linked to a PCAP file containing
network traffic from the infection on Malware-Traffic-Analysis.net.
Image: Screenshot of original infection email from Unit 42
Attachment MD5: 825e8ea8a9936eb9459344b941df741a
Emotet Download
The PCAP from Malware-Traffic-Analysis.net shows that the Excel spreadsheet attachment caused the download of a DLL file
classified as Emotet.
The victim PC eventually started sending out spam emails.
The spam bot used TLS encryption when possible, either through SMTPS (implicit TLS) or with help of STARTTLS (explicit TLS).
Below is a spam email sent from the victim PC without TLS encryption.
The attached zip file contains a malicious Excel spreadsheet,
which is designed to infect new victims with Emotet.
Image: Spam email extracted from Emotet PCAP with NetworkMiner
My lightning talk from the SEC-T 0x0D conference has now been
published on YouTube.
This 13 minute talk covers tactics and techniques that the SolarWinds hackers used
in order to avoid being detected.
Some of these tactics included using DNS based command-and-control (C2) that mimicked Amazon AWS DNS traffic, blending in with SolarWind’s legitimate source code and handpicking only a small number of targets.
One thing I forgot to mention in my SEC-T talk though, was the speed at which the attackers were working to analyze incoming data from the trojanized installs and selecting organizations to
target for stage two operations.
For example, just during June 2020 the attackers got more than 1300 new organizations that started beaconing in using the DNS-based C2.
The beaconed data only included the organizations’ Active Directory domain name and a list of
installed security applications.
Based on this information the attackers had to decide whether or not they wanted to target the organization.
We have previously estimated that less than 1% of the organizations were targeted, while the malicious backdoor was disabled for all the other 99% who had installed the trojanized SolarWinds Orion update.
The attackers typically decided whether or not to target an organization within one week from when they started beaconing.
This means that the attackers probably had several hundred organizations in queue for a targeting decision on any given week between April and August 2020.
That's a significant workload!
Posted by Erik Hjelmvik on Monday, 18 October 2021 10:30:00 (UTC/GMT)