Landingpages bites the dust - Sweet Orange

Sweet Orange (SO) have become more and more rare lately but it's one of the kits that haven't changed at all when it comes to the landingpage.

Basic Structure

SO carries one of the biggest landingpages of all the kits with a size of 280-300Kb, all of which includes a string of 6-8 bytes that works as a delimiter for the "main" script in the landingpage.

It also includes some legitimate HTML to make it look like a legitimate webpage, and the content is actually from real webpages. The sample used in this post can be found on [pastebin]. Using Google it's found that the HTML originates from www.mariposamuseum.org/world_instruments03.html, the difference is that the word Idiophones have been replaced with Large Cloud:

Sweet Orange HTML compared to legitimate webpage

 After the decoy HTML, the malicious script starts. The plugin detection is hidden in a li-tag which is subject for replacement at the bottom of the landingpage.

There is two levels of obfuscation, first the delimiter will be removed, revealing the main script however, all &, <,  > and % are nowhere to be found. Those are added at the end using String.replace in the second level.

String replacement in landingpage

Client identification

The main script [pastebin] checks for browser version and Flash version before launching any exploits. The function names are not obfuscated, making it easy to read.

Check browser and launch IE exploit

Check Flash and launch Flash exploit

Last but not least, a JNLP will be loaded in preparation for Java exploitation.

There isn't really that much to it in terms of advanced techniques or tricks.

Detection

Here is a few examples taken from Sweet Orange throughout the year.
2014-04-20:

ubjCzzjOSb = jinLOqHUrn.substring(60).replace(/jeR--_33S/, "");
ubjCzzjOSb = ubjCzzjOSb["xRadwPhBvkonCnYGSLGSNR".charAt(21).toString().toLowerCase() + "zQYbiTsKBgHRMmboJTCAUePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__mb3__/, "<");
ubjCzzjOSb = ubjCzzjOSb["BVsXCvUwSbVDbYmIAxdwKR".charAt(21).toString().toLowerCase() + "BuMUiFRjDVDxOELrHlydsePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__Ob8__/, ">");
ubjCzzjOSb = ubjCzzjOSb["VgIvbfxtpUcdELmXlPMuDR".charAt(21).toString().toLowerCase() + "cluTqHOwGCviXBvPObDlaePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__Hb7__/, "&");
ubjCzzjOSb = ubjCzzjOSb["UJchLeVPhClZLEBVWleeBR".charAt(21).toString().toLowerCase() + "RzifGzNyuLgkuWfsJdvktePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__Nc0__/, "%");

2014-06-28:

mmSGqncKVi = DkPBNuJiFk.substring(60).replace(/ZJXm-_7q2/, "");
mmSGqncKVi = mmSGqncKVi["svcUQTPiOxzQewMHjxUSmR".charAt(21).toString().toLowerCase() + "ynnIJcpckBccKDamANMALePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__hhg7_/, "<");
mmSGqncKVi = mmSGqncKVi["IJvXqlxwzJjPMiYeTCdJUR".charAt(21).toString().toLowerCase() + "XTLpgjtTeESBeyEKjWQhGePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__Db8__/, ">");
mmSGqncKVi = mmSGqncKVi["fCDSsWebkuqhbWMWbZLChR".charAt(21).toString().toLowerCase() + "lkgHcnCcpWveIGpoYMNStePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/_uio0__/, "&");
mmSGqncKVi = mmSGqncKVi["uNADVNFPkHZaUlEcMVVyTR".charAt(21).toString().toLowerCase() + "tUFiudmZYpEKgtNxoehPuePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__cc0__/, "%");

2014-08-20:

PoBpsXFGOP = jUkalrchvM.substring(60).replace(/n5Xc4_7w9/, "");
PoBpsXFGOP = PoBpsXFGOP["hhFcPPScoahJvsMypMhooR".charAt(Math.sqrt(441)).toString().toLowerCase() + "ghoAJERaNwXAkWJcmsXBoePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__hhg7_/, "<");
PoBpsXFGOP = PoBpsXFGOP["qaBaJkOMfRPHHqyRBmGnZR".charAt(Math.sqrt(441)).toString().toLowerCase() + "LNlIfrpfGHpeqyJtyGMJlePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__Db8__/, ">");
PoBpsXFGOP = PoBpsXFGOP["gfZrLHSdOjKprxNoOQqXFR".charAt(Math.sqrt(441)).toString().toLowerCase() + "KzlUJPpCvqIVcAZhjsNGZePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/_uio0__/, "&");
PoBpsXFGOP = PoBpsXFGOP["LBeVqPfZzJLqgNhrMJNIMR".charAt(Math.sqrt(441)).toString().toLowerCase() + "wXWMEtMqIJmHaazzTqEOcePl".substring(21, 28).toLowerCase() + "Ace".toLowerCase()](/__cc0__/, "%");

It's found that the pattern below is consistent in all the landingpages (not limited to above samples).

.substring(21, 28).toLowerCase() + "Ace".toLowerCase()]

This would enable for detecting and blocking Sweet Orange before any exploits gets to be launched.

 Resources 

Check out Malware-traffic-analysis.net for more examples and live traffic from Sweet Orange. The post include links to all captures done by @malware_traffic (big thanks for providing data!).

Landingpages bites the dust - Angler

Basic structure

The landingpage is built up of two stages of obfuscation where there are five containers at the beginning of the page with obfuscated data (one for each line), each with it's own specific purpose. In the landingpage used in this example [pastebin] you'll find these five on lines 28-32.

After the five containers comes the function for deobfuscating and executing the code in the each container.

The section that comes next includes obfuscated strings which will be used by the code in the containers at the top, this includes domain and URI for the exploits.

The rest of the landingpage is simply just a decoy to make the page look "legit".

Client identification

Angler does not only use plugin-detection to identify vulnerable versions, it does also employ detection of installed anti-virus software. This is done through the code in the first container. The code can be found by setting a breakpoint on the line calling eval() in the deobfuscation-function:

Firefox Webdeveloper Debugger

The contents of HzV0 gives us the code:

  function gs7sfd(txt) {
      var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
      xmlDoc.async = true;
      xmlDoc.loadXML('');
      if (xmlDoc.parseError.errorCode != 0) {
          var err = "Error Code: " + xmlDoc.parseError.errorCode + "\n";
          err += "Error Reason: " + xmlDoc.parseError.reason;
          err += "Error Line: " + xmlDoc.parseError.line;
          if (err.indexOf("-2147023083") > 0) {
              return 1;
          } else {
              return 0;
          }
      }
      return 0;
  }
  if (gs7sfd("c:\\Windows\\System32\\drivers\\kl1.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmactmon.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmcomm.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmevtmgr.sys") || gs7sfd("c:\\windows\\system32\\drivers\\TMEBC32.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmeext.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmnciesc.sys") || gs7sfd("c:\\windows\\system32\\drivers\\tmtdi.sys")) {
      window['zxtbVDMp'] = true;
      BzJUQufh = '';
      window.sf325gtgs7sfdj = window.sf325gtgs7sfds = window.sf325gtgs7sfdf1 = window.sf325gtgs7sfdf2 = false;
  };

If it should find that if Kaspersky or TrendMicro anti-virus is installed, it will cancel the intrusion attempt as it's likely to fail and unwanted noise is created (alerts from anti-virus). Another interesting part is that if you look at the landingpage of RIG you'll find that it uses the exact same code, which is originally found in "Operation Snowman".

The code in the second container is responsible for checking the version of installed plugins, but also the function for decoding the strings listed in the original landingpage where the key is defined in the variable ending with 0:

Original landingpage on the left, code in second container on the right

The third contains the code for generating code used for loading a Silverlight exploit:

Original landingpage on the left, code in third container on the right

 The same approach is used for the Flash exploit. If it should be found that none of Silverlight, Flash or Java installed it would resort to Internet Explorer exploit if the version is > 10.

A summary of all deobfuscated sections can be found on pastebin. [pastebin]

Detection

Angler is one of the kits which have a generic look when it comes to the landingpage request, the response however is another story as shown above.

The top containers are changing from instance to instance but the variables after the deobfuscation function doesn't (i.e the variables ending with 0-11), they follow the same pattern. Some examples:

Three different landingpages

The one which is most noticeable is the variable ending with 0, which as shown earlier holds the deobfuscation key which is always 20 byte. Giving a suggested pattern of:
/[A-Za-z]{6}([0-9])?0\s=\s'[A-Za-z0-9]{20}',\x0a/

Resources

For those who use Snort/Suricata which only capture the trigger-packet, this script could help in decoding the strings and revealing the source domain. [pastebin]

More examples of Angler can be found from malware-traffic-analysis.net

Landingpages bites the dust - Fiesta

Fiesta is one of the kits which have been around for quite some time and haven't undergone any major changes. The URI have changed for the landingpage but not the landingpage itself.

Basic structure

Fiesta is using string obfuscation to hide links to exploits which then is concatenated to form the landingpage. There isn't much to it than that, moving on to the client identification and detection.

Client identification

Fiesta doesn't employ any detection for anti-virus or virtual environment as Angler nor using PluginDetect, but simply uses it's own implementation of detecting installed plugins.

It will run the detection for each plugin, top to bottom and directly after each check it will load an exploit if the plugin is found to be vulnerable as shown below (comments added by me):

The sample from above can be found here; [pastebin, raw]  [pastebin, decoded]

Detection

Fiesta have made small changes to the URI to the landingpage during the last year using for example:
domain.tld/anfjsf4/2
domain.tld/skejgq7/?1
domain.tld/ajdw2ja/osf3tyzhuohcvpxoythoclzqruiis6rxd9w

The landingpage however haven't been changed more than the obfuscation key, which is changed every 7 days (approximately).

The key can be identified in the first Javascript function in the response as shown in the PCAP's below:
Example one:

Example two:

Example three:

Example two and three is using the same key but the rest differs, for example function and variable names, the key however stays the same.

The same key will also be used for deobfuscating the IE exploit.

Resources

This script can be used to decode the strings in the landingpage [pastebin].
More examples of Fiesta can be found from malware-traffic-analysis.net

Landingpages bites the dust - RIG

 

 

Basic structure

RIG have adopted a "top-to-bottom"-approach when executing it's code. The page starts with checks for installed anti-virus before moving on to deobfuscate and execute exploits (more on this in the next section). Sample used in the post can be found [raw] and [decoded] (exploits).

The exploits are split up into sections where a portion of the code is concatenated into a long string for each line:

 Capture below show the decoding used when the all the portions have been concatenated:

This pattern repeats for every exploit found in the landingpage.

Client identification

At the very beginning RIG will check for the presence of Kaspersky and TrendMicro. What's interesting is the code used for checking if they're installed:

The code above is the exact same code used in the watering-hole attack "Operation Snowman" targeting US military personnel, the only modification is to make the code callable from a loop as it does in the landingpage.

The code used in Operation Snowman can be seen below, the only difference is that RIG ignores the check for EMET and goes for anti-virus instead.

Code from Blackploit

Since this check utilizes Microsoft.XMLDOM, it means that only users of Internet Explorer will exploitable. Any other browser will fail the check for anti-virus as the function itself will fail. If it's found to have none of the blacklisted anti-virus installed it will do a function re-assignment of String which is later used in calling String.fromCharCode to decode each exploit section:

After each exploit section has been decoded, it's found that no checks are being made for which specific version of the plugins that is installed other than for Adobe Flash:

(Each section can be decoded by setting a breakpoint on the line calling appendChild in the landingpage and inspecting the content of the parameter (I used Firefox Debugger in the Web Developer tools)).

Detection

Much like Fiesta, RIG does change it's obfuscated strings, however, the deobfuscation routine stays the same so it's possible to use almost any line for simple string-matching signature.

It's also possible, since RIG doesn't obfuscate the AV-detection to trigger on for example c:\\windows\\system32 as there is almost no legitimate reason for calling files from system directory in webpages.