The entry barriers for app development have plummeted in recent times — with nearly anyone now able to build a professional website, personal news bot, or dashboard simply by giving a chatbot or AI agent a few instructions in natural English. Unfortunately, a massive gap exists between a slick prototype and a reliable, production-ready, secure application. To avoid becoming the subject of another AI fail story, or losing money and sensitive data, follow these straightforward tips. These are intended specifically for non-technical creators and very small teams. Larger enterprises should follow more sophisticated recommendations.

The primary risks of AI-generated code

While vibe coding can deliver a seemingly functional app in just a few hours, it will likely contain dangerous flaws. AI models are trained on code samples from across the internet, which often include suboptimal tutorials, buggy snippets, and outright junk. Sometimes this code simply fails to run, but more often the situation is subtler and more hazardous: the app appears to work, yet under the hood, it might rely on a crude imitation of the required logic or contain critical vulnerabilities. According to a study by the Cloud Security Alliance AI Safety Initiative, the following facts should be considered when using AI for coding:

• At least 45% of AI-generated code contains dangerous vulnerabilities, such as failing to verify the user before granting access to sensitive data.
• A professional developer using AI can write code three to four times faster, but may introduce 10 times as many vulnerabilities.
• Twenty percent of AI-generated code attempts to use external libraries and modules that don’t actually exist.
• Even when an application handles confidential data — such as payments, private messages, or documents — AI-generated code sometimes skips credential verification entirely. This can leave the app’s data open for anyone on the internet to read.
• In other instances, the app might correctly prompt for a username and password but fail to enforce access controls, allowing any registered user to view everyone else’s data.
• Access keys (tokens) for databases and AI services may be embedded directly into the source code, easy to steal, and difficult to rotate after a data breach or cyberattack.
• Project code or critical build outputs are often deployed to servers without proper access restrictions, leaving both the application logic and sensitive access keys vulnerable to theft.
• AI may implement insecure database access patterns, which can allow attackers to bypass the application to steal data or execute arbitrary code on the database server.
• Apps that include API functionality often suffer from insecure API implementations, lacking both user permission checks and rate limiting.

Core principles of securing vibe code

Always verify. Treat AI-generated code as a rough draft. It should always be reviewed and rigorously tested. Ideally, professional developers should handle this; however, if none are available, the vibe-coder should at least test the application themselves, have friends or colleagues poke around the live app, and ask them to review key code snippets. It’s also possible to evaluate code integrity by submitting a separate prompt to the AI: “Review this code for secure development best practices and check for OWASP Top 10 vulnerabilities”.

Protect secrets. Never include passwords, API keys, or any other sensitive data in AI prompts. Instead, instruct the AI to write code that securely stores all secrets in environment variables (special hidden settings).

Prioritize efforts. The main risks emerge when an application is network-accessible to outsiders, processes valuable data, or runs on infrastructure that would be useful to attackers. The components of an app or system that meet these criteria are precisely what’s needed to be protected first. A static website composed of three HTML pages faces significantly lower risk than a loyalty program integrated into an online store.

Make security an explicit requirement. Even a simple, straightforward line in the prompt, like “Follow industry standards and security best practices when generating this code”, improves the output. Providing more specific requirements for critical code snippets makes the results even better.

Don’t trust default settings. Often, the danger in vibe coding lies in the configuration rather than the code itself. For example, an app processing sensitive company data might be deployed on a public vibe-coding platform (Lovable or the like), and remain accessible to the entire internet by default. Even if the code is flawless, making that information public is a critical security failure. Because of this, every component — from hosting and database settings to the deployment pipeline — must be manually reviewed and properly configured. If the purpose of a setting is unclear, consult a chatbot for the optimal values, specifying that its goal is to enhance security, and describing who the app is intended for.

Security is a continuous process. Securing the app should not be treated as a one-off task. Every time an application is updated, hosting providers are changed, or a project undergoes any other major shift, all steps in making it secure should be revisited, and the risks reassessed.

Tips for securing vibe code

It’s natural to want an app built from broad prompts like “Make me a beautiful, user-friendly, fast, reliable, and secure app for [use case].” However, for the results to actually be effective, each of those requirements needs to be fleshed out. Below, we’ve outlined recommendations for building standard components that will make vibe code more secure. It’s important to emphasize that “more secure” doesn’t mean “perfectly secure” — these approaches lower the risk, but that risk remains well above zero.

Demand security from the AI. When assigning a task to a neural network, be explicit: “write secure code, validate data, encrypt passwords”. Each type of task requires its own security prompt. For instance, don’t just ask to “build a login form”. Instead, ask for a “secure login form with credential validation, authentication and authorization (user permissions) controls, brute-force protection, password hashing according to modern standards, transmission strictly over HTTPS, and no hardcoded secrets”. It makes sense to use these secure requirement templates every time. It’s also helpful to keep a short cheat sheet of standard requirements for AI prompts: “validate all external data and user input before processing”, “no secrets in code”, “protect APIs from abuse”, “restrict user permissions”, and “secure default settings”.

Use off-the-shelf solutions. If an app needs a user management system, insist on using a popular, reputable library, such as NextAuth, Auth0, and so on, rather than inventing a new and vulnerable solution. This is the most common cause of data breaches. This applies to more than just login and registration; for other high-risk actions like file uploads and API call processing, it’s better to use established frameworks and libraries with built-in protections rather than building everything from scratch.

Don’t trust the AI blindly; verify open-source components. Neural networks often try to inject non-existent components and libraries into a project or suggest outdated versions. Always search for the suggested names online to ensure they are real, widely used, and secure — and make sure the latest versions are used.

Demand robust encryption. Explicitly state that modern industry standards must be used for both data transmission and storage: TLS 1.3 based on OpenSSL for network traffic; argon2 or bcrypt for hashing credentials; and so on.

Never trust user input. Always instruct the AI to include validation for any data entered by users, whether in forms or search bars. Use terms like “parameterization” and “sanitization” to emphasize that the app needs protection against malicious actors, not just users’ typos.

Set limits on user actions. Require the AI to implement rate limiting for login attempts or general requests. This will protect a project from automated attacks like DoS and brute-force password guessing.

Hide the system’s inner workings. If the site crashes, users should see a simple apology page rather than a detailed error report containing snippets of the code. That kind of information is a goldmine for hackers.

Remember that you’re a developer, and you need to protect development-related digital assets. All related accounts — such as access to GitHub, project hosting, and other resources — are prime targets for attackers. Be sure to enable two-factor authentication (2FA) on all work accounts.

Make backups. Regularly back up a project both locally and to the cloud to protect it against critical AI errors as well as cyberattacks. These backups should include both the application’s source code and its databases.

Set up a sandbox. Test new features and app versions in a secure environment using a clone of an active site or app and a copy of a database. Always run thorough tests before pushing an update live. This allows catching issues without putting users or their data at risk.

Update dependencies and scan them for vulnerabilities. A vibe-coded app will almost certainly rely on third-party libraries and components, known as dependencies. It’s wise to update these regularly by rebuilding an app with the latest versions, even if app’s code itself has not been changed. This process helps patch known security flaws in the used packages.

Check for secrets leaking into the repository. Use secrets scanners like TruffleHog to audit resulting code. Even with instructions, AI might slip up and include an API key or password in the source code. A scanner ensures that files containing keys and passwords don’t end up in Git or get published alongside the project.

Even if you keep your crypto assets in a cold wallet and use Apple devices — which enjoy a strong reputation for security — cybercriminals may still find a way to swipe your funds. These bad actors are combining well-known tricks into new attack chains — including baiting victims right inside the App Store.

Crypto-wallet clones

This past March, we discovered phishing apps at the top of the Chinese App Store charts with icons and names mimicking popular crypto-wallet management tools. Because regional restrictions block several official wallet apps from the Chinese App Store, attackers have stepped in to fill the void. They created fake apps using icons similar to the originals and names with intentional typos — likely to bypass App Store moderation and deceive users.

Phishing apps in the App Store appearing in search results for Ledger Wallet (formerly Ledger Live)

Beyond these, we found a number of apps with names and icons that had nothing to do with cryptocurrency. However, their promotional banners claimed they could be used to download and install official wallet apps that are otherwise unavailable in the regional App Store.

Banners on app pages claiming they can be used to download the official TokenPocket app, which is missing from the local App Store

In total, we identified 26 phishing apps mimicking the following popular wallets:

• MetaMask
• Ledger
• Trust Wallet
• Coinbase
• TokenPocket
• imToken
• Bitpie

A few other very similar apps didn’t contain phishing functionality yet, but all signs point to them being linked to the same attackers. It’s likely they plan to add malicious features in future updates.

To get these apps cleared for the App Store, the developers added basic functionality, such as a game, a calculator, or a task planner.

Installing any of these clones is the first step toward losing your crypto assets. While the apps themselves don’t steal cryptocurrency, seed phrases, or passwords, they serve as bait that builds user trust by virtue of being listed on the official App Store. Once installed and launched, however, the app opens a phishing site in the victim’s browser, designed to look like the App Store, which then prompts the user to install a compromised version of the relevant crypto wallet. The attackers have created multiple versions of these malicious modules, each tailored to a specific wallet. You can find a detailed technical breakdown of this attack in our Securelist post.

A victim who falls for the ruse is first prompted to install a provisioning profile, which allows apps to be sideloaded onto an iPhone outside the App Store. The profile is then used to install the malicious app itself.

A fake App Store site prompting the user to install an app masquerading as Ledger Wallet

In the example above, the malware is built on the original Ledger app with integrated Trojan functionality. The app looks identical to the original, but when connected to a hardware wallet, it displays a window requiring a seed phrase, supposedly to restore access. This is not standard procedure: typically, you only need to enter a PIN — never a recovery phrase. If a victim is deceived by the app’s apparent legitimacy and enters their seed phrase, it’s immediately sent to the attackers’ server — granting them full access to the victim’s crypto assets.

Sideloading outside the App Store

A critical component of this scheme involves installing malware on the victim’s iPhone by bypassing the App Store and its verification process. This is executed much like the SparkKitty iOS infostealer we discovered previously. The attackers managed to gain access to the Apple Developer Enterprise Program. For just US$299 a year — and following an interview and corporate verification — this program allows entities to issue their own configuration profiles and apps for direct download to user devices without ever publishing them in the App Store.

To install the app, the victim must first install a configuration profile that enables the malware to be downloaded directly, bypassing the App Store. Note the green verification checkmark

In general, enterprise profiles are designed to allow organizations to deploy internal apps to employees’ devices. These apps don’t require App Store publication and can be installed on an unlimited number of devices. Unfortunately, this feature is often abused. These profiles are frequently used for software that fails to meet Apple’s policies, such as online casinos, pirated mods, and, of course, malware.

This is precisely why the fake site mimicking the Apple Store prompts the user to install a configuration profile before delivering the app signed by that profile.

Stealing cryptocurrency via macOS apps and extensions

Many crypto owners prefer managing their wallets on a computer rather than a smartphone — often choosing Macs for the task. It’s no surprise, then, that most popular macOS infostealers target crypto-wallet data in one way or another. Recently, however, a new malicious tactic has been gaining traction: in addition to stealing saved data, attackers are embedding phishing dialogs directly into legitimate wallet applications already installed on users’ computers. Earlier this year, the MacSync infostealer adopted this functionality. It infiltrates systems via ClickFix attacks: users searching for software are lured to fake sites with fraudulent instructions to install the app by running commands in Terminal. This executes the infostealer, which scrapes passwords and cookies saved in Chrome, chats from popular messengers, and data from browser-based crypto-wallet extensions.

But the most interesting part is what happens next. If the victim already has a legitimate Trezor or Ledger app installed, the infostealer downloads additional modules and… swaps out fragments of the app with its own trojanized code. The malware then re-signs the modified file so that after these “fixes” are made, Gatekeeper (a built-in protection mechanism in macOS) allows the application to run without an additional permission request from the user. While this trick doesn’t always work, it’s effective for simpler apps built on the popular Electron framework.

The trojanized app prompts the user for the seed phrase of their wallet

When the trojanized app is opened, it fakes an error and initiates a “recovery process”, prompting the user for their wallet seed phrase.

Besides MacSync, the developers behind other popular macOS infostealers have adopted this same trojanization approach. We previously detailed a similar mechanism used to compromise Exodus and Bitcoin-Qt wallets.

How to keep your crypto assets safe

Time and again, attackers have proved that no gadget is truly invincible. With so many developers and cryptocurrency users preferring macOS and iOS, threat actors have designed and deployed industrial-scale attacks for both platforms. Staying safe requires in-depth defense backed by skepticism and vigilance.

• Download apps only from trusted sources: either the developer’s official website or their App Store page. Since malware can slip even into official stores, always verify the app’s publisher.
• Check the app’s rating, publication date, and download counter.
• Read the reviews — especially the negative ones. Sort reviews by date to evaluate the latest version. Attackers often start with a perfectly innocent app that earns high ratings before introducing malicious functionality in a later update.
• Never copy and paste commands into your Terminal unless you’re 100% certain what they do. These attacks have become very popular lately, often disguised as installation steps for AI apps like Claude Code or OpenClaw.
• Use a comprehensive security system on all your computers and smartphones. We recommend Kaspersky Premium. This goes a long way to mitigate the risk of visiting phishing sites or installing malicious apps.
• Never enter your seed phrase into a hardware wallet app, on a website, or in a chat. In every scenario, whether migrating to a new wallet, reinstalling apps, or recovering a wallet, the seed phrase should be entered exclusively on the hardware device itself — never in a mobile or desktop app.
• Always verify the recipient’s address on the hardware wallet’s screen to prevent attacks involving address swapping.
• Store your seed phrases in the most secure way possible, such as on a metal plate or in a sealed envelope in a safe deposit box. It’s best not to store them on a computer at all, but if that’s your only option, use a secure, encrypted vault like Kaspersky Password Manager.

Still believe that Apple devices are bulletproof? Think again as you read the following:

• The iPhone — invincible no more: a look at DarkSword and Coruna
• Predator vs. iPhone: the art of invisible surveillance
• Are your Bluetooth headphones spying on you?
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Banshee: A stealer targeting macOS users

Unit 42 analyzes npm supply chain evolution post-Shai Hulud. Discover wormable malware, CI/CD persistence, multi-stage attacks and more.

The post The npm Threat Landscape: Attack Surface and Mitigations (Updated June 2) appeared first on Unit 42.

Unit 42 research reports that TGR-STA-1030 remains an active threat, particularly in Central and South America.

The post TGR-STA-1030: New Activity in Central and South America appeared first on Unit 42.

aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output text

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
        "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
        "accountId": "111122223333",
        "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROA123456789EXAMPLE",
                "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                "accountId": "111122223333",
                "userName": "YOUR-EC2-INSTANCE-PROFILE"
            },
            "attributes": {
                "creationDate": "2026-03-27T17:08:37Z",
                "mfaAuthenticated": "false"
            },
            "ec2RoleDelivery": "2.0"
        },
        "inScopeOf": {
            "issuerType": "AWS::EC2::Instance",
            "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
        }
    },
    "eventTime": "2026-03-27T17:12:54Z",
    "eventSource": "secretsmanager.amazonaws.com",
    "eventName": "GetSecretValue",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "1.2.3.4",
    "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
    "requestParameters": {
        "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
    },
    "responseElements": null,
    "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
    "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::SecretsManager::Secret",
            "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
        "keyExchange": "X25519MLKEM768"
    }
}

If you have feedback about this post, submit comments in the Comments section below.

Half a million Britons signed up to help cure cancer. Their data ended up for sale on Alibaba.

The UK Biobank charity informed the British government of an incident concerning the medical data belonging to 500,000 British citizens being offered for sale on the Chinese e-commerce website Alibaba.

The National Data Guardian, Dr Nicola Byrne, said in a statement:

“People who generously share their health data to benefit others through medical research rightly expect it to be kept safe and for there to be accountability when things go wrong.”

Officials said the researchers downloaded the data under a legitimate contract, but its appearance on Alibaba shows how “approved” access can still turn into public exposure.

UK Biobank holds more than 15 million biological samples and detailed health records from volunteers recruited between 2006 and 2010, and researchers worldwide use it to study cancer, dementia, diabetes, and other chronic diseases.

UK Biobank normally signs contracts with vetted universities and private companies before it lets them access the data, but investigators traced the Alibaba listings to three research institutions. UK Biobank revoked their access and paused new data access while it strengthens security controls.

At least one listing reportedly contained data on all 500,000 volunteers, and Alibaba and Chinese authorities removed the adverts before anyone could confirm a sale.

The dataset comes from UK Biobank’s long‑running research cohort and includes genetic sequences, blood samples, medical imaging, and detailed lifestyle information used for global health research.

UK Biobank emphasizes that the data was “de‑identified,” meaning it didn’t include names, addresses, or NHS numbers. But it still contained granular demographics, such as gender, age, birth month/year, socioeconomic indicators, lifestyle details, and health measures. We have repeatedly seen that such data can be re‑linked to individuals by cross‑referencing with other public or commercial records.

Why China cares

US intelligence, policy reports, and academic work paint a consistent picture: China treats large, diverse human genomic and health datasets as a strategic resource for both economic and security reasons.

The US National Counterintelligence and Security Center (NCSC) explicitly states that the People’s Republic of China views bulk healthcare and genomic data as a “strategic commodity” to drive its biotech, AI, and precision medicine industries, and has invested billions in national genomics and precision‑medicine initiatives.

Large datasets from non‑Chinese populations are particularly valuable for building AI models and improving the global commercial competitiveness of Chinese pharma and biotech.

From an attacker’s or foreign intelligence perspective, UK Biobank is a “crown jewel” asset: It’s curated, high‑quality, population‑scale, and much more useful than random breach dumps. And because genetic data is immutable (unlike a password, it cannot be replaced), any compromise has very long‑term intelligence usefulness.

Last year, the Guardian reported that one in five successful UK Biobank access applications came from Chinese entities, including BGI, China’s flagship genomics company that was later placed on the US Entity List over concerns about its role in surveillance of minority populations.

China is not just stockpiling DNA for curiosity’s sake. It is building a global genomic map that covers adversaries as well as its own citizens.

Your genome data

There have been major concerns about genetic data ending up in the wrong hands, and for good reason. But I’m not going to say that volunteering your medical data for research is bad. Researchers often put the data to good use to help others.

But there are some good questions to ask before doing so.

• Who runs the project and where is it based?
  Prefer non‑profit or academic biobanks with clear public‑interest mandates and strong oversight, rather than opaque commercial data brokers.
• How do they store the collected data?
  Ask specifically about genomic data, raw sequencing files, links to medical records, and whether data is encrypted at rest and in transit.
• Who can access the data and under what controls?
  Look for a formal access committee, strict contracts, and technical controls like secure analysis environments and limited export options, not “download CSV and walk away” models like the one that enabled the UK Biobank incident.
• Are foreign entities allowed to access or copy the data?
  In light of US and UK government warnings about Chinese access to Western genomic data, it’s reasonable to ask whether data can be accessed, processed, or stored in jurisdictions with different security expectations.
• How do they handle re‑identification risk?
  As we’ve discussed, “de‑identified” is not a magic word. Privacy experts and US intelligence have warned that health and genomic data can often be re‑identified when combined with other datasets.

If data containing your DNA is in someone else’s hands, you can’t put it back, but you can demand better governance, push institutions to treat genomic data as national‑security‑grade sensitive.

It also requires more skepticism of highly targeted scams. Attackers can use large combined datasets to craft convincing spear‑phishing or health‑related scams, for example, contacting you about a specific condition you or a family member has. Treat unsolicited health or DNA‑related emails, calls, and apps with extra suspicion.

Intro

Windows Interprocess Communication (IPC) is one of the most complex technologies within the Windows operating system. At the core of this ecosystem is the Remote Procedure Call (RPC) mechanism, which can function as a standalone communication channel or as the underlying transport layer for more advanced interprocess communication technologies. Because of its complexity and widespread use, RPC has historically been a rich source of security issues. Over the years, researchers have identified numerous vulnerabilities in services that rely on RPC, ranging from local privilege escalation to full remote code execution.

In this research, I present a new vulnerability in the RPC architecture that enables a novel local privilege escalation technique likely in all Windows versions. This technique enables processes with impersonation privileges to elevate their permissions to SYSTEM level. Although this vulnerability differs fundamentally from the “Potato” exploit family, Microsoft has not issued a patch despite proper disclosure.

I will demonstrate five different exploitation paths that show how privileges can be escalated from various local or network service contexts to SYSTEM or high-privileged users. Some techniques rely on coercion, some require user interaction and some take advantage of background services. As this issue stems from an architectural weakness, the number of potential attack vectors is effectively unlimited; any new process or service that depends on RPC could introduce another possible escalation path. For this reason, I also outline a methodology for identifying such opportunities.

Finally, I examine possible detection strategies, as well as defensive approaches that can help mitigate such attacks.

MSRPC

Microsoft RPC (Remote Procedure Call) is a Windows technology that enables communication between two processes. It enables one process to invoke functions that are implemented in another process, even though they are running in different execution contexts.

The figure below illustrates this mechanism.

Let us assume that Host A is running two processes: Process A and Process B. Process B needs to execute a function that resides inside Process A. To enable this type of interaction, Windows provides the Remote Procedure Call (RPC) architecture, which follows a client–server model. In this model, Process A acts as the RPC server, exposing its functionality through an interface, in our example, Interface A. Each RPC interface is uniquely identified by a Universally Unique Identifier (UUID), which is represented as a 128-bit value. This identifier enables the operating system to distinguish one interface from another.

The interface defines a set of functions that can be invoked remotely by the RPC client implemented in Process B. In our example, the interface exposes two functions: Fun1 and Fun2.

To communicate with the server, the RPC client must establish a connection through a communication endpoint. An endpoint represents the access point that enables transport between the client and the server. Because RPC supports multiple transport mechanisms, different endpoint types may exist, depending on the underlying transport.

For example:

• When TCP is used as the transport layer, the endpoint is a TCP port.
• When SMB is used, communication occurs through a named pipe.
• When ALPC is used, the endpoint is an ALPC port.

Each transport mechanism is associated with a specific RPC protocol sequence. For instance:

• ncacn_ip_tcp is used for RPC over TCP.
• ncacn_np is used for RPC over named pipes.
• ncalrpc is used for RPC over ALPC.

In this research, I focus specifically on Advanced Local Procedure Call (ALPC) as the RPC transport mechanism. ALPC is a Windows interprocess communication mechanism that predates MSRPC. Today, RPC can leverage ALPC as an efficient transport layer for communication between processes located on the same machine.

For simplicity, an ALPC port can be thought of as a communication channel similar to a file, where processes can send messages by writing to it, and receive messages by reading from it.

When the client wants to invoke a remote function, for example, Fun1, it must construct an RPC request. This request includes several important pieces of information, such as the interface UUID, the protocol sequence, the endpoint, and the function identifier. In RPC, functions are not referenced by name, but by a numerical identifier called the operation number (OPNUM). Depending on the requirements of the call, the request may also contain additional structures, such as security-related information.

Impersonation in Windows

In Windows, impersonation enables a service to temporarily operate using another user’s security context. For example, a service may need to open a file that belongs to a user while performing a specific operation. By impersonating the calling user, the system allows the service to access that file, even if the service itself would not normally have permission to do so. You can read more about impersonation in James Forshaw’s book Windows Security Internals.

This research focuses specifically on RPC impersonation. Instead of describing the interaction as a service and a user, I refer to the participants as a client and a server. In this model, the RPC server may temporarily adopt the identity of the client that initiated the request.

To perform this operation, the RPC server can call the RpcImpersonateClient API, which causes the server thread to execute under the client’s security context.

However, in some situations, a client may not want the server to be able to impersonate its identity. To control this behavior, Windows introduces the concept of an impersonation level. This defines how much authority the client grants the server to act on its behalf.

These settings are defined as part of the Security Quality of Service (SQOS) parameters, specified using the SECURITY_QUALITY_OF_SERVICE structure.

As you can see, this structure contains the impersonation level field, which determines the extent to which the server can assume the client’s identity.

Impersonation levels range from Anonymous, where the server cannot impersonate the client at all, to Impersonate and Delegate, which allow the server to act fully on behalf of the client.

At the same time, not every server process is allowed to impersonate a client. If any process could perform impersonation freely, it would pose a serious security risk. To prevent this, Windows requires the server process to possess a specific privilege called SeImpersonatePrivilege. Only processes with this privilege can successfully impersonate a client.

This privilege is granted by default to certain service accounts, such as Local Service and Network Service.

Interaction between Group Policy service and TermService

The Group Policy Client service (gpsvc) is a core Windows service responsible for applying and enforcing group policy settings on a system. It runs under the SYSTEM account inside svchost.exe.

When a group policy update is triggered, Windows uses an executable called gpupdate.exe. This tool can be executed with the /force flag to force an immediate refresh of all group policy settings. Internally, this executable communicates with the Group Policy service, which coordinates the update process.

At a certain stage during this operation, the Group Policy service attempts to communicate with TermService (Terminal Service, the Remote Desktop Services service) using RPC.

TermService is responsible for providing remote desktop functionality. This service is not running by default and can be enabled manually by the administrator via activation of Remote Desktop access. When this happens, the service exposes an RPC server with multiple interfaces and endpoints. TermService runs under the NT AUTHORITY\Network Service account.

When the command gpupdate /force is executed, the Group Policy service performs an RPC call to the TermService using the following parameters:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe.
• Endpoint: ncalrpc:[TermSrvApi].
• Function: void Proc8(int).

However, because TermService is disabled by default, the RPC call fails and an exception occurs in rpcrt4.dll (the RPC runtime). The returned error is:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722).

This error indicates that the RPC client could not reach the target server.

Tracing the failure path further reveals that the root cause originates from a call to NtAlpcConnectPort, which is used by RPC to establish an ALPC connection between processes.

The NtAlpcConnectPort function is responsible for connecting to a specific ALPC port and returning a handle that the client can use for further communication. This function accepts multiple parameters.

The first two parameters include:

• A pointer to the returned port handle.
• The ALPC port name, represented as an ASCII string.

Another important argument is PortAttributes, which is an ALPC_PORT_ATTRIBUTES structure. Inside this structure is the SECURITY_QUALITY_OF_SERVICE structure, which, as mentioned above, defines the impersonation level used for the connection.

The final parameter of interest is RequiredServerSid, which specifies the expected identity of the target server process. This identity is represented using a Security Identifier (SID) structure.

Inspecting this call reveals that the Group Policy service attempts to connect to the RPC server using an impersonation level of Impersonate, expecting the remote server to run under the Network Service account. This behavior makes sense because TermService normally runs under Network Service.

Based on all the information above, the following scheme can be created to illustrate the interaction between TermService and gpsvc.

Up to this point, nothing unusual has occurred. An RPC client attempts to connect to an RPC server that is unavailable, resulting in an exception handled by the RPC runtime.

However, an interesting question arises: What if an attacker compromises a service that runs under the Network Service identity and mimics the exact RPC server exposed by TermService?

Could the attacker deploy a fake RPC server with the same endpoint?

If so, would the RPC runtime allow the client to connect to this illegitimate server?

And if the connection is successful, how could an attacker leverage this behavior?

Coercing the Group Policy service

To better understand the implications of the previously described behavior, let us consider the following attack scenario.

Imagine an attacker has compromised a service running on the system under the Network Service account, for example, an IIS server operating under the Network Service account. With this level of access, the attacker can deploy a malicious RPC server.

The attacker’s RPC server is designed to mimic the RPC interface exposed by the Remote Desktop service (TermService). Specifically, it implements the same RPC interface UUID and exposes the same endpoint name: TermSrvApi. Once deployed, the malicious server listens for RPC requests that would normally be directed to the legitimate RDP service.

Next, the attacker coerces the Group Policy service by triggering a policy update using gpupdate.exe /force. This causes the Group Policy Client service, which runs under the SYSTEM account, to perform the previously described RPC call. As observed earlier, this RPC call uses a high impersonation level (Impersonate).

When the attacker’s fake RPC server receives the request, it calls RpcImpersonateClient. This enables the server thread to impersonate the security context of the calling client, which, in this case, is SYSTEM.

As a result, the attacker can elevate privileges from Network Service to SYSTEM. In our proof-of-concept implementation, the exploit demonstrates privilege escalation by spawning a SYSTEM-level command prompt.

When this attack scenario was first discussed, it was purely theoretical. However, after implementing the malicious RPC server, the experiment confirmed that Windows allowed the server to be deployed and started successfully, and that the RPC runtime permitted the client to connect to the malicious endpoint. This made it possible to reliably escalate privileges from Network Service to SYSTEM using this technique. For this attack to succeed, though, at least one group policy must be applied on the system.

RPC architecture flow

Further investigation revealed that many Windows services attempt to communicate with TermService using RPC. These RPC calls often originate from winsta.dll, which acts as the RPC client component.

Windows processes invoke APIs exposed by winsta.dll; these APIs rely internally on RPC communication with TermService. This pattern is common in Windows; many system DLLs use RPC behind the scenes when their exported APIs are called.

However, it appears that the RPC runtime (rpcrt4.dll) does not provide a mechanism to verify the legitimacy of RPC servers. Moreover, Windows allows another process to deploy an RPC server that exposes the same endpoint as a legitimate service.

As a result, this architectural design introduces a large attack surface because RPC is heavily used across numerous system DLLs. Applications that invoke seemingly benign APIs may unintentionally trigger privileged RPC interactions. Under certain conditions, these interactions could be abused to achieve local privilege escalation without the user’s knowledge.

Identifying RPC calls to unavailable servers

As the issue appears to stem from an architectural weakness, a systematic approach is needed to identify RPC clients attempting to communicate with servers that are unavailable. First, I need a platform capable of monitoring RPC activity and extracting relevant information from each RPC request.

Specifically, I need to capture key RPC metadata, including:

• Interface UUID, endpoint, and OPNUM.
• Impersonation level and RPC status code.
• Client process privilege level, process name, and module path.

This information is critical because it enables me to reconstruct the RPC interaction, mimic the expected RPC server, and determine how the call is triggered.

The platform that provides this capability is Event Tracing for Windows (ETW). ETW is a built-in Windows logging framework that captures both kernel-mode and user-mode events in real time.

Windows provides a tool called logman to collect ETW data. It enables us to create trace sessions, select event providers, and configure the verbosity level of the tracing process. The collected tracing data is stored in an .etl file, which can later be analyzed using tools such as Event Viewer or other ETW analysis utilities.

ETW provides deep visibility into RPC activity without requiring modifications to applications. Through ETW, it is possible to capture detailed RPC information, such as:

• RPC bindings
• Endpoints
• Interface UUIDs
• Authentication details
• Call flow and timing
• RPC status codes

However, I’m not interested in every RPC event. My focus is on RPC call failures, specifically those that return the status RPC_S_SERVER_UNAVAILABLE.

For an event to be relevant to this research, the exception must meet two conditions:

• It must originate from a high-privileged process because impersonating such a process may allow an attacker to escalate privileges to a more powerful security context.
• The RPC call must use a high impersonation level, enabling the server to fully impersonate the client once the connection is established.

I cannot rely solely on the raw ETW output to implement this framework because it contains thousands of events, making manual filtering with standard tools inefficient. Therefore, I need to automate this process. The workflow shown below enables me to efficiently filter and extract only those events that are relevant to this analysis.

After generating the logs as an .etl file, I convert them to JSON format using tools such as etw2json. JSON is a much easier format to process programmatically. In this case, I use a Python script to filter and extract the relevant information.

The filtering process begins with a search for Event ID 1, which corresponds to an RPC stop event. This event indicates that the RPC client has completed the call and the result is available. From this event, I can extract useful information, such as:

• Status code
• Client process name
• Client process ID
• Endpoint

After extracting the status code, I filter for the specific value RPC_S_SERVER_UNAVAILABLE, which indicates that the target server was unreachable during an RPC call. These events represent the scenarios that are of interest.

However, Event ID 1 does not contain all of the required RPC metadata. To obtain the missing information, it is correlated with Event ID 5, which represents the RPC start event. This event is generated when the client initiates the RPC call.

By matching the metadata between Event ID 1 and Event ID 5, I can recover the missing details, including:

• Interface UUID
• OPNUM
• Impersonation level

After correlating and filtering these events, a JSON entry is obtained that is almost ready for analysis. At this stage, the data can be enriched further by adding context that will be helpful when reversing or analyzing the RPC server implementation. For example, the following can be identified:

• The DLL where the RPC interface is implemented
• The location of that DLL
• The number of procedures exposed by the interface

To retrieve this information, I match the UUID with an external RPC interface database. In this case, I used the RPC database, which contains a comprehensive list of RPC interfaces and their corresponding DLL implementations.

At the end of this process, a complete JSON dataset is obtained that can be used for further analysis.

One important observation is that the RPC calls I am looking for may only occur when specific system actions are triggered. Additionally, the resulting exceptions may vary from one system to another depending on which services are enabled or disabled. Therefore, I need a reliable way to generate these RPC exceptions.

In this research, I used several approaches to trigger such events:

1. Monitoring RPC activity during system startup
   I observed RPC activity while the system booted. During startup, many services initialize and perform various RPC calls, which increases the chances of capturing calls to unavailable servers.
2. Triggering administrative operations
   I developed PowerShell scripts that perform common administrative tasks, such as updating Group Policy, changing network settings, or creating new users. These operations often trigger RPC communication and may generate exceptions.
3. Disabling services intentionally
   After observing that Remote Desktop was disabled by default, I extended this idea by disabling additional services one by one and repeating the previous steps. This approach can reveal RPC clients that attempt to connect to services that are no longer available.

Additional privilege escalation paths

After running the logging and monitoring framework described earlier, I identified four additional scenarios that can lead to privilege escalation. The following sections introduce each case and explain how escalation can be achieved.

User interaction: From Edge to RDP

Microsoft Edge (msedge.exe) comes preinstalled on Windows systems. During startup, Edge triggers an RPC call to TermService. This RPC call is performed with a high impersonation level.

As previously discussed, Terminal Service is disabled by default. Because of this, the expected RPC server is unavailable, creating an opportunity for the attack scenario illustrated below.

The attack follows the same initial assumption as before: the attacker has already compromised a process running under the Network Service account. From there, they deploy the same malicious RPC server that mimics the legitimate TermService RPC interface.

However, unlike the previous scenario where the attacker coerced the Group Policy service, no coercion is required this time. Instead, the attacker simply waits for a high-privileged user, such as an administrator, to launch msedge.exe.

When Edge starts, it triggers the RPC client to attempt communication with the expected TermService RPC interface. Because the legitimate server is not running, the request is received by the attacker’s fake RPC server. Since the RPC call is made with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client process.

As a result, the attacker is able to impersonate the administrator-level client and escalate privileges from Network Service to Administrator.

Background services: From WDI to RDP

Some background Windows services periodically attempt to make RPC calls to the RDP service without user interaction. One such service is the WdiSystemHost service. The Diagnostic System Host Service (WDI) is a built-in Windows service that runs system diagnostics and performs troubleshooting tasks. This service runs under the SYSTEM account.

During normal operation, WDI periodically performs background RPC calls to the Remote Desktop service (TermService) using a high impersonation level. These RPC interactions occur automatically every 5–15 minutes and do not require any user input.

This behavior can be abused in a similar manner to the previous attack scenarios, as illustrated in the figure below.

In this case, however, no user interaction or coercion is required. After deploying a malicious RPC server that mimics the expected TermService RPC interface, the attacker only needs to wait for the WDI service to perform its periodic RPC call. Because the request is made with a high impersonation level, the malicious server can invoke RpcImpersonateClient and impersonate the calling process. This enables the attacker to escalate privileges to SYSTEM.

Abusing the Local Service account: From ipconfig to DHCP

Another scenario involves the DHCP Client service, which manages DHCP client operations on Windows systems. This service runs under the Local Service account and is enabled by default.

The DHCP Client service exposes an RPC server with multiple interfaces and endpoints. These interfaces are frequently invoked by various system DLLs, often using a high impersonation level.

In this scenario, instead of compromising a process running under Network Service, it is assumed the attacker has compromised a process running under the Local Service account. I also assume that the DHCP Client service is disabled, meaning the legitimate RPC server is unavailable.

As the figure below illustrates, the attacker can leverage this situation to escalate privileges.

After gaining control of a Local Service process, the attacker deploys a malicious RPC server that mimics the legitimate RPC server normally exposed by the DHCP Client service. Once the malicious server is running, the attacker waits for a high-privileged user, such as an administrator, to execute ipconfig.exe.

When ipconfig is run, it internally triggers an RPC request to the DHCP Client service. Since the legitimate RPC server is not running, the request is received by the attacker’s fake RPC server. Because the RPC call is performed with a high impersonation level, the malicious server can call RpcImpersonateClient to impersonate the client.

As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

Abusing Time

The Windows Time service (W32Time) is responsible for maintaining date and time synchronization across systems in a Windows environment. This service is enabled by default and runs under the Local Service account.

The service exposes an RPC server with two endpoints:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

The executable C:\Windows\System32\w32tm.exe interacts with the Windows Time service through RPC. However, before connecting to the valid RPC endpoints exposed by the service, the executable first attempts to access the nonexistent named pipe: \PIPE\W32TIME. This named pipe is not exposed by the legitimate W32Time service. However, if this endpoint were available, w32tm.exe would attempt to connect to it.

An attacker can abuse this behavior by deploying a malicious RPC server that mimics the legitimate RPC interface of the Windows Time service. Rather than exposing the legitimate endpoints, the attacker’s server exposes the nonexistent endpoint \PIPE\W32TIME, as shown in the figure below.

As in the previous scenarios, it is assumed the attacker has already compromised a process running under the Local Service account. The attacker then deploys a fake RPC server that implements the same RPC interface as the Windows Time service, but which exposes the alternative endpoint used by w32tm.exe.

Once the malicious server is running, the attacker simply waits for a high-privileged user, such as an administrator, to execute w32tm.exe. When the executable runs, it attempts to connect to the endpoint \PIPE\W32TIME. Because the attacker’s fake server exposes this endpoint, the RPC request is directed to the malicious server.

Since the RPC call is performed with a high impersonation level, the malicious server can impersonate the calling client. As a result, the attacker can escalate privileges from the Local Service account to the Administrator account.

In this scenario, it is important to note that the legitimate Windows Time service does not need to be disabled. Because the executable attempts to connect to a nonexistent endpoint, it is sufficient for the attacker to expose that endpoint through the malicious RPC server.

Vulnerability disclosure

After discovering the vulnerability, Kaspersky Security Services prepared a 10-page technical report describing the issue and the various aforementioned exploitation scenarios. The report was submitted to the Microsoft Security Response Center (MSRC) to report the vulnerability and request a fix.

Twenty days later, Microsoft responded, indicating that they did not classify the vulnerability as high severity. According to their assessment, the issue was classified as moderate severity and would therefore not be patched immediately. No CVE would be assigned, and the case would be closed without further tracking.

Microsoft explained that the moderate severity classification was due to the requirement that the originating process had to already possess the SeImpersonatePrivilege privilege. Since this privilege was typically required for the attack to succeed, Microsoft determined that the issue did not require immediate remediation.

Kaspersky Security Services respect Microsoft’s assessment and only published the research after the embargo period ends. In line with the coordinated vulnerability disclosure policy, Kaspersky Security Services will refrain from publishing detailed instructions that could enable or accelerate mass exploitation.

The disclosure timeline is shown below:

• 2025-09-19: Vulnerability reported to Microsoft Security Response Center (Case 101749).
• 2025-10-10: MSRC response – the case was assessed as moderate severity, not eligible for a bounty, no CVE was issued, and the case was closed without further tracking.
• 2026-04-24: expected whitepaper publication date.

Detection and defense

As discussed above, this vulnerability is related to an architectural design behavior. Fully preventing it would require Microsoft to release a patch that addresses the underlying issue.

Nevertheless, organizations can still take steps to detect and mitigate potential abuse. ETW-based monitoring within the framework described above enables defenders to identify RPC exceptions in their environment, especially when RPC clients attempt to connect to unavailable servers.

I have provide the tools used in the previously described framework so that organizations can check their environment for such behavior. You can find all of them in the research repository.

By monitoring these events, administrators can identify situations where legitimate RPC servers are expected but not running. In some cases, the attack surface may be reduced by enabling the corresponding services, ensuring that the legitimate RPC server is available. This can hinder attackers from deploying malicious RPC servers that imitate legitimate endpoints.

It is also good practice to reduce the use of the SeImpersonatePrivilege privilege in processes where it is not required. Some system processes need this privilege for normal operations. However, granting it to custom processes is generally not considered good security practice.

Conclusion

All the exploits described in this research were tested on Windows Server 2022 and Windows Server 2025 with the latest available updates prior to the submission date. The proof-of-concept implementations can be found in the research repository. However, it is highly likely that this issue may also be exploitable on other Windows versions.

Because the vulnerability stems from an architectural design issue, there may be additional attack scenarios beyond those presented in this research. The exact exploitation paths may vary from one system to another depending on factors such as installed software, the DLLs involved in RPC communication, and the availability of corresponding RPC servers.

Key Takeaways

• The real challenge in cybersecurity isn’t intelligence or visibility, it’s speed. Attackers operate at machine speed, while most organizations are still constrained by manual, human-driven workflows.
• Traditional threat intelligence falls short because it stops at insight. To reduce risk effectively, intelligence must not only inform decisions but also actively drive response.
• Fragmentation across cyber, fraud, and third-party risk creates exploitable gaps. A unified, intelligence-driven approach is essential to understanding and addressing modern threats holistically.
• Autonomous defense is the path forward. By enabling continuous, real-time action across the attack surface, organizations can close the speed gap and move from reactive security to proactive risk reduction.

For most security teams today, volume and access to intelligence isn’t the problem. It’s the speed at which they can turn that intelligence into action.

Over the last decade, organizations have invested heavily in threat intelligence and cybersecurity. Global security spending has surged past $200 billion annually, growing double digits year over year, while security’s share of IT budgets has climbed from under 9% to more than 13%. Most CISOs report continued budget increases, and enterprises are making billion-dollar investments in intelligence capabilities.

And yet, breaches still happen. Fraud still slips through. Third-party risk still catches teams off guard. The issue isn’t visibility. It’s the growing gap between how fast threats move and how fast organizations can respond.

Attackers now operate at machine speed, leveraging automation and AI to identify vulnerabilities, launch campaigns, and exploit opportunities in real time. Most security teams, however, are still constrained by manual workflows, fragmented systems, and processes that require human intervention at every step. That mismatch is where risk can accumulate—and where even well-resourced teams fall behind.

The Hidden Cost of Human-Speed Security

For many organizations, this gap shows up in subtle but compounding ways. Analysts spend hours triaging alerts, trying to determine which signals actually matter. Security teams often discover incidents after damage has already occurred, not because the data wasn’t there, but because it couldn’t be acted on quickly enough. Across the organization, teams responsible for cyber operations, fraud, and third-party risk operate in silos, each with their own tools and workflows, rarely sharing a unified view of risk.

At the same time, expectations from leadership have shifted. Executives and boards no longer want activity metrics—they want clear evidence that security investments are reducing business risk. But when intelligence is not clearly connected to action from security teams, that proof becomes difficult to deliver.

Traditional threat intelligence was designed to inform decisions made by humans, at human speed. In today’s environment, that model introduces delay. And delay, in cybersecurity, is increasingly indistinguishable from exposure.

Intelligence That Acts, Not Just Informs

Closing the speed gap requires more than incremental improvements. It requires a shift in how organizations think about intelligence altogether. Moving forward, the future of cybersecurity must be more than just intelligence-led—it must be intelligence-acted.

In this model, intelligence doesn’t sit in dashboards waiting for analysts to interpret it. It continuously correlates signals, prioritizes what matters, and drives action across the security environment automatically. Instead of asking teams to move faster, it enables the entire system to operate at the speed of the threat.

This is the foundation of autonomous defense, and it’s the future of effective, machine-speed cybersecurity.

From Reactive to Autonomous: A New Operating Model

Autonomous defense fundamentally changes the role of the security team. Rather than serving as the bottleneck between detection and response, analysts become decision-makers operating on top of continuously running intelligence.

Recorded Future’s Autonomous Threat Operations brings this model to life by eliminating the manual steps that slow teams down. It ingests and correlates intelligence from multiple sources, applies context in real time, and triggers actions across existing security tools—all without requiring constant human input.

The impact of such a dramatic shift is immediate and measurable. Threat hunting becomes continuous instead of periodic. Alerts arrive enriched with context, reducing the time needed to investigate and respond. Detection and remediation workflows execute automatically, freeing analysts to focus on strategic threats rather than routine triage.

Just as importantly, this approach transforms how organizations measure success. Instead of tracking activity—alerts processed, queries written, incidents reviewed—teams can demonstrate real outcomes: faster response times, reduced exposure, and a clearer connection between intelligence and risk reduction; the latter of which is becoming increasingly necessary for organizational buy-in.

This is so much more than just adding another tool to the stack. Instead, it’s about making every existing control smarter, faster, and more effective. And it’s paying off. On average, security teams using Recorded Future save up to 100 hours per week through improved analyst productivity, allowing teams to redirect effort toward threat hunting and proactive defense instead of repetitive manual analysis.

The Bigger Challenge: Fragmented Visibility Across the Attack Surface

Speed alone, however, is only part of the equation. Many organizations are also limited by how they view risk. Threats today don’t respect organizational boundaries. A phishing campaign can lead to credential theft, which can then be used to access systems, exploit third-party relationships, or enable fraudulent transactions. These events are connected, but still far too many organizations manage them in isolation.

Cyber operations teams focus on internal threats. Fraud teams monitor transactions. Risk teams assess vendors. Each group has visibility into part of the problem, but no one has a complete picture. This fragmentation creates blind spots, and attackers are increasingly skilled at navigating between them.

A Unified Approach to Risk

To effectively reduce risk, organizations need more than faster response times. They need a connected understanding of their entire attack surface, along with the ability to act across it in a coordinated way.

Recorded Future addresses this through four core solution areas—Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud Intelligence—all built on a single, integrated intelligence foundation.

In cyber operations, this means moving beyond alert overload to real-time prioritization. Instead of forcing analysts to sift through volumes of data, intelligence surfaces the threats that are most relevant to the organization’s environment and enables immediate action. The combination of prioritization and automation allows teams to reduce noise while improving both detection speed and response quality.

In digital risk protection, the focus shifts beyond the traditional perimeter. Today’s attackers target brands, customers, and executives just as frequently as they target infrastructure. By monitoring the open, deep, and dark web, Recorded Future provides visibility into impersonation campaigns, credential exposure, and emerging threats long before they impact the organization. More importantly, it enables rapid response, whether that means taking down fraudulent domains or preventing account takeover attempts.

Third-party risk represents another growing challenge. As organizations expand their ecosystems, they inherit risk from vendors and partners, often without real-time visibility. Third-party involvement in breaches has reached a staggering 30%, up from just 15% a year ago. Static assessments and periodic reviews can’t keep pace with how quickly vendor risk evolves today. Continuous monitoring, grounded in real-world intelligence, allows organizations to detect issues earlier, respond faster, and maintain a more accurate understanding of their exposure.

In the realm of payment fraud intelligence, the shift is equally significant. There were some 269 million records posted across dark and clear web platforms in 2024, and a tripling of certain e-skimmer infections. It’s important to keep in mind that fraud doesn’t begin at the moment of transaction. Rather, it begins much earlier, in the environments where stolen data is exchanged and tested. Recorded Future provides comprehensive coverage across the complete payment fraud lifecycle. Sophisticated cleanup and normalization techniques result in better data quality and richer data sets, reducing manual research and enabling high confidence mitigation actions. By identifying these signals upstream and intervening, organizations can stop fraud before it’s executed, reducing both financial loss and customer impact.

One Intelligence Foundation. Total Visibility.

What makes this approach fundamentally different is that these capabilities are not delivered as isolated solutions. They are unified through the Recorded Future Intelligence Platform, which correlates data across millions of sources and billions of entities to provide a single, coherent view of risk.

This unified foundation enables organizations to connect signals that would otherwise remain siloed. Threat actors, infrastructure, vulnerabilities, and campaigns are all linked, allowing teams to understand not just what is happening, but what is likely to happen next.

That level of visibility is what makes autonomous defense possible. And not just within a single domain, but across the entire attack surface.

The urgency behind this shift cannot be overstated. Attackers are already operating at machine speed, using automation to scale their efforts and reduce the time between discovery and exploitation. At the same time, organizations that rely on manual processes are finding it increasingly difficult to keep up.

The consequences of this gap are significant. Longer dwell times allow attackers to entrench themselves more deeply. Delayed responses increase the cost and impact of incidents. And as breaches and fraud events become more visible, customer trust becomes harder to maintain.

This is no longer a question of optimization. It’s a question of whether existing operating models can keep pace with the reality of modern threats.

Rethinking What Threat Intelligence Should Do

As organizations evaluate their approach to cybersecurity, the role of threat intelligence needs to be reconsidered. It is no longer enough for intelligence to provide visibility. It must enable action. It must operate in real time. And it must extend across the full scope of organizational risk—not just one domain at a time.

Equally important, it must deliver outcomes that matter to the business. Faster detection, reduced exposure, and measurable risk reduction are no longer aspirational. They are essential for enterprise security in the modern, AI-powered threat landscape.

The goal for most organizations isn’t to replace their security stack. It’s to make it work better. By enabling intelligence to act autonomously, connecting visibility across domains, and aligning security operations with the speed of modern threats, organizations can close the gap that has long existed between insight and action. Recorded Future is built to make that possible.

If your team is still struggling with alert fatigue, delayed responses, or fragmented visibility, the issue may not be a lack of resources. It may be a limitation in how intelligence is being applied.

Now is the time to rethink that model.

Connect with Recorded Future to see how autonomous defense can help your organization move at the speed of today’s threats—and stay ahead of what comes next.

Contact us

What are the next steps for security leaders in this new age of frontier AI? We answer the top 10 questions customers are asking.

The post Frontier AI and the Future of Defense: Your Top Questions Answered appeared first on Unit 42.