KiranaPro breach exposes cloud threat monitoring and offboarding gaps

At a glance

What this is: This is an analysis of the KiranaPro breach, where attackers used a former employee’s account to delete AWS and GitHub infrastructure and expose gaps in cloud threat monitoring.

Why it matters: It matters to IAM and NHI practitioners because the same offboarding, standing access, and monitoring failures that enable human account abuse also weaken control over service accounts, tokens, and other non-human identities.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Exaforce's analysis of the KiranaPro breach and cloud threat monitoring gaps

Context

KiranaPro is a reminder that cloud security failures often begin with identity, not infrastructure. When a former employee account remains capable of destructive actions, the problem is usually poor offboarding, weak entitlement review, or inadequate detection of abnormal activity. In that sense, cloud threat monitoring is inseparable from identity governance, because access misuse is the path through which cloud damage becomes operational loss.

The article also exposes a familiar gap between provider controls and customer responsibility. MFA and native cloud safeguards do not remove the need for lifecycle control over user accounts, API access, and privileged actions. For IAM and NHI programmes, the lesson is not only about human users. The same control blind spots apply to non-human identities that can persist beyond their useful life if monitoring and revocation are not enforced.

Key questions

Q: What breaks when a former employee account is not fully revoked?

A: A retained former employee account can preserve the exact permissions an attacker needs to alter, delete, or exfiltrate cloud and SaaS assets. The failure is usually not login bypass but lifecycle failure: access, sessions, tokens, and entitlements remain valid after employment ends. That makes offboarding a security control that must terminate authority, not just accounts.

Q: Why do MFA and cloud-native controls still fail in destructive account abuse cases?

A: MFA only proves that a session was authenticated at login. It does not stop a valid session from using over-broad permissions to delete infrastructure or data. If privilege scope is too wide, destructive actions remain available after authentication. That is why least privilege and step-up controls matter as much as login assurance.

Q: How do teams know if cloud threat detection is actually working?

A: The strongest signal is whether security teams can validate an alert with evidence captured during execution, not after the fact. If investigations routinely end in partial logs, missing traces, or unresolved assumptions, the programme has visibility gaps that runtime monitoring should be closing.

Q: Who is accountable when offboarding failures lead to cloud destruction?

A: Accountability usually sits with the organisation, not the cloud provider, because the provider secures infrastructure while the customer governs identities, entitlements, and sessions. IAM, security operations, and application owners all share responsibility for ensuring access is removed promptly and destructive permissions are controlled before a departure becomes an incident.

Technical breakdown

Former employee access and cloud account abuse

A compromised or retained former employee account becomes a high-trust entry point because it already carries legitimate authentication context. If that account can reach cloud consoles, Git repositories, or automation surfaces, the attacker does not need to defeat perimeter controls first. In practice, the breach path is often less about technical exploitation than about lifecycle failure: credentials, tokens, and entitlements were not revoked fast enough, or access was broader than the person needed at departure. That makes offboarding a security control, not just an HR workflow.

Practical implication: tie offboarding to immediate access revocation, entitlement review, and session invalidation across cloud and SaaS systems.

Why MFA does not stop destructive cloud actions

Multi-factor authentication raises the bar for login, but it does not validate whether the authenticated session should still be allowed to delete infrastructure or data. Once the session is established, a compromised account can still perform whatever the assigned permissions allow. That is why destructive cloud incidents often bypass MFA without bypassing it technically. The real control boundary is privilege scope, not authentication alone. Continuous verification, session risk checks, and least privilege are what limit blast radius after login succeeds.

Practical implication: pair MFA with least-privilege entitlements and step-up controls for destructive actions.

Cloud threat monitoring and identity telemetry

Cloud threat monitoring works by correlating identity events, resource changes, and unusual behaviour patterns in real time. The important signals are not only failed logins, but also suspicious geolocation shifts, unexpected privilege changes, mass deletions, and access patterns that diverge from a user’s normal role. In mature programmes, these signals feed alerting and automated containment before a destructive action completes. That is especially important where cloud consoles, code repositories, and identity providers are all connected to the same operational path.

Practical implication: monitor identity events alongside infrastructure changes so anomalous account behaviour can be contained before data or code is destroyed.

Threat narrative

Attacker objective: The attacker’s objective was to destroy the company’s cloud and software operations by abusing retained account access.

1. Entry occurred through a former employee account that still had sufficient access to reach KiranaPro’s cloud and GitHub environments.
2. Escalation was achieved through legitimate permissions that allowed destructive actions once the account session was active, despite the presence of MFA.
3. Impact followed when attackers deleted AWS and GitHub infrastructure, wiping code, data, and operational resources and disrupting the business.

NHI Mgmt Group analysis

Cloud breaches increasingly expose identity governance failures, not just security tooling gaps. KiranaPro’s loss shows that destructive cloud actions often come from accounts that were still trusted by the organisation but no longer should have been. The operational mistake is treating departure workflows as administrative rather than security-critical. For identity teams, the breach reinforces that offboarding completeness is a control outcome, not a process checkbox.

Standing account authority: is the failure mode this breach makes visible. A former employee account that can still reach AWS or GitHub represents latent authority that attackers can inherit without technical exploitation. That is a lifecycle problem that spans IAM, SaaS governance, and privileged access review. The practitioner conclusion is simple: if access can survive role exit, it can survive into compromise.

Provider-native controls do not replace customer-side governance. The shared responsibility model works only when organisations actively govern accounts, entitlements, and destructive actions in their own environments. Cloud providers can secure infrastructure, but they do not know which accounts should be dormant, revoked, or stepped up for sensitive operations. IAM and NHI programmes should treat cloud and SaaS access as a continuous governance surface.

Cloud threat monitoring is becoming an identity detection problem. The most useful signals are account misuse, abrupt privilege shifts, and resource destruction patterns, not just malware or perimeter alerts. That pulls SIEM, IAM telemetry, and cloud audit logs into one operating model. Practitioners should expect cloud monitoring to converge with identity threat detection and response rather than remain a separate function.

For NHI governance, the same lesson applies to tokens and service accounts. If a human account can survive offboarding, so can a machine credential if ownership and revocation are unclear. KiranaPro is a human-account case, but the governance failure mode is identical: retained authority with no effective lifecycle endpoint. Practitioners should use the breach to pressure-test all identities, not only employee accounts.

What this signals

Cloud breach response is increasingly an identity programme issue because account misuse, not malware, is what turns ordinary access into irreversible loss. The practical lesson for IAM and NHI teams is to treat offboarding latency, privilege scope, and session revocation as operational resilience controls, not administrative housekeeping.

Standing authority collapse: the real risk is any identity that remains trusted after its owner is no longer trusted. That applies to employee accounts, service accounts, API keys, and automation tokens alike. When access can outlive its business purpose, cloud monitoring becomes the last line of defence rather than a preventive control.

Practitioners should expect cloud audit logs, IAM telemetry, and security operations workflows to merge more tightly. The organisations that respond best will be those that can detect abnormal identity behaviour quickly enough to stop destructive actions before repositories, infrastructure, or data are permanently lost.

For practitioners

• Tighten offboarding with same-day access revocation Revoke cloud console access, GitHub permissions, API tokens, and active sessions as part of a single offboarding workflow so departed users cannot retain destructive authority. Include emergency escalation for accounts with production reach and validate that revocation completes across all connected systems.
• Scope destructive permissions separately Separate routine operational access from permissions that can delete infrastructure, repositories, or data. Require explicit approval and step-up checks for mass deletion, privilege changes, and other irreversible actions so a valid login does not automatically equal destructive capability.
• Monitor identity-led cloud anomalies in real time Correlate sign-in context, permission changes, and resource deletion events in the same detection path. Prioritise alerts for unusual locations, sudden role changes, and bulk destructive actions because these are often the earliest reliable indicators of account abuse.
• Verify recovery readiness for cloud and source control Keep tested backups, infrastructure-as-code templates, and restoration runbooks for both cloud resources and repositories. Recovery planning should assume that an account compromise can wipe production assets faster than manual response teams can intervene.

Key takeaways

• KiranaPro shows that cloud destruction often starts with retained identity authority rather than a platform vulnerability.
• The incident reinforces that MFA alone does not constrain what an authenticated account can do when privileges are too broad.
• The control that matters most is lifecycle governance, combined with real-time monitoring for destructive identity behaviour.

Key terms

• Cloud Security Monitoring: Cloud security monitoring is the continuous collection and analysis of cloud activity to detect threats, policy drift, and control failures. It turns logs and alerts into operational visibility, but it only improves security when teams can act on the findings through IAM, SOC, and remediation processes.
• Offboarding Latency: Offboarding latency is the delay between removing an identity's access entitlement and the actual disappearance of that access from systems. For NHIs and privileged access paths, long latency creates residual exposure, especially when multiple platforms or extra components must be cleaned up separately.
• Standing authority: Standing authority is access that remains continuously available instead of being granted only when needed. It becomes dangerous when a person, service, or automation no longer has a valid business need but still retains permissions that can be used to alter or destroy systems.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Exaforce's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step recommendations for monitoring SaaS and IaaS environments for unusual account activity.
• Specific examples of IP allow-listing, resource access monitoring, and user agent validation.
• Practical guidance on controlling long-term IAM credentials and mapping offboarding dependencies.
• Discussion of disaster recovery and backup discipline after destructive cloud incidents.

👉 The full Exaforce post covers the account abuse pattern, monitoring signals, and recovery measures in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build lifecycle controls that reduce the kind of retained-access risk this breach exposed.