Malware of the Day – Tunneled C2 Beaconing

What is Malware of the Day?

 

Lab Setup

“Malware”: Ligolo-ng (tunneling) & Sliver (C2)

MITRE Tactics: TA0011 Command and Control , T1572 Protocol Tunneling

Traffic Type: HTTPS/TLS

Connection Type: Reverse TCP

C2 Platform: Sliver

Tunneling Platform: Ligolo-ng

Origin of Sample: Active Countermeasures Lab

Host Payload Delivery Method: ELF file (ligolo-ng agent), EXE binary (C2 implant)

Target Host/Victim: 192.168.100.129 (Linux Ubuntu 22.04), 192.168.200.130 (Windows 10 Enterprise x64)

C2 Server: 143.198.3.13

Beacon Timing: 5s

Jitter: 60%

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for command and control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Background

How do threat actors move across different network segments within a larger architecture? Lateral movement allows them to move from one host to another within the same segment (VLAN/subnet), however, threat actors also frequently seek to traverse from a host in one segment to another in a different segment. This action, known as pivoting, is crucial for expanding access within a network. In today’s Malware of the Day post, we explore tunneling as a method to accomplish this. But first, let’s delve into some theory to better grasp the underlying mechanisms and motivations.

 

DMZ to Internal Network Pivoting

One common scenario where pivoting is essential for threat actors involves corporate networks segmented into a demilitarized zone (DMZ) and internal networks (refer to Image 1 below for a simplified representation). Machines in the DMZ, such as web servers, mail servers, FTP servers, etc., are public-facing, that is they allow systems on the internet to establish inbound connections. Conversely, for security reasons, systems on the internal network typically cannot be accessed from the internet. This ability to allow/disallow network connections based on the host’s segment is mediated by a firewall.

Now, because DMZ hosts are publicly accessible, they are often easier to compromise. However, for most threat actors, they rarely (if ever) contain anything of value. But what they do represent is an opportunity – since DMZ hosts can typically communicate directly with systems on the internal network, compromising the former may allow a threat actor to access the latter. Thus, compromising a DMZ host can be seen as a stepping stone to pivot to the internal network where further compromise of internal systems can occur until the threat actor achieves their ultimate goal.

 

Scenario

 

In today’s scenario, a threat actor (143.198.3.13) was able to compromise a web server (192.168.100.129) located within the DMZ of a corporate environment (Image 1 above). Once on the web server they installed a Ligolo-ng agent, which performed a reverse tcp callback (TLS) to a ligolo-ng proxy server listening on their remote system. Once the connection was established the threat actor was able to determine the presence of the 192.168.200.0/24 internal network, which allowed them to establish a tunnel to this subnet. A network scan was performed to enumerate specific IPs on this subnet, while also revealing a vulnerability that ultimately allowed the threat actor access to the internal host 192.168.200.130 (Image 2 below).

 

 

In order to perform further post-exploitation activities, the threat actor then installed a Sliver C2 implant, which called back to the Sliver remote server using port 8888 (mTLS). However, since this communication could not be performed directly, it was done within the context of the tunnel with port-forwarding mediated in both directions by the Ligolo-ng agent on the internal web server (Image 3 below).

 

 

Network Traffic Analysis Using AC-Hunter

Routine Analysis

During our regular network security checks, we collected a day’s worth of network traffic (.pcapng format) from a tap inside the firewall of the DMZ-segment. We converted this .pcapng file to Zeek logs and then imported it into a RITA/AC-Hunter database. At this point it is now ready for analysis in the AC-Hunter interface.

 

Dashboard

Upon opening AC-Hunter we immediately view our dashboard (Image 4 below), which in this case only shows a single host IP belonging to our internal web server. This is of course because the traffic was captured on the internal-side of the DMZ segment, and thus we would not expect the other internal network hosts to appear on this interface. This remains true for our ultimate victim, though technically the C2 traffic that originated from our ultimate target victim (192.168.200.130) did leave the network at this point, it did so via the Ligolo-ng agent on the internal web server (192.168.100.129) and thus externally it appears to have originated from the internal web server.

 

 

On the right-hand side of the dashboard we notice a number of high scores for our Beacon and Beacon Web modules. Digging into these connections further reveals the presence of typical update services (Google, Mozilla, and Canonical etc.). One might be surprised that these were picked up and assigned such high scores, but the reason is simple – this is the first time this network has been analyzed and thus the “regular business” IPs have not yet been safelisted. This reinforces the importance of diligent baselining during the initial phase after adopting AC-Hunter, whereafter no more (or, very little) such false positives should appear.

Something else that does stand out however is an outbound connection totaling a little over 24 hours. Though this is a web server, and thus one would expect a large volume of traffic, what one would not expect per se is a single connection lasting for more than a day. Unless an immediate business use case comes to mind, further investigation is warranted, so let’s move onto the long connections module.

 

Long Connections

 

In the Long Connections module (Image 5 above) we once again see at the top the long connection of 24:01:51 to the external IP 143.198.3.13. On the top right we can see that the IP resolves to a resource within the Digital Ocean organization, and we can confirm this by clicking on the IP and selecting among any number of external reputation databases such as Virus Total, AbuseIPDB, Shodan etc. One might be lulled into a false sense of relief that the IP belongs to a reputable company. However Digital Ocean is one of the largest providers of public cloud services, which threat actors love using since they have a strong reputation and can essentially be treated like a disposable commodity.

Further, we see about 68.86 MB of data that was transferred over an unusual port of 11601 using TCP/SSL. Googling this port does not provide an abundance of clear results, but digging a bit lower into the first page of results we discover that the port belongs to Ligolo-ng, which its Github page explains is a tool used by pentesters. Uh-oh. Even more concerning however is another article on the first page of Google results – see Image 6, below.

 

 

Now even though this article does not explicitly mention Ligolo-ng by name, it does state that the Darktrace SOC and Threat team have seen a number of incidents starting around January 2024 where long SSL connections were made outbound over port 11601 with several megabytes exchanged.

At this point it would be wise to immediately find out if a pentesting engagement is being, or has recently been performed on this network. It is also important to mention we cannot say with 100% certainty that port 11601 usage means it was Ligolo-ng, that Ligolo-ng was being used for nefarious purposes, nor that it has any relation to the attacks that were reported by Darktrace. Besides, it never pays to panic. But at this point, in all honesty, this case should (at the very least) be escalated internally to the incident response team for review.

For further investigation, we suggest that one analyze the East-West traffic on the interface between the DMZ and the internal network. If a C2-via-tunnel compromise has taken place one would expect an unusually high volume of internal traffic occurring between the DMZ host and 1 (or perhaps a few) internal network hosts.

 

Conclusion

Today’s Malware of the Day is interesting for several reasons. Most importantly, it reminds us not to become complacent and succumb to tunnel vision by focusing only upon a singular or small subset of methods of compromise. In the realm of defensive cybersecurity it pays to never accept anything as self-evident – deception is the rule, not the exception.

Imagine for example we placed all our energy and attention on analyzing traffic exiting the internal network, since this is after all where the systems and data we are most concerned with reside. Well, in a case such as presented here, where traffic is tunneled from the internal network through the DMZ and then exits the network from that segment, we would completely miss this compromise. Threat actors love using tunnels, whether that be Ligolo-ng, Chisel, or ProxyChains; so it is important to remain vigilant on all egress points, and not just those you view as being more sensitive.

Additionally, it’s worth pointing out that even though our C2 implant was beaconing (5 seconds with jitter of 60%), AC-Hunter reported no beaconing associated with this connection – see Image 7, below.

 

 

And this is not due to some error on AC-Hunter’s part. Rather, as mentioned before, all the C2 traffic was happening in the context of the tunnel. So not only did our C2 victim IP and port (8888 for mTLS) not appear, but the actual beaconing behavior itself was cloaked by the tunnel.

This is important to note because beaconing (cyclical connections with jitter) was originally used to hoodwink defenders who at that time (the good old Metasploit days) were solely focused on long connections. But today beaconing technology is itself mature and well-known. Thus, herein lies a danger that we hope today’s case may serve as an antidote against: don’t become so overly obsessed with looking for beacons, that one forgets to look for the long connections right under one’s nose.

Below are capture files of this network traffic. Would you be able to easily identify this C2 channel within your network?

 

Video Summary

 

 

 

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

Tunneled C2 Beaconing 1 Hour Capture
tunneled_c2_beaconing_1hr.pcapng
Size: 5.99 MB
SHA256 Checksum: D78422277A974FC5C5BC1BF056DE9DB867EDCFE387F5825FE159DD5FB5A4A75A

Tunneled C2 Beaconing 24 Hour Capture
tunneled_c2_beaconing_24hr.pcapng
Size: 109.14 MB
SHA256 Checksum: 991A6C0672EAC7BD3527F79C90D025C3D12A8FC12993E5B6B6BD8CA1490F2C2A

 

Zeek Logs

If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

How to import Zeek logs into AC-Hunter example:

ssh into your AC-Hunter server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/tunneled-c2-beaconing-zeek-logs/

Then run the following command:

rita import /tmp/tunneled-c2-beaconing-zeek-logs/*.log tunneledc2beaconing

You will now have a new database in the AC-Hunter UI/web interface titled “tunneledc2beaconing” you can select and view.

24 Hour Zeek Logs
tunneled-c2-beaconing_zeek_logs.zip
Size: 231.08 KB
SHA256 Checksum: C65B286DB4EBAFA78A95FBD3A570B6B249F4F55EBBEAD77543D050B3A82E7FDC

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

Additional Resources

https://attack.mitre.org/

How Hackers Move Through Networks (with Ligolo) by John Hammond

The Sliver C2 Framework – Moloch

 

A huge thanks to Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!