Spanish MSSP Targeted by BitPaymer Ransomware

Initial discovery

This week the news hit that several companies in Spain were hit by a ransomware attack. Ransomware attacks themselves are not new but, by interacting with one of the cases in Spain, we want to highlight in this blog how well prepared and targeted an attack can be and how it appears to be customized specifically against its victims.

In general, ransomware attacks are mass-spread attacks where adversaries try to infect many victims at the same time and cash out quickly. However, this has significantly changed over the past two years where more and more ransomware attacks are targeting high-value targets in all kinds of sectors.

Victims are infected with a different type of malware before the actual ransomware attack takes place. It looks like adversaries are using the infection base to select or purchase the most promising victims for further exploitation and ransomware, in a similar way to how the sale of Remote Desktop Access on underground forums or private Telegram channels is being used for victim selection for ransomware attacks.

In the following paragraphs, we will take you step by step through the modus operandi of the attack stages and most important techniques used and mapped against the MITRE ATT&CK Framework.

The overall techniques observed in the campaign and flow visualization:

Technical Analysis

The overall campaign is well known in the industry and the crew behind it came back to the scene reusing some of the TTPs observed one year ago and adding new ones like: privilege escalation, lateral movement and internal reconnaissance.

Patient 0 – T1189 Drive-by Compromise

The entry point for these types of campaigns starts with a URL that points the user to a fake website (in case the website is compromised) or a legitimate page (in case they decided to use a pay-per-install service) using social engineering techniques; the user gets tricked to download the desired application that will use frameworks like Empire or similar software to download and install next stage malware which, in this case, is Dridex.

First infection – T1090 Connection Proxy

These types of attacks are not limited to one type of malware; we have observed it being used by:

  • Azorult
  • Chthonic
  • Dridex

It is currently unclear why one would select one malware family above the other, but these tools allow for remote access into a victim’s network. This access can then be used by the actor as a launchpad to further exploit the victim’s network with additional malware, post-exploitation frameworks or the access can be sold online.

For quite some time now, Dridex’s behavior has changed from its original form. Less Dridex installs are linked to stealing banking info and more Dridex infections are becoming a precursor to a targeted ransomware attack.

This change or adaptation is something we have observed with other malware families as well.

For this campaign, the Dridex botnet used was 199:

Information Harvesting – T1003 Credential Dumping

From the infection, one or multiple machines are infected, and the next step is to collect as many credentials as they can to perform lateral movement. We observed the use of Mimikatz to collect (high privileged) credentials and re-use them internally to execute additional software in the Active Directory servers or other machines inside the network.

The use of Mimikatz is quite popular, having been observed in the modus operandi of more than 20 different threat actors.

Lateral Movement – T1086 PowerShell

The use of PowerShell helps attackers to automate certain things once they are in a network. In this case, we observed how Empire was used for different sock proxy PowerShell scripts to pivot inside the network:

Extracting information about the IP found in the investigation, we observed that the infrastructure for the Dridex C2 panels and this proxy sock was shared.

PowerShell was also used to find specific folders inside the infected systems:

A reason for an attacker to use a PowerShell based framework like Empire, is the use of different modules, like invoke-psexec or invoke-mimikatz, that can execute remote processes on other systems, or get credentials from any of the systems where it can run Mimikatz. When deployed right, these modules can significantly increase the speed of exploitation.

Once the attackers collected enough high privileged accounts and got complete control over the Active Directory, they would then distribute and execute ransomware on the complete network as the next step of their attack, in this case BitPaymer.

Ransomware Detonation – T1486 Data Encrypted for Impact

BitPaymer seemed to be the final objective of this attack. The actors behind BitPaymer invest time to know their victims and build a custom binary for each which includes the leet-speek name of the victim as the file extension for the encrypted files, i.e. “financials.<name_of_victim>”.

In the ransomware note, we observed the use of the company name too:


  • One of the remote proxy servers used in the operation shares the same infrastructure as one of the C2 panels used by Dridex.
  • We observed how a Dridex infection served as a launch point for an extensive compromise and BitPaymer ransomware infection.
  • Each binary of Bitpaymer is specially prepared for every single target, including the extension name and using the company name in the ransomware note.
  • Certain Dridex botnet IDs are seen in combination with targeted BitPaymer infections.
  • Companies must not ignore indicators of activity from malware like Dridex, Azorult or NetSupport; they could be a first indicator of other malicious activity to follow.
  • It is still unclear how the fake update link arrived at the users but in similar operations, SPAM campaigns were most likely used to deliver the first stage.

McAfee Coverage

Based on the indicators of compromise found, we successfully detect them with the following signatures:

  • RDN/Generic.hbg
  • Trojan-FRGC!7618CB3013C3
  • RDN/Generic.dx

The C2 IPs are tagged as a malicious in our GTI.

McAfee ATD Sandbox Detonation

Advanced Threat Detection (ATD) is a specialized appliance that identifies sophisticated and difficult to detect threats by executing suspicious malware in an isolated space, analyzing its behavior and assessing the impact it can have on an endpoint and on a network.

For this specific case, the ATD sandbox showcases the activity of Bitpaymer in a system:

We observe the use of icacls and takeown to change permissions inside the system and the living off the land techniques are commonly used by different type of malware.

ATD Sandbox extracted behavior signatures observing Bitpaymer detonation in the isolated environment:

Having the opportunity to detonate malware in this environment could give indicators about the threat types and their capabilities.

McAfee Real Protect

Analysis into the samples garnered from this campaign would have been detected by Real Protect. Real Protect is designed to detect zero-day malware in near real time by classifying it based on behavior and static analysis. Real Protect uses machine learning to automate classification and is a signature-less, small client footprint while supporting both offline mode and online mode of classification. Real Protect improves detection by up to 30% on top of .DAT and McAfee Global Threat Intelligence detections, while producing actionable threat intelligence.


We have a YARA rule available on our ATR GitHub repository to detect some of the versions of BitPaymer ransomware.


The post Spanish MSSP Targeted by BitPaymer Ransomware appeared first on McAfee Blogs.

Buran Ransomware; the Evolution of VegaLocker

McAfee’s Advanced Threat Research Team observed how a new ransomware family named ‘Buran’ appeared in May 2019. Buran works as a RaaS model like other ransomware families such as REVil, GandCrab (now defunct), Phobos, etc. The author(s) take 25% of the income earned by affiliates, instead of the 30% – 40%, numbers from notorious malware families like GandCrab, and they are willing to negotiate that rate with anyone who can guarantee an impressive level of infection with Buran. They announced in their ads that all the affiliates will have a personal arrangement with them.

For this analysis we present, we will focus on one of the Buran hashes:

We will highlight the most important observations when researching the malware and will share protection rules for the endpoint, IOCs and a YARA rule to detect this malware.

Buran Ransomware Advertisement

This ransomware was announced in a well-known Russian forum with the following message:


Buran is a stable offline cryptoclocker, with flexible functionality and support 24/7.


Reliable cryptographic algorithm using global and session keys + random file keys;
Scan all local drives and all available network paths;
High speed: a separate stream works for each disk and network path;
Skipping Windows system directories and browser directories;
Decryptor generation based on an encrypted file;
Correct work on all OSs from Windows XP, Server 2003 to the latest;
The locker has no dependencies, does not use third-party libraries, only mathematics and vinapi;

The completion of some processes to free open files (optional, negotiated);
The ability to encrypt files without changing extensions (optional);
Removing recovery points + cleaning logs on a dedicated server (optional);
Standard options: tapping, startup, self-deletion (optional);
Installed protection against launch in the CIS segment.


They are negotiated individually for each advert depending on volumes and material.

Start earning with us!


The announcement says that Buran is compatible with all versions of the Windows OS’s (but during our analysis we found how, in old systems like Windows XP, the analyzed version did not work) and Windows Server and, also, that they will not infect any region inside the CIS segment. Note: The CIS segment belongs to ten former Soviet Republics: Armenia, Belarus, Kazakhstan, Kyrgyzstan, Moldova, Russia, Tajikistan, Turkmenistan, Ukraine, and Uzbekistan.

Rig Exploit Kit as an Entry Vector

Based upon the investigation we performed, as well as research by “nao_sec” highlighted in June 2019, we discovered how Buran ransomware was delivered through the Rig Exploit Kit. It is important to note how the Rig Exploit Kit is the preferred EK used to deliver the latest ransomware campaigns.


The Rig Exploit Kit was using CVE-2018-8174 (Microsoft Internet Explorer VBScript Engine, Arbitrary Code Execution) to exploit in the client-side. After successful exploitation this vulnerability will deliver Buran ransomware in the system.

Static Analysis

The main packer and the malware were written in Delphi to make analysis of the sample more complicated. The malware sample is a 32-bit binary.


In our analysis we detected two different versions of Buran, the second with improvements compared to the first one released.


The goal of the packer is to decrypt the malware making a RunPE technique to run it from memory. To obtain a cleaner version of the sample we proceed to dump the malware from the memory, obtaining an unpacked version.

Country Protection

Checking locales has become quite popular in RaaS ransomware as authors want to ensure they do not encrypt data in certain countries. Normally we would expect to see more former CIS countries but, in this case, only three are verified.


This function gets the system country and compares it with 3 possible results:

  • 0x177 -> BELARUS
  • 0x17C -> UKRAINE

It is important to note here that the advertising of the malware in the forums said it does not affect CIS countries but, with there being 10 nations in the region, that is obviously not entirely accurate.

If the system is determined to be in the Russian Federation, Belarus or Ukraine the malware will finish with an “ExitProcess”.

The next action is to calculate a hash based on its own path and name in the machine. With the hash value of 32-bits it will make a concat with the extension “.buran”. Immediately after, it will create this file in the temp folder of the victim machine. Importantly, if the malware cannot create or write the file in the TEMP folder it will finish the execution; the check will be done extracting the date of the file.


If the file exists after the check performed by the malware, the temporary file will be erased through the API “DeleteFileW”.


This function can be used as a kill switch to avoid infection by Buran.

Buran ransomware could accept special arguments in execution. If it is executed without any special argument, it will create a copy of Buran with the name “ctfmon.exe” in the Microsoft APPDATA folder and will launch it using ShellExecute, with the verb as “runas”. This verb is not in the official Microsoft SDK but, if we follow the MSDN documentation to learn how it works, we can deduce that the program will ignore its own manifest and prompt the UAC to the user if the protection is enabled.

This behavior could change depending on the compilation options chosen by the authors and delivered to the affiliates.

According to the documentation, the function “CreateProcess” checks the manifest, however in Buran, this is avoided due to that function:


Buran in execution will create a registry key in the Run subkey section pointing to the new instance of the ransomware with a suffix of ‘*’. The meaning of this value is that Buran will run in safe mode too:


The writing operation in the registry is done using the “reg” utility, using a one-liner and concatenating different options with the “&” symbol. This method through “reg.exe” avoids a breakpoint in the main binary.


Buran implements this technique with the objective of making analysis of the sample complicated for malware analysts looking at reverse engineering profiles. After these operations, the old instance of the ransomware will die using “Exit Process”.

Analysis of the Delphi code show that the 2nd version of Buran will identify the victim using random values.


After that it will decrypt a registry subkey called “Software\Buran\Knock” in the HKEY_CURRENT_USER hive. For the mentioned key it will check the actual data of it and, if the key does not exist, it will add the value 0x29A (666) to it. Interestingly, we discovered that GandCrab used the same value to generate the ransom id of the victim. If the value and subkey exists the malware will continue in the normal flow; if not, it will decrypt a URL ,“”, and make a connection to this domain using a special user agent:


As mentioned, the referrer will be the victim identifier infected with Buran.

The result of this operation is the writing of the subkey previously checked with the value 0x29A, to avoid repeating the same operation.

After this action the malware will enumerate all network shares with the functions :

  • WNetOpenEnumA,
  • WNetEnumResourceA
  • WNetCloseEnum

This call is made in a recursive way, to get and save all discovered shared networks in a list. This process is necessary if Buran wants to encrypt all the network shares as an addition to the logical drives. Buran will avoid enumerating optical drives and other non-mounted volumes. The result of those operations will be saved for Buran to use later in the encryption process.

The ransom note is crypted inside the binary and will be dumped in execution to the victim’s machine. Inside this ransom note, the user will find their victim identifier extracted with the random Delphi function mentioned earlier. This identification is necessary to track their infected users to affiliates to deliver the decryptor after the payment is made.

In the analysis of Buran, we found how this ransomware blacklists certain files and folders. This is usually a mechanism to ensure that the ransomware does not break its functionality or performance.

Blacklisted folders in Buran:

Blacklisted files in Buran:

The encryption process will start with special folders in the system like the Desktop folder. Buran can use threads to encrypt files and during the process will encrypt the drive letters and folders grabbed before in the recognition process.

The ransom note will be written to disk with the name “!!! YOUR FILES ARE ENCRYPTED !!!” with the following content:


Each file crypted is renamed to the same name as before but with the new extension of the random values too.

For example: “rsa.bin.4C516831-800A-6ED2-260F-2EAEDC4A8C45”.

All the files encrypted by Buran will contain a specific filemarker:


In terms of encryption performance, we found Buran slower compared to other RaaS families. According to the authors’ advertisement in the underground forums, they are continually improving their piece of ransomware.

Buran Version 1 vs Buran Version 2

In our research we identified two different versions of Buran. The main differences between them are:

Shadow copies delete process:

In the 2nd version of Buran one of the main things added is the deletion of the shadow copies using WMI.

Backup catalog deletion:

Another feature added in the new version is the backup catalog deletion. It is possible to use the Catalog Recovery Wizard to recover a local backup catalog.

System state backup deletion:

In the same line of system destruction, we observed how Buran deletes in execution the system state backup in the system:

Ping used as a sleep method:

As a poor anti-evasion technique, Buran will use ping through a ‘for loop’ in order to ensure the file deletion system.

The ransom note changed between versions:

VegaLocker, Jumper and Now Buran Ransomware

Despite the file marker used, based on the behavior, TTPs and artifacts in the system we could identify that Buran is an evolution of the Jumper ransomware. VegaLocker is the origin for this malware family.

Malware authors evolve their malware code to improve it and make it more professional. Trying to be stealthy to confuse security researchers and AV companies could be one reason for changing its name between revisions.

This is the timeline of this malware family:

Similarities in Behavior:

Files stored in the temp folder:




Registry changes:



Extension overlapping:

In one of the variants (Jumper) it is possible to spot some samples using both extensions:

  • .vega
  • .jamper

Shadow copies, backup catalog and systembackup:

In the analyzed samples we saw how VegaLocker used the same methods to delete the shadow copies, backup catalog and the systembackup.


  • RDN/Ransom
  • Ransomware-GOS!E60E767E33AC
  • Ransom
  • RDN/Ransom
  • RDN/
  • Ransom-Buran!

Expert Rule:

Indicators of Compromise


The sample uses the following MITRE ATT&CK™ techniques:

  • Disabling Security Tools
  • Email Collection
  • File and Directory Discovery
  • File Deletion
  • Hooking
  • Kernel Modules and Extensions
  • Masquerading
  • Modify Registry
  • Network Service Scanning
  • Peripheral Device Discovery
  • Process Injection
  • Query Registry
  • Registry Run Keys / Start Folder
  • Remote Desktop Protocol
  • Remote System Discovery
  • Service Execution
  • System Time Discovery
  • Windows Management Instrumentation


We created a YARA rule to detect Buran ransomware samples and the rule is available in our GitHub repository


Buran represents an evolution of a well-known player in the ransomware landscape. VegaLocker had a history of infections in companies and end-users and the malware developers behind it are still working on new features, as well as new brands, as they continue to generate profits from those actions. We observed new versions of Buran with just a few months between them in terms of development, so we expect more variants from the authors in the future and, perhaps, more brand name changes if the security industry puts too much focus on them. We are observing an increase in ransomware families in 2019, as well as old players in the market releasing new versions based on their own creations.

For the binaries, all of them appeared with a custom packer and already came with interesting features to avoid detection or to ensure the user must pay due to the difficulty of retrieving the files. It mimics some features from the big players and we expect the inclusion of more features in future developments.

Buran is slower than other ransomware families we observed, and samples are coded in Delphi which makes reverse engineering difficult.

The post Buran Ransomware; the Evolution of VegaLocker appeared first on McAfee Blogs.

Office 365 Users Targeted by Voicemail Scam Pages

Over the past few weeks McAfee Labs has been observing a new phishing campaign using a fake voicemail message to lure victims into entering their Office 365 email credentials. At first, we believed that only one phishing kit was being used to harvest the user’s credentials. However, during our investigation, we found three different malicious kits and evidence of several high-profile companies being targeted. McAfee Customers using VSE, ENS, Livesafe, WebAdvisor and MGW are protected against this phishing campaign.

The attack begins when the victim receives an email informing them that they have missed a phone call, along with a request to login to their account to access their voicemail.

An example of the malicious email is shown below:

The phishing email contains a HTML file as an attachment which, when loaded, will redirect the user to the phishing website. There are slight variations in the attachment, but the most recent ones contain an audio recording of someone talking which will lead the victim to believe they are listening to the beginning of a legitimate voicemail.

The HTML code which plays the recording is shown below:

Once redirected, the victim is shown the phishing page which asks them to log into their account. The email address is prepopulated when the website is loaded; this is another trick to reinforce the victim’s belief that the site is legitimate.

When the password is entered, the user is presented with the following successful login page and redirected to the login page.

We observed the following filenames being used for the attachments:

  • 10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]
  • 14-August-2019.html [Format: DD-Month-YYYY.html]
  • Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]
  • Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

Phishing Sites

As explained in the introduction, we were surprised to observe three different phishing kits being used to generate the malicious websites. All three look almost identical but we were able to differentiate them by looking at the generated HTML code and the parameters which were accepted by the PHP script.

Voicemail Scmpage 2019 (Not a typo)

The first kit is being sold on an ICQ channel and the creator advertises it on social media. The kit goes by the name of ‘Voicemail Scmpage 2019’ and operates on a license key basis, where the license key is checked prior to the phishing site being loaded.

A snippet of the generated HTML code is shown below:

A file, data.txt, is created on the compromised website and it contains a list of visitors, including their IP address, web browsers and the date.

The following data is harvested from the victims and emailed to the owner of the phishing site:

  • Email
  • Password
  • IP Address
  • Region (Location)

Office 365 Information Hollar

The second phishing kit we discovered is called ‘Office 365 Information Hollar’. This kit is very similar to ‘Voicemail Scmpage 2019’ and gathers the same data, as shown in the image below:

Third “Unnamed” Kit

The final phishing kit is unbranded, and we could not find any attribution to it. This kit makes use of code from a previous malicious kit targeting Adobe users back in 2017. It is possible that the original author from 2017 has modified this kit, or perhaps more likely the old code has been re-used by a new group.

This kit also harvests the same data as the previous two. The ‘Unnamed Kit’ is the most prevalent malicious page we have observed while tracking these voicemail phishing campaigns.

Targeted Industries

During our investigation we observed the following industries being targeted with these types of phishing emails:

[Services includes tourism, entertainment, real estate and others which are too small to group]

A wide range of employees were targeted, from middle management to executive level staff. We believe that this is a ‘Phishing’ and ‘Whaling’ campaign.


The goal of malicious actors is to harvest as many credentials as possible, to gain access to potentially sensitive information and open the possibility of impersonation of staff, which could be very damaging to the company. The entered credentials could also be used to access other services if the victim uses the same password, and this could leave them open to a wider of range targeted attacks.

What sets this phishing campaign apart from others is the fact that it incorporates audio to create a sense of urgency which, in turn, prompts victims to access the malicious link. This gives the attacker the upper hand in the social engineering side of this campaign.

We urge all our readers to be vigilant when opening emails and to never open attachments from unknown senders. We also strongly advise against using the same password for different services and, if a user believes that his/her password is compromised, it is recommended to change it as soon as possible

It is highly recommended to use Two-Factor Authentication (2FA) since it provides a higher level of assurance than authentication methods based on Single-Factor Authentication (SFA), like the one that many users utilise for their Office 365 accounts.

When possible for enterprise customers, we recommend blocking .html and .htm attachments at the email gateway level so this kind of attack will not reach the final user.

Also, be sure to read our companion blog which details how you can stay safe from such phishing campaigns.

Indicators of Compromise

Email Attachment with the following filename:

10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]

14-August-2019.html [Format: DD-Month-YYYY.html]

Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]

Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

McAfee Detections

HTML/Phishing.g V2 DAT = 9349, V3 DAT = 3800

HTML/Phishing.av V2 DAT = 9371, V3 DAT = 3821

HTML/ V2 DAT = 9371, V3 DAT = 3821

The hashes of the attachments will not be provided as this will provide information on the potential targets


(Domains (all blocked by McAfee WebAdvisor)






More Information on Phishing Attacks:

The post Office 365 Users Targeted by Voicemail Scam Pages appeared first on McAfee Blogs.

Did You Check Your Quarantine?!

A cost-effective way to detect targeted attacks in your enterprise

While it is easy to get caught up in the many waves of new and exciting protection strategies, we have recently discovered an interesting approach to detect a targeted attack and the related actor(s). Quite surprisingly, a big part of the solution already exists in most enterprises: the tried, tested endpoint security platform. In this case, we used our own McAfee Endpoint Security (ENS). Along with ENS, we used GetQuarantine, a freeware tool from McAfee, and a third-party threat analytics service.

The Problem

We will begin with a working definition of a targeted attack:

A targeted attack is a threat in which a threat actor actively pursues and compromises a specific target. To achieve the goal, the adversary may adapt and improve their attack(s) to counter the victim’s defenses and persist at it for a long period of time.

What does this say? First, the adversary’s objective is to compromise a specific target, not just an arbitrary target. Second, the adversary is skilled enough to know how defenses work and is resourceful enough to actively adapt and improve their attack to beat defenses. Third, the adversary is determined enough to pursue the objective for perhaps an indefinite period of time.

Taken together, the above characteristics challenge most defense technologies. Why so? Because these characteristics run counter to the assumptions on which these technologies are based.

At the heart of it, most defense technologies are signature-based, where the signatures are created either by a human analyst, by a machine, or by using instances of known malicious behavior. The cost of constructing signatures is high and is amortized by using the same signature to defend against the same attack elsewhere.

Twenty years ago, when there were just a few thousand examples of malicious software around, it was relatively easy to find the origin, perpetrators, and the reason for the creation and release of a malicious file or application. Security researchers would manually analyze each sample, carefully identify similarities with previously known samples through sheer memory and label each sample with a unique name. This method worked well because the attacks then were opportunistic and aimed at spreading as wide as possible. This meant that anti-virus companies could discover an attack in one place, extract relevant detection signatures, and send the signature updates to its install base.

Now, security threat intelligence companies receive hundreds of thousands of new malware samples every day. There is simply not enough time or resources to analyze each malware to answer who, what, when, and why? The best any anti-virus software can do is to classify a file into just two bins: good or bad. It is impossible for researchers to manually look at every sample and process them to the same detail as before. To make matters worse, attacks today are targeted. Attackers create one-off variants aimed at a specific enterprise. This makes it virtually impossible to connect attacks across enterprises to understand the attacker.

And therein lies an important problem. Just as the numbers and sophistication of attacks have increased exponentially, the objective of tracking who is behind an attack, and identifying linkages between different malware samples and their authors, and the intent behind an attack, have been lost.

Why should it matter? In the absence of information about who is attempting to breach an organization, defenders are left operating in the dark. They make security decisions based on breaches that happen elsewhere using threat intelligence that is most often irrelevant, and when relevant, is most likely outdated.

The Solution

Analysis of targeted campaigns shows that programs that are part of an attack usually show a couple of similar characteristics. First, the malware or attack mechanism is focused on one enterprise or, at most, one sector and second, the malware program demonstrates evolutionary characteristics where the actor repeatedly unleashes different variants of it. Our proposed solution focuses on these characteristics and tries to uncover targeted campaigns by finding binary semantics between malware found in customer environments and known targeted campaigns.

Our solution strategy is:

Endpoint-security detects a malware sample. It is compared with a sample from a known targeted attack. If the similarity is high, it is a strong indication that the ENS detected sample is a part of that targeted attack and the threat actor is the same.

The strategy is implemented in three building blocks: sample collector, sample storage and targeted attack analysis using third-party threat analytics application.

Sample Collector (GetQuarantine)

Sample collection is performed using McAfee proprietary licensed freeware, GetQuarantine. GetQuarantine is a McAfee e-Policy Orchestrator (ePO) deployable tool that can run on all endpoints protected by McAfee ENS. GetQuarantine runs as an ePO scheduled product deployment task. ENS cleans or deletes items that are detected as threats and saves copies in a non-executable format to the Quarantine folder. The GetQuarantine tool on a scheduled run, checks the quarantine folder and uploads items to the McAfee backend if items are not already uploaded during previous tool runs.

Sample Storage (McAfee Workflow & AWS)

The McAfee workflow backend receives sample submissions from GetQuarantine and stores them in an S3 bucket. Samples are segregated per enterprise and made available for further analysis. Third-party analytics applications like MAGIC can be run on samples to extract targeted attack insights. Analytics services are available to McAfee customers participating in a third-party analytics program. For customers that do not participate in a third-party analytics program, sample processing ends at the McAfee backend layer and the sample eventually gets deleted without further analysis.

Targeted Attack Analysis

For our pilot implementation we used Cythereal MAGIC services. The McAfee backend submits samples to MAGIC for binary similarity analysis. Customers can check analysis reports using Cythereal website. Cythereal is McAfee’s Security Innovation Alliance (SIA) partner.

Cythereal MAGIC™ (malware genomic correlation) is a web-service touted as “BinDiff on Steroids”. The system carries out semantic similarity analysis of programs using advanced program analysis techniques at the assembly instruction-level code. The semantics of the program gives more meaningful insights than structural or behavioral characteristics. MAGIC can find similarity between samples submitted using GetQuarantine and also find variants of those samples from MAGIC’s database. It has the facility to provide alerts for campaign detections and can generate YARA rules that can be used for searching other services, like VirusTotal.

We first tried human-driven in-house analysis using open source tools like SSDEEP, SDHASH, TLSH, etc. to prove the concept of identifying targeted attacks using the binary similarity of samples found in quarantine. Though we were successful in proving this concept with these open source tools, they were not very effective, especially with polymorphic variants, so we explored third-party options and identified Cythereal MAGIC™.


Figure 1 shows the overall architecture of our system:

[Figure 1: McAfee ENS detects a suspicious sample by studying its behavior or other means and then moves the sample file to the quarantine folder. The scheduled execution of the GetQuarantine Tool configured in ePO as a scheduled task submits the sample to the McAfee backend. The third-party analytics app, periodically receives samples from McAfee backend for further analysis.]

Case Study

For a case study, we used samples from a McAfee discovered campaign, Oceansalt. We tested the solution’s ability to group samples using semantic similarity and also tested the solution’s ability to identify new variants of Oceansalt samples.

Illustration of the Solution’s Ability to Group Malware From Quarantine

McAfee Endpoint Security (ENS) detected two samples of Oceansalt (as listed in Table 1). GetQuarantine submitted these samples to the McAfee backend. Targeted attack analysis of these files showed a semantic similarity of 95.1%. The comparison of their control-flow graphs in Figure 2 justifies the high semantic similarity score.

[Table 1: Oceansalt samples reported by McAfee™ security operation center in June-July 2018.]

[Figure 2: Control-flow graph of Oceansalt samples from Table 1]

Illustration of the Solution’s Ability to Link New Variants From the Wild to a Known Targeted Attack

Finally, we come to the use case that motivated this study. Malware belonging to a targeted attack is identified by its file-hashes. However, attackers use polymorphism and other obfuscations to create new variants. Though McAfee ENS may block such variants, it may not link it to the original attack. Targeted attack analytics can help fill this void.

To test the solution’s ability to locate such targeted attacks, we uploaded an Oceansalt sample (MD5: 531DEE019792A089A4589C2CCE3DAC95 [VT]) to MAGIC and identified it as an APT. We then uploaded a large number (thousands) of malware samples via GetQuarantine. As we had thought, targeted attack analytics sent an alert that it had detected variants of Oceansalt (Figure 3).

[Figure 3: Alert about detecting an Oceansalt variant in the quarantine]

MAGIC’s alert was triggered because it found two Oceansalt variants from the wild which were not previously reported by the McAfee SOC or any other global threat intelligence.

[Table 2: Two new variants of Oceansalt samples found using semantic similarity]

Try Your Quarantine

We tested the GetQuarantine-based solution in our lab and found encouraging results. If you would like to try out this solution use the following steps, along with McAfee Endpoint Security (ENS):

  • Download the beta version of GetQuarantine, a proprietary licensed freeware.
  • Deploy it using the ePO ecosystem.
  • On successful sample submission to the McAfee backend, receive an acknowledgment email.

To obtain analysis results from the third-party analytics app, follow these steps:

  • Visit Cythereal MAGIC™.
  • The MAGIC dashboard contains plots with details about various ongoing campaigns.
  • Upon selecting a campaign in the plot, a table with all the associated malware is displayed where the customer can download samples and YARA rules.
  • Whenever MAGIC detects a targeted attack, it sends an alert email to the registered email address of the customer, along with additional threat intelligence, such as information on the threat group, third-party research on the group, and associated IoCs. Customers can also see the list of alerts on the MAGIC website.


As you can see from this exercise, traditional AV still has lot to offer and can play an important role in overall security strategy againt targeted attacks. We can amplify signals coming out of AV detections using tools like GetQuarantine and by running analytics on quarantine artifacts to uncover targeted attacks. We can take an incremental approach in solving targeted attack challenges.

The post Did You Check Your Quarantine?! appeared first on McAfee Blogs.