Spotlight on Shamoon

Our analysis this month has pointed to Shamoon emerging in the Middle East. We have recently seen a number of similarities that we had highlighted in our earlier blogs (on The campaign continues to target organizations in the Middle East from a variety of verticals. Reports suggest that a further 15 disk-wiping Shamoon incidents have occurred in public and private sectors.

Rev.2 campaign

The code for the current revision is almost identical to the original version: Changes include the addition of a victim’s credentials to spread and execute the wiper in a large part of the environment. In the following screenshot, we can see that the old encoded resource names PKCS12, PKCS7, and X509 are still present in the new variants but not used.

Screen Shot 2017-01-27 at 10.47.27 AM

A question that many of us in the industry have asked ourselves is How were the attackers able to gain the credentials from so many victims in the Middle East? Let’s approach this from the attacker’s view and follow the Cyber Kill Chain steps.


An attack group prepares a plan and identifies the victims it wants to hit to create an impact or make a statement. The group gathers email addresses and other open-source intelligence as the first step to preparing for the campaign. They register domains, code backdoors, and prepare for the reconnaissance phase. When all is tested, the initial attack starts with spear phishing:

Screen Shot 2017-01-27 at 10.47.12 AM

The victims receive emails, for example, one like the preceding business proposal. The email also contains a tempting attachment. When opening the attachment, some victims saw this:

Screen Shot 2017-01-27 at 10.49.37 AM

Any requirement to activate macros before seeing content should set off alarm bells. Analyzing the document, we received confirmation of our suspicions:

Screen Shot 2017-01-27 at 10.46.48 AM

Decoding the obfuscated macro code results in a PowerShell script that proceeds to download a file, a Trojan capable of gathering system information and downloading other tools.

In other cases, we found a backdoor using a PowerShell script to gather information from the system and write to a temporary file. A code snippet:

Screen Shot 2017-01-27 at 10.46.25 AM

We also found a script that creates an instance of Mimikatz, a tool known to dump user credentials from a computer:

  • CreateMimi1.Bat or CreateMimi2.Bat

When all the data are gathered, the information is uploaded. To open a command channel, the attackers used, for example, a PowerShell script that launches Powercat, a TCP/IP “Swiss army knife” that works with netcat. A code example:

Screen Shot 2017-01-27 at 10.46.04 AM


The attackers invariably sort the credentials of the victims to gain an indication of the IP range and possible scale of the network. Depending on the goal of the attack, a selection of victims can be made to serve the cause. From the original Shamoon code, the current attackers have made several changes:

  • Added victims’ credentials
  • Replaced picture from flag to boy
  • Changed resource language to Yemeni Arabic
  • Tested samples

Delivery/Exploitation/Installation/Control servers/Action on objectives

In these phases, the actors needed only one or two hosts in the victim’s network as a beachhead to upload the wipers and scripts. Because the attackers already had valid credentials, no exploitation was needed.

Batch file:

Screen Shot 2017-01-27 at 10.45.44 AM

The batch file copies ntertmgr32.exe (one of many filenames of the Shamoon 2 variant) and starts it. Once the hardcoded date was reached, systems were wiped. Objective accomplished.

Actor sophistication

Our analysis of the execution of this attack tells a story about the actors capability and skills. Their attack precision is very good; they know whom and what to attack, in this case to disrupt and leave a statement. Their focus is on Windows and they use well-known practices to gather information and credentials, with no zero days. From a coding perspective, many security industry colleagues have already commented on the sloppy coding practices. From an operations security perspective—how well are the actors able to hide details that could lead to them?—we noticed that quite a few details are available: email addresses, program database paths, and Yemeni Arabic as the language identifier of almost all the samples, although we discovered one sample with a different language identifier. Was that on purpose, or a slip by the actor because this was a large campaign?



  • // domain registered on 2016-11-25 by [email protected]
  • hash 146a112cb01cd4b8e06d36304f6bdf7b and bf4b07c7b4a4504c4192bd68476d63b5 were connecting to this site


  • 146a112cb01cd4b8e06d36304f6bdf7b
  • bf4b07c7b4a4504c4192bd68476d63b5
  • a96d211795852b6b14e61327bbcc3473
  • 1507A4FDF65952DFA439E32480F42CCF1460B96F

File locations and filenames:

Collection of system information:

  • “%localappdata%\Microsoft\Windows\Tmp765643.txt” //where Tmp[6digits].txt is the syntax//

Filenames and Locations:

  • Microsoft\Windows\ccd
  • Microsoft\Windows\ccd6.exe”
  • Microsoft\Windows\ssc”
  • Microsoft\Windows\tss.ps1″
  • Microsoft\Windows\Tmp9932u1.bat”
  • Microsoft\Windows\Tmp765643.txt”
  • Microsoft\Windows\dp.ps1″
  • Microsoft\Windows\ccd61.ps1
  • Microsoft\Windows\dp.ps1″

Interesting strings in code samples:

  • F:\Projects\Bot Fresh\Release\Bot Fresh.pdb
  • F:\Projects\Bot\Bot\Release\Ism.pdb
  • G:\Projects\Bot\Bots\Bot5\Release\Ism.pdb


The post Spotlight on Shamoon appeared first on McAfee Blogs.

With Release of Windows 10, Questions About BitLocker Arise Again

This post was written by Ted Pan.

For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack and make sure we never again lost data.

What happened?

BitLocker is actually pretty good. It is nicely integrated into Windows, it does its job well, and it is really simple to operate. As it was designed to “protect the integrity of the operating system,” most who use it implemented it in TPM mode, which requires no user involvement to boot the machine.

And that’s where problems started.

Hands up: How many people have a TPM chip on their laptop? Everyone, we bet. It’s a ubiquitous piece of hardware nowadays. OK, another show of hands for those who have enabled, and taken ownership of the chip? “Taken ownership?” You remember going through the personalization phase of the chip, enabling it in the BIOS, etc.? Remember, all TPMs are shipped disabled and deactivated.

You didn’t do that before you deployed your laptops? In that case, BitLocker will be a bit of a struggle for you.

Fact 1. To use BitLocker without adding additional authentication, you need an enabled, owned TPM1.2+ hardware chip.

For those of you who did go through this, we congratulate you on your foresight. The only problem is:

Fact 2. BitLocker with TPM-only protection is vulnerable to cold boot, Firewire, and BIOS keyboard buffer attacks.

There are some pretty simple attacks on TPM-only machines. Search for “BitLocker Firewire,” “BitLocker cold boot,” or “BitLocker forensic tool” and you’ll find lots of research, and even a few tools that will unlock your nice “protected” machine and recover the data. There was even a trivial method that allowed an attacker to gain access to a BitLocker protected system as late as November 2015 (8 years after BitLocker’s initial release); this has only recently been patched.

To make a machine secure, and by that we mean give you protection against having to disclose lots of personal information to all your customers if the machine goes missing, you need to use some form of pre-Windows authentication (with or without TPM; it makes no difference). Even Microsoft recommends this mode of operation.

For BitLocker, turning on authentication gives you a couple of choices. You can set a pin for the machine, and, if you want, you can also use a USB storage device (a memory stick, not a smart card) as a token. We wrote “pin”; we certainly did not write “your Windows user ID and password.” In fact, we didn’t mention users at all. BitLocker officially supports one login, so if more than one person uses a machine, you’re going to have to share that with everyone.

Some more facts:

Fact 3. BitLocker is secure only if you use a pin or USB stick for authentication.

Fact 4. There is no link between your Windows credentials and BitLocker credentials. 

Fact 5. BitLocker does not support the concept of more than one user.

Even Microsoft’s official advice tells you to use a 6+char pin, plus TPM for authentication—no using it in TPM-only mode.

So now your lucky BitLocker users have PCs protected, maybe with a TPM, but certainly with some form of authentication that is shared between the owner of the machine and with you (as administrator), and probably the system guys. You probably have an Excel spreadsheet with everyone’s pin.

We hope so, because when those users start forgetting their pins, who’s at the end of the phone? The good news is the pin never changes. There’s no forced change or lifetime. That doesn’t fit with your password policy? Did we mention that the PIN can be made only from the function keys, not the normal letter keys, unless you configure a special enhanced PIN mode that does not work on non-USA keyboards? Did we mention there are no complexity or content rules apart from length? 

Fact 6. BitLocker PINs are usually Fn-key based. BitLocker does not support non-US keyboards.

For all of you who have implemented public key infrastructure smart cards, bought laptops with fingerprint sensors, or who have tokens such as ActivIdentity, common access cards, personal identity verification, etoken keys, Datakey cards, SafeNet cards, etc. You’d like to be able to use them for authentication to your PCs, wouldn’t you?

Fact 7. BitLocker supports only USB storage devices and PINs—no integration with any other token.

Fact 8. Active Directory and additional servers are required to administrate BitLocker in a corporate environment.

There are Active Directory–based methods. The Group Policy Object settings will let you store the (fixed) recovery key in your AD. I’m not sure how you feel about that data getting propagated to every controller in your forest, but I’m sure you know and trust every AD administrator in your organization who (now) has access to those keys. If someone were to dump those keys and then quit, what would you do? It’s not as if the key ever expires. We guess you could write a program and then run it on every machine to recreate the keys, or write down the recovery key and give it to the user to hold onto.

Let’s review why we are going through this effort. The flippant answer is “because we were told to secure our machines,” but what does that mean? Most likely your company falls under one of the 250+ global laws defining and mandating the protection of people’s personal data, social security numbers, health information, credit card numbers, etc. Regulations such as PCI, HIPAA, HITECH, SOX, etc. You want to use BitLocker to encrypt your machines because when they get lost or stolen, you won’t have to pay fines, or tell everyone you lost their data. You lost the machine, sure, but because the data was encrypted, no one can get access to it.

To use this “get out of jail” card you need to be able to prove a couple of things:

  • That the data was indeed protected at the time of loss.
  • That the protection method was appropriate given the type of data.

So, applying those tests, a rule appears: 

Fact 9. You need extra software to prove BitLocker was enabled and protecting the drive at the time of the theft to claim protection from personally identifiable information laws.

We know how to set GPOs etc. to mandate the use of BitLocker, but we also know how easy it is for a user to turn it off. Setting up an MBAM server with all its associated requirements (such as an additional SQL server) would increase your complexity as well as causing you to write scripts to perform automated deployments. We don’t know of anything in Active Directory that gives me a definitive answer as to the state of protection of a given machine. There’s even a command-line tool that can be run to completely (un)configure it. We need something that reports on the state of protection of a lost machine. Saying “Well, the policy says it should be encrypted” is not enough. Perhaps a reader can help out?

Let’s finally take a look at implementing this solution. You do have a 100% Windows enterprise environment, don’t you? What if you still have some XP, Vista, Business, or Macs? Are you going to leave those machines unprotected, or are you planning to run a mix of third-party software and BitLocker? 

Fact 10. BitLocker encryption and administration supports only Windows—with no support for other operating systems, such as Mac or Linux.

You may think that we are not great fans of BitLocker—yet that’s far from the truth. We would use it, and would recommend it to friends. We see it as really good for technical, trustworthy users. But that’s not the market it’s being promoted for. Nothing fills us with dread more than an enterprise product that requires yet another password, requires specific hardware that is not enabled by default, presents a black screen with white text to users (so archaic), does not conform to our recognized password/PIN lifetime policies, does not work on non-USA machines, and does not have audit-friendly output for the main purpose it serves, namely, to tell us whether this stolen machine is a liability.

One of us actually likes it for the following reasons:

  • Only one of the three machines he uses has a USA keyboard, so he can use Fn-mode PINs.
  • It never forces him to change his PIN.
  • He can turn it on and off whenever he likes without corporate IT people knowing.
  • He gets to use the TPM chip, even though it took him a whole day to work out how to enable it.
  • He can write fancy scripts to turn it on and off. (He’s a closet programmer.)
  • He gets a nice DOS-like screen when he turns on his machine, just like 20 years ago.
  • BitLocker is mostly controlled through a command-line script (Manage-bde).
  • His local IT team can’t come and use his machine, or see what’s stored on it without his knowing.
  • He just likes things to be done the hard way.

The post With Release of Windows 10, Questions About BitLocker Arise Again appeared first on McAfee Blogs.

Analyzing KillDisk Ransomware, Part 1: Whitelisting

At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how to unlock the locked screen in an infected system (with a demo video).

KillDisk demands a pretty high ransom: 222 Bitcoins (around US$170,000).

KillDisk Ransom-note (Infected Machine)

The KillDisk ransom note. 

KillDisk is data-wiping malware, and is generally used by other malware to hide their artifacts from an infected system. BlackEnergy is one brand of malware that uses KillDisk.

Recently, the author of KillDisk enhanced the malware by adding the ransomware capability. This ransomware targets both Windows and Linux systems. It encrypts files, blocks the screen, and demands an unusually high ransom. We analyzed the Windows variant and found some interesting things.


During our analysis of KillDisk, we saw little file system activity. To remove its(or its component’s) execution traces from the infected system, KillDisk uses the Windows event utility (wevtutil). One statement from Microsoft about wevtutil:

“Wevtutil enables you to retrieve information about event logs and publishers. You can also use this command to install and uninstall event manifests, to run queries, and to export, archive, and clear logs.”

KillDisk executes these commands before starting its encryption process:

  • wevtutil clear-log application
  • wevtutil clear-log security
  • wevtutil clear-log setup
  • wevtutil clear-log system

This malware has a complex routine that decrypts the DLL names, API names, file extensions, process names, and other strings including the preceding commands. This screenshot illustrates:

Decryption Routine

Decryption routine.

KillDisk targets the following files:

.pdb .vbm .vbk .dat .crt .key .kdbx .bak .back .dr .bkf .cfg .fdb .mdb .accdb .gdb .wdb .csv .sdf .myd .dbf .sql .edb .mdf .ib .db3 .db4 .accdc .mdbx .sl3 .sqlite3 .nsn .dbc .dbx .sdb .ibz .sqlite .ova .vmdk .vhd .vmem .vdi .vhdx .vmx .ovf .vmc .vmfx .vmxf .hdd .vbox .vcb .vmsd .vfd .pvi .hdd .bin .avhd .vsv  .iso .nrg .disk .hdd .pmf .vmdk .xvd .dev .pem .jrs .cer .pvk .pfx .pd .pio .csr .crl .p7c .piz .p7b .spc .p7r .io .pyc .dwg .max .dxf .3ds .ai .conf .my .ost .pst .mkv .mp3 .wav .oda .sh .py .ps .ps1 .php .aspx .asp .rb .js .git .mdf .pdf .djvu .doc .docx .xls .xlsx .jar .ppt .pptx .rtf .vsd .vsdx .jpeg .jpg .png . tiff .msi .zip .rar  .7z .tar .gz .eml .mail .ml

After encryption, the files have the same extensions but the data is encrypted, with the addition of 0x98 bytes at the end of each file. The first 0x80 bytes are related to the key and the next 0x18 bytes are the ransomware message, shown below


KillDisk also uses these 0x18 bytes as an infection marker, to avoid multiple encryptions of already locked files. The following screenshot shows the appended data in an encrypted file:

Appended Data/Signature in Encrypted file

The appended data/signature in an encrypted file.

Whitelisting to avoid analysis

We have observed some malware use blacklisting methods to kill analysis tools: If they find antimalware or related applications, they will terminate that process. But this malware uses the opposite technique of whitelisting: It maintains a list of benign processes, checks the system for them, and stores their process IDs (PIDs) along with its PID. After generating the PID list, the malware again enumerates the running processes and terminates those that are not on its generated PID list.

The following chart illustrates both blacklist and whitelist techniques:

Blacklist Flowchart             WhiteList Guard Flowchart

                  Blacklist flowchart.                                                             Whitelist flowchart.

The whitelist technique works pretty well under automation environments such as the Cuckoo sandbox, etc.

Debugger evasion via whitelist

The malware retrieves its PID using the GetCurrentProcessId function so that while debugging the process in any debugger—OLLY, IDA, etc.—the function will return the malware’s PID and not the debugger’s. Thus, the PID whitelist created by the malware will not contain the debugger’s PID. When the malware executes its termination routine using TerminateProcess API, the debugger’s process will be killed.

The following screenshot shows disassembly of the code that terminates calc.exe because the process name is not on malware’s whitelist.

Terminating calc.exe

Terminating calc.exe.

However, we see not only the termination of the debugger process, but also of the child-sample process. We did not expect this behavior because the malware is using the TerminateProcess() API, which kills only the specified process not child processes.

Why are the child processes also terminated? It’s because of how the debugger creates its child processes. The debugger creates its child processes using specific creation flags related to debugging. The debugger uses the DEBUG_ONLY_THIS_PROCESS/DEBUG_PROCESS flag while calling the CreateProcess() API. Due to this flag, when the parent process gets terminated, the child processes die as well.

KillDisk’s whitelist consists of Windows and antimalware process names, including McAfee products.

Why are antimalware process names part of the malware’s whitelist? It may be because AV products generally use protection techniques so that other processes can’t kill their processes, and they may check on any process that wants to kill their processes. We think the malware author does not want to give the AV processes any indication of the malware’s existence.

The whitelisted process names:

smss.exe, csrss.exe, wininit.exe, services.exe, lsass.exe, lsm.exe, svchost.exe, winlogon.exe, explorer.exe, dwm.exe, wuauclt.exe,spoolss.exe, spoolsv.exe, taskhost.exe, conhost.exe, shutdown.exe, avp.exe, avpui.exe, ekrn.exe, egui.exe, mfemmc.exe, mfefire.exe, mfevtps.exe, pefservice.exe, mcsvhost.exe, msascui.exe, msmpeng.exe, mpcmdrun.exe

There is a typo in this list related to one McAfee process name. Our mfemms.exe is part of the McAfee Management service, but the malware looks for the process name mfemmc.exe.


KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself, although it looks unstable because it kills all the other processes in the system. This malware has some coding bugs but can still badly harm its victims by encrypting files and demanding a huge ransom. This might be a beta version of this malware; we could see an updated version in the near future.

The second part of this post will contain our analysis of the malware’s other variants, along with some techniques including how to unlock the locked screen on an infected system (with a demo video).

McAfee products detect all known variants of this malware.

Thanks to Vikas Taneja for his valuable input.


The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

Stopping Malware With a Fake Virtual Machine

As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic.

Some malware use a mutex or registry key to avoid re-infecting a machine. For example, a previous version of Locky used a registry key with the string “locky” to check if the machine was already infected. This variant also used a basic check to verify if the local language was Russian; if it was, the ransomware did not infect the machine. With this kind of information, security analysts can proactively configure these artefacts to boost protection against some malicious software.

The following diagram illustrates this concept:

20170118 Roccia fake vm 1


Proof of concept functions

Sandboxes and virtual environments are full of artefacts that betray their analysis environment. Malware can protect itself against these by running some checks to detect such environments before performing any malicious actions. Our POC will reproduce a virtual environment on a normal user machine. It is available at

Creating fake registry keys

A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor.

The following list shows of few of the potential registry keys that malware can detect:

  • HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
  • HKLM\SOFTWARE\VMware, Inc.\VMware Tools
  • HKLM\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
  • HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
  • HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions

The following function explains in more detail the registry key creation process:

HKEY_LOCAL_MACHINE, // registry key
RegValuePath[i], // subkey
0, // reserved and must be 0
NULL, // class type of the key
REG_OPTION_NON_VOLATILE, // keep the key after reboot
KEY_WRITE, // registry key security and access right
NULL, // security attributes
&hKey, // handle to the opened key
NULL) // determine weither the key exists or not


Other API functions are used to set a value on a previously created key (RegOpenKeyEx, RegSetValueEx).

Creating fake processes

The hypervisor runs several processes in the virtual machine to perform actions and ensure compatibility with the host machine. For example, VirtualBox uses several processes on a machine that can be spotted by malware.

The following list shows processes created by VirtualBox:

  • exe
  • exe
  • exe

The function CreateProcess can be used to load a fake process into memory:

ProcessName[i], // name of the fake process
NULL, // additional command line
NULL, // security attributes
NULL, // security attributes
FALSE, // handle are not inherited
CREATE_SUSPENDED, // create the process in suspended mode to avoid resource consumption
NULL, // pointer to the environment block
NULL, // specific directory for the file
&si, // startup info
&pi) // process info


Creating fake files

Malware can also try to detect the presence of any files related to virtual environments. A lot of driver or DLL files are created by the hypervisor.

The following list shows a short extract of potential virtual files:

  • C:\\WINDOWS\system32\drivers\VBoxMouse.sys
  • C:\\WINDOWS\system32\vboxhook.dll
  • C:\\WINDOWS\system32\vboxdisp.dll
  • C:\\Windows\system32\drivers\vmmouse.sys
  • C:\\system32\drivers\vmhgfs.sys

The function CreateFile can be used to create fake files on the system:

fname[i],// open file
GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
OPEN_ALWAYS, // open or create
NULL) == INVALID_HANDLE_VALUE) // no attribute template


Creating a fake MAC address

VirtualBox and VMware use default MAC addresses on virtual machines. The VirtualBox default address uses the first three bytes 08:00:27. The VMware default address uses the first three bytes 00:0C:29, 00:1C:14, 00:50:56, or 00:05:69. Malware can detect these MAC addresses by requesting the following registry key:



Proof of Concept

We have tested some samples with “VM aware” capabilities with our tool. In each case the malware did not run and the machine was not infected.

The tool Pafish, an open-source project, uses similar tricks as malware to identify virtual environments. We used Pafish to observe the difference between a normal machine and a machine set up with our tool emulating a virtual machine.

The following screenshot shows the output of Pafish with few detections of a virtual environment:

20170118 Roccia fake vm 2

After running our tool, we can clearly see the differences in detection.

20170118 Roccia fake vm 3

On the left we see the output of RocProtect, our proof of concept, which created fake artefacts on the machine. On the right we see the output of Pafish that shows us the number of detections.

Malware is constantly becoming more advanced. Analysis and detection are become harder and very time consuming. This proof of concept introduces a different way to protect against malware infections by emulating a virtual environment. Of course, this tool cannot replace a real security application, but it can complement your defenses. Sometimes we need to try different tactics to fight malware.

The post Stopping Malware With a Fake Virtual Machine appeared first on McAfee Blogs.