Beyond the Zero Day: Detecting JVM Drive-bys – Part 1 of 3

By Erik Heuser, RSA Advanced Cyber Defense Services Advisory Practice Consultant

With all the recent Java Virtual Machine (JVM)exploits, a lot of attention is being focused on figuring out how best to mitigate the vulnerability.  Detection has been limited to signature-based attempts, mostly firing on class names or well-known strings within the JAR/Class.  While this works for the commodity malware based on pre-packaged kits like Black Hole and Redkit, a clever adversary will re-write the exploit and avoid that simple detection method.

During a recent engagement we came across a unique JVM drive-by. In this 3-part series I’ll cover:  detecting malicious JVM activity with the RSA NetWitness network forensics platform; reverse engineering the Class file, and analyzing the host with the RSA ECAT signature-less malware detection tool to quickly triage the incident.

Detecting Malicious JVM Activity with RSA NetWitness

How do we detect and analyze these attacks?  We start by profiling JVM activity and HTTP Methods.  Within the context of RSA NetWitness, we can write simple Application Rules to identify JVM activity via HTTP.  Next, we write another Application rule to profile HTTP Methods.  We’re specifically interested in HTTP GET’s without a POST.  This indicates a request to pull a resource from the remote host and is typical behavior post-exploit.

Combining this new metadata and analyzing the destination by host name or by IP revealed a direct to IP GET request from the JVM.  Re-pivoting on the destination IP revealed the entire attack.  The user was watching a YouTube video and was redirected to the attacker by a compromised ad network.

The iframe redirects to a PHP page and assigns a string to the variable ‘zid’.  The browser then crafts this request and sends it to the server.

Here we see HTML that uses the img operator to request a GIF.  At the bottom we have some Javascript that writes another iframe and passes the ‘zid’ variables to 4f.php.  This will generate two separate requests.

The first request is for the GIF, we can see the magic in the response.  When rendered we can tell it is a legitimate advertisement.

The next request, built by the Javascript-created iframe, retrieved an applet with an embedded parameter.

The “code” in the applet is the Class file and we can see it downloaded.

The Class file is compiled and starts with the magic 0xCAFEBABE, after the host executes it we see the JVM download a ‘blob’.

The ‘blob’ has no recognizable magic file header and has no known filetype.  The NetWitness Investigator forensics application attempts to render HTTP as ASCII so the binary data appears to be random.  Upon closer inspection, we can find 31 byte repeating structures within the ‘blob’ that would be at the same offset as the padding section in a PE header.

In Part 2 of this blog series, we’ll investigate the repeating structures further, reverse engineer the Class file to decode the ‘blob’ and assess the host with RSA ECAT.

Erik Heuser is an advisory Practice Consultant for the RSA NetWitness Incident Response /Discovery (IR/D) Practice at RSA. In this capacity, Erik is responsible for delivering holistic incident response services using state-of-the-art host and network-based technologies. In addition, Erik performs threat research and develops content / techniques that can be used by clients to identify compromise and mitigate risk.