Visar inlägg med etikett angler. Visa alla inlägg
Visar inlägg med etikett angler. Visa alla inlägg

lördag 2 augusti 2014

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

söndag 25 maj 2014

Dropnote #2 - Pony changing it's pattern

After the tweet from @malware_traffic I found myself recognizing the callback pattern and thought I would take a look.


The initial callback after the successful exploitation was a POST-request to 'gate.php' togheter with a few GET-requests for executables, both using HTTP/1.0 as shown below:

The first pattern looks alot like Pony (Pony is well documented on other blogs), however, I was expecting the usual "Microsoft 98" user-agent when inspecting the whole request, but instead I found:
Looking at Virustotal results, which at the time of writing is 3/52, it's flagged as "Fareit" by ESET and Kaspersky. So now to the interesting part, what is this Pony up to?

Pony itself is normally around 86kb depending on configuration and the payload itself in this case is 164kb which does suggest that it's either bundled with other malware, heavily modified version of Pony or that it includes alot of junkcode.

After running the sample under a debugger, setting breakpoints on CreateFileA and CreateFileW, I start finding interesting strings for example the "obfuscated" password used for encryption.

Just to mention, Pony stores the password it uses for encryption in an "obfuscated" pattern where each character is rotated two steps to the right. And looking at an unpacked version of Pony you'll find that the password is listed just before the callback server.

The strings above confirm that this is indeed Pony, yet modified. Let's continue with the configuration and encryption.

By letting Pony run, using the same breakpoints we find several interesting URL's:
So now we got the encryption-key, two gates and several executables that will be downloaded. Let's try decrypting the posted data.

Pony 1.9 used two layers of RC4 to protect the data. The key for the first layer is the first four bytes in the POST-data, the second layer is encrypted with the key found in the binary.

Decrypting the first layer gives us the familiar string CRYPTED0:
And the second layer using the key 'guardian1' gives us a compressed report:


So the encryption-scheme is the same, the change up to this point is simply to be harder to detect together with the ability to steal Bitcoin wallets.

EDIT: More coverage on the Pony Loader "2.0" on https://blog.damballa.com/archives/2558.

$ date
Mon May 26 01:33:37 CEST 2014

h00p://ourlittleponic.pw/gate.php - Active
h00p://ourponicjunior.pw/gate.php - Domain doesn't resolve
h00p://softwaregamecenter.eu/store/2.exe - Domain doesn't resolve
h00p://softwaregamecenter.eu/store/3.exe - Domain doesn't resolve
h00p://freepicscenter.pw/store/2.exe - 27ce89cc842baf51de2e08e2baa50b24
h00p://freepicscenter.pw/store/3.exe - c1d40e3677ea39be891550f6b03d112d
h00p://freecenterpics.pw/store/2.exe - Domain doesn't resolve
h00p://freecenterpics.pw/store/3.exe - Domain doesn't resolve
h00p://picsfreecenter.pw/store/2.exe - Domain doesn't resolve
h00p://picsfreecenter.pw/store/3.exe - Domain doesn't resolve

Also found h00p://freepicscenter.pw/store/1.exe (1f195fdf14b2691fcc487f9a474ab443) to be active.