Living‑off‑the‑platform attacks
Security briefings emphasise that many high‑value intrusions now use legitimate cloud identity workflows — like consent grants, service‑principal changes and role assignments — instead of malware, so detections must focus on post‑consent and post‑privilege activity. Analysts recommend two‑tier rules: broad anomaly detections for visibility, then chained high‑confidence alerts when consent or admin changes are followed by mailbox, file or admin access. (cxotoday.com)
A lot of cloud break-ins now start with a button click that looks legitimate: a user approves an app, an administrator changes a role, or a service identity gets new permissions. Microsoft says consent phishing works by tricking a user into granting an application access to mail, files, or profile data without stealing the user’s password first. (learn.microsoft.com) That works because cloud systems are built to let software ask for permission through a consent screen. Microsoft’s consent model lets an application request access to protected resources like a mailbox, and the user or an administrator can approve that access depending on the permission level. (learn.microsoft.com) A service principal is the cloud’s version of a staff badge for an application. Once that badge is trusted, the application can call services over and over without a human typing a password each time. (learn.microsoft.com) Role assignment is the next lever. In Google Cloud, granting roles on a service account can let another identity impersonate that account, which means a permission change can quietly turn into broad access to data or systems. (docs.cloud.google.com) That is why these attacks are called living off the platform. The intruder is using the cloud provider’s real workflows the way a burglar might use a copied building key instead of breaking a window, and CISA says living-off-the-land activity is hard to spot because the same actions can also be normal administration. (cisa.gov) The first clue is often not the permission change itself but what happens right after it. Microsoft’s guidance on illicit consent grants says attackers typically register an app, trick a user into approving it, and then use that granted access to pull email, documents, or contacts from Microsoft 365. (learn.microsoft.com) That changes what defenders need to watch. A single new consent grant can be noisy and benign, but a new consent grant followed by mailbox reads from the same application is a much stronger signal that the app is not a calendar helper and is actually harvesting data. (learn.microsoft.com) The same logic applies to administrator changes. Google says Identity and Access Management policies control who can access data, create compute instances, and modify security settings, so a risky policy change followed by unusual activity from that identity is the pattern that matters. (cloud.google.com) Security teams are responding with two layers of rules instead of one. Broad anomaly rules cast a wide net for unusual consent, role, or service-account changes, while narrower chained rules fire when those changes are followed by concrete actions like file access, mailbox access, or administrative operations. (cloud.google.com) The cleanup also looks different from old malware response. Microsoft’s incident playbook for app consent investigations focuses on finding the malicious application, reviewing granted permissions, revoking consent, disabling the service principal, and checking what data the app touched after approval. (learn.microsoft.com) The old question was “Did malware run on this device.” The new question is “Which identity got new trust, who granted it, and what did it do in the minutes after that change.” (cisa.gov)
