AnglerEK - EITest

In this brief introduction I will try to cover what’s all about Exploit Kits in a simple way: an Exploit Kit is a set of software tools that are usually running in a web server that aim to enumerate vulnerabilities that clients accessing it may have. Once it determines them, it tries to exploit them to install any kind of malware. The exploitation objectives are usually the browsers themselves or third party software such as Java, Adobe Flash and Microsoft Silverlight.

The exploits used include a payload to download and execute malware such as ransomware ((Torrent|Crypto|CTB)Locker/Locky/CryptoWall)) or trojans aimed to steal credentials such as Bedep or Pony.

In order to have access to a Exploit Kit infrastructure, the most usual way is to rent it with the objective of distributing a specific piece of malware, leading to the concept of Exploit Kit as a Service, on which the author of the malware doesn’t need to follow any of the necessary steps to set up the entire infrastructure or even know anything about exploiting, because all this is on the actors behind the Exploit Kit.

One can have access to these kind of resources in underground forums, where every Exploit Kit has its own pricing depending on the coverage and the distribution time one may want.

Additionally, lots of Exploit Kits have control panels with indicators about exploited software, victim origin countries, malicious hosts with more infections done and so on.

Illustration 1 – BlackHole EK control panel

Angler - EITest

We will refer to campaign when we talk about the set of techniques used to distribute the malware. The differences between campaigns lie in the method used to redirect victims between compromised hosts and/or the malware dropped.

The previous illustration is about Angler’s EITest campaign, which can be distinguished because uses a unique URI path pattern in the first redirection and because the use of .tk ccTLDs us pretty common. This is an example of what an EITest URL looks like (which we cover in this post):

hxxp://badphone.tk/sdlvoidkiere/3cdoetpk3kf1r2cbri8bbc0mlst4lt/psnpeeo/aapasferbmnk/6s2pf1odse0kp8b2iro/endo4de2kam6a3pf3rl/index.php

The difference between the other Angler campaigns lies in the method used on the first redirection. While in previous campaigns obfuscated JavaScript code was widely used (being relatively simple to detect), in this one you have to get the Flash object it embeds in the first compromised host and then reverse ingeneer it and reimplement by hand the construction method used to build the JavaScript that will redirect the victim to the Landing Page. The diagram about this campaign looks like the following Illustration:

Illustration 2 - Angler’s EK / EITest infrastructure (source: Trend-Micro)

The actors behind the Exploit Kit compromise a web server (usually the victims are all vulnerable WordPress or Joomla) and inject malicious code in order to redirect visits, silently, to another compromised site. In our case:

  1. A user access to the compromised server.

  2. The user is redirected to a second server, which will download a SWF (Flash) compressed object, which then will generate JavaScript code that the browser will run. Such JavaScript code redirects the user to the Exploit Kit Landing Page creating an iframe element and appending it to the original HTML source code of the compromised site.

  3. Once in the Landing Page, the Exploit Kit will try to exploit vulnerable software through the browser, using Flash/Silverlight/Java embedded objects. The user can’t see the Landing Page because it is being loaded through a hidden iframe.

  4. If the exploitation succeeds, the download and execution of the payload is loaded. Usually, the malware downloads from a third URL with a different domain from the Gate and the Landing Page.

We may call a Gate to the server used as TDS (Traffic Direction System) that you can see on the previous illustration.

A real hit

In the next few lines we will explore a real hit of a user accessing a compromised site, leading to Angler’s EK EITest campaign, where I will try to detail the attributes and features of the Gate and the Landing Page. This case is dated on 04/12/2016, where I received a PCAP which contained all browsing traffic of a user for a limited time range.

First compromised server and initial redirection

In this PCAP file, if we filter it out to show only HTTP traffic, we can see some suspicious URLs that smell to Angler:

Illustration 3 - Suspicious browsing

So I proceeded to analyze the traffic with more detail. The first step was to get the response body for the first request to hxxp://www.dircom.org. According to the usual behavior in Angler, one may expect to find obfuscated JavaScript injected on the site’s HTML which would lead to the first redirection, but I found something a little different:

Illustration 4 - Embedded Flash object

Instead of Javascript, the injected code is an embedded Flash object. The object is requested on the following URL:

hxxp://badphone.tk/sdlvoidkiere/3cdoetpk3kf1r2cbri8bbc0mlst4lt/psnpeeo/aapasferbmnk/6s2pf1odse0kp8b2iro/endo4de2kam6a3pf3rl/

Once I downloaded the Flash object I began to rip it off.

Analysis of the first Flash object

From the previous request, we got the following object:

Illustration 5 - Request and response of the Flash object used to redirect

The attributes and the metadata about the object are the following:

Illustration 6 - Metadata of the downloaded Flash object

If we proceed to look inside, we can access the ActionScript scripts executed where the object is loaded. In this particular case, the class used as “entry point” was a script called App:

Illustration 7 - App.as3

We can see in the first lines of the App() function that the first it does is call another function called go(), which then calls da() several times and it also calls ur(), which is used as a parameter of the ej() function.

The dad() function returns several concatenated plain text strings. At a first glance, the final result looks like a plain text Base64 string.

The da() function takes a number as unique parameter, assigns the result of calling hr() with the result of dad() as a parameter to a variable and then assigns to a variable of type Array the result of splitting the first variable with $ character. Then it returns the content of the array index which is specified by the number taken as a parameter.

The hr() function takes as unique parameter a text string. As we saw before, that text string is a Base64 string. In the first place, it instantiates the search class. Then it decodes the Base64 encoded string and transforms it to a ByteArray. Finally, it calls the de() method of the search class with the previous ByteArray converted to string and the value of the f parameter corresponding to the HTTP request of the embedded Flash object. You can see the value in the FlashVars parameter corresponding to the embedded object in the HTML of the compromised site:

Illustration 8 - f parameter value

The search class consisted in the following:

Illustration 9 - search.as3

The most important method of the search class is de(), which takes two parameters: a string and a number. This method executes several operations for each and every character of the string it takes as a parameter. More specifically, converts to ASCII the value of each character and it converts it again to hexadecimal and substracts the value of the second parameter from it (in this case, the method was called using the value of the f parameter seen before). The method ur() simply returns the URL where the Flash object was loaded.

So with all this in mind, the strings one could get from calling the da() method of the App class are the following:

Illustration 10 - Strings obtained from calling App.da()

The method ej() from the search class is responsible to call the Call method from the ExternalInterface class. This class allows communication between ActionScript and the SWF container. In this case the container was HTML, so by using this Call method it seems that is possible to execute JavaScript on the browser.

Illustration 11 - search.ej()

This method needs two parameters, which will be used to call ExternalInterface.Call(). The two parameters are a function name and its arguments. So following the go() method in the App class:

Illustration 12 - App.go()

And having the result of calling da() and ur(), what it gets executed throuhg ExternalInterface.Call() is ExternalInterface.Call(setTimeout(...), eval).

Illustration 13 - Final call to ExternalInterface.call(setTimeout(...), eval)

So once the Flash object is loaded, it redirects us to the following URL:

hxxp://badphone.tk/sdlvoidkiere/3cdoetpk3kf1r2cbri8bbc0mlst4lt/psnpeeo/aapasferbmnk/6s2pf1odse0kp8b2iro/endo4de2kam6a3pf3rl/index.php

Landing Page

The contents of the GET request to the previous URL is the following:

Illustration 14 - Redirection to the Landing Page

In that request we can see that the Referer HTTP Header still aims to hxxp://www.dircom.org. If we look closer to the response, we will see that the server is returning HTML on which the new redirection appers twice:

  • Using an HTTP meta element with http-equiv attribute pointing to refresh, the content attribute set to 0 and the new URL. Such element will cause an immediate redirection.

  • Using JavaScript, it calls document.location.href to redirect the user to the same URL.

If we follow the request, we will find the Angler’s Landing Page. Its code alternates between non-sense text and HTML tags without any order and obfuscated JavaScript and text blocks. Here is a sample:

Illustration 15 - Landing Page obfuscated JavaScript

With a closer look at the JavaScript code we can locate the function used to decrypt encrypted elements in the Landing Page:

Illustration 16 - Decrypt function on the Landing Page

With the Landing Page in the DOM, we can use this function in order to get the values we’re interested in. The encrypted strings are the following:

Illustration 17 - Encrypted strings in the Landing Page

Those strings can be decrypted using the previous function. The result is the following:

Illustration 18 - Decrypted strings

Using a little script in Python with Selenium and PhantomJS I was able to get the HTML for the Flash and Silverlight embedded objects and the HTTP Headers it will use to make the request. All of it was obtained using the decrypt function we saw:

Ilustración 19 – HTTP Headers and Flash/Silverlight embedded objects

Environment checks and software enumeration

The actors behind Angler perform several checks in order to detect security products installed on the victim’s computer and also to check if it’s running on a virtual environment:

Illustration 20 - Browser security tools checks

In the previous illustration we can see how the execution flow ends if the browser is not Internet Explorer, so the next lines only apply to Internet Explorer and won’t be valid on other browsers such as Mozilla Firefox or Google Chrome due its sandboxed nature. Once it performs the browser check, it tries to find out if IE’s developer tools are enabled and also checks for Kaspersky’s Internet Security Virtual Keyboard.

After all those checks, it follows an interesting approach in order to check if several security tools are installed in the computer. First, it defines an array variable and puts inside several obfuscated strings. Then iterates on the array, passing every element as a parameter to the function uIkesd_pf():

Illustration 21 - An array of obfuscated strings

We can see that the function uIkesd_pf() takes two parameters and calls uIkesd(), concatenating two additional strings to the parameters received.

Illustration 22 - uIkesd_pf() detail

The value of x1 and x2 variables are %PROGRAMFILES% and %PROGRAMFILES(x86)% respectively:

Illustration 23 - x1 and x2 values

At last, uIkesd() instantiates the Image class (<img> HTML tag), which has its src attribute aiming at the result of executing xText() with the obfuscated text string. In order to embed the <img> tags on the HTML, it locates the first q element on the Landing Page and it runs appendChild on it, so every new <img> tag will be inside that element. What xText() does is to deobfuscate every obfuscated string it receives as parameter:

Illustration 24 - xText() and uIkesd() details

If we manually replicate all the process, we can see the deobfuscated strings:

Resource Type Identifier
res://C:\Program Files (x86)\VMware\VMware Tools\TPAutoConnSvc.exe 2 26567
res://C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe 2 26567
res://C:\Program Files (x86)\Fiddler2\Fiddler.exe 3 32512
res://C:\Program Files\Fiddler2\Fiddler.exe 3 32512
res://C:\Program Files (x86)\VMware\VMware Tools\TPAutoConnSvc.exe 2 30996
res://C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe 2 30996
res://C:\Program Files (x86)\Oracle\VirtualBox Guest Additions\uninst.exe 2 110
res://C:\Program Files\Oracle\VirtualBox Guest Additions\uninst.exe 2 110
res://C:\Program Files (x86)\Parallels\Parallels Tools\Applications\setup_nativelook.exe 2 204
res://C:\Program Files\Parallels\Parallels Tools\Applications\setup_nativelook.exe 2 204
res://C:\Program Files (x86)\Malwarebytes Anti-Malware\mbamext.dll 2 202
res://C:\Program Files\Malwarebytes Anti-Malware\mbamext.dll 2 202
res://C:\Program Files (x86)\Malwarebytes Anti-Malware\unins000.exe 2 DISKIMAGE
res://C:\Program Files\Malwarebytes Anti-Malware\unins000.exe 2 DISKIMAGE
res://C:\Program Files (x86)\Malwarebytes Anti-Exploit\unins000.exe 2 DISKIMAGE
res://C:\Program Files\Malwarebytes Anti-Exploit\unins000.exe 2 DISKIMAGE
res://C:\Program Files (x86)\Trend Micro\Titanium\TmConfig.dll 2 30994
res://C:\Program Files\Trend Micro\Titanium\TmConfig.dll 2 30994
res://C:\Program Files (x86)\Trend Micro\Titanium\TmSystemChecking.dll 2 30994
res://C:\Program Files\Trend Micro\Titanium\TmSystemChecking.dll 2 30994
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Windows Workstations\shellex.dll 2 102
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Windows Workstations\shellex.dll 2 102
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 6.0\shellex.dll 2 102
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 6.0\shellex.dll 2 102
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 7.0\shellex.dll 2 102
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 7.0\shellex.dll 2 102
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 2009\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 2009\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 2010\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 2010\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 2011\avzkrnl.dll 2 BBALL
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 2011\avzkrnl.dll 2 BBALL
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 2012\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 2012\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 2013\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 2013\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Anti-Virus 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 6.0\shellex.dll 2 102
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 6.0\shellex.dll 2 102
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 7.0\shellex.dll 2 102
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 7.0\shellex.dll 2 102
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 2009\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2009\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 2010\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2010\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 2011\avzkrnl.dll 2 BBALL
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2011\avzkrnl.dll 2 BBALL
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 2012\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2012\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 2013\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 2013\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Internet Security 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Internet Security 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Total Security 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Total Security 14.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Total Security 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Total Security 15.0.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Total Security 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Total Security 15.0.1\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky Total Security 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky Total Security 15.0.2\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 2.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky PURE 2.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE 3.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky PURE 3.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky CRYSTAL 3.0\x86\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky CRYSTAL 3.0\x86\mfc42.dll 2 26567
res://C:\Program Files (x86)\Kaspersky Lab\Kaspersky PURE\mfc42.dll 2 26567
res://C:\Program Files\Kaspersky Lab\Kaspersky PURE\mfc42.dll 2 26567

Table 1 - Resources accessed by the Landing Page using res:// URI handler

It uses Microsoft’s res:// protocol as URI handler. Such protocol is used to access specific elements of the resources section of a PE file (dll/exe/ocx). The URI format is as follows:

res://<FILEPATH>#<ELEMENT_TYPE>#<ID/ELEMENT_NAME>

As a quick check, in order to access the Windows Genuine image of calc.exe resources section (Win 7), the path we should follow is:

res://c:\Windows\system32\calc.exe/#2/#51209

Which converted to HTML code is equal to the following:

<IMG src="res://C:\Windows\System32\calc.exe/#2/#51209">

Which rendered to an HTML table, we get this:

Illustration 25 - calc.exe BITMAP resource with ID 51298

This is a fairly common technique to run software enumeration through the browser and it has been widely used for almost 10 years. In this specific case, Angler uses the onload event to check if the image is being loaded with the result of setQuery() and setDatabase() functions. In case the resource is loaded successfully, the execution of the JavaScript stops.

In order to be able to view all it checks, you can check the previous table which contains every element the Landing Page tries to load. In the next screenshot we can see how it detects VirtualBox Guest Tools when we open the Landing Page on a VirtualBox VM:

Illustration 26 - VirtualBox Guest Tools detection

The resource types it tries to load are pics. The 2 refers to RT_BITMAP resources, and type 3 refers to RT_ICON resources.

Exploitation

During the exploitation phase, the Landing Page loads a second embedded Flash object with the parameters we’ve previously seen:

Illustration 27 - Embedded Flash object HTML

The request URL is the following:

URL:

hxxp://blushing.findgutterhelmet.com/

URI path:

v=-znJ&d=0Tb7c02J&g=miQ&t=nUa2\_f&m=AriD&j=EJgrozr&x=xeZF6X7b&a=W7yyvIn&p=P

Moreover, several parameters are passed to the Flash object using the FlashVars attribute. This object follows the same pattern we saw on the other Flash objects. It consists of a binary object in binaryData which gets converted to a ByteArray and a XOR function applied to every single byte of the ByteArray. In this case, every byte is XORed with 0x93:

Illustration 28 - XOR function

With some scripting we can obtain the decrypted Flash object:

Illustration 29 - Extracting the Flash object within the Flash object

The problem is that the file we get is not a valid Flash file. If we take a closer look, we can see that the first 7 bytes of the file can be omitted:

Illustration 30 - Flash file header

Once we cut off the first 7 bytes, we can work with the file. We will find that it is more obfuscated than the previous ones:

Illustration 31 - Obfuscated ActionScript

However, we can deobfuscate it enough to be able to follow the execution flow in order to identify key functions such as the following:

Illustration 32 - Deobfuscated ActionScript

The 3 functions are used to manipulate the binary data contained in several binaryData objects, converting them to ByteArrays:

Illustration 33 - Content of one of the binaryData objects

Evaluating the ActionScript code, we can see that it dinamycally loads the previous byteArrays and performs several operations that include, but are not limited to the following:

  1. 2 XOR encryption functions with a dynamic key. Such key is retrieved from the result of several operations on every byteArray.

  2. About the final byteArrays: they seem to be built in 16 byte blocks and sequential sized blocks, iterating over one of the byteArray objects. The index where the data is being saved is obtained from the remainder of dividing the actual array index with the size of the other byteArrays. Before writing the data in the corresponding index, a first XOR encryption is made, where the key equals the result of calling readInt() over one of the byteArrays.

Looking at the common Angler behavior, those byteArrays contain the payload with the shellcode used to exploit the Flash vulnerabilities. It seems that the binary data is encrypted using RC4, but I’m still working on the static analysis of the file in order to get the shellcode and determine the exploited vulnerabilities.

Dropped files

I couldn’t get the shellcode used in the Flash exploits (yet), so I followed a dynamic analysis approach, emulating the Landing Page on a webserver and using a VM with Flash Player 18.0.0.232 and Internet Explorer 7 and 8. The steps I followed were the following:

  1. Creation of an HTML file with the embedded Flash object, modifying its attributes so all the requests were made to a local webserver.

  2. Open the HTML file with IE7/IE8.

  3. Full memory dump after accessing the emulated Landing Page.

  4. Using volatility, perform a memory dump of the memory being used by the Flash ActiveX plugin binary for Internet Explorer (pid 3144):

Illustration 34 - Flash plugin binary identification

  1. Create a Yara rule for potentially malicious URL and perform a search on the process memory dump.

Illustration 35 - Malicious URL identification

The only suspicious URL I could obtain was the following:

hxxp://maisespanhol.com.br/1/8y7h8bv6f

Such URL wasn’t available during this analysis. Howevevr, I could find some references to it. It seems that this URL was delivering Locky:

It was active in March and the first half of April.

Unfortunately, I could not find any traces of the Silverlight object, so I couldn’t analyze it.

IOCs

Indicator Type Description
badphone.tk domain Gate
blushing.findgutterhelmet.com domain Landing page
hxxp://maisespanhol.com.br/1/8y7h8bv6f url Download URL for Locky
e8f8f04614169707872f2700d6a3ef8764c412b950ad867365604224960b0d6d sha256 SHA256 Flash Object - Redirection
8b8e2875b82661b06f54ad118035d558cd6f92949d928b688e0d72021636116e sha256 SHA256 Flash Object - Exploits

:wq!

comments powered by Disqus