Another Journey into a Malicious Abyss
This anonymous submission came to us a few days ago, only with the knowledge that the this payload tripped and was dropped by an Enterprise level A/V appliance. The 'submitter' got their hands on it and asked us to break it down. For this project, I elicited the help of F1re_W1re, a very good c0d3r as well as a very good brother. we have worked together many times in the past, with nothing but amazing results. When a second set of eyes or decoded iteration is needed, he is my go to. A hat tip to you, Sir.
This project was a true collaboration of skillz to which I graciously thank him for his role as primary contributor. For reasons, I assumed the role of Project Manager (PM), and Lead Consultant. This was solved by both of us doing out part and offering input and direction as needed. Often time it takes another set of eyes to see what's there, (or just not apparent). You will get what I mean later on. Let's get at it!!
After acquiring the sample, it was clear that it had been base64 encoded using the JavaScript vairiant; bota(). The base64 encoding has implements in many langs. However, despite some nuances, it's similar to what can be seen below, at times several pages in length: (We will go into those nuances at a later time).
Current Python libs contain good modules to decode these strings which give way to the raw code. However, F1re_W1re utilized a couple other implements that produced similar results, maybe even more efficiently. Using the Py interpreter and simple arithmetic, he ran:
>> print (x-y,x1-y1,xn-yn...).
Once the numerical values were extracted, he went back to JS and and input results in the String.fromCharCode() command to extract the ASCII chars, as seen below:
Finally, back to Python where some slight modifications were made to a Py 'XOR' script to decode the rest of the troublesome obsfucation in the beginning of the base64. Although we can't disclose our modz, a sample of the original Py elegant XOR code and screenshot are below are courtesy of a dustri.org tuto. (Thank you, Dustri, for the code logic and inspiration!!).
**Just an fyi to those not familiar with XOR, it is an expression used in some langs to make logical comparisons like, (a or b = 'true' but a and b cannot be true).
Despite the sizable block of strings that didn't decode, at first glance the raw JS wasn't all that malicious looking. It got suspicious when walking it. A bit odd, (maybe suspicious), but overall fairly begnin in nature. This is where the 'true' Malware Analysis comes into play.
1. It was a payload, and recently placed on a 'vendor's' site, and intentionally sent to a trusted partner's Enterprise environment. - Strike#1.
2. It was rejected/dropped by AV. This wasn't due to the base64 either, this is commonly used in packet transfers. - Strike#2.
3. There was the bit of raw code viewed early on that was written to create two (permanent) redirects, with no-exp cookie and placed in local storage, not a cache! - Strike#3 Out!
4. Several layers of obsfucation.
5. Codes many redirects to a final page, a BHO like behavior.
6. More suspicious/malicious activity at final URL.
Recall as I said, these put together in this scenario makes it all more suspicious, at least illogical. We need more analysis, especially since this is a submission and verified, in the wild, mal sample. We will rip it apart and find it!... Plus, those who know of us, know our tenacity. So with a mal somewhere to uncover, we continue on...
Now that we had a fully decoded payload, I ran a dynamic analysis which resulted in the following. Although these may not be seen as malicious, they are quite intrusive with very suspicious behaviors. To unleash this in an enterprise type environment... IS nothing less than malicious. Each category listed below has numerous instances, with NONE having any valid purpose but to gather info and change system settings. The two images below show a good enough overview of the questionable activities of the script. This is the listed behaviors, a post dynamic analysis:
Spoiler alert! This is a variant of a js code injection used on WP sites and onto any visitor's browsers. After all the decoding I was able to positively match the code and 'magic' cookie hash seen in the image below AND matching the site redirect. It's simply an BHO/SEO rankings attack, just as I had suspected, a variant WP -JS injection of last year's BHO/SEO attacks. The particulars are changed some, but still intact enough to be a match. Explained simply as:
What can be read from the code:
It does not run if a bot is the user agent (e.g. google, yahoo...) or if you are running as admin/editor?
After some seconds: It setups a cookie with name "yYjra4PCc8kmBHess1ib" for the attacked domain, with value "123" and stores in local storage such key with value 1. (key must be different per site, to identify it) After that, it will redirect your site to: http://xxx . com.mx/xxx/ and onto...
...site 'loxxxe . com':
It is/was a dating site located and registered in US. So what I see from this, is that they use a Wordpress vulnerability to inject a JS which will redirect visitors into 'loxxxe . com' ...Bad business!...
Possible encoding problems:
The problem with the encoding could be related to other reasons: perhaps the code who injects the code altered the original content intentionally (vandalism) or unintentionally (they don't handle unicode very well).
There is one error some beginning analysts can make when walking JS code. For those that have experience, you know simple mal-scripts can be anywhere and not outwardly noticeable, it's very good at hiding unless you immerse yourself in command/string/array and visualize it. In this case, it wasn't malicious but more a suspicious code. It was the behavior of the script. Albeit somewhat BHO'ish, the code at first glance seemed OK. It is a bit dirty, however, placed in context of this particular situation, it was illogical, The idea it was checking for and placing referrer redirects, using magic cookies with null expire and placing them in local storage instead of cache? The last I saw of this behavior was when wp had cache entries that were actually xhtml files with all authentications, no exp. cookie, appropriate cert swaps along with "keep-alive" status... made for one hidden backdoor. I'll leave the intrusive page source out! :-/. Stupid 'wp' sans-integrity, has anyone else read the source of their 'free' sites? IMO-Only...gtg!
One has to look at the macro and micro; the entirety of facts available. Making sure the pieces fit before the final synopsis (or an all-clear) is given. Code can be misread, especially if you are already seeing signs of suspicion. Code can easily be misinterpreted as you start seeing things that aren't there. Anyone who has been on a deep dive can tell you, things can get fuzzy. That's why it's wise, (especially during deep dives), that you turn your findings over to a trusted colleague for confirmation. Another reason we don't have a definitive answer now, even though we technically have the decoded source of the payload... some questions remain to put it all together, giving the ability to explain the overall function of the malcode:
-what is on those referrer/redirect sites? Decode all "drive-by DL's" on rHosts.
-what is their code and purpose? Log and decode each.
-decrypt/decode everything on the way. I've watched hijacked domains/servers change assets and code in minutes. Log it ALL.
We have all the data that will prove to be our PoC in this matter: raw assets and pcap data of attempted delivery, decoded and dynamic behavior of the payload, very suspicious browser modification (redirects) and suspicious landing domain, containing outwardly suspicious http and JS with a hard-coded IP in a script. We can be confident it can be classified malicious, but never was, just dirty practices. The only thing left to do would be to walk the source of the page and decode all the toxic assets it is showing a date of 1970 and status "keep-alive". That is too much dive for this project. We have all requisite data.
We were able to look into some source-code scripts using which when analyzed. 'xxx . com.mx/xxx', which was burned, (completely unresponsive). The second, 'loxxxe . com', was a different story. The domain was up for lease, but the site was a typical dating site. No way! Leaving out the pcap summary, below is a bit of its dynamic activity in general. The second image is the same page, only hours later, see how much it's code has morphed? This only helps prove that this injection likely has polymorphic properties.
This didn't fit right to begin with, a fresh payload, redirecting to an obviously unrelated site..uhhh, right. So I dynamically hit the site, it wasn't cool, as seen above. I sent the analysis to F1re_W1re, he busted apart the source code. To start, no way a domain lease site is going to have this much action, even if it was of dating origin, (well, some irreputable ones maybe). What got me was the amount of http transactions/requests it had, with most assets having the infamous invalid date of 01/1970, a null or outrageous expire time and/or set to "keep alive". My partner found a ominous file in the page source called "img.php" inside a frame. Using the Linux "curl" command, inside was a similar 'magic' cookie, and instead of another redirect, it has a hard-coded IP address; xx:xx:1x:93. This php file is also notorious for an IP logger on php framework. Upon lookup using ARIN db., this is an IP block belonging to one of the 'big 3' ISP's in the US. Sorry m8'z, image below is only a snippet AND edited for privacy. It states this IP has a status of: reassignment.
All in all, this appears to be a strict variant of the "WP js injection", using multiple langs between it's delivery, execution/implementation and persistence, As to it's intent... an annoying BHO for SEO rank. We will track the file, (note any variants or changes in code) and it's movement as well, (by usual methods). ;), adjusting accordingly. Hehe.
IMO, from its code to the other data points around its existence, it's a novice or a 'skid'. One thing IS for sure, you lose! Again, our ''fu'' proves stronger than you. Especially that weak-azz code and obsfucation. Honestly, it took me longer to write this than it did for us to break you apart, "varmais" ... 'skid'
Ohh.. one more thing, so called 'coder'; hide your keys better, even brute-forced, they all told their secrets quickly... Estúpido codificador. Esto era demasiado facil.!
As always,
``r3v
-------
This project was a true collaboration of skillz to which I graciously thank him for his role as primary contributor. For reasons, I assumed the role of Project Manager (PM), and Lead Consultant. This was solved by both of us doing out part and offering input and direction as needed. Often time it takes another set of eyes to see what's there, (or just not apparent). You will get what I mean later on. Let's get at it!!
After acquiring the sample, it was clear that it had been base64 encoded using the JavaScript vairiant; bota(). The base64 encoding has implements in many langs. However, despite some nuances, it's similar to what can be seen below, at times several pages in length: (We will go into those nuances at a later time).
 |
| Base64 snippet. For those that aren't aware, to decode base64 in JS, is simply the original encode command, bota(), only backward. So, atob(). My results were as expected, encoded strings of a Unicode-type, as seen in the screenshot below. |
 |
| Raw strings. |
>> print (x-y,x1-y1,xn-yn...).
Once the numerical values were extracted, he went back to JS and and input results in the String.fromCharCode() command to extract the ASCII chars, as seen below:
Despite the sizable block of strings that didn't decode, at first glance the raw JS wasn't all that malicious looking. It got suspicious when walking it. A bit odd, (maybe suspicious), but overall fairly begnin in nature. This is where the 'true' Malware Analysis comes into play.
1. It was a payload, and recently placed on a 'vendor's' site, and intentionally sent to a trusted partner's Enterprise environment. - Strike#1.
2. It was rejected/dropped by AV. This wasn't due to the base64 either, this is commonly used in packet transfers. - Strike#2.
3. There was the bit of raw code viewed early on that was written to create two (permanent) redirects, with no-exp cookie and placed in local storage, not a cache! - Strike#3 Out!
4. Several layers of obsfucation.
5. Codes many redirects to a final page, a BHO like behavior.
6. More suspicious/malicious activity at final URL.
Recall as I said, these put together in this scenario makes it all more suspicious, at least illogical. We need more analysis, especially since this is a submission and verified, in the wild, mal sample. We will rip it apart and find it!... Plus, those who know of us, know our tenacity. So with a mal somewhere to uncover, we continue on...
Now that we had a fully decoded payload, I ran a dynamic analysis which resulted in the following. Although these may not be seen as malicious, they are quite intrusive with very suspicious behaviors. To unleash this in an enterprise type environment... IS nothing less than malicious. Each category listed below has numerous instances, with NONE having any valid purpose but to gather info and change system settings. The two images below show a good enough overview of the questionable activities of the script. This is the listed behaviors, a post dynamic analysis:
Spoiler alert! This is a variant of a js code injection used on WP sites and onto any visitor's browsers. After all the decoding I was able to positively match the code and 'magic' cookie hash seen in the image below AND matching the site redirect. It's simply an BHO/SEO rankings attack, just as I had suspected, a variant WP -JS injection of last year's BHO/SEO attacks. The particulars are changed some, but still intact enough to be a match. Explained simply as:
What can be read from the code:
It does not run if a bot is the user agent (e.g. google, yahoo...) or if you are running as admin/editor?
After some seconds: It setups a cookie with name "yYjra4PCc8kmBHess1ib" for the attacked domain, with value "123" and stores in local storage such key with value 1. (key must be different per site, to identify it) After that, it will redirect your site to: http://
...site 'lo
It is/was a dating site located and registered in US. So what I see from this, is that they use a Wordpress vulnerability to inject a JS which will redirect visitors into 'lo
Possible encoding problems:
The problem with the encoding could be related to other reasons: perhaps the code who injects the code altered the original content intentionally (vandalism) or unintentionally (they don't handle unicode very well).
There is one error some beginning analysts can make when walking JS code. For those that have experience, you know simple mal-scripts can be anywhere and not outwardly noticeable, it's very good at hiding unless you immerse yourself in command/string/array and visualize it. In this case, it wasn't malicious but more a suspicious code. It was the behavior of the script. Albeit somewhat BHO'ish, the code at first glance seemed OK. It is a bit dirty, however, placed in context of this particular situation, it was illogical, The idea it was checking for and placing referrer redirects, using magic cookies with null expire and placing them in local storage instead of cache? The last I saw of this behavior was when wp had cache entries that were actually xhtml files with all authentications, no exp. cookie, appropriate cert swaps along with "keep-alive" status... made for one hidden backdoor. I'll leave the intrusive page source out! :-/. Stupid 'wp' sans-integrity, has anyone else read the source of their 'free' sites? IMO-Only...gtg!
One has to look at the macro and micro; the entirety of facts available. Making sure the pieces fit before the final synopsis (or an all-clear) is given. Code can be misread, especially if you are already seeing signs of suspicion. Code can easily be misinterpreted as you start seeing things that aren't there. Anyone who has been on a deep dive can tell you, things can get fuzzy. That's why it's wise, (especially during deep dives), that you turn your findings over to a trusted colleague for confirmation. Another reason we don't have a definitive answer now, even though we technically have the decoded source of the payload... some questions remain to put it all together, giving the ability to explain the overall function of the malcode:
-what is on those referrer/redirect sites? Decode all "drive-by DL's" on rHosts.
-what is their code and purpose? Log and decode each.
-decrypt/decode everything on the way. I've watched hijacked domains/servers change assets and code in minutes. Log it ALL.
We have all the data that will prove to be our PoC in this matter: raw assets and pcap data of attempted delivery, decoded and dynamic behavior of the payload, very suspicious browser modification (redirects) and suspicious landing domain, containing outwardly suspicious http and JS with a hard-coded IP in a script. We can be confident it can be classified malicious, but never was, just dirty practices. The only thing left to do would be to walk the source of the page and decode all the toxic assets it is showing a date of 1970 and status "keep-alive". That is too much dive for this project. We have all requisite data.
We were able to look into some source-code scripts using which when analyzed. '
All in all, this appears to be a strict variant of the "WP js injection", using multiple langs between it's delivery, execution/implementation and persistence, As to it's intent... an annoying BHO for SEO rank. We will track the file, (note any variants or changes in code) and it's movement as well, (by usual methods). ;), adjusting accordingly. Hehe.
IMO, from its code to the other data points around its existence, it's a novice or a 'skid'. One thing IS for sure, you lose! Again, our ''fu'' proves stronger than you. Especially that weak-azz code and obsfucation. Honestly, it took me longer to write this than it did for us to break you apart, "varmais" ... 'skid'
Ohh.. one more thing, so called 'coder'; hide your keys better, even brute-forced, they all told their secrets quickly... Estúpido codificador. Esto era demasiado facil.!
As always,
``r3v
-------
 |
| RIP Sheikh Zayed... my friend. |
Comments
Post a Comment