August 14, 2025 5 Minute Read

As security researchers, we actively monitor the latest CVEs and their publicly available exploits to create signatures. Beyond CVEs, we also hunt for malware on platforms such as MalwareBazaar, which enhances our visibility into attacks occurring across networks.

Today, we'll demonstrate a simple workflow showing how researchers use various tools to collect indicators of compromise (IOCs) and develop appropriate signatures from detonated malware.

We'll begin by examining MalwareBazaar for newly uploaded or interesting malware samples in their database, like the one shown below.

Figure 1. MalwareBazaar Database entry for SnakeKeylogger.

Let’s explore this SnakeKeylogger to understand what information it exfiltrates. Does it capture the victim's keystrokes in real time? Does it steal cookies or login credentials? Or does it simply dump everything and extract important data later?

A little background about Snake Keylogger: it is a malware written in .NET that primarily focuses on stealing information. First observed in 2020, Snake Keylogger was sold on dark web and underground forums as Malware-as-a-Service. Its capabilities include recording keystrokes, stealing browser cookies, capturing geolocation and system information, and more — often exfiltrated via FTP, SMTP, or HTTP. Based on our observation, Snake Keylogger shares the same functionalities as VIPKeylogger. We believe that VIP Keylogger is possibly a rebranded version of Snake Keylogger that's sold in underground markets.

First, let's examine additional details about SnakeKeylogger and check for existing signatures in ET. By analyzing the hash value on VirusTotal, we can get a brief overview of discovered IOCs and existing rules.

Figure 2. SnakeKeylogger on VirusTotal.

We can see many potential IOCs and existing ET rules. However, the signatures only relate to external IP checks connected to various keyloggers and don't specifically detect data exfiltration, which is crucial for tracing an attack.

Therefore, let's download the sample and record all possible IOCs. For this malware analysis, we'll use the following tools:

• FlareVM
• Procmon
• Procexp
• Tcpview
• Zui/Brim
• Procdot
• Wireshark
• Suricata

Now, letʼs dig into it.

Figure 3. Process and TCP Connections made by SnakeKeyLogger.

After detonating it, we can see the file has already established external connections, though we don't know their purpose yet. These IPs aren't listed among the IOCs from VirusTotal, so let's investigate whether they're potentially malicious.

Figure 4. 158.101.44[.]242 - Connected to SnakeKeylogger.

Figure 5. 104.21.48[.]1 - C2.

Now that we've confirmed that these IPs are malicious, we'll record the processes using ProcMon. This approach allows us to save the data and analyze it more thoroughly when we transfer it to ProcDot.

Figure 6. Recording processes via ProcMon.

Let's load the .csv file we exported from ProcMon into ProcDot to visualize the process and isolate network IOCs for later use. ProcDot is an excellent tool for security researchers as it shows the flow of actions when malware is triggered. Here's a brief overview of the ProcDot graph:

Figure 7. Visualizing SnakeKeylogger using ProcDot.

We could further dissect this at the host level, but for the purpose of this blog post, we’ll focus on the network IOCs.

Figure 8. SnakeKeylogger’s network IOCs.

The analysis reveals four external connections using ports 80, 443, and 587. I'm particularly interested in the activity on port 587.

We captured the PCAP before detonating the malware, which allows us to verify the existing rule against the network packets. Before doing anything, letʼs load the PCAP to Zui so we can see the alerts.

Figure 9. Loading the PCAP to Zui.

Examining the alerts we received, we only see reconnaissance alerts with no indication of information exfiltration. Below is the ET rule that triggered these alerts.

Figure 10. ET rule.

Below is the actual network request and response that triggered the alert.

Figure 11. Network request and response.

Now that we've confirmed this is connected to SnakeKeylogger, we also need to check if there are any existing SnakeKeylogger rules and test them against the ET ruleset.

The presence of this signature ID indicates this has been observed before — but like any other malware, it may have been tweaked to evade existing signatures.

sid:2060048 "ET MALWARE Snake Keylogger Exfil via SMTP (VIP Recovery)"

With this in mind, we will still try to run it on Suricata to confirm if those two rules cover the attack. Figure 14 confirms that the existing rule doesnʼt cover this attack. “We can now proceed to check what is happening on the network during the exfil.ˮ

Figure 12. Using Suricata to confirm if rules cover the attack.

But why is it happening, and why is it not triggering a  Suricata alert for the IDS? Letʼs grab the rule and cross-check it with whatʼs in the wire.

Below is the existing rule:

Figure 13. Existing rule.

Now, let's check the TCP stream:

Figure 14. TCP stream.

The stream above immediately reveals why the signature didnʼt trigger a Suricata alert for IDS — the malware exfiltrates data using Base64 encoding. Although itʼs a simple technique, it can easily bypass signatures as shown earlier. Letʼs use CyberChef to decode the Base64 and reveal the exfiltrated data.

Figure 15. Base64 decoding using CyberChef.

So now, letʼs try creating a rule that will actually match this malware.

Weʼll need content that identifies SnakeKeylogger — specifically, the subject header — and use the
Content-Transfer-Encoding: value of base64 as an anchor so we can decode the Base 64 data properly.

Looking at Wireshark, we can see that each line is terminated with a CRLF, but letʼs see if the first line is enough to correlate the header to the body.

Figure 16. Each line is terminated with a CRLF.

Figure 17. Checking the first line.

The first line starts with "Cookies", giving us an idea of what is being exfiltrated. It also includes "VIP Recovery", which is present in the subject header as well — making it a strong indicator that these are the strings we should take note of when creating a signature.

SMTP-Based Exfiltration Detection: Rule Breakdown and Explanation

Hereʼs a draft of the signature I made:

Figure 18. Signature draft.

Letʼs walk through how the Suricata rule is crafted to catch this type of exfiltration.

1. Header Matching: Subject, PC Name, and VIP Recovery

We begin by looking for indicators in the Subject line. This field carries key metadata, such as the infected PC Name and a suspicious tag: VIP Recovery. The rule below scans for:

• "Subject:" (case-insensitive),
• "Pc Name:" right after,
• And the keyword format. "| / VIP Recovery" — which appears to be part of a signature-like format.
• content:"Subject|3a|"; nocase;
• content:"Pc Name|3a|"; distance:0;
• content:"|7c| |2f| VIP Recovery"; fast_pattern;
• "Subject|3a|" and "Pc Name |3a|" match the respective labels.
• The third pattern matches the visual structure "| / VIP Recovery"
• "fast_pattern" enables Suricata to efficiently index the content for quick scanning.

This entire structure is an excellent indicator of an attacker tagging the system or session with something recognizable for them, such as a “VIP Recoveryˮ tag.

2. Content-Transfer-Encoding: base64 as an Anchor

The "Content-Transfer-Encoding" field of the email header shows that this content is encoded in Base64. This is a critical point of detection because attackers often use Base64 to hide plaintext data during exfiltration.

The rule matches this field like so:

content:"base64|0d 0a 0d 0a|"; distance:0;

This looks for the string "base64" followed by two newline sequences (\r\n\r\n), which signals the end of headers and the start of the encoded body.

It's a strong anchor — once we hit this point, we can assume any data afterward is Base64 and can begin decoding.

3. Decoding and Matching the Payload

At this point, we decode the Base64 data — but only a portion of it. Why?

• Performance reasons: We limit it to 68 bytes so Suricata doesnʼt process a large payload, which could cause false positives or slow scanning.
• Offset  0: Tells Suricata to start decoding immediately after the last match (base64\r\n\r\n).
• "relative": Ensures the decoding is done relative to where the previous match occurred — maintaining positional accuracy.

We then look for keywords like "Cookies" and "VIP Recovery" in the decoded content:

• base64_decode:bytes 68, offset 0, relative;
• base64_data;
• content:"Cookies";
• content:"VIP Recovery"; distance:0;
• base64_data signals that Suricata should now analyze the decoded content
• This allows us to find attacker-defined markers inside the exfiltrated payload itself.

Now, letʼs run Suricata and see if we are going to get alerts out of the signature we made:

Figure 19. Running Suricata to check for alerts.

And yes, we got an alert! Letʼs review the logs to see what an SOC analyst can see when they review the alert.

Figure 20. Reviewing the alert.

Summary

This detection strategy is effective for identifying exfiltration attempts over email that use Base64 encoding for obfuscation. It focuses on key indicators such as system identifiers in the subject line, the use of Base64 as a transfer encoding, and the presence of specific keywords such as “Cookiesˮ or “VIP Recoveryˮ within the decoded payload. By combining header-level matching, encoding detection, and selective Base64 decoding, the Suricata rule is able to detect suspicious activity efficiently without compromising performance. This approach offers a balanced and practical method for monitoring and flagging potential data exfiltration attempts in real-world SMTP traffic.