Tracing a breach through cloud logs to find the root cause
Most breach stories are assembled after the fact from fragments: a failed sign-in, a new access key, a suspicious API call, and a file transfer nobody recognised at the time. Analyzing cloud logs to identify the root cause of a breach means turning those fragments into a defensible sequence. Identity records, cloud audit trails, network telemetry, endpoint alerts, configuration changes, and SaaS activity must be aligned to show what happened, when it happened, and which control allowed it.
Cloud evidence differs from evidence on a corporate server because it is distributed, short-lived, and often owned by another team. A workload may disappear before investigators collect its logs, regional buckets expire, and identity events may sit apart from affected resources. The same incident can look different in Sydney, Melbourne, and Perth because daylight-saving changes distort local timestamps. Good analysis starts with preserving raw evidence and converting it to one time standard before drawing conclusions.
Build a defensible evidence timeline
Start by preserving the logs that still exist, rather than opening a console and reacting to whatever remains. Export relevant records to immutable storage, record the tenant, region, collection time, retention setting, and chain of custody, and retain the original format. Where legal, regulatory, or litigation holds apply, collection must preserve evidentiary integrity.
Normalise timestamps carefully. Record each event’s generation time separately from its ingestion time, then display the sequence in UTC while retaining original local values. Australian cloud estates may use hyperscale regions in Sydney and Melbourne while administrators and workloads operate elsewhere, so an event labelled by local time can easily be placed before the event that caused it.
Define collection scope around the incident hypothesis, not one vendor’s default view. Prioritise identity provider logs, cloud control-plane audit records, IAM changes, network flow and firewall events, endpoint telemetry, email and SaaS audits, and data-loss prevention records. Capture configuration snapshots as well as activity logs, because a change record may reveal what was altered after the live setting has been restored.
Separate initial access from downstream impact
Reconstruct the attack as a chain rather than a collection of alerts. Label significant events as initial access, execution, persistence, privilege escalation, credential access, lateral movement, collection, or exfiltration. This separates the first unauthorised action from consequential events that occurred hours or days later. Indicators of compromise become useful only in sequence, since the same address or token can have legitimate uses.
Initial access may involve a stolen password, malicious OAuth consent, an exposed application endpoint, or misuse of a valid service account. If a trusted identity was used, the absence of malware does not prove the account was uncompromised. Look for unusual token issuance, new MFA methods, sessions from unfamiliar networks, and access outside an identity’s normal pattern.
Also separate compromise from impact. Attackers may browse data without downloading it, create snapshots, enable sharing, or modify mail rules. Search read, copy, forwarding, and administrative events rather than treating a large transfer as the only possible outcome. The earliest credible intrusion can be more useful for containment than the largest later alert.
Correlate identity, workload, network, and endpoint signals
Correlation becomes stronger when analysts join events through shared entities: user principal, source IP, session or token identifier, device, workload, request ID, and affected resource. A SIEM can perform this joining, but it depends on consistent clocks, identifiers, and tenant context. Where fields differ, preserve original values and document the mapping rather than forcing a false match.
Cloud-native and workload signals answer different questions. Cloud audit records reveal control-plane activity such as role changes and API calls, while workload and container logs show what an application did after receiving a request. Endpoint telemetry can connect a token on a developer laptop to process execution or persistence, but ephemeral workloads may leave no durable endpoint trace, so both layers are needed.
Do not overlook collaboration and SaaS services. OAuth grants, mailbox forwarding rules, bulk downloads, unusual sharing links, and data exports can reveal impact without producing a conspicuous workload alert. Audit coverage and retention vary by plan, so identify missing telemetry before treating an absence of activity as proof that nothing occurred.
Test privilege and configuration changes
Privilege changes deserve dedicated analysis. Review role trust policies, policy attachments, access keys, service principals, delegated administration, MFA enrolments, and KMS permissions in the cloud audit trail. Attackers often blend into normal administration, making an authorised request more suspicious when its context differs from the operator’s usual location, device, time, or requested actions.
Configuration history can show how apparently harmless access became dangerous. Compare current settings with change records and snapshots, looking for public exposure, disabled logging, shortened retention, permissive trust relationships, or newly reachable storage. If an attacker changed a setting and later changed it back, the second event does not erase the first; both belong in the forensic timeline.
For Australian organisations, technical findings should also be mapped to applicable obligations. The OAIC and the Privacy Act framework, including Notifiable Data Breaches considerations, affect how personal information is assessed and escalated. ASD’s Essential Eight informs risk controls, while APRA CPS 230 applies to covered financial entities. These frameworks help prioritise remediation, but they do not replace causal analysis of the breach.
Build an incident narrative from tested hypotheses
Turn the evidence into testable hypotheses. For each possible cause, record supporting facts, contradictory facts, confidence, and the logs needed to close the gap. A useful hypothesis is specific: “a personal access token was created outside the deployment pipeline and then used to read customer objects,” rather than “credentials may have been stolen.”
A defensible conclusion explains the incident’s mechanics. It identifies the initial access path, the weakness or failed control that permitted persistence or escalation, the actions that created impact, and the detection opportunities missed along the way. Naming “phishing” as the cause may describe the lure, but it does not explain why the malicious sign-in succeeded or why subsequent cloud activity was not escalated sooner.
This is where the CARM Security ecosystem is relevant. Developed by Exclusive Networks, the platform integrates multiple security technologies around post-breach attack remediation and mitigation, helping enterprises identify, contain, respond to, and remediate cyberattacks. Its documents and videos can connect a forensic finding with the coordinated response required across identity, cloud, network, and endpoint teams.
Compare evidence sources and prioritise response actions
A practical response depends on matching each evidence source to a specific question. Australian security teams use the phrase “forensic deep dive” for disciplined log analysis: work the logs, establish what happened, and show the evidence. That discipline should be paired with exercises that test both visibility and response. A mature detection programme needs red versus blue teams, because adversarial activity exposes gaps while defensive exercises validate containment and escalation.
| Evidence source | Primary question | Strong signal | Common blind spot |
|---|---|---|---|
| Identity provider audit | Who authenticated, and from where? | New MFA methods, impossible travel, unfamiliar sessions | Activity before federation or poorly retained records |
| Cloud control-plane audit | What administrative action changed access? | Role, key, policy, and API changes | Missing tenant logs or events made with valid credentials |
| Network and firewall logs | Which systems communicated, and where? | East-west anomalies and unusual destinations | Encrypted payloads and short-lived workloads |
| Endpoint telemetry | What ran on affected devices? | Persistence, credential theft, suspicious processes | Cloud workloads without durable endpoint records |
| Email and SaaS audits | Was collaboration data exposed or shared? | Forwarding rules, OAuth grants, bulk downloads | Retention limits and incomplete API coverage |
| DLP and file activity | What left, staged, or entered protected data? | Uploads to personal storage and bulk read events | Blind spots caused by misconfigured sensors |
No single source establishes how the incident unfolded. An identity audit can show unauthorised authentication but miss changes made with a legitimately issued token; endpoint data can reveal persistence but miss control-plane-only activity; DLP may show a transfer without identifying the compromised identity. Australian organisations often combine global hyperscaler services with local managed-service and incident-response providers, so evidence ownership, regional retention, and escalation paths need explicit agreement before an investigation begins.
Practical recommendations for an evidence-led response
- Preserve raw evidence immediately, record provenance and retention windows, and export priority logs to immutable storage before further configuration changes.
- Establish one UTC timeline while retaining source timestamps, tenant identifiers, region names, and daylight-saving context for every significant event.
- Build an entity map linking identities, sessions, tokens, devices, workloads, network locations, and affected resources to expose repeated pivots.
- Test competing explanations against contradictory evidence and keep confidence levels explicit, rather than forcing every alert into a single theory.
- Contain confirmed paths with the least disruptive control that stops further access, while preserving evidence from identities, tokens, services, and infrastructure still under attacker control.
- Convert the confirmed cause into specific control improvements, owners, detection tests, and evidence that will prove the corrective action works.
The findings that should remain
The final forensic summary should let technical and non-technical readers see the same truth: what was accessed, how the attacker entered, which controls failed, how far the activity spread, what was contained, and what evidence supports each claim. Preserve the timeline, key artefacts, decisions, and unresolved gaps, because the record may be needed for regulatory notification, legal advice, customer communication, or later validation.
The finding to remember is that cloud logs do not explain a breach by themselves; a trustworthy root cause emerges when preserved, time-aligned identity, control-plane, network, endpoint, and application records are correlated against the actual sequence of attacker actions.