[This is a Guest Diary by David Fitzmaurice, an ISC intern as part of the SANS.edu Bachelor’s Degree in Applied Cybersecurity (BACS) program [1].
Over the last six months there have been frequent SSH connections leaving versions of the RedTail malware on my DShield Honeypot [2]. This variation of the malware is placed on a victim device through a secure shell (SSH) connection. Upon a successful install of the malware the server will send a domain name system (DNS) request for the command and control IPs and begin communicating with its botnet.
This kind of attack is easy to prevent on a small network with only a handful of devices where SSH servers aren’t accessible to the internet. In a large network serviced by administrators with varying skill levels devices are often left with default or weak credentials. How can we minimize the time to detect a breach from a crypto miner?
Figure 1: Diagram showing the collecting network architecture and the visible portion of the attacking network.
This malware uses SSH password guessing for the initial exploit and install of the RedTail malware as shown in figure 2. This attack uses username and password combos that can be found as defaults or passwords commonly used when users are forced to change their passwords frequently such as username root and password abc123!@#. This is a great reminder not to arbitrarily require password changes. Once the attacking server successfully authenticates it will upload the following files.
- setup.sh
- redtail.x86_64
- redtail.i686
- redtail.arm8
- redtail.arm7
- clean.sh
Figure 2: Initial SSH Connection to DShield Honeypot
The RedTail files above each contain strings associated with the XMRig [3] crypto mining software. The clean.sh script is used to prep the system for install and the setup.sh script is used to select and install the executable file appropriate for the victim system which will be one of the RedTail files above. Once the RedTail malware is run it will start two apache [4] processes for network communications, send a DNS request to various DNS servers for moneroed[.]net, create a connection to the original attacking IP on %%port:43782%%, and create a connection to one of the servers identified in the DNS request to moneroed[.]net IPv4 records on %%port:2137%%. The DNS requests can be seen in Figure 3, and the command and control connections can be seen in Figure 4.
Figure 3: DNS Request/Response
Figure 4: Command and Control Channels
Using the default configuration for Snort [5] did not generate any alerts from this attack. The default configuration for Zeek created SSH logs, DNS logs, and connection logs. In a busy network this could easily go undetected. Following the TCP stream for that %%port:2137%% connection in Wireshark shows JSON entries in ASCII that look exactly like the Stratum mining protocol [6] used by the XMRig software. This is shown in Figure 5.
Figure 5: Port 2137 connection showing Stratum mining protocol communications
In order to detect the Stratum mining protocol I found a Zeek package called zeek-cryptomining [6] that included Zeek scripts and signatures to detect the most common crypto mining communications such as communications from XMRig. Once the package was loaded onto my network sensor I started getting logs showing the malware communications. The network tap and network sensor can be seen in figures 1-4 and the logs created from the Stratum mining protocol can be seen in figure 6.
Figure 6: An example of searching Grafana for Zeek_Notice logs generated from an infected system.
The %%port:43782%% connection proved to be a bit more complicated. During the initial connection the attacking server transferred around 70,000 bytes of data to the victim device. Once that concluded the victim system would send data starting with the hex bytes 0x0c180000003c in each transmission. This is shown below in figure 7.
Figure 7: Hex dump of port 43782 TCP stream in Wireshark.
In order to track the connections seen on %%port:43782%% a Snort rule can be written. In this case I used the hex bytes 0x0c180000003c which I observed in most client to server packets. To speed up the rule writing process I used ChatGPT [8] to generate a basic draft.
ChatGPT Prompt
“Create a Snort signature to alert when the first six bytes of a TCP payload are as follows 0x0c180000003c. This signature should alert when the communications are from the home network to the internet.“
ChatGPT Rule
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"TCP payload matches 0x0c180000003c"; content:"|0C 18 00 00 00 3C|"; offset:0; depth:6; flow:to_server,established; sid:1000001; rev:1;)
I searched the Snort documentation [8] to verify the fields and add additional information. As a rule AI in its current state should be used as an augment, but any outputs should be verified. The Snort rule I used is added below. I decided to use the classtype field to output “Known malware command and control traffic” and set “Priority: 1” in the alert logs. The logs from testing the rule on my network tap and Grafana[9] server can be seen in figure 8.
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"TCP payload starts with 0x0c180000003c. Possible Crypto mining."; content:"|0c 18 00 00 00 3c|"; offset:0; depth:6; sid:1900001; rev:1; classtype:malware-cnc;)
Figure 8: Snort alerts seen in Grafana for %%port:43782%% traffic
These rules are specific enough to avoid false positives and broad enough to consistently detect when the RetTail malware is active. These rules have been running on my network tap from September 12, 2024 through November 15, 2024 and have not created any false positives. In that time the RedTail network has used three different initial attack IPs, and the sha256 hash of the X86_64 variant of RedTail has changed five times. If we were to only rely on threat intelligence to identify malicious file hashes or IPs we would miss those changes.
Using a network tap or mirroring a port into an intrusion detection system (IDS) like Snort or Zeek and sending the traffic to a log analysis tool like Grafana creates a great environment for threat hunting activities. With some effort to characterize and create signatures or scripts for malicious network traffic threats can be detected almost immediately when the network is monitored. Analysts could take this a step further and characterize normal communications on the network so when something unusual occurs it will be noticed by security analysts much quicker.
[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://isc.sans.edu/honeypot.html
[3] https://xmrig.com/
[4] https://httpd.apache.org/
[5] https://www.snort.org/
[6] https://github.com/xmrig/xmrig-proxy/blob/master/doc/STRATUM.md
[7] https://packages.zeek.org/packages/view/cccea150-9348-11eb-81e7-0a598146b5c6
[8] https://chatgpt.com/
[9] https://docs.snort.org/rules/options/general/
[10] https://grafana.com/
—
Jesse La Grew
Handler
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.