Interactive redirection to an exploit kit

Exploit kits are used by hackers to automatically install malicious code on a user's computer. In order for the user to be on the “landing page” itself (landing page), which will select the desired type of exploit that corresponds to the user's browser environment, it must be redirected to it. This redirection may occur from legitimate websites that have been compromised by malicious content (javascript or iframe).



Thus, the usual scenario of using exploit kits by attackers is to compromise a legitimate web resource from which the user is redirected to malicious content. This week we are faced with an interesting variation on how the user is redirected to the page of one of the exploit kits. On the compromised web page, we found malicious code that can interact with the user, displaying a fake message about the browser’s work.
')

Fig. Fake message generated by malicious code.

The code that is responsible for user interaction through such a message is executed in the form of an HTML form embedded in a web page. The window is displayed only when the user views the page in Internet Explorer. We also noticed that this form sends some data to the server in a POST request.


Fig. Malicious content embedded in a webpage.

Regardless of which answer option the user chooses (Cancel or OK), he will be redirected to the Angler exploit kit exploit page. To perform a redirect, a POST request specified in the screenshot will be sent via the form, which will return a small fragment of HTML and JavaScript code. This code will redirect to the final URL.


Fig. URL of the intermediate webpage.


Fig. Complete chain of redirects and end exploitation.

Now back to the data that is sent in the POST request. It can be seen that they are encoded in Base64 format. Below is their transcript.

The original string.

ua_base64 =
"TlP7Vt89hmr1vjdAW8YqmDT / sGFiyxROsPBX45R6HxinEeZC + YGrgEA0mmA3NDEJUYzgWm29EKShU2QPqxBXzVNMJvpfJN3Q
cVGGehPCNNXOlxo0JE94z0RTBgCq0VubolrWHmAexV14 + cqx6qILC6z1EZDl4JFYd32wrMZrhNinl47lzpnvXwPluNsmh0CA »

Decoded string

base64.b64decode (ua_base64) =
"\ xb6S \ xfbV \ xdf = \ x86j \ xf5 \ xbe7 @ [\ xc6 * \ x984 \ xff \ xb0ab \ xcb \ x14N \ xb0 \ xf0W \ xe3 \ x94z \ x1f \ x18 \ xa7 \ x11 \ xe6B \ xf9 \ x81 \ xab \ x80 @ 4 \ x9a`741 \
tQ \ x8c \ xe0Zm \ xbd \ x10 \ xa4 \ xa1Sd \ x0f \ xab \ x10W \ xcdSL & \ xfa _ $ \ xdd \ xc24 \ xd5 \ xc \ xc \ xc \ xc \ x97 \ xd \ xd \ xx \ xc \ xd \ xc \ xc \ xd \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xc \ xd \ \ xaa \ xd1 [
\ x9b \ xa2Z \ xd6 \ x1e` \ x1e \ xc5] x \ xf9 \ xca \ xb1 \ xea \ xa2 \ x0b \ x0b \ xac \ xf5 \ x11 \ x90 \ xe5 \ xe0 \ x91Xw \ xb0 \ xac \ xc6k \ x84 \ xd8 \ xa7 \ x97 \ x8e \ xe5 \ xce \ x99
\ xef_ \ x03 \ xe5 \ xb8 \ xdb & \ x87 @ \ x80 "

By the name of the parameter “ua”, one can guess that this data is the encrypted User-Agent string used by the browser user. In our example, it looks like this.

Mozilla / 4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident / 4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET4.0C; .NET4.0E; BOIE8; ENUSMSCOM).

It can be assumed that the parameters specified in the HTML code of the form (see the screenshot above) are encrypted using XOR using the same keystream. To do this, you can apply the XOR operation to the decoded via base64 string, which contains the User-Agent c keystream in the form of the User-Agent string already known to us (translated into lower case). We can use the resulting value as a keystream to decrypt the furl parameter (see the screenshot above). As a result of this operation, we get the original URL of the exploit kit web page. To do this, you can use the following code in Python.

import base64
def xor (message, key):
decrypted = ""
for i in range (0, len (message)):
decrypted + = chr (ord (message [i]) ^ ord (key [i% len (key)]))
return (decrypted)

ua = “Mozilla / 4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident / 4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET4.0C; .NET4.0E; BOIE8; ENUSMSCOM)”
ua_plaintext = ua.lower ()
ua_base64 = "tlP7Vt89hmr1vjdAW8YqmDT / sGFiyxROsPBX45R6HxinEeZC + YGrgEA0mmA3NDEJUYzgWm29EKShU2QPqxBXzVNMJvpfJN3QcVGGehPCNNXOlxo0JE94z0RTBgCq0VubolrWHmAexV14 + cqx6qILC6z1EZDl4JFYd32wrMZrhNinl47lzpnvXwPluNsmh0CA"
furl_base64 = “s0j1T4l + yCai5DANXd0gmz38sX5pwRVb / vhQpcU9Qlj8G6tQ5Nc =”
keystream = xor (base64.b64decode (ua_base64), ua_plaintext)
print “Decrypted furl:”
print (xor (base64.b64decode (furl_base64), keystream))

$ python angler-dexor.py

Decrypted furl parameter:
hxxp: //cct7m.xenybuvifd.net/4genk1met8

The cybercrime practice of interactivity (user interaction), when performing a redirection operation, is designed to avoid detection of the final URL of the payload by the automatic analysis systems.

Malicious code that is installed on a computer using this set of exploits is detected by ESET antivirus products as Win32 / PSW.Papras.CX .