Trustwave's 2024 Retail Report Series Highlights Alarming E-Commerce Threats and Growing Fraud Against Retailers. Learn More
Get access to immediate incident response assistance.
Get access to immediate incident response assistance.
Trustwave's 2024 Retail Report Series Highlights Alarming E-Commerce Threats and Growing Fraud Against Retailers. Learn More
I recently got a chance to dig into a couple variants of the new Apache injection module that Sucuri recently discovered (check out their nice write-up here). Unfortunately this thing still doesn't have a cool whiz-bang name like most of the other malware out there. This is likely due to the fact that very few (if any) Anti-virus companies have provided detections for the malware at this time. While it's still very early in my progress reversing the samples thus far, I wanted to share what information I had in the meantime in order to help other analysts, or perhaps any individuals looking for ways of identifying the malware.
During this post I'll dig into the encryption discovered within the Apache modules, and provide some YARA signatures I've created for detection purposes (Sucuri provided on method of detection, however, I simply wanted to complement it with another technique).
While I was analyzing the Apache modules, it quickly became apparent that some form of encryption was being utilized in order to decrypt the 'juicy' bits of this malware. Specifically, I found the following function was called when the module was initialized:
After a bit of confusion, I determined that XTEA—or some form of it, was being used by the authors. XTEA is a newer variant of the Tiny Encryption Algorithm (TEA), and it's a perfect candidate for malware authors who are looking to hide some data without some of the overhead other encryption algorithms provide.
Going through the assembly, I was able to reproduce the function in (my personal favorite language) Ruby. I should note that I somewhat cheated by simply modifying some other code I discovered on a GitHub Gist. You can see my results, along with a few notes on why their implementation was non-standard, below:
Using this algorithm, I can take the encrypted blob of data within the Apache module, and decrypt it using the supplied key. I've included an example of this below (not all data displayed due to length):
I haven't discovered how all of this data is used at this time, however, some things should be easily identifiable, such as the injected iframe string. Additionally, you can see some blacklisted User-Agent strings (google, bing, yandex). I've also identified the 'admin' string to be a blacklisted URL (paths with this string look to be ignored).
What's great about this encryption implementation is the fact that it's used throughout all of the Apache modules I looked at. Because it's non-standard, it provides a perfect unique characteristic that can be used for detection. That being said, I've created a YARA signature that will hit on either the encryption implementation, or the individual keys that were found in the samples. You can grab the signature from our Github:
https://github.com/SpiderLabs/Malware_Analysis/blob/master/Yara/Apache_Injection_Module/apacheInjection.yara
Trustwave is a globally recognized cybersecurity leader that reduces cyber risk and fortifies organizations against disruptive and damaging cyber threats. Our comprehensive offensive and defensive cybersecurity portfolio detects what others cannot, responds with greater speed and effectiveness, optimizes client investment, and improves security resilience. Learn more about us.
Copyright © 2024 Trustwave Holdings, Inc. All rights reserved.