This post is the result of research into the real-world application of the Bring Your Own Vulnerable Driver (BYOVD) technique along with Cisco Talos’ series of posts about  malicious Windows drivers. Some of this research was presented at the AVAR conference in Chennai at the beginning of December 2024. 

We would like to send a special thanks to Connor McGarr, Russell Sanford, Ryan Warns, Tim Harrison and Michal Poslušný for their previous work on analyzing vulnerabilities in drivers.  

During our research into vulnerable Windows drivers, we investigated classes of vulnerabilities typically exploited by threat actors as well as the payloads they typically deploy post-exploitation. The attacks in which attackers are deliberately installing known vulnerable drivers only to later exploit them is a technique referred to as Bring Your Own Vulnerable Driver (BYOVD). 

How are threat actors using BYOVD? 

The malicious actors use these drivers to perform a myriad of actions that help them achieve their goals. In our research, we identified three major payloads used, which we describe below.  Along with these payloads, we also identified recent activity linked to ransomware groups, which demonstrates real-world cases of malicious actors exploiting vulnerable Windows drivers to achieve their objectives. 

Vulnerable drivers and common payloads 

Local escalation of privileges (admin to kernel/system) 

One of the most common payloads, when we consider vulnerable drivers with arbitrary kernel memory write vulnerabilities, is escalating the privileges of a malicious process. The access privileges for any process are stored in the primary access token structure, which is contained at an undocumented offset in the _EPROCESS structure, the kernel mode structure used to maintain information about each individual process by the Windows kernel. Vergilius Project contains the documentation and offsets of almost all undocumented Windows structures, including _EPROCESS, and can be used as a reference, equally by offensive researchers and defenders.    

A common strategy for escalating privileges of an unprivileged process is to find the _EPROCESS structure of a higher privileged process in kernel memory and replace the access token of the unprivileged process with the access token of the privileged process, which is relatively simple if a vulnerable drivers can be used for reading and writing kernel memory space.  

For example, a privilege escalation may be done by following the steps below: 

1. Find one _EPROCESS structure/object 
2. For example, load ntoskernel.exe in user mode and calculate RVA to PsInitialSystemProcess, which points to the System process (id: 0x04) _EPROCESS structure when ntoskernel.exe is loaded in memory during the boot process. 
3. Use NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS) 11, ModuleInfo, 1024 * 1024, NULL))) // 11 = SystemModuleInformation to find ntoskernel VA – use the vuln driver to read the offset, add the RVA to find the _EPROCESS structure in kernel memory. 
4. Read the token from the known offset using the vulnerable driver read or memory copy functionality. 
5. Parse _EPROCESS to find the  ActiveProcess links member that points to a linked list of other _EPROCESSES and iterate until the low privilege process is found. 
6. Overwrite the unprivileged process access token with the one previously saved from the SYSTEM process, using a vulnerable driver kernel memory write functionality.  

Loading of unsigned kernel code 

Arbitrary kernel memory write vulnerabilities in drivers can be used to deploy unsigned malicious code into the kernel memory space, either in the shellcode format or a format of the unsigned malicious driver. There are several open-source unsigned device drivers loading utilities. In one instance, Lenovo Mapper was used as a base to develop a game cheat utility “sexy_girl_addy.exe”, which was uploaded to VirusTotal in May 2024. The utility used the code in Lenovo Mapper to load a driver which seems to attempt to disable the TPM-based license check in the game Valorant.  

Bypass EDR software or game anti cheat software 

To showcase an example of malware exploiting vulnerable drivers to terminate EDR tools, we chose a Gh0stRAT campaign from September 2024. The dropper drops an executable “nthandlecallback.exe”, a vulnerable Dell binary utilities driver “dbutil_2_3.sys”, and a ZIP file with the name “tree.exe”. The ZIP contains an executable file “EDR.exe”, a DLL file “irrlicht.dll” and an encrypted file “server.log”. “EDR.exe” is a variant of the open-source tool RealBlindingEDR used to disable EDR programs by exploiting arbitrary memory write vulnerability in Dell’s binary utility driver while the first executable loads the DLL, which decrypts the final Gh0stRAT payload from the encrypted file.  

RealBlindingEDR is just one of many open-source tools developed for the purpose of disabling endpoint security software, and they are used by both threat actors and in red team-based exercises. 

Miscellaneous other payloads 

Vulnerable drivers, mostly in the category of drivers with insufficient access controls, have been used in some advanced attacks. For example, in the Shamoon campaign, a RawDisk driver from Eldos was used to overwrite hard drives, while in February 2022, HermeticWiper used a proxy physical disk writing driver from “EaseUS Partition Master” driver partition manager “empntdrv.sys” for overwriting drives. HermeticWiper contained four embedded resources, which are compressed copies of drivers used by the wiper, depending on the Windows version and the default word memory size for the operating system. 

Ransomware examples of malicious actors’ use of BYOD 

With the wide availability of EDR bypassing tools exploiting vulnerable drivers, it is not a surprise that the exploitation moved from the domain of advanced threat actors into the domain of commodity threats, primarily ransomware. We document here some of the known ransomware groups employing the BYOVD technique.  

January – Kasseika  

In January 2024, Kasseika ransomware operators abused a vulnerable driver, “viragt64.sys”, which is part of the legitimate VirIT antivirus software, to disable a pre-determined list of 991 processes related to security tools and system utilities. The ransomware-as-a-service (RaaS) operation has been active since 2023 and uses double extortion techniques but does not operate a data leak site. In recent attacks, the ransomware first executes a script to load various tools, such as a malicious executable named “Martini.exe” and the vulnerable driver that is renamed “Martini.sys”. Next, Kasseika will create and start a new service whereby the driver is loaded into the malicious executable.   

The executable starts scanning the environment for the hard-coded list of processes and, if detected, a control code is sent to the driver enabling it to terminate processes.  

March – Akira  

In March 2024, Akira has been observed abusing the legitimate, signed Zemana anti-malware kernel driver “zamguard64.sys” via PowerTool to disable EDR at the kernel level. The exploitation of the Zemana zamguard driver was a main component of the popular Terminator EDR killer tool listed for sale on illicit marketplaces beginning May 2023.  

July – Qilin   

In July 2024, the Qilin ransomware group, another group operating under a Raas model, was observed using a new malware dubbed “Killer Ultra” within an attack. Killer Ultra has a plethora of capabilities, including the ability to terminate security tools with a BYOVD technique, abusing a known arbitrary process termination vulnerability impacting Zemana Anti-Keylogger driver “ ”, tracked as CVE-2024-1853. The vulnerability enables attackers with the ability to terminate processes. Upon execution, Killer Ultra unpacks the vulnerable driver and creates a new service to looks for and disable a list of security tools.    

July – BlackByte  

Talos recently observed and documented developments in recent BlackByte attacks in July 2024 leveraging BYOVD to facilitate host encryption. The newer encryptor variant was observed dropping four vulnerable drivers as part of BlackByte’s usual BYOVD attack chain, which is an increase from the two or three drivers described in previous reports.These drivers consisted of RtCore64.sys, a driver originally used by MSI Afterburner a system overclocking utility, DBUtil_2_3.sys, a driver that is part of the Dell Client firmware update utility, zamguard64.sys, a part of the previously mentioned Zemana Anti-Malware (ZAM) application exploited by other threat actors, and gdrv.sys, a component of is the GIGABYTE tools software package for GIGABYTE motherboards. 

These four drivers were renamed and dropped by the encryptor binary in all BlackByte attacks investigated by Cisco Talos Incident Response (Talos IR), each with a similar naming convention. The nomenclature for the vulnerable drivers consisted of eight random alphanumeric characters followed by an underscore and an iterating number value.  

August – RansomHub  

In August 2024, RansomHub ransomware actors were observed using a new malware known as EDRKillShifter to disable security tools prior to executing the ransomware binary. The EDRKillShifter can act as a loader for a vulnerable legitimate driver that, once exploited, can facilitate persistent defense evasion. Recent exploits used by the adversary are related to POCs found on Github leveraging RentDrv2, while the other exploited a driver called ThreatFireMonitor. The adversary initiated the process by launching the password-protected EDRKillShifter binary, which decrypts and executes an embedded resource in memory, unpacking and executing a payload to exploit the target vulnerable legitimate driver to escalate privileges and disable active EDR processes.  

The malware then created and started a new service for the driver, loading it into the system. Finally, it continuously scanned for and terminated processes that match a hardcoded list of targets, for persistent defense evasion even on reboot.  

The adoption of the BYOVD technique by RansomHub and Qilin may be linked to members of the financially motivated threat group Scattered Spider joining forces with these ransomware groups.  The new partnership was identified and disclosed in public reporting in July 2024, but it is possible the relationship was already well established before then. Scattered Spider members are known for employing BYOVD tactics since at least December 2022.  

Windows drivers and vulnerabilities 

Creating malicious Windows drivers is increasingly difficult 

Creating a new malicious Windows kernel driver is becoming increasingly difficult. New Windows drivers must be signed with a valid extended validation (EV) certificate by the developer, pass the Microsoft Hardware Lab Kit (HLK) compatibility tests, and be signed by the Microsoft Dev Portal.  

However, this complex process, introduced for any newly created Windows kernel or user mode driver, does not apply to existing drivers, which means that legacy drivers signed with valid certificates will still be loaded into the Windows kernel space.  

Installing and exploiting existing legacy vulnerable drivers may be one of the very few ways to make changes to kernel data structures or execute code in kernel, as drivers have the same permissions as any other Windows kernel component.  

Microsoft introduced a blocklist of known vulnerable drivers to tackle this issue. At the beginning, the list was included into the Windows Defender Application Control feature and was superseded by the Windows Security application in newer Windows versions.  

Although the vulnerable drivers block list is turned on by default in systems running the Windows 11 2022 update or with systems with hardware virtualization code integrity (HVCI) turned on, there are still many systems which can be attacked by deploying a vulnerable driver or any newly discovered vulnerable driver that is not already on the blocklist.   

Common classes of vulnerabilities in BYOVD drivers 

While investigating vulnerable Windows kernel drivers commonly used by threat actors for BYOVD campaigns, we identified three classes of vulnerabilities that are typically exploited: arbitrary MSR writes, arbitrary kernel memory writes, and insufficient access controls to driver’s functionality. This classification is not strict, and one driver can belong to multiple classes of vulnerabilities.  

Arbitrary MSR read/write vulnerabilities 

To consider this class of vulnerabilities, we first need to introduce CPU model specific registers (MSRs). MSRs are additional CPU registers that are used by the CPU and the operating system for various purposes, including regulation of caching mechanism, regulation of fan speed, or transition from user mode into kernel mode. The MSRs can be addressed by their specific number, and some of them also have human readable names.  

 As a reminder, the transition from kernel to user mode happens in the lowest user mode DLL layer, usually “ntdll.dll”, when a system call number is placed into register rax and the syscall or the “int 0x2e” instruction is executed. During the transition, the syscall instruction updates the Instruction Pointer (RIP) and sets it to the address of the system call handler in the kernel as well as the Stack Pointer (RSP) to point to a stack in kernel space. 

The first function to run is “KiSystemCall64”, and a question one can ask is how do Windows know where to start the execution in kernel mode? The answer lies in a MSR specifically used during user to kernel mode transition. For 64-bit Windows systems, it is the IA32_LSTAR (MSR 0xC0000082), which contains the address of the kernel-mode entry point for the syscall instruction, typically the KiSystemCall64 function. 

By having the ability to write content into arbitrary MSRs, attackers may be able to replace the pointer to KiSystemCall64 with the pointer to a malicious function that can run code in the kernel context.  

As an example of a driver vulnerable to arbitrary MSR modifications, we chose WinRing0 driver, which is commonly used by XMRig cryptocurrency mining software to disable some processor features such as caching, to increase the performance of the miner. WinRing0 is also included in many open and closed source programs. Unfortunately, the driver is also exposed to an arbitrary MSR write vulnerability which can lead to kernel mode code execution in versions of Windows prior to Windows 8 or to escalation of privileges in later Windows versions. This method is mitigated in the latest Windows versions with the latest exploit mitigations, such as Virtualization Based Security (which will be discussed later in the post), which is enabled by default.    

Arbitrary kernel physical memory read/write vulnerabilities 

The second class of vulnerabilities in frequently used BYOVD drivers is the arbitrary kernel memory write class. Here, a driver functionality to write arbitrary memory is used as a write primitive to deploy shellcode into kernel memory or change important kernel data structures to achieve escalation of privileges for a malicious user mode process.  

A significant number of drivers with this class of vulnerability exists, and most of them are well documented. Readers are referred to the loldrivers project to find examples of vulnerable drivers allowing kernel memory write.  

Any driver that uses one of the following kernel functions for may be regarded as a candidate for this class of vulnerabilities, although further analysis is almost always required to conclude that a user buffer and the target address can be supplied to the driver through a user-accessible device I/O control code (IOCTL): 

Access to Physical Memory 
MmMapIOSpace() 
ZwMapViewOfSection()
  
PCI Config Space Access 
HalSetBusDataByOffset() 
HalGetBusDataByOffset()
  
Memory Copying Operations 
memcpy() 
memmove() 

A good example of this vulnerability group is CVE-2022-3699, a vulnerability in a Lenovo driver that allows arbitrary memory reading and writing.  

Misusing existing functionality in Windows drivers with insufficient access controls 

The third and the last class of vulnerabilities used by threat actors in attacks using BYOVD drivers is misusing existing driver functionality caused by insufficient access controls.  

INF files are files used during a driver’s installation, and among other things, they also contain permissions for the driver, specified using the SDDL language. The Security Descriptor Definition Language (SDDL) is a domain specific language that allows components to generate access control lists (ACLs) using a string format. It is utilized in both user-mode and kernel-mode programming. The diagram below illustrates how SDDL strings are structured for device objects. 

The access value specifies the type of access allowed. The SID value specifies a security identifier that determines to whom the access value applies (for example, a user or group). For example, string “D:P(A;;GA;;;SY)(A;;GR;;;WD)” allows the system (SY) access to everything and allows everyone else (WD) only read access.  

Programming Windows kernel drivers has a steep learning curve and, as a consequence, many drivers contain code that is copied from templates and example drivers, including their SDDL access permissions. When a driver is created, it is likely that its access permissions will be inadequate and will allow unprivileged users access to functionality that should otherwise be available to users with higher privilege levels.  

A good example of a vulnerable driver with insufficient permissions would be an old version of an antimalware software driver “viragt64.sys” (VirIT Agent System) developed by TG Soft, which exposes the functionality of terminating a process from the kernel mode to users with lower levels of privileges. This driver is used by ransomware threat actors such as Kasseika to terminate other antimalware and EDR products.  

In addition to documenting different classes of vulnerabilities in frequently used BYOVD drivers, we also investigated the most common payloads delivered by threats and potentially unwanted applications after exploiting vulnerable drivers and classified them into several groups including local escalation privileges, loading of unsigned code and bypassing EDR functionality.   

Modern Windows mitigations and vulnerable drivers 

Loading malicious code into kernel memory is one of the most powerful payloads attackers can use. This approach was frequently employed in the early days of Windows, prior to Windows Vista, when there were no requirements to sign drivers. The ability to load unsigned code into kernel mode was an incentive for the creation of several Windows kernel rootkits, such as Sinowal or TDL4, designed to hide the presence of malicious payloads from defenders by modifying kernel programs and data structures.  

To respond to those threats and kernel exploitation in general, Microsoft introduced kernel patch protection (KPP), better known as Patch Guard, in x64 versions of Windows XP SP3. This was followed by the requirement for drivers to be signed in x64 Windows Vista.  

The introduction of the mitigations into the Windows kernel sparked a race between threat actors and Microsoft. Attackers quickly responded to newly introduced mitigations by showing how digital signature enforcement can be turned off in a race with the Patch Guard, and Microsoft responded with more mitigations. Over time, the exploitation of Windows kernels became increasingly challenging.   Next, we will briefly describe only four significant anti-exploitation features implemented with Windows 10 and 11.  

Virtualization-Based Security (VBS) 

Virtual Trust Levels (VTLs) are a key concept within Virtualization-Based Security (VBS), designed to enhance system security by creating isolated execution environments. VTLs leverage hardware virtualization to separate and protect sensitive processes from potentially less secure code running in the main operating system. 

VTLs are essentially different security levels or “worlds” within the same physical machine, each providing a different level of trust. The main goal of VTLs is to isolate trusted operations and data from the rest of the system to prevent tampering. In Windows, there are two main VTL levels.  

• VTL0: This is the standard trust level, where the traditional operating system and all user-mode and kernel-mode applications run.  

• VTL1: This is a higher trust level used to execute sensitive security functions and store critical data. It is isolated from VTL0, meaning that operations in VTL0 cannot directly access or modify the code and data in VTL1. VTL1 is used to store sensitive information like encryption keys, password hashes, and security tokens (credentials guard).  

 By running different parts of the kernel in different trust levels, effectively different virtual machines, Windows can use Second Level Address Translation (SLAT) to create different access permissions for memory pages depending on the source of access.  

Essentially, in a process similar to shadowing page tables, VBS enforces exclusive write or execute page access permission. In other words, if a code from VTL0 attempts to change its own page table permissions from writable to executable this will be detected by the VTL1 and the data in the page still won’t be able to execute.  

This mechanism is one of the key features of another important mitigation, Hypervisor-Protected Code Integrity (HVCI). 

Hypervisor-Protected Code Integrity (HVCI) 

When Hypervisor-protected Code Integrity (HVCI) is enabled on a Windows system, it enforces control over memory page permissions to mitigate executable code injection. HVCI is designed so that only verified and trusted code is executed in kernel mode, and it applies policies to manage how memory pages can be used and modified. 

One of the important features enforced by HVCI (and supported by modern CPUs) is the prevention of pages being simultaneously writable and executable. This policy is known as Write XOR Execute (W^X), which prevents memory pages from being both writable and executable at the same time.  

HVCI prevents direct execution of code from pages that were recently writable, unless specific security checks are passed. Before any code can execute from a page that has had its permissions altered, it must pass a code integrity check, ensuring it is signed by a trusted certificate. If the code does not meet these integrity requirements, execution will be blocked. HVCI attempts to ensure that any code running in kernel mode is signed with a valid certificate.  

Kernel Control Flow Guard (kCFG) 

Kernel Control Flow Guard (kCFG) is a security feature in Windows designed to protect the operating system’s kernel from certain types of attacks that attempt to manipulate the control flow of kernel-mode code. It builds on the principles of Control Flow Guard (CFG), used to secure user-mode applications. 

kCFG aims to prevent exploits that involve redirecting the control flow of kernel code to unintended or malicious locations which should prevent exploits that hijack the control flow by overwriting function pointers and other data used for indirect code execution.  

During the compilation of the Windows kernel, kCFG instruments the code to create valid address bitmap and any indirect call must finish at a target known at compile time. If the call is directed outside know target the system will cause a security check failure.   

Kernel shadow stack 

The primary purpose of the Windows kernel shadow stack is to ensure that the return addresses on the call stack cannot be tampered with, specifically to mitigate exploitation using Return Oriented Programming (ROP). 

The shadow stack maintains a separate, copy of return addresses parallel to the regular call stack. When a function call occurs, the return address is pushed onto both the regular stack and the shadow stack. Upon function return, the system verifies the return address against the shadow stack to ensure it has not been altered. The shadow stack in Windows is hardware assisted for better performance through Intel Control-Flow Enforcement Technology (CET) and AMD Shadow Stacks.  

Conclusion 

In recent years, Windows platform security has improved to effectively prevent deployment of newly developed malicious drivers. However, kernel mode threats of vulnerable legacy drivers remain a concern. Luckily there are a few things we can do to mitigate the risks and detect potential campaigns using BYOVD technique. 

This could include enforcement of Extended Validation (EV) and Windows Hardware Quality Labs (WHQL) certified drivers, preventing risks associated with legacy drivers. If the blocking of all legacy drivers is not possible, employing the Windows Defender Application Control (Windows Security) drivers blocklist is recommended way to prevent the execution of known vulnerable drivers. 

Apart from the above, for threat detection and response, it recommended to develop a capability to monitor driver load events, such as those recorded by Sysmon’s event ID 6.  

In summary, while Windows security has improved, maintaining vigilance against kernel mode threats requires adoption of best practices and monitoring techniques to protect against known and unknown driver vulnerabilities.  

References and further reading 

Posts and papers 

1. Exploring Malicious Drivers Part 1 – Cisco Talos 
2. Exploring Malicious Drivers Part 2 – Cisco Talos 
3. The Current State of Exploit Development, Part 1 – Connor McGarr, Crowdstrike 
4. The Current State of Exploit Development, Part 2 – Connor McGarr, Crowdstrike 
5. No Code Execution? No Problem! Living The Age of VBS, HVCI, and Kernel CFG – Connor McGarr 
6. Signed kernel drivers – Unguarded gateway to Windows’ core – Michal Poslušný, ESET 
7. An In-Depth Look At Windows Kernel Threats – TrendMicro 
8. Windows security model for driver developers – Microsoft 
9. Driver Signing Policy – Microsoft  
10. Driver code signing requirements – Microsoft 

Videos 

1. A Look at Modern Windows Kernel Exploitation/Hacking – Off By One Security podcast with Connor McGarr 
2. Windows Internals – By Alex Sotirov 
3. Kernel Mode Threats and Practical Defenses – Joe Desimone, Gabriel Landau, Endgame (now Elastic) 
4. Device Driver Debauchery and MSR Madness – Ryan Warns, Timothy Harrison – INFILTRATE 2019  
5. No Code Execution? No Problem!  – Connor McGarr 
6. Get Off the Kernel if You Can’t Drive – Jesse Michael, DEF CON 27 Conference  

Books 

1. Windows Internals 7^th Edition – Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, David A. Solomon, Published by Microsoft Press 
2. Windows NT Device Driver Development – Peter G. Viscarola & W. Anthony Mason, Published by New Riders Publishing 
3. Windows Kernel Programming – Pavel Yosifovich, Published by Pavel Yosifovich 

Cisco Talos Blog – ​Read More

It’s December, and it’s high time to tell Santa how good girls and boys we’ve been at ANY.RUN. It’s time to reap acknowledgment from the industry, the community, and the customers. Here are the major tech awards we’ve received in 2024 as cybersecurity experts.  

Cybersecurity Excellence Awards from Cybersecurity Insiders

We nailed it in the Threat Hunting category. And we are proud: the award is well respected throughout the industry. Winners are selected by both community votes and judging panel evaluations. This ensures that recognition reflects real-world impact and peer validation.  
 
Holger Schulze, CEO of Cybersecurity Insiders:

With over 600 entries across more than 300 categories, the awards are highly competitive. Your achievement reflects outstanding commitment to the core principles of excellence, innovation, and leadership in cybersecurity.

Best Security Solution from World Future Awards 

The entire suite of ANY.RUN’s services, including the Interactive Sandbox, Threat Intelligence Lookup, and TI Feeds, was recognized as the “Best Threat Intelligence & Interactive Malware Analysis Platform.

That’s what the FWA team thinks of us:

ANY.RUN’s innovative, user-friendly malware analysis platform excels in its impact, value, and timeliness, making it a standout in the cybersecurity industry. The platform’s high quality and emotional quotient ensure it meets the evolving challenges of its users effectively.

For those who haven’t yet had a chance to explore Threat Intelligence Lookup, it is ANY.RUN’s flagship product that lets security professionals enrich their investigations into the latest malware and phishing threats.

It offers a searchable database of fresh Indicators of Compromise (IOCs), Indicators of Behavior (IOBs), and Indicators of Attack (IOAs), extracted from public samples analyzed in ANY.RUN’s sandbox.

Top 150 Cybersecurity Vendors by IT-Harvest 

We are in the list of Top 150 cybersecurity vendors. It is a well-respected global industry benchmark supported by IT-Harvest. It gathers top-tier vendors in cybersecurity — which is, by the way, a highly competitive and densely populated field.

ANY.RUN “managed to make an outstanding contribution to the cybersecurity landscape”, Richard Stiennon, Chief Research Analyst at IT-Harvest, says.  

Best in Behavior Analytics by CyberSecurity Breakthrough Awards 

We are grateful to be recognized for delivering quality behavior analytics, as it is among the key features of the ANY.RUN sandbox. It implies detailed analysis of network activity, and the processes malware agents initiate and engage in.

Besides, this fall we’ve taken our Automated Interactivity feature to the next level by implementing the Smart Content Analysis mechanism. The enhanced Automated Interactivity simplifies malicious behavior analysis and spares user’s time by identifying and auto-detonating the key components of malware at each stage of the attack. 
 
So the recognition was well deserved. But no time to rest on our laurels. We have huge plans for 2025, stay tuned!

Special Thanks to the ANY.RUN Community  

We would like to send our love and appreciation to our unique community.

Every analytic session, every piece of feedback, and every insight you provide helps us grow and improve. You are not just users — you are collaborators in our mission to build a safer digital world. 

About ANY.RUN  

ANY.RUN is a leading provider of a cloud-based malware analysis sandbox for effective threat hunting. Our service lets users safely and quickly analyze malware without the need for on-premises infrastructure. ANY.RUN is used by organizations of all sizes, including Fortune 500 companies, government agencies, and educational institutions.

With ANY.RUN you can: 

• Detect malware in seconds
• Interact with samples in real time
• Save time and money on sandbox setup and maintenance
• Record and study all aspects of malware behavior
• Collaborate with your team 
• Scale as you need

Get a 14-day free trial of ANY.RUN’s Interactive Sandbox →

The post Well done, ANY.RUN: Our Top Cybersecurity Awards in 2024 appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Today, AI-based technologies are already being used in every second company — with another 33% of commercial organizations expected to join them in the next two years. AI, in one form or another, will soon be ubiquitous. The economic benefits of adopting AI range from increased customer satisfaction to direct revenue growth. As businesses deepen their understanding of AI systems’ strengths and weaknesses, their effectiveness will only improve. However, it’s already clear that the risks associated with AI adoption need to be addressed proactively.

Even early examples of AI implementation show that errors can be costly — affecting not only finances but also reputation, customer relationships, patient health, and more. In the case of cyber-physical systems like autonomous vehicles, safety concerns become even more critical.

Implementing safety measures retroactively, as was the case with previous generations of technology, will be expensive and sometimes impossible. Just consider the recent estimates of global economic losses due to cybercrime: $8 trillion in 2023 alone. In this context, it’s not surprising that countries claiming 21^st century technological leadership are rushing to set up AI regulation (for example, China’s AI Safety Governance Framework, the EU’s AI Act, and the US Executive Order on AI). However, laws rarely specify technical details or practical recommendations — that’s not their purpose. Therefore, to actually apply regulatory requirements such as ensuring the reliability, ethics, and accountability of AI decision-making, concrete and actionable guidelines are required.

To assist practitioners in implementing AI today and ensuring a safer future, Kaspersky experts have developed a set of recommendations in collaboration with Allison Wylde, UN Internet Governance Forum Policy Network on AI team-member; Dr. Melodena Stephens, Professor of Innovation & Technology Governance from the Mohammed Bin Rashid School of Government (UAE); and Sergio Mayo Macías, Innovation Programs Manager at the Technological Institute of Aragon (Spain). The document was presented during the panel “Cybersecurity in AI: Balancing Innovation and Risks” at the 19^th Annual UN Internet Governance Forum (IGF) for discussion with the global community of AI policymakers.

Following the practices described in the document will help respective engineers — DevOps and MLOps specialists who develop and operate AI solutions — achieve a high level of security and safety for AI systems at all stages of their lifecycle. The recommendations in the document need to be tailored for each AI implementation, as their applicability depends on the type of AI and the deployment model.

Risks to consider

The diverse applications of AI force organizations to address a wide range of risks:

• The risk of not using AI. This may sound amusing, but it’s only by comparing the potential gains and losses of adopting AI that a company can properly evaluate all other risks.
• Risks of non-compliance with regulations. Rapidly evolving AI regulations make this a dynamic risk that needs frequent reassessment. Apart from AI-specific regulations, associated risks such as violations of personal-data processing laws must also be considered.
• ESG risks. These include social and ethical risks of AI application, risks of sensitive information disclosure, and risks to the environment.
• Risk of misuse of AI services by users. This can range from prank scenarios to malicious activities.
• Threats to AI models and datasets used for training.
• Threats to company services due to AI implementation.
• The resulting threats to the data processed by these services.

“Under the hood” of the last three risk groups lie all typical cybersecurity threats and tasks involving complex cloud infrastructure: access control, segmentation, vulnerability and patch management, creation of monitoring and response systems, and supply-chain security.

Aspects of safe AI implementation

To implement AI safely, organizations will need to adopt both organizational and technical measures, ranging from staff training and periodic regulatory compliance audits to testing AI on sample data and systematically addressing software vulnerabilities. These measures can be grouped into eight major categories:

• Threat modeling for each deployed AI service.
• Employee training. It’s important not only to teach employees general rules for AI use, but also to familiarize business stakeholders with the specific risks of using AI and tools for managing those risks.
• Infrastructure security. This includes identity security, event logging, network segmentation, and XDR.
• Supply-chain security. For AI, this involves carefully selecting vendors and intermediary services that provide access to AI, and only downloading models and tools from trusted and verified sources in secure formats.
• Testing and validation. AI models need to be evaluated for compliance with the industry’s best practices, resilience to inappropriate queries, and their ability to effectively process data within the organization’s specific business process.
• Handling vulnerabilities. Processes need to be established to address errors and vulnerabilities identified by third parties in the organization’s system and AI models. This includes mechanisms for users to report detected vulnerabilities and biases in AI systems, which may arise from training on non-representative data.
• Protection against threats specific to AI models, including prompt injections and other malicious queries, poisoning of training data, and more.
• Updates and maintenance. As with any IT system, a process must be built for prioritizing and promptly eliminating vulnerabilities, while preparing for compatibility issues as libraries and models evolve rapidly.
• Regulatory compliance. Since laws and regulations for AI safety are being adopted worldwide, organizations need to closely monitor this landscape and ensure their processes and technologies comply with legal requirements.

For a detailed look at the AI threat landscape and recommendations on all aspects of its safe use, download Guidelines for Secure Development and Deployment of AI Systems.

Kaspersky official blog – ​Read More

Overview

The Australian Cyber Security Center (ACSC) has alerted organizations about a severe vulnerability in the Apache Struts2 Framework. The vulnerability, CVE-2024-53677, has been identified in the Framework, posing a critical risk to organizations that use, develop, or support Java-based applications built on this widely adopted framework. 

This vulnerability primarily affects versions of Apache Struts2 before 6.4.0 and can lead to severe security breaches, including remote code execution (RCE). Australian organizations using these versions must take immediate action to mitigate the risks posed by this flaw.

CVE-2024-53677 is a critical file upload vulnerability in the Apache Struts2 Framework. It allows attackers to exploit path traversal flaws and manipulate file upload parameters. The flaw is found in the deprecated File Upload Interceptor component.

Under certain circumstances, this can lead to the uploading of malicious files that could be executed remotely, potentially giving attackers full control over the affected system. The issue is particularly concerning for enterprise Java applications that rely on Apache Struts2.

Details of Apache Struts2 Framework Vulnerability (CVE-2024-53677)

According to the Apache advisory, the affected versions of Struts include Struts 2.0.0 through 2.3.37 (end-of-life versions), Struts 2.5.0 through 2.5.33, and Struts 6.0.0 through 6.3.0.2. The vulnerability has been classified as “critical,” with a CVSSv3 score of 9.8, reflecting its potential for exploitation. 

This issue is not isolated; Apache Struts vulnerabilities have been popular targets for threat actors, with two major incidents occurring in 2017 and 2023. As such, CVE-2024-53677 must be taken seriously by organizations that continue to use older versions of Struts.

Organizations using Java applications that leverage the affected versions of Apache Struts2 are at high risk of exploitation. This includes various industries such as government, telecommunications, finance, and e-commerce, where the framework remains integral to business operations.

The critical nature of CVE-2024-53677 lies in its ability to facilitate remote code execution. Once an attacker successfully uploads a malicious file—often a web shell—through the vulnerable file upload mechanism, they can execute arbitrary commands, steal sensitive data, and further compromise the system.

Recommendations for securing your systems

Organizations are strongly advised to take the following steps to mitigate the risks associated with CVE-2024-53677:

• The most effective way to address the vulnerability is to upgrade to Apache Struts 6.4.0 or a later version. This version replaces the deprecated File Upload Interceptor with the more secure Action File Upload Interceptor, which significantly reduces the risk of exploitation. However, migrating to this new file upload mechanism requires modifications to the existing code, as the old File Upload Interceptor is no longer secure.
• If upgrading to Struts 6.4.0 is not immediately feasible, organizations should apply any available patches for affected versions of Struts. Additionally, continuous monitoring of systems for suspicious activity is crucial. Logs should be reviewed regularly for any indications of attempts to exploit the vulnerability.
• Organizations should audit their Java-based applications to determine whether they are using the affected versions of Apache Struts. They should also verify whether the vulnerable File Upload Interceptor component is being used. Applications that do not rely on this component are not affected by CVE-2024-53677.
• Given the critical nature of this vulnerability, organizations must stay updated on vendor advisories and any new patches or security releases. Apache’s security bulletins should be regularly checked to ensure that any new information or mitigation strategies are quickly applied.

Conclusion 

CVE-2024-53677 presents a critical risk of remote code execution (RCE), allowing attackers to exploit file upload vulnerabilities and gain unauthorized control over systems. Organizations using Struts2 versions prior to 6.4.0 must upgrade immediately and migrate to the new Action File Upload Interceptor.

Prompt patching and monitoring are essential to prevent exploitation. To strengthen defenses, businesses can turn to Cyble’s AI-powered cybersecurity solutions like Cyble Vision, which offer advanced threat intelligence, dark web monitoring, and proactive risk detection. Discover how Cyble Vision can enhance your cybersecurity strategy by booking a free demo today.

References:

https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/critical-security-vulnerability-affecting-apache-struts2-below-6-4-0

The post ACSC Warns of Remote Code Execution Risk in Apache Struts2 appeared first on Cyble.

Blog – Cyble – ​Read More