Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: KiranaPro’s cloud environment was wiped after attackers used a former employee’s account to delete AWS and GitHub infrastructure, demonstrating that provider-native controls and MFA do not stop account abuse when offboarding and monitoring are weak, according to Exaforce. The breach shows why access governance and runtime visibility must be treated as operational controls, not documentation exercises.
NHIMG editorial — based on content published by Exaforce covering the KiranaPro breach: The KiranaPro breach: A wake-up call for cloud threat monitoring
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Scope destructive permissions separately Separate routine operational access from permissions that can delete infrastructure, repositories, or data.
- Monitor identity-led cloud anomalies in real time Correlate sign-in context, permission changes, and resource deletion events in the same detection path.
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.
👉 Read Exaforce's analysis of the KiranaPro breach and cloud threat monitoring gaps →
KiranaPro breach: what cloud and identity teams need to fix now?
Explore further
02/08/2026 1:02 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: KiranaPro breach exposes cloud threat monitoring and offboarding gaps
