There are new articles available, click to refresh the page.
Today — 26 January 2022Vulnerabily Research

Vulnerability Spotlight: WiFi-connected security camera could be manipulated to spy on communications, among other malicious actions

26 January 2022 at 21:09
Francesco Benvenuto of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw.  Cisco Talos recently discovered several vulnerabilities in the Reolink RLC-410W security camera that could allow an attacker to perform several malicious actions, including performing man-in-the-middle...

[[ This is only the beginning! Please visit the blog for the complete entry ]]
Yesterday — 25 January 2022Vulnerabily Research

Vulnerability Spotlight: Vulnerability in Apple iOS, iPad OS and MacOS could lead to disclosure of sensitive memory data

25 January 2022 at 17:31
Jaewon Min of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw.  Cisco Talos recently discovered an out-of-bounds read vulnerability in Apple’s macOS and iOS operating systems that could lead to the disclosure of sensitive memory content. An attacker could capitalize on that...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

CVE-2021-44790: Code Execution on Apache via an Integer Underflow

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team detail a recent code execution vulnerability in the Apache webserver. The bug was originally discovered and reported by the researcher named Chamal. A carefully crafted request body can cause a buffer overflow in the mod_lua multipart parser, which could lead to code execution in the context of the security process. The following is a portion of their write-up covering CVE-2021-44790, with a few minimal modifications.

An integer underflow vulnerability has been reported in the mod_lua module of Apache httpd. The vulnerability is due to improper validation of the request body in the module's multipart parser, called via the r:parsebody() function in Lua scripts. A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation could lead to remote code execution under the security context of the server process, while an unsuccessful attack could lead to a denial-of-service condition.

The Vulnerability

The Apache HTTP server is the most popular webserver used on the Internet. The server is capable of being utilized with many different options and configurations. A wide variety of runtime loadable plug-in modules can be used to extend its functionality.

One of the official plug-in modules is the mod_lua module. As with all other modules, it can be compiled as a separate shared library with a “.so” extension. The purpose of this module is to allow the extension of the HTTP server with scripts written in the Lua programming language. If this module is loaded in the HTTP server configuration file, the lua-script handler can be set for files ending in “.lua”. The following demonstrates such a sample configuration:

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character.Parameters can be passed from the client to the server as name-value pairs in either the Request-URI, or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like this:

A similar request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:


The data in the Body of HTTP POST requests can be encoded using various standardized or proprietary methods. One of the standardized methods is multipart/form-data, defined in RFC 2388. Multipart/form-data is made up of multiple parts, each of which contains a Content-Disposition header. Each part is separated by a string of characters. The string of characters separating the parts is defined by the boundary keyword found on the Content-Type header line. The Content-Type must also be set to multipart/form-data. The Content-Disposition header contains a name parameter describing the form element being returned. Additional header lines may be present in each part; each line is separated by a new line sequence. The header is terminated by two consecutive new lines. The form element's data follows. The filename parameter provides a suggested filename to be used if the entity is detached and stored in a separate file.

One of the built-in functions supported by the mod_lua module is r:parsebody(). This function allows Lua scripts to parse the body of HTTP POST requests sent to the server. The function returns two Lua tables containing the parameter names and values parsed from the body. This function also supports HTTP POST requests encoded using the multipart/form-data content type.

An integer underflow vulnerability exists in the Apache HTTP server. When the mod_lua module is enabled and the r:parsebody() function is called from within a Lua script parsed by the server, the function req_parsebody() is called. This function checks if the HTTP POST request received by the server contains a Content-Type header beginning with the string "multipart/form-data; boundary=", indicating that the request body is encoded using the multipart/form-data content type. If found, the function searches for the boundary string defined in the ContentType header, saved to the multipart variable. After each match of the multipart string, the function searches for the first occurrence of two consecutive CRLF sequences, stored to the CRLF variable. If this match is found, the function searches in the following content for another occurrence of the multipart variable, stored to the end variable, indicating the end of the form element's data.

Later, the size of the form element's data is calculated by taking the end variable, subtracting the CRLF variable, then subtracting 8 (representing the two CRLF sequences before the element's data, and the CRLF and "--" characters at the end of the element's data). However, if the form element is not properly formatted, such that the end boundary string appears within less than 8 characters after the beginning of the two CRLF sequences, this subtraction would result in a negative number. The result of the subtraction is stored in a variable named vlen of type size_t. Therefore, if the subtraction results in a negative number, it will be converted into a large positive number before being stored in the vlen variable, resulting in an integer underflow. Specifically, if the subtraction results in -1, the vlen variable will contain the maximum size of size_t. Later, a buffer named buffer is allocated on the heap with a size of vlen+1. In the case described, this will result in an integer overflow, resulting in the allocation of a buffer of size 0. Later, the memcpy() function is called to copy the element's data into the buffer variable, with a size of vlen, resulting in a buffer overflow.

A remote, unauthenticated attacker could exploit this vulnerability by sending an HTTP POST request with a crafted body, encoded using the multipart/form-data content type, to the target server. Successful exploitation could lead to remote code execution under the security context of the server process, while an unsuccessful attack could lead to a denial-of-service condition.

Detection of Generic Attacks

The detection device must inspect all HTTP POST requests to URLs resolving to Lua scripts hosted on the Apache server. The detection device must then inspect the Content-Type header and check if it is set to “multipart/formdata”. If found, the detection device must inspect all instances of the boundary string from the Content-Type header in the HTTP body. For each instance of the boundary string found, the detection device must search for the first instance of two consecutive CRLF sequences following the found boundary. If found, the detection device must search for the next instance of the boundary string. If found, the detection device must calculate the number of characters between the beginning of the two consecutive CRLF sequences and the following boundary string. If the number of characters is less than 8, the traffic should be considered malicious; an attack exploiting this vulnerability is likely underway.

A sample malicious request, with 7 characters between beginning of the two consecutive CRLF sequences and the end boundary string, follows:

Note that the string matching must be performed in a case-sensitive manner


This bug has been patched by Apache with HTTP Server 2.4.52. They do not list any mitigating factors, so applying the update is the only method to fully address this vulnerability.

Special thanks to Guy Lederfein and Dusan Stevanovic of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-44790: Code Execution on Apache via an Integer Underflow

Before yesterdayVulnerabily Research

Talos Incident Response year-in-review for 2021

22 January 2022 at 13:45
By David Liebenberg.  Cisco Talos Incident Response (CTIR), as with everyone else in the cybersecurity world, dealt with a bevy of threats last year, as responders dealt with an expanding set of ransomware adversaries and several major cybersecurity incidents affecting organizations worldwide,...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Ukraine Campaign Delivers Defacement and Wipers, in Continued Escalation

24 January 2022 at 14:29
Authored by Nick Biasini, Michael Chen, Chris Neal, and Matt Olney with Contributions from Dmytro Korzhevin. Several cyber attacks against Ukrainian government websites — including website defacements and destructive wiper malware — have made headlines over the past few weeks as military...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Threat Roundup for January 14 to January 21

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Jan. 14 and Jan. 21. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Better Together: The Power of Managed Cybersecurity Services in the Face of Pressing Global Security Challenges

The results from the 2021 Global Security Attitude Survey paint a bleak picture of how organizations globally are feeling about the cybersecurity landscape before them. Organizations are grappling with shortages of cybersecurity skills and a lack of capability to detect and contain intrusions in a timely way. This comes against a backdrop of persistent ransomware attacks, the increasing regularity of supply chain vulnerabilities and a large attack surface due to sustained high levels of remote work. 

Although these are legitimate concerns, the battle is not lost. Effective managed cybersecurity services that include continuous threat hunting and rapid response can provide organizations with an immediate injection of world-class capability to detect, disrupt and contain serious hands-on-security threats at speed and at scale.

“Trusted” Entry Points Are No Match for Human Hunters

Many survey respondents (84%) predict that supply chain attacks could become one of the biggest cyber threats facing their organization. This boils down to a fear of an adversary gaining access through a trusted channel and going undetected. Sophisticated attacks of this nature require a mix of automation and human expertise in the form of human-based threat hunting. One of the strengths of threat hunting is that the ability to quickly and decisively detect a threat is not contingent on the initial access vector. Whether initial access is achieved via a supply chain attack, a vulnerable public-facing application or another trusted entry point, CrowdStrike Falcon OverWatch™ remains vigilant in hunting for post-exploitation behavior that signals an interactive threat on an endpoint.

OverWatch recently uncovered interactive intrusion activity that followed the unintended download of a suspected backdoored Zsh installation file. Zsh is a legitimate Unix shell and was likely downloaded by the victim organization from a legitimate GitHub repository.

Upon download and installation of Zsh, a binary for the remote access utility NetSupport was executed. Concurrently, the malicious installer also attempted to download additional binaries and batch files from an external domain. OverWatch tracked the adversary as they leveraged NetSupport to execute PowerShell commands to download a malicious DLL and batch file from an adversary command-and-control (C2) server and execute basic network reconnaissance commands. Later investigation found that the malicious DLL was modified to include VBScript that, if loaded, would have attempted to disable and add a number of folder exclusions to a third-party security tool. 

This attempted intrusion highlights how adversaries abuse user trust in legitimate download locations and exploit public edit settings on numerous GitHub repositories. Fortunately for this victim organization, OverWatch’s continuous hunting quickly spotted the anomalous activity based on threat hunting leads and known indicators of compromise (IOCs). Based on this rapid detection, OverWatch provided the necessary context to the victim organization enabling them to take swift remedial action.

Managed threat hunting delivers the human element that is crucial in detecting and disrupting adversary activity designed to exploit trusted components in a victim environment. Unlike solutions based exclusively on automated technology, human hunters approach their analysis with informed skepticism. OverWatch looks for behaviors that are indicative of a malicious presence in an environment. While the application or user activity involved with initial access might fall within parameters that technology considers normal, hunting looks at the broader context to detect even the faintest traces of malicious follow-on activity.

OverWatch and Falcon Complete Combine Forces to Stop Ransomware in Its Tracks

The 2021 survey also revealed that the persistent threat of ransomware attacks remains organizations’ most pressing cybersecurity concern, a concern that is firmly based in their lived experience. Two-thirds of the organizations surveyed had fallen victim to at least one ransomware attack in the preceding 12 months. This highlights how critical it is for organizations to have comprehensive security solutions in place that ensure that ransomware attempts are met with swift and decisive action. 

OverWatch and CrowdStrike Falcon Complete™ recently disrupted a ransomware attempt against a victim organization’s domain controller. An affiliate of the LockBit ransomware as a service (RaaS), run by BITWISE SPIDER, targeted the domain controller by exploiting the Zerologon vulnerability. The adversary connected to the domain controller remotely from a host on the network that did not have Falcon coverage. Thanks to the Falcon platform’s rich telemetry on covered workloads and OverWatch’s proactive threat hunting, the attack was immediately detected. Within minutes, OverWatch identified the adversary’s presence and began investigating. 

Having leveraged the exploit to obtain domain admin privileges, the adversary undertook initial discovery actions and created a new domain account to facilitate persistence and lateral movement. In under 20 minutes, the adversary used their new domain account to move laterally, via RDP, to another domain controller on the network, where they changed the “administrator” account’s password. By this time, OverWatch hunters were already in direct communication and coordination with Falcon Complete responders to begin stopping the attack.

Less than 10 minutes after the breakout, the adversary deployed and attempted to execute a novel binary. Further analysis performed by the CrowdStrike Intelligence team found the binary to be a variant of LockBit 2.0. Thanks to the Falcon platform’s prevention capabilities, the attempted LockBit execution was prevented, ensuring that this CrowdStrike customer did not become another one of BITWISE SPIDER’s many victims.

A Bit About LockBit
LockBit is developed by an adversary that CrowdStrike Intelligence tracks as BITWISE SPIDER, who provides their ransomware to affiliates in a RaaS model. BITWISE SPIDER has recently and quickly become a significant player in the big game hunting (BGH) landscape. Their dedicated leak site (DLS) has received the highest number of victims posted each month since July 2021 compared to other adversary DLSs due to the growing popularity and effectiveness of LockBit 2.0.

The Falcon platform is finely tuned to identify known malicious behaviors associated with ransomware. Despite the novel nature of the binary used in this attempted intrusion, the Falcon platform anticipated and immediately prevented the unknown threat from executing using a combination of artificial intelligence, behavioral detection and machine learning algorithms. 

Meanwhile, OverWatch tracked the adversary at every turn, providing context-rich information about the adversary’s movements to Falcon Complete, whose responders notified the customer and rapidly performed their response. Falcon Complete began by rapidly network containing the affected hosts, completely cutting off the adversary’s remote access. They also disabled the domain account created by the adversary and deployed a custom IOC hash block across the entire environment for the observed LockBit variant. To further assist the customer, Falcon Complete analysts delivered specific recommendations for further hardening of the network, including guidance, removing the adversary-created account, resetting the affected “administrator” account and fully patching the compromised domain controller. 

Thanks to the unrivaled security combination of the Falcon platform and the OverWatch, CrowdStrike Intelligence and Falcon Complete teams, the adversary was thwarted. This coordinated response effectively stopped the intrusion before the customer suffered any significant impact — protecting them against a serious eCrime threat that is growing all too prevalent. 

The findings from last year’s survey prove that it is a matter of when, not if, an organization will fall victim to an attempted ransomware attack. Yet, respondents’ self-reported estimated time to detect an intrusion has increased to an average of 146 hours, or over 6 days. Having expert managed services on your side makes the difference when minutes matter. The combination of OverWatch’s unrivaled ability to uncover adversary activity and Falcon Complete’s expert and timely response is proven to disrupt ransomware attempts before the adversary can do damage.

Managed Services Plug the Skills Gap

Amid these persistent threats, organizations report difficulty in finding staff with the skills needed to establish and maintain a comprehensive security posture. Managed services can deliver an immediate injection of security capability that can begin to pay dividends from Day One. In fact, OverWatch regularly uncovers pre-existing intrusions during roll-out to new customer environments.

CrowdStrike’s managed services provide benefits that cannot easily be replicated with an in-house solution. Because CrowdStrike analysts have access to cloud-scale telemetry encompassing trillions of events per day, they have unparalleled visibility across the entire customer install base. This allows hunters to rapidly identify anomalous activity, which ensures every customer benefits from near-real time insights into active threats. Both OverWatch and Falcon Complete are powered by CrowdStrike’s global threat intelligence, bringing critical context to the detection and response process. Crucially, all of this is delivered with 24/7/365 coverage, providing comprehensive security when it is most needed: ALWAYS.

Finally, a partnership with CrowdStrike’s managed services equips organizations with round-the-clock access to elite resources. OverWatch’s expert hunters deliver context-rich alerts that empower organizations to rapidly contain threats and remediate their environments with confidence. For organizations leveraging the power of Falcon Complete, expert responders will work in lock-step with OverWatch threat hunters to rapidly and surgically remediate malicious activity on an organization’s behalf.

Managed services can be your fast track to a comprehensive, mature endpoint security program that equips you to face the most pressing global security challenges into 2022 and beyond.

Additional Resources

Threat Source Newsletter (Jan. 20, 2022)

20 January 2022 at 19:00
Newsletter compiled by Jon Munshaw.Good afternoon, Talos readers.   Even though we're nearly a month into 2022, we're still not quite ready to move on from 2021. That's why next week, we'll be going live on social media to talk about some of the top cybersecurity stories from the past...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Looking Back at the Zero Day Initiative in 2021

20 January 2022 at 17:43

Now that we’re almost through the first month of 2022, it’s a good opportunity for us to take a look back at 2021 and the accomplishments of the Zero Day Initiative throughout the year. The past year was certainly a year full of its challenges, but we also celebrated some unique achievements in our busiest year ever. In addition to publishing the highest number of advisories in the history of the program, we hit our first million-dollar Pwn2Own in April. And as if that weren’t enough, we did it again in the fall as Pwn2Own Austin also exceeded the $1,000,000 threshold.

To say these were superlative events is an understatement. In the spring edition, we saw multiple Exchange exploits demonstrated, including ProxyShell. We saw 0-click remote code execution demonstrated on Zoom messenger and a 1-click code execution on Microsoft Teams. That’s on top of the Chrome, Edge, and Safari web browsers all getting compromised, too. The fall event had its own highlights, with the Samsung Galaxy, multiple routers, NAS devices, and printers being exploited. Watching a printer rock out some AC/DC after an exploit was just a bonus.

Of course, that should not detract from the great submissions we received throughout the year. We’ve already listed our Top 5 bugs from 2021, but that barely scratches the surface of the tremendous research disclosed to ZDI this past year. And while we are always impressed with the quality of research submitted to the program, ZDI’s own researchers stepped up this year and account for 31% of all published advisories. Still, we’re super thankful for our global community of independent researchers, and we congratulate the 25 researchers to achieve reward levels in 2021. We had six people reach Platinum status, two reach Gold, 4 Silver, and 13 Bronze. The work and submissions from our community of independent researchers are key to our success, and we thank all of them for their continued trust in our program.

Our program also wouldn’t work without vendors generating and releasing fixes for the vulnerabilities we report to them. The ZDI would not be able to sustain this level of advisories – and thus, better protections for Trend Micro customers – without the contributions of researchers and vendors, and we thank them for all they do.

Let’s take a look at some of the more interesting stats from 2021.

By the Numbers

In 2021, the ZDI has published 1,604 advisories – the most ever in the history of the program. This is the second year in a row where eclipsed our previous all-time total. While it’s unlikely we’ll keep up a record-breaking pace for the third year in a row, it does speak to the overall health of the program. Here’s how that number of advisories stacks up year-over-year.  

Figure 1 - Published Advisories Year-Over-Year

Coordinated disclosure of vulnerabilities continues to be a successful venture. While 2020 saw our largest percentage of 0-day disclosures, the number declined in 2021 to be in line with our “average” number of disclosures from previous years. The 137 0-day disclosures this past year represents 8.5% of our total disclosures – down from 18.6% the year before. This is a positive trend, and we hope it continues moving forward.

Figure 2 - 0-day Disclosures Since 2005

Here’s a breakdown of advisories by vendor. The top vendors here should not be surprising, although it is interesting to see Siemens in the top 5. We purchase quite a few ICS-related bugs throughout the year, and our Pwn2Own Miami competition focuses solely on ICS and SCADA-related bugs. In all, we disclosed 586 ICS-related bugs in 2021 – roughly 36.5% of the total number of advisories published by ZDI. As far as enterprise software goes, it’s no surprise at all to see Microsoft on top of the list again this year. In fact, 19.6% of all bugs addressed by Microsoft in 2021 came through the ZDI program, and we remain a significant source of bugs reported to Adobe, Apple, and others.

Figure 3 - Advisories per vendor for 2021

We’re always looking to acquire impactful bugs and, looking at the CVSS scores for the advisories we published in 2021, we did just that. A total of 74% of these vulnerabilities were rated Critical or High severity.

Figure 4 - CVSS 3.0 Scores for Published Advisories in 2021

Here’s how that compares year-over-year going back to 2015:

Figure 5 - CVSS Scores from 2015 through 2021

As you can see, after 2018 we made a conscious effort to ensure we were acquiring vulnerabilities that have the greatest impact on our customers. We’ll continue to do that in the coming year as well. We continually work with Trend Micro customers to determine which products they have deployed in their enterprise. That helps us shape our purchasing and research directions.

When it comes to the types of bugs we’re buying, here’s a look at the top 10 Common Weakness Enumerations (CWEs) from 2021:

Figure 6 - Top 10 CWEs from 2021 Published Advisories

It’s no surprise to see two CWEs related to out-of-bounds accesses at the top of the list, nor is it surprising to see this followed by use-after-free (UAF) bugs and heap-based buffer overflow issues. In fact, the top seven CWEs are all related to memory corruption somehow. A total of 72% of the advisories we published in 2021 were related to memory corruption bugs. Clearly, we as an industry still have work to do in this area.

Looking Ahead

Moving into the new year, we anticipate staying just as busy. We currently have more than 600 bugs reported to vendors awaiting disclosure. We have Pwn2Own Miami and Pwn2Own Vancouver just on the horizon – and both will (fingers crossed) have participation on location. This year will be the 15th anniversary of Pwn2Own in Vancouver, and we’re planning some very special treats as a way to celebrate. Don’t worry if you can’t come to the contest themselves, as we’ll be streaming the events on YouTube and Twitch as they occur. If you ever wanted to attend Pwn2Own but couldn’t, you have a chance to watch them online.

In the coming year, we’re also looking to expand our program by acquiring bugs with an even bigger impact on our customers and the global community. Expect to see us purchasing more bugs in cloud-native applications, the Linux operating system, and anything else that poses a significant threat to our customer’s networks and resources. We look forward to refining our outreach and acquisition efforts by further aligning with the risks our customers are facing to ensure the bugs we squash have the biggest impact on our customers and the broader ecosystem.

In other words, 2022 is shaping up to be another exciting year with impactful research, great contests, and real information you can use. We hope you come along for the ride. Until then, be well, stay tuned to this blog, subscribe to our YouTube channel, and follow us on Twitter for the latest updates from the ZDI. 

Looking Back at the Zero Day Initiative in 2021

Mind the MPLog: Leveraging Microsoft Protection Logging for Forensic Investigations

20 January 2022 at 08:41

In an incident response investigation, CrowdStrike analysts use multiple data points to parse the facts of who, what, when and how. As part of that fact-finding mission, analysts investigating Windows systems leverage the Microsoft Protection Log (MPLog), a forensic artifact on Windows operating systems that offers a wealth of data to support forensic investigations. MPLog has proven to be beneficial in identifying process execution and file access on systems.  

To aid investigators everywhere, this blog post provides an overview of the MPLog files, offers examples of the data contained within and walks through a case study of RClone, a data exfiltration tool used by eCrime actors during ransomware attacks

What Is the MPLog?

The Microsoft Protection Log, or MPLog, is a plain-text log file generated by Windows Defender or Microsoft Security Essentials for troubleshooting purposes. This log can contain historical evidence of the following:

  • Process execution
  • Threats detected
  • Scan results and actions taken
  • Signature update versions
  • File existence

Where to Find the MPLogs

MPLog files are stored under the directory C:\ProgramData\Microsoft\Windows Defender\Support. In this directory you will find the file MPLog-*. The screenshot in Figure 1 provides an example of sample content.

Figure 1. Example MPLog location

Interpreting MPLog Data

There are several different event types present in this log file. Some examples are listed below.

Note: Log formatting for each event has changed over time, so depending on when the event was written, you may have more or fewer fields than explained below.

Estimated Impact Events

Estimated impact events are generated to log the estimated performance impact information of running software as part of Windows Defender. These events can show evidence of execution, file access and count of file access. Microsoft documentation on these events can be found here.

Example: 2020-06-14T20:11:42.880Z ProcessImageName: explorer.exe, TotalTime: 30, Count: 11, MaxTime: 15, MaxTimeFile: \Device\HarddiskVolume1\Users\Public\Desktop\PuTTY (64-bit).lnk->[CMDEmbedded], EstimatedImpact: 9%

Field Name Description Data
N/A Event time generated in UTC 2020-06-14T20:11:42.880Z
ProcessImageName Process image name explorer.exe
TotalTime The cumulative duration in milliseconds spent in scans of files accessed by this process 30
Count The number of scanned files accessed by this process 11
MaxTime The duration in milliseconds in the longest single scan of a file accessed by this process 15
MaxTimeFile The path of the file accessed by this process for which the longest scan of MaxTime duration was recorded \Device\HarddiskVolume1\Users\Public\Desktop\PuTTY (64-bit).lnk
EstimatedImpact The percentage of time spent in scans for files accessed by this process out of the period in which this process experienced scan activity 9%

Table 1: Estimated Impact Events

SDN Events

As part of Windows Defender’s cloud protection service, SDN events can show evidence of file existence on disk along with sha1 and sha2 hashes for the identified file. The following is an example of an SDN event:

Field Name Description Data
N/A File full path and name C:\ProgramData\badfile.exe
Sha1 SHA1 hash of file 876d0908145c822c06060413ecacc1baca97892c
Sha2 SHA256 hash of file 121b6ad75b3ead2a09e8bf6959423f6ce91239e0c062060aa948bb379f906534

Table 2. SDN events

Detection Events

These events can show evidence of file execution, process information and the Windows Defender street name for detection. 


  • 2021-07-22T15:38:04.557Z DETECTION_ADD Ransom:Win32/Conti.ZA file:C:\ProgramData\badfile.exe
  • 2021-07-22T15:38:04.557Z DETECTION_ADD Ransom:Win32/Conti.ZA process:pid:100128,ProcessStart:132696072639875080
Field Name Description Data
N/A Event time generated in UTC 2021-07-22T15:38:04.557Z
N/A AV street name Win32/Conti.ZA
PID Process ID 100128
ProcessStart Process start time (WebKit/Chrome Timestamp) 132696072639875080
File File full path and name C:\ProgramData\badfile.exe

Table 3. Detection events

EMS Detection Events

As part of Windows Defender’s memory scanning engine, EMS detection events can show evidence of process injection.


  • Engine:EMS scan for process: explorer pid: 6108, sigseq: 0x0, sendMemoryScanReport: 0, source: 1
  • Engine:EMS detection: HackTool:Win64/CobaltStrike.A!!CobaltStrike.A64, sigseq=0x0000C0C53E1F0B73, pid=6108
Field Name Description Data
N/A Process name explorer.exe
N/A AV street name HackTool:Win64/CobaltStrike.A!!CobaltStrike.A64
PID Process ID 6108

Table 4. EMS detection events

Rclone Case Study

In a recent ransomware incident, CrowdStrike leveraged MPLog data to gain more insight into the use of the file transfer utility Rclone, used by the threat actor for data exfiltration. MPLog data was used to identify which files the threat actor was targeting and the potential number of files exfiltrated. 

Like many ransomware incidents today, CrowdStrike identified evidence of potential data exfiltration prior to execution of the ransomware. This was evident from the presence of the Rclone utility and evidence of execution found on an encrypted system. Unfortunately, there was no telemetry from the system to say what the exact Rclone command parameters were. For those unfamiliar with Rclone, a typical command is as follows:

As seen in the sample command, the data targeted for exfiltration can be identified in the path information. Using a simple string search for the term “rclone.exe” CrowdStrike discovered the following hits in the MPLog file:

Combined with what we know about the Estimated Impact Events from Microsoft’s documentation, we can make several statements from this data: 

  1. rclone.exe executed with Pid 5244
  2. rclone.exe accessed 32,873 files 
    1. Windows Defender scanned 32,873 files that rclone.exe accessed
  3. rclone.exe accessed the file \Device\Mup\fileserver\VOL1\PRIVATE\HR\PAYROLL\<redacted>.exe 
    1. This is a file that Windows Defender took the longest time to scan that rclone.exe accessed


Additional research is needed to fully understand the details and additional potential  investigative value of the MPLog, but initial analysis and research show that this data can be valuable for assisting in forensic investigations to identify process execution and file access on systems. Especially in cases where anti-forensic measures are taken or other artifacts on disk become impacted, MPLog can help investigators pick up the pieces and tell the full story.

Additional Resources

CrowdStrike Powers MXDR by Deloitte, Offering Customers Risk Mitigation with Powerful Customized and Managed Security Services

20 January 2022 at 07:01

Deloitte, a leader in managed security services, has launched MXDR by Deloitte — a Managed Extended Detection and Response suite of offerings — within which the CrowdStrike Falcon® platform will power a number of solutions.

MXDR by Deloitte combines an integrated, composable and modular managed detection and response SaaS platform with managed security services in a unified offering of advanced, military-grade threat hunting, detection, response and remediation capabilities.

The CrowdStrike Falcon platform is one of the world’s most advanced cloud-native platforms for protecting critical areas of enterprise risk, including endpoints, cloud workloads, identity and data. The CrowdStrike Falcon platform provides highly standardized, cloud-delivered, effective and easy to use SaaS solutions.

“Many of our clients have dozens — if not hundreds — of security tools in their arsenals, which can be a challenge to manage. We developed MXDR by Deloitte to help organizations consolidate into one managed services and solutions suite to help improve ease, efficiency and effectiveness in cyber program management,” said Curt Aubley, MXDR by Deloitte leader and a Deloitte Risk & Financial Advisory managing director, Deloitte & Touche LLP. “We asked CrowdStrike to be part of our MXDR offering due to their technological capabilities and open API platform — both of which enable integration into our MXDR platform and scalability that Deloitte clients demand.”

Enhance Visibility, Improve Incident Response and Lower Operational Costs

Working together, CrowdStrike’s solutions and Deloitte’s advisory services are designed to help organizations identify security gaps, prioritize risk-mitigation initiatives and help improve their risk posture. In particular, CrowdStrike technologies in MXDR by Deloitte will focus on helping clients:

  1. Increase real-time multi-platform visibility for enterprise assets across on-premises, cloud and container workloads — including the capabilities to research common vulnerabilities and exposures (CVEs), examine threat actor profiles and targets, understand all applications running in their environment, and search to see versions, hosts and users that may pose a risk
  2. Improve mean time to prevent, detect, respond and mitigate vulnerabilities in security assets and related cyberattacks
  3. Reduce business costs through proactive identification and improved response efforts to unknown cyberattacks with additional benefits of consolidation, lowered complexity and total cost of ownership

With its newly expanded MXDR suite, Deloitte has positioned the CrowdStrike Falcon platform as a core enabling technology for multiple services in the MXDR suite and is adopting multiple CrowdStrike modules to power the services.  

Current MXDR by Deloitte service offerings leveraging CrowdStrike include: 

  • Cloud Security: Prevention, Detection and Response powered by Falcon Cloud Workload protection (CWP), Falcon Horizon™ cloud security posture management and Falcon Discover™ network security monitoring
  • Enterprise Prevention, Detection and Response powered by the CrowdStrike Falcon platform
  • Zero Trust: Identity Prevention, Detection and Response powered by Falcon Identity Threat Protection and Falcon Zero Trust
  • Insider Threat Detection powered by Falcon Identity Threat Protection
  • Adversary Pursuit: Proactive Hunting powered by Falcon OverWatch™ managed threat hunting
  • Attack Surface Management (ASM) and Vulnerability Management (VM) powered by Falcon Spotlight™ scanless vulnerability and Falcon Discover network security monitoring
  • Incident Response (IR): Contain and Recover powered by the CrowdStrike Falcon platform
  • Master Operator and Hunt Training powered by Falcon Insight™ endpoint detection and response and Falcon Prevent™ next-gen antivirus

In addition to CrowdStrike, Deloitte is also leveraging complementary strategic alliances with  Amazon Web Services (AWS), Google, Zscaler, Splunk, ServiceNow and Exabeam to operationalize its MXDR suite. CrowdStrike already has robust technical integrations across the other alliances involved, bringing multi-layered defense solutions to CrowdStrike customers. CrowdStrike is also currently the only EDR vendor included in the MXDR by Deloitte program.

“Organizations are still dealing with breaches day in and day out. This alliance helps enterprises better identify, prevent and respond to cyber threats by providing risk insights and protection to help enable better business decision making, from the security operations center to the boardroom,” states Matthew Polly, VP of WW Alliances, Channels and Business Development at CrowdStrike. “These new MXDR services from Deloitte offer customers best-of-breed holistic security risk and threat management, incident response and threat intelligence services to help organizations prevent, detect and mitigate potential cyberattacks.” 

Better Together: CrowdStrike and Deloitte

CrowdStrike and Deloitte are both dedicated to delivering best-in-class security solutions for our customers globally. This strategic alliance will further enable organizations to deploy powerful solutions to combat adversaries and ultimately help stop breaches.  

Learn more about CrowdStrike’s Falcon platform here.

Additional Resources

LiveAction LiveNX AWS Credential Disclosure Vulnerability

19 January 2022 at 20:56


Several versions of LiveAction LiveNX network monitoring software contain Amazon Web Services (AWS) credentials. These credentials have privileged access to the LiveAction AWS infrastructure. A remote attacker may abuse these credentials to gain access to LiveAction internal resources.

Vulnerability Identifiers

  • Exodus Intelligence: EIP-7d4ec9e3

Vulnerability Metrics

  • CVSSv2 Score: 10

Vendor References

  • This vulnerability has been address in LiveAction LiveNX version 21.4.0

Discovery Credit

  • Exodus Intelligence

Disclosure Timeline

  • Disclosed to affected vendor: July 1st, 2021
  • Disclosed to public: January 19th, 2022

Further Information

Readers of this advisory who are interested in receiving further details around the vulnerability, mitigations, detection guidance, and more can contact us at [email protected].

Researchers who are interested in monetizing their 0Day and NDay can work with us through our Research Sponsorship Program.

The post LiveAction LiveNX AWS Credential Disclosure Vulnerability appeared first on Exodus Intelligence.

Technical Analysis of the WhisperGate Malicious Bootloader

19 January 2022 at 17:37

On Jan. 15, 2022, a set of malware dubbed WhisperGate was reported to have been deployed against Ukrainian targets. The incident is widely reported to contain three individual components deployed by the same adversary, including a malicious bootloader that corrupts detected local disks, a Discord-based downloader and a file wiper. The activity occurred at approximately the same time multiple websites belonging to the Ukrainian government were defaced.

This blog covers the malicious bootloader in more detail. 


The installer component for the bootloader has an SHA256 hash of


and contains a build timestamp of 2022-01-10 10:37:18 UTC. It was built using MinGW, similar to the file-wiper component. This component overwrites the master boot record (MBR) of an infected host with a malicious 16-bit bootloader with a SHA256 hash of


that displays a ransom note when the host boots (Figure 1) and, at the same time, performs destructive operations on the infected host’s hard drives.

Figure 1. Fake ransom note

The destructive wiping operation has the following pseudocode:

for i_disk between 0 and total_detected_disk_count do
   for i_sector between 1 and total_disk_sector_count, i_sector += 199, do
      overwrite disk i_disk at sector i_sector with hardcoded data

At periodic offsets, the bootloader overwrites sectors of an infected host’s entire hard drive, with a message similar to the ransom note, padded with additional bytes (Figure 2).

Figure 2. Hexadecimal dump of the pattern written to the disks of an infected host

The data consists of the string AAAAA, the index of the infected drive, the ransom note and the MBR footer magic value 55 AA, followed by two null bytes.

The bootloader accesses the disk via BIOS interrupt 13h in logical block addressing (LBA) mode and overwrites every 199th sector until the end of the disk is reached. After a disk is corrupted, the malware overwrites the next in the detected disk list. 

This process is unsophisticated but reminiscent of the more evolved implementation of NotPetya’s malicious MBR that masqueraded as the legitimate chkdsk disk-repair utility while actually corrupting the infected host’s file system.

The bootloader installer does not initiate a reboot of the infected system, as has been observed in past intrusions such as BadRabbit and NotPetya. The lack of forced reboot suggests the threat actor took other steps to initiate it (e.g., via a different implant) or decided to let users perform the reboot themselves. A delayed reboot may allow other components of the WhisperGate intrusion to run (e.g., the file wiper).


The WhisperGate bootloader malware complements its file-wiper counterpart. Both aim to irrevocably corrupt the infected hosts’ data and attempt to masquerade as genuine modern ransomware operations. However, the WhisperGate bootloader has no decryption or data-recovery mechanism, and has inconsistencies with malware commonly deployed in ransomware operations. 

The displayed message suggests victims can expect recovery of their data, but this is technically unachievable. These inconsistencies very likely indicate that WhisperGate activity aims to destroy data on the impacted assets. This assessment is made with moderate confidence as technical analysis of the WhisperGate activity continues.

The activity is reminiscent of VOODOO BEAR’s destructive NotPetya malware, which included a component impersonating the legitimate chkdsk utility after a reboot and corrupted the infected host’s Master File Table (MFT) — a critical component of Microsoft’s NTFS file system. However, the WhisperGate bootloader is less sophisticated, and no technical overlap could currently be identified with VOODOO BEAR operations.

CrowdStrike Intelligence Confidence Assessment 

High Confidence: Judgments are based on high-quality information from multiple sources. High confidence in the quality and quantity of source information supporting a judgment does not imply that that assessment is an absolute certainty or fact. The judgment still has a marginal probability of being inaccurate.

Moderate Confidence: Judgments are based on information that is credibly sourced and plausible, but not of sufficient quantity or corroborated sufficiently to warrant a higher level of confidence. This level of confidence is used to express that judgments carry an increased probability of being incorrect until more information is available or corroborated.

Low Confidence: Judgments are made where the credibility of the source is uncertain, the information is too fragmented or poorly corroborated enough to make solid analytic inferences, or the reliability of the source is untested. Further information is needed for corroboration of the information or to fill known intelligence gaps.

Additional Resources

CVE-2022-21661: Exposing Database Info via WordPress SQL Injection

18 January 2022 at 18:15

In October of this year, we received a report from ngocnb and khuyenn from GiaoHangTietKiem JSC covering a SQL injection vulnerability in WordPress. The bug could allow an attacker to expose data stored in a connected database. This vulnerability was recently addressed as CVE-2022-21661 (ZDI-22-220). This blog covers the root cause of the bug and looks at how the WordPress team chose to address it. First, here’s a quick video demonstrating the vulnerability:

The Vulnerability

The vulnerability occurs in the WordPress Query (WP_Query) class. The WP_Query object is used to perform custom queries to the WordPress database. This object is used by plugins and themes to create their custom display of posts. 

The vulnerability occurs when a plugin uses the vulnerable class. One such plugin is Elementor Custom Skin. For this post, we tested the vulnerability against WordPress version 5.8.1 and Elementor Custom Skin plugin version 3.1.3.

In this plugin, the vulnerable WP_Query class is utilized in the get_document_data method of ajax-pagination.php:

Figure 1- - wordpress/wp-content/plugins/ele-custom-skin/includes/ajax-pagination.php

The get_document_data method is invoked when a request is sent to wp-admin/admin-ajax.php and the action parameter is ecsload.  

Figure 2 - wordpress/wp-admin/admin-ajax.php

The admin-ajax.php page checks whether the request was made by an authenticated user. If the request came from a non-authenticated user, admin-ajax.php calls a non-authenticated Ajax action. Here, the request is sent without authentication so that the non-authenticated Ajax action is called, which is wp_ajax_nopriv_ecsload.

Searching for the string “wp_ajax_nopriv_ecsload” shows that it is a hook name present in the ajax-pagination.php page:

Figure 3 - wordpress/wp-content/plugins/ele-custom-skin/includes/ajax-pagination.php

The wp_ajax_nopriv_ecsload hook name refers to the get_document_data callback function. This means that the do_action method calls the get_document_data method.

The get_document_data method creates a WP_Query object. The initialization of the WP_Query object calls the following get_posts method:

Figure 4 - wordpress/wp-includes/class-wp-query.php

The get_posts method first parses the user-supplied parameters. Next, it calls the get_sql method which eventually calls get_sql_for_clause to create clauses of the SQL statement from the user-supplied data. get_sql_for_clause calls clean_query to validate the user-supplied string. However, the method fails to validate the terms parameter if the taxonomy parameter is empty and the value of the field parameter is the string “term_taxonomy_id”. The value of the terms parameter is later used in the SQL statement.

Figure 5 - wordpress/wp-includes/class-wp-tax-query.php

Note that the sql variable returned by get_sql() is appended to an SQL SELECT statement and assembled using strings returned from the WP_Tax_Query->get_sql() method. Later, in the get_posts method, this query is executed by $wpdb->get_col() method, where an SQL injection condition occurs.

This vulnerability can be exploited to read the WordPress database:

Figure 6 - PoC output

The Patch

The patch to address CVE-2022-21661 adds some additional checks to the terms parameter to help prevent further SQL injections from occurring.

Figure 7 - The clean_query method of wordpress/wp-includes/class-wp-tax-query.php


Active attacks on WordPress sites often focus on optional plugins rather than the core of WordPress itself. That was the case earlier this year when a bug in the Fancy Product Designer plugin was reported as being under active attack. Similarly, a file upload vulnerability in the Contact Form 7 plugin was also detected as being exploited by Trend Micro sensors. In this case, the bug is exposed through plugins, but exists within WordPress itself. While this is a matter of information disclosure rather than code execution, the data exposed could prove valuable for attackers. It would not surprise us to see this bug in active attacks in the near future. We recommend applying the patch or taking other remedial action as soon as possible. Special thanks to ngocnb and khuyenn from GiaoHangTietKiem JSC for reporting this to the ZDI. You can read their analysis of the bug here.

CVE-2022-21661: Exposing Database Info via WordPress SQL Injection

BlackCat Ransomware | Highly-Configurable, Rust-Driven RaaS On The Prowl For Victims

18 January 2022 at 17:40

BlackCat (aka AlphaVM, AlphaV) is a newly established RaaS (Ransomware as a Service) with payloads written in Rust. While BlackCat is not the first ransomware written in the Rust language, it joins a small (yet growing) sliver of the malware landscape making use of this popular cross-platform language.

First appearing in late November, BlackCat has reportedly been attacking targets in multiple countries, including Australia, India and the U.S, and demanding ransoms in the region of $400,000 to $3,000,000 in Bitcoin or Monero.

BlackCat Ransomware Overview

In order to attract affiliates, the authors behind BlackCat have been heavily marketing their services in well-known underground forums.

BlackCat operators maintain a victim blog as is standard these days. The blog hosts company names and any data leaked in the event that the victims do not agree to cooperate.

Current data indicates primary delivery of BlackCat is via 3rd party framework/toolset (e.g., Cobalt Strike) or via exposed (and vulnerable) applications. BlackCat currently supports both Windows and Linux operating systems.

BlackCat Configuration Options

Samples analyzed (to date ) require an “access token” to be supplied as a parameter upon execution. This is similar to threats like Egregor, and is often used as an anti-analysis tactic. This ‘feature’ exists in both the Windows and Linux versions of BlackCat.

However, the BlackCat samples we analyzed could be launched with any string supplied as the access token. For example:

Malware.exe -v --access-token 12345

The ransomware supports a visible command set, which can be obtained via the -h or --help parameters.

BlackCat command line options

As seen above, the executable payloads support a variety of commands, many of which are VMware-centric.

 --no-prop                                  Do not self propagate(worm) on Windows
 --no-prop-servers <NO_PROP_SERVERS>        Do not propagate to defined servers
 --no-vm-kill                               Do not stop VMs on ESXi
 --no-vm-snapshot-kill                      Do not wipe VMs snapshots on ESXi
 --no-wall                                  Do not update desktop wallpaper on Windows

In verbose mode (-v) the following output can be observed upon launch of the BlackCat payloads:

BlackCat ransomware run in verbose mode

BlackCat Execution and Encryption Behaviour

Immediately upon launch, the malware will attempt to validate the existence of the previously mentioned access-token, followed by querying for the system UUID (wmic).

Those pieces of data are concatenated together into what becomes the ‘Access key’ portion of their recovery URL displayed in the ransom note. In addition, on Windows devices, BlackCat attempts to delete VSS (Volume Shadow Copies) as well as enumerate any accessible drives to search for and encrypt eligible files.

Other configuration parameters are evaluated before proceeding to execute multiple privilege escalation methods, based on the OS identified by wmic earlier. These methods are visible at the time of execution and include the use of the Com Elevation Moniker.

It is at this point that BlackCat will attempt to terminate any processes or services listed within the configuration such as any processes which may inhibit the encryption process. There are also specific files and directories that are excluded from encryption. Much of this is configurable at the time of building the ransomware payloads.

The targeted processes and services are noted in the kill_processes and kill_services sections respectively. File and folder exclusions are handled in the exclude directory_names section.

To further illustrate, the following were extracted from sample ​d65a131fb2bd6d80d69fe7415dc1d1fd89290394/​74464797c5d2df81db2e06f86497b2127fda6766956f1b67b0dcea9570d8b683:


backup memtas mepocs msexchange
sql svc$ veeam vss


agntsvc dbeng50 dbsnmp encsvc
excel firefox infopath isqlplussvc
msaccess mspub mydesktopqos mydesktopservice
notepad ocautoupds ocomm ocssd
onenote oracle outlook powerpnt
sqbcoreservice sql steam synctime
tbirdconfig thebat thunderbird visio
winword wordpad xfssvccon


$recycle.bin $windows.~bt $windows.~ws 386
adv all users ani appdata
application data autorun.inf bat bin
boot boot.ini bootfont.bin bootsect.bak
cab cmd com config.msi
cpl cur default deskthemepack
diagcab diagcfg diagpkg dll
drv exclude_file_extensions:[themepack exclude_file_names:[desktop.ini exe
google hlp hta icl
icns ico iconcache.db ics
idx intel key ldf
lnk lock mod mozilla
mpa msc msi msocache
msp msstyles msu] nls
nomedia ntldr ntuser.dat ntuser.dat.log]
ntuser.ini ocx pdb perflogs
prf program files program files (x86) programdata
ps1 public rom rtp
scr shs spl sys
system volume information theme thumbs.db tor browser
windows windows.old] wpx

BlackCat also spawns a number of its own processes, with syntax (for Windows) as follows:

 WMIC.exe (CLI interpreter)   csproduct get UUID
 cmd.exe (CLI interpreter)   /c "reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt /d 65535 /t REG_DWORD /f"
 cmd.exe (CLI interpreter)   /c "wmic csproduct get UUID"
 cmd.exe (fsutil.exe)        /c "fsutil behavior set SymlinkEvaluation R2L:1"
 fsutil.exe                  behavior set SymlinkEvaluation R2L:1
 cmd.exe (fsutil.exe)        /c "fsutil behavior set SymlinkEvaluation R2R:1"

The fsutil-based modifications are meant to allow for use of both remote and local symlinks. BlackCat enables ‘remote to local’ and ‘remote to remote’ capability.

 fsutil.exe                     behavior set SymlinkEvaluation R2R:1
 cmd.exe (vssadmin.exe)         /c "vssadmin.exe delete shadows /all /quiet"
 reg.exe (CLI interpreter)      add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt /d 65535 /t REG_DWORD /f

 cmd.exe (worldwideStrata.exe)  /c "C:\Users\admin1\Desktop\worldwideStrata.exe" --child
 vssadmin.exe                   delete shadows /all /quietcmd.exe (ARP.EXE) /c "arp -a"

Some more recently-built copies have a few additions. For example, in sample c1187fe0eaddee995773d6c66bcb558536e9b62c/c3e5d4e62ae4eca2bfca22f8f3c8cbec12757f78107e91e85404611548e06e40 we see the addition of:

 wmic.exe Shadowcopy Delete"
 "iisreset.exe /stop"
 bcdedit.exe /set {default} recoveryenabled No

Much like other fine details, all this can be adjusted or configured by the affiliates at the time of building the payloads.

BlackCat configurations are not necessarily tailored to the target operating system. In the Linux variants we have analyzed to date, there are Windows-specific process, service, and file references in the kill_processes, kill_services, and exclude_directory_names.

The following excerpt is from sample f8c08d00ff6e8c6adb1a93cd133b19302d0b651afd73ccb54e3b6ac6c60d99c6.

Linux variant configuration

Specific encryption logic is not necessarily novel either and is somewhat configurable by the affiliate at the time of building the ransomware payloads. BlackCat supports both ChaCha20 and AES encryption schemes.

Extensions on encrypted files can vary across samples. Examples observed include .dkrpx75, .kh1ftzx and .wpzlbji.

BlackCat ransomware execution chain (Windows version)

Post-Infection, Payment and Portal

Infected clients will be greeted with a ransom note as well as a modified desktop image.

BlackCat’s modified desktop image

Infected uses are instructed to connect to the attackers’ payment portal via TOR.

BlackCat ransom note

The ransom note informs the victim that not only have files been encrypted but data has been stolen.

Victim’s are threatened with data leakage if they refuse to pay and provided with a list of data types that have been stolen.

In theory, once victims connect to the attacker’s portal, they are able to communicate and potentially acquire a decryption tool. Everything on the BlackCat portal is tied back to the specific target ID, which must be supplied correctly from the URL in the ransom note.


In its relatively short time on the radar, BlackCat has carved a notable place for itself amongst mid-tier ransomware actors. This group knows their craft and are cautious when selecting partners or affiliates. It is possible that some of the increased affiliation and activity around BlackCat is attributed to other actors migrating to BlackCat as larger platforms fizzle out (Ryuk, Conti, LockBit and REvil).

Actors utilizing BlackCat know their targets well and make every attempt to stealthily compromise enterprises. Prevention by way of powerful, modern, endpoint security controls are a must. The SentinelOne Singularity Platform is capable of detecting and preventing BlackCat infections on both Windows and Linux endpoints.

Indicators of Compromise



T1027.002 – Obfuscated Files or Information: Software Packing
T1027 – Obfuscated Files or Information
T1007 – System Service Discovery
T1059 – Command and Scripting Interpreter
TA0010 – Exfiltration
T1082 – System Information Discovery
T1490 – Inhibit System Recovery
T1485 – Data Destruction
T1078 – Valid Accounts
T1486 – Data Encrypted For Impact
T1140 – Encode/Decode Files or Information
T1202 – Indirect Command Execution
T1543.003 – Create or Modify System Process: Windows Service
T1550.002 – Use Alternate Authentication Material: Pass the Hash

Zooming in on Zero-click Exploits

18 January 2022 at 17:28
By: Ryan

Posted by Natalie Silvanovich, Project Zero

Zoom is a video conferencing platform that has gained popularity throughout the pandemic. Unlike other video conferencing systems that I have investigated, where one user initiates a call that other users must immediately accept or reject, Zoom calls are typically scheduled in advance and joined via an email invitation. In the past, I hadn’t prioritized reviewing Zoom because I believed that any attack against a Zoom client would require multiple clicks from a user. However, a zero-click attack against the Windows Zoom client was recently revealed at Pwn2Own, showing that it does indeed have a fully remote attack surface. The following post details my investigation into Zoom.

This analysis resulted in two vulnerabilities being reported to Zoom. One was a buffer overflow that affected both Zoom clients and MMR servers, and one was an info leak that is only useful to attackers on MMR servers. Both of these vulnerabilities were fixed on November 24, 2021.

Zoom Attack Surface Overview

Zoom’s main feature is multi-user conference calls called meetings that support a variety of features including audio, video, screen sharing and in-call text messages. There are several ways that users can join Zoom meetings. To start, Zoom provides full-featured installable clients for many platforms, including Windows, Mac, Linux, Android and iPhone. Users can also join Zoom meetings using a browser link, but they are able to use fewer features of Zoom. Finally, users can join a meeting by dialing phone numbers provided in the invitation on a touch-tone phone, but this only allows access to the audio stream of a meeting. This research focused on the Zoom client software, as the other methods of joining calls use existing device features.

Zoom clients support several communication features other than meetings that are available to a user’s Zoom Contacts. A Zoom Contact is a user that another user has added as a contact using the Zoom user interface. Both users must consent before they become Zoom Contacts. Afterwards, the users can send text messages to one another outside of meetings and start channels for persistent group conversations. Also, if either user hosts a meeting, they can invite the other user in a manner that is similar to a phone call: the other user is immediately notified and they can join the meeting with a single click. These features represent the zero-click attack surface of Zoom. Note that this attack surface is only available to attackers that have convinced their target to accept them as a contact. Likewise, meetings are part of the one-click attack surface only for Zoom Contacts, as other users need to click several times to enter a meeting.

That said, it’s likely not that difficult for a dedicated attacker to convince a target to join a Zoom call even if it takes multiple clicks, and the way some organizations use Zoom presents interesting attack scenarios. For example, many groups host public Zoom meetings, and Zoom supports a paid Webinar feature where large groups of unknown attendees can join a one-way video conference. It could be possible for an attacker to join a public meeting and target other attendees. Zoom also relies on a server to transmit audio and video streams, and end-to-end encryption is off by default. It could be possible for an attacker to compromise Zoom’s servers and gain access to meeting data.

Zoom Messages

I started out by looking at the zero-click attack surface of Zoom. Loading the Linux client into IDA, it appeared that a great deal of its server communication occurred over XMPP. Based on strings in the binary, it was clear that XMPP parsing was performed using a library called gloox. I fuzzed this library using AFL and other coverage-guided fuzzers, but did not find any vulnerabilities. I then looked at how Zoom uses the data provided over XMPP.

XMPP traffic seemed to be sent over SSL, so I located the SSL_write function in the binary based on log strings, and hooked it using Frida. The output contained many XMPP stanzas (messages) as well as other network traffic, which I analyzed to determine how XMPP is used by Zoom. XMPP is used for most communication between Zoom clients outside of meetings, such as messages and channels, and is also used for signaling (call set-up) when a Zoom Contact invites another Zoom Contact to a meeting.

I spent some time going through the client binary trying to determine how the client processes XMPP, for example, if a stanza contains a text message, how is that message extracted and displayed in the client. Even though the Zoom client contains many log strings, this was challenging, and I eventually asked my teammate Ned Williamson for help locating symbols for the client. He discovered that several old versions of the Android Zoom SDK contained symbols. While these versions are roughly five years old, and do not present a complete view of the client as they only include some libraries that it uses, they were immensely helpful in understanding how Zoom uses XMPP.

Application-defined tags can be added to gloox’s XMPP parser by extending the class StanzaExtension and implementing the method newInstance to define how the tag is converted into a C++ object. Parsed XMPP stanzas are then processed using the MessageHandler class. Application developers extend this class, implementing the method handleMessage with code that performs application functionality based on the contents of the stanza received. Zoom implements its XMPP handling in CXmppIMSession::handleMessage, which is a large function that is an entrypoint to most messaging and calling features. The final processing stage of many XMPP tags is in the class ns_zoom_messager::CZoomMMXmppWrapper, which contains many methods starting with ‘On’ that handle specific events. I spent a fair amount of time analyzing these code paths, but didn’t find any bugs. Interestingly, Thijs Alkemade and Daan Keuper released a write-up of their Pwn2Own bug after I completed this research, and it involved a vulnerability in this area.

RTP Processing

Afterwards, I investigated how Zoom clients process audio and video content. Like all other video conferencing systems that I have analyzed, it uses Real-time Transport Protocol (RTP) to transport this data. Based on log strings included in the Linux client binary, Zoom appears to use a branch of WebRTC for audio. Since I have looked at this library a great deal in previous posts, I did not investigate it further. For video, Zoom implements its own RTP processing and uses a custom underlying codec named Zealot (libzlt).

Analyzing the Linux client in IDA, I found what I believed to be the video RTP entrypoint, and fuzzed it using afl-qemu. This resulted in several crashes, mostly in RTP extension processing. I tried modifying the RTP sent by a client to reproduce these bugs, but it was not received by the device on the other side and I suspected the server was filtering it. I tried to get around this by enabling end-to-end encryption, but Zoom does not encrypt RTP headers, only the contents of RTP packets (as is typical of most RTP implementations).

Curious about how Zoom server filtering works, I decided to set up Zoom On-Premises Deployment. This is a Zoom product that allows customers to set up on-site servers to process their organization’s Zoom calls. This required a fair amount of configuration, and I ended up reaching out to the Zoom Security Team for assistance. They helped me get it working, and I greatly appreciate their contribution to this research.

Zoom On-Premises Deployments consist of two hosts: the controller and the Multimedia Router (MMR). Analyzing the traffic to each server, it became clear that the MMR is the host that transmits audio and video content between Zoom clients. Loading the code for the MMR process into IDA, I located where RTP is processed, and it indeed parses the extensions as a part of its forwarding logic and verifies them correctly, dropping any RTP packets that are malformed.

The code that processes RTP on the MMR appeared different than the code that I fuzzed on the device, so I set up fuzzing on the server code as well. This was challenging, as the code was in the MMR binary, which was not compiled as a relocatable binary (more on this later). This meant that I couldn’t load it as a library and call into specific offsets in the binary as I usually do to fuzz binaries that don’t have source code available. Instead, I compiled my own fuzzing stub that called the function I wanted to fuzz as a relocatable that defined fopen, and loaded it using LD_PRELOAD when executing the MMR binary. Then my code would take control of execution the first time that the MMR binary called fopen, and was able to call the function being fuzzed.

This approach has a lot of downsides, the biggest being that the fuzzing stub can’t accept command line parameters, execution is fairly slow and a lot of fuzzing tools don’t honor LD_PRELOAD on the target. That said, I was able to fuzz with code coverage using Mateusz Jurczyk’s excellent DrSanCov, with no results.

Packet Processing

When analyzing RTP traffic, I noticed that both Zoom clients and the MMR server process a great deal of packets that didn’t appear to be RTP or XMPP. Looking at the SDK with symbols, one library appeared to do a lot of serialization: libssb_sdk.so. This library contains a great deal of classes with the methods load_from and save_to defined with identical declarations, so it is likely that they all implement the same virtual class.

One parameter to the load_from methods is an object of class msg_db_t,  which implements a buffer that supports reading different data types. Deserialization is performed by load_from methods by reading needed data from the msg_db_t object, and serialization is performed by save_to methods by writing to it.

After hooking a few save_to methods with Frida and comparing the written output to data sent with SSL_write, it became clear that these serialization classes are part of the remote attack surface of Zoom. Reviewing each load_from method, several contained code similar to the following (from ssb::conf_send_msg_req::load_from).


msg_db, &this->str_len, consume_bytes, error_out);

  str_len = this->str_len;

  if ( str_len )


    mem = operator new[](str_len);

    out_len = 0;

    this->str_mem = mem;


read_str_with_len(msg_db, mem, &out_len);

read_str_with_len is defined as follows.

int __fastcall ssb::i_stream_t<ssb::msg_db_t,ssb::bytes_convertor>::

read_str_with_len(msg_db_t* msg, signed __int8 *mem,

unsigned int *len)


  if ( !msg->invalid )


ssb::i_stream_t<ssb::msg_db_t,ssb::bytes_convertor>::operator>>(msg, len, (int)len, 0);

    if ( !msg->invalid )


      if ( *len )


read(msg, mem, *len, 0);



  return msg;


Note that the string buffer is allocated based on a length read from the msg_db_t buffer, but then a second length is read from the buffer and used as the length of the string that is read. This means that if an attacker could manipulate the contents of the msg_db_t buffer, they could specify the length of the buffer allocated, and overwrite it with any length of data (up to a limit of 0x1FFF bytes, not shown in the code snippet above).

I tested this bug by hooking SSL_write with Frida, and sending the malformed packet, and it caused the Zoom client to crash on a variety of platforms. This vulnerability was assigned CVE-2021-34423 and fixed on November 24, 2021.

Looking at the code for the MMR server, I noticed that ssb::conf_send_msg_req::load_from, the class the vulnerability occurs in was also present on the MMR server. Since the MMR forwards Zoom meeting traffic from one client to another, it makes sense that it might also deserialize this packet type. I analyzed the MMR code in IDA, and found that deserialization of this class only occurs during Zoom Webinars. I purchased a Zoom Webinar license, and was able to crash my own Zoom MMR server by sending this packet. I was not willing to test a vulnerability of this type on Zoom’s public MMR servers, but it seems reasonably likely that the same code was also in Zoom’s public servers.

Looking further at deserialization, I noticed that all deserialized objects contain an optional field of type ssb::dyna_para_table_t, which is basically a properties table that allows a map of name strings to variant objects to be included in the deserialized object. The variants in the table are implemented by the structure ssb::variant_t, as follows.

struct variant{

char type;

short length;

var_data data;


union var_data{

        char i8;

        char* i8_ptr;

        short i16;

        short* i16_ptr;

        int i32;

        int* i32_ptr;

        long long i64;

        long long i64*;


The value of the type field corresponds to the width of the variant data (1 for 8-bit, 2 for 16-bit, 3 for 32-bit and 4 four 64-bit). The length field specifies whether the variant is an array and its length. If it has the value 0, the variant is not an array, and a numeric value is read from the data field based on its type. If the length field has any other value, the data field is cast to a pointer, an array of that size is read.

My immediate concern with this implementation was that it could be prone to type confusion. One possibility is that a numeric value could be confused with an array pointer, which would allow an attacker to create a variant with a pointer that they specify. However, both the client and MMR perform very aggressive type checks on variants they treat as arrays. Another possibility is that a pointer could be confused with a numeric value. This could allow an attacker to determine the address of a buffer they control if the value is ever returned to the attacker. I found a few locations in the MMR code where a pointer is converted to a numeric value in this way and logged, but nowhere that an attacker could obtain the incorrectly cast value. Finally, I looked at how array data is handled, and I found that there are several locations where byte array variants are converted to strings, however not all of them checked that the byte array has a null terminator. This meant that if these variants were converted to strings, the string could contain the contents of uninitialized memory.

Most of the time, packets sent to the MMR by one user are immediately forwarded to other users without being deserialized by the server. For some bugs, this is a useful feature, for example, it is what allows CVE-2021-34423 discussed earlier to be triggered on a client. However, an information leak in variants needs to occur on the server to be useful to an attacker. When a client deserializes an incoming packet, it is for use on the device, so even if a deserialized string contains sensitive information, it is unlikely that this information will be transmitted off the device. Meanwhile, the MMR exists expressly to transmit information from one user to another, so if a string gets deserialized, there is a reasonable chance that it gets sent to another user, or alters server behavior in an observable way. So, I tried to find a way to get the server to deserialize a variant and convert it to a string. I eventually figured out that when a user logs into Zoom in a browser, the browser can’t process serialized packets, so the MMR must convert them to strings so they can be accessed through web requests. Indeed, I found that if I removed the null terminator from the user_name variant, it would be converted to a string and sent to the browser as the user’s display name.

The vulnerability was assigned CVE-2021-34424 and fixed on November 24, 2021. I tested it on my own MMR as well as Zoom’s public MMR, and it worked and returned pointer data in both cases.

Exploit Attempt

I attempted to exploit my local MMR server with these vulnerabilities, and while I had success with portions of the exploit, I was not able to get it working. I started off by investigating the possibility of creating a client that could trigger each bug outside of the Zoom client, but client authentication appeared complex and I lacked symbols for this part of the code, so I didn’t pursue this as I suspected it would be very time-consuming. Instead, I analyzed the exploitability of the bugs by triggering them from a Linux Zoom client hooked with Frida.

I started off by investigating the impact of heap corruption on the MMR process. MMR servers run on CentOS 7, which uses a modern glibc heap, so exploiting heap unlinking did not seem promising. I looked into overwriting the vtable of a C++ object allocated on the heap instead.


I wrote several Frida scripts that hooked malloc on the server, and used them to monitor how incoming traffic affects allocation. It turned out that there are not many ways for an attacker to control memory allocation on an MMR server that are useful for exploiting this vulnerability. There are several packet types that an attacker can send to the server that cause memory to be allocated on the heap and then freed when processing is finished, but not as many where the attacker can trigger both allocation and freeing. Moreover, the MMR server performs different types of processing in separate threads that use unique heap arenas, so many areas of the code where this type of allocation is likely to occur, such as connection management, allocate memory in a different heap arena than the thread where the bug occurs. The only such allocations I could find that were made in the same arena were related to meeting set-up: when a user joins a meeting, certain objects are allocated on the heap, which are then freed when they leave the meeting. Unfortunately, these allocations are difficult to automate as they require many unique users accounts in order for the allocation to be performed repeatedly, and allocation takes an observable amount of time (seconds).

I eventually wrote Frida scripts that looked for free chunks of unusual sizes that bordered C++ objects with vtables during normal MMR operation. There were a few allocation sizes that met this criteria, and since CVE-2021-34423 allows for the size of the buffer that is overflowed to be specified by the attacker, I was able to corrupt the memory of the adjacent object. Unfortunately, heap verification was very robust, so in most cases, the MMR process would crash due to a heap verification error before a virtual call was made on the corrupted object. I eventually got around this by focusing on allocation sizes that are small enough to be stored in fastbins by the heap, as heap chunks that are stored in fastbins do not contain verifiable heap metadata. Chunks of size 58 turned out to be the best choice, and by triggering the bug with an allocation of that size, I was able to control the pointer of a virtual call about one in ten times I triggered the bug.

The next step was to figure out where to point the pointer I could control, and this turned out to be more challenging than I expected. The MMR process did not have ASLR enabled when I did this research (it was enabled in version 4.6.20211128.136, which was released on November 28, 2021), so I was hoping to find a series of locations in the binary that this call could be directed to that would eventually end in a call to execv with controllable parameters, as the MMR initialization code contains many calls to this function. However, there were a few features of the server that made this difficult. First, only the MMR binary was loaded at a fixed location. The heap and system libraries were not, so only the actual MMR code was available without bypassing ASLR. Second, if the MMR crashes, it has an exponential backoff which culminates in it respawning every hour on the hour. This limits how many exploit attempts an attacker has. It is realistic that an attacker might spend days or even weeks trying to exploit a server, but this still limits them to hundreds of attempts. This means that any exploit of an MMR server would need to be at least somewhat reliable, so certain techniques that require a lot of attempts, such as allocating a large buffer on the heap and trying to guess its location were not practical.

I eventually decided that it would be helpful to allocate a buffer on the heap with controlled contents and determine its location. This would make the exploit fairly reliable in the case that the overflow successfully leads to a virtual call, as the buffer could be used as a fake vtable, and also contain strings that could be used as parameters to execv. I tried using CVE-2021-34424 to leak such an address, but wasn’t able to get this working.

This bug allows the attacker to provide a string of any size, which then gets copied out of bounds up until a null character is encountered in memory, and then returned. It is possible for CVE-2021-34424 to return a heap pointer, as the MMR maps the heap that gets corrupted at a low address that does not usually contain null bytes, however, I could not find a way to force a specific heap pointer to be allocated next to the string buffer that gets copied out of bounds. C++ objects used by the MMR tend to be virtual objects, so the first 64 bits of most object allocations are a vtable which contains null bytes, ending the copy. Other allocated structures, especially larger ones, tend to contain non-pointer data. I was able to get this bug to return heap pointers by specifying a string that was less than 64 bits long, so the nearby allocations were sometimes the pointers themselves, but allocations of this size are so frequent it was not possible to ascertain what heap data they pointed to with any accuracy.

One last idea I had was to use another type confusion bug to leak a pointer to a controllable buffer. There is one such bug in the processing of deserialized ssb::kv_update_req objects. This object’s ssb::dyna_para_table_t table contains a variant named nodeid which represents the specific Zoom client that the message refers to. If an attacker changes this variant to be of type array instead of a 32-bit integer, the address of the pointer to this array will be logged as a string. I tried to combine CVE-2021-34424 with this bug, hoping that it might be possible for the leaked data to be this log string that contains pointer information. Unfortunately, I wasn’t able to get this to work because of timing: the log entry needs to be logged at almost exactly the same time as the bug is triggered so that the log data is still in memory, and I wasn't able to send packets fast enough. I suspect it might be possible for this to work with improved automation, as I was relying on clients hooked with Frida and browsers to interact with the Zoom server, but I decided not to pursue this as it would require tooling that would take substantial effort to develop.


I performed a security analysis of Zoom and reported two vulnerabilities. One was a buffer overflow that affected both Zoom clients and MMR servers, and one was an info leak that is only useful to attackers on MMR servers. Both of these vulnerabilities were fixed on November 24, 2021.

The vulnerabilities in Zoom’s MMR server are especially concerning, as this server processes meeting audio and video content, so a compromise could allow an attacker to monitor any Zoom meetings that do not have end-to-end encryption enabled. While I was not successful in exploiting these vulnerabilities, I was able to use them to perform many elements of exploitation, and I believe that an attacker would be able to exploit them with sufficient investment. The lack of ASLR in the Zoom MMR process greatly increased the risk that an attacker could compromise it, and it is positive that Zoom has recently enabled it. That said, if vulnerabilities similar to the ones that I reported still exist in the MMR server, it is likely that an attacker could bypass it, so it is also important that Zoom continue to improve the robustness of the MMR code.

It is also important to note that this research was possible because Zoom allows customers to set up their own servers, meanwhile no other video conferencing solution with proprietary servers that I have investigated allows this, so it is unclear how these results compare to other video conferencing platforms.

Overall, while the client bugs that were discovered during this research were comparable to what Project Zero has found in other videoconferencing platforms, the server bugs were surprising, especially when the server lacked ASLR and supports modes of operation that are not end-to-end encrypted.

There are a few factors that commonly lead to security problems in videoconferencing applications that contributed to these bugs in Zoom. One is the huge amount of code included in Zoom. There were large portions of code that I couldn’t determine the functionality of, and many of the classes that could be deserialized didn’t appear to be commonly used. This both increases the difficulty of security research and increases the attack surface by making more code that could potentially contain vulnerabilities available to attackers. In addition, Zoom uses many proprietary formats and protocols which meant that understanding the attack surface of the platform and creating the tooling to manipulate specific interfaces was very time consuming. Using the features we tested also required paying roughly $1500 USD in licensing fees. These barriers to security research likely mean that Zoom is not investigated as often as it could be, potentially leading to simple bugs going undiscovered.  

Still, my largest concern in this assessment was the lack of ASLR in the Zoom MMR server. ASLR is arguably the most important mitigation in preventing exploitation of memory corruption, and most other mitigations rely on it on some level to be effective. There is no good reason for it to be disabled in the vast majority of software. There has recently been a push to reduce the susceptibility of software to memory corruption vulnerabilities by moving to memory-safe languages and implementing enhanced memory mitigations, but this relies on vendors using the security measures provided by the platforms they write software for. All software written for platforms that support ASLR should have it (and other basic memory mitigations) enabled.

The closed nature of Zoom also impacted this analysis greatly. Most video conferencing systems use open-source software, either WebRTC or PJSIP. While these platforms are not free of problems, it’s easier for researchers, customers and vendors alike to verify their security properties and understand the risk they present because they are open. Closed-source software presents unique security challenges, and Zoom could do more to make their platform accessible to security researchers and others who wish to evaluate it. While the Zoom Security Team helped me access and configure server software, it is not clear that support is available to other researchers, and licensing the software was still expensive. Zoom, and other companies that produce closed-source security-sensitive software should consider how to make their software accessible to security researchers.

3 Biggest Threats to the Retail Industry

14 January 2022 at 13:28

Retail is one of the top industries targeted by cyber attacks and physical attacks. VerSprite's Threat Intelligence Group have been tracking patterns of cyber attacks and physical attacks and compiled our findings into one attack tree. In this article, VerSprite uses an attack tree to map the top methods, motives, and threat organizations the financial industry should be aware of.

The post 3 Biggest Threats to the Retail Industry appeared first on VerSprite.

Threat Roundup for January 7 to January 14

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Jan. 7 and Jan. 14. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

January 2022 Patch Tuesday: Multiple Critical Vulnerabilities and Microsoft Exchange Remote Code Execution

14 January 2022 at 12:37

Kicking off the first Patch Tuesday of 2022, CrowdStrike continues to provide research and analysis regarding critically rated vulnerabilities and the subsequent patches offered by Microsoft. In this month’s updates we see the lion’s share of updates directed at Microsoft’s Windows and Extended Security Update (ESU) products, while other patches target lesser-known components of Microsoft’s operating system. What is noticeably missing this month is a patch for any in-the-wild exploited vulnerabilities, as there have been several in recent months. 

We also discuss three Microsoft Exchange remote code execution vulnerabilities that received updates. If you recall, Microsoft Exchange was involved in a massive exploitation campaign in early 2021. Prioritizing these patches should be strongly considered if your organization relies on this product. 

New Patches for 97 Vulnerabilities

This month’s Patch Tuesday update includes fixes for 97 vulnerabilities. Combined with the 29 vulnerabilities that received out-of-band (OOB) updates at the start of January, this first month of 2022 has a total of 126 patched updates. On its own, that number isn’t too surprising, given the Log4j vulnerabilities SecOps staff have to deal with (see the CrowdStrike Log4j Resource Center for more information) but the updates from Microsoft are certainly needed, as SecOps still remain pressed for time when it comes to mitigation and remediation. 

Similar to risk analysis for the past three months, the top two attack types for Microsoft products continue to be privilege elevation and remote code execution. The third primary attack type alternates between information disclosure and denial of service.

However, unlike the last two months of updates — where patches were spread more evenly across product families — this month we see the large majority of updates concentrated on Windows products and Extended Security Updates (ESU) products. Consider focusing your patching based on the family of Windows products your organization uses.

Figure 1. Breakdown of January 2022 Patch Tuesday attack types

Figure 2. Breakdown of January 2022 Patch Tuesday affected product families

Remote Code Execution and Elevation of Privilege Dominate as Attack Types for January’s Critical Vulnerabilities

This month, a number of vulnerabilities have a CVSS score of 8.8 or higher affecting various Microsoft products. Remember, the criticality of a CVSS score alone should not be the only determining factor in your prioritization process. A combination of various data points, attacker information and news reports could change how severe or critical that score may be for your organization. (Falcon Spotlight™ ExPRT.AI can help your staff quickly identify what’s truly critical and relevant to your organization.) However, CrowdStrike analysis shows that among this month’s critically ranked vulnerabilities, two attack types — remote code execution and privilege escalation — are particularly attractive methods, allowing attackers to gain a foothold in affected systems.

CVE-2022-21849: This remote code execution vulnerability affects the Internet Key Exchange. It can be leveraged with an unauthenticated attacker that is able to run the IPSec Service. It’s been given the most Critical CVSS score of 9.8. 

CVE-2022-21907: This vulnerability affecting the HTTP Protocol Stack is also ranked as Critical this month. This vulnerability impacts the Windows Operating System in Windows 10 and Windows Server 2019, but the HTTP Trailer Support feature — which is the vulnerable component — is not enabled by default. There may be additional manual validation that your SecOps staff should perform. It should be noted that this vulnerability is remotely exploitable on older versions of the operating system, which could open the door for self-propagating malware to exploit it.

CVE-2022-21901: This vulnerability is exploited via privilege escalation. Attackers exploit this Windows Hyper-V vulnerability by executing a specially crafted application on a vulnerable system. If successful, an attacker could potentially interact with processes of another Hyper-V guest hosted on the same Hyper-V host.

The remaining vulnerabilities listed in the table below are executed via a Remote Procedure Call (RPC) Runtime for CVE-2022-21922 and a remote code execution attack type on Microsoft Office for CVE-2022-21840. For the latter vulnerability, it’s worth noting that this vulnerability affects Microsoft Office versions for macOS, Apple’s operating system. At the time of this month’s Microsoft Patch Tuesday release, there are no currently available patches for Apple Systems running Microsoft Office products.

Rank CVSS Score CVE Description
Critical 9.8 CVE-2022-21849 Windows IKE Extension Remote Code Execution Vulnerability
Critical 9.8 CVE-2022-21907 HTTP Protocol Stack Remote Code Execution Vulnerability
Critical 9 CVE-2022-21901 Windows Hyper-V Elevation of Privilege Vulnerability
Critical 8.8 CVE-2022-21922 Remote Procedure Call Runtime Remote Code Execution Vulnerability
Critical 8.8 CVE-2022-21840 Microsoft Office Remote Code Execution Vulnerability

Microsoft Exchange Remote Code Execution Vulnerabilities

Microsoft Exchange Server is a known objective for attackers. When vulnerabilities affecting this product are released, SecOps staff often face the pressure of patching them as soon as possible, especially if these servers are exposed to the internet. This month’s updates include fixes for three remote code execution vulnerabilities, all with a CVSS Score of 9.0 (see the table below). 

As we’re approaching the one year anniversary of the massive exploitation campaign that occurred against Microsoft Exchange Server, it’s important to keep an eye out for potential attack vectors. It’s paramount for SecOps teams to be able to identify vulnerable instances and patch them the first opportunity they have.

Of note, all of the CVEs listed in the table below have been flagged as the attack vector being “adjacent.” This means that this particular attack type cannot be executed across the internet, but it could be successful if an attacker has gained a foothold on any other machine in the network.

Rank CVSS Score CVE Description
Critical 9 CVE-2022-21846 Microsoft Exchange Server Remote Code Execution Vulnerability
Critical 9 CVE-2022-21855 Microsoft Exchange Server Remote Code Execution Vulnerability
Critical 9 CVE-2022-21969 Microsoft Exchange Server Remote Code Execution Vulnerability

Remote Desktop Protocol Vulnerabilities

Three remote code execution vulnerabilities received updates this month on Microsoft’s Remote Desktop Protocol. Two of them affect the client (CVE-2022-21850 and CVE-2022-21851), and one affects Remote Desktop Protocol (CVE-2022-21893).

To exploit CVE-2022-21850 and CVE-2022-21851, an attacker would need to persuade an authenticated user to connect to a malicious remote desktop server, enabling the attacker to then exploit the vulnerabilities via remote code execution. 

Similarly, to succeed in exploiting CVE-2022-21893, an attacker would need to convince the victim to connect to a vulnerable server, which would enable the attacker to read or tamper with clipboard contents on the victim’s machine to read the file system.

We reported two similar vulnerabilities in November 2021, and two information disclosure vulnerabilities and another remote code execution vulnerability in our December 2021 update.

Rank CVSS Score CVE Description
Critical 8.8 CVE-2022-21850 Remote Desktop Client Remote Code Execution Vulnerability
Critical 8.8 CVE-2022-21851


Remote Desktop Client Remote Code Execution Vulnerability
Critical 8.8 CVE-2022-21893 Remote Desktop Protocol Remote Code Execution Vulnerability

Other Critical and Important Vulnerabilities to Consider

Rank CVSS Score CVE Description
Critical 8.8 CVE-2022-21920 Windows Kerberos Elevation of Privilege Vulnerability
Important 7.0 CVE-2022-21882 Win32k Elevation of Privilege Vulnerability
Important 7.0 CVE-2022-21887 Win32k Elevation of Privilege Vulnerability
Important 5.5 CVE-2022-21876 Win32k Information Disclosure Vulnerability
Important 5.5 CVE-2022-21906 Windows Defender Application Control Security Feature Bypass Vulnerability
Important 4.4 CVE-2022-21921 Windows Defender Application Control Security Feature Bypass Vulnerability

Patch and Review Your Mitigation Strategy 

A layered security approach — with a heavy emphasis on tools, programs and solutions that create efficiency and quicken response time — is key to a defensible security posture for your organization. Vulnerabilities are found in a wide variety of Microsoft products and platforms, with attackers diligently working on more creative ways to access valuable systems and information. 

This month’s focus on Windows and ESU products underscores the value of a robust mitigation strategy for vulnerabilities that affect your organization’s critical systems where patches are not available. 

Security and operations teams need layered security and tools that help prevent, detect and identify vulnerabilities and guide them through their patching and assessment process. A quick mitigation strategy will help to reduce the windows of opportunity for attackers, helping companies to remain as secure as possible and prevent any potential breach.

Learn More

Watch this video on Falcon Spotlight™ vulnerability management to see how you can quickly monitor and prioritize vulnerabilities within the systems and applications in your organization.

About CVSS Scores

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that CrowdStrike and many other cybersecurity organizations use to assess and communicate software vulnerabilities’ severity and characteristics. The CVSS Base Score ranges from 0.0 to 10.0, and the National Vulnerability Database (NVD) adds a severity rating for CVSS scores. Learn more about vulnerability scoring in this article

Additional Resources