We’ve run the Encrypted Visibility Engine (EVE) in Firewall Threat Defense (FTD) at enough conferences to develop a ‘usual suspects’ list of malware detections. Endpoint connections related to Upatre, Xpiro, and Quasar malware are among the most consistent malware related detections in EVE from conference to conference. The Splunk .conf network brought a new detection that we hadn’t seen before: Flawed AMMYY.

AMMYY is a remote access tool that is often misused in scams to gain access to victim computers. There is also a Remote Access Tool (RAT) called Flawed AMMYY that was developed from leaked AMMYY source code, and is directly used as malware. See the MITRE advisory here.

One of the key value propositions of EVE is that it can use granular session fingerprinting to differentiate between similar but distinct applications like AMMYY and Flawed AMMYY. Let’s dig into the events we saw for Flawed AMMYY and some of the details that EVE had to look at.

Our EVE detections for Flawed AMMYY came in pairs with identical timestamps, as seen above, all from a single IP. While these connections are tightly related, one is HTTP (as seen in the URL column) and the other is HTTPS. Notice that EVE assesses both the HTTP and the HTTPS connections, but has a higher Confidence Score for HTTP—because EVE is able to see the full session details for the HTTP session, it can issue a higher confidence score. While EVE provides crucial visibility for encrypted HTTPS sessions, decrypted is always better.

Let’s pivot to Splunk and look at a broader set of the fields that are available for these EVE events. First, the HTTPS connection:

We can see above that even though the session is HTTPS, EVE is still able to see some destination information, including the destination IP, URL, and other criteria. All these components go into the EVE fingerprint for the session, which is used to determine the process that launched the connection. Also note that MITRE information is provided for the connection, including the Command and Control | Encrypted Channel designation that we would expect for this malware. Now let’s look at the accompanying HTTP connection.

Because this connection is HTTP, we can see not only the destination IP and URL, but also a download attempt for an .exe. This additional level of visibility allows EVE to upgrade its confidence from 82 (for the HTTPS connection) to 99 (for the HTTP connection). Note that while the endpoint initiated this HTTP connection, if we performed TLS decryption we would get this same level of visibility for decrypted HTTPS sessions.

So why is this endpoint repeatedly launching dual HTTP and HTTPS connections with the same timestamp? We can leverage our Endace full session packet capture to confirm exactly what occurred during the HTTP session.

We can see above that after the TCP three-way handshake, the endpoint (10.x.x.x) attempts a GET request for an .exe file. The server (136.) responds with an ACK, then a 301 redirect, then closes the connection with a FIN packet. From this, we can infer that the endpoint starts with an HTTP connection, receives a redirect, and then proceeds to an HTTPS connection. The initial download attempt over HTTP isn’t successful (because of the 301 Moved Permanently redirect), but may succeed over HTTPS. This is where an organization would shift to endpoint analysis to verify the process source of these repeated download attempts, whether the HTTP requested .exe succeeded over HTTPS, and whether the file was successfully installed.

EVE gives that initial process level detection—using only an HTTPS connection fingerprint, or in this case, a pair of HTTP and HTTPS connection fingerprints—that can turn blind HTTPS traffic into a granular malware detection.

Check out the other blogs written by our Agentic SOC team at Splunk. conf.