Corelight Bright Ideas Blog: NDR & Threat Hunting Blog

Detecting The Agent-Tesla Malware Family | Corelight

Written by Keith J. Jones | Jul 2, 2024 9:55:20 PM

Welcome to the latest from Corelight Labs! This blog continues our tradition of picking a popular malware family from Any.Run and writing a detector for it! Trending consistently at #1 on Any.Run’s malware trends list, Agent Tesla uses multiple protocols to communicate with its C2 infrastructure, making it more difficult to detect robustly than a malware sample utilizing only one network protocol for its C2.

The behavior we’ll review here concerns samples sending information back to controllers via one-way traffic (“exfiltration”, or “exfil”). This is a tad different than the usual C2 command-and-control, which is bidirectional (the C2 server sends commands to the infected system, which sends back status and data). However, convention also applies the term C2 to exfil, so we’ll stick with it throughout this blog to stay consistent with prior discussions of this malware family. (Technically, Agent Tesla is classified as InfoStealer malware.)

According to Blackberry’s blog, there are four network protocols used for Agent Tesla’s C2: FTP, SMTP, HTTP, and Telegram. Our research of the public data at Any.Run confirms Blackberry’s findings; we also saw four C2 protocols.

You can download PCAPs of each C2 protocol at the following links:

We will discuss each C2 protocol in its own section below.

FTP C2

This was the first C2 protocol we discovered while browsing Any.Run. An example of an exfiltrated message (copied verbatim) from the first PCAP linked above uses a structured format we can search for:

We can build a Zeek signature to detect the first three field names listed in the exfiltrated data from several samples we saw on Any.Run:

Notice the signature must happen at the beginning of the connection and is signified with the caret, as this is unique to the FTP data transfer. When this FTP signature matches, it will run the following Zeek function to log a notice in notice.log:

1 Note that technically this caret is redundant because the signature payload must match from the beginning of the connection. We put the caret in here to clearly contrast the concepts in this FTP signature with the signature you’ll see in the next SMTP section.

The function to log a notice is “NOTICE” (see above). Zeek notices allow for a suppression interval, based on the “$identifier” field in the input record to the “NOTICE” function. In our example above, we did not use an “$identifier” value, so every matching instance is output to the notice.log file. Typically, authors who write detectors for CVE exploits and other non-malware-related detections will suppress on the orig_h and resp_h endpoint pair because the analyst usually only cares that an exploit was executed. In the case of malware analysis, we prefer to see all of the messages passed between the victim endpoints and the C2 infrastructure because, in many cases, we can decode/decrypt the payloads. Therefore, we do not suppress notices. Of course, we could create a new Zeek log to save this information, but there is some complexity involved with adding new logs, schemas, SIEMs, etc. when you go this route (a good topic for another time). Therefore, we use notice.log as our one and only log destination to save the exfiltrated payloads.

An example notice.log for this detection follows:

The source, destination, and exfiltrated message are listed above in bold in the log.

For the next protocol, SMTP, Agent Tesla uses a similar message structure, which allows us to write another Zeek signature.

SMTP C2

According to Blackberry, Sophos, and McAfee, SMTP appears to be the most widely used protocol for Agent Tesla’s C2 because it requires the least amount of work and the most security for the malware author. In the FTP example, the attacker needs an FTP server available, which could be taken down by law enforcement. But with SMTP, the malware only needs a compromised email address to exfiltrate the data.

We found the same Agent Tesla message format used in FTP pushed across an SMTP session, such as in this example from the third Any.Run sample linked at the beginning of this blog:

We’ve listed the exfiltrated message in bold, above. Notice it is the same message format as the FTP example. We will use a Zeek signature that is similar to the FTP example, but since the Agent Tesla message can come later in an SMTP session, we do not anchor the regular expression to the beginning of the connection:

Notice how the “.+” in the regular expression detects the exfiltrated message anywhere but at the beginning of the connection. When the signature above is detected, the following Zeek function runs to generate a notice in notice.log:

Next, we will look at HTTP, a protocol where Agent Tesla diverts from the message structure we saw in the FTP and SMTP examples.

HTTP C2

The fourth Any.Run PCAP linked at the beginning of this blog has an Agent Tesla HTTP C2 session within it, as follows:

Red signifies the data transferred from the client to the server, and blue represents the data transferred from the server to the client. Agent Tesla uses an HTTP form in the session above, and the structure of the exfiltrated message is:

Base64 strings contain the following encoded characters: A-Z, a-z, +, and /. Here, the plus sign is encoded as %2B in the HTTP data. Therefore, we can search for this HTTP form C2 with the following signature:

The following Zeek function runs every time this signature is matched:

The function above generates the notice.log below:

The data appears to be encrypted inside base64, so decoding the base64 results is not immediately helpful to the incident responder without a decryption key.

Telegram C2

The last protocol we know Agent Tesla to use for C2 is Telegram, a widely used messaging service. Since all of the data is exfiltrated over HTTPS to Telegram’s API servers, it is difficult, if not impossible, to tell AgentTesla C2 traffic apart from benign Telegram messages.

We checked the JA3 value of Agent Tesla against JA3 values we found logged on a real university network and determined the JA3 value could not be used as part of the detector because many other benign connections would match, too. Today, Telegram is the most difficult-to-detect C2 method in AgentTesla.

Conclusion

We were able to detect AgentTesla C2 in three out of four protocols we know it to use. FTP and SMTP C2 were very similar Zeek signature detections, while HTTP required us to write a slightly longer signature to detect the base64 data.

If you would like to install the source code discussed throughout this blog, you can do so from the following link:

https://github.com/corelight/zeek-agenttesla-detector