Cloud-native tradecraft used to be the signature of a handful of highly capable groups. That’s changing. Artificial Intelligence (AI) cyber-attacks are letting far less specialized actors navigate an unfamiliar environment and adapt at machine speed, and it’s showing up in MOXFIVE’s incident response caseload as a distinct, repeatable pattern: containment succeeds until attackers find a new way in.
A few things distinguish this wave of incidents from the cloud intrusions we've handled in years past:
Across a growing set of engagements, the initial event is theft of source code from a code repository (e.g., GitHub). What used to be the whole incident, is now the Threat Actor's first initiative in a longer campaign.
AI enables two points of failure to converge here, and together they’re what turns a contained incident into a series of incidents that ultimately interrupt business operations.
The first isn’t new: exfiltrated repositories routinely contain hardcoded API keys, service account credentials, and access tokens. Once a repository is stolen, every one of those credentials is a live key until someone finds and rotates it. Attackers don’t have to guess. They use tools like Trufflehog to scan files for secrets far faster than mass secrets rotation can complete.
The second is new, and it’s the part being underestimated. Threat actors are using large language models to read stolen source code the way a penetration tester would, at a scale and speed no human team matches. The models aren’t hunting for secrets, they’re hunting for logic flaws, unvalidated inputs, and misconfigured services baked into the application itself. Attackers are then directly targeting specific applications, on systems they had no prior foothold on, in ways that suggest they already knew what was there.
“You should assume that anyone who exfiltrates your source repositories is not just walking away with secrets. Prepare for a penetration test run by someone who genuinely knows your environment.”
— Luke Moran, Associate Director, MOXFIVE
What those two failure modes produce, in the same engagement, are two different problems, and they don’t respond to the same fix.
This is technical persistence: more advanced than these case types typically carry: implanted credentials, modified identity trust, and hooks back into the environment through paths that have nothing to do with the original access.
This is persistent behavior: close one access vector and the next is live within hours. On one recent engagement, that meant a new vector every other day for weeks, none of them connected to the previous, because the attacker was working from a map of the environment the response team didn’t control and couldn’t revoke.
"We are seeing advanced persistence mechanisms that we do not typically encounter coupled with a threat actor who is relentless in getting back into the environment through new vectors and has the means to do it. Believing a cloud-based attack is contained because initial access was contained is increasingly untenable.”
— Ryan Ikeler, President, MOXFIVE
An eradication that’s technically correct, complete, and well evidenced based on the Threat Actor’s observed actions and initial vector is becoming less effective. The Threat Actor, working from a model-assisted read of the stolen codebase and environment details, can now quickly identify new vectors on the fly, based on personalized vulnerabilities in the organization’s own applications and environment architecture. That’s what makes a “contained incident” stretch into a multi-week outage, further pushing back confidence in resumption of normal operations.
These are timing questions, and the honest answer needs to be a number, not a guess:
If the answer to any of these is "we don't know," that's the finding. It means your containment timeline is currently set by how patient the attacker feels like being, not by you.
This is a visibility gap that exists before any incident happens, not a response-capability gap, which is exactly why it’s worth closing proactively rather than discovering it under pressure. A continued understanding of your machine identities and their reach across your cloud footprint, where secrets sit in logs and datasets, and which of these attack patterns actually apply to your environment is what compresses the response window when an incident does happen, instead of starting that work from zero.
Your existing security tools still earn their place. However, AI-assisted defense is only as effective as what it can see, and the gaps where logs aren’t generated or reviewed are gaps that AI-assisted attackers are routinely finding. Your tools probably won’t stop an attack moving this fast, but they’re what gives an investigation something to work with. The practical goal is visibility broad enough to reconstruct what happened, which is an argument for choosing tools that genuinely fit each part of your environment over standardizing on a single vendor. Still defense in depth, just spread wider so the story stays recoverable.
Want to talk through which of these patterns apply to your environment? Contact us at 833-568-6695 or proactive@moxfive.com for a MOXFIVE readiness assessment.
MOXFIVE provides the clarity and peace of mind needed for attack victims during the incident response process. Our platform approach enables victims of attacks to work with a Technical Advisor who provides the expertise and guidance needed in a time of crisis, and facilitates the delivery of all technical needs required, consistently and efficiently.
Learn More
With experience on the front lines responding to incidents daily, MOXFIVE Technical Advisors have the unique ability to connect the dots between business, information technology, and security objectives to help you quickly identify the gaps and build a more resilient environment.
