Malware of the Day – Specula
What is Malware of the Day?
Lab Setup
“Malware”: Specula
MITRE Tactics: TA0011 Command and Control, T1137.004 Office Application Startup: Outlook Home Page, T1559.001 Inter-Process Communication: Component Object Model (COM), T1059.005 – Command and Scripting Interpreter: Visual Basic, T1071.001 – Application Layer Protocol: Web Protocols, T1112 – Modify Registry, T1203 – Exploitation for Client Execution
Traffic Type: HTTPS
Connection Type: Reverse TCP
C2 Platform: Specula
Origin of Sample: Active Countermeasures Cloud Lab
Host Payload Delivery Method: Registry Key (*.reg)
Target Host/Victim: 172.208.51.75 (Windows 10 Pro x64)
C2 Server: 24.199.110.233 (weathersync.cloud)
Beacon Delay: 30 seconds
Beacon Jitter: 50%
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 Treat 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
In the ongoing security co-evolutionary arms race, attackers continually develop innovative ways to blend into their environment. As defenders improve at detecting specific tools or techniques, attackers develop new methods to achieve the same goals through different means. These evolutionary adaptations may occur on the network—for example, when new communication methods like “C2 over DNS” are developed—but more frequently occur within the endpoint itself.
Specula, a new command and control (C2) framework recently released by TrustedSec, evades many modern endpoint detections by operating solely within the context of Microsoft Outlook. By creating a specific registry key, it alters Outlook’s execution, essentially transforming it into a C2 framework. Specula thus co-opts a trusted application present on most modern Windows endpoints, repurposing it to function as the C2’s implant which connects back to a Python-based server.
What makes this technique unusual is that the vulnerability in Outlook exploited by Specula was publicly disclosed by Microsoft back in October 2017 as CVE-2017-11774. However, it appears that Microsoft only partially patched the vulnerability, likely for pragmatic reasons. As a result, a simple workaround still allows non-privileged users to set a URL target (i.e., the C2 server) in Outlook’s WebView registry entry – as illustrated in Image 1 below.
Image 1. By setting a key containing the C2 domain (weathersync.cloud), as well as encryption key (0-9brEabGmpegw), Outlook.exe effectively acts as the C2 implant.
Oddvar Moe, one of Specula’s principal creators, states: “TrustedSec has successfully leveraged this specific channel for initial access in hundreds of client environments, despite existing knowledge and preventions available for this technique.” The significance of this vulnerability is further underscored by the U.S. Cyber Command (USCyberCom), which issued a warning in 2019 that this specific flaw had been exploited to target various U.S. government agencies. Subsequently, several private intelligence agencies linked these attacks to APT34, and later to APT33 – both state-sponsored espionage groups based in Iran.
In today’s Malware of the Day, we’ll investigate a Specula C2 compromise. We’ll start by examining network traffic using AC-Hunter, RITA, and WireShark. Then, we’ll analyze the suspicious connection on the endpoint using System Informer and Sysmon.
Using this approach, we’ll learn to recognize Specula C2, and more broadly, applications exploiting CVE-2017-11774 on your network. We hope that by doing so we can help keep your organization safe against it.
Setup
Today’s target network is a single cloud-based host (private: 10.0.0.4, public: 172.208.51.75) running Windows 10.
Scenario + Chain-of-Infection
In today’s scenario, a threat actor (24.199.110.233) purchased unauthorized access from an Initial Access Broker (IAB) via XSS, a Russian ransomware forum. The original access was gained by brute-forcing a poorly secured, publicly-exposed RDP service.
Following the purchase, the threat actor used RDP to install a Specula hooking agent, then stopped using RDP. Since outlook.exe is trusted and less conspicuous than RDP, it allows for more covert subsequent operations.
Network Threat Hunting Using AC-Hunter
During routine monitoring using the AC-Hunter dashboard, we systematically review all top threats. Let’s first focus on a high-scoring signal (86.50) identified in the Beacon module – see Image 2 below.
Image 2. An overview of the AC-Hunter dashboard with the top beacon signal highlighted in green.
Examining this Beacon module entry, we note several interesting observations – see Image 3 below.
Image 3. The Beacon module entry for our connection of interest.
The hourly-connection graph (green box) appears “wavier” than typical C2 communication. However, it still shows some consistency, with a limited deviation range (indicated by the red minimum and maximum lines).
The histogram in the orange box displays positive skew, or a “long tail”. As we learned in Part 2 of our Understanding C2 Beacons article, this shape typically suggests the use of multiple redirectors and use of the randomized host rotation strategy.
However, since we cannot locate any corresponding histograms that match the typical patterns of a randomized host rotation strategy in this set, it is unlikely multiple redirectors are in use. The pattern seen here is still unusual in the sense that we do not expect it to be produced by chance, and so it could be that the malware employs unusual randomization in its implementation of beacon jitter.
In the blue box, we note key IP details. The FQDN weathersync.cloud, is situated within Digital Ocean’s network. While Digital Ocean is legitimate, its reputation and disposable nature make it a popular choice among threat actors using public cloud services.
Let’s now switch over to our other primary threat hunting tool, RITA, to see if it may offer any additional insights.
Network Threat Hunting Using RITA
After locating the same connection to weathersync.cloud in RITA, we can make a few notable observations – see Image 4 below.
Image 4. The connection to weathersync.cloud as it appears in RITA.
We see two applied modifiers: High Prevalence and First Seen (< 7days). However, both result from our experimental setup, not potential threats. With only one system on our subnet, all connections appear on “100% of hosts”. And since our dataset is 24-hours in length, it means all connections are “first seen” within that period.
What’s unusual about this result however is the number of connections (639) in relation to the total connection duration of 23h55m20s. Typically, we’d expect a connection of this length to consist of only a few connections, perhaps even just one.
Conversely, for most C2 frameworks with hundreds of connections in a 24-hour period, we don’t anticipate the total duration of the connected state to be so close to the maximum value (23h55m/24h = 99.65%).
To see why this might be the case, let’s perform some deep packet inspection using Wireshark.
Deep Packet Inspection Using WireShark
After opening the pcap in Wireshark, we immediately apply the filter ‘ip.addr == 24.199.110.233’ to focus on communication with our system of interest. As we scroll through the packets for a high-level overview, an intriguing pattern emerges – see Image 5 below.
Image 5. An overview in WireShark of all communication between ourselves (10.0.0.4) and the system of interest (24.199.110.233).
Here we can see two clusters of packets (labeled A and B) displaying a similar pattern. Note that packets with the SYN flag set are colored red, while those with the FIN flag set are gray. Looking closely at the Info column, we observe that the SYN packet initiating a new connection is sandwiched between the two FIN, ACK packets ending the previous one. In other words, a new connection is created the moment the previous one closes.
Scrolling through the entire capture, we see this pattern repeat consistently. The blue box (Image 5, above) provides an overview of packet colors, where we can clearly observe periodic red stripes. Each stripe represents the nexus where one connection ends and the next immediately begins.
This finding illuminates our earlier RITA observation. Despite the connection stopping and starting multiple times (639), the absence of idle periods between connections resulted in the high total connection duration. Each connection seamlessly transitions into the next, maintaining near-constant connectivity.
But What Does This Mean?
To grasp why this result is unusual, let’s first examine the “connection interval” – the time span displayed on AC-Hunter’s histogram – as shown in Image 6 below.
Image 6. AC-Hunter’s primary histogram plots the frequency of “connection intervals” – in this example we see 58 connections lasting 56 seconds each within our 24-hour dataset.
It’s important to understand what “connection interval” denotes: it’s the time from the start of one connection to the start of the next – as illustrated in Image 7 below.
Image 7. An overview of how “connection interval” is determined.
In most C2 frameworks (shown in orange), a connection typically ends well before the next one starts. This results in a significant “pause” – the connection interval includes both an active connection period and a period of no connection.
However, for the suspected C2 framework we’re examining (shown in blue), this isn’t the case. The connection is maintained up until a new one is created, resulting in minimal time spent in a “connectionless” state.
This explains the unusual result from RITA – despite the high number of individual connections (639), the total connection duration was nearly 24 hours. This is because each new connection was established immediately as the previous one closed, leaving virtually no gaps in connectivity.
This unusual property could serve as a diagnostic characteristic when analyzing data in RITA. Its unique connection profile – high connection count coupled with near-continuous connectivity – may help identify this specific C2 framework, significantly aiding future response efforts.
“Network for Breadth, Endpoint for Depth”
Our investigation has uncovered several suspicious and unusual properties of the connection in question. The evidence gathered from our primary threat hunting tools likely warrants alerting the Incident Response team for further investigation. Following their strict guidance and instructions – as we’re now under their jurisdiction – we can delve deeper into the endpoint to identify the specific C2 framework in use with greater certainty.
Connection-Process Correlation with System Informer
Knowing our target IP (24.199.110.233), we can use System Informer (formerly Process Hacker) to identify the process mediating this connection. After opening System Informer with administrative privileges we click the Network tab at the top (see Image 8 below). This displays a list of processes, including the external host IP each is connecting to.
Image 8. The Network tab in System Informer helps to correlate processes with their outbound IPs.
We then click the “Remote address” tab to sort IPs in descending order, helping us locate our IP of interest – see the red box in Image 9 below.
Image 9. System Informer provides in-depth information on processes, including for example any outbound IPs it might be connected to.
We’ve identified ‘OUTLOOK.EXE’ as the process mediating the connection to 24.199.110.233. While we’d expect Microsoft Outlook to make outbound connections, this doesn’t explain the unusual beaconing pattern observed in AC-Hunter. Moreover, we’re aware that techniques such as process injection can allow malware to execute within legitimate processes.
The most troubling anomaly however is that Outlook, a Microsoft product, is connecting to a non-Microsoft server. We recall AC-Hunter identified this IP as belonging to Digital Ocean. While we trust AC-Hunter’s accuracy, an additional data point never hurts. A Censys lookup confirms the IP indeed belongs to Digital Ocean – see Image 10 below.
Image 10. Censys entry for 24.199.110.233.
While Digital Ocean is a legitimate cloud service provider, it has no official affiliation with Microsoft. This discrepancy strongly suggests that the connection is almost certainly part of a compromise.
OSINT – “Using Outlook.exe as C2”
A Google search for “using outlook.exe as a C2 channel” immediately yields multiple leads (see Image 11 below), including azureOutlookC2, BadOutlook, and Specula. This suggests that exploiting Outlook as a C2 channel is a known technique with various implementations.
Image 11. Google results related to using Outlook as a C2 channel.
The first link leads to Specula’s description on the website of its developer, TrustedSec. This page links to Specula’s official wiki, which mentions that the hooking agent creates a new registry key – see Image 12 below.
Image 12. The registry key created by Specula, from the application’s wiki.
Knowing that registry modifications are captured by Sysmon as EventID 13, and that Sysmon is automatically installed on our endpoints with BeaKer, we can check our logs to confirm whether this is indeed a Specula compromise.
Process Identification with Sysmon
Using the timestamp of the first outbound connections (from Wireshark), we can search for Sysmon EventID 13 occurrences during this period. This search immediately yields a relevant log entry – see Image 13 below.
Image 13. Sysmon EventID 13 identifying the registry event of interest.
The “Details” section (green box) shows the registry key value was altered to the ‘/plugin/search‘ extension, as described in Specula’s wiki. Notably, just 2 minutes later, the value is altered again – see Image 14 below.
Image 14. A subsequent Sysmon EventID 13 indicates the registry value was modified.
As seen in the orange box, and further described in the Specula training material, once the hooking agent is accepted, the URL changes from ‘/plugin/search’ to ‘/css/’ + the encryption key.
At this point, we can be completely confident that we are indeed dealing with a compromise involving the Specula C2 framework. We’ve completed our role as Threat Hunters, and can now allow the Response team to perform their duties.
Conclusion
The co-evolutionary arms race in cybersecurity drives constant innovation on both sides. Attackers develop new tools and techniques, then defenders learn to detect and defend against them, then attackers develop new tools and techniques – ad infinitum. This perpetual dance will continue as long as information technology exists.
Notably, in this case and many others, much of the focus is on detection, and consequently on the development of new evasion tactics from the attacker’s perspective occurs within the realm of the endpoint rather than the network.
While Specula C2 is certainly unique in its endpoint operations and perhaps even in its specific network profile, its fundamental network communication patterns still align with those of other C2 frameworks. This consistency in network behavior is why malware detection at the network level is often referred to as the “great equalizer.”
No matter how a specific malware process operates, on the wire, they all look similar. They must use specific protocols to communicate, choose specific communication strategies, and they all have to send packets. This means that on the network, there’s nowhere to hide – all applications are naked in front of the Network Gods.
This insight underscores the effectiveness of tools like RITA and AC-Hunter against both known and unknown forms of post-compromise communication malware. They look beyond the details to identify patterns, and as described, these patterns rarely (if ever) change significantly. For this reason, RITA and AC-Hunter are invaluable assets in your threat hunting toolbox.
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.
Specula 1 hour capture
specula_1h.pcap
File Size: 76.4 MB
SHA-256 Hash: 8F30ACC5970455A97C395DA6B72A635101C3E1712B1ED202A18BD1FAD9184F05
Specula 24 hour capture
specula_24h.pcap
File Size: 1.5 GB
SHA-256 Hash: DB4629786AD6620115B8273D75AE976BA66730BB7AB35A07CECA76A44EA54D84
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.
Importing 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/specula-zeek-logs/
Then run the following command:
For AC-Hunter v6.x and RITA v4.x and earlier:
rita import /tmp/specula-zeek-logs/*.log specula
For RITA v5.x+:
rita import --logs=/tmp/specula-zeek-logs/*.log --database=specula
You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “specula” you can select and view.
Specula 24 Hour Zeek Logs
specula_zeek_logs.zip
Size: 8.7 MB
SHA256 Checksum: 8DDD0C105CF174F3ED11A0B61583BB0DC7D49D21E5847A3684E6B60D8E40CE0A
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.
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.