Malware of the Day – XenoRAT
What is Malware of the Day?
Lab Setup
Malware: XenoRAT
MITRE Tactics: TA0011 Command and Control , T1571 Non-Standard Port
Traffic Type: TCP
Connection Type: Reverse TCP
C2 Platform: XenoRAT
Origin of Sample: Active Countermeasures Lab
Host Payload Delivery Method: EXE binary (C2 implant)
Target Host/Victim: 192.168.2.77 (Windows 10 Pro x64)
C2 Server: 172.208.51.75
Beacon Timing: none
Jitter: none
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.
Preface: The Threat Hunting Mindset
As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.
The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.
Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.
By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.
Background
As discussed in our previous ‘Malware of the Day’ report, there has been a proliferation in the use of simpler open-source command and control (C2) frameworks, including remote-access trojans (RATs) in recent years. One RAT in particular has been prominent over the last few months—XenoRAT (Image 1, below).
Image 1. A tweet from a noted malware analyst highlights the increased sightings of XenoRAT in real-world applications. Its usage is anticipated to rise.
In today’s Malware of the Day investigation, we’ll explore a XenoRAT compromise, including a chain of infection similar to those reported by other parties recently. XenoRAT is another open-source C# RAT freely available on GitHub, and although its codebase is relatively simple compared to, for example, commercial C2 frameworks, it does feature a whole swathe of advanced features, including Hidden Virtual Network Computing (HVNC), multiple built-in UAC bypasses, and a SOCKS5 Reverse Proxy.
In this case study, we’ll learn how to identify a typical XenoRAT network connection using AC-Hunter, as well as use BeaKer to correlate the local process responsible for mediating said connection. We’ll also see how we can include the use of other freely available tools (PEStudio and TypeRefHasher) to support our base findings and potentially fingerprint the exact malware involved. We’ll also introduce the concept of robust versus brittle detections, and explore why one has to build a successful threat hunting program based on the former.
We hope that by showing how such a compromise might appear in AC-Hunter/BeaKer, along with support from other free detection tools, we can help keep your organization safe against it.
Setup
The local corporate network has a single subnet (192.168.2.0/24), containing 9 workstations (192.168.2.77, 79, 82, 84, 85, 87, 88, 89, 90) all running Windows 10 – (Image 2 below). A local, dedicated Zeek sensor (192.168.2.19) running Ubuntu 20.04 pushes hourly logs to a cloud-based AC-Hunter server (64.23.195.234), which also runs Ubuntu 20.04. This same cloud server also runs BeaKer (64.23.195.234:5601), allowing us deeper insight into the network traffic.
Image 2. Simplified diagram of today’s XenoRAT case study setup.
Scenario + Chain-of-Infection
In today’s scenario, a threat actor (172.208.51.75) successfully compromised one of the corporate workstations (192.168.2.77) via a chain of infection similar to those reported by other organizations within the last few months (Q1, 2024). The user of this station unfortunately downloaded an attachment from a sender impersonating a potential supplier. While the attachment masqueraded as an image file (discount_pricelist_jan_2024.png), it was actually a shortcut file (.lnk). Shortcut files serve as a convenient malware vector that is both adept at avoiding detection and functions as a de facto downloader by executing commands via the Windows Command shell.
Once the user ran the payload it downloaded and installed the RAT stub onto the local system and established a reverse TCP connection over port 4444 to a cloud VM running the xenoRAT server (172.208.51.75).
Network Traffic Analysis Using AC-Hunter
During routine monitoring with AC-Hunter, we systematically reviewed all the local hosts’ important modules from our dashboard (Image 3 below). Though our victim (192.168.2.77) did not feature near the top of the list (highlighted in green), it’s important to understand that the designated Threat Score serves to assist with triage, and it is still critical to manually review all systems if and when possible.
Image 3. Overview of the AC-Hunter dashboard.
Long Connections
Upon landing on the Long Connections module, we noticed four long connections (> 5 hours) that were either alive or had been alive within the past 24 hours (Image 4 below). Since the bottom connection (highlighted in orange) lasted only 5.5 hours in total and is currently closed, we decided to skip that for now, knowing of course that we can always come back later and dig deeper if need be.
We then performed a reputation check on the third longest connection (highlighted in green) by clicking on it and selecting from the various external reputation databases AC-Hunter provides. After reviewing several of these, we are provisionally satisfied that this is a genuine Microsoft server used for the collection of telemetry.
We immediately recognized the second longest connection (highlighted in red) to our own server (64.23.195.234), where the Elastic server is listening on port 9200. Since we determined this is legitimate traffic to a known resource we proceeded to add it to our safelist by clicking on the icon to the right of Total Duration (turquoise arrow), thereby ensuring it will no longer appear in future threat hunting sessions.
Image 4. All long connections totaling more than 5 hours that were either active, or closed, within the last 24 hours.
The longest connection (highlighted in purple), totaling over 45 hours at the moment of review, is a little more perplexing than the others. As we can see in the top right, the domain also belongs to Microsoft; however, running reputation checks on it in the same manner as above essentially leads to the digital equivalent of blank stares—Image 5 below.
Image 5. Doing a reputation check on the IP associated with the long connection in AbuseIPD.
All the sites report that this specific IP has never been seen or reported. This can seem like a good thing, and perhaps it is; but it’s also possible that it simply means this IP belongs to a new cloud instance—possibly a VM running on the Azure network since it belongs to Microsoft. As we’ve mentioned before, threat actors love using these because they have a good reputation and can essentially be treated like a disposable commodity.
We also noticed in our AC-Hunter long connections module that the connection is to an unusual port—4444. We searched for any potential applications or malware associated with this port on Google, and though there are some worrying indicators—for example, this report on the SANS Internet Storm Center—the overall results are inconsistent and do not provide an immediately satisfying answer.
We decided that for now, instead of digging into search results beyond the first page, to consult BeaKer and see what specific host process is mediating this connection.
BeaKer
After logging into our Elastic portal (64.23.195.234:5601), we select our Sysmon dataset, as it is the Sysmon logs from the corporate workstations that BeaKer uses as input data. We can now use KQL Syntax to specify the exact data we are looking for. Knowing the destination IP and port, we search using the following query: ‘destination.ip: “172.208.51.75” and destination.port: 4444’. This search immediately shows the connection in question—Image 6, below.
Image 6. Overview of our Elastic dashboard displaying our BeaKer results associated with the connection in question.
We can immediately see the specific process responsible for mediating this connection (highlighted in red), which raises some concerns. First, the name of the process (“resumebuilder.exe”) is not familiar, nor is it known to have any specific use case on these corporate workstations. It is thus unclear why a long connection of more than 40 hours to an external server over an unusual port is being made by this process.
Secondly, and perhaps even more concerning, is the exact location of this process: C:\Windows\Temp. It’s concerning because not only is this an exceedingly unusual installation directory for legitimate software, but it is also known to be a “go-to” installation directory for malware due to the typically lax write permissions associated with it.
By utilizing BeaKer and integrating the information it provides with data from AC-Hunter, we now have strong evidence suggesting a potential compromise. At this stage, our primary Threat Hunting tools have provided sufficient reason to notify the Incident Response team for further investigation. Following the strict guidance and instructions from the Incident Response team—since we are now under their jurisdiction—we will conduct some basic static analysis to gather more insights.
PEStudio
We’ll now perform some basic static analysis on the executable using an excellent tool called PEStudio. While PEStudio offers a paid version, it also provides a free version which is sufficient for our needs. The program can be downloaded from its official site.
Open the program with Administrator privileges and load resumebuilder.exe. The program will take a few moments (approximately 10-30 seconds) to load all the results, after which we can proceed.
SHA256 Hash and ImpHash
In the left-hand side column, we select the footprints module, which gives us an overview of some of the most important hash signatures associated with the file—Image 7, below. We first check the SHA-256 hash value by simply clicking on the value (highlighted in green), which will take us directly to the VirusTotal search results page. Unfortunately, no match is found.
Image 7. Overview of the PEStudio footprints module for resumebuilder.exe
It is, however, extremely common not to get a match on the SHA-256 hash since it is considered a brittle detection method—meaning a match is only made based on very specific criteria, and if even the smallest detail changes, the detection will fail. Of course, with most cryptographic hashes, a change in only a single byte will produce a different result, meaning it is very easily foiled by threat actors.
It is thus preferable to use, to the extent available, more robust detection methods. Unlike brittle detections, robust detections are more flexible, meaning there is a shift away from specific details and a greater emphasis on behaviors. Thus, even if some details change—for example, a few bytes—the detection may still be effective since it focuses on patterns, not specifics.
On this very note, we can, for example, use an ImpHash (highlighted in red), since it is derived not from the full sequence of specific bytes, but rather from the specific module imports. Thus, even if a malware author changes the names of functions and variables, the ImpHash will remain the same as long as the exact same modules are imported in the same order. However, clicking on it also produces no hits in VirusTotal. If we look at other databases, we get a variety of inconsistent results—for example, MalwareBazaar reports it as being the RedLineStealer malware.
TypeRefHash
To understand why this might be the case, let’s head to the indicators module in PEStudio (Image 8, below). As we can see here, PEStudio reports the file signature as Microsoft .NET. Without delving too deeply (interested readers can learn more here), because of the pronounced module homogeneity of .NET-based applications, we cannot use ImpHash reliably for this kind of malware.
Image 8. Overview of the PEStudio indicators module for resumebuilder.exe.
Instead, we can use a unique and innovative technique called TypeRefHash for .NET malware samples. I’ll leave the details for each individual reader to explore further, but in practical terms, we can simply download the TypeRefHasher binary from GitHub and run it against resumebuilder.exe to obtain it—Image 9, below.
Image 9. Running TypeRefHasher (by GDATA Software) against our suspicious binary.
Since TypeRefHash is still an emerging indicator, a search for this does not produce many results. However, the top result on Google indicates that this same TypeRefHash has been identified in reference to XenoRAT—see Image 10, below.
Image 10. Another analyst, Andrew Petrus, produced the same TypeRefHash for XenoRAT.
Strings
Back in PEStudio, we can all but confirm that the malware is indeed XenoRAT by navigating to the strings module—see Image 11, below. By sorting the value column alphabetically, we can see a number of strings in the malware mentioning the terms “xeno” and “rat” (highlighted in orange).
Image 11. Overview of the PEStudio strings module for resumebuilder.exe.
Conclusion
At this point, we can feel confident that we have discovered a compromise thanks to AC-Hunter and BeaKer:
- AC-Hunter indicated an unusually long connection to an unusual port (4444), associated with an IP possibly belonging to an Azure Cloud VM.
- BeaKer showed us the process responsible for mediating the connection as being both unknown, and located in an unusual directory.
By using other free software, we not only confirmed this but also discovered the most likely malware involved—XenoRAT. Along with helping to confirm what we learned with AC-Hunter and BeaKer with greater conviction, these additional details may be valuable to the Response team as they kick off their remediation efforts.
Before concluding this case study, we’d once again like to emphasize the importance of understanding the difference between robust and brittle detections. Though brittle detections such as signature hashes and analyzing PE file strings have their place, we cannot ultimately rely on them. This is because they depend on specific details and it only requires a crafty malware author to deviate from the expected patterns in order to render them ineffective.
It’s for this reason we always recommend building any solid detection or threat hunting program using robust detections, such as AC-Hunter and BeaKer. These tools do not rely on specific details—they detect TTPs, or specific patterns of behaviors. In line with frameworks such as David J. Bianco’s Pyramid of Pain, it is incredibly difficult for threat actors to alter these behaviors, and thus even if all the details change, you can rest assured that AC-Hunter will still be able to detect and alert us to the presence of a compromise.
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.
XenoRAT 1 Hour Capture
xenorat_1hr.pcap
Size: 12.68 MB
SHA256 Checksum: A945662C2AA594FB9860319C05752CFB47662D08793AD8AF53CC70A44332EAB2
XenoRAT 24 Hour Capture
xenorat_24hr.pcap
Size: 564.22 MB
SHA256 Checksum: EFA57A100EE8D9EC91204D79CB34E634B715C69A85DE465BA007194E0956569B
Zeek Logs
If you are an AC-Hunter or RITA user, we are providing 48-hours of Zeek logs for you to import directly into AC-Hunter or RITA. The following Zeek Logs have been taken from the same lab environment over a 48-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.
The following is an example of how to import Zeek logs into AC-Hunter or RITA:
ssh into your AC-Hunter or RITA server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log.gz’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/xenorat-zeek-logs/
Then run the following command:
rita import /tmp/xenorat-zeek-logs/*log.gz xenorat
You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “xenorat” you can select and view.
48 Hour Zeek Logs
xenorat_zeek_logs.zip
Size: 3.71 MB
SHA256 Checksum: 37416F90FCC1ABB4030786D864C01EDFE063EAB4C69A5405183A052785361D7E
NOTE: You may notice some variances in scoring and time when importing these files into your AC-Hunter or RITA instance compared to our screenshots. This can be caused by inconsistencies in capture export timing and by manually importing greater than 24-hours of Zeek logs into AC-Hunter or RITA, but it is not an indication of an issue.
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
XenoRAT: A New Remote Access Trojan with Advanced Capabilities
XenoRAT: Basic Malware Analysis
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!
Faan has a profound love for the natural world, technology, design, and retro aesthetics. He is incredibly grateful to have discovered cybersecurity as a path relatively late in his life, and his main interests are threat hunting and post-exploitation custom tooling, in particular C2 frameworks and RATs.