When AI Turns Stolen Credentials into an Intrusion

At 08.17, a security analyst sees a familiar company domain inside an unfamiliar infostealer record. The entry contains a former contractor's email address and the URL of a supplier portal. The password might be stale. The portal is still online.

It begins with an ordinary problem because ordinary problems increasingly supply the raw material for AI-assisted intrusions. An exposed identity, a forgotten application and a permissive account can become more dangerous when an attacker can quickly work out how they fit together. Understanding those connections is where external attack surface management, cyber threat intelligence and controlled security testing earn their place.

At first, the record appears unremarkable. Security teams see recycled credential lists constantly. The contractor's main company account was disabled months ago, and the project ended before that. But the supplier portal uses a separate account directory. Its application owner has changed twice. Nobody has yet established whether the local account was disabled or what it could still access.

The attacker faces a similar uncertainty. A stolen password is only useful if it leads somewhere. Historically, resolving that uncertainty took time and familiarity with the target's systems. AI can reduce the effort required to interpret unfamiliar material, identify relationships and support the next stage of an operation. It cannot make an expired token valid, and it cannot bypass an effective authorization control merely by describing one. It can help an operator spend less time understanding an environment whose controls are already weak.

The material available to that operator is more varied than a list of email addresses and passwords. A breach dump may contain records taken from one service. A combolist may combine credentials from unrelated incidents, with duplicates and little reliable provenance. An infostealer record may preserve the URL associated with a credential, alongside browser artifacts and information about the infected device. Depending on the malware and environment, stolen material can also include cookies, tokens or other secrets.

Those categories should not receive the same interpretation. A password hash is not a plaintext password. A session cookie is not automatically reusable on another machine. Token expiry, device binding, conditional access and application-specific controls can all limit what an attacker can do. An employee address found in a stolen dataset does not, on its own, establish that the employer's network was compromised. The source could be a personal device, a supplier or an unrelated service where the address was used.

Distribution is equally fragmented. Material circulates through criminal forums and marketplaces, but also through messaging channels, paste sites and exposed repositories. Telegram is a communications platform, not a synonym for the dark web. Deep-web content includes ordinary authenticated services that search engines do not index. For defenders, the useful question is which accessible sources contain relevant evidence, how trustworthy that evidence is, and what action it supports.

The age of a record is particularly easy to misread. The day a collector first sees it may be months after the original theft. A newly advertised collection may largely consist of old material. Yet an old record can remain operationally valuable if the underlying access was never revoked.

Mandiant documented that problem in its 2024 investigation of UNC5537 attacks against Snowflake customer environments. The incidents it investigated were traced to compromised customer credentials, often obtained through earlier infostealer infections. Some dated back to 2020. Affected accounts lacked MFA, and credentials could remain valid for years. Mandiant found no evidence that those incidents resulted from a compromise of Snowflake's enterprise environment. This was a credential-abuse campaign, and the report did not establish AI involvement. It demonstrates the unresolved access that later AI-assisted operations can encounter.

More recent investigations show where AI enters the process. In February 2026, Amazon Threat Intelligence reported an AI-augmented actor compromising more than 600 FortiGate devices across more than 55 countries between 11 January and 18 February 2026. Amazon observed exposed management interfaces and weak or reused credentials protected by single-factor authentication. It did not observe exploitation of FortiGate vulnerabilities. After access, AI-assisted tooling helped process stolen device configurations containing credentials and network information. Amazon also described failures against better-defended environments. The report did not establish that the initial passwords came from a particular breach marketplace.

This case gives the analyst in our story a useful way to think about the exposed portal. A reachable service and an identity weakness can matter even when there is no newly announced software exploit. AI may make an operation easier to scale while leaving its dependence on basic security failures intact.

Google Threat Intelligence Group's September 2026 report described another acceleration. In an observed Q2 incident, an attacker first compromised cloud infrastructure, then planned, built and executed an agent-enabled mass credential-harvesting operation in less than six hours. That timing begins after the initial cloud compromise. It is not evidence that an AI system independently broke into an unknown organization from a standing start. It does show how quickly a foothold can become infrastructure for further credential theft.

Anthropic's September 2026 threat report connects these developments more directly to malicious use of AI security-testing workflows. It described suspected ShinyHunters affiliates using compromised credentials and AI-assisted reconnaissance, exploitation and data theft. In one reported compromise, a stolen developer token preceded full cloud administrative control in roughly three hours. The provider also observed attackers stealing customer-held AI API keys and using them to support further activity. Attribution was qualified, and humans retained important decisions, including target selection and monetization. These are observations from particular investigations, rather than a universal timetable for AI attacks.

A language model connected to tools can review results, propose further work and help an operator adapt when a command fails. Authorization determines whether that work belongs to a legitimate assessment or a criminal intrusion. Commercial models, open-weight models and purpose-built wrappers can appear in either context. There is no need to assume that every attacker possesses a fully autonomous system, or that using an AI tool makes every attempted exploit effective.

The more consequential change may happen after access is obtained. A stolen mailbox contains information about how a company makes decisions. An attacker who understands the correspondence can identify whose instructions colleagues trust and which payment discussions are still active.

Microsoft's September 2026 EvilTokens investigation documented this use of AI. The service, marketed through Telegram, used device-code phishing to obtain account access, then applied AI to compromised inboxes to identify business relationships and opportunities for fraud. Microsoft linked it to more than 12,000 compromised inboxes across over 10,000 organizations. Victims could complete a legitimate authentication process while authorizing the attacker's session, without revealing a password. This was a token-based access path, not simply the reuse of leaked passwords. AI helped interpret the business information available after compromise.

Together, these cases suggest that the defensive priority is to reduce the time between recognizing a dangerous connection and removing it. Waiting for proof of AI involvement adds little when an exposed administrative service or compromised identity already needs attention.

Back at the supplier portal, the analyst starts by checking ownership. A domain name that resembles the company is not sufficient evidence that the company controls the service. Certificates, DNS records, hosting relationships and application content can help, but shared infrastructure can produce misleading associations. A cloud address may host many unrelated customers. Asset attribution needs confirmation from the business and the service provider.

External attack surface management, or EASM, makes this investigation repeatable. It helps teams discover and track the internet-facing assets associated with an organization, including services that central inventories have missed. The useful output connects an asset to its owner and operating purpose. A portal used by suppliers needs a different exposure decision from an administrative console that should only be reachable through a protected management route.

Discoverability is only the beginning. A login page can be public by design. A reported software version may be incomplete or misleading. An open port establishes reachability under the observed conditions, not successful exploitation. The security team needs to know what is exposed, whether it should be exposed, and which evidence would justify corrective work.

Darkivore supports that external view through asset discovery, reconnaissance and exposure monitoring. Its intelligence categories include domains and subdomains, login and administrative pages, open services, technologies and vulnerability-related findings. Monitoring certificate and email-security configuration information adds context about the organization's public presence. These observations give analysts a starting point for investigating the portal without assuming that every reachable asset is compromised.

Cyber threat intelligence, or CTI, adds evidence about what is happening beyond the organization's systems. Darkivore collects and organizes relevant findings from surface, deep and dark-web sources, including monitored messaging communities. Its coverage includes compromised accounts and infostealer records, exposed authentication keys, source code and configuration files. Analysts can examine related malicious infrastructure, campaign information and other indicators to judge the relevance of an observation.

The practical value comes from the investigation these findings enable. In our example, the team connects a leaked identity to a current application and asks whether the account still exists. It checks the evidence's timestamp and provenance, the former contractor's role and the portal's authentication arrangements. This correlation requires analyst judgment and customer context. It should not be treated as proof that every observed identity has a working path into the business.

A sound case record distinguishes the observed facts from the hypotheses. The leaked record was observed. The portal is reachable. The local account remains active, as confirmed by the application owner. Whether the exposed password still works has not been established. Keeping those statements separate allows the team to act on a clear account-management failure without unnecessarily replaying stolen credentials against production.

The team also checks for signs of an existing compromise. External intelligence can identify exposure, but authentication logs, endpoint telemetry and application audit trails help determine whether access was used. A recent stealer infection may require investigation of the originating device. If that device belongs to a contractor, the response may need to involve another organization. The finding remains relevant even when the affected endpoint falls outside the company's managed fleet.

Identity response must match the kind of access at risk. Changing a password may be appropriate, but it is not a complete response to every stolen-session incident. Microsoft's token-theft playbook includes token revocation, investigation of affected devices and removal of attacker-added access. An organization also has to consider sessions maintained by downstream applications and the time those applications take to enforce changes. Recovery should be verified through the controls and logs of the systems involved.

The analyst now has a containment task and a separate testing question. The obsolete contractor account can be disabled through the authorized identity process. But does the supplier portal enforce the right boundaries for accounts that are supposed to exist?

This is where Potech's Red Agent can contribute. Our AI-powered penetration-testing platform supports authorized assessment of web applications and APIs, including technical vulnerabilities, business-logic weaknesses and data-access issues. It provides testing modes suited to different levels of available information and access, with verification and retesting as part of the workflow. For this investigation, the scope should focus on the portal and the actions an approved supplier account is meant to perform.

The application owner provides controlled test identities representing different supplier roles. The team uses synthetic records whose ownership is known. The question is whether each identity can access only the records and operations allowed by its role. Authentication may correctly identify the supplier while an authorization defect still permits access to another supplier's information. An assessment that stops after confirming a successful login would miss that business consequence.

In our illustrative scenario, validation finds that a low-privilege test account can retrieve a synthetic record assigned to another supplier. No real customer data is needed to establish the failure. The evidence records the affected operation, the test identity's privileges and the expected access rule. The application team can reproduce the issue and understand why it needs correction.

This example also explains how breached-data intelligence should inform testing. The leaked record directs attention to an application and an account-lifecycle problem. Authorized test identities establish whether a separate application weakness exists. The process does not require placing a live stolen password into a general-purpose model or permitting an automated tester to attempt unrestricted logins.

Red Agent's role in this workflow is bounded by the agreed web and API scope. Discovering an exposed VPN appliance, industrial controller or internal directory relationship does not mean the same assessment covers those systems. Such findings may need device-specific reviews or other specialist testing. The engagement should state which targets and actions are supported, where testing must stop, and what evidence is sufficient to confirm a result.

Prioritization then becomes more useful than sorting a spreadsheet by a single severity score. The portal contains commercially sensitive information, accepts external identities and has a verified access-control failure. Those facts justify attention even if the flaw has no published CVE. Elsewhere, a known software vulnerability may demand urgent action because exploitation has been observed and the affected service is exposed.

FIRST's Exploit Prediction Scoring System estimates the probability that a published vulnerability will be exploited in the wild during the next 30 days. That can inform prioritization, but it is not the probability that a particular company will be breached. Asset reachability, installed configuration, permissions and business impact still have to be assessed. Credential exposure and custom application logic also require evidence that a CVE-based score cannot supply.

The relationship between Darkivore and Red Agent is therefore operational. External findings help the team select and scope a relevant assessment. Testing produces evidence that helps the application owner fix a weakness. Darkivore's APIs and ticket-related capabilities can support movement of findings into existing security processes, but integrations require configuration and ownership. A feed arriving in a SIEM does not by itself disable an account, change an application or complete a remediation task.

For the security operations team, this means attaching the finding to the information needed to act. The record should identify the asset, evidence source, observation time and confidence, together with the responsible owner. Sensitive credential material should have restricted handling. Routine tickets can carry redacted identifiers and secure evidence references, rather than distributing usable secrets to everyone who can read the queue.

Phishing and impersonation create another opportunity to intervene. AI can use exposed business context to make a message more relevant to its recipient. Darkivore's domain, brand and impersonation monitoring, supported by investigation and takedown services, can help teams identify and respond to associated external infrastructure. Removing a phishing site can interrupt access to that site. It cannot revoke tokens already stolen or erase every copy of leaked information. Identity containment and investigation still have to follow.

The testing system itself also needs protection. NIST's research on agent hijacking examines how malicious instructions in external content can redirect an AI agent. A security tool necessarily reads material from potentially hostile environments. A page under assessment, an uploaded document or a purported breach record may contain text intended to manipulate the system interpreting it.

For any AI-assisted security workflow, we would require a boundary between external evidence and execution authority. A retrieved page must not be allowed to expand the target scope or authorize access to a secrets store. Target restrictions, permission checks and controls on data leaving the environment should be enforced outside the model. Audit records should make it possible to inspect what was proposed, what was executed and why. High-impact actions need an appropriate approval point, and testing needs a reliable stop mechanism.

These are requirements for the deployment and assessment design, not a reason to abandon automation. They make automation useful in an environment where the inputs can be malicious and the consequences of an incorrect action can be expensive. Evidence-based validation also requires acknowledging blocked or inconclusive tests. A clean report cannot establish coverage of functions that the assessment never reached.

AI adoption within the customer introduces additional assets to review. A model API key, an agent connector or a service account used by an assistant can carry production privileges. A retrieval system may expose sensitive documents if its access checks fail to preserve the user's permissions. These systems belong in the organization's inventory and security reviews. Monitoring for leaked keys helps identify external evidence, while configuration review and authorized testing establish what those keys and integrations can actually do.

The team returns to the supplier portal after remediation. The obsolete local account has been disabled, and relevant sessions have been revoked through the application's supported process. The application owner has corrected the authorization failure. A repeat test using the same synthetic records now demonstrates that the supplier roles remain separated. The team also reviews similar portals for the same account-lifecycle weakness, rather than assuming the finding was unique.

The record can now be closed with evidence. It shows what was found, what was confirmed and which access conditions changed. The team has not proved that a particular criminal intended to exploit the portal, or that a measured financial loss was prevented. It has established that an unnecessary account and a demonstrated access-control failure have been addressed.

This is how we judge the practical contribution of Darkivore and Red Agent. External intelligence should bring relevant exposure to the team's attention. Controlled testing should help establish the weaknesses that need action. The customer must be able to see whether remediation changed the condition that created the risk.

For a security leader, useful measures include the age of confirmed exposed credentials awaiting action, the time taken to assign an owner to an unknown asset, and the interval between a verified finding and a successful retest. These measures reveal whether the organization is shortening the opportunities an attacker can exploit. The volume of collected data or completed scans cannot answer that question on its own.

At the start of the story, the analyst had one old record and an unanswered question. By the end, the organization knew who owned the portal, which identity should have lost access, and how the application enforced supplier boundaries. That is the work AI-assisted attackers are trying to complete for their own purposes. Defenders need to resolve the same relationships early enough to change the outcome, with authority to act and evidence that the action worked.