Update September 1, 2026: Added a fourth case following the August 2026 charges against two alleged TeamPCP operators, and a closing section on what these failures do and do not give defenders.
--
A ransomware crew launched an affiliate program with its own management systems reachable from the internet. A group claiming a breach had actually been rummaging through a honeypot. A developer working on state cyber operations had a commodity infostealer running on his own machine.
Threat actors invest in tooling, infrastructure and evasion, and they work to look disciplined. The reporting below suggests the investment is uneven.
Four documented OPSEC failures follow. The first three were reported by researchers in December 2025, the fourth in August 2026. I have grouped them by what broke: process, behavior, technical isolation, and identity.
Devman: Procedural OPSEC failures in ransomware operations
In a previous article, I covered the technical details of the Devman ransomware, including how it worked and what it reused from existing ransomware code.
After the launch, Devman drew public criticism on X for what researchers described as “poor OPSEC.” Ctrl Alt Intel's write-up documented a group exposing its own infrastructure while rolling out a ransomware-as-a-service offering.
The reported issues:
- Internal infrastructure exposed during launch: systems used to manage the operation, internal services included, were reachable from the internet.
- Management and communication systems left weakly protected, which let researchers observe how parts of the operation were coordinated.
- Tooling reused without hardening: the operation ran on existing components that had not been tested from an OPSEC perspective.
The launch went live before any of that was isolated. For a group recruiting affiliates, the result was a public reputation for running an immature operation.
Scattered Lapsu$ Hunters: behavioral OPSEC failures in target verification
Actors associated with SLSH publicly claimed a breach of a cybersecurity company, released screenshots, and said sensitive data had been stolen.
Follow‑up reporting established that the systems they reached were not production. They held synthetic data, the deception technique Resecurity documents here, built to survive a casual look.
The failures:
- No validation of the target environment: accessible systems were assumed real, with no check on whether they were isolated or monitored.
- Synthetic data accepted as proof of compromise, because it read as legitimate.
- Repeated scraping and access attempts caused proxy failures that leaked technical detail useful for tracking.
The claim went public before it was confirmed, and the group's credibility went with it when the claim was disproven.
North Korean operator: technical OPSEC failures in system isolation
A machine used by a developer involved in North Korean cyber operations was itself infected with LummaC2, a commodity information-stealing malware. Log analysis exposed credentials and tooling on the device, and investigators linked it to infrastructure associated with the Bybit cryptocurrency theft, attributed to North Korean actors including the Lazarus Group. The reporting here is secondary rather than a primary advisory, so treat the specifics with the caution that deserves.
The reported failures:
- Poor endpoint hygiene: an attacker-controlled system was compromised by a commodity infostealer.
- No isolation: tooling, phishing domains and operational assets sat on one machine, and credentials stored there tied back to known malicious infrastructure.
- Incomplete anonymization: VPN use did not mask browser configuration, language settings or usage patterns.
In May 2025, developers behind the DanaBot malware accidentally infected their own machines, and investigators later used the recovered credential data.
Both cases show how attackers can fall victim to the same threats they deploy.
TeamPCP: identity OPSEC failures in persona management
The poisoned Trivy and LiteLLM releases I covered in July are attributed to TeamPCP by the FBI's July 2 FLASH advisory. On August 27, 2026, the Australian Federal Police charged two Western Australian men following a joint AFP, FBI and WA Police operation. Those charges are allegations and have not been tested in court.
Flare's Emerging Threats Team published a deanonymization walkthrough the same day, and Brian Krebs reported the charges separately. The starting point is the useful part, not the outcome.
Flare began with a single alias used in earlier TeamPCP operations, distinctive enough to search on directly. It resolved to a bug bounty profile carrying a real name, and to a machine learning community profile that publicly listed a domain later used as command-and-control infrastructure for the Mini-Shai-Hulud worm. From there the chain ran through leaked credentials: a school email address, a password exposed in a public dump, then a personal email account recovered by pivoting on that password. One account registered against it carried the same picture fronting the group's Telegram channel.
The failures:
- One distinctive alias across operational and personal accounts, appearing in both TeamPCP tooling and a profile carrying a real name.
- Operational infrastructure listed on a personal profile: per Flare, a C2 domain used in the May 2026 worm campaign was public on a personal account.
- Password reuse: a single credential in a public dump connected a school email to a personal account, and that account to everything registered against it.
None of that is technical. Flare's own recommendation to defenders draws the line: monitor your domains in stealer logs and combolists. The credential exposure that let researchers reach a real identity is the same exposure class that put 2,500 organizations in TeamPCP's own archive.
TeamPCP was also loud on purpose: Telegram channels, a since-deleted X account, taunts aimed at victims, and worm source code published under an MIT license with a joke attached. The group also gave an interview to Forbes, describing itself as "a loose-knit group of teenagers and young adults who couldn't find paying work, so they turned to cybercrime." Every one of those was a place to start looking.
What these failures actually give defenders
Ctrl Alt Intel documented Devman's management systems by reading its infrastructure from the outside. The infostealer on the North Korean operator's machine surfaced in someone else's log analysis. Flare's chain started from a public alias and ran on public data. In all four cases the mistake reached the public record through research, after the fact, rather than through anything a victim's own monitoring caught.
That distinction matters, because of how the ordinary case looks:
- An attacker using native admin tooling and signed binaries leaves no malware to scan: nothing looks wrong.
- One presenting a real credential and a real token produces a clean entry in the sign-in log: authentication succeeds.
- One crossing on-premises, identity and cloud planes leaves no single system holding the whole picture: movement isn't visible.
Those are the three gaps I write about, and none of the four failures above changed any of them while the attacks were running.
Devman's exposed panel helped researchers profile an operation, not a victim spot an intrusion. Flare's walkthrough produced an attribution, not an alert. These mistakes serve attribution, prosecution and public reporting, all three of which matter, and none of which is detection. Detection has to assume no mistake was made.
What the failures do point to is the kind of signal worth watching. In each case the tell was behavioral rather than static: how the actor behaved after gaining access, which infrastructure got reused, and where isolation broke down. Deception environments, synthetic data and behavior-based monitoring do not prevent attacks. They surface behavior when an assumption fails.
Attackers are also adopting AI-driven tooling, which accelerates reconnaissance, targeting and exploitation without removing human judgment from the loop. That brings its own failure modes: over-trusting automated output, and scaling a false assumption before anyone notices it was false.
The gap chapters in Mind Your Attack Gaps work through what detection looks like when the attacker gets it right, which is the case worth planning for. At Vectra AI we model behavior after access across identity, cloud and network, because that signal survives when the attacker makes no mistakes at all.
The technology changes. The people don't.