Today we are going to start a new series of blog posts called “Malware tales”: the intent is to go deep on code-level analysis of most widespread malware to allow everyone to get a better picture of everyday cyber threats. Also, we’d like to demystify malware and show that we are just talking about a bunch of code


  1. The Threat
  2. Payload delivery
  3. Gootkit executable
  4. Stage 1: Packed Gootkit
  5. Stage 2: Gaining a foothold
  6. Stage 3: Check-in phase
  7. Last stage
  8. Additional findings
  9. Conclusions

The Threat:

Gootkit belongs to the category of Infostealers and Bankers therefore it aims to steal information available on infected machines and to hijack bank accounts to perform unwanted transactions.

It has been around at least since 2014 and it seems being actively distributed in many countries, including Italy.

Previous reports about this threat can be found following this link:Malpedia

Today we are going to dive into the analysis of a particular variant that came up the last week.

Payload Delivery:

The infection vector is an email written in Italian. In this case adversaries used one of the most common social engineering techniques to trigger the user to open the attachment.

The downloaded file is a heavily obfuscated Javascript file called "GLS_Notifica.js". If the user opens it, the native Javascript interpreter wscript.exe would be executed by default and it would perform the following HTTP request:

The result is the download of a cabinet file that is an archive file which can be extracted natively by Windows. Inside there is a Portable Executable file that is saved into the %TEMP% folder (“C:\Users\<username>\AppData\Local\Temp”) and launched.

Javascripts downloaders are a common payload delivery because a little obfuscation can be enough to make them very difficult to be detected by antivirus engines.

Gootkit executable:

First run of the sample in an automated environment revealed that something new was added in this version. As we can see in the following images, malware authors added a new layer of protection to the malicious agent. The comparison has been made with a variant spread during December of 2018 in Italy. (images are from AnyRun)

This means that the original program was “packed” with the aim to slow down reverse engineers and to make ineffective static analysis tools like Yara rules.

Stage 1: Packed Gootkit

In such cases, a malware analyst knows that he has to extract the original payload as fast as possible without losing time to try to understand the inner workings of this stage.

A great open-source tool exists which can resolve the problem in a matter of seconds. It’s called PE-Sieve (Github). Even though it does not always work, in this case it can dump the unmapped version of the original executable because the malicious software uses a technique called Process Hollowing a.k.a. RunPE. This method consists in starting a new process in a suspended state, “hollowing” out the content of the process, replacing it with malicious code and, finally, resuming the thread.

In the image we can see that the 6th parameter of "CreateProcessW" was set to "4", indicating that the process will start in a suspended state.

We are talking about a well known technique that is easily detectable with the monitoring of the Windows API calls that are needed to perform the injection. But here comes the trick.

Following the flow of execution we couldn’t find all the needed API calls: we got NtCreateProcess, NtGetContextThread, NtReadVirtualMemory and NtSetContextThread.

The most important ones that are used by monitoring applications to detect the technique were missing:

  • NtUnmapViewOfSection to “hollow” the target process
  • NtWriteVirtualMemory to write into the target process
  • NtResumeThread to resume the suspended thread

Let’s find out what’s happening!

After some shellcode injections inside its memory space, the process executes a call to IsWow64Process API that is used by the application to understand if the process is running under the WOW64 environment (Wiki): this is a subsystem of the Windows OS that is able to run 32-bit applications, like this one, on 64-bit operating systems.

The result of this check is used to run two different paths of code but with the same scope: run one of the aforementioned missing API calls in the Kernel mode. This means that, in this way, classic user-level monitoring tools would not catch these calls and the RunPE technique would remain unnoticed.

Specifically, in case the process is running in a 32-bit environment, it would use the SYSENTER command to switch into the Kernel mode, while, on the contrary, it would use the SYSCALL command to perform the same operation.

To complicate even further, the SYSCALL command can’t be called in the context of a 32-bit application. This means that the executable needs to perform a “trick-into-the-trick” to execute this operation. We are talking about a technique known as The Heaven’s Gate.

Practically, thanks to the RETF instruction, it’s possible to change the code segment (CS) from 0x23 to 0x33, de facto enabling 64-bit mode on the running process.

In the following image we highlight the entrance and the exit of the “Gate” which contains the 64-bit code that performs the SYSCALL operation.

Instead, in this other image, we can see the process status before opening the gate (grey=suspended process) and after having closed it (orange=running process).

Also, Gootkit takes advantage of The Heaven’s Gate as an anti-debugging technique because the majority of commonly used debuggers can’t properly handle this situation, not allowing the analyst to follow the code of the Gate step-by-step.

For further details, this method was deeply explained in this blog (MalwareBytes)

Going back to the point, the first stage resulted more complicated than expected because it pushed over the limits of obfuscation and stealthiness with the combination of various techniques.

Stage 2: Gaining a foothold

At this point we can proceed with the analysis of the unpacked Gootkit.

The very first considerable finding was the check for the existence of a mutex object named “ServiceEntryPointThread”. If it exists, the process would terminate itself.

But how mutexes works? Mutexes are used as a locking mechanism to serialize access to a resource on the system. Malware sometimes uses it as an “infection marker” to avoid to infect the same machine twice. The fascinating thing about mutexes is that they are a double-edged weapon: security analysts could install the mutex in advance to vaccinate endpoints. (ref: Zeltser blog)

This means that this is a great indicator of compromise that we can use not only to detect the infection but also to prevent it.

Moving on, we found that malware authors implemented a lot of checks to understand if the malware is running inside a virtual environment. Some of them are:

  • It checks if the registry key “HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString” contains the word “Xeon”

  • it checks if the computer name is “7SILVIA” or “SANDBOX”, if the username is “CurrentUser” or “Sandbox” or if “sbiedll.dll” has been loaded.

  • it checks if “HKLM\HARDWARE\Description\System\VideoBiosVersion” contains the word “VirtualBox”

  • it checks “HKLM\Software\Microsoft\Windows\CurrentVersion\SystemBiosVersion” for the string “VBOX”

In the case one of this check fails, the program would execute a Sleep operation in a infinite cycle in the attempt to thwart automated sandbox execution.

After that, we encountered the implementation of a particular persistence mechanism that it seems Gootkit has been using for many months: it’s already documented in various blog posts, for ex. ReaQta blog.

Briefly, the infostealer generates a INF file with the same filename of itself.

Content of the INF file:

Then it creates 3 different registry keys (“Count”, “Path1” and “Section1”) inside “HKCU\Software\Microsoft\IEAK\GroupPolicy\PendingGPOs” with the purpose to allow the threat to execute on reboot.

It seems that this technique was reported to be used only by Gootkit.

Famous security tools still can’t detect this mechanism even if it has been used for months.

For example, the famous SysInternal Autoruns tool, that should be able to show all the programs that are configured to run on system bootup or login, fails the detection of this persistence method.

Stepping through the code, we noticed that, at runtime, Gootkit decrypts the strings it uses with a custom algorithm to evade static analysis detection of anomalous behaviour.

It’s a combination of “stack strings”, XOR commands and the modulo operation.

An exhaustive explanation of the decryption routine can be found here:link

Skipping further, eventually there’s a call to “CreateProcessW” to start a new instance of Gootkit with the following parameter: --vwxyz

Stage 3: Check-in phase

Quickly we found out that executing the malware with the cited parameter allows us to skip all the previous anti-analysis controls to get into the part of the code that starts to contact the Command & Control Server.

The first check-in to home is done to the following URL via HTTPS:

As we can see from the image, many headers were added to the request to send different informations of the infected machine to the C&C Server.

In particular one of the headers caught my attention: “ X-IsTrustedComp”. Digging into the code we found that the value would be set to “1” if an environment variable called “crackmeololo” was found in the host, “0” otherwise.

That seems another “escaping” mechanism implementing by the author, probably to stop the infection chain for his own debugging purposes.

Last stage:

The response that arrives from the previous connection contains the final stage of Gootkit, configured to work properly on the infected machine.

The malware dynamically loaded “RtlDecompressBuffer” call to use it to decompress the payload; then, it injected into an area of the current process memory.

Afterwards the flow of execution is transferred to the start of the injected code.

The final payload is a DLL file that is bigger than 5MB because it contains the Node.js engine which is probably needed to run some embedded javascript files. At this time we decided to stop our analysis and leave the rest to future work.

Additional findings:

While debugging, we noticed that Gootkit does not check only if a parameter called “ --vwxyz” was passed to the command line. Also it checks if other 3 parameters:

  • --reinstall

  • --service

  • -test

Pretty strange thing. We haven’t found the malware to actively use these arguments yet. However, stepping through code we discovered that:

1 - the “--reinstall” command leaded the execution to some curious code. First, the malware used “CreateToolHelp32Snapshot” to retrieve a list of the current running processes.

Then, it iterated through the retrieved list via “ Process32FirstW” and “Process32NextW” with the aim to get a handle to the active “explorer.exe” instance.

At this point it killed “explorer.exe”. The following image shows the process list before the “TerminateProcess” command.

After having executed that command, we found that a new instance of the malware spawned as a child of “explorer.exe”.

What happened? We performed some tests and it seems that “ explorer.exe” was killed and then automatically restarted by “winlogon.exe”. Therefore “explorer.exe” accessed the keys involved in the persistence mechanism previously explained:

Using this trick, the malware is able to “reinstall” itself, without the need to use suspicious API calls like “ CreateProcessW”.

2 - the “ --service” command did not change the flow of execution with the exception of creating a new environment variable called “USERNAME_REQUIRED” and set it to “TRUE”.

Eventually we found that the final stage checks if the aforementioned variable exists.

3 - the “ -test” command just terminate the process. Indeed it’s a test.


We explored some of the functionalities of one of the most widespread Infostealers of these days, revealing new and old tricks that is using to remain undetected as much time as possible.

Certego is actively monitoring every day threats to improve our detection and response methods, continuously increasing the effectiveness of the incident response workflow.

PS: Let us know if you liked this story and feel free to tell us how we can improve it!


gootkit 1st stage
gootkit 2nd stage
gootkit DLL module

About the author:

Matteo Lodi, Cyber Threat Intelligence Team Leader


Licenza Creative Commons
Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 4.0 Internazionale.

Hi everyone, here is Matteo Lodi, Threat Intelligence Analyst in Certego.

Recently, we saw a particular new spam campaign targeting italian users with the focus of delivering a downloader known as Sload.

Nowadays, attackers are trying harder and harder to make difficult the analysis and the detection. The most common tool misused in this way is Powershell: it's installed by default in every recent version of Windows and is commonly used to perform administrator tasks.

The infection chain

Let's dig in the infection chain:

1. A user receives an email with subject "<TARGET_COMPANY_NAME> Emissione fattura <random_number>" containing a reference to a fake invoice.

The user is tricked to click on the malicious link that points to a randomly generated domain hosted with HTTPS in 91.218[.]127.189. The following is an example:

2. Once downloaded, if the user opens the archive, it would find two files. The first one is a legit image, while the second one is a .lnk file. We have already seen the misuse of shortcut files with powershell to perform the download of malicious samples. But this time it seemed different: in fact, the .lnk points to the following command:

3. Where is the download? At first glance, that seemed very strange: what is the aim of this execution? After having analyzed the command, the trick was clear. The attackers wants to call "Invoke-Expression" command to run a string hidden inside the zip itself!! But where?

As we can see in the following image, at the end of the original downloaded zip file we can see readable strings that are the real first stage downloader!!

The zip file is still a legit and correctly working archive! Powershell commands are written after the EOCD (End of central directory) which determines the end of a zip file.

This clever trick can deceive many signatures-based detection tools.

4. The extracted command is the following:

5. The result is the download and the execution of another powershell script from a server hosted in 185.17[.]27.108. We saw different domains used but, in the last week, the Dropzone IP never changed. Also, we noted that the CnC server was blocking requests without the "Microsoft BITS/7.5" User-Agent to prevent unwanted download by non-infected machines.

This script was very well detected by antivirus engines as you can see in the following image!

How funny was I? Static analysis is completely useless in such cases.

Going forward, the malware drops the following items before deleting itself:

Therefore it registers a task called "AppRunLog" to maintain persistence

6. At the end, it calls the registered task. This will execute the dropped Visual Basic Script file that, in turn, will execute the dropped Powershell script:

This script parses arguments and it won't execute properly in case they are not what it expects. It needs the numbers from 1 to 16 as arguments because, in fact, they are the key to decrypt the last stage.

7. The final payload is decrypted from the "config.ini" file and is called with "Invoke-Expression". It's loaded directly in memory: this makes very difficult for antivirus products to detect the threat. At the moment, this execution method is widely known as "fileless" because, indeed, the malware is never written on disk.

The payload is the last (finally) powershell script: it is the real Sload downloader which performs various malicious steps that were already explained in details in the article written by Proofpoint.

In few words, Sload can:

  1. Load external binaries
  2. Take screenshots
  3. Update configuration and CnC servers
  4. List running processes
  5. Detect Outlook usage

The variant we spotted in the last week uses the following CnC domains, which resolve in the same IP used by the second downloader stage (185.17[.]27.108)

However, we expect that this configuration won't last long, because, as we said before, Sload is able to update his CnC servers at any time.


We had a fantastic journey that made us understand, hopefully, how powerful can be Powershell and how attackers are misusing this tool to evade analysis detection.

We analyzed 5 different powershell scripts and that was only the "downloader" phase of the infection.

In case of a successfull one, Sload was seen to download known malware like Ramnit, Gootkit, DarkVNC or Ursnif (reference: Proofpoint). At that stage the threat would be really important.

Certego is monitoring the campaign and it's updating its signatures to correctly detect possible infections.


First stage download: (many and changing fast)

Second stage download: (many and changing fast)

CnC servers: (stable through the last week)

Hash (sha256):

first stage

second stage


Certego Threat Intelligence platform is observing some SPAM campaigns which are using  .url files as first-stage downloader to spread malware and avoid anti-SPAM filters.

What are .url files?  This file type is usually used by Windows OS to save a web link, that it can be accessed easily by a simple click. These are normally licit files and harmless files, however they can be abused to create malicious links.

The particularity of these campaigns lies not only in the use of this particular type of file, but also in how these have been configured. In fact, all analyzed samples so far used particular URLs, in which the schema is not the well known and popular http (or https). Instead, file is used.

What does file schema do? Normally this schema is used to access local filesystem. It can also be used to explore remote ones: on Windows these are accessed via SMB protocol.

It seems just a new way to deliver malware using SMB.

How does this attack work? As in every SPAM campaign, the victim receives a mail which tells him that an important document is inside the attached ZIP archive.

Once ZIP content is extracted, the user faces what he belives a simple Windows' link (because it is really a link!).
After double-click it, the host tries to connect with remote server via SMB. Then a JScript is served which, once received, asks to be launched or saved.

JScript file is the second-stage downloader: it will contact an other remote server from which it will download a malicious executable file.
Till now, payload was a variant of Quant Loader malware, which aims getting persistence on the infected host and downloading others malware (third-stage downloader).

How can we protect ourself from this kind of attack?

As for every mail based attacks first defence line is made of anti-SPAM filters. However the main component remains users, cause without their intervention this kind of attacks wont succeed. Therefore, the main goal should be training the userbase on this phenomenon.

SPAM subjects

Emailing: <random>
Unpaid invoice [ID:<random>]
Bill No

Read more

Hi everyone, here’s Matteo Lodi, member of the Incident Response Team.

Today, we want to talk about a new threat we have just detected while analyzing the alerts generated by our platform.

Everthing started from the analysis of the following ET Signature ET TROJAN Windows executable base64 encoded.

At the first glance, it seemed that there were no executables downloaded.

That was quite strange. A deeper analysis showed that many hosts belonging to one of our customers downloaded a zip file from different domains but the same IP.

Here we are! We could guess that a new spam campaign has just started and many domains are being used to deliver a malware.

So, we started to analyze “Nuovo documento” to understand what kind of threat it is. Once uncompressed, we found inside a batch file called “Nuovo documento 2018.bat”.

The first two lines are the following:

Oh, let’s see what it is:

A poorly trained eye could have just said to himself: “Well that’s just an image, this batch is harmless”

But it wasn’t. In fact, the batch file was other 200 empty lines long and, at the end of it, there were the following statements:

So we found that it’s a downloader. It tries to get a fake php file that, indeed, it’s the base64 encoded executable reported by our platform.

We also noticed the CnC server has implemented a domain whitelist and it allows to download the malware only by the IPs it sent the phishing campaign. If someone tries to get the zip file connecting from other IPs, the site would return a xml empty page.

First VirusTotal analysis wasn’t really satisfying because there was no indication about the malware classification, enhancing our hypothesis about a new spreading threat:

Then, we sent the malware to our threat intelligence platform for further analysis.

External and internal feed couldn't identify with ease what kind of malware it is.

In fact, as already said, the threat is new: manual or automatic analysis didn't get a perfect indication. However, this kind of anti-VM and anti-debugging abilities could lead us to guess that it's an infostealer, probably a Ursnif variant.

Meanwhile, we alerted the customer: to contain the threat, we worked together to find the mail responsible of the infection. The mail was the following one:

So, as already seen in older phishing campaigns, users have to pay attention to emails with “pending invoice” or similar as subject and they haven’t to get tricked to click to the link provided after panicking about a fake unpaid bill.


We found a new spam campaign delivering an evasive infostealer, targeting at least Italian users





www.synchronr[.]com/jcsuyg?wkblw=142954 (Download)
cloudblueprintprogram[.]com/images4.php (Malware)


e1e4e1c8288a62c7f4acb9ba4b5d2a57 malware.exe (malware)
c7bfa2bb1a027d6179eaa5d48465fad3 images4.php (malware base64 encoded)
a09916eb46ff94a89f09a072100eb3eb Nuovo documento 2018.bat (dropper)

Our threat intelligence platform has been logging a huge spike in ruby http exploiting since yesterday (10 January) at 23:00.

The exploit has been trying to leverage a fairly old CVE (CVE-2013-0156) that allows remote code execution. The following public Emerging Threat signature cover the exploit:

alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"ET CURRENT_EVENTS Possible CVE-2013-0156 Ruby On Rails XML POST to Disallowed Type YAML"; flow:established,to_server; content:"POST"; http_method; content:"|0d 0a|Content-Type|3a 20|"; pcre:"/^(?:application\/(?:x-)?|text\/)xml/R"; content:" type="; http_client_body; nocase; fast_pattern; content:"yaml"; distance:0; nocase; http_client_body; pcre:"/<[^>]*\stype\s*=\s*([\x22\x27])yaml\1/Pi"; reference:url,!topic/rubyonrails-security/61bkgvnSGTQ; classtype:web-application-attack; sid:2016175; rev:3; metadata:created_at 2013_01_09, updated_at 2013_01_09;)

The attacker has been sending the following data through a POST request:

The attacker sends a base64 encoded payload inside a POST request in the hope that the ruby interpreter configured on the server will execute it. By unpacking the payload we obtained the following code:

This is a very simple bash script that adds a new entry in the crontab of the host. The cronjob is executed once per hour (notice the number 1: it means every first minute of every hour) and it downloads the file robots.txt via wget. The file is piped through bash, so most probably it’s a text file containing a shell script. By manually downloading it we can confirm our hypothesis. This is the file content:

The script checks if there is a a coinminer already in execution and, if not, it downloads the coinminer from hxxp://internetresearch[.]is/sshd (or sshd.i686), launching it afterwards. We found the coinminer used is the linux version of XMRIG Cpu Miner:


185.130.104[.]17 80 GET hxxp://internetresearch[.]is/robots.txt (Cronjob Bash script) 

185.130.104[.]17 80 GET hxxp://internetresearch[.]is/robots.txt (x86-64 XMRIG coinminer download) 

185.130.104[.]17 80 GET hxxp://internetresearch[.]is/robots.txt (i686 XMRIG coinminer download) 

185.130.104[.]17 80 GET http://internetresearch[.]is/robots.txt (Sending system Info in User Agent) 

XMRIG Executable:
MD5:  761f5cfd0a3cddb48c73bc341a4d07a9
FileSize: 723080 bytes

Hi everyone, here's Matteo Lodi, member of the Incident Response Team.

This time i want to talk about a new threat we detected randomly while analyzing the alerts generated by our platform.

Everything starts from the analysis of a little and alone level 2 ET signature called "ET PRO POLICY DNS Query to .onion proxy Domain (onion . casa)".

At the beginning, the only evidence we got from the traffic analysis are many DNS queries followed by 4 HTTPS contacts to the following weird domain: vvrhhhnaijyj6s2m[.]onion[.]casa

We found that is a proxy used to access to hidden services behind the renowned TOR network. In details, if we visit the site, we can find that the domain in question hosts a site which claim to sell a malware known as Qarallax.

Qarallax is a RAT (remote access tool) and infostealer. This malware was born from an open-source software known LaZagne. At this time, this artifact let an attacker to execute different kinds of operations inside the infected machine:

  • Catch mouse movements and clicks.
  • Catch keyboard inputs.
  • Record the output of the webcam and of the screen
  • Find and steal every kind of credential stored inside the machine.

There's a group called Quaverse which claim to be the R&D behind this threat, constantly working to evolve and upgrade the malware. Their objective is to sell the agent as a RaaS (RAT as a Service).

The file is a JAVA application that runs on operating systems with JAVA Runtime Environment (JRE) installed. It runs silently in the background without any indication to the user.

At this time, we had no evidence that the host that contacted the suspicious domain is infected, but we are strongly suggested to investigate further to understand if this is a real threat.

We tried to look for some intelligence feeds from the internet, looking if someone else has found some useful infos about the domain in question. At the beginning, we checked from Google, Twitter and Reverse but we didn't found anything. Then, checking VirusTotal, we found that they list the following URL as a malicious one: hxxps://vvrhhhnaijyj6s2m[.]onion[.]casa/storage/cryptOutput/0.92915600%201512026521.jar

Wow, only 3 hits and no sample uploaded to VT. However, at that time, we got an idea about what the SSL connections did: downloading a .jar file containing, with high probability, the malware.

Meanwhile, we contacted the client and, luckily, the host infected was a virtual machine that got reverted to a clean state and the AV Agent detected and stopped the execution of the malware.

Afterwards, the real questions were:

  • how did they get the malware?
  • was the attack targeted or opportunistic?

The day after, inside our spamtrap, we retrieved a sample called "IMG6587JPG..jar", identified as malicious (8.2/10 score) by our sandbox. The first thing where we put our attention was the traffic this sample generated towards the suspicious domain.

That's it! Probably we found the malware our client got and, luckily, it came from a normal email spam tricking the user to open a fake image containing the infostealer.

Fun fact was that only 4 AV engines detected it. After 4 hours, finally, some other antivirus products started to identify that threat as malicious (15).

We said that to our client who could find the email that was the infection vector and send it to us. The Qarallax variant was almost identical to the one we caught just some minutes before. The only thing that changed was the email body (different language, from english to italian) and the name of the sample: PAGAMENTO.jar. Even in this case, the first time we send the sample to VT, only few antivirus were able to identify it.


We detected some new similar samples. The malware capabilities are the same as before. The biggest difference is the proxy used to contact the C&C server: from onion[.]casa to onion[.]top. We want to underline that the threat is evolving day by day: every new sample we get to analyze is almost undetected by every kind of AV engine.


We found a new spam campaing delivering a RAT malware, nearly undetectable by IDS Signatures or AV engines.




RAT samples (MD5):


Certego, a VEM Sistemi Group company, specialized in providing managed computer security services and to contrast cybercrime, was again cited in the Gartner Report "Competitive Landscape: Threat Intelligence Services, Worldwide, 2017" as an example of Regional Player of Services (IT) for Industry and PA (security advisory services and government and industry-based threats).

Although most of the Threat Intelligence market players originate from the United States, local players are becoming more and more prominent, benefiting from growing international demand in this sector.

"We are proud that Gartner for the second time has listed Certego as a Regional Player in the report Competitive Landscape: Threat Intelligence Services, Worldwide, 2017, we think it’s a confirmation of our Adaptive Cyber Defense model," continues Gignaffini “we combine traditional detection prevention (Rapid Detection) and Incident Response Coordination, continually adapting our customers' defense strategies to significantly reduce the impact of attacks and constantly improve the effectiveness of security systems (Continuous Vulnerability Assessment)."

According to our experience, threat intelligence services are becoming become more and more central within corporate business plans, even if small-sized companies often struggle to understand the real exposure to Cyber Crime risks and the values of TI services.

Gartner clients can access the report on

Gartner, Competitive Landscape: Threat Intelligence Services, Worldwide, 2017, 26 July 2017
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Starting from May 2016, Certego Threat Intelligence platform has been detecting multiple viral spam campaigns using a new evasion technique. These attacks are able to hide malicious attachments inside a specific area of the MIME/Multipart structure and to avoid Content Filtering controls.

Certego has also verified that few of the most common email clients and Web Mail services, using a different way of rendering the MIME/Multipart structure, are able to identify and extract the attachment, resulting in a Malware Evasion technique that we called BadEpilogue.

Analysis of the evasion technique

The picture at the top of the page shows a snippet of the source of a malicious email message.

Rows from 53 to 57 contain the end of the HTML message, while the attachment is located within an area that RFC2046 defines as Epilogue of a MIME/Multipart message, right after the final boundary of the Multipart message located at line 59 ending with the double “-” character.

According to RFC 2046, the message’s epilogue should not contain any useful text and, in particular, it should be ignored by MIME-compliant software:

NOTE: These "preamble" and "epilogue" areas are generally not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways. However, rather than leaving the preamble area blank, many MIME implementations have found this to be a convenient place to insert an explanatory note for recipients who read the message with pre-MIME software, since such notes will be ignored by MIME-compliant software.

In the attack, right after the closing boundary of the MIME/Multipart message and at the beginning of the Epilogue area, there is a new boundary (see line 61) that starts another Multipart section containing the malicious attachment.

Certego verified that many libraries used in Antispam and Antivirus systems to extract and analyze email attachments are unable to detect files hidden in the Epilogue area. On the other hand, popular email clients such as Outlook, Thunderbird and Evolution and also Web Mail services are able to detect the attachment and to show it to the user resulting in a new malware evasion technique.

Responsible Disclosure Policy

Certego decided to report this evasion technique to the developers of the email clients impacted by BadEpilogue. At the same time, we informed the vendors of major Antispam systems so that some of their Content Filters are ignoring attachments hidden in the Epilogue area.

So, we reported the technique to Microsoft and Mozilla. Microsoft has just released a patch for their email client in their last Security Bulletin (CVE-2016-3366 in the security bulletin MS16-107) fixing the vulnerability.

Talking about Antispam systems, Certego contacted Google and TrendMicro: both vendors confirmed the existence of the problem and promptly released a fix for it.

Detecting BadEpilogue using a SNORT signature

Certego also created the following Snort signature, that should detect all incoming SMTP messages exploiting the BadEpilogue evasion technique.

alert tcp any any -> $HOME_NET [25,587] (msg:"CERTEGO CURRENT_EVENTS Incoming SMTP Message with Possibly Malicious MIME Epilogue 2016-05-13 (BadEpilogue)"; flow:to_server,established; content:"|0d 0a|Content-Type|3a 20|multipart|2f|mixed|3b|"; pcre:"/\x0d\x0a--(?P<boundary>[\x20\x27-\x29\x2b-\x2f0-9\x3a\x3d\x3fA-Z\x5fa-z]{1,70})--(?:\x0d\x0a(?!--|\x2e|RSET).*)*\x0d\x0a--(?P=boundary)\x0d\x0a/"; reference:url,; classtype:bad-unknown; sid:9000501; rev:3;)

The campaigns

As mentioned, this evasion technique has been detected in the wild since May 2016, in at least eleven different campaigns exclusively targeting Italian users. These campaigns use messages written in a fluent Italian asking the user to open an attachment labeled as invoice or payment receipt. The attachment is in ZIP format and it contains a malware in PE EXE format. This attack pattern is typical of the so-called Viral Spam that has been prevalent until a few months ago, but it has now been deemed ineffective by antispam filters blocking ZIP files containing PE EXE. In this case, the BadEpilogue evasion technique allows the attacker to generate extremely effective campaigns that can reach a very high number of targets.

While the first campaigns were spreading a malicious attachment containing a Trojan Downloader of the Fareit family which downloaded a variant of the Andromeda Infostealer, the latest campaigns have started working mainly with ransomware and in the last few days we have observed a massive amount of emails containing Zlader.

The following picture shows the various campaigns using the BadEpilogue evasion technique as reported by our systems.

The following picture shows the geolocation of IP addresses used to spread the malicious emails. Spreading patterns seem to be related to a single botnet that is expanding and contracting over time. This seems to be confirmed also by the fact that so far only Italian users have been targeted by these attacks.

There are many ways to detect ransomware at the network level: some families check-in to their C&C before encrypting files, some send a report when they're done encrypting; other samples can be detected by the hash of a known SSL certificate, or by their .onion domain used to pay the ransom.

Some more indicators of compromise (IoC) could be used on the endpoint: ransomware often has a custom file extension for encrypted files (even if latest variants avoid doing so), and in addition leaves a trail of instruction files for the victim.

Those same endpoint IoCs can be used on the network to detect if the ransomware is encrypting files on mapped and unmapped SMB shares. Here are some template Snort/Suricata signatures valid for both SMB ( 0xA2 SMB_COM_NT_CREATE_ANDX command) and SMB2 (0x05 SMB2/Create command). SMB3 can not be covered because "unfortunately" it adds an encryption layer.

alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Encrypted File over SMBv1 (.EXT ASCII)"; flow:established,to_server; content:"|FF|SMB|A2|"; offset:4; depth:5; byte_test:1,!&,0x80,6,relative; content:".EXT"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000001; rev:1;)
alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Encrypted File over SMBv1 (.EXT Unicode)"; flow:established,to_server; content:"|FF|SMB|A2|"; offset:4; depth:5; byte_test:1,&,0x80,6,relative; content:".|00|E|00|X|00|T|00|"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000002; rev:1;)
alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Instructions File over SMBv1 (FILENAME.EXT ASCII)"; flow:established,to_server; content:"|FF|SMB|A2|"; offset:4; depth:5; byte_test:1,!&,0x80,6,relative; content:"FILENAME.EXT"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000003; rev:1;)
alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Instructions File over SMBv1 (FILENAME.EXT Unicode)"; flow:established,to_server; content:"|FF|SMB|A2|"; offset:4; depth:5; byte_test:1,&,0x80,6,relative; content:"F|00|I|00|L|00|E|00|N|00|A|00|M|00|E|00|.|00|E|00|X|00|T|00|"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000004; rev:1;)
alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Encrypted File over SMBv2 (.EXT)"; flow:established,to_server; content:"|FE|SMB|40 00|"; offset:4; depth:6; content:"|05 00|"; distance:0; content:".|00|E|00|X|00|T|00|"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000005; rev:1;)
alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"CERTEGO TROJAN Possible FAMILYNAME Ransomware Writing Instructions File over SMBv2 (FILENAME.EXT)"; flow:established,to_server; content:"|FE|SMB|40 00|"; offset:4; depth:6; content:"|05 00|"; distance:0; content:"F|00|I|00|L|00|E|00|N|00|A|00|M|00|E|00|.|00|E|00|X|00|T|00|"; threshold: type limit, track by_src, count 1, seconds 600; reference:url,; classtype:trojan-activity; sid:9000006; rev:1;)

What follows is just an example of how those template signatures could be used for older Locky and CryptoFortress samples. More ransomware families could be easily added or updated to reflect latest changes (the old cat and mouse game).

CERTEGO TROJAN Possible Locky Ransomware Writing Encrypted File over SMBv1 (.locky ASCII)
CERTEGO TROJAN Possible Locky Ransomware Writing Encrypted File over SMBv1 (.locky Unicode)
CERTEGO TROJAN Possible Locky Ransomware Writing Instructions File over SMBv1 (_HELP_instructions.txt ASCII)
CERTEGO TROJAN Possible Locky Ransomware Writing Instructions File over SMBv1 (_HELP_instructions.txt Unicode)
CERTEGO TROJAN Possible Locky Ransomware Writing Encrypted File over SMBv2 (.locky)
CERTEGO TROJAN Possible Locky Ransomware Writing Instructions File over SMBv2 (_HELP_instructions.txt)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Encrypted File over SMBv1 (.frtrss ASCII)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Encrypted File over SMBv1 (.frtrss Unicode)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Instructions File over SMBv1 (READ IF YOU WANT YOUR FILES BACK.html ASCII)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Instructions File over SMBv1 (READ IF YOU WANT YOUR FILES BACK.html Unicode)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Encrypted File over SMBv2 (.frtrss)
CERTEGO TROJAN Possible CryptoFortress Ransomware Writing Instructions File over SMBv2 (READ IF YOU WANT YOUR FILES BACK.html)

In the last few days, since October 7, 2015, Certego's spamtrap started analyzing three different malware campaigns targeted to Italian users. All three campaigns are using a JavaScript downloader called JS/Nemucod, which is attached directly to the emails inside a ZIP file. When the user opens the zip file and double clicks the JavaScript, the default file type associations in Windows will cause Internet Explorer to open and execute the JavaScript.

We were able to identify three different campaigns, all of them being targeted specifically at Italian users: in all cases, emails were written in Italian, and so was the PDF document used as a decoy.

Campaign 0710TIT
This campaign started hitting our mailboxes on October 7. Some examples of attachment names are:

Some examples of the JavaScript files inside the zip are:


The variant of JS/Nemucod used in this campaign is employing two different layers of obfuscation, both of them using a simple bitwise XOR with a 12 to 14-byte long key. In the first layer, all the JavaScript code is obfuscated; the second layer only obfuscates the domain names of the Command & Control servers.

Once executed, Nemucod will instantiate three different ActiveX controls: WScript.Shell, MSXML2.XMLHTTP and ADODB.Stream. To make a long story short, Nemucod will use them to save an executable file to the temporary folder %TEMP% and to run it; right after that, Nemucod will open a legitimate PDF file in the browser: this document is uses as a decoy to let the user believe they're actually viewing a real invoice, as shown below.

This version of the JavaScript file downloads a simple EXE file which is then invoked directly in the background through the WScript.Shell ActiveX control. Right after that, the malware opens the decoy PDF document through the ADODB.Stream ActiveX control.

Campaign 0810DTIT
This campaign started hitting our sandbox on October 8. Attachment names are very similar to the first campaign:

Even the JavaScript files are pretty much the same:


However, this second campaign does not download an EXE file; instead, it downloads a DLL library which is then invoked by running rundll32.exe through the WScript.Shell ActiveX control. The DLL's entry point is the non-standard function name "DLLRegisterServer". Once again, right after that, the malware uses the ADODB.Stream ActiveX control to open the decoy PDF file.

Campaign 1410DTIT
The last campaign started hitting our sandbox early this morning, even if its name suggests that it probably started yesterday. This campaign uses a different naming for both the compressed file and its content, some examples being:

This campaign also downloads a DLL library which is invoked through rundll32.exe; the entry point is still "DLLRegisterServer" and the decoy PDF document is always the same.

The payload
Execution of these campaigns in our Sandbox showed that the executable files downloaded by Nemucod are used to retrieve a Trojan Downloader called Fareit or Pony Downloader, which in turn downloads another set of executable files containing the Gozi infostealer. Interestingly enough, the computer is rebooted after a few instants, and Gozi starts phoning home only after the reboot. This technique may be used to avoid detection in sandboxed environments.

It looks like the bad guys made some mistakes in the setup of the Command & Control servers used by Nemucod. During our analyses we found out that sometimes the servers were replying with a HTTP header indicating that the file being server was an application/x-dosexec; but better analysis of the payload only showed an internal error generated by the script that probably packs the file before serving it, as shown in the following picture.

Nemucod's C&C domains from the first campaign (0710TIT):


Second campaign (0810DTIT):


Third campaign (1410DTIT):


C&Cs for Gozi and Fareit/Pony Downloader


Snort signatures
The following Snort signatures should help detect the execution of Nemucod; the first two of them will detect any request that looks like Nemucod's italian campaigns; the third and fourth will detect the server returning an executable or the decoy PDF. 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"CERTEGO MALWARE JS/Nemucod.M.gen requesting EXE payload"; flow:to_server,established; content:"GET"; http_method; content:".php?"; http_uri; nocase; content:"key="; http_uri; nocase; content:!"pdf="; http_uri; nocase; content:!"Referer|3a| "; nocase; http_header; pcre:"/\/get(_new)?\.php\?[a-zA-Z]{4,}=0\.[0-9]{10,}&key=[a-zA-Z0-9]{4,}$/U"; flowbits:set,CERTEGO.nemucod.exerequest; classtype:trojan-activity; sid:9000101; rev:2;)
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"CERTEGO MALWARE JS/Nemucod.M.gen requesting PDF payload"; flow:to_server,established; content:"GET"; http_method; content:".php?"; http_uri; nocase; content:"key="; http_uri; nocase; content:"pdf="; http_uri; nocase; content:!"Referer|3a| "; nocase; http_header; pcre:"/\/get(_new)?\.php\?[a-zA-Z]{4,}=0\.[0-9]{10,}&key=[a-zA-Z0-9]{4,}&pdf=[a-zA-Z]{4,}$/U"; flowbits:set,CERTEGO.nemucod.pdfrequest; classtype:trojan-activity; sid:9000102; rev:2;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"CERTEGO MALWARE JS/Nemucod.M.gen downloading EXE payload"; flow:from_server,established; flowbits:isset,CERTEGO.nemucod.exerequest; file_data; content:"MZ"; within:2; byte_jump:4,58,relative,little; content:"PE|00 00|"; fast_pattern; distance:-64; within:4; classtype:trojan-activity; sid:9000103; rev:1;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"CERTEGO MALWARE JS/Nemucod.M.gen downloading PDF payload"; flow:from_server,established; flowbits:isset,CERTEGO.nemucod.pdfrequest; file_data; content:"%PDF-"; within:5; classtype:trojan-activity; sid:9000104; rev:1;)

UPDATE 2015-10-16

A better look at yesterday's traffic showed that the new campaigns were actually two: one with ID 1410DTIT and the other with ID 14IT10M. Looking at timestamps shows that 14IT10M was probably released a few hours after 1410DTIT. Both campaigns are already covered by the Snort signatures that we released yesterday, and that have been included in today's release by Emerging Threats. 

A few hours ago Certego's Incident Response Team detected a malware campaign serving a new Ransomware variant through Nuclear Pack Exploit Kit.

Compromised web sites redirect the user to the Exploit Kit's first step, located at IP address 85.143.218 .208. The domain name used for this first step varies over time, and some of the variants we saw are:

mexicoss.everythingcannabis .biz
shift.boutiqueeuphoria .com

The resource name, instead, does not seem to change:


The second step is located at IP address 62.76.180 .20 and some of the domain names we saw are:

actually.murdererswelcome .com
utah.murwel .com

In this case, the resources seem to mimic the behaviour of a search engine:


Flash SWF exploit

The Exploit Kit serves a Flash SWF file with a 0/56 detection rate on VirusTotal.

The execution of this exploit causes the download of a payload that is obfuscated by running a byte-wise XOR with a 7 bytes long key, as shown in the picture below.

Encoded payload

Deobfuscation is pretty simple and leads to a PE file (Windows executable) that has a pretty low detection rate on VirusTotal (2/56), with only AhnLab-v3 and SUPERAntiSpyware detecting it as malicious.

But what does this malware do? Execution on Certego's sandbox shows it will encrypt all of the files on the affected PC, renaming them in the form:


with <original_name> being the original file name, <id-number> being a unique ID the malware gives to each victim, and <email> being the address to contact to get the decryption instructions.

Ransomware effects

The most peculiar characteristic of this ransowmare is the fact that it does not give you clear instructions for the payment: it simply renames all your files, and you'll have to be smart enough to understand that all you have to do is to contact the email address you see appended in your file names. The fact that almost no antivirus solution is still able to correctly detect this ransomware shows that it's probably a brand new piece of malware. We still haven't analyzed it, so we still cannot say anything, but right after being executed, the malware makes a single POST request to the following site:

http://permanencez .com/script.php

The content of the POST request and the subsequent server response are shown below.

Malicious POST to C&C

Basically, the malware sends its C&C server a unique ID, the hostname of the infected machine, the whole string appended to the file names (using the format shown above) and a number that appears to be randomly generated. The server answers with a binary string that may contain the encryption key - but we still have to verify this point. They also seem to be using one or more Squid instances as reverse proxies to hide the real C&C's address.

The exploit kit can be detected by using the following two Emerging Threats Snort/Suricata signatures:

ET CURRENT_EVENTS Nuclear EK Exploit URI Struct Aug 12

However, the download of the XOR-ed payload and the malware's request to the above mentioned C&C Server do not seem to trigger any alert on Snort at the moment.

Andromeda/Gamarue bots are routinely used as backdoors to infected systems and can also be vectors for downloading different malicious payloads.

Over the last few weeks we noticed the resurgence of a particular spam campaign that is distributing Andromeda/Gamarue to Italian domains, with a couple of bursts in the last 20 days but also going back to April and May 2015.


Our systems collected more than 4000 unique emails with malicious attachments that can be linked to Andromeda with an ultimate goal of distributing two particular families of financial malware. Spam relays linked to this campaign are primarily located in Europe with a strong focus on Spain and Italy.


The attachments (ZIP archives) have been crafted using names that resemble standard Italian business documents, but actually they are executable files compromising the system. As previously reported, the malicious executable creates a new msiexec.exe process and injects code into it, then it joins the Andromeda botnet by connecing to the C&C 93.115.38[.]134 using an RC4-encoded JSON.

In the second stage of infection, we have observed the download of one or two different payloads: Citadel (“ssdc32716372” gang) or Gozi/Ursnif (a recent variant, see here and here). In the recent past, other Andromeda botnets have been detected, one of them dropping Lethic malware instead of infostealers.

On June, 24th we also identified a different sample having the same behaviour but targeting German users. That sample is using a different Command and Control server 5.9.253[.]153.

Some IOCs we have identified so far:

MD5 hashes


Attachment names

FATT. 130-2015 SRL noleggio_pdf_.exe         
FT. 118 - 2015 srl noleggio _docx_.doc.exe
fattura Tiscali numero 026778844.pdf.exe             

Dropped files
Seemingly random, regexp: KB[0-9]{8}\.exe

KB07341263.exe    (896dec6dd2e1190aa69e3f19bd7c00c9)
KB21743115.exe    (f7c776865c6e202a19a590e063303016)
KB21746240.exe    (1c04d9fac2fdc1017b8443de81dabc3c)
KB33798926.exe 	  (2d11c7b7d7b418a45a30cf4ba4e938d8)
KB07887278.exe 	  (1df302a42144ad240f7b0ee8b165840f)
KB36135815.exe	  (ebb7e22d4a10cbed0d6f1a5be3163078)

Command and Control servers

hxxp://93.115.38 .134/new/stats.php    (Italian campaign)
hxxp://5.9.253 .153/new/stats.php      (German campaign)

In the last few days Certego identified and analyzed a new spam campaign that targeted italian domains. This campaign is spreading a variant of the Dridex financial malware which is loaded with operational intelligence that is effective against many Italian banks. Dridex is not new nor original software, as it belongs to the famous Zeus family, being derived from one of Zeus descendant known as Cridex or Feodo. It uses a command and control system based on traditional web servers via plain HTTP. The spreading technique itself is not particularly sophisticated, as it uses an Office document, in this case an Excel file, that is attached to spam email messages. The document contains a series of VBScript macros, which execution is usually disabled by default in Office products, just because in the past the same method was widely used to convey malicious programs. It therefore seems even more surprising that, despite the notifications that alert the user about the potentially dangerous consequences of their actions, this block is voluntarily removed to be able to open the attachment. Once again the most basic social engineering techniques are enough to induce a careless behaviour that can have very serious consequences.

The campaign analyzed by Certego uses email messages in English, with the subject "Order T / N: CL0943_744". One of the sender is "Mariana Holland, State Department <>". The body of the email is as follows:

"Your order is ready for collection at your chosen store.View full order details T / N: CL0943_744 in attached document."

The attachment is an excel file containing different macros,  a sequence of statements in VBScript that have the task of downloading the malware itself from a public site and of running it. Macros are heavily obfuscated in an attempt often successful of circumventing antivirus checks. The following image shows the VBScript procedure used to execute a command using the system shell.

As we see, the command is a heavily obfuscated string, which is processed by a further subroutine that returns the cleartext version of the command to be executed. This second subroutine, from wich we have removed some jump code for clarity, is shown in the following screenshot.

This function only takes the odd characters of the obfuscated string, and the end result is visible in the last image below.

The macro downloads a file "" from the IP address 134.19.180 [.] 144, then decompresses it and launches the executable content.

Once installed on your system Dridex uses, like all other Zeus variants, a configuration file that contains the "instructions" on the actions to take when it detects that a browser on the infected machine is visiting a specific web page belonging to a targeted bank. In the latest sample we analyzed, as we posted Friday on Twitter and Pastebin, there were about forty new Italian targets , including some major banks and e-commerce portals.

Dridex can intercept  communications with your home banking portal, and possibly steal login credentials or manipulate transactions in order to commit fraud. The only effective defense is a sufficient awareness and preparation of users, that must avoid the opening of suspicious attachments. In the case we have shown, the email you may receive in your inbox should ring many alarms: it comes from an unknown and implausible sender, it refers to a purchase you have never done, and it requires you to disable Office macros protection in order to be able to open the attachment. If you already fell to the trick and became infected, you must be aware of unnecessary sensitive data that your usual home banking portal may ask you to input at login or during transactions.

Certego Threat Intelligence can help the affected institutions to identify suspicious transactions carried out by malware compromised devices and block fraud transactions.

Image from:

In the last few days, Certego threat monitoring systems detected a malware distribution campaign affecting several forums hosted on italian domains.

How it works

The affected forum sites have been previously compromised, possibly exploiting vulnerabilities in software platforms used for forums management, namely vBulletin version 4.1.9 and IP Board version 3.4.6. Users who visit the forum pages are redirected to external sites to download the so called Nuclear Pack Exploit Kit, a software container that provides the ability to leverage several vulnerabilities on user machines in order to infect them and gain complete control. In this particular case, files in .swf format are used to exploit the latest Adobe Flash Player vulnerabilities.

All the forums identified by Certego as being compromised during this campaign have URLs in the following format:


with domains like:


For example, these are some of the domains used to distribute Nuclear Pack, albeit not all of them are still reachable and active:

72ni9v3j9chko9ak5u4uwhf.nostaljiyemekler [.] com
ey03cunzlam19kc1v9ee9jf.gumuspastabodrum [.] com
ftafyk9wkvu42523ju20iri.devletdestegi [.] com

We also identified some of the IP addresses on which the malicious domains are are hosted, in example:


Some of the IPs as well are no longer reachable and may have been cleaned, but most of them are still active and dangerous.

A few of these IP addresses belong to Virtual Private Servers purchased specifically for the installation of Nuclear Pack Exploit Kit, while others, used only as the first step in the redirection chain, are more likely to be compromised hosts. Gaining the control of these servers in the first place has allowed the creation of sub-domains with random names used for the distribution of malware. As a matter of fact, this way the Exploit Kit is reachable only by knowing beforehand the subdomain used, and is therefore much more protected from accidental discovery.


This attack exploits vulnerabilities in Flash Player, which therefore must be updated to the latest version If you suspect to be already compromised, you can try to remove the infection using the following free products:

A more radical solution is to uninstall the Flash plug-in browser, or to limit the operation selectively, as explained in this guide, but this must be carefully evaluated because of the impacts it may have on usability and user experience in a production environment.