Malware RSS Feed

Securely Deleting Files

SANS Tip of the Day - Thu, 10/19/2017 - 01:00
When you delete a file, that file is actually still on your computer. The only way you can truly and securely remove a file is by wiping it or using some type of secure deletion.

ATM malware is being sold on Darknet market

Malware Alerts - Tue, 10/17/2017 - 05:00

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.


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):


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


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:


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:

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


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

Malware Alerts - Mon, 10/16/2017 - 10:28

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


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 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:</p style=”margin-bottom:0!important”>

  • 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:</p style=”margin-bottom:0!important”>

  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:</p style=”margin-bottom:0!important”>

  • C:\ProgramData\ManagerApp\AdapterTroubleshooter.exe
  • C:\ProgramData\ManagerApp\
  • C:\ProgramData\ManagerApp\
  • 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.


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:


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

  1. Adobe Bulletin
Indicators of compromise


Cloud Security

SANS Tip of the Day - Fri, 10/13/2017 - 01:00
One of the most effective steps you can take to protect your cloud account is to make sure you are using two-step verification. In addition, always be sure you know exactly whom you are sharing files with. It is very easy to accidently share your files with the entire Internet when you think you are only sharing them with specific individuals.

ATMii: a small but effective ATM robber

Malware Alerts - Tue, 10/10/2017 - 05:00

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

“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

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


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.

Back up Your Files

SANS Tip of the Day - Tue, 10/10/2017 - 01:00
Eventually, we all have an accident or get hacked. And when we do, backups are often the only way to recover. Backups are cheap and easy; make sure you are backing up all of your personal information (such as family photos) on a regular basis.

Shopping Online

SANS Tip of the Day - Mon, 10/09/2017 - 01:00
When shopping online, always use your credit cards instead of a debit card. If any fraud happens, it is far easier to recover your money from a credit card transaction. Gift cards and one-time-use credit card numbers are even more secure.

Email and Emotions

SANS Tip of the Day - Fri, 10/06/2017 - 01:00
Never send an email when you are angry; you will most likely regret it later. Instead, when you are emotional and want to reply to someone, open up an email and write everything you feel, but do not send it. (Be sure there is no name in the TO field so that you do not accidently send it.) After you have vented, save the email and come back an hour later. You only want to reply to any type of emotional situation after you have had time to cool down.

The Festive Complexities of SIGINT-Capable Threat Actors

Malware Alerts - Wed, 10/04/2017 - 06:00

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

Malware Alerts - Thu, 09/28/2017 - 08:00

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

Malware Alerts - Mon, 09/25/2017 - 08:23

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

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

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

Malware Alerts - Tue, 09/19/2017 - 06:00

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:

  • 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:

  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:

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


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:

  • 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:

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

.entry-content table tr:first-child td, .entry-content table th { border-bottom: none; font-weight: normal; } .entry-content table td { border-bottom: none; } .gist{font-size:16px;color:#333;text-align:left;/*! * GitHub Light v0.4.1 * Copyright (c) 2012 - 2017 GitHub, Inc. * Licensed under MIT ( */direction:ltr}.gist .markdown-body{font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";font-size:16px;line-height:1.5;word-wrap:break-word}.gist .markdown-body::before{display:table;content:""}.gist .markdown-body::after{display:table;clear:both;content:""}.gist .markdown-body>*:first-child{margin-top:0 !important}.gist .markdown-body>*:last-child{margin-bottom:0 !important}.gist .markdown-body a:not([href]){color:inherit;text-decoration:none}.gist .markdown-body .absent{color:#cb2431}.gist .markdown-body .anchor{float:left;padding-right:4px;margin-left:-20px;line-height:1}.gist .markdown-body .anchor:focus{outline:none}.gist .markdown-body p,.gist .markdown-body blockquote,.gist .markdown-body ul,.gist .markdown-body ol,.gist .markdown-body dl,.gist .markdown-body table,.gist .markdown-body pre{margin-top:0;margin-bottom:16px}.gist .markdown-body hr{height:0.25em;padding:0;margin:24px 0;background-color:#e1e4e8;border:0}.gist .markdown-body blockquote{padding:0 1em;color:#6a737d;border-left:0.25em solid #dfe2e5}.gist .markdown-body blockquote>:first-child{margin-top:0}.gist .markdown-body blockquote>:last-child{margin-bottom:0}.gist .markdown-body kbd{display:inline-block;padding:3px 5px;font-size:11px;line-height:10px;color:#444d56;vertical-align:middle;background-color:#fafbfc;border:solid 1px #c6cbd1;border-bottom-color:#959da5;border-radius:3px;box-shadow:inset 0 -1px 0 #959da5}.gist .markdown-body h1,.gist .markdown-body h2,.gist .markdown-body h3,.gist .markdown-body h4,.gist .markdown-body h5,.gist .markdown-body h6{margin-top:24px;margin-bottom:16px;font-weight:600;line-height:1.25}.gist .markdown-body h1 .octicon-link,.gist .markdown-body h2 .octicon-link,.gist .markdown-body h3 .octicon-link,.gist .markdown-body h4 .octicon-link,.gist .markdown-body h5 .octicon-link,.gist .markdown-body h6 .octicon-link{color:#1b1f23;vertical-align:middle;visibility:hidden}.gist .markdown-body h1:hover .anchor,.gist .markdown-body h2:hover .anchor,.gist .markdown-body h3:hover .anchor,.gist .markdown-body h4:hover .anchor,.gist .markdown-body h5:hover .anchor,.gist .markdown-body h6:hover .anchor{text-decoration:none}.gist .markdown-body h1:hover .anchor .octicon-link,.gist .markdown-body h2:hover .anchor .octicon-link,.gist .markdown-body h3:hover .anchor .octicon-link,.gist .markdown-body h4:hover .anchor .octicon-link,.gist .markdown-body h5:hover .anchor .octicon-link,.gist .markdown-body h6:hover .anchor .octicon-link{visibility:visible}.gist .markdown-body h1 tt,.gist .markdown-body h1 code,.gist .markdown-body h2 tt,.gist .markdown-body h2 code,.gist .markdown-body h3 tt,.gist .markdown-body h3 code,.gist .markdown-body h4 tt,.gist .markdown-body h4 code,.gist .markdown-body h5 tt,.gist .markdown-body h5 code,.gist .markdown-body h6 tt,.gist .markdown-body h6 code{font-size:inherit}.gist .markdown-body h1{padding-bottom:0.3em;font-size:2em;border-bottom:1px solid #eaecef}.gist .markdown-body h2{padding-bottom:0.3em;font-size:1.5em;border-bottom:1px solid #eaecef}.gist .markdown-body h3{font-size:1.25em}.gist .markdown-body h4{font-size:1em}.gist .markdown-body h5{font-size:0.875em}.gist .markdown-body h6{font-size:0.85em;color:#6a737d}.gist .markdown-body ul,.gist .markdown-body ol{padding-left:2em}.gist .markdown-body,.gist .markdown-body{padding:0;list-style-type:none}.gist .markdown-body ul ul,.gist .markdown-body ul ol,.gist .markdown-body ol ol,.gist .markdown-body ol ul{margin-top:0;margin-bottom:0}.gist .markdown-body li>p{margin-top:16px}.gist .markdown-body li+li{margin-top:0.25em}.gist .markdown-body dl{padding:0}.gist .markdown-body dl dt{padding:0;margin-top:16px;font-size:1em;font-style:italic;font-weight:600}.gist .markdown-body dl dd{padding:0 16px;margin-bottom:16px}.gist .markdown-body table{display:block;width:100%;overflow:auto}.gist .markdown-body table th{font-weight:600}.gist .markdown-body table th,.gist .markdown-body table td{padding:6px 13px;border:1px solid #dfe2e5}.gist .markdown-body table tr{background-color:#fff;border-top:1px solid #c6cbd1}.gist .markdown-body table tr:nth-child(2n){background-color:#f6f8fa}.gist .markdown-body table img{background-color:transparent}.gist .markdown-body img{max-width:100%;box-sizing:content-box;background-color:#fff}.gist .markdown-body img[align=right]{padding-left:20px}.gist .markdown-body img[align=left]{padding-right:20px}.gist .markdown-body .emoji{max-width:none;vertical-align:text-top;background-color:transparent}.gist .markdown-body span.frame{display:block;overflow:hidden}.gist .markdown-body span.frame>span{display:block;float:left;width:auto;padding:7px;margin:13px 0 0;overflow:hidden;border:1px solid #dfe2e5}.gist .markdown-body span.frame span img{display:block;float:left}.gist .markdown-body span.frame span span{display:block;padding:5px 0 0;clear:both;color:#24292e}.gist .markdown-body span.align-center{display:block;overflow:hidden;clear:both}.gist .markdown-body span.align-center>span{display:block;margin:13px auto 0;overflow:hidden;text-align:center}.gist .markdown-body span.align-center span img{margin:0 auto;text-align:center}.gist .markdown-body span.align-right{display:block;overflow:hidden;clear:both}.gist .markdown-body span.align-right>span{display:block;margin:13px 0 0;overflow:hidden;text-align:right}.gist .markdown-body span.align-right span img{margin:0;text-align:right}.gist .markdown-body span.float-left{display:block;float:left;margin-right:13px;overflow:hidden}.gist .markdown-body span.float-left span{margin:13px 0 0}.gist .markdown-body span.float-right{display:block;float:right;margin-left:13px;overflow:hidden}.gist .markdown-body span.float-right>span{display:block;margin:13px auto 0;overflow:hidden;text-align:right}.gist .markdown-body code,.gist .markdown-body tt{padding:0;padding-top:0.2em;padding-bottom:0.2em;margin:0;font-size:85%;background-color:rgba(27,31,35,0.05);border-radius:3px}.gist .markdown-body code::before,.gist .markdown-body code::after,.gist .markdown-body tt::before,.gist .markdown-body tt::after{letter-spacing:-0.2em;content:"\00a0"}.gist .markdown-body code br,.gist .markdown-body tt br{display:none}.gist .markdown-body del code{text-decoration:inherit}.gist .markdown-body pre{word-wrap:normal}.gist .markdown-body pre>code{padding:0;margin:0;font-size:100%;word-break:normal;white-space:pre;background:transparent;border:0}.gist .markdown-body .highlight{margin-bottom:16px}.gist .markdown-body .highlight pre{margin-bottom:0;word-break:normal}.gist .markdown-body .highlight pre,.gist .markdown-body pre{padding:16px;overflow:auto;font-size:85%;line-height:1.45;background-color:#f6f8fa;border-radius:3px}.gist .markdown-body pre code,.gist .markdown-body pre tt{display:inline;max-width:auto;padding:0;margin:0;overflow:visible;line-height:inherit;word-wrap:normal;background-color:transparent;border:0}.gist .markdown-body pre code::before,.gist .markdown-body pre code::after,.gist .markdown-body pre tt::before,.gist .markdown-body pre tt::after{content:normal}.gist .markdown-body .csv-data td,.gist .markdown-body .csv-data th{padding:5px;overflow:hidden;font-size:12px;line-height:1;text-align:left;white-space:nowrap}.gist .markdown-body .csv-data .blob-num{padding:10px 8px 9px;text-align:right;background:#fff;border:0}.gist .markdown-body .csv-data tr{border-top:0}.gist .markdown-body .csv-data th{font-weight:600;background:#f6f8fa;border-top:0}.gist .pl-c{color:#6a737d}.gist .pl-c1,.gist .pl-s .pl-v{color:#005cc5}.gist .pl-e,.gist .pl-en{color:#6f42c1}.gist .pl-smi,.gist .pl-s .pl-s1{color:#24292e}.gist .pl-ent{color:#22863a}.gist .pl-k{color:#d73a49}.gist .pl-s,.gist .pl-pds,.gist .pl-s .pl-pse .pl-s1,.gist .pl-sr,.gist .pl-sr .pl-cce,.gist .pl-sr .pl-sre,.gist .pl-sr .pl-sra{color:#032f62}.gist .pl-v,.gist .pl-smw{color:#e36209}.gist .pl-bu{color:#b31d28}.gist .pl-ii{color:#fafbfc;background-color:#b31d28}.gist .pl-c2{color:#fafbfc;background-color:#d73a49}.gist .pl-c2::before{content:"^M"}.gist .pl-sr .pl-cce{font-weight:bold;color:#22863a}.gist .pl-ml{color:#735c0f}.gist .pl-mh,.gist .pl-mh .pl-en,.gist .pl-ms{font-weight:bold;color:#005cc5}.gist .pl-mi{font-style:italic;color:#24292e}.gist .pl-mb{font-weight:bold;color:#24292e}.gist .pl-md{color:#b31d28;background-color:#ffeef0}.gist .pl-mi1{color:#22863a;background-color:#f0fff4}.gist .pl-mc{color:#e36209;background-color:#ffebda}.gist .pl-mi2{color:#f6f8fa;background-color:#005cc5}.gist .pl-mdr{font-weight:bold;color:#6f42c1}.gist .pl-ba{color:#586069}.gist .pl-sg{color:#959da5}.gist .pl-corl{text-decoration:underline;color:#032f62}.gist .breadcrumb{margin-bottom:10px;font-size:18px;color:#586069}.gist .breadcrumb .separator::before,.gist .breadcrumb .separator::after{content:" "}.gist .breadcrumb{color:#24292e}.gist .breadcrumb .zeroclipboard-button{display:inline-block;margin-left:5px}.gist .breadcrumb .repo-root{font-weight:600}.gist .breadcrumb .octicon{vertical-align:-2px}.gist .editor-license-template,.gist .editor-code-of-conduct-template,.gist .editor-gitignore-template{position:relative;top:3px;display:block;float:right;font-size:14px}.gist .editor-license-template .select-menu-git-ignore,.gist .editor-code-of-conduct-template .select-menu-git-ignore,.gist .editor-gitignore-template .select-menu-git-ignore{right:0}.gist .editor-abort{display:inline;font-size:14px}.gist .blob-interaction-bar{position:relative;background-color:#f2f2f2;border-bottom:1px solid #e5e5e5}.gist .blob-interaction-bar::before{display:table;content:""}.gist .blob-interaction-bar::after{display:table;clear:both;content:""}.gist .blob-interaction-bar .octicon-search{position:absolute;top:10px;left:10px;font-size:12px;color:#586069}.gist .blob-filter{width:100%;padding:4px 20px 5px 30px;font-size:12px;border:0;border-radius:0;outline:none}.gist .blob-filter:focus{outline:none}.gist .html-blob{margin-bottom:15px}.gist .license-summary-octicon{color:#959da5}.gist .rule-type-permissions{color:#28a745}.gist .rule-type-conditions{color:#0366d6}.gist .rule-type-limitations{color:#d73a49}.gist .blob-wrapper{overflow-x:auto;overflow-y:hidden;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.gist .blob-wrapper-embedded{max-height:240px;overflow-y:auto}.gist .diff-table{width:100%;border-collapse:separate}.gist .diff-table .line-comments{padding:10px;vertical-align:top;border-top:1px solid #e1e4e8}.gist .diff-table .line-comments:first-child+.empty-cell{border-left-width:1px}.gist .diff-table tr:not(:last-child) .line-comments{border-top:1px solid #e1e4e8;border-bottom:1px solid #e1e4e8}.gist .blob-num{width:1%;min-width:50px;padding-right:10px;padding-left:10px;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;line-height:20px;color:rgba(27,31,35,0.3);text-align:right;white-space:nowrap;vertical-align:top;cursor:pointer;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}.gist .blob-num:hover{color:rgba(27,31,35,0.6)}.gist .blob-num::before{content:attr(data-line-number)}.gist .blob-num.non-expandable{cursor:default}.gist .blob-num.non-expandable:hover{color:rgba(27,31,35,0.3)}.gist .blob-code{position:relative;padding-right:10px;padding-left:10px;line-height:20px;vertical-align:top}.gist .blob-code-inner{overflow:visible;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;color:#24292e;word-wrap:normal;white-space:pre}.gist .blob-code-inner .x-first{border-top-left-radius:0.2em;border-bottom-left-radius:0.2em}.gist .blob-code-inner .x-last{border-top-right-radius:0.2em;border-bottom-right-radius:0.2em}.gist .blob-code-inner::before{content:""}.gist .blob-code-inner.highlighted{background-color:#fffbdd}.gist .soft-wrap .diff-table{table-layout:fixed}.gist .soft-wrap .blob-code{padding-left:18px;text-indent:-7px}.gist .soft-wrap .blob-code-inner{word-wrap:break-word;white-space:pre-wrap}.gist .soft-wrap .no-nl-marker{display:none}.gist .soft-wrap .add-line-comment{margin-left:-28px}.gist .blob-num-hunk,.gist .blob-code-hunk,.gist .blob-num-expandable,.gist .blob-code-expandable{color:rgba(27,31,35,0.5);vertical-align:middle}.gist .blob-num-hunk,.gist .blob-num-expandable{background-color:#dbedff}.gist .blob-code-hunk,.gist .blob-code-expandable{padding-top:4px;padding-bottom:4px;background-color:#f1f8ff;border-width:1px 0}.gist .blob-expanded .blob-num,.gist .blob-expanded .blob-code{background-color:#fafbfc}.gist .blob-expanded+tr:not(.blob-expanded) .blob-num,.gist .blob-expanded+tr:not(.blob-expanded) .blob-code{border-top:1px solid #eaecef}.gist .blob-expanded .blob-num-hunk{border-top:1px solid #eaecef}.gist tr:not(.blob-expanded)+.blob-expanded .blob-num,.gist tr:not(.blob-expanded)+.blob-expanded .blob-code{border-top:1px solid #eaecef}.gist .blob-num-expandable{padding:0;font-size:12px;text-align:center}.gist .blob-num-expandable .octicon{vertical-align:top}.gist .blob-num-expandable .diff-expander{display:block;width:auto;height:auto;padding:4px 11px 4px 10px;margin-right:-1px;color:#586069;cursor:pointer}.gist .blob-num-expandable .diff-expander:hover{color:#fff;text-shadow:none;background-color:#0366d6;border-color:#0366d6}.gist .blob-code-addition{background-color:#e6ffed}.gist .blob-code-addition .x{color:#24292e;background-color:#acf2bd}.gist .blob-num-addition{background-color:#cdffd8;border-color:#bef5cb}.gist .blob-code-deletion{background-color:#ffeef0}.gist .blob-code-deletion .x{color:#24292e;background-color:#fdb8c0}.gist .blob-num-deletion{background-color:#ffdce0;border-color:#fdaeb7}.gist .selected-line.blob-code{background-color:#fffbdd}.gist .selected-line.blob-code .x{background-color:transparent}.gist .selected-line.blob-num{background-color:#fff5b1;border-color:#ffea7f}.gist .add-line-comment{position:relative;z-index:5;float:left;width:22px;height:22px;margin:-2px -10px -2px -20px;line-height:21px;color:#fff;text-align:center;text-indent:0;cursor:pointer;background-color:#0366d6;background-image:linear-gradient(#0372ef, #0366d6);border-radius:3px;box-shadow:0 1px 4px rgba(27,31,35,0.15);opacity:0;transition:-webkit-transform 0.1s ease-in-out;transition:transform 0.1s ease-in-out;-webkit-transform:scale(0.8, 0.8);transform:scale(0.8, 0.8)}.gist .add-line-comment:hover{-webkit-transform:scale(1, 1);transform:scale(1, 1)}.is-hovered .gist .add-line-comment,.gist .add-line-comment:focus{opacity:1}.gist .add-line-comment .octicon{vertical-align:text-top;pointer-events:none}.gist .add-line-comment.octicon-check{background:#333;opacity:1}.gist .inline-comment-form{border:1px solid #dfe2e5;border-radius:3px}.gist .inline-review-comment{margin-top:0 !important;margin-bottom:10px !important}.gist .inline-review-comment .gc:first-child+tr .blob-num,.gist .inline-review-comment .gc:first-child+tr .blob-code{padding-top:5px}.gist .inline-review-comment tr:last-child{border-bottom-right-radius:2px;border-bottom-left-radius:2px}.gist .inline-review-comment tr:last-child .blob-num,.gist .inline-review-comment tr:last-child .blob-code{padding-bottom:8px}.gist .inline-review-comment tr:last-child .blob-num:first-child,.gist .inline-review-comment tr:last-child .blob-code:first-child{border-bottom-left-radius:2px}.gist .inline-review-comment tr:last-child .blob-num:last-child,.gist .inline-review-comment tr:last-child .blob-code:last-child{border-bottom-right-radius:2px}.gist .timeline-inline-comments{width:100%;table-layout:fixed}.gist .timeline-inline-comments .inline-comments,.gist .show-inline-notes .inline-comments{display:table-row}.gist .inline-comments{display:none}.gist{display:none}.gist .inline-comments{visibility:hidden}.gist .inline-comments .line-comments+.blob-num{border-left-width:1px}.gist .inline-comments .timeline-comment{margin-bottom:10px}.gist .inline-comments .inline-comment-form,.gist .inline-comments .inline-comment-form-container{max-width:780px}.gist .comment-holder{max-width:780px}.gist .line-comments+.line-comments,.gist .empty-cell+.line-comments{border-left:1px solid #eaecef}.gist .inline-comment-form-container .inline-comment-form,.gist .inline-comment-form-actions{display:none}.gist .inline-comment-form-container .inline-comment-form-actions,.gist .inline-comment-form{display:block}.gist body.split-diff .container,.gist body.full-width .container{width:100%;padding-right:20px;padding-left:20px}.gist body.split-diff .repository-content,.gist body.full-width .repository-content{width:100%}.gist body.split-diff .new-pr-form,.gist body.full-width .new-pr-form{max-width:980px}.gist body.split-diff .new-pr-form .discussion-sidebar,.gist body.full-width .new-pr-form .discussion-sidebar{width:200px}.gist .file-diff-split{table-layout:fixed}.gist .file-diff-split .blob-code+.blob-num{border-left:1px solid #f6f8fa}.gist .file-diff-split .blob-code-inner{word-wrap:break-word;white-space:pre-wrap}.gist .file-diff-split .empty-cell{cursor:default;background-color:#fafbfc;border-right-color:#eaecef}.gist .submodule-diff-stats .octicon-diff-removed{color:#cb2431}.gist .submodule-diff-stats .octicon-diff-renamed{color:#677a85}.gist .submodule-diff-stats .octicon-diff-modified{color:#d0b44c}.gist .submodule-diff-stats .octicon-diff-added{color:#28a745}.gist .BlobToolbar{left:-17px}.gist .BlobToolbar-dropdown{margin-left:-2px}.gist .task-list-item{list-style-type:none}.gist .task-list-item label{font-weight:normal}.gist .task-list-item.enabled label{cursor:pointer}.gist .task-list-item+.task-list-item{margin-top:3px}.gist .task-list-item .handle{display:none}.gist .task-list-item-checkbox{margin:0 0.2em 0.25em -1.6em;vertical-align:middle}.gist .reorderable-task-lists .markdown-body .contains-task-list{padding:0}.gist .reorderable-task-lists .markdown-body li:not(.task-list-item){margin-left:26px}.gist .reorderable-task-lists .markdown-body ol:not(.contains-task-list) li,.gist .reorderable-task-lists .markdown-body ul:not(.contains-task-list) li{margin-left:0}.gist .reorderable-task-lists .markdown-body li p{margin-top:0}.gist .reorderable-task-lists .markdown-body .task-list-item{padding-right:15px;padding-left:42px;margin-right:-15px;margin-left:-15px;border:1px solid transparent}.gist .reorderable-task-lists .markdown-body .task-list-item+.task-list-item{margin-top:0}.gist .reorderable-task-lists .markdown-body .task-list-item .contains-task-list{padding-top:4px}.gist .reorderable-task-lists .markdown-body .task-list-item .handle{display:block;float:left;width:20px;padding:2px 0 0 2px;margin-left:-43px;opacity:0}.gist .reorderable-task-lists .markdown-body .task-list-item .drag-handle{fill:#333}.gist .reorderable-task-lists .markdown-body .task-list-item.hovered{background:#fafafa;border-top-color:#ededed;border-bottom-color:#ededed}.gist .reorderable-task-lists .markdown-body .task-list-item.hovered>.handle{opacity:1}.gist .reorderable-task-lists .markdown-body{opacity:0}.gist .reorderable-task-lists .markdown-body{border-right-color:#ededed;border-left-color:#ededed}.gist .review-comment-contents .markdown-body .task-list-item{padding-left:42px;margin-right:-12px;margin-left:-12px;border-top-left-radius:3px;border-bottom-left-radius:3px}.gist .review-comment-contents .markdown-body .task-list-item.hovered{border-left-color:#ededed}.gist .highlight{padding:0;margin:0;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;font-size:12px;font-weight:normal;line-height:1.4;color:#333;background:#fff;border:0}.gist .render-viewer-error,.gist .render-viewer-fatal,.gist .render-viewer-invalid,.gist .octospinner{display:none}.gist iframe.render-viewer{width:100%;height:480px;overflow:hidden;border:0}.gist pre,.gist code{font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace !important;white-space:pre}.gist .gist-meta{padding:10px;overflow:hidden;font:12px -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";color:#586069;background-color:#f7f7f7;border-radius:0 0 2px 2px}.gist .gist-meta a{font-weight:600;color:#666;text-decoration:none;border:0}.gist .gist-data{overflow:auto;word-wrap:normal;background-color:#fff;border-bottom:1px solid #ddd;border-radius:2px 2px 0 0}.gist .gist-file{margin-bottom:1em;font-family:"SFMono-Regular", Consolas, "Liberation Mono", Menlo, Courier, monospace;border:1px solid #ddd;border-bottom:1px solid #ccc;border-radius:3px}.gist .gist-file article{padding:6px}.gist .gist-file .scroll .gist-data{position:absolute;top:0;right:0;bottom:30px;left:0;overflow:scroll}.gist .gist-file .scroll .gist-meta{position:absolute;right:0;bottom:0;left:0}.gist .blob-num{min-width:inherit;padding:1px 10px !important;background:transparent}.gist .blob-code{padding:1px 10px !important;text-align:left;background:transparent;border:0}.gist .blob-wrapper table{border-collapse:collapse}.gist .blob-wrapper tr:first-child td{padding-top:4px}.gist .markdown-body .anchor{display:none} /* Copyright 2017 AO Kaspersky Lab. All Rights Reserved. Anti-Sandboxing: Wait for Mouse Click PoC: RU: EN: */ #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; }


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:

  • 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

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:

  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

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>
[…] <LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x30000000″ ImageSize=”0x15d000″>
<ImagePath>\Device\HarddiskVolumeZ\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE</ImagePath>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x78e50000″ ImageSize=”0x1a9000″>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0x7de70000″ ImageSize=”0x180000″>
[…] [0YYY] >> SetWindowTextW (0000000000050018,00000000001875BC -> “e15b36c2e394d599a8ab352159089dd2.doc [Compatibility Mode] — Microsoft Word”) => 00000000390A056C {0000}
[…] <FILE_CREATED Pid=”0xYYY”>
<FILE_WRITE Pid=”0xYYY” Position=”0x0″ Size=”0x0000000000000001″>
<FILE_WRITE Pid=”0xYYY” Position=”0x1″ Size=”0x0000000000000001″>
<FILE_WRITE Pid=”0xYYY” Position=”0x2″ Size=”0x0000000000000001″>
[…] <FILE_WRITE Pid=”0xYYY” Position=”0x1afff” Size=”0x0000000000000001″>
[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”>
<LOAD_IMAGE Pid=”0xYYY” ImageBase=”0xcb90000″ ImageSize=”0x1b000″>
[…] [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_WRITE Pid=”0xZZZ” Position=”0x0″ Size=”0x000000000000DE00″>
[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_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>
<Name>\Device\HarddiskVolumeZ\Users\[HIDDEN_USER]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\{C2F5139C-7918-4CE6-A17C-77B9290128D8}.lnk</Name>
[…] [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”>
<CmdLine>&quot;%SYSTEM_ROOT%\Windows\System32\rundll32.exe&quot; &quot;%SYSTEM_ROOT%\Users\[HIDDEN_USER]\AppData\Local\FONTCACHE.DAT&quot;,#1</CmdLine>
[…] [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”>
<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>

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

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


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

Malware Alerts - Mon, 09/18/2017 - 05:00

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:

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

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

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

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:

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

Detecting Fraud

SANS Tip of the Day - Thu, 09/14/2017 - 01:00
Review your bank, credit card and financial statements regularly to identify unauthorized activity. This is one of the most effective ways to quickly detect if your bank account, credit card or identity has been compromised.

Connected Medicine and Its Diagnosis

Malware Alerts - Wed, 09/13/2017 - 05:00

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.

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.

Yes, naming policy can provide useful information about your infrastructure. Must read for medical facilities:

— Denis Makrushin (@difezza) March 16, 2017

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:

  • 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

Malware Alerts - Tue, 09/12/2017 - 05:00

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:

  • 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


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:

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


Unique Passwords

SANS Tip of the Day - Tue, 09/12/2017 - 01:00
Make sure each of your accounts has a separate, unique password. Can't remember all of your passwords/passphrases? Consider using a password manager to securely store all of them for you.

CEO Fraud

SANS Tip of the Day - Mon, 09/11/2017 - 01:00
CEO Fraud is a type of targeted attack. It commonly involves a cyber criminally pretending to be your boss, then tricking or fooling you into sending the criminal highly sensitive information or initiating a wire transfer. Be highly suspicious of any emails demanding immediate action and/or asking you to bypass any security procedures.

Satoshi Bomb

Malware Alerts - Thu, 09/07/2017 - 05:10

Let us discuss what defines the profitability of bitcoin mining, what principles for mining speed adaptation were initially embedded into it, and why these principles can lead to the failure of the cryptocurrency in the long run.

We assume that the reader has an idea of basic Bitcoin mechanics such as blockchains, mining, mining pools, and block rewards.

Note: In this article, we investigate a theoretical possibility of how the described scenario may evolve by considering the algorithms embedded in Bitcoin. Our goal was not to make a deep analysis of the structure of miner expenditures, electricity prices in different areas of the world, bank interest rates, or payback periods for equipment.

A 51% attack

The Bitcoin community is well aware of “51% attack”. If a miner controls more than a half of all of the mining hashrate, then he or she is capable of doing the following:

  1. Pay with his or her bitcoins for a commodity or service or exchange them for traditional money.
  2. Begin generating blocks that do not include the mentioned transaction, but not show the generated blocks to other miners.
  3. Wait until the commodity has been delivered.
  4. Publish the generated chain of blocks.

At the same time, the following happens:

  • All of the other miners will have to accept the fraudster’s blockchain version as the only one that is genuine because it is longer and the miner has a mining hashrate that is more powerful than that of all of the participants put together.
  • The fraudster receives the commodity and keeps his/her bitcoins, as he or she did not spend them in his or her version of history.
  • The fraudster receives the reward for all of the generated blocks, not for one half of the blocks, which is what they would generate if they were playing fair and adding blocks to a common chain.
  • The fraudster during the Attack will most likely buy coins of another cryptocurrency using bitcoins, as it is fast, quite safe, and irreversible.

The community concurs that such an attack if it were possible, would raise questions about the further existence of Bitcoin.

It is important to note that a successful attack does not necessarily entail a 51% or higher hashrate. There is some possibility that it can be carried out with a smaller hashrate share. For example, owning 30% of hashrate gives the attacker about an 18% chance of generating a chain of five blocks in a row, which would be longer than the shared one. In that case, the attacker gains all of the same privileges as in a 51% attack. In case of failure, the attacker can just try again. The majority of services that receive bitcoin payments require only five “confirmations”, which means that such a generated chain will be enough.

Adaptation of mining difficulty

After generation of a pack of 2016 blocks, the Bitcoin network adapts the difficulty of mining. The standard of difficulty is when the mining of one block takes around 10 minutes. Therefore, mining 2016 blocks will take two weeks. If the generation process took, for instance, only one week, then the difficulty will be increased twofold after the next reassessment (so that it would take two weeks to generate the next 2016 blocks at the same network hashrate).

It’s worth noting that the Bitcoin network uses software to prohibit changing the difficulty of mining more than four times per one reassessment.

There are direct consequences stemming from these rules. If mining hashrates are added or removed during a period of 2016 blocks, then the following occurs:

  • This does not affect the reward received by the remaining miners in any way. The reward is determined by the hashrate of a miner but not their share in the common hashrate. For example, after one half of the hashrates have been deactivated, the remaining miners will mine twice as many blocks; but this will require double the time. Income will be retained.
  • This directly affects the output rate. If 99% miners stop mining, then the next difficulty reassessment will occur in 4 years. Creation of one block will take about 16 hours.

The authors of Bitcoin assumed that the described algorithm would smoothly adjust network power by pushing out less power-efficient equipment and restoring the reasonable marginality of the remaining equipment. However, what this rare difficulty reassessment does is open the door to another strategy for miners: they may trick the algorithm by artificially lowering network performance. After all, when a rig is abruptly powered down, the revenue generated for the day stays at the same level; and when a rig is suddenly powered up, costs are lowered.

Mining fees and the free will of miners

In addition to receiving a reward for a block (of an emitted currency), miners also collect fees for transactions that are included in the block. As of today, the fees currently sit at approximately 10% of the block reward. We won’t dwell on this for too long, but, nevertheless, according to our estimations, it turns out that the existence of fees makes the miner strategy that we are researching here even more appealing.

Another aspect is that mining pools frequently do not directly control the mining rigs that are part of those pools. Each participant and rig owner is free to choose the pool that they will work in. The decision to move from one pool to another is usually based on economic grounds.

However, the person in charge of the pool determines the policy regarding powering up and powering down the rigs and switching the rigs to mine an alternative currency (Bitcoin Cash). In other words, we think that the described behavioral strategy should be adopted and implemented by only about 20 participants who are pool owners: the rig owners do not matter in the least here even though they possess their own “free will”.

Let’s suppose that the total hashrate of all of the miners has been stabilized and review one of the strategies for increasing marginality.

An example of miner behavior during a stable Bitcoin network hashrate

For the sake of simplicity, let’s assume that you control one half of all of the hashrates of the Bitcoin network. You can keep the rig turned on all the time and receive the reward for about 1008 blocks (50%).

You could also do the following:

  1. Wait until the next period of 2016 blocks.
  2. Turn off your mining rigs.
  3. Wait until the remaining miners get 2016 blocks within 4 weeks.
  4. After that, the Bitcoin network will halve the mining difficulty for the next period.
  5. You can turn on your rigs, and the entire network will mine 2016 blocks within one week.
  6. You will receive a reward for the same 1008 blocks (approximately) within just a week.

Please note the first scenario assumes that five weeks of regular operation will yield a reward for 5/2 × 1008 = 2520 blocks, but you would have to pay for electricity for the entire time period. The second scenario assumes that the same five weeks will yield a reward for 1008 blocks, but you would have to pay the electricity costs for only one week.

Let’s suppose that the electricity price comprises only about 90% of the reward. It is easy to calculate that the first scenario assumes that a five-week profit is equivalent to a reward for 2520 × 0.1 = 252 blocks, while the second scenario yields a reward for “reward − costs” = 1008 − 0.9 × 1008/2 = 554.4. This means that the proposed strategy turns out to be twice as lucrative.

Economically profitable miner behavior with different parameters

Let’s assume the following.

  • A smart miner controls a share x, of the total network hashrate.
  • The bitcoin reward for all of the 2016 blocks is A.
  • The electricity and maintenance costs for two weeks of network rig operation equals C. We assume that the rent of premises and downtime costs are insignificant. To simplify the calculation, we deliberately disregard the depreciation of the rig.

Thus, the following happens.

  1. A miner’s reward is Ax − Cx for the time period of two weeks of regular operation.
  2. If a smart miner turns off his mining rig, the network will produce 2016 blocks within the period that will take as much time.
    For example, if x = 1/3, then it will take one and a half as much time to finish the task.
  3. After the end of the period when the network adapts the difficulty, and the smart miner turns on the rig, the network will complete the task (1 − x) times faster than the planned two weeks.
    For example, if x = 1/3, then it will require 2/3rd of the regular time after the rig has been turned on, which is approximately 10 days.
  4. The total duration of the two periods will be () × (2 weeks);
  5. Thus, in regular conditions (without downtime), working during these two periods lets miners earn
    Pregular operation = () × (A − C) = () × (A − C)
    This means that all of the miners earn a little more than double the net profit for the prolonged conventional period.
  6. A smart miner who operates with downtime will earn nothing for the first period, but the second period (the shorter one) will yield
    Psmart = Ax − Cx(1 − x) = Ax − Cx + Cx2
    This means that the smart miner gains a single regular net profit and additionally saves up the share of x of the costs.
  7. During the slow period, all of the non-disconnected miners will earn Pslow period  = A − C,
    and for the fast period: Pfast period  = A − C (1 − x), as the reward is the same, but they work faster.

It is easy to see the following:

  • If the expenditures of miners are precisely equal to their rewards (the miners work with a margin of zero), then the clever approach would let them gain a net profit of Ax2.
  • If miners pay no electricity costs (a margin of 100%), then they will earn more than double the amount of income within the period of regular operation and a only one regular amount of income when working with downtime.
  • Let’s find out how much of the rig power x should be turned off in order to maximize the revenue for all miners with a margin of M = (A − C)/A:

maxx(Pslow period + Pfast period  − Pregular operation) =

maxx( − ()

maxx( − ()M)

maxx() =


This equation reaches its maximum at x = 1 −  . For example, smart miners should temporarily disable 80% of their rig power when M = 4%.

Why miners are not using the described strategy right now

The increase of hashrate on the Bitcoin network. The hashrate of the network has grown by 4 times in a year (Source)

The increase in difficulty on the Bitcoin network for the entire time period. Starting January 2016, the difficulty has been increased by 8 times, just like the value of bitcoin (Source)

The described strategy makes sense only under the condition that the overall network difficulty does not increase over time. Otherwise, turning off rigs will not lead to a decrease in difficulty, which makes this economically unviable.

Up until now, mining hashrates have been increasing at a fast tempo; this is a consequence of the growth of the bitcoin exchange rate. The income of miners is estimated in bitcoins, but they pay for costs in traditional currency.

The growth rate of bitcoin value (Source)

Nevertheless, it would be reasonable to suppose that if the bitcoin does not endlessly grow in price, then at some time introducing new mining hashrates would not be economically viable and electricity costs would sooner or later be practically equal to the reward.

The dangers of turning off mining hashrates

When new mining hashrates are no longer introduced, miners will may resort to the above-mentioned strategy.

An estimate of hashrate distribution among the largest mining pools (Source)

If mining pools maximize their own profit, then 75% of hashrates are expected to be turned off at a margin of 6.25%. There is no sense in switching off more rigs, as the network will not reduce its difficulty by more than 4 times.

After that, in order to carry out a 51% attack, a fraudster must either control more than one half of the remaining hashrate (which can be easily done with the current distribution of hashrates) or suddenly turn on more rigs than were working before (which is currently unfeasible, considering the share of the largest pool).

Now, the question arises as to whether attacking the network is profitable for a person who has invested considerable amounts into increasing mining hashrates. Well, the answer is “yes, it is profitable”. In case of low mining marginality, the price of the existing mining rig is decreased too. In other words, if mining brings no revenue, then playing honestly will no longer be viable. Aside from that, the attacking party may remain anonymous and, among other things, speculate for a fall of the bitcoin price.

A Bitcoin Cash attack

We are intentionally not considering a situation where the price of electricity quickly and significantly goes up or where the price of bitcoins falls quickly and by a significant amount (which is much more likely to happen). If that happens, then the miners’ strategy is quite obvious. During drastic price variations, all miners will turn off their rigs. Perchance, only those who take advantage of free electricity will stay afloat. In that case, network operation will simply stop: finishing the “two weeks” will require a lifetime, while the inability to carry out a transaction will lower the bitcoin’s price even more.

Our colleague from BitcoinMagazine analyzed the situation with the Bitcoin Cash currency just the other day. This currency appeared after Bitcoin network split on August 1, 2017. The new currency has a feature called Emergency Difficulty Adjustment (EDA). The EDA allows for adaptation of the difficulty on the Bitcoin Cash network even more often. This means that the difficulty is lowered by 20% if fewer than 6 blocks were mined in the span of 12 hours. The author comes to a conclusion similar to ours, but what’s more important is that he mentions that he has already been observing manipulations by smart miners. He fears destabilization of the Bitcoin Cash network and is counting on a prompt solution from developers.


We have analyzed one of the economically viable strategies of honest miners after the hashrate of the Bitcoin network stops growing. We have also calculated some of the key values of this strategy and inferred that using it is profitable for each individual participant but also considerably increases the risk of a 51% attack and a potential crash of the Bitcoin network as a whole.

If all of the miners were capable of coming to a solid agreement, they would go even further by turning off all but one of the rigs. This would be optimal in respect to revenue but fatal from the point of view of network security.

How should miners act in order to guarantee security? Here we can see a couple of analogies. The first one is an overproduction crisis. When this happens, manufacturers come to an agreement to publicly eliminate some of their products (at least, this was how it happened in the Middle Ages). The second one is nuclear disarmament, where countries that own large arsenals of nuclear weapons arrange for their proportional reduction.

Ideally, all miners should agree on turning off some of their rigs and, above all, on the controlled destruction of their rigs. It would be important not only to destroy rigs systematically but to control their production in a strict manner as well.

We do not have to rely on such a “peaceful” resolution. The recent split of the Bitcoin chain into two chains and the formation of Bitcoin Cash reveal that miners are not always able or have the desire to solve common problems together. It is possible that the ability to cooperate will become a decisive factor in the future.

Only time will tell how our theoretical research corresponds with actual practice.

Dissecting the Chrome Extension Facebook malware

Malware Alerts - Thu, 08/31/2017 - 07:00

It’s been a few days since Kaspersky Lab’s blog post about the Multi Platform Facebook malware that was spread through Facebook Messenger. At the same time as Kaspersky Lab were analyzing this threat, a few researchers where doing the same, including Frans Rosén, Security Advisor at Detectify.

After Frans saw David’s tweet about the blog post, he called David and asked why they were both doing the same job. Frans had a good point, so they started to compare notes and found out that Frans had actually analyzed some of the parts that David hadn’t. They decided to jointly write this second part of the analysis, which is going to describe the attack in detail.

Spreading mechanism

Frans spent quite some time analyzing the JavaScript and trying to figure out how the malware was spreading, which might seem like a simple task but it wasn’t. There were multiple steps involved trying to figure out what the Javascript payloads did. Also, since the script dynamically decided when to launch the attack, it had to be monitored when the attackers triggered it.

The conclusions can be broken down into a few steps, because it’s not only about spreading a link, the malware also notifies the attackers about each infection to collect statistics, and enumerates browsers. We tried summarizing the steps as simply as possible below:

  1. The victim receives a link on Facebook Messenger from a friend.
  2. The link goes to Google Docs with an image that looks like a fake video player with the friend’s profile picture.
  3. Clicking on that link using Chrome will send you to a fake YouTube page that asks you to install a Chrome Extension directly on the page.
  4. Installing that Chrome Extension will then spread malicious links to the victim’s online friends, combined with the victim’s profile picture.

There are some interesting things in all these steps, so we will take a closer look below.

Technical details Facebook message

The message itself will consist of the first name of the user that gets the message, the word “Video” and one of these emojis selected at random:

together with a link created with a URL shortener.

Google Docs shared PDF preview

Clicking on the link will redirect the user to a URL on This link is made by using the preview link of a shared PDF, most likely because it is the quickest way to get a large controlled content area on a legit Google domain with an external link.

The PDF itself is created using PHP with TCPDF 6.2.13 and then uploaded to Google Docs using Google Cloud Services. Clicking the will send us to a page containing details about the PDF file being previewed.

The share settings are an interesting detail about the link created:

“Anyone can edit”. This configuration means that anyone who has the link can actually edit it. Looking at how these links spread, the attack reuses the same link for all the victim’s friends. One friend changing the access rights of the link could potentially prevent the attack from spreading to the victim’s other friends.

Another interesting detail is the user who created the file. Collecting a bunch of examples, we can see some patterns:

These were four links created for different victims, but three of them share the same IAM username (ID-34234) even though they were created using different Google Cloud Projects.

At the time of the attack, none of the URLs being linked from the PDF preview were blacklisted by Google.

Redirect party

After the Google Docs link is clicked, the user will go through a bunch of redirects, most likely fingerprinting the browser. Below, we will focus on Chrome as it is clear it was one of the targeted browsers for the spreading mechanism.

For the other browsers, ads were shown and adware was downloaded, read more about this under Landing Pages below.

Fake YouTube page with Chrome Extension installation

When using Chrome, you are redirected to a fake YouTube page. We noticed several different domains being used during the attack.

This page will also ask you to install a Chrome Extension. Since you can install a Chrome Extension directly on the page, the only action the victim had to perform was to click “Add extension”. No other interaction after that point was needed from the victim for the attack to spread further.

Chrome Extension

Several different Chrome Extensions were used. All of the extensions were newly created and the code was stolen from legit extensions with similar names. The differences in the extensions’ Javascript code were the background.js and a modification in the manifest.json.

The manifest was changed to allow control over tabs and all URLs, and also to enable support for the background script:

The background script was obfuscated differently in all the Chrome Extensions we found, but the basic concept looked like this:

Obfuscated background script

This script was interesting in many ways.

First, the background script would fetch an external URL only if the extension was installed from the Chrome Webstore; a version installed locally using an unpacked extension would not trigger the attack.

The URL being fetched would contain a reference to another script. This script would be sent into a Javascript blob using URL.createObjectURL and then executed in the background script.

This new script from the blob would also be obfuscated. It looked like this:

What happens here is the following:

  1. Add a listener to all tabs when the tab has loaded successfully.
  2. When the tab is loaded, make a new request to another URL. If the response contains anything, it will send it to the tab that triggered it using executeScript. This will run the Javascript in the context of the tab making the request, basically injecting an XSS that will trigger directly.
Getting all the scripts

When doing the research trying to identify the file that was being injected, I noticed that the attackers’ command and control server did not always return any code. My guess is that they were able to trigger when the attack should spread or not either manually or by specify when the attack should start.

To avoid sitting and waiting for a request to hit, I built my own pseudo extension doing the same thing as they did, but instead of triggering the code, I saved it locally.

Browsing around for a while, I noticed I got a bunch of hits. Their endpoint was suddenly returning back code:

The code returned was not obfuscated in any way, and had a simple flow of what it should do. It was fully targeted towards Facebook.

The script did the following:

  • Check that the domain it ran on contained
  • Extract the CSRF token for a requests on Facebook, called fb_dtsg. Check if it had already fetched the access token (being used to make authenticated calls to the Facebook API). If not, it would make a request which is commonly made on Android to get the access token using the CSRF token.
  • Send the access token + profile ID to an external site owned by the attackers.
  • Make sure that the platform functionality is enabled (disabling the platform kill-switch):
  • Create a legacy access token. It turns out that Facebook has deprecated their FQL API, which is an old way of talking with the Facebook API:But the attackers found out that if you made an access token using the app called “Pages Manager for iOS”, the FQL API would still be enabled.

Now, let’s move on to the most interesting parts of what the script did.

Analytics for the attackers, liking a Facebook page

The script would like a page on Facebook that was hardcoded in the script. This was most likely used by the attackers to count the amount of infected users by keeping an eye on the amount of likes on this page.

Watching the page used during one phase of the attack, the amount increased fast, from 8,900 at one point:

and up to 32,000 just a few hours later:

It was also clear that they had control over when it should trigger or not using the script fetcher from the Command and Control, since the amount of likes increased at extremely varying speeds during the attack.

They also changed pages during the attack, most likely because they were closed down by Facebook.

Fetching your friends

Since the attackers now had an FQL-enabled access token, they could use the deprecated API to fetch the victim’s friends sorted by date of their online presence, getting the friends that were online at the time.

They randomized these friends picking 50 of them each time the attack would run only if the friends were marked as idle or online.

A link was then generated by a third domain, which only received the profile ID of the user. This site most likely created the PDF on Google Docs with the profile picture of the current victim and passed the public link back through a URL shortener.

After the link was fetched, a message was created randomly for each friend, but the link was reused among them.

Interesting details

Some parts of the injected code were never used, or were leftovers from previous attacks.

One part was the localization function to send messages in the proper locale of each friend. This was replaced by the random emoji in the live attack:


Some files on the domains used had some easy to guess PHP files still on the server such as login.php. That one exposed a login script to Facebook together with a hardcoded email address:


We noticed multiple versions of the injected Facebook script being used. At the end of the attack, the script only liked the Facebook page and did not spread at all. Also, the domain being used to gather access tokens was removed from the script.

Landing pages

As already mentioned, the script also enumerates which browser you are using. The Chrome extension part is only valid for victims using Google Chrome. If you are using a different browser, the code will execute other commands.

What makes this interesting is that they have added support for most of the operating systems; we were not able to collect any samples targeting the Linux operating system.

All of the samples that we collected where identified as Adware, and before the victim landed on the final landing page, they were redirected through several tracking domains displaying spam/ads. This is an indication that the people behind this scam were trying to earn money from clicks and distributing spam and ads.

  • MD5 (AdobeFlashPlayerInstaller.dmg) = d8bf71b7b524077d2469d9a2524d6d79
  • MD5 (FlashPlayer.dmg) = cfc58f532b16395e873840b03f173733
  • MD5 (MPlay.dmg) = 05163f148a01eb28f252de9ce1bd6978

These are all fake Adobe Flash updates, but the victim ends up at different websites every time, it seems that they are rotating a set of domains for this.

Mozilla Firefox
  • MD5 (VideoPlayerSetup_2368681540.exe) = 93df484b00f1a81aeb9ccfdcf2dce481
  • MD5 (VideoPlayerSetup_3106177604.exe) = de4f41ede202f85c370476b731fb36eb

“I was infected by this, what do I do?”

The Google Chrome Security Team has disabled all the malicious extensions, but when the attackers infected your Facebook profile they also stole an access-token from your Facebook account.

With this access-token the attackers will be able to gain access to your profile again, even if you have for example: Changed your password, signed out from Facebook or turned off the platform settings in Facebook:

We are currently discussing this with Facebook but at the moment it seems like there is no simple way for a victim to revoke the token the attackers stole.

It’s highly recommended that you update your Anti Virus solution because the malicious domains and scripts have been blocked.


The attack relied heavily on realistic social interactions, dynamic user content and legit domains as middle steps. The core infection point of the spreading mechanism above was the installation of a Chrome Extension. Be careful when you allow extensions to control your browser interactions and also make sure you know exactly what extensions you are running in your browser. In Chrome, you can write chrome://extensions/ in your URL field to get a list of your enabled extensions.

We would like to give out special thanks to the following people who helped us shut down the attack as much as possible:

  • Marc at CloudFlare
  • Trevor Pottinger at Facebook
  • April Eubank at Facebook
  • Rodrigo Paim at Facebook
  • Adam Rudderman and Jack Whitton of the Facebook Security team
  • Nav Jagpal at Google

Without your help this campaign would have been much more widespread. Thank you for your time and support! Also thanks to @edoverflow for poking at the obfuscated code at the same time as us.