RSS Security

❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Babuk: Biting off More than they Could Chew by Aiming to Encrypt VM and *nix Systems?

29 July 2021 at 04:01

Co-written with Northwave’s Noël Keijzer.

Executive Summary

For a long time, ransomware gangs were mostly focused on Microsoft Windows operating systems. Yes, we observed the occasional dedicated Unix or Linux based ransomware, but cross-platform ransomware was not happening yet. However, cybercriminals never sleep and in recent months we noticed that several ransomware gangs were experimenting with writing their binaries in the cross-platform language Golang (Go).

Our worst fears were confirmed when Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems. Many core backend systems in companies are running on these *nix operating systems or, in the case of virtualization, think about the ESXi hosting several servers or the virtual desktop environment.

We touched upon this briefly in our previous blog, together with the many coding mistakes the Babuk team is making.

Even though Babuk is relatively new to the scene, its affiliates have been aggressively infecting high-profile victims, despite numerous problems with the binary which led to a situation in which files could not be retrieved, even if payment was made.

Ultimately, the difficulties faced by the Babuk developers in creating ESXi ransomware may have led to a change in business model, from encryption to data theft and extortion.

Indeed, the design and coding of the decryption tool are poorly developed, meaning if companies decide to pay the ransom, the decoding process for encrypted files can be really slow and there is no guarantee that all files will be recoverable.

Coverage and Protection Advice

McAfee’s EPP solution covers Babuk ransomware with an array of prevention and detection techniques.

McAfee ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections. For DAT based detections, the family will be reported as Ransom-Babuk!. ENS ATP adds 2 additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.

Updates on indicators are pushed through GTI, and customers of Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.

Initially, in our research the entry vector and the complete tactics, techniques and procedures (TTPs) used by the criminals behind Babuk remained unclear.

However, when its affiliate recruitment advertisement came online, and given the specific underground meeting place where Babuk posts, defenders can expect similar TTPs with Babuk as with other Ransomware-as-a-Service families.

In its recruitment posting Babuk specifically asks for individuals with pentest skills, so defenders should be on the lookout for traces and behaviors that correlate to open source penetration testing tools like winPEAS, Bloodhound and SharpHound, or hacking frameworks such as CobaltStrike, Metasploit, Empire or Covenant. Also be on the lookout for abnormal behavior of non-malicious tools that have a dual use, such as those that can be used for things like enumeration and execution, (e.g., ADfind, PSExec, PowerShell, etc.) We advise everyone to read our blogs on evidence indicators for a targeted ransomware attack (Part1Part2).

Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common amongst ransomware criminals:

  • E-mail Spearphishing (T1566.001). Often used to directly engage and/or gain an initial foothold, the initial phishing email can also be linked to a different malware strain, which acts as a loader and entry point for the ransomware gangs to continue completely compromising a victim’s network. We have observed this in the past with Trickbot and Ryuk, Emotet and Prolock, etc.
  • Exploit Public-Facing Application (T1190) is another common entry vector; cyber criminals are avid consumers of security news and are always on the lookout for a good exploit. We therefore encourage organizations to be fast and diligent when it comes to applying patches. There are numerous examples in the past where vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
  • Using valid accounts (T1078) is and has been a proven method for cybercriminals to gain a foothold. After all, why break the door if you have the keys? Weakly protected Remote Desktop Protocol (RDP) access is a prime example of this entry method. For the best tips on RDP security, we would like to highlight our blog explaining RDP security.
  • Valid accounts can also be obtained via commodity malware such as infostealers, that are designed to steal credentials from a victim’s computer. Infostealer logs containing thousands of credentials are purchased by ransomware criminals to search for VPN and corporate logins. As an organization, robust credential management and multi-factor authentication on user accounts is an absolute must have.

When it comes to the actual ransomware binary, we strongly advise updating and upgrading your endpoint protection, as well as enabling options like tamper protection and rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.

Summary of the Threat

  • A recent forum announcement indicates that the Babuk operators are now expressly targeting Linux/UNIX systems, as well as ESXi and VMware systems
  • Babuk is riddled with coding mistakes, making recovery of data impossible for some victims, even if they pay the ransom
  • We believe these flaws in the ransomware have led the threat actor to move to data theft and extortion rather than encryption

Learn more about how Babuk is transitioning away from an encryption/ransom model to one focused on pure data theft and extortion in our detailed technical analysis.

The post Babuk: Biting off More than they Could Chew by Aiming to Encrypt VM and *nix Systems? appeared first on McAfee Blogs.

Fighting new Ransomware Techniques with McAfee’s Latest Innovations

20 July 2021 at 04:01

In 2021 ransomware attacks have been dominant among the bigger cyber security stories. Hence, I was not surprised to see that McAfee’s June 2021 Threat report is primarily focused on this topic.

This report provides a large range of statistics using the McAfee data lake behind MVISION Insights, including the Top MITRE ATT&CK Techniques. In this report I highlight the following MITRE techniques:

  1. Spear phishing links (Initial Access)
  2. Exploit public-facing applications (Initial Access)
  3. Windows Command Shell (Execution)
  4. User execution (Execution)
  5. Process Injection (Privilege escalation)
  6. Credentials from Web Browsers (Credential Access)
  7. Exfiltration to Cloud Storage (Exfiltration)

I also want to highlight one obvious technique which remains common across all ransomware attacks at the end of the attack lifecycle:

  1. Data encrypted for impact (Impact)

Traditional defences based on anti-malware signatures and web protection against known malicious domains and IP addresses can be insufficient to protect against these techniques. Therefore, for the rest of this article, I want to cover a few recent McAfee innovations which can make a big difference in the fight against ransomware.

Unified Cloud Edge with Remote Browser Isolation

The following three ransomware techniques are linked to web access:

  • Spear phishing links
  • User execution
  • Exfiltration to Cloud Storage

Moreover, most ransomware attacks require some form of access to a command-and-control server to be fully operational.

McAfee Remote Browser Isolation (RBI) ensures no malicious web content ever even reaches enterprise endpoints’ web browsers by isolating all browsing activity to unknown and risky websites into a remote virtual environment. With spear phishing links, RBI works best when running the mail client in the web browser. The user systems cannot be compromised if web code or files cannot run on them, making RBI the most powerful form of web threat protection available. RBI is included in most McAfee United Cloud Edge (UCE) licenses at no additional cost.

Figure 1. Concept of Remote Browser Isolation

McAfee Client Proxy (MCP) controls all web traffic, including ransomware web traffic initiated without a web browser by tools like MEGAsync and Rclone. MCP is part of McAfee United Cloud Edge (UCE).

Protection Against Fileless Attacks

The following ransomware techniques are linked to fileless attacks:

  • Windows Command Shell (Execution)
  • Process Injection (Privilege escalation)
  • User Execution (Execution)

Many ransomware attacks also use PowerShell.

Figure 2. Example of an attack kill chain with fileless

McAfee provides a large range of technologies which protect against fileless attack methods, including McAfee ENS (Endpoint Security) Exploit prevention and McAfee ENS 10.7 Adaptive Threat Protection (ATP). Here are few examples of Exploit Prevention and ATP rules:

  • Exploit 6113-6114-6115-6121 Fileless threat: self-injection
  • Exploit 6116-6117-6122: Mimikatz suspicious activity
  • ATP 316: Prevent PDF readers from starting cmd.exe
  • ATP 502: Prevent new services from being created via sc.exe or powershell.exe

Regarding the use on Mimikatz in the example above, the new McAfee ENS 10.7 ATP Credential Theft Protection is designed to cease attacks against Windows LSASS so that you do not need to rely on the detection of Mimikatz.

Figure 3. Example of Exploit Prevention rules related to Mimikatz

ENS 10.7 ATP is now included in most McAfee Endpoint Security licenses at no additional cost.

Proactive Monitoring and Hunting with MVISION EDR

To prevent initial access, you also need to reduce the risks linked to the following technique:

  • Exploit public facing applications (Initial Access)

For example, RDP (Windows Remote Desktop Protocol) is a common initial access used by ransomware attacks. You may have a policy that already prohibits or restricts RDP but how do you know it is enforced on every endpoint?

With MVISION EDR (Endpoint Detection and Response) you can perform a real time search across all managed systems to see what is happening right now.

Figure 4. MVISION EDR Real-time Search to verify if RDP is enabled or disabled on a system

Figure 5. MVISION EDR Real-time Search to identify systems with active connections on RDP

MVISION EDR maintains a history of network connections inbound and outbound from the client. Performing an historical search for network traffic could identify systems that actively communicated on port 3389 to unauthorized addresses, potentially detecting attempts at exploitation.

MVISION EDR also enables proactive monitoring by a security analyst. The Monitoring Dashboard helps the analyst in the SOC quickly triage suspicious behavior.

For more EDR use cases related to ransomware see this blog article.

Actionable Threat Intelligence

With MVISION Insights you do not need to wait for the latest McAfee Threat Report to be informed on the latest ransomware campaigns and threat profiles. With MVISION Insights you can easily meet the following use cases:

  • Proactively assess your organization’s exposure to ransomware and prescribe how to reduce the attack surface:
    • Detect whether you have been hit by a known ransomware campaign
    • Run a Cyber Threat Intelligence program despite a lack of time and expertise
    • Prioritize threat hunting using the most relevant indicators

These use cases are covered in the webinar How to fight Ransomware with the latest McAfee innovations.

Regarding the following technique from the McAfee June 2021 Threat Report:

Credentials from Web Browsers (Credential Access)

MVISION Insights can display the detections in your environment as well as prevalence statistics.

Figure 6. Prevalence statistics from MVISION Insights on the LAZAGNE tool

MVISION Insights is included in several Endpoint Security licenses.

Rollback of Ransomware Encryption

Now we are left with the last technique in the attack lifecycle:

  • Data encrypted for impact (Impact)

McAfee ENS 10.7 Adaptive Threat Protection (ATP) provides dynamic application containment of suspicious processes and enhanced remediation with an automatic rollback of the ransomware encryption.

Figure 7. Configuration of Rollback remediation in ENS 10.7

You can see how files impacted by ransomware can be restored through Enhanced Remediation in this video. For more best practices on tuning Dynamic Application Containment rules, check the knowledge base article here.

Additional McAfee Protection Against Ransomware

Last year McAfee released this blog article covering additional capabilities from McAfee Endpoint Security (ENS), Endpoint Detection and Response (EDR) and the Management Console (ePO) against ransomware including:

  • ENS Exploit prevention
  • ENS Firewall
  • ENS Web control
  • ENS Self protection
  • ENS Story Graph
  • ePO Protection workspace
  • Additional EDR use cases against ransomware


To increase your protection against ransomware you might already be entitled to:

  • ENS 10.7 Adaptive Threat Protection
  • Unified Cloud Edge with Remote Browser Isolation and McAfee Client Proxy
  • MVISION Insights

If you are, you should start using them as soon as possible, and if you are not, contact us.

The post Fighting new Ransomware Techniques with McAfee’s Latest Innovations appeared first on McAfee Blogs.

An Overall Philosophy on the Use of Critical Threat Intelligence

16 July 2021 at 20:15

The overarching threat facing cyber organizations today is a highly skilled asymmetric enemy, well-funded and resolute in his task and purpose.   You never can exactly tell how they will come at you, but come they will.  It’s no different than fighting a kinetic foe in that, before you fight, you must choose your ground and study your enemy’s tendencies.

A lot of focus has been placed on tools and updating technology, but often we are pushed back on our heels and find ourselves fighting a defensive action.

But what if we change?  How do we do that?

The first step is to study the battlefield, understand what you’re trying to protect and lay down your protection strategy.  Pretty basic right??

Your technology strategy is very important, but you must embrace and create a thorough Cyber Threat Intelligence (CTI) doctrine which must take on many forms.

First, there is data, and lots of it.  However, the data must take specific forms to research and detect nascent elements where the adversary is attempting to catch you napping or give you the perception that the activity you see is normal.

As you pool this data, it must be segmented into layers and literally mapped to geographic locations across the globe.  The data is classified distinctly as malicious and reputations are applied.  This is a vital step in that it enables analytical programs, along with human intelligence analysts to apply the data within intelligence reports which themselves can take on many forms.

Once the data takes an analytic form, then it allows organizations to forensically piece together a picture of an attack.  This process is painstakingly tedious but necessary to understand your enemy and his tendencies.  Tools are useful, but it’s always the human in the loop that will recognize the tactical and strategic implications of an adversary’s moves. Once you see the picture, it becomes real, and then you’re able to prepare your enterprise for the conflict that follows.

Your early warning and sensing strategy must incorporate this philosophy.  You must sense, collect, exploit, process, produce and utilize each intelligence product that renders useful information.  It’s this process that will enable any organization to move decisively to and stay “left of boom”.

The McAfee Advanced Programs Group (APG) was created eight years ago to support intelligence organizations that embrace and maintain a strong CTI stance.  Its philosophy is to blend people, processes, data and a strong intelligence heritage to enable our customers to understand the cyber battlefield to proactively protect, but “maneuver” when necessary to avoid an attack.

APG applies three key disciplines or mission areas to provide this support.

First, we developed an internal tool called the Advanced Threat Landscape Analysis System (ATLAS).  This enables our organization to apply our malicious threat detections to a geospatial map display to see where we’re seeing malicious data.  ATLAS draws from our global network of billions of threat sensors to see trillions of detections each day, but enables our analysts to concentrate on the most malicious activity.  Then we’re better able to research and report accurate threat landscape information.

The second leg in the stool is our analytical staff, the true cyber ninjas that apply decades of experience supporting HUMINT operations across the globe and a well-established intelligence-based targeting philosophy to the cyber environment.  The result is a true understanding of the cyber battlefield enabling the leadership to make solid “intelligence-based” decisions.

Finally, the third leg is our ability to develop custom solutions and interfaces to adapt in a very custom way our ability to see and study data.  We have the ability to leverage 2.8 billion malicious detections, along with 20 other distinct malicious feeds, to correlate many different views, just not the McAfee view.  We interpret agnostically.

These three legs provide APG a powerful CTI advantage allowing our customers to adapt and respond to events by producing threat intelligence dynamically. When using this service it allows the customer to be fully situationally aware in a moments notice (visual command and control). Access to the data alone is an immense asset to any organization.  This allows each customer not only to know what their telemetry is, but also provides real time insights into the entire world ecosystem. Finally, the human analysis alone is immensely valuable.  It allows for the organizations to read and see/understand what it all means (the who, what, where and why).   “The so what!!”

The post An Overall Philosophy on the Use of Critical Threat Intelligence appeared first on McAfee Blogs.

REvil Ransomware Uses DLL Sideloading

16 July 2021 at 16:49

This blog was written byVaradharajan Krishnasamy, Karthickkumar, Sakshi Jaiswal


Ransomware attacks are one of the most common cyber-attacks among organizations; due to an increase in Ransomware-as-a-service (RaaS) on the black market. RaaS provides readily available ransomware to cyber criminals and is an effective way for attackers to deploy a variety of ransomware in a short period of time.

Usually, RaaS model developers sell or rent their sophisticated ransomware framework on the black market. After purchasing the license from the ransomware developer, attackers spread the ransomware to other users, infect them, encrypt files, and demand a huge ransom payment in Bitcoin.  Also, there are discounts available on the black market for ransomware frameworks in which the ransom money paid is shared between developers and the buyer for every successful extortion of ransom from the victims. These frameworks reduce the time and effort of creating a new ransomware from scratch using latest and advanced programming languages.

REvil is one of the most famous ransomware-as-a-service (RaaS) providers. The group released the Sodinokibi ransomware in 2019, and McAfee has since observed REvil using a DLL side loading technique to execute ransomware code. The actual ransomware is a dropper that contains two embedded PE files in the resource section.  After successful execution, it drops two additional files named MsMpEng.exe and MpSvc.dll in the temp folder. The file MsMpEng.exe is a Microsoft digitally signed file having a timestamp of March 2014 (Figure 1).

Figure-1: Image of Microsoft Digitally signed File


The malware uses DLL side loading to execute the ransomware code. This technique allows the attacker to execute malicious DLLs that spoof legitimate ones. This technique has been used in many APTs to avoid detection. In this attack, MsMpEng.exe loads the functions of MpSvc.dll during the time of execution. However, the attacker has replaced the clean MpSvc.dll with the ransomware binary of the same name. The malicious DLL file has an export function named ServiceCrtMain, which is further called and executed by the Microsoft Defender file. This is a clever technique used by the attacker to execute malicious file using the Microsoft digitally signed binary.

Figure-2: Calling Export function


The ransomware uses the RC4 algorithm to decrypt the config file which has all the information that supports the encryption process.

Figure-3: REvil Config File

Then it performs a UI language check using GetSystemDefaultUILanguage/GetUserDefaultUILanguage functions and compares it with a hardcoded list which contains the language ID of several countries as shown in below image.

Figure-4: Language Check

Countries excluded from this ransomware attack are mentioned below:

GetUserDefaultUILanguage Country name
0x419 Russian
0x422 Ukranian
0x423 Belarusian
0x428 Tajik (Cyrilic from Tajikistan)
0x42B Armenian
0x42C Azerbaijani (Latin from Azerbaijan)
0x437 Georgian
0x43F Kazakh from Kazakhastan
0x440 Kyrgyzstan
0x442 Turkmenistan
0x443 Latin from Uzbekistan
0x444 Tatar from Russia Federation
0x818 Romanian from Moldova
0x819 Russian from Moldova
0x82C Cyrilic from Azerbaijan
0x843 Cyrilic from Uzbekistan
0x45A Syriac
0x281A Cyrilic from Serbia


Additionally, the ransomware checks the users keyboardlayout and it skips the ransomware infection in the machine’s which are present in the country list above.

Figure-5: Keyboardlayout check

Ransomware creates a Global mutex in the infected machine to mark its presence.

Figure-6: Global Mutex

After creating the mutex, the ransomware deletes the files in the recycle bin using the SHEmptyRecycleBinW function to make sure that no files are restored post encryption.

Figure-7: Empty Recycle Bin

Then it enumerates all the active services with the help of the EnumServicesStatusExW function and deletes services if the service name matches the list present in the config file. The image below shows the list of services checked by the ransomware.

Figure-8: Service List check

It calls the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW functions to enumerate running processes and terminates those matching the list present in the config file.  The following processes will be terminated.

  • allegro
  • steam
  • xtop
  • ocssd
  • xfssvccon
  • onenote
  • isqlplussvc
  • msaccess
  • powerpnt
  • cad
  • sqbcoreservic
  • thunderbird
  • oracle
  • infopath
  • dbeng50
  • pro_comm_msg
  • agntsvc
  • thebat
  • firefox
  • ocautoupds
  • winword
  • synctime
  • tbirdconfig
  • mspub
  • visio
  • sql
  • ocomm
  • orcad
  • mydesktopserv
  • dbsnmp
  • outlook
  • cadence
  • excel
  • wordpad
  • creoagent
  • encsvc
  • mydesktopqos


Then, it encrypts files using the Salsa20 algorithm and uses multithreading for fast encryption of the files. Later, background wallpaper will be set with a ransom message.

Figure-9: Desktop Wallpaper

Finally, the ransomware displays ransom notes in the victim’s machine. Below is an image of readme.txt which is dropped in the infected machine.

Figure-10: Ransom Note

IOCs and Coverage

Type Value Detection Name Detection Package Version (V3)
Loader 5a97a50e45e64db41049fd88a75f2dd2 REvil.f 4493
Dropped DLL 78066a1c4e075941272a86d4a8e49471 REvil.e 4493


Expert rules allow McAfee customers to extend their coverage. This rule covers this REvil ransomware behaviour.


Technique ID Tactic Technique Details
T1059.003 Execution Command and Scripting Interpreter
T1574.002 DLL Side-Loading Hijack Execution Flow
T1486 Impact Data Encrypted for Impact
T1036.005 Defense Evasion Masquerading
T1057 Discovery Process Discovery
T1082 Discovery System Information Discovery


McAfee observed that the REvil group has utilized oracle web logic vulnerability (CVE-2019-2725) to spread the ransomware last year and used kaseya’s VSA application recently for their ransomware execution, with the help of DLL sideloading. REvil uses many vulnerability applications for ransomware infections, however the encryption technique remains the same. McAfee recommends making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place.

The post REvil Ransomware Uses DLL Sideloading appeared first on McAfee Blogs.

Hancitor Making Use of Cookies to Prevent URL Scraping

8 July 2021 at 22:15
Consejos para protegerte de quienes intentan hackear tus correos electrónicos

This blog was written by Vallabh Chole & Oliver Devane

Over the years, the cybersecurity industry has seen many threats get taken down, such as the Emotet takedown in January 2021. It doesn’t usually take long for another threat to attempt to fill the gap left by the takedown. Hancitor is one such threat.

Like Emotet, Hancitor can send Malspams to spread itself and infect as many users as possible. Hancitor’s main purpose is to distribute other malware such as FickerStealer, Pony, CobaltStrike, Cuba Ransomware and Zeppelin Ransomware. The dropped Cobalt Strike beacons can then be used to move laterally around the infected environment and also execute other malware such as ransomware.

This blog will focus on a new technique used by Hancitor created to prevent crawlers from accessing malicious documents used to download and execute the Hancitor payload.

The infection flow of Hancitor is shown below:

A victim will receive an email with a fake DocuSign template to entice them to click a link. This link leads him to, a service that works similar to an RSS Feed and enables site owners to publish site updates to its users.

When accessing the link, the victim is redirected to the malicious site. The site will check the User-Agent of the browser and if it is a non-Windows User-Agent the victim will be redirected to

If the victim is on a windows machine, the malicious site will create a cookie using JavaScript and then reload the site.

The code to create the cookie is shown below:

The above code will write the Timezone to value ‘n’ and the time offset to UTC in value ‘d’ and set it into cookie header for an HTTP GET Request.

For example, if this code is executed on a machine with timezone set as BST the values would be:

d = 60

n = “Europe/London”

These values may be used to prevent further malicious activity or deploy a different payload depending on geo location.

Upon reloading, the site will check if the cookie is present and if it is, it will present them with the malicious document.

A WireShark capture of the malicious document which includes the cookie values is shown below:

The document will prompt them to enable macros and, when enabled, it will download the Hancitor DLL and then load it with Rundll32.

Hancitor will then communicate with its C&C and deploy further payloads. If running on a Windows domain, it will download and deploy a Cobalt Strike beacon.

Hancitor will also deploy SendSafe which is a spam module, and this will be used to send out malicious spam emails to infect more victims.


With its ability to send malicious spam emails and deploy Cobalt Strike beacons, we believe that Hancitor will be a threat closely linked to future ransomware attacks much like Emotet was. This threat also highlights the importance of constantly monitoring the threat landscape so that we can react quickly to evolving threats and protect our customers from them.

IOCs, Coverage, and MITRE


IOC Type IOC Coverage Content Version
Malicious Document SHA256 e389a71dc450ab4077f5a23a8f798b89e4be65373d2958b0b0b517de43d06e3b W97M/Dropper.hx


Hancitor DLL SHA256 c703924acdb199914cb585f5ecc6b18426b1a730f67d0f2606afbd38f8132ad6


Trojan-Hancitor.a 4644
Domain hosting Malicious Document URL http[:]//onyx-food[.]com/coccus.php RED N/A
Domain hosting Malicious Document


URL http[:]//feedproxy[.]google[.]com/~r/ugyxcjt/~3/4gu1Lcmj09U/coccus.php RED N/A


Technique ID Tactic Technique details
T1566.002 Initial Access Spam mail with links
T1204.001 Execution User Execution by opening link.
T1204.002 Execution Executing downloaded doc
T1218 Defence Evasion Signed Binary Execution Rundll32
T1055 Defence Evasion Downloaded binaries are injected into svchost for execution
T1482 Discovery Domain Trust Discovery
T1071 C&C HTTP protocol for communication
T1132 C&C Data is base64 encoded and xored



The post Hancitor Making Use of Cookies to Prevent URL Scraping appeared first on McAfee Blogs.

Zloader With a New Infection Technique

8 July 2021 at 21:44

This blog was written by Kiran Raj & Kishan N.


In the last few years, Microsoft Office macro malware using social engineering as a means for malware infection has been a dominant part of the threat landscape. Malware authors continue to evolve their techniques to evade detection. These techniques involve utilizing macro obfuscation, DDE, living off the land tools (LOLBAS), and even utilizing legacy supported XLS formats.

McAfee Labs has discovered a new technique that downloads and executes malicious DLLs (Zloader) without any malicious code present in the initial spammed attachment macro. The objective of this blog is to cover the technical aspect of the newly observed technique.

Infection map

Threat Summary

  • The initial attack vector is a phishing email with a Microsoft Word document attachment.
  • Upon opening the document, a password-protected Microsoft Excel file is downloaded from a remote server.
  • The Word document Visual Basic for Applications (VBA) reads the cell contents of the downloaded XLS file and writes into the XLS VBA as macros.
  • Once the macros are written to the downloaded XLS file, the Word document sets the policy in the registry to Disable Excel Macro Warning and calls the malicious macro function dynamically from the Excel file,
  • This results in the downloading of the Zloader payload. The Zloader payload is then executed by rundll32.exe.

The section below contains the detailed technical analysis of this technique.

Detailed Technical Analysis

Infection Chain

The malware arrives through a phishing email containing a Microsoft Word document as an attachment. When the document is opened and macros are enabled, the Word document, in turn, downloads and opens another password-protected Microsoft Excel document.

After downloading the XLS file, the Word VBA reads the cell contents from XLS and creates a new macro for the same XLS file and writes the cell contents to XLS VBA macros as functions.

Once the macros are written and ready, the Word document sets the policy in the registry to Disable Excel Macro Warning and invokes the malicious macro function from the Excel file. The Excel file now downloads the Zloader payload. The Zloader payload is then executed using rundll32.exe.

Figure-1: flowchart of the Infection chain

Word Analysis

Here is how the face of the document looks when we open the document (figure 2). Normally, the macros are disabled to run by default by Microsoft Office. The malware authors are aware of this and hence present a lure image to trick the victims guiding them into enabling the macros.

Figure-2: Image of Word Document Face

The userform combo-box components present in the Word document stores all the content required to connect to the remote Excel document including the Excel object, URL, and the password required to open the Excel document. The URL is stored in the Combobox in the form of broken strings which will be later concatenated to form a complete clear string.

Figure-3: URL components (right side) and the password to open downloaded Excel document (“i5x0wbqe81s”) present in user-form components.

VBA Macro Analysis of Word Document

Figure-4: Image of the VBA editor

In the above image of macros (figure 4), the code is attempting to download and open the Excel file stored in the malicious domain. Firstly, it creates an Excel application object by using CreateObject() function and reading the string from Combobox-1 (ref figure-2) of Userform-1 which has the string “excel. Application” stored in it. After creating the object, it uses the same object to open the Excel file directly from the malicious URL along with the password without saving the file on the disk by using Workbooks.Open() function.

Figure-5: Word Macro code that reads strings present in random cells in Excel sheet.


The above snippet (figure 5) shows part of the macro code that is reading the strings from the Excel cells.

For Example:

Ixbq = ifk.sheets(3).Cells(44,42).Value

The code is storing the string present in sheet number 3 and the cell location (44,42) into the variable “ixbq”. The Excel.Application object that is assigned to variable “ifk” is used to access sheets and cells from the Excel file that is opened from the malicious domain.

In the below snippet (figure 6), we can observe the strings stored in the variables after being read from the cells. We can observe that it has string related to the registry entry “HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM” that is used to disable trust access for VBA into Excel and the string “Auto_Open3” that is going to be the entry point of the Excel macro execution.

We can also see the strings “ThisWorkbook”, “REG_DWORD”, “Version”, “ActiveVBProject” and few random functions as well like “Function c4r40() c4r40=1 End Function”. These macro codes cannot be detected using static detection since the content is formed dynamically on run time.

Figure-6: Value of variables after reading Excel cells.

After extracting the contents from the Excel cells, the parent Word file creates a new VBA module in the downloaded Excel file by writing the retrieved contents. Basically, the parent Word document is retrieving the cell contents and writing them to XLS macros.

Once the macro is formed and ready, it modifies the below RegKey to disable trust access for VBA on the victim machine to execute the function seamlessly without any Microsoft Office Warnings.


After writing macro contents to Excel file and disabling the trust access, function ’Auto_Open3()’ from newly written excel VBA will be called which downloads zloader dll from the ‘hxxp://’ with extension .cpl

Figure-7: Image of ’Auto_Open3()’ function

The downloaded dll is saved in %temp% folder and executed by invoking rundll32.exe.

Figure-8: Image of zloader dll invoked by rundll32.exe

Command-line parameter:

Rundll32.exe shell32.dll,Control_RunDLL “<path downloaded dll>”

Windows Rundll32 commands loads and runs 32-bit DLLs that can be used for directly invoking specified functions or used to create shortcuts. In the above command line, the malware uses “Rundll32.exe shell32.dll,Control_RunDLL” function to invoke control.exe (control panel) and passes the DLL path as a parameter, therefore the downloaded DLL is executed by control.exe.

Excel Document Analysis:

The below image (figure 9) is the face of the password-protected Excel file that is hosted on the server. We can observe random cells storing chunks of strings like “RegDelete”, “ThisWorkbook”, “DeleteLines”, etc.

These strings present in worksheet cells are formed as VBA macro in the later stage.

Figure-9: Image of Remote Excel file.

Coverage and prevention guidance:

McAfee’s Endpoint products detect this variant of malware and files dropped during the infection process.

The main malicious document with SHA256 (210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf) is detected with V3 package version – 4328.0 as “W97M/Downloader.djx”.  The final Zloader payload with SHA-256 (c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2)which is a DLL is detected by signature Zloader-FCVPwith V3 package version – 4327.0

Additionally, with the help of McAfee’s Expert rule feature, customers can strengthen the security by adding custom Expert rules based on the behavior patterns of the malware. The below EP rule is specific to this infection pattern.

McAfee advises all users to avoid opening any email attachments or clicking any links present in the mail without verifying the identity of the sender. Always disable the macro execution for Office files. We advise everyone to read our blog on this new variant of Zloader and its infection cycle to understand more about the threat.

Different techniques & tactics are used by the malware to propagate and we mapped these with the MITRE ATT&CK platform.

  • E-mail Spear Phishing (T1566.001): Phishing acts as the main entry point into the victim’s system where the document comes as an attachment and the user enables the document to execute the malicious macro and cause infection. This mechanism is seen in most of the malware like Emotet, Drixed, Trickbot, Agenttesla, etc.
  • Execution (T1059.005): This is a very common behavior observed when a malicious document is opened. The document contains embedded malicious VBA macros which execute code when the document is opened/closed.
  • Defense Evasion (T1218.011): Execution of signed binary to abuse Rundll32.exe and to proxy execute the malicious code is observed in this Zloader variant. This tactic is now also part of many others like Emotet, Hancitor, Icedid, etc.
  • Defense Evasion (T1562.001): In this tactic, it Disables or Modifies security features in Microsoft Office document by changing the registry keys.


Type Value Scanner Detection Name Detection Package Version (V3)
Main Word Document 210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf ENS W97M/Downloader.djx 4328
Downloaded dll c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2 ENS Zloader-FCVP 4327
URL to download XLS hxxp:// WebAdvisor


Blocked N/A
URL to download dll hxxp:// WebAdvisor


Blocked N/A


Malicious documents have been an entry point for most malware families and these attacks have been evolving their infection techniques and obfuscation, not just limiting to direct downloads of payload from VBA, but creating agents dynamically to download payload as we discussed in this blog. Usage of such agents in the infection chain is not only limited to Word or Excel, but further threats may use other living off the land tools to download its payloads.

Due to security concerns, macros are disabled by default in Microsoft Office applications. We suggest it is safe to enable them only when the document received is from a trusted source.

The post Zloader With a New Infection Technique appeared first on McAfee Blogs.

New Ryuk Ransomware Sample Targets Webservers

7 July 2021 at 04:01

Executive Summary

Ryuk is a ransomware that encrypts a victim’s files and requests payment in Bitcoin cryptocurrency to release the keys used for encryption. Ryuk is used exclusively in targeted ransomware attacks.

Ryuk was first observed in August 2018 during a campaign that targeted several enterprises. Analysis of the initial versions of the ransomware revealed similarities and shared source code with the Hermes ransomware. Hermes ransomware is a commodity malware for sale on underground forums and has been used by multiple threat actors.

To encrypt files Ryuk utilizes a combination of symmetric AES (256-bit) encryption and asymmetric RSA (2048-bit or 4096-bit) encryption. The symmetric key is used to encrypt the file contents, while the asymmetric public key is used to encrypt the symmetric key. Upon payment of the ransom the corresponding asymmetric private key is released, allowing the encrypted files to be decrypted.

Because of the targeted nature of Ryuk infections, the initial infection vectors are tailored to the victim. Often seen initial vectors are spear-phishing emails, exploitation of compromised credentials to remote access systems and the use of previous commodity malware infections. As an example of the latter, the combination of Emotet and TrickBot, have frequently been observed in Ryuk attacks.

Coverage and Protection Advice

Ryuk is detected as Ransom-Ryuk![partial-hash].

Defenders should be on the lookout for traces and behaviours that correlate to open source pen test tools such as winPEAS, Lazagne, Bloodhound and Sharp Hound, or hacking frameworks like Cobalt Strike, Metasploit, Empire or Covenant, as well as abnormal behavior of non-malicious tools that have a dual use. These seemingly legitimate tools (e.g., ADfind, PSExec, PowerShell, etc.) can be used for things like enumeration and execution. Subsequently, be on the lookout for abnormal usage of Windows Management Instrumentation WMIC (T1047). We advise everyone to check out the following blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).

  • Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common among ransomware criminals:
  • E-mail Spear phishing (T1566.001) often used to directly engage and/or gain an initial foothold. The initial phishing email can also be linked to a different malware strain, which acts as a loader and entry point for the attackers to continue completely compromising a victim’s network. We have observed this in the past with the likes of Trickbot & Ryuk or Qakbot & Prolock, etc.
  • Exploit Public-Facing Application (T1190) is another common entry vector, given cyber criminals are often avid consumers of security news and are always on the lookout for a good exploit. We therefore encourage organizations to be fast and diligent when it comes to applying patches. There are numerous examples in the past where vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
  • Using valid accounts (T1078) is and has been a proven method for cybercriminals to gain a foothold. After all, why break the door down if you already have the keys? Weakly protected RDP access is a prime example of this entry method. For the best tips on RDP security, please see our blog explaining RDP security.
  • Valid accounts can also be obtained via commodity malware such as infostealers that are designed to steal credentials from a victim’s computer. Infostealer logs containing thousands of credentials can be purchased by ransomware criminals to search for VPN and corporate logins. For organizations, having a robust credential management and MFA on user accounts is an absolute must have.

When it comes to the actual ransomware binary, we strongly advise updating and upgrading endpoint protection, as well as enabling options like tamper protection and Rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.

Summary of the Threat

Ryuk ransomware is used exclusively in targeted attacks

Latest sample now targets webservers

New ransom note prompts victims to install Tor browser to facilitate contact with the actors

After file encryption, the ransomware will print 50 copies of the ransom note on the default printer

Learn more about Ryuk ransomware, including Indicators of Compromise, Mitre ATT&CK techniques and Yara Rule, by reading our detailed technical analysis.

The post New Ryuk Ransomware Sample Targets Webservers appeared first on McAfee Blogs.

Fuzzing ImageMagick and Digging Deeper into CVE-2020-27829

30 June 2021 at 15:00


ImageMagick is a hugely popular open source software that is used in lot of systems around the world. It is available for the Windows, Linux, MacOS platforms as well as Android and iOS. It is used for editing, creating or converting various digital image formats and supports various formats like PNG, JPEG, WEBP, TIFF, HEIC and PDF, among others.

Google OSS Fuzz and other threat researchers have made ImageMagick the frequent focus of fuzzing, an extremely popular technique used by security researchers to discover potential zero-day vulnerabilities in open, as well as closed source software. This research has resulted in various vulnerability discoveries that must be addressed on a regular basis by its maintainers. Despite the efforts of many to expose such vulnerabilities, recent fuzzing research from McAfee has exposed new vulnerabilities involving processing of multiple image formats, in various open source and closed source software and libraries including ImageMagick and Windows GDI+.

Fuzzing ImageMagick:

Fuzzing open source libraries has been covered in a detailed blog “Vulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade” last year. Fuzzing ImageMagick is very well documented, so we will be quickly covering the process in this blog post and will focus on the root cause analysis of the issue we have found.

Compiling ImageMagick with AFL:

ImageMagick has lot of configuration options which we can see by running following command:

$./configure –help

We can customize various parameters as per our needs. To compile and install ImageMagick with AFL for our case, we can use following commands:

$CC=afl-gcc CXX=afl=g++ CFLAGS=”-ggdb -O0 -fsanitize=address,undefined -fno-omit-frame-pointer” LDFLAGS=”-ggdb -fsanitize=address,undefined -fno-omit-frame-pointer” ./configure

$ make -j$(nproc)

$sudo make install

This will compile and install ImageMagick with AFL instrumentation. The binary we will be fuzzing is “magick”, also known as “magick tool”. It has various options, but we will be using its image conversion feature to convert our image from one format to another.

A simple command would be include the following:

$ magick <input file> <output file>

This command will convert an input file to an output file format. We will be fuzzing this with AFL.

Collecting Corpus:

Before we start fuzzing, we need to have a good input corpus. One way of collecting corpus is to search on Google or GitHub. We can also use existing test corpus from various software. A good test corpus is available on the  AFL site here:

Minimizing Corpus:

Corpus collection is one thing, but we also need to minimize the corpus. The way AFL works is that it will instrument each basic block so that it can trace the program execution path. It maintains a shared memory as a bitmap and it uses an algorithm to check new block hits. If a new block hit has been found, it will save this information to bitmap.

Now it may be possible that more than one input file from the corpus can trigger the same path, as we have collected sample files from various sources, we don’t have any information on what paths they will trigger at the runtime. If we use this corpus without removing such files, then we end up wasting time and CPU cycles. We need to avoid that.

Interestingly AFL offers a utility called “afl-cmin” which we can use to minimize our test corpus. This is a recommended thing to do before you start any fuzzing campaign. We can run this as follows:

$afl-cmin -i <input directory> -o <output directory> — magick @@ /dev/null

This command will minimize the input corpus and will keep only those files which trigger unique paths.

Running Fuzzers:

After we have minimized corpus, we can start fuzzing. To fuzz we need to use following command:

$afl-fuzz -i <mincorpus directory> -o <output directory> — magick @@ /dev/null

This will only run a single instance of AFL utilizing a single core. In case we have multicore processors, we can run multiple instances of AFL, with one Master and n number of Slaves. Where n is the available CPU cores.

To check available CPU cores, we can use this command:


This will give us the number of CPU cores (depending on the system) as follows:

In this case there are eight cores. So, we can run one Master and up to seven Slaves.

To run master instances, we can use following command:

$afl-fuzz -M Master -i <mincorpus directory> -o <output directory> — magick @@ /dev/null

We can run slave instances using following command:

$afl-fuzz -S Slave1 -i <mincorpus directory> -o <output directory> — magick @@ /dev/null

$afl-fuzz -S Slave2 -i <mincorpus directory> -o <output directory> — magick @@ /dev/null

The same can be done for each slave. We just need to use an argument -S and can use any name like slave1, slave2, etc.


Within a few hours of beginning this Fuzzing campaign, we found one crash related to an out of bound read inside a heap memory. We have reported this issue to ImageMagick, and they were very prompt in fixing it with a patch the very next day. ImageMagick has release a new build with version: 7.0.46 to fix this issue. This issue was assigned CVE-2020-27829.

Analyzing CVE-2020-27829:

On checking the POC file, we found that it was a TIFF file.

When we open this file with ImageMagick with following command:

$magick poc.tif /dev/null

As a result, we see a crash like below:

As is clear from the above log, the program was trying to read 1 byte past allocated heap buffer and therefore ASAN caused this crash. This can atleast lead to a  ImageMagick crash on the systems running vulnerable version of ImageMagick.

Understanding TIFF file format:

Before we start debugging this issue to find a root cause, it is necessary to understand the TIFF file format. Its specification is very well described here:

In short, a TIFF file has three parts:

  1. Image File Header (IFH) – Contains information such as file identifier, version, offset of IFD.
  2. Image File Directory (IFD) – Contains information on the height, width, and depth of the image, the number of colour planes, etc. It also contains various TAGs like colormap, page number, BitPerSample, FillOrder,
  3. Bitmap data – Contains various image data like strips, tiles, etc.

We can tiffinfo utility from libtiff to gather various information about the POC file. This allows us to see the following information with tiffinfo like width, height, sample per pixel, row per strip etc.:

There are a few things to note here:

TIFF Dir offset is: 0xa0

Image width is: 3 and length is: 32

Bits per sample is: 9

Sample per pixel is: 3

Rows per strip is: 1024

Planer configuration is: single image plane.

We will be using this data moving forward in this post.

Debugging the issue:

As we can see in the crash log, program was crashing at function “PushQuantumPixel” in the following location in quantum-import.c line 256:

On checking “PushQuantumPixel” function in “MagickCore/quantum-import.c” we can see the following code at line #256 where program is crashing:

We can see following:

  • “pixels” seems to be a character array
  • inside a for loop its value is being read and it is being assigned to quantum_info->state.pixel
  • its address is increased by one in each loop iteration

The program is crashing at this location while reading the value of “pixels” which means that value is out of bound from the allocated heap memory.

Now we need to figure out following:

  1. What is “pixels” and what data it contains?
  2. Why it is crashing?
  3. How this was fixed?

Finding root cause:

To start with, we can check “ReadTIFFImage” function in coders/tiff.c file and see that it allocates memory using a “AcquireQuantumMemory” function call, which appears as per the documentation mentioned here:

“Returns a pointer to a block of memory at least count * quantum bytes suitably aligned for any use.

The format of the “AcquireQuantumMemory” method is:

void *AcquireQuantumMemory(const size_t count,const size_t quantum)

A description of each parameter follows:


the number of objects to allocate contiguously.


the size (in bytes) of each object. “

In this case two parameters passed to this function are “extent” and “sizeof(*strip_pixels)”

We can see that “extent” is calculated as following in the code below:

There is a function TIFFStripSize(tiff) which returns size for a strip of data as mentioned in libtiff documentation here:

In our case, it returns 224 and we can also see that in the code mentioned above,  “image->columns * sizeof(uint64)” is also added to extent, which results in 24 added to extent, so extent value becomes 248.

So, this extent value of 248 and sizeof(*strip_pixels) which is 1 is passed to “AcquireQuantumMemory” function and total memory of 248 bytes get allocated.

This is how memory is allocated.

“Strip_pixel” is pointer to newly allocated memory.

Note that this is 248 bytes of newly allocated memory. Since we are using ASAN, each byte will contain “0xbe” which is default for newly allocated memory by ASAN:

The memory start location is 0x6110000002c0 and the end location is 0x6110000003b7, which is 248 bytes total.

This memory is set to 0 by a “memset” call and this is assigned to a variable “p”, as mentioned in below image. Please also note that “p” will be used as a pointer to traverse this memory location going forward in the program:

Later on we see that there is a call to “TIFFReadEncodedPixels” which reads strip data from TIFF file and stores it into newly allocated buffer “strip_pixels” of 248 bytes (documentation here:

To understand what this TIFF file data is, we need to again refer to TIFF file structure. We can see that there is a tag called “StripOffsets” and its value is 8, which specifies the offset of strip data inside TIFF file:

We see the following when we check data at offset 8 in the TIFF file:

We see the following when we print the data in “strip_pixels” (note that it is in little endian format):

So “strip_pixels” is the actual data from the TIFF file from offset 8. This will be traversed through pointer “p”.

Inside “ReadTIFFImage” function there are two nested for loops.

  • The first “for loop” is responsible for iterating for “samples_per_pixel” time which is 3.
  • The second “for loop” is responsible for iterating the pixel data for “image->rows” times, which is 32. This second loop will be executed for 32 times or number of rows in the image irrespective of allocated buffer size .
  • Inside this second for loop, we can see something like this:

  • We can notice that “ImportQuantumPixel” function uses the “p” pointer to read the data from “strip_pixels” and after each call to “ImportQuantumPixel”, value of “p” will be increased by “stride”.

Here “stride” is calculated by calling function “TIFFVStripSize()” function which as per documentation returns the number of bytes in a strip with nrows rows of data.  In this case it is 14. So, every time pointer “p” is incremented by “14” or “0xE” inside the second for loop.

If we print the image structure which is passed to “ImportQuantumPixels” function as parameter, we can see following:

Here we can notice that the columns value is 3, the rows value is 32 and depth is 9. If we check in the POC TIFF file, this has been taken from ImageWidth and ImageLength and BitsPerSample value:

Ultimately, control reaches to “ImportRGBQuantum” and then to the “PushQuantumPixel” function and one of the arguments to this function is the pixels data which is pointed by “p”. Remember that this points to the memory address which was previously allocated using the “AcquireQuantumMemory” function, and that its length is 248 byte and every time value of “p” is increased by 14.

The “PushQuantumPixel” function is used to read pixel data from “p” into the internal pixel data storage of ImageMagick. There is a for loop which is responsible for reading data from the provided pixels array of 248 bytes into a structure “quantum_Info”. This loop reads data from pixels incrementally and saves it in the “quantum_info->state.pixels” field.

The root cause here is that there are no proper bounds checks and the program tries to read data beyond the allocated buffer size on the heap, while reading the strip data inside a for loop.

This causes a crash in ImageMagick as we can see below:

Root cause

Therefore, to summarize, the program crashes because:

  1. The program allocates 248 bytes of memory to process strip data for image, a pointer “p” points to this memory.
  2. Inside a for loop this pointer is increased by “14” or “0xE” for number of rows in the image, which in this case is 32.
  3. Based on this calculation, 32*14=448 bytes or more amount of memory is required but only 248 in actual memory were allocated.
  4. The program tries to read data assuming total memory is of 448+ bytes, but the fact that only 248 bytes are available causes an Out of Bound memory read issue.

How it was fixed?

If we check at the patch diff, we can see that the following changes were made to fix this issue:

Here the 2nd argument to “AcquireQuantumMemory” is multiplied by 2 thus increasing the total amount of memory and preventing this Out of Bound read issue from heap memory. The total memory allocated is 496 bytes, 248*2=496 bytes, as we can see below:

Another issue with the fix:

A new version of ImageMagick 7.0.46 was released to fix this issue. While the patch fixes the memory allocation issue, if we check the code below, we can see that there was a call to memset which didn’t set the proper memory size to zero.

Memory was allocated extent*2*sizeof(*strip_pixels) but in this memset to 0 was only done for extent*sizeof(*strip_pixels). This means half of the memory was set to 0 and rest contained 0xbebebebe, which is by default for ASAN new memory allocation.

This has since been fixed in subsequent releases of ImageMagick by using extent=2*TIFFStripSize(tiff); in the following patch:


Processing various image files requires deep understanding of various file formats and thus it is possible that something may not be exactly implemented or missed. This can lead to various vulnerabilities in such image processing software. Some of this vulnerability can lead to DoS and some can lead to remote code execution affecting every installation of such popular software.

Fuzzing plays an important role in finding vulnerabilities often missed by developers and during testing. We at McAfee constantly fuzz various closed source as well as open source software to help secure them. We work very closely with various vendors and do responsible disclosure. This shows McAfee’s commitment towards securing the software and protecting our customers from various threats.

We will continue to fuzz various software and work with vendors to help mitigate risk arriving from such threats.

We would like to thank and appreciate ImageMagick team for quickly resolving this issue within 24 hours and releasing a new version to fix this issue.

The post Fuzzing ImageMagick and Digging Deeper into CVE-2020-27829 appeared first on McAfee Blogs.

Analyzing CVE-2021-1665 – Remote Code Execution Vulnerability in Windows GDI+

28 June 2021 at 19:44
Consejos para protegerte de quienes intentan hackear tus correos electrónicos


Microsoft Windows Graphics Device Interface+, also known as GDI+, allows various applications to use different graphics functionality on video displays as well as printers. Windows applications don’t directly access graphics hardware such as device drivers, but they interact with GDI, which in turn then interacts with device drivers. In this way, there is an abstraction layer to Windows applications and a common set of APIs for everyone to use.

Because of its complex format, GDI+ has a known history of various vulnerabilities. We at McAfee continuously fuzz various open source and closed source software including windows GDI+. Over the last few years, we have reported various issues to Microsoft in various Windows components including GDI+ and have received CVEs for them.

In this post, we detail our root cause analysis of one such vulnerability which we found using WinAFL: CVE-2021-1665 – GDI+ Remote Code Execution Vulnerability.  This issue was fixed in January 2021 as part of a Microsoft Patch.

What is WinAFL?

WinAFL is a Windows port of a popular Linux AFL fuzzer and is maintained by Ivan Fratric of Google Project Zero. WinAFL uses dynamic binary instrumentation using DynamoRIO and it requires a program called as a harness. A harness is nothing but a simple program which calls the APIs we want to fuzz.

A simple harness for this was already provided with WinAFL, we can enable “Image->GetThumbnailImage” code which was commented by default in the code. Following is the harness code to fuzz GDI+ image and GetThumbnailImage API:


As you can see, this small piece of code simply creates a new image object from the provided input file and then calls another function to generate a thumbnail image. This makes for an excellent attack vector and can affect various Windows applications if they use thumbnail images. In addition, this requires little user interaction, thus software which uses GDI+ and calls GetThumbnailImage API, is vulnerable.

Collecting Corpus:

A good corpus provides a sound foundation for fuzzing. For that we can use Google or GitHub in addition to further test corpus available from various software and public EMF files which were released for other vulnerabilities. We have generated a few test files by making changes to a sample code provided on Microsoft’s site which generates an EMF file with EMFPlusDrawString and other records:


Minimizing Corpus:

After we have collected an initial corpus file, we need to minimize it. For this we can use a utility called as follows: -D D:\\work\\winafl\\DynamoRIO\\bin32 -t 10000 -i inCorpus -o minCorpus -covtype edge -coverage_module gdiplus.dll -target_module gdiplus_hardik.exe -target_method fuzzMe -nargs 2 — gdiplus_hardik.exe @@

How does WinAFL work?

WinAFL uses the concept of in-memory fuzzing. We need to provide a function name to WinAFL. It will save the program state at the start of the function and take one input file from the corpus, mutate it, and feed it to the function.

It will monitor this for any new code paths or crashes. If it finds a new code path, it will consider the new file as an interesting test case and will add it to the queue for further mutation. If it finds any crashes, it will save the crashing file in crashes folder.

The following picture shows the fuzzing flow:

Fuzzing with WinAFL:

Once we have compiled our harness program, collected, and minimized the corpus, we can run this command to fuzz our program with WinAFL:

afl-fuzz.exe -i minCorpus -o out -D D:\work\winafl\DynamoRIO\bin32 -t 20000 —coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module gdiplus_hardik.exe -target_offset 0x16e0 -nargs 2 — gdiplus_hardik.exe @@


We found a few crashes and after triaging unique crashes, and we found a crash in “gdiplus!BuiltLine::GetBaselineOffset” which looks as follows in the call stack below:

As can be seen in the above image, the program is crashing while trying to read data from a memory address pointed by edx+8. We can see it registers ebx, ecx and edx contains c0c0c0c0 which means that page heap is enabled for the binary. We can also see that c0c0c0c0 is being passed as a parameter to “gdiplus!FullTextImager::RenderLine” function.

Patch Diffing to See If We Can Find the Root Cause

To figure out a root cause, we can use patch diffing—namely, we can use IDA BinDiff plugin to identify what changes have been made to patched file. If we are lucky, we can easily find the root cause by just looking at the code that was changed. So, we can generate an IDB file of patched and unpatched versions of gdiplus.dll and then run IDA BinDiff plugin to see the changes.

We can see that one new function was added in the patched file, and this seems to be a destructor for BuiltLine Object :

We can also see that there are a few functions where the similarity score is < 1 and one such function is FullTextImager::BuildAllLines as shown below:

Now, just to confirm if this function is really the one which was patched, we can run our test program and POC in windbg and set a break point on this function. We can see that the breakpoint is hit and the program doesn’t crash anymore:

Now, as a next step, we need to identify what has been changed in this function to fix this vulnerability. For that we can check flow graph of this function and we see something as follows. Unfortunately, there are too many changes to identify the vulnerability by simply looking at the diff:

The left side illustrates an unpatched dll while right side shows a patched dll:

  • Green indicates that the patched and unpatched blocks are same.
  • Yellow blocks indicate there has been some changes between unpatched and patched dlls.
  • Red blocks call out differences in the dlls.

If we zoom in on the yellow blocks we can see following:

We can note several changes. Few blocks are removed in the patched DLL, so patch diffing will alone will not be sufficient to identify the root cause of this issue. However, this presents valuable hints about where to look and what to look for when using other methods for debugging such as windbg. A few observations we can spot from the bindiff output above:

  • In the unpatched DLL, if we check carefully we can see that there is a call to “GetuntrimmedCharacterCount” function and later on there is another call to a function “SetSpan::SpanVector
  • In the patched DLL, we can see that there is a call to “GetuntrimmedCharacterCount” where a return value stored inside EAX register is checked. If it’s zero, then control jumps to another location—a destructor for BuiltLine Object, this was newly added code in the patched DLL:

So we can assume that this is where the vulnerability is fixed. Now we need to figure out following:

  1. Why our program is crashing with the provided POC file?
  2. What field in the file is causing this crash?
  3. What value of the field?
  4. Which condition in program which is causing this crash?
  5. How this was fixed?

EMF File Format:

EMF is also known as enhanced meta file format which is used to store graphical images device independently. An EMF file is consisting of various records which is of variable length. It can contain definition of various graphic object, commands for drawing and other graphics properties.

Credit: MS EMF documentation.

Generally, an EMF file consist of the following records:

  1. EMF Header – This contains information about EMF structure.
  2. EMF Records – This can be various variable length records, containing information about graphics properties, drawing order, and so forth.
  3. EMF EOF Record – This is the last record in EMF file.

Detailed specifications of EMF file format can be seen at Microsoft site at following URL:

Locating the Vulnerable Record in the EMF File:

Generally, most of the issues in EMF are because of malformed or corrupt records. We need to figure out which record type is causing this crash. For this if we look at the call stack we can see following:

We can notice a call to function “gdiplus!GdipPlayMetafileRecordCallback

By setting a breakpoint on this function and checking parameter, we can see following:

We can see that EDX contains some memory address and we can see that parameter given to this function are: 00x00401c,0x00000000 and 0x00000044.

Also, on checking the location pointed by EDX we can see following:

If we check our POC EMF file, we can see that this data belongs to file from offset: 0x15c:

By going through EMF specification and manually parsing the records, we can easily figure out that this is a “EmfPlusDrawString” record, the format of which is shown below:

In our case:

Record Type = 0x401c EmfPlusDrawString record

Flags = 0x0000

Size = 0x50

Data size = 0x44

Brushid = 0x02

Format id = 0x01

Length = 0x14

Layoutrect = 00 00 00 00 00 00 00 00 FC FF C7 42 00 00 80 FF

String data =

Now that we have located the record that seems to be causing the crash, the next thing is to figure out why our program is crashing. If we debug and check the code, we can see that control reaches to a function “gdiplus!FullTextImager::BuildAllLines”. When we decompile this code, we can see something  like this:

The following diagram shows the function call hierarchy:

The execution flow in summary:

  1. Inside “Builtline::BuildAllLines” function, there is a while loop inside which the program allocates 0x60 bytes of memory. Then it calls the “Builtline::BuiltLine”
  2. The “Builtline::BuiltLine” function moves data to the newly allocated memory and then it calls “BuiltLine::GetUntrimmedCharacterCount”.
  3. The return value of “BuiltLine::GetUntrimmedCharacterCount” is added to loop counter, which is ECX. This process will be repeated until the loop counter (ECX) is < string length(EAX), which is 0x14 here.
  4. The loop starts from 0, so it should terminate at 0x13 or it should terminate when the return value of “GetUntrimmedCharacterCount” is 0.
  5. But in the vulnerable DLL, the program doesn’t terminate because of the way loop counter is increased. Here, “BuiltLine::GetUntrimmedCharacterCount” returns 0, which is added to Loop counter(ECX) and doesn’t increase ECX value. It allocates 0x60 bytes of memory and creates another line, corrupting the data that later leads the program to crash. The loop is executed for 21 times instead of 20.

In detail:

1. Inside “Builtline::BuildAllLines” memory will be allocated for 0x60 or 96 bytes, and in the debugger it looks as follows:

2. Then it calls “BuiltLine::BuiltLine” function and moves the data to newly allocated memory:

3. This happens in side a while loop and there is a function call to “BuiltLine::GetUntrimmedCharacterCount”.

4. Return value of “BuiltLine::GetUntrimmedCharacterCount” is stored in a location 0x12ff2ec. This value will be 1 as can be seen below:

5. This value gets added to ECX:

6. Then there is a check that determines if ecx< eax. If true, it will continue loop, else it will jump to another location:

7. Now in the vulnerable version, loop doesn’t exist if the return value of “BuiltLine::GetUntrimmedCharacterCount” is 0, which means that this 0 will be added to ECX and which means ECX will not increase. So the loop will execute 1 more time with the “ECX” value of 0x13. Thus, this will lead to loop getting executed 21 times rather than 20 times. This is the root cause of the problem here.

Also after some debugging, we can figure out why EAX contains 14. It is read from the POC file at offset: 0x174:

If we recall, this is the EmfPlusDrawString record and 0x14 is the length we mentioned before.

Later on, the program reaches to “FullTextImager::Render” function corrupting the value of EAX because it reads the unused memory:

This will be passed as an argument to “FullTextImager::RenderLine” function:

Later, program will crash while trying to access this location.

Our program was crashing while processing EmfPlusDrawString record inside the EMF file while accessing an invalid memory location and processing string data field. Basically, the program was not verifying the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function and this resulted in taking a different program path that  corrupted the register and various memory values, ultimately causing the crash.

How this issue was fixed?

As we have figured out by looking at patch diff above, a check was added which determined the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function.

If the retuned value is 0, then program xor’s EBX which contains counter and jump to a location which calls destructor for Builtline Object:

Here is the destructor that prevents the issue:


GDI+ is a very commonly used Windows component, and a vulnerability like this can affect billions of systems across the globe. We recommend our users to apply proper updates and keep their Windows deployment current.

We at McAfee are continuously fuzzing various open source and closed source library and work with vendors to fix such issues by responsibly disclosing such issues to them giving them proper time to fix the issue and release updates as needed.

We are thankful to Microsoft for working with us on fixing this issue and releasing an update.





The post Analyzing CVE-2021-1665 – Remote Code Execution Vulnerability in Windows GDI+ appeared first on McAfee Blogs.

McAfee Labs Report Highlights Ransomware Threats

24 June 2021 at 04:01

The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: June 2021.

In this edition we introduce additional context into the biggest stories dominating the year thus far including recent ransomware attacks. While the topic itself is not new, there is no question that the threat is now truly mainstream.

This Threats Report provides a deep dive into ransomware, in particular DarkSide, which resulted in an agenda item in talks between U.S. President Biden and Russian President Putin. While we have no intention of detailing the political landscape, we certainly do have to acknowledge that this is a threat disrupting our critical services. Furthermore, adversaries are supported within an environment that make digital investigations challenging with legal barriers that make the gathering of digital evidence almost impossible from certain geographies.

That being said, we can assure the reader that all of the recent campaigns are incorporated into our products, and of course can be tracked within our MVISION Insights preview dashboard.

This dashboard shows that – beyond the headlines – many more countries have experienced such attacks. What it will not show is that victims are paying the ransoms, and criminals are introducing more Ransomware-as-a-Service (RaaS) schemes as a result. With the five-year anniversary of the launch of the No More Ransom initiative now upon us it’s fair to say that we need more global initiatives to help combat this threat.

Q1 2021 Threat Findings

McAfee Labs threat research during the first quarter of 2021 include:

  • New malware samples averaging 688 new threats per minute
  • Coin Miner threats surged 117%
  • New Mirai malware variants drove increase in Internet of Things and Linux threats

Additional Q1 2021 content includes:

  • McAfee Global Threat Intelligence (GTI) queries and detections
  • Disclosed Security Incidents by Continent, Country, Industry and Vectors
  • Top MITRE ATT&CK Techniques APT/Crime

We hope you enjoy this Threats Report. Don’t forget to keep track of the latest campaigns and continuing threat coverage by visiting our McAfee Threat Center. Please stay safe.

The post McAfee Labs Report Highlights Ransomware Threats appeared first on McAfee Blogs.

A New Program for Your Peloton – Whether You Like It or Not

16 June 2021 at 04:01
Connected Fitness

Executive Summary 

The McAfee Advanced Threat Research team (ATR) is committed to uncovering security issues in both software and hardware to help developers provide safer products for businesses and consumers. As security researchers, something that we always try to establish before looking at a target is what our scope should be. More specifically, we often assume well-vetted technologies like network stacks or the OS layers are sound and instead focus our attention on the application layers or software that is specific to a target. Whether that approach is comprehensive sometimes doesn’t matter; and it’s what we decided to do for this project as well, bypassing the Android OS itself and with a focus on the Peloton code and implementations. During our research process, we uncovered a flaw (CVE-2021-33887) in the Android Verified Boot (AVB) process, which was initially out of scope, that left the Peloton vulnerable. 

For those that are not familiar with Peloton, it is a brand that has combined high end exercise equipment with cutting-edge technology. Its products are equipped with a large tablet that interfaces with the components of the fitness machine, as well as provides a way to attend virtual workout classes over the internet. “Under the hood” of this glossy exterior, however, is a standard Android tablet, and this hi-tech approach to exercise equipment has not gone unnoticed. Viral marketing mishaps aside, Peloton has garnered attention recently regarding concerns surrounding the privacy and security of its products. So, we decided to take a look for ourselves and purchased a Pelton Bike+.

Attempting to Backup 

One of the first things that we usually try do when starting a new project, especially when said projects involve large expenses like the Peloton, is to try to find a way to take a backup or system dump that could be used if a recovery is ever needed. Not all of our research techniques keep the device in a pristine state (we’d be poor hackers if they did)and having the ability to restore the device to its factory settings is a safety net that we try to implement on our targets 

Because we are working with a normal Android device with only the Peloton customizations running at the application layer, many of the processes used to back up an Android phone would also work with the Peloton. It is common in the Android custom ROM scene to use a custom recovery image that allows the user to take full flash dumps of each critical partition and provides a method to restore them later. In such communities, it often also goes without saying that the device must first be unlocked in order to perform any of these steps. While the Android OS allows users to flash these critical partitions, there are restrictions in place that typically prevent an attacker from gaining access to the “currently” running system. If an attacker was able to get their hands on an Android device with the goal of installing a rootkit, they would have to jump through some hoops. The first step that an attacker would need to take is to enable “Original Equipment Manufacturer (OEM) Unlocking”, which is a user mode setting within the “developer options” menu. Even with physical access to the bootloader, an attacker would not be able to “unlock” the Android device unless this setting is checked. This option is usually secured behind the user’s password, PIN, or biometric phone lock, preventing an attacker from accessing it easily. The second security measure in place is that even with the “OEM Unlocking” setting on, issuing commands to the bootloader to perform the unlock first causes all data on the Android device, including applications, files, passwords, etc., to be wiped. This way, even if an attacker did gain access to the Android device of an unsuspecting victim, they wouldn’t be able to install a rootkit or modify the existing kernel without deleting all the data, which both prevents personal data from falling into the attacker’s hands and makes it obvious the device has been tampered with. 

For this research effort, wresisted the urge to unlock the Peloton, as there are ways for apps to query the unlock status of a device within Android, and we wanted to ensure that any vulnerabilities we found weren’t the result of the device behaving differently due to it being unlocked. These discrepancies that arise from our research are usually identified by having two target devices: one to serve as the control and the other to serve as the test device. Unfortunately, we only had one Peloton to play with. Another issue was that the Peloton hardware is not very common and the developers of the aforementioned custom recovery images, like Team Win Recovery Project (TWRP), don’t create images for every device,  just the most common ones. So, the easy method of taking a backup would not only require unlocking the device but also trying to create our own custom recovery image 

This left us as at a crossroads. We could unlock the bootloader and root the device, granting us access to the flash memory block devices (raw interfaces to the flash partitions) internallywhich would allow us to create and restore backups as needed. However, as mentioned before, this would leave the bike in a recognizably “tampered” state. Alternatively, we could try to capture one of the bike’s Over-The-Air (OTA) updates to use as backup, but we would still need to “unlock” the device to actually flash the OTA image manually. Both options were less than ideal so we kept looking for other solutions. 

Android Verified Boot Process

Just as Secure Boot provides a security mechanism for properly booting the OS on Windows PCs, Android has implemented measures to control the boot process, called Android Verified Boot (AVB). According to Android’s documentation, AVB requires cryptographically verifying all executable code and data that is part of the Android version being booted before it is used. This includes the kernel (loaded from the boot partition), the device tree (loaded from the dtbo partition), system partition, vendor partition, and so on. 

The Peloton Bike+ ships with the default settings of “Verity Mode” set to trueas well as “Device Unlocked” and “Device Critical Unlocked” set to falsewhich is intended to prevent the loading of modified boot images and provide a way to determine if the device has been tampered with. This information was verified by running fastboot oem device-info on the Peloton, as demonstrated in Figure 1. 


Figure 1: OEM device info showing verity mode and unlocked status. 

To clarify, a simplified Android boot process can be visualized as follows: 

Figure 2: Simplified Android Boot Process 

If modified code is found at any of the stages in Figure 2, the boot process should abort or, if the device is unlocked, warn the user that the images are not verified and give the option to the user to abort the boot. 

Given that we defined our scope of this project to not include the Android boot process as a part of our research and verifying that Peloton has attempted to use the security measures provided by Android, we again found ourselves debating if a backup would be possible.  

In newer Android releases, including the Peloton, the update method uses Android’s Seamless System Updates (A/B). This update method no longer needs the “recovery” partition, forcing users who wish to use a custom recovery to use the fastboot boot command which will download and boot the supplied image. This is a temporary boot that doesn’t “flash“ or alter any of the flash partitions of the device and will revert to the previous boot image on restartSince this option allows for modified code to be executed, it is only available when the device is in an unlocked state and will error out with a message stating Please unlock device to enable this command, if attempted on a locked device.  

This is a good security implementation because if this command was always allowed, it would be very similar to the process of booting from a live USB on your PC, where you can login as a root user and have full control over the underlying system and components. 

Booting Modified Code 

This is where our luck or maybe naïveté worked to our advantage. Driven by our reluctance to unlock the device and our desire to make a backup, we tried to boot a generic TWRP recovery image just to see what would happen. The image ended up leaving us at a black screen, and since each recovery image needs to contain a small kernel with the correct drivers for the display, touch digitizer, and other devicespecific hardware, this was to be expectedWhat we didn’t expect, however, was for it to get past the fastboot boot command. While we didn’t get a custom recovery running, it did tell us one thingthe system was not verifying that the device was unlocked before attempting to boot a custom imageNormally this command would be denied on a “locked” device and would have just errored out on the fastboot command, as mentioned previously. 

It is also important to point out that despite having booted a modified image, the internal fuse had not been burned. These fuses are usually burned during the OEM unlocking process to identify if a device has allowed for a different “root of trust” to be installed. The burning of such a fuse is a permanent operation and a burnt fuse often indicates that the device has been tampered with. As shown in Figure 3, the “Secure Boot” fuse was still present, and the device was reporting a locked bootloader. 

Figure 3: Secure boot enabled with fused protection 

Acquiring an OTA Image 

This discovery was unexpected and we felt like we had stumbled upon a flaw that gave us the ability to finally take a backup of the device and leave the Peloton in an “untampered” state. Knowing that a custom image could be booted even with a “locked” bootloader, we began looking at ways to gather a valid boot image, which would contain the correct kernel drivers to facilitate a successful boot. If we could piece together the OTA update URL and just download an update package directly from Peloton, it would likely contain a boot image that we could modifyHaving the ability to modify a boot image would give us root and access to the blocked devices. 

Even with just ADB debugging enabled we were able to pull the Pelotonspecific applications from the device. We listed all the Peloton APKand sought out the ones that could help us get the OTA path, shown in Figure 4. 

Figure 4: Listing Peloton Specific Applications and Highlighting the one related to OTA Updates. 

Finding the name OTAService promising, we pulled down the APK and began to reverse-engineer it using JADX. After some digging, we discovered how the app was building the download URL string for OTA updateswhich would then be passed to beginDownload(), as seen in Figure 5. 

Figure 5OTA image path being constructed as “key” 

We also noticed quite a few Android log calls that could help us, such as the one right before the call to beginDownload(), so we used Android’s builtin logcat command and grepped the output for “OTA” as seen in Figure 6. Doing so, we were able to find which S3 bucket was used for the OTA updates and even a file manifest titled OTAConfig.json  

Figure 6: Relevant OTA logs in red 

Combining the information obtained from OTAService.apk and the logs, we were able to piece together the full path to the OTA images manifest file and names for each OTA zip file, as shown in Figure 7.  

Figure 7: Contents of OTAConfig.json 

Our next step was to extract the contents of the OTA update to get a valid boot.img file that would contain all the specific kernel drivers for the Peloton hardware. Since the Peloton is using AndroidA/B partitions, which facilitate seamless updates, the update packages were stored in a “payload.bin” format. Using the Android payload dumper tool, we were able to extract all of the images contained in the bin file. 

Modifying the Boot Image 

Once the boot.img was extracted, we needed a way to modify the initial kernel to allow us to gain root access on the device. Although there are a variety of ways to accomplish this, we decided to keep things simple and just use the Magisk installer to patch the boot.img file to include the “su” binary. With the boot.img patched, we were able to use the fastboot boot command again but this time passing it our patched boot.img file. Since the Verified Boot process on the Peloton failed to identify the modified boot image as tampered, the OS booted normally with the patched boot.img file. After this process was complete, the Peloton Bike+ was indistinguishable from its “normal” state under visual inspection and the process left no artifacts that would tip off the user that the Pelton had been compromised. But appearances can be deceiving, and in reality the Android OS had now been rootedallowing us to use the su” command to become root and perform actions with UID=0, as seen in Figure 8. 

Figure 8: Booting modified boot.img and executing whoami as Root 

Impact Scenarios 

As we just demonstrated, the ability to bypass the Android Verified Boot process can lead to the Android OS being compromised by an attacker with physical accessA worst-case scenario for such an attack vector might involve a malicious agent booting the Peloton with a modified image to gain elevated privileges and then leveraging those privileges to establish a reverse shell, granting the attacker unfettered root access on the bike remotely. Since the attacker never has to unlock the device to boot a modified image, there would be no trace of any access they achieved on the device. This sort of attack could be effectively delivered via the supply chain process. A malicious actor could tamper with the product at any point from construction to warehouse to delivery, installing a backdoor into the Android tablet without any way the end user could know. Another scenario could be that an attacker could simply walk up to one of these devices that is installed in a gym or a fitness room and perform the same attack, gaining root access on these devices for later use. The Pelobuddy interactive map in figure 9 below could help an attacker find public bikes to attack. 

Figure’s interactive map to help locate public Peloton exercise equipment. 

Once an attacker has root, they could make their presence permanent by modifying the OS in a rootkit fashion, removing any need for the attacker to repeat this step. Another risk is that an attacker could modify the system to put themselves in a man-in-the-middle position and sniff all network traffic, even SSL encrypted traffic, using a technique called SSL unpinning, which requires root privileges to hook calls to internal encryption functionality. Intercepting and decrypting network traffic in this fashion could lead to users personal data being compromised. Lastly, the Peloton Bike+ also has a camera and a microphone installed. Having remote access with root permissions on the Android tablet would allow an attacker to monitor these devices and is demoed in the impact video below. 

Disclosure Timeline and Patch 

Given the simplicity and criticality of the flaw, we decided to disclose to Peloton even as we continue to audit the device for remote vulnerabilities. We sent our vendor disclosure with full details on March 2, 2021 – shortly after, Peloton confirmed the issue and subsequently released a fix for it in software version “PTX14A-290”. The patched image no longer allows for the “boot” command to work on a user build, mitigating this vulnerability entirelyThe Peloton vulnerability disclosure process was smooth, and the team were receptive and responsive with all communications. Further conversations with Peloton confirmed that this vulnerability is also present on Peloton Tread exercise equipment; however, the scope of our research was confined to the Bike+.

Peloton’s Head of Global Information Security, Adrian Stone, shared the following “this vulnerability reported by McAfee would require direct, physical access to a Peloton Bike+ or Tread. Like with any connected device in the home, if an attacker is able to gain physical access to it, additional physical controls and safeguards become increasingly important. To keep our Members safe, we acted quickly and in coordination with McAfee. We pushed a mandatory update in early June and every device with the update installed is protected from this issue.”

We are continuing to investigate the Peloton Bike+, so make sure you stay up to date on McAfee’s ATR blogs for any future discoveries. 

The post A New Program for Your Peloton – Whether You Like It or Not appeared first on McAfee Blogs.

Are Virtual Machines the New Gold for Cyber Criminals?

AI Cyber Security


Virtualization technology has been an IT cornerstone for organization for years now. It revolutionized the way organizations can scale up IT systems in a heartbeat, allowing then to be more agile as opposed to investing into dedicated “bare-metal” hardware. To the outside untrained eye, it might seem that there are different machines on the network, while in fact all the “separate” machines are controlled by a hypervisor server. Virtualization plays such a big role nowadays that it isn’t only used to spin up servers but also anything from virtual applications to virtual user desktops.

This is something cyber criminals have been noticing too and we have seen an increased interest in hypervisors. After all, why attack the single virtual machine when you can go after the hypervisor and control all the machines at once?

In recent months several high impact CVEs regarding virtualization software have been released which allowed for Remote Code Execution (RCE); initial access brokers are offering compromised VMware vCenter servers online, as well as ransomware groups developing specific ransomware binaries for encrypting ESXi servers.

VMware CVE-2021-21985 & CVE-2021-21986

On the 25th of May VMware disclosed a vulnerability impacting VMware vCenter servers allowing for Remote Code Execution on internet accessible vCenter servers, version 6.5,6.7 and 7.0. VMware vCenter is a management tool, used to manage virtual machines and ESXi servers.

CVE-2021-21985 is a remote code execution (RCE) vulnerability in the vSphere Client via the Virtual SAN (vSAN) Health Check plugin. This plugin is enabled by default. The combination of RCE and default enablement of the plugin resulted in this being scored as a critical flaw with a CVSSv3 score of 9.8.

An attacker needs to be able to access vCenter over TCP port 443 to exploit this vulnerability. It doesn’t matter if the vCenter is remotely exposed or when the attacker has internal access.

The same exploit vector is applicable for CVE-2021-21986, which is an authentication mechanism issue in several vCenter Server Plug-ins. It would allow an attacker to run plugin functions without authentication. This leads to the CVE being scored as a ‘moderate severity’, with a CVSSv3 score of 6.5.

While writing this blog, a Proof-of-Concept was discovered that will test if the vulnerability exists; it will not execute the remote-code. The Nmap plugin can be downloaded from this location:

Searching with the Shodan search engine, narrowing it down to the TCP 443 port, we observe that close to 82,000 internet accessible ESXi servers are exposedZooming in further on the versions that are affected by these vulnerabilities,  almost 55,000 publicly accessible ESXi servers are potentially vulnerable to CVE-2021-21985 and CVE-2021-21986, providing remote access to them and making them potential candidates for ransomware attacks, as we will read about in the next paragraphs.

Ransomware Actors Going After Virtual Environments

Ransomware groups are always trying to find ways to hit their victims where it hurts. So, it is only logical that they are adapting to attacking virtualization environments and the native Unix/Linux machines running the hypervisors. In the past, ransomware groups were quick to abuse earlier CVEs affecting VMware. But aside from the disclosed CVEs, ransomware groups have also adapted their binaries specifically to encrypt virtual machines and their management environment. Below are some of the ransomware groups we have observed.

DarkSide Ransomware

Figure 1. Screenshot from the DarkSide ransomware group, explicitly mentioning its Linux-based encryptor and support for ESXi and NAS systems

McAfee Advanced Threat Research (ATR) analyzed the DarkSide Linux binary in our recent blog and we can confirm that a specific routine aimed at virtual machines is present in it.

Figure 2. DarkSide VMware Code routine

From the configuration file of the DarkSide Linux variant, it becomes clear that this variant is solely designed to encrypt virtual machines hosted on an ESXi server. It searches for the disk-files of the VMs, the memory files of the VMs (vmem), swap, logs, etc. – all files that are needed to start a VMware virtual machine.

Demo of Darkside encrypting an ESXi server:

Babuk Ransomware

Babuk announced on an underground forum that it was developing a cross-platform binary aimed at Linux/UNIX and ESXi or VMware systems:

Figure 3. Babuk ransomware claiming to have built a Linux-based ransomware binary capable of encrypting ESXi servers

The malware is written in the open-source programming language Golang, most likely because it allows developers to have a single codebase to be compiled into all major operating systems. This means that, thanks to static linking, code written in Golang on a Linux system can run on a Windows or Mac system. That presents a large advantage to ransomware gangs looking to encrypt a whole infrastructure comprised of different systems architecture.

After being dropped on the ESXi server, the malware encrypts all the files on the system:

The malware was designed to target ESXi environments as we guessed, and it was confirmed when the Babuk team returned the decryptor named d_esxi.out. Unfortunately, the decryptor has been developed with some errors, which cause corruption in victim’s files:

Overall, the decryptor is poor as it only checks for the extension “.babyk” which will miss any files the victim has renamed to recover them. Also, the decryptor checks if the file is more than 32 bytes in length as the last 32 bytes are the key that will be calculated later with other hardcoded values to get the final key. This is bad design as those 32 bytes could be trash, instead of the key, as the customer could make things, etc. It does not operate efficiently by checking the paths that are checked in the malware, instead it analyzes everything. Another error we noticed was that the decryptor tries to remove a ransom note name that is NOT the same that the malware creates in each folder. This does not make any sense unless, perhaps, the Babuk developers/operators are delivering a decryptor that works for a different version and/or sample.

The problems with the Babuk decryptor left victims in horrible situations with permanently damaged data. The probability of getting a faulty decryptor isn’t persuading victims to pay up and this might be one of the main reasons that Babuk  announced that it will stop encrypting data and only exfiltrate and extort from now on.

Initial-Access-Brokers Offering VMware vCenter Machines

It is not only ransomware groups that show an interest in virtual systems; several initial access brokers are also trading access to compromised vCenter/ESXi servers on underground cybercriminal forums. The date and time of the specific offering below overlaps with the disclosure of CVE-2021-21985, but McAfee ATR hasn’t determined if this specific CVE was used to gain access to ESXi servers.

Figure 4. Threat Actor selling access to thousands of vCenter/ESXi servers

Figure 5. Threat actor offering compromised VMware ESXi servers

Patching and Detection Advice

VMware urges users running VMware vCenter and VMware Cloud Foundation affected by CVE-2021-21985 and CVE-2021-21986 to apply its patch immediately. According to VMware, a malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server. The disclosed vulnerabilities have a critical CVSS base score of 9.8.

However, we do understand that VMware infrastructure is often installed on business-critical systems, so any type of patching activity usually has a high degree of impact on IT operations. Hence, the gap between vulnerability disclosure and patching is typically high. With the operating systems on VMware being a closed system they lack the ability to natively install workload protection/detection solutions. Therefore, the defenses should be based on standard cyber hygiene/risk mitigation practices and should be applied in the following order where possible.

  1. Ensure an accurate inventory of vCenter assets and their corresponding software versions.
  2. Secure the management plane of the vCenter infrastructure by applying strict network access control policies to allow access only from special management networks.
  3. Disable all internet access to vCenter/VMware Infrastructure.
  4. Apply the released VMware patches.
  5. McAfee Network Security Platform (NSP) offers signature sets for detection of CVE-2021-21985 and CVE-2021-21986.


Virtualization and its underlying technologies are key in today’s infrastructures. With the release of recently discovered vulnerabilities and an understanding of their criticality, threat actors are shifting focus. Proof can be seen in underground forums where affiliates recruit pentesters with knowledge of specific virtual technologies to develop custom ransomware that is designed to cripple these technologies. Remote Desktop access is the number one access vector in many ransomware cases, followed by edge-devices lacking the latest security updates, making them vulnerable to exploitation. With the latest VMware CVEs mentioned in this blog, we urge you to take the right steps to secure not only internet exposed systems, but also internal systems, to minimize the risk of your organization losing its precious VMs, or gold, to cyber criminals.


Special thanks to Thibault Seret, Mo Cashman, Roy Arnab and Christiaan Beek for their contributions.

The post Are Virtual Machines the New Gold for Cyber Criminals? appeared first on McAfee Blogs.

Scammers Impersonating Windows Defender to Push Malicious Windows Apps

17 May 2021 at 21:25

Summary points:

  • Scammers are increasingly using Windows Push Notifications to impersonate legitimate alerts
  • Recent campaigns pose as a Windows Defender Update
  • Victims end up allowing the installation of a malicious Windows Application that targets user and system information

Browser push notifications can highly resemble Windows system notifications.  As recently discussed, scammers are abusing push notifications to trick users into taking action.  This recent example demonstrates the social engineering tactics used to trick users into installing a fake Windows Defender update.  A toaster popup in the tray informs the user of a Windows Defender Update.

Clicking the message takes the user to a fake update website.

The site serves a signed ms-appinstaller (MSIX) package.  When downloaded and run, the user is prompted to install a supposed Defender Update from “Publisher: Microsoft”

After installation, the “Defender Update” App appears in the start menu like other Windows Apps.

The shortcut points to the installed malware: C:\Program Files\WindowsApps\245d1cf3-25fc-4ce1-9a58-7cd13f94923a_1.0.0.0_neutral__7afzw0tp1da5e\bloom\Eversible.exe, which is a data stealing trojan, targeting various applications and information:

  • System information (Process list, Drive details, Serial number, RAM, Graphics card details)
  • Application profile data (Chrome, Exodus wallet, Ethereum wallet, Opera, Telegram Desktop)
  • User data (Credit card, FileZilla)

Am I protected?

  • McAfee customers utilizing Real Protect Cloud were proactively protected from this threat due to machine learning.
  • McAfee customers utilizing web protection (including McAfee Web Advisor and McAfee Web Control) are protected from known malicious sites.
  • McAfee Global Threat Intelligence (GTI) provides protection at Very Low sensitivity

General safety tips

  • See: How to Stop the Popups
  • Scams can be quite convincing. It’s better to be quick to block something and slow to allow than the opposite.
  • When in doubt, initiate the communication yourself.
    • For Windows Updates, click the Start Menu and type “Check For Updates”, click the System Settings link.
    • Manually enter in a web address rather than clicking a link sent to you.
    • Confirm numbers and addresses before reaching out, such as phone and email.

Reference IOCs

  • MSIX installer: 02262a420bf52a0a428a26d86aca177796f18d1913b834b0cbed19367985e190
  • exe: 0dd432078b93dfcea94bec8b7e6991bcc050e6307cd1cb593583e7b5a9a0f9dc
  • Installer source site: updatedefender [dot] online


The post Scammers Impersonating Windows Defender to Push Malicious Windows Apps appeared first on McAfee Blogs.

DarkSide Ransomware Victims Sold Short

14 May 2021 at 10:32
How to check for viruses

Over the past week we have seen a considerable body of work focusing on DarkSide, the ransomware responsible for the recent gas pipeline shutdown. Many of the excellent technical write-ups will detail how it operates an affiliate model that supports others to be involved within the ransomware business model (in addition to the developers). While this may not be a new phenomenon, this model is actively deployed by many groups with great effect. Herein is the crux of the challenge: while the attention may be on DarkSide ransomware, the harsh reality is that equal concern should be placed at Ryuk, or REVIL, or Babuk, or Cuba, etc. These, and other groups and their affiliates, exploit common entry vectors and, in many cases, the tools we see being used to move within an environment are the same. While this technical paper covers DarkSide in more detail, we must stress the importance of implementing best practices in securing/monitoring your network. These additional publications can guide you in doing so:

DarkSide Ransomware:  What is it?

As mentioned earlier, DarkSide is a Ransomware-as-a-Service (RaaS) that offers high returns for penetration-testers that are willing to provide access to networks and distribute/execute the ransomware. DarkSide is an example of a RaaS whereby they actively invest in development of the code, affiliates, and new features. Alongside their threat to leak data, they have a separate option for recovery companies to negotiate, are willing to engage with the media, and are willing to carry out a Distributed Denial of Service (DDoS) attack against victims. Those victims who do pay a ransom receive an alert from DarkSide on companies that are on the stock exchange who are breached, in return for their payment. Potential legal issues abound, not to mention ethical concerns, but this information could certainly provide an advantage in short selling when the news breaks.

The group behind DarkSide are also particularly active. Using MVISION Insights we can identify the prevalence of targets. This map clearly illustrates that the most targeted geography is clearly the United States (at the time of writing). Further, the sectors primarily targeted are Legal Services, Wholesale, and Manufacturing, followed by the Oil, Gas and Chemical sectors.

Coverage and Protection Advice

McAfee’s market leading EPP solution covers DarkSide ransomware with an array of early prevention and detection techniques.

Customers using MVISION Insights will find a threat-profile on this ransomware family that is updated when new and relevant information becomes available.

Early Detection

MVISION EDR includes detections on many of the behaviors used in the attack including privilege escalation, malicious PowerShell and CobaltStrike beacons, and visibility of discovery commands, command and control, and other tactics along the attack chain. We have EDR telemetry indicating early detection before the detonation of the Ransomware payload.


ENS TP provides coverage against known indicators in the latest signature set. Updates on new indicators are pushed through GTI.

ENS ATP provides behavioral content focusing on proactively detecting the threat while also delivering known IoCs for both online and offline detections.

ENS ATP adds two (2) additional layers of protection thanks to JTI rules that provide attack surface reduction for generic ransomware behaviors and RealProtect (static and dynamic) with ML models targeting ransomware threats.

For the latest mitigation guidance, please review:

Technical Analysis

The RaaS platform offers the affiliate the option to build either a Windows or Unix version of the ransomware. Depending on what is needed, we observe that affiliates are using different techniques to circumvent detection, by masquerading the generated Windows binaries of DarkSide. Using several packers or signing the binary with a certificate are some of the techniques used to do so.

As peers in our industry have described, we also observed campaigns where the affiliates and their hacking crew used several ways to gain initial access to their victim’s network.

  1. Using valid accounts, exploit vulnerabilities on servers or RDP for initial stage
  2. Next, establish a beachhead in the victim’s network by using tools like Cobalt-Strike (beacons), RealVNC, RDP ported over TOR, Putty, AnyDesk and TeamViewer. TeamViewer is what we also see back in the config of the ransomware sample:

The configuration of the ransomware contains several options to enable or disable system processes, but also the above part where it states which processes should not be killed.

As mentioned before, a lot of the current Windows samples in the wild are the 1.8 version of DarkSide, others are the version. In a chat one of the actors revealed that a V3 version will be released soon.

On March 23rd, 2021, on XSS, one of the DarkSide spokespersons announced an update of DarkSide as a PowerShell version and a major upgrade of the Linux variant:

In the current samples we observe, we do see the PowerShell component that is used to delete the Volume Shadow copies, for example.

  1. Once a strong foothold has been established, several tools are used by the actors to gain more privileges.

Tools observed:

  • Mimikatz
  • Dumping LSASS
  • IE/FireFox password dumper
  • Powertool64
  • Empire
  • Bypassing UAC
  1. Once enough privileges are gained, it is time to map out the network and identify the most critical systems like servers, storage, and other critical assets. A selection of the below tools was observed to have been used in several cases:
  • BloodHound
  • ADFind
  • ADRecon
  • IP scan tools
  • Several Windows native tools
  • PowerShell scripts

Before distributing the ransomware around the network using tools like PsExec and PowerShell, data was exfiltrated to Cloud Services that would later be used on the DarkSide Leak page for extortion purposes. Zipping the data, using Rclone or WinSCP are some of the examples observed.

While a lot of good and in-depth analyses are written by our peers, one thing worth noting is that when running DarkSide, the encryption process is fast. It is one of the areas the actors brag about on the same forum and do a comparison to convince affiliates to join their program:

DarkSide, like Babuk ransomware, has a Linux version. Both target *nix systems but in particular VMWare ESXi servers and storage/NAS. Storage/NAS is critical for many companies, but how many of you are running a virtual desktop, hosted on a ESXi server?

Darkside wrote a Linux variant that supports the encryption of ESXI server versions 5.0 – 7.1 as well as NAS technology from Synology. They state that other NAS/backup technologies will be supported soon.

In the code we clearly observe this support:

Also, the configuration of the Linux version shows it is clearly looking for Virtual Disk/memory kind of files:

Although the adversary recently claimed to vote for targets, the attacks are ongoing with packed and signed samples observed as recently as today (May 12, 2021):


Recently the Ransomware Task Force, a partnership McAfee is proud to be a part of, released a detailed paper on how ransomware attacks are occurring and how countermeasures should be taken. As many of us have published, presented on, and released research upon, it is time to act. Please follow the links included within this blog to apply the broader advice about applying available protection and detection in your environment against such attacks.

MITRE ATT&CK Techniques Leveraged by DarkSide:

Data Encrypted for Impact – T1486

Inhibit System Recovery – T1490

Valid Accounts – T1078

PowerShell – T1059.001

Service Execution – T1569.002

Account Manipulation – T1098

Dynamic-link Library Injection – T1055.001

Account Discovery – T1087

Bypass User Access Control – T1548.002

File Permissions Modification – T1222

System Information Discovery – T1082

Process Discovery – T1057

Screen Capture – T1113

Compile After Delivery – T1027.004

Credentials in Registry – T1552.002

Obfuscated Files or Information – T1027

Shared Modules – T1129

Windows Management Instrumentation – T1047

Exploit Public-Facing Application – T1190

Phishing – T1566

External Remote Services – T1133

Multi-hop Proxy – T1090.003

Exploitation for Privilege Escalation – T1068

Application Layer Protocol – T1071

Bypass User Account Control – T1548.002

Commonly Used Port – T1043

Compile After Delivery – T1500

Credentials from Password Stores – T1555

Credentials from Web Browsers – T1555.003

Credentials in Registry – T1214

Deobfuscate/Decode Files or Information – T1140

Disable or Modify Tools – T1562.001

Domain Account – T1087.002

Domain Groups – T1069.002

Domain Trust Discovery – T1482

Exfiltration Over Alternative Protocol – T1048

Exfiltration to Cloud Storage – T1567.002

File and Directory Discovery – T1083

Gather Victim Network Information – T1590

Ingress Tool Transfer – T1105

Linux and Mac File and Directory Permissions Modification – T1222.002

Masquerading – T1036

Process Injection – T1055

Remote System Discovery – T1018

Scheduled Task/Job – T1053

Service Stop – T1489

System Network Configuration Discovery – T1016

System Services – T1569

Taint Shared Content – T1080

Unix Shell – T1059.004

The post DarkSide Ransomware Victims Sold Short appeared first on McAfee Blogs.

Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit

12 May 2021 at 15:48
AI Cyber Security

Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.

With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.

The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.

At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.

McAfee Network Security Platform (NSP) Protection
Sigset Version:
Attack ID: 0x4528f000
Attack Name: HTTP: Microsoft HTTP Protocol Stack Remote Code Execution Vulnerability (CVE-2021-31166)

McAfee Knowledge Base Article KB94510:



The post Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit appeared first on McAfee Blogs.

“Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards

11 May 2021 at 04:01
By: Anne An


Countries all over the world are racing to achieve so-called herd immunity against COVID-19 by vaccinating their populations. From the initial lockdown to the cancellation of events and the prohibition of business travel, to the reopening of restaurants, and relaxation of COVID restrictions on outdoor gatherings, the vaccine rollout has played a critical role in staving off another wave of infections and restoring some degree of normalcy. However, a new and troubling phenomenon is that consumers are buying COVID-19 vaccines on the black market due to the increased demand around the world. As a result, illegal COVID-19 vaccines and vaccination records are in high demand on darknet marketplaces.

The impact on society is that the proliferation of fraudulent test results and counterfeit COVID-19 vaccine records pose a serious threat to public health and spur the underground economyIndividuals undoubtedly long to return to their pre-pandemic routines and the freedom of travel and behavior denied them over the last year. However, the purchase of false COVID-19 test certifications or vaccination cards to board aircraft, attend an event or enter a country endangers themselves, even if they are asymptomatic. It also threatens the lives of other people in their own communities and around the world. Aside from the collective damage to global health, darknet marketplace transactions encourage the supply of illicit goods and services. The underground economy cycle continues as demand creates inventory, which in turn creates supply. In addition to selling COVID-19 vaccines, vaccination cards, and fake test results, cybercriminals can also benefit by reselling the names, dates of birth, home addresses, contact details, and other personally indefinable information of their customers. 

Racing Toward a Fully Vaccinated Society Along with a Growing Underground Vaccine Market

As we commemorate the one-year anniversary of the COVID-19 pandemic, at least 184 countries and territories worldwide have started their vaccination rollouts.[1] The United States is vaccinating Americans at an unprecedented rate. As of May 2021, more than 105 million Americans had been fully vaccinated. The growing demand has made COVID-19 vaccines the new “liquid gold” in the pandemic era.

However, following vaccination success, COVID-19 related cybercrime has increased. COVID-19 vaccines are currently available on at least a dozen darknet marketplaces. Pfizer-BioNTech COVID-19 vaccines (and we can only speculate as to whether they are genuine or a form of liquid “fool’s gold”) can be purchased for as little as $500 per dose from top-selling vendors. These sellers use various channels, such as Wickr, Telegram, WhatsApp and Gmail, for advertising and communications. Darknet listings associated with alleged Pfizer-BioNTech COVID-19 vaccines are selling for $600 to $2,500. Prospective buyers can receive the product within 2 to 10 days. Some of these supposed COVID-19 vaccines are imported from the United States, while others are packed in the United Kingdom and shipped to every country in the world, according to the underground advertisement.

Figure 1: Dark web marketplace offering COVID-19 vaccines

Figure 2: Dark web marketplace offering COVID-19 vaccines

A vendor sells 10 doses of what they claim to be Moderna COVID-29 vaccines for $2,000. According to the advertisement, the product is available to ship to the United Kingdom and worldwide.

Figure 3: Dark web marketplace offering COVID-19 vaccines

Besides what are claimed to be COVID-19 vaccines, cybercriminals offer antibody home test kits for $152 (again, we do not know whether they are genuine or not). According to the advertisement, there are various shipping options available. It costs $41 for ‘stealth’ shipping to the United States, $10.38 to ship to the United Kingdom, and $20 to mail the vaccines internationally.

Figure 4: Dark web marketplace offering COVID-19 test kits

Proof of Vaccination in the Underground Market

On the darknet marketplaces, the sales of counterfeit COVID-19 test results and vaccination certificates began to outnumber the COVID vaccine offerings in mid-April. This shift is most likely because COVID-19 vaccines are now readily available for those who want them. People can buy and show these certificates without being vaccinated. A growing number of colleges will require students to have received a COVID-19 vaccine before returning to in-person classes by this fall.[2] Soon, COVID-19 vaccination proof is likely to become a requirement of some type of “passport” to board a plane or enter major events and venues.

The growing demand for proof of vaccination is driving an illicit economy for fake vaccination and test certificates. Opportunistic cybercriminals capitalize on public interest in obtaining a COVID-19 immunity passport, particularly for those who oppose COVID-19 vaccines or test positive for COVID-19 but want to return to school or work, resume travel or attend a public event. Counterfeit negative COVID-19 test results and COVID-19 vaccination cards are available for sale at various darknet marketplaces. Fake CDC-issued vaccination cards are available for $50. One vendor offers counterfeit German COVID-19 certificates for $23.35. Vaccination cards with customized information, such as “verified” batch or lot numbers for particular dates and “valid” medical and hospital information, are also available for purchase.

One darknet marketplace vendor offers to sell a digital copy of the COVID-19 vaccination card with detailed printing instructions for $50.

Figure 5: Dark web marketplace offering COVID-19 vaccination cards

One vendor sells CDC vaccination cards for $1,200 and $1,500, as seen in the following screenshot. These cards, according to the advertisement, can be personalized with details such as the prospective buyer’s name and medical information.

Figure 6: Dark web marketplace offering COVID-19 vaccination cards

Other darknet marketplace vendors offer fake CDC-issued COVID-19 vaccination card packages for $1,200 to $2,500. The package contains a PDF file that buyers can type and print, as well as personalized vaccination cards with “real” lot numbers, according to the advertisement. Prospective buyers can pay $1,200 for blank cards or $1,500 for custom-made cards with valid batch numbers, medical and hospital details.

Figure 7: Dark web marketplace offering COVID-19 vaccination cards

One vendor offers counterfeit negative COVID-19 test results and vaccine passports to potential buyers.

Figure 8: Dark web marketplace offering negative COVID-19 test results and vaccination cards

A seller on another dark web market sells five counterfeit German COVID-19 certificates for $23.35. According to the advertisement below, the product is available for shipping to Germany and the rest of the world.

Figure 9: Dark web marketplace offering German COVID-19 vaccination certificates


The proliferation of fraudulent test results and counterfeit COVID-19 vaccine records on darknet marketplaces poses a significant threat to global health while fueling the underground economyWhile an increasing number of countries begin to roll out COVID-19 vaccines and proof of vaccination, questionable COVID vaccines and fake proofs are emerging on the underground market. With the EU and other jurisdictions opening their borders to those who have received vaccinations, individuals will be tempted to obtain false vaccination documents in their drive to a return to pre-pandemic normalcy that includes summer travel and precious time with missed loved ones. Those who buy questionable COVID-19 vaccines or forged vaccination certificaterisk their own lives and the lives of others. Apart from the harm to global health, making payments to darknet marketplaces promotes the growth of illegal products and services. The cycle of the underground economy continues as demand generates inventory, which generates supply. These are the unintended consequences of an effective global COVID vaccine rollout. 

[1] https[:]//

[2] https[:]//

The post “Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards appeared first on McAfee Blogs.

Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware

5 May 2021 at 18:17
Quel antivirus choisir ?

The Roaming Mantis smishing campaign has been impersonating a logistics company to steal SMS messages and contact lists from Asian Android users since 2018. In the second half of 2020, the campaign improved its effectiveness by adopting dynamic DNS services and spreading messages with phishing URLs that infected victims with the fake Chrome application MoqHao.

Since January 2021, however, the McAfee Mobile Research team has established that Roaming Mantis has been targeting Japanese users with a new malware called SmsSpy. The malicious code infects Android users using one of two variants depending on the version of OS used by the targeted devices. This ability to download malicious payloads based on OS versions enables the attackers to successfully infect a much broader potential landscape of Android devices.

Smishing Technique

The phishing SMS message used is similar to that of recent campaigns, yet the phishing URL contains the term “post” in its composition.

Japanese message: I brought back your luggage because you were absent. please confirm. hxxps://post[.]cioaq[.]com


Fig: Smishing message impersonating a notification from a logistics company. (Source: Twitter)

Another smishing message pretends to be a Bitcoin operator and then directs the victim to a phishing site where the user is asked to verify an unauthorized login.

Japanese message: There is a possibility of abnormal login to your [bitFlyer] account. Please verify at the following URL: hxxps://bitfiye[.]com


Fig: Smishing message impersonating a notification from a bitcoin operator. (Source: Twitter)

During our investigation, we observed the phishing website hxxps://bitfiye[.]com redirect to hxxps://post.hygvv[.]com. The redirected URL contains the word “post” as well and follows the same format as the first screenshot. In this way, the actors behind the attack attempt to expand the variation of the SMS phishing campaign by redirecting from a domain that resembles a target company and service.

Malware Download

Characteristic of the malware distribution platform, different malware is distributed depending on the Android OS version that accessed the phishing page. On Android OS 10 or later, the fake Google Play app will be downloaded. On Android 9 or earlier devices, the fake Chrome app will be downloaded.

Japanese message in the dialog: “Please update to the latest version of Chrome for better security.”

Fig: Fake Chrome application for download (Android OS 9 or less)


Japanese message in the dialog: “[Important] Please update to the latest version of Google Play for better security!”


Fig: Fake Google Play app for download (Android OS 10 or above)

Because the malicious program code needs to be changed with each major Android OS upgrade, the malware author appears to cover more devices by distributing malware that detects the OS, rather than attempting to cover a smaller set with just one type of malware

Technical Behaviors

The main purpose of this malware is to steal phone numbers and SMS messages from infected devices. After it runs, the malware pretends to be a Chrome or Google Play app that then requests the default messaging application to read the victim’s contacts and SMS messages. It pretends to be a security service by Google Play on the latest Android device. Additionally, it can also masquerade as a security service on the latest Android devices. Examples of both are seen below.

Japanese message: “At first startup, a dialog requesting permissions is displayed. If you do not accept it, the app may not be able to start, or its functions may be restricted.”


Fig: Default messaging app request by fake Chrome app


Japanese message: “Secure Internet Security. Your device is protected. Virus and Spyware protection, Anti-phishing protection and Spam mail protection are all checked.”

Fig: Default messaging app request by fake Google Play app

After hiding its icon, the malware establishes a WebSocket connection for communication with the attacker’s command and control (C2) server in the background. The default destination address is embedded in the malware code. It further has link information to update the C2 server location in the event it is needed. Thus, if no default server is detected, or if no response is received from the default server, the C2 server location will be obtained from the update link.

The MoqHao family hides C2 server locations in the user profile page of a blog service, yet some samples of this new family use a Chinese online document service to hide C2 locations. Below is an example of new C2 server locations from an online document:

Fig: C2 server location described in online document

As part of the handshake process, the malware sends the Android OS version, phone number, device model, internet connection type (4G/Wi-Fi), and unique device ID on the infected device to the C2 server.

Then it listens for commands from the C2 server. The sample we analyzed supported the commands below with the intention of stealing phone numbers in Contacts and SMS messages.

Command String Description
通讯录 Send whole contact book to server
收件箱 Send all SMS messages to server
拦截短信&open Start <Delete SMS message>
拦截短信&close Stop <Delete SMS message>
发短信& Command data contains SMS message and destination number, send them via infected device

Table: Remote commands via WebSocket


We believe that the ongoing smishing campaign targeting Asian countries is using different mobile malware such as MoqHao, SpyAgent, and FakeSpy. Based on our research, the new type of malware discovered this time uses a modified infrastructure and payloads. We believe that there could be several groups in the cyber criminals and each group is developing their attack infrastructures and malware separately. Or it could be the work of another group who took advantage of previously successful cyber-attacks.

McAfee Mobile Security detects this threat as Android/SmsSpy and alerts mobile users if it is present and further protects them from any data loss. For more information about McAfee Mobile Security, visit

Appendix – IoC

C2 Servers:

  • 168[.]126[.]149[.]28:7777
  • 165[.]3[.]93[.]6:7777
  • 103[.]85[.]25[.]165:7777

Update Links:

  • r10zhzzfvj[.]
  • 0204[.]info
  • 0130one[.]info
  • 210302[.]top
  • 210302bei[.]top

Phishing Domains:

Domain Registration Date 2021-03-15 2021-03-11 2021-03-08 2021-03-04 2021-03-04 2021-02-08 2021-02-06 2021-02-05 2021-02-04 2021-02-03 2021-02-01 2021-02-01 2021-01-31 2021-01-30 2021-01-30 2021-01-30 2021-01-29 2021-01-29 2021-01-28 2021-01-27 2021-01-25 2021-01-24 2021-01-23 2021-01-22 2021-01-21 2021-01-19 2021-01-16 2021-01-15 2021-01-12 2021-01-2


Sample Hash information:

Hash Package name Fake Application
EA30098FF2DD1D097093CE705D1E4324C8DF385E7B227C1A771882CABEE18362 com.gmr.keep Chrome
29FCD54D592A67621C558A115705AD81DAFBD7B022631F25C3BAAE954DB4464B com.gmr.keep Google Play
9BEAD1455BFA9AC0E2F9ECD7EDEBFDC82A4004FCED0D338E38F094C3CE39BCBA Google Play
D33AB5EC095ED76EE984D065977893FDBCC12E9D9262FA0E5BC868BAD73ED060 com.mrc.keep Chrome
8F8C29CC4AED04CA6AB21C3C44CCA190A6023CE3273EDB566E915FE703F9E18E com.hhz.keeping Chrome
21B958E800DB511D2A0997C4C94E6F0113FC4A8C383C73617ABCF1F76B81E2FD com.hhz.keeping Google Play
7728EF0D45A337427578AAB4C205386CE8EE5A604141669652169BA2FBA23B30 com.hz.keep3 Chrome
056A2341C0051ACBF4315EC5A6EEDD1E4EAB90039A6C336CC7E8646C9873B91A com.hz.keep3 Google Play
054FA5F5AD43B6D6966CDBF4F2547EDC364DDD3D062CD029242554240A139FDB com.hz.keep2 Google Play
DD40BC920484A9AD1EEBE52FB7CD09148AA6C1E7DBC3EB55F278763BAF308B5C com.hz.keep2 Chrome
FC0AAE153726B7E0A401BD07C91B949E8480BAA0E0CD607439ED01ABA1F4EC1A com.hz.keep1 Google Play
711D7FA96DFFBAEECEF12E75CE671C86103B536004997572ECC71C1AEB73DEF6 com.hz.keep1 Chrome
FE916D1B94F89EC308A2D58B50C304F7E242D3A3BCD2D7CCC704F300F218295F com.hz.keep1 Google Play
3AA764651236DFBBADB28516E1DCB5011B1D51992CB248A9BF9487B72B920D4C com.hz.keep1 Chrome
F1456B50A236E8E42CA99A41C1C87C8ED4CC27EB79374FF530BAE91565970995 com.hz.keep Google Play
77390D07D16E6C9D179C806C83D2C196A992A9A619A773C4D49E1F1557824E00 com.hz.keep Chrome
49634208F5FB8BCFC541DA923EBC73D7670C74C525A93B147E28D535F4A07BF8 com.hz.keep Chrome
B5C45054109152F9FE76BEE6CBBF4D8931AE79079E7246AA2141F37A6A81CBA3 com.hz.keep Google Play
85E5DBEA695A28C3BA99DA628116157D53564EF9CE14F57477B5E3095EED5726 com.hz.keep Chrome
53A5DD64A639BF42E174E348FEA4517282C384DD6F840EE7DC8F655B4601D245 com.hz.keep Google Play
80B44D23B70BA3D0333E904B7DDDF7E19007EFEB98E3B158BBC33CDA6E55B7CB com.hz.keep Chrome
797CEDF6E0C5BC1C02B4F03E109449B320830F5ECE0AA6D194AD69E0FE6F3E96 com.hz.keep Chrome
691687CB16A64760227DCF6AECFE0477D5D983B638AFF2718F7E3A927EE2A82C com.hz.keep Google Play
C88C3682337F7380F59DBEE5A0ED3FA7D5779DFEA04903AAB835C959DA3DCD47 com.hz.keep Google Play


The post Roaming Mantis Amplifies Smishing Campaign with OS-Specific Android Malware appeared first on McAfee Blogs.

Steps to Discover Hidden Threat from Phishing Email

5 May 2021 at 18:04
coin miners


Email is one of the primary ways of communication in the modern world. We use email to receive notifications about our online shopping, financial transaction, credit card e-statements, one-time passwords to authenticate registration processes, application for jobs, auditions, school admissions and many other purposes. Since many people around the globe depend on electronic mail to communicate, phishing emails are an attack method favored by cyber criminals.

In this type of attack, cyber criminals design emails to look convincing and send them to targeted people. The sender pretends to be someone the potential victim knows, someone who can be trusted, like a friend, or close contact, or the very bank where they save their income, or even the social media platform where they might have an account. As soon as they click on any malicious files or links embedded within these emails, they may land in a compromised situation.

Detailed Analysis

In this write up, I will focus on things to look at while hunting threats in phishing emails.

Header analysis:

An email is divided into three parts: header, body, and attachment. The header part keeps the routing information of the email. It may contain other information like content type, from, to, delivery date, sender origin, mail server, and the actual email address used to send/receive the email.

Important headers

Return- Path:

The Return-path email address receives the delivery status information. To get undelivered emails, or any other bounced back messages, our emails’ server uses Return-Path. The recipient server uses this field to identify spoof emails. In this process, the recipient server retrieves all the permitted IPs related to the sender domain and matches with the sender IP. If it fails to provide any match, we can consider the email to be spam.


This field shows information related to all hops, through which the email was transferred. The last entry shows the initial address of the email sender.


This field’s email address is used to receive the reply message. It can differ from the address in spoof emails.


SPF (Sender Policy Framework) helps to verify that messages appearing from a particular domain were sent from servers under control of the actual owner. If the value is Pass, then the email source is valid.


Domain Keys Identified Mail (DKIM) signs the outgoing email with an encrypted signature inside the headers and the recipient email server decrypts it, using a shared public key to check whether the message was changed in transit.


These headers are known as experimental or extension headers. They are usually added by the recipient mailbox providers. Fields like X-FOSE-Spam and X-Spam-Score are used to identify spam emails.

Consider the following email message:


Figure1: Raw email header information

  1. In the above example we notice the return path does not match with the from address, meaning any undelivered email will return to the return path email address.
  2. In the Received field, the domain name from where this email is sent is (the email spoofing site) and not This is clearly not legitimate. Even the IP ( does not correspond to, as per the Whois lookup.
  3. The from email address is different from the Reply-To email address. This clearly implies that the actual reply will go to not to
  4. The Received-SPF value is neutral; the domain neither permits nor denies the IP ( On further confirmation with Whois lookup, we see that this domain does not belong to the IP (
  5. DKIM is none. This means the email is unsigned.

Based on the above information the email is suspected to be spoofed. We should put the extracted email IDs in the block list.

Email Body Analysis:

The email bodies of phishing emails we usually receive mostly target our trust, by having something faithful and reliable in their content. It is so personalized and seemingly genuine, that victim’s often take the bait. Let us see the example below and understand what actions should be taken in such a scenario.

Figure2: Phishing email related to COVID-19

In the above email, the spammer pretends to be a medical insurance service provider and this mail is regarding a health-plan payment invoice for COVID-19 insurance the victim has supposedly purchased recently.

Figure2: Phishing email related to COVID-19 (continued)


Moreover, if we look closely at the bottom of the email, we can see the message, ‘This email has been scanned by McAfee’. This makes the email appear believable, as well as trustworthy.

Now, if we hover the mouse pointer over the |SEE DETAILS| button, one OneDrive link will pop up. Rather than clicking on the link, we must copy it for execution separately.

Figure3: Downloaded html file after clicking on the OneDrive link.

To execute the above OneDrive link separately (hxxps://1drv[.]ms/u/s!Ajmzc7fpBw5lrzwfPwIkoZRelG4D), it would be preferable to load it inside an isolated environment. If you do not have such an environment available yourself, you can use an online browser service like Browserling.

After loading the link in the browser, you will notice that it downloads an html attachment. Clicking on the html file takes us to another webpage (hxxps://selimyildiz[.]


Figure4: Fake Office 365 login page

The content of the site is a lookalike of an online Microsoft Excel document where it is asking for Office 365 login details to download it. Before doing anything here we need to check a few more things.

Figure5: WordPress admin panel of selimyildiz[.]

To further validate whether the webpage is genuine or not, I have shortened the URL to its domain level to load it. The domain leads to a WordPress login page which does not belong to Microsoft, further arousing suspicion.

Figure 6: whois information of selimyildiz[.]

As per the whois information This domain has not been registered by Microsoft and it resolves to the public IP which is also not owned by Microsoft. The information clearly indicates that it is not a genuine website.

Figure7: Attempting to login with random credentials to validate the authentication

Now to check the behavior, I came back to the login page, enter some random credentials, and try to download the invoice. As expected, I was faced with a login failed error. Here on we can assume there might be two probable reasons for the login failure. Firstly, to make the victim believe that it is a genuine login page or, secondly, to confirm whether the typed password is correct, as the victim may have made a typing error.

Figure8: Fake invoice to lure the victim

Now that we know this is fake, what is next? To validate the authentication check I entered random credentials again and bingo! This time it redirects to a pdf invoice, which looks genuine by showing it belongs to some medical company. However, the sad part is if the victim falls under this trap then, by the time they realize that this is a fake invoice, their login credentials will be phished.

Email Attachment Analysis:

In email, users commonly share two types of documents as an attachment, Microsoft office documents or PDF files. These are often used in document-based malware campaigns. To exploit the targeted systems, attackers usually infect these documents using VBA or JavaScript and distribute them via (phishing) emails.

In the first section of this part, we will analyze a malicious Word document. This type of document contains malicious Visual Basic Application (VBA) code, known as macros. Sometimes, a macro triggers the moment a document is opened, but from Microsoft Office 2007 onwards, a macro cannot execute itself until and unless the user enables the macro content. To deal with such showstoppers, attackers utilize various social engineering methods, where the primary goal is to build trust with the victim so that they click on the ‘Enable Editing’ button without any second thought.

Word Document Analysis:

File Name: PR_Report.bin

Hash: e992ffe746b40d97baf56098e2110ff3978f8229ca333e87e24d1539cea7415c


  • Oletools
  • Yara
  • Didier Stevens Suite
  • Process Monitor
  • Windows Network Monitor (Packet capture tool)

Step 1: Getting started with File properties

It is always good practice to get familiar with the properties before starting any file analysis. We can get the details using the ‘file’ command in Linux.

  • We have found the file is a “Microsoft Office Word file”
  • Create Time/Date: Thu Jun 28 16:48:00 2018
  • Last Saved Time: Thu Jun 28 16:54:00 2018

Step 2: Apply Yara rules

Yara is a tool to identify and classify malware. This tool is used to conduct signature-based detection against any file. Let us check a couple of premade Yara rules from Didier Stevens Suites.

  • The above Yara rule (maldoc.yara) matches the OLE file magic number (D0 CF 11 E0) which is nothing but the HEX identifier (magic bytes) for Microsoft Office documents.
  • It also detects a couple of suspicious imports inside the file like GetProcAddr and LoadLibrary.

  • This Yara rule (contains_pe_file.yara) checks if a file has any PE file embedded. Based on that it matches the above strings from the file. MZ is a signature of a PE file.

Step 3: Dump the document contents using


As we know, an OLE file contains streams of data. will help us to analyze those streams further to extract macros or objects out of it.

You may notice in the above figure that we can see two letters ‘M‘ and ‘O’ in stream 8, 9 and 15, respectively. Here ‘M’ indicates the stream might contain macro code and ‘O’ indicates an object.

Step 4: Extract the VB script in macros



  • In stream 8, the code contains a method named as ‘killo’. This function saves the document with the same file name.
  • In stream 9, the code provides lot of interesting information.
    • In Document_Open() function we can find the file names like 5C.pif, 6C.pif where 5C.pif  is copying into ‘6C.pif’ using FileCopy function.
  • In the later part, the function is calling ‘killo’ method from the other module (Stream 8).
  • In the end Document_Close() function executes a obfuscated command using shell. After de-obfuscation we see it executes 6C.pif in background (using vbHide method) and pings localhost all together.

Shell cmd.exe /c  ping localhost -n 100 && start Environ(“Temp”) & “\6C.pif”, vbHide

Step 5: Extract file from the ole object.

It is clear that the document has an embedded file which can be extracted using the oleobj tool.

  • As shown above, oleobj extracts the embedded file from the object and saves it inside the current working directory.
  • The above highlighted part also provides details about the source path and temporary path where the file is going to save itself inside the victim’s system after execution of the document.

Step 6: Getting the static information from the extracted file.

  • The above information shows us this is a PE32 executable for MS Windows.
  • For confirmation, we can also run tool and find the PE headers inside the file.

Step 7: Behavior analysis

Setup a Windows 7 32-bit VM, change the file extension to ‘.exe’ and simply run Apate DNS and Windows Network Monitoring tool before execution.

Figure9: Command and Control domain’s DNS queries captured in Apate DNS

Figure10: Captured network traffic of 5C.exe while trying to communicate with the C2

  • The results in Apate DNS and Microsoft Network Monitoring tool show the file has created a process name 5C.exe and repeatedly tried connecting to multiple C2 servers.

Figure11:  Registry changes captured in Process Monitor


  • Process Monitor tells us some modifications took place in the Registry keys of Internet Settings by 5C.exe. It disabled the IE browser proxy by setting the value of ProxyEnable to 0 and SavedLegacySettings sets the 9th byte value to “09”. It means the browser disabled the proxy and automatically detect the internet settings.

We can summarize it as the Word document first ran a VBA macro, dropped and ran an embedded executable, created a new process, communicated with the C2 servers and made unauthorized Registry changes. This is enough information to consider the document as malicious. From this point, if we want, we can do more detailed analysis like debugging the executable or analyzing the process dump to learn more about the file behavior.

PDF Document Analysis:

A PDF document can be defined as a collection of objects that describes how the pages should be displayed inside the file.

Usually, an attack vector uses email or other social engineering skills to lure the user to click or open the pdf document. The moment a user opens the pdf file it typically executes JavaScript in the background that may exploit the existing vulnerability that persist with the Adobe pdf reader or drop an executable as a payload that might perform the rest of the objectives.

A pdf file has four components. They are header, body, reference, and trailer.

  1. Header is the topmost part of the document. It shows information related to the version of the document.
  2. Body might contain various objects (Objects are made of streams. These streams are used to store the data).
  3. The cross-reference table points to each object.
  4. Trailer points to the cross-reference table.

File name: Report.pdf

Sha256: a7b423202d5879d1f9e47ae85ce255e3758c5c1e5b19fcd56691dab288a47b4c

Tools –

Step 1: Scan the pdf document with PDFiD

PDFiD is a part of the Didier Stevens Suite. It scans the pdf document with a list of strings, which helps you to identify the information like JavaScript, Embedded files, actions while opening the documents and the count of the occurrences of some specific strings inside the pdf file.

  • According to the result shown above, PDFiD has identified the number of objects, streams, /JS, /JavaScript, OpenAction present inside the Report.pdf file. Here is some information about them.
    • /JS, /Javascript or /RichMedia means Pdf document contains JavaScript or Flash media.
    • /Embedded file indicates the presence of other file formats inside the pdf file.
    • /OpenAction, AA, /Acroform tells us an automatic action should be executed when the pdf document is opened/viewed.
    • Streams contain data inside an object.

Step 2: Looking inside the Objects

We have now discovered that there is JavaScript present inside the pdf file so let us start from there. We will run to search the JavaScript indirect object.

  • The above result shows the JavaScript will launch the file ‘virus’ whenever the pdf is opened so, in the next step, we will extract the mentioned file from the pdf.

Step 3: Extract the embedded file using peepdf.

Peepdf is a tool built in Python, which provides all the necessary components in one place that are required during PDF analysis.

Syntax: peepdf –i file_name.pdf

The syntax (-i) means enabling interaction mode.

To learn more, just type help with the topic and explore the options it displays.

  • The above result from peepdf indicates the embedded file is available in object number 14. Going inside object 14, we find it is pointed to object 15; similarly, object 15 is further pointed to object 16. Finally, we get a clue about the existence of the file ‘virus’ inside object 17. Usually, to avoid detection, attackers design documents like this. Now, if we look inside PDF version 1, there is only one stream available that is also pointed to 17. Seeing this, we come to know that object 17 is a stream and the file is available inside.

  • Now inside stream 17, we get the file signature starting with MZ and hex value starting with 4d 5a, which indicates this is a PE executable file.

  • Now save the stream as virus.exe and run file command for confirmation.


Step 4: Behavior analysis

Now set up a windows 7 32-bit virtual machine and execute the file.

Figure12: Process Explorer displays processes created by virus.exe

  • As shown in Process Explorer, virus.exe created a couple of suspicious processes (zedeogm.exe, cmd.exe) and they were terminated after execution.

Figure13: Process Monitor captured the system changes made by virus.exe

The results in Process Monitor show the file was dropped as zedeogm.exe. Later it modified the Windows firewall rule. Then it executed WinMail.exe, following which it started cmd.exe to execute ‘tmpd849fc4d.bat’ and exited the process.

At this point, we have collected enough evidence to treat the pdf file as malicious. We can also perform additional precautionary steps like binary debugging and memory forensics on the extracted IOCs to hunt for further threats


In this write-up, we have understood the purpose of email threat hunting, how it will help to take preventive actions against un-known threats. We have discovered the areas we should investigate for hunting threats. We learned how a malicious URL can be hidden inside an email body and its analysis to further see if it is malicious or not.

To stay protected:

  • Never trust the email sender. Always check the basic identity verification before responding to any email.
  • Never click on any links or open any attachment if the email sender is not genuine.
  • Attackers often use arbitrary domain names. So read the site address carefully to avoid the typo-squatting trap.
  • Cross-check the website background before providing any personal information like name, address, login details, financial information etc.
  • If you realize that you have already entered your credentials to any unauthorized sources please change your password immediately.
  • Use McAfee Web Gateway or McAfee WebAdvisor to get maximum security against malicious URLs and IPs.
  • For protection from drive-by downloads and real-time threats associated with email attachments, enabling McAfee Endpoint Security’s Suspicious Attachment detection is highly recommended.
  • MVISION Unified Cloud Edge protects against Tactics Technique and Procedure (TTP) used by Advanced Persistent Threats.
  • Suspicious links can be submitted to to check the status and to submit for review.
  • Suspicious files can be submitted to McAfee Labs

The post Steps to Discover Hidden Threat from Phishing Email appeared first on McAfee Blogs.

How to Stop the Popups

5 May 2021 at 18:06

McAfee is tracking an increase in the use of deceptive popups that mislead some users into taking action, while annoying many others.  A significant portion is attributed to browser-based push notifications, and while there are a couple of simple steps users can take to prevent and remediate the situation, there is also some confusion about how these should be handled.

How does this happen?

In many cases scammers use deception to trick users into Allowing push notifications to be delivered to their system.

In other cases, there is no deception involved.  Users willingly opt-in uncoerced.

What happens next?

After Allowing notifications, messages quickly start being received.  Some sites send notifications as often as every minute.

Many messages are deceptive in nature.  Consider this fake alert example.  Clicking the message leads to an imposter Windows Defender alert website, complete with MP3 audio and a phone number to call.

In several other examples, social engineering is crafted around the McAfee name and logo.  Clicking on the messages lead to various websites informing the user their subscription has expired, that McAfee has detected threats on their system, or providing direct links to purchase a McAfee subscription.  Note that “Remove Ads” and similar notification buttons typically lead to the publishers chosen destination rather than anything that would help the user in disabling the popups.  Also note that many of the destination sites themselves prompt the user to Allow more notifications.  This can have a cascading effect where the user is soon flooded with many messages on a regular basis.


How can this be remediated?

First, it’s important to understand that the representative images provided here are not indications of a virus infection.  It is not necessary to update or purchase software to resolve the matter.  There is a simple fix:

1. Note the name of the site sending the notification in the popup itself. It’s located next to the browser name, for example:

Example popup with a link to a Popup remover

2. Go to your browser settings’ notification section

3. Search for the site name and click the 3 dotes next to the entry.

Chrome’s notification settings

4. Select Block

Great, but how can this be prevented in the future?

The simplest way is to carefully read such authorization prompts and only click Allow on sites that you trust.  Alternatively, you can disable notification prompts altogether.

As the saying goes, an ounce of prevention is worth a pound of cure.

What other messages should I be on the lookout for?

While there are thousands of various messages and sites sending them, and messages evolve over time, these are the most common seen in April 2021:

  • Activate Protection Now?|Update Available: Antivirus
  • Activate your free security today – Download now|Turn On Windows Protection ✅
  • Activate your McAfee, now! ✅|Click here to review your PC protection
  • Activate your Mcafee, now! ✅|Reminder From McAfee
  • Activate your Norton, now! ✅|Click here to review your PC protection
  • Activate Your PC Security ✅|Download your free Windows protection now.
  • Antivirus Gratis Installieren✅|Bestes Antivirus–Kostenlos herunterladen
  • Antivirus Protection|Download Now To Protect Your Computer From Viruses &amp; Malware Attacks
  • Best Antivirus 2020 – Download Free Now|Install Your Free Antivirus ✅
  • Check here with a Free Virus Scan|Is Windows slow due to virus?
  • Click here to activate McAfee protection|McAfee Safety Alert
  • Click here to activate McAfee protection|Turn on your antivirus
  • Click Here To Activate McAfee Protection|Upgrade Your Antivirus
  • Click here to activate Norton protection|Turn on your antivirus ✅
  • Click here to clean.|System is infected!
  • Click here to fix the error|Protect your PC now !
  • Click here to fix the error|System alert!
  • Click here to protect your data.|Remove useless files advised
  • Click Here To Renew Subscription|Viruses Found (3)
  • Click here to review your PC protection|⚠ Your Mcafee has Expired
  • Click here to Scan and Remove Virus|Potential Virus?
  • Click To Renew Your Subscription|Viruses Found (3)
  • Click to turn on your Norton protection|New (1) Security Notification
  • Critical Virus Alert|Turn on virus protection
  • Free Antivirus Update is|available.Download and protect system?
  • Install Antivirus Now!|Norton – Protect Your PC!
  • Install FREE Antivirus now|Is the system under threat?
  • Install free antivirus|Protect your Windows PC!
  • Jetzt KOSTENLOSES Antivirus installieren|Wird das System bedroht?
  • McAfee Safety Alert|Turn on your antivirus now [Activate]
  • McAfee Total Protection|Trusted Antivirus and Privacy Protection
  • Norton Antivirus|Stay Protected. Activate Now!
  • Norton Expired 3 Days Ago!⚠ |Renew now to stay protected for your PC!
  • PC is under virus threat! |Renew Norton now to say protected ⚠
  • Protect Your Computer From Viruses|⚠ Activate McAfee Antivirus
  • Renew McAfee License Now!|Stay Protected. Renew Now!
  • Renew McAfee License Now!|Your McAfee Has Expired Today
  • Renew Norton License Now!|Your Norton Has Expired Today
  • Renew Now For 2021|Your Norton has Expired Today?
  • Renew now to stay protected!|⚠ Your Mcafee has Expired
  • Scan Report Ready|Tap to reveal
  • Turn on virus protection|Viruses found (3)
  • Your Computer Might be At Risk ☠ |❌ Renew Norton Antivirus!

General safety tips

  • Scams can be quite convincing. It’s better to be quick to block something and slow to allow than the opposite.
  • When in doubt, initiate the communication yourself.
    • Manually enter in a web address rather than clicking a link sent to you.
    • Confirm numbers and addresses before reaching out, such as phone and email.
  • McAfee customers utilizing web protection (including McAfee Web Advisor and McAfee Web Control) are protected from known malicious sites.

The post How to Stop the Popups appeared first on McAfee Blogs.