An Example of Evolving Obfuscation

Published: 2015-03-03
Last Updated: 2015-03-03 16:42:34 UTC
by Brad Duncan (Version: 1)
3 comment(s)

Since May of 2014, I've been tracking a particular group that uses the Sweet Orange exploit kit to deliver malware.  This group also uses obfuscation to make it harder to detect the infection chain of events.

By 2015, this group included more obfuscation within the initial javascript.  It's a relatively minor change in the overall traffic patterns; however, the result causes more work to detect the malicious activity.

Either way, the infection chain flows according to following block diagram:


 

 

Previous obfuscation

Below are images from an infection chain from July 2014 [1].  Here we find malicious javascript from the compromised website.  In this image, I've highlighted two areas: 

First is the function that replaces any non-hexadecimal characters with nothing, and it replaces various symbols with the percent symbol (%):

Second is the URL that will return the variable to be translated:

Here's how the variable is translated to the URL for the Sweet Orange EK landing page:

 

Recent obfuscation

Below are images from an infection chain by the same actor in February 2015 [2].  Again we find malicious javascript from the compromised website.  However, in this case, there's more obfuscation:

First is the function that replaces any non-hexadecimal characters with nothing and replaces various symbols with the percent symbol (%).  This time, we have unicode-based hexadecimal obfuscation and some variables thrown in.  This does the same basic function as the previous example.  It's now a bit harder to find when you're looking through the javascript.

Second is the URL that will return the variable to be translated:

That URL is now obfuscated with unicode-based hexadecimal characters.  For example, \u0074 represents the ASCII character "t" (lower case).

Once again, let's see how the variable is translated to the URL for the Sweet Orange EK landing page:

 

Final Words

This evolution in obfuscation is a minor change in the overall traffic; however, the result causes more work for analysts to fully map the chain of events.  We can expect continued evolution of these obfuscation used by this and other actors.

---

Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://malware-traffic-analysis.net/2014/07/08/index.html
[2] http://malware-traffic-analysis.net/2015/02/09/index2.html

Keywords:
3 comment(s)

Comments

I wonder what the point is of using port numbers that differ from the standard 80 and 443 in the malicious URL's. Taking the simple precaution of basic egress filtering would prevent client computers from reaching the URL's. Ports 80 and 443 are generally open and accessible by everyone.
Good question. HTTP traffic on non-standard ports is a way to evade detection. Some intrusion detection systems (IDS) don't examine HTTP traffic over non-standard HTTP ports. We see this with Sweet Orange exploit kit (EK), and we also see it with Neutrino EK (especially since that EK's reboot in late 2014). HTTP traffic on non-HTTP ports is sometimes generated by malware from an infected host.


Simple egress filtering would block such traffic. Judging from what I've seen, I think the most home networks don't have this in place. Many businesses might not, either. You'd have to be careful not to block legitimate TCP traffic.
We deal with many local and county government sites and they are infamous for a number of "not good" practices, including running multiple websites on the same IP address but doing it by running them on different ports. Go figure.

Diary Archives