Wednesday, 12 June 2013

Zuponcic: "Is it a bird?... Is it a plane?... No, it's another Exploit Kit" --- Part 1

Updated 2013-08-19: Number of changes to reflect the findings covered in Part 2.

Zuponcic is relatively rare malware delivery kit. The name was given after the website( the kit was detected on back in November 2012. Earliest mentioning of it on Emerging Sigs mailing list. I first encountered it in July 2012 hosted on '' The kit has been slightly updated since.

NOTE: Information is based on a sample captured on 2013-06-10.

"In thrust we trust."

The journey starts with a couple of redirects before arriving at the website hosting the landing page and the malicious JAR file.

1st level redirect

GET request

After clicking on one of the links delivered by Google Search when looking for 'mansfield township nj', the browser was taken to ''.

first redirect

First redirect goes to a server hosting TDS(Traffic Distribution System) - ''. TDS is given a number of parameters and one of them is the website name the browser arrived from - ''. TDS more likely maintains a list of domain names allowed to use the service - protection mechanism in some way.

2nd level redirect

GET request

Referrer is still Google even though the browser was redirected to TDS host from ''

second redirect

Once TDS is satisfied with all of the parameters given and possibly other conditions(cookie, sessionID, etc), the browser is redirected to a website hosting the landing page and the malicious JAR file.

landing page GET

The browser arrived at the landing page and is still having Google as a referrer with the original search request details in the URL.

June 2013 sample has the following URL pattern:

The URL pattern for a sample seen in July 2012:

There are no GET requests for '.mt' and '/js/java.js'  files in June 2013 sample, but the landing page still has commented out code related to them.

'.mt' file request

Even though the code is commented out the '.mt' file URL has 'live' domain name in it - 'on the fly' generated I guess.

'java.js' file request

"Home! Sweet Home!"

Landing page requests the JAR file without performing any checks - <body> tag with 'onLoad' action calls a function that requests the file. There is only one '.class' file in the JAR - 'FlashPlayer.class' and it's 'doctored' with a bytecode obfuscation tool. JAR file is signed with 'Kurz Instruments, Inc.' certificate issued by 'GlobalSign' CA.

<applet> requesting the JAR file

 JAR signature

 Looks like the previous version of the kit used to check Java version. There is some 'leftover' code still on the page.

The landing page is armed with a couple more tricks. There is a hidden(0 by 0 pixels) <form> with an <img> tag that has an 'onClick' action.

The action will call a function that checks if Java is enabled in the browser. If not found it will 'submit' the <form> initiating a POST request.

POST request will be generated using two 'hidden' input values. One of the values contains an executable file name 'viewer_mansfield_township.exe'. In response, the server will send unprotected payload giving it this name. Note the name has two search keywords in it that were used in the original Google Search request(refer to 1st level redirect section). Looks like the landing page is being dynamically generated based on the details given to TDS during 2nd level redirect.

Another example. The search criteria in this case was 'perfume worldwide'.

'viewer', 'movie' and 'tool' seem to be 'padding' words for creating the filenames.

The second trick is 'onContextMenu' action. Right-clicking on the landing page will restart the redirect chain with a GET to the first website in it. This will also trigger 'onBeforeUnload' action that prompts user to confirm leaving the page while displaying a message. Which might be a bit embarrassing if you misspell it.

The landing page also has <title> tag that has the name of the website the redirects started from. Poor attempt to disguise I guess.

"Please wait! Zuponcic is lading.."

Quick summary:
  • has quite unique URL pattern
  • utilizes TDS to help prevent direct download of the exploit kit components
  • uses Java as a malware delivery method
  • JAR is signed with a valid certificate
  • attempts to trick user to download and execute the Initial Payload if no Java detected
See part 2 for JAR file analysis.

P.S. If you have any additional information on this exploit kit please share. Contact details can be found under Blogger profile.

No comments:

Post a Comment