Authentication weak points are driving this week’s breach wave

At a glance

What this is: FireCompass’s weekly incident report highlights four breaches where credential abuse, third-party compromise, and zero-day exploitation drove the impact.

Why it matters: IAM, PAM, and security teams should read this as a signal that authentication controls, vendor access governance, and incident response readiness remain central to breach containment.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read FireCompass's weekly cybersecurity intelligence report on recent breach patterns

Context

Weekly incident roundups are useful because they expose recurring control failures before they become accepted operating conditions. In this case, the common thread is not a single exploit class but the repeated abuse of authentication, trusted third-party access, and exposed credentials across consumer platforms, education, and enterprise systems.

The identity lesson is straightforward: when access is governed primarily by shared secrets, delegated support accounts, or weakly monitored authentication flows, attackers need less technical depth to succeed. That makes IAM, PAM, NHI governance, and vendor access lifecycle controls part of the breach surface, not just supporting controls.

Key questions

Q: What breaks when application security controls are too weak against credential stuffing?

A: The application starts treating automation as legitimate traffic, which lets attackers reuse breached credentials to take over accounts at scale. Without MFA, rate limits, lockouts, and bot detection, the same login flow that serves users also serves attackers. The result is often account takeover, personal data exposure, and expensive incident response.

Q: Why do support accounts create outsized breach risk?

A: Support accounts often reach multiple customer-facing systems and may bypass normal least-privilege controls for convenience. If one of those accounts is compromised, the attacker can move directly into sensitive data without searching for additional permissions. That makes support access a high-value target and a strong candidate for task-scoped privilege and stricter review.

Q: What are the signs that vendor access governance is failing?

A: Common signals include long-lived support privileges, unclear ownership of vendor accounts, inconsistent offboarding, and access paths that reach multiple systems without segmentation. If a third party can move from a support workflow into identity or data systems with little friction, governance is already weaker than it appears.

Q: What should security teams do when a public-facing application is exploited?

A: They should contain the exposed system first, revoke or restrict any related service accounts, and determine whether the application can reach identity, finance, or support data. The key question is not only how the flaw was exploited, but which accounts and downstream permissions it could activate.

Technical breakdown

Credential stuffing and account takeover in consumer platforms

Credential stuffing is an automated attack pattern that reuses username-password pairs from previous breaches against live authentication systems. It succeeds when users recycle credentials and when login controls do not adequately rate-limit, challenge, or correlate abnormal access patterns. In the DraftKings case, attackers combined bulk login attempts with likely stolen credentials, producing successful account access without malware or internal compromise. The technical issue is not brute force alone. It is the mismatch between high-volume attacker automation and authentication systems that still treat each login as an isolated event.

Practical implication: enforce adaptive MFA, risk-based authentication, and credential reuse monitoring on every customer and privileged login flow.

Third-party support access as an identity trust boundary

A third-party breach becomes your breach when vendor credentials can reach your support tooling, identity systems, or customer data without strong segmentation and lifecycle controls. In the Discord incident, attackers used valid accounts from an outsourced support path to access Zendesk and connected tools, showing how delegated trust expands the blast radius. The critical technical weakness is not just vendor compromise. It is that support identities often inherit broad access, long-lived permissions, and weak offboarding discipline across multiple systems.

Practical implication: treat vendor support accounts as high-risk identities and scope them with least privilege, segmentation, and continuous review.

Zero-day exploitation in enterprise applications

A zero-day exploit is dangerous because defenders do not yet have a patch, signature, or stable detection pattern when exploitation begins. The Harvard Oracle E-Business Suite case shows how chained weaknesses such as authentication bypass, request forgery, and template injection can convert a public-facing business application into a remote code execution path. Once that path exists, attackers can move from initial entry to data access quickly, often before normal patch cycles or vulnerability processes can react. The core challenge is exposure duration, not just vulnerability presence.

Practical implication: shorten exposure windows with asset inventory, emergency patch processes, and compensating controls for internet-facing applications.

Threat narrative

Attacker objective: The attackers aimed to convert weak authentication and delegated access into data theft, account control, and extortion leverage across multiple organisations.

1. Entry began through automated credential reuse against DraftKings login systems, then through compromised third-party support credentials at Discord, and through unauthenticated Oracle E-Business Suite exploitation at Harvard.
2. Escalation came from valid account access, inherited vendor permissions, and application-level execution paths that expanded an initial foothold into broader data access.
3. Impact included account takeover, government ID exposure, ransomware-driven exfiltration, and the potential for mass downstream extortion from compromised enterprise systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication failure is now a recurring breach pattern, not an isolated tactic. The DraftKings incident shows how quickly automated credential reuse can succeed when login defenses treat attacks as ordinary user activity. For IAM teams, this is a reminder that authentication telemetry must be operationally meaningful, not just logged. Adaptive controls and credential intelligence are now baseline expectations, not hardening extras.

Third-party access governance is an identity problem as much as a supply chain problem. The Discord breach illustrates that outsourced support accounts can become an indirect route to internal systems, customer records, and identity tooling. That means vendor access cannot be managed as a one-time onboarding exercise. It requires scoped permissions, periodic revalidation, and explicit offboarding tied to the lifecycle of each delegated identity.

Public-facing business applications remain high-value identity attack surfaces. Harvard’s Oracle exploitation shows how a single application weakness can bypass perimeter assumptions and expose downstream data domains. The practical consequence is that application security and identity controls now intersect more tightly, especially where application sessions, administrative roles, or service accounts can be abused after entry. Security teams should align vulnerability response with access containment.

Standing privilege is the accelerant behind both compromise and impact. Each incident reflects a different entry path, but all of them become more damaging when access is persistent, broad, or poorly monitored. This is where NHI governance matters directly, because service accounts, support tokens, and delegated credentials behave like identities with blast radii. Practitioners should treat lifecycle control as a first-class control plane, not an inventory exercise.

Identity governance now has to cover customers, vendors, and machine-mediated workflows together. The common failure mode across these incidents is not just weak login hygiene but weak trust boundary design. Identity programmes that separate human IAM, vendor access, and NHI governance into disconnected processes will miss the way attackers move between them. The discipline now needs one control model for access lifecycle, privilege scope, and trust validation.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Explore The 52 NHI breaches Report for breach patterns that show how exposed secrets, standing privilege, and delegated trust translate into real-world incidents.

What this signals

Standing access is the common denominator across credential abuse, vendor compromise, and application exploitation. Once a login path or support identity is trusted by default, attackers do not need to own the whole environment to create major impact. The practical signal for programmes is to collapse standing privilege, shorten trust windows, and make review of delegated access continuous rather than periodic.

Identity teams should expect more cross-domain incidents where human, vendor, and machine credentials fail together. That makes access lifecycle evidence, not policy intent, the key control artifact. Where organisations already struggle to track non-human identities, the probability of hidden blast radius rises quickly, and the remediation burden shifts from detection to governance.

Authentication telemetry should now be treated as a risk indicator for both IAM and NHI programmes. Failed logins, unusual device patterns, and sudden success after repeated attempts are early warning signs of broader credential exposure. The control objective is to turn those signals into faster revocation, narrower permissions, and cleaner identity ownership.

For practitioners

• Strengthen adaptive authentication for high-risk logins Add risk-based MFA, velocity checks, and anomalous user-agent detection to customer and privileged authentication flows so reused credentials are less likely to succeed.
• Tighten third-party support access Inventory every vendor identity that can reach support, admin, or customer data systems, then reduce scope, shorten approval windows, and enforce explicit offboarding.
• Contain internet-facing application exposure Map all public-facing business systems, prioritise those handling finance or identity data, and define emergency patch and compensating control playbooks before the next zero-day lands.
• Monitor for credential reuse and account takeover signals Correlate failed login bursts, lockouts, and successful logins from unusual geographies or devices so investigators can separate password reuse from normal customer behaviour.

Key takeaways

• The weekly incident pattern is clear: weak authentication, delegated trust, and exposed application paths still create most practical breach opportunities.
• The evidence points to a governance problem, not just a detection problem, because vendor access and standing privilege expand the blast radius of every successful entry point.
• Teams that want to reduce breach impact need tighter authentication, stronger third-party access controls, and faster containment for public-facing systems.

Key terms

• Credential Stuffing: Credential stuffing is an attack that uses stolen username and password pairs from previous breaches to try logging into other services. It works because many people reuse credentials, and because the login attempt uses valid information, it can look ordinary until the surrounding behavior gives it away.
• Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Actively Exploited Zero-Day: An actively exploited zero-day is a vulnerability being used by attackers before or immediately after a fix becomes available. In practice, it demands urgent prioritisation because exploitation risk is confirmed, not theoretical, and defensive teams often have little time to compensate with mitigations or exposure reduction.

What's in the full article

FireCompass's full analysis covers the incident detail this post intentionally leaves for the source:

• IOC-level authentication log patterns and suspicious login indicators from the DraftKings case
• Named remediation actions taken after each incident, including vendor access revocation and MFA enforcement
• Technical indicators tied to the Oracle zero-day chain, including exploit paths and request patterns
• The full per-incident chronology across credential stuffing, third-party compromise, ransomware, and zero-day exploitation

👉 FireCompass's full report includes the incident-by-incident technical detail, remediation steps, and exploitation timelines.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It helps practitioners connect identity lifecycle controls to real breach patterns across human and non-human access.