Lord EK: A New Exploit Kit with an Ambitious Name
After a bit of a lull in the world of exploit kits, a new exploit kit by the name of “Lord EK” has been discovered out in the wild. This blog post will give an overview of what’s already been talked about as well as add some insights that I believe have not yet been shared publicly and provide Trustwave customers with some additional information for relevant products.
A few weeks ago Adrian Luca of Virus Bulletin spotted a new exploit kit that goes by the name of “Lord EK”. Finding a name for this kit was easy, as the author themselves stamped the landing page with the kit’s name, which can be seen with just a bit of de-obfuscation work:
Figure 1: The source code of the landing page (left) and the de-obfuscated version of the code (right)
Brad Duncan of Malware Traffic Analysis shared samples of Lord EK, and Jérôme Segura of Malwarebytes did a nice write-up on the kit, including some IoCs.
While analyzing this kit as part of the research for Trustwave SWG, I noticed something strange about Lord EK that has yet to be mentioned. We already know that there is a script within the page which collects information about the victim’s machine (specifically the victim’s Flash Player version, IP address, country, state, and city) and sends it back to the server.
A couple of requests later, when it seems that the decision has been made to deliver an exploit to the victim, a cookie by the name of “session” is set on the victim machine using the Set-Cookie HTTP header, this cookie is returned back to the server in the follow-up request for the Flash exploit. What caught my eye about this cookie is that it looked like base64 encoded data:
Figure 2: The cookie data before decoding
And attempting to decode the data confirmed my suspicion, here is the cookie after a base64 decode:
Figure 3: Cookie data after a base64 decode operation
The decoded string already appears to be a little more meaningful, with several values separated by pipe (“|”) characters. The first can easily be identified as a unix timestamp which appears to note the current time when the cookie is issued. The second part seems to contain some more base64-encoded data, which decodes into the following:
Figure 4: Cookie data after a second base64 decode operation
or, in a more readable format:
Figure 5: Formatted data extracted from the cookie
Here we can clearly see that the cookie contains information regarding the CVE used, the URL of the payload and the type of exploit. Note that the payload link correlates to that observed in the SWF exploit file itself which is definitely not static since we observed different temporary names used for the .vbs file in different attacks:
Figure 6: ActionScript code from within the malicious SWF
Now, we know from previous work with EKs that exploit kit authors often like to retain information and statistics regarding victims, like which CVEs were delivered and whether the attack was successful, but usually this is all done on the server. There is technically no need for any of this to involve the victim, which makes this behavior a little odd.
Unfortunately, the server became unresponsive before we could test whether data from the cookie is directly used in the construction of the Flash or whether the kit’s author has simply chosen an odd way of collecting data. Either way, it’s an interesting piece of the puzzle that is Lord EK.
Taking a step back from Lord EK specifically, drive-by web attack trends are always interesting to observe, we’ve been seeing web miners replacing exploit kits for a while, but in the context of the demise of CoinHive (and consequential decline in web miners), does the appearance of a new exploit kit imply a renewed demand for drive-by exploits?
Time will tell…
Trustwave SWG customers are (and have been) protected against the Lord Exploit Kit and its observed payloads, additional detection logic will be added soon to help identify Lord EK specifically. Trustwave IDS and NGFW customers are also protected against Lord EK.