Certified: The GIAC GCLD Audio Course

Identity logs are the backbone of cloud investigations because they explain who showed up, how they authenticated, what level of authority they gained, and what they tried to do after they got in. In this episode, we focus on capturing identity evidence that reveals misuse, privilege changes, and suspicious sign-ins, because most cloud incidents either begin with identity compromise or quickly involve identity abuse for persistence and expansion. When identity logging is weak, responders end up staring at resource activity without being able to tie actions back to a principal with confidence, and that slows containment and increases uncertainty. Strong identity logging also supports normal operations by making access reviews, troubleshooting, and governance decisions easier and more defensible. The goal is not to collect identity events as a compliance exercise, but to preserve an authoritative record that can answer investigation questions under pressure. If you capture the right identity events with the right context, you can often identify the turning points of an incident quickly and scope impact with far less guesswork.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Authentication events should be captured comprehensively because they are the earliest signals of attempted compromise and the clearest record of how access was obtained. This includes successful and failed sign-ins, because failure patterns often reveal password spraying, credential stuffing, or brute-force attempts that would otherwise blend into background noise. Authentication logs should also include multi-factor authentication prompts and outcomes, because MFA fatigue and push approval abuse can look very different from normal interactive logins. Device context matters as well, because many real-world compromises involve unfamiliar devices, missing device compliance posture, unusual browser fingerprints, or sign-ins that do not match the organization’s typical endpoint population. Capturing source information such as client type, network source, and the authentication method used helps differentiate legitimate access from automated abuse. The goal is to create a clear story of how the session began, including which checks were passed or bypassed. When authentication evidence is complete, responders can answer whether access was likely stolen, guessed, socially engineered, or legitimately granted.

Session and token events are the next critical area because modern cloud access often relies on tokens that persist beyond a single login. A credentialed attacker may not need to repeatedly authenticate if they can obtain and reuse tokens, refresh them unusually, or create new sessions that appear legitimate on the surface. Capturing token issuance events helps establish when a principal received access that could be used to call services and APIs, and it helps differentiate interactive user sessions from noninteractive service-to-service flows. Unusual refresh behavior can indicate automated tooling, persistence mechanisms, or session replay patterns where tokens are being used in ways that do not match normal user behavior. Session logs that show sign-in method, token lifetime, client application, and scope are especially useful because they reveal what the token could do, not just that it exists. When these events are missing, responders may see resource activity but remain uncertain about how the actor maintained access across time. Capturing session and token evidence closes that gap and makes identity investigations far more precise.

Role assignments and privilege changes must be logged with full metadata because privilege escalation is a common incident inflection point. The most damaging events are often not the initial sign-in, but the moment an attacker gains higher permissions or broadens access paths. Identity logs should capture the actor who performed the assignment, the target principal receiving new privileges, the role or permission set granted, and the scope of that grant, including which resources or organizational units it affects. Timing and request context matter, because escalations often occur soon after initial access, and they may come from unusual clients or automation paths. Metadata should also include whether the change was part of an approved workflow or an ad hoc administrative action, because responders need to distinguish legitimate access administration from unauthorized privilege growth. When privilege change logs are strong, investigators can quickly identify whether the environment’s blast radius expanded and what containment steps are required. In practice, privilege changes are among the highest-signal identity events you can capture.

Policy edits and trust relationship changes deserve the same level of logging rigor because they often enable persistence that survives password resets and even account remediation. Identity and access policies define what principals can do, and attackers who can edit policies can create backdoors in the form of overly broad permissions, exceptions, or conditions that are hard to notice in routine reviews. Trust relationships, such as federation settings and cross-account trust, are particularly sensitive because they can allow access paths that bypass normal authentication expectations. Changes to these settings should be logged consistently, including what was modified, who modified it, and how the change was authorized. A small, seemingly legitimate policy edit can have outsized effect, such as allowing access from a broader set of identities or granting administrative actions under conditions that are rarely scrutinized. When these events are captured reliably, responders can trace how access boundaries were altered and whether the changes were used to establish long-lived control. Without them, teams may fix symptoms while leaving the enabling policy change in place.

Nonhuman identities require special attention because their credentials often behave differently and can be harder to govern. Many environments rely on access keys, secrets, or other credential forms for automation and service-to-service access, and attackers frequently target these because they can provide quiet, durable access. Identity logging should capture access key creation, modification, rotation, and usage, including which principal created the key and where the key was used afterward. Usage context is crucial because an access key used from a new location, at unusual times, or against unusual services can be an early indicator of compromise. Nonhuman identities also tend to accumulate permissions over time, so key events combined with privilege change events can reveal when a service identity becomes a high-value target. Capturing these events allows investigators to determine whether automation credentials were abused and whether the access path is still active. Strong logging for nonhuman identities also improves governance, because it supports lifecycle management and reduces the number of credentials that exist without clear ownership.

Interpreting identity evidence requires practice because misuse signals are often patterns rather than single events. A single failed sign-in can be benign, but repeated failures across many accounts or a rapid sequence of attempts against one account can indicate automated attack activity. A successful sign-in immediately followed by privilege escalation events is a classic escalation pattern that should raise suspicion, especially if it occurs outside normal working hours or from an unfamiliar device. Repeated MFA prompts or unusual MFA denial patterns can indicate prompt bombing or social engineering attempts designed to pressure a user into approving access. Token issuance followed by service usage that does not match the principal’s normal behavior can suggest stolen tokens or malicious automation. The key is to look for sequences that do not fit the organization’s baseline, rather than treating each event in isolation. When analysts are trained to interpret sequences, they can identify compromise faster and reduce the time attackers have to expand control.

A common pitfall is missing critical identity logs because defaults were never enabled, or because logging was treated as optional during early platform rollout. This failure mode is especially painful because it is not obvious until the first investigation, when teams realize they lack the historical record needed to establish timelines and accountability. In cloud environments, identity logging can be fragmented across accounts, regions, and services, and a partial rollout can create blind spots where the most interesting activity occurs. Another variation of the pitfall is capturing logs but failing to centralize them, leaving evidence scattered and inaccessible during a crisis. Teams also sometimes enable logs but do not retain them long enough, which turns slow-moving compromise into an untraceable event. The practical lesson is that identity logging must be treated as foundational infrastructure, not as an enhancement that can be deferred. When identity logs are consistently enabled and centralized, every other investigation becomes faster and more accurate.

A quick win that provides immediate defensive value is to alert on privileged changes and new key events, because these are high-signal activities with clear potential impact. Privileged role assignments, policy edits affecting trust or authorization, and creation of new access keys for nonhuman identities should all be treated as events that warrant prompt review. The goal is not to trigger panic for every legitimate change, but to ensure that high-impact actions are visible quickly enough to catch misuse early. Alerts should include enough context to enable triage, such as the acting principal, the target principal, the scope of change, and the origin context like device or client type. Over time, these alerts can be tuned based on normal change windows and approved workflows, but the baseline should be visibility first, tuning second. This quick win works because attackers often need these actions to progress, and early detection can prevent them from reaching deeper systems. Even in well-run environments, privileged change alerts catch mistakes that would otherwise create long-lived exposure.

A scenario rehearsal that ties these concepts together is a compromised account adding itself to administrative roles. In this scenario, the initial signals may be authentication anomalies, such as an unfamiliar device, unusual location, or multiple failed attempts before a success. Shortly after access is obtained, identity logs may show the account initiating role assignment changes, either granting itself an admin role directly or modifying a group or policy that results in elevated access. Control-plane and identity policy logs then capture the change details, including which role was granted and at what scope, which is essential for containment decisions. Token and session events may show new tokens issued with expanded scopes shortly after privilege is gained, followed by service usage that targets identity and governance functions. Responders should be able to confirm the sequence, revoke or reduce privileges, invalidate sessions where possible, and preserve evidence for later analysis. The critical value of identity logging here is that it provides a defensible narrative of how authority changed and how quickly the attacker attempted to exploit it.

Correlation strengthens identity investigations by connecting sign-ins with geography, timing, and service usage patterns that reveal intent and abnormality. Geographic anomalies can include logins from regions the user never operates in, but correlation must be applied thoughtfully because legitimate travel, remote work, and routing changes can create false signals. Timing patterns matter because many compromises occur during low-staffing hours to maximize dwell time, and unusual access during those windows can increase suspicion when combined with other indicators. Service usage patterns help identify misuse because legitimate users and service identities typically interact with a predictable set of services, and sudden expansion into identity administration, key management, or logging configuration often indicates malicious intent. Correlation also means linking identity events to the subsequent resource actions so you can see what the actor did with the access they obtained, which is essential for scoping impact. When correlation is strong, responders can move from detection to containment with confidence rather than speculation. The best identity logging strategies are designed with correlation in mind, ensuring shared identifiers and timestamps make the joining of events straightforward.

A memory anchor that fits identity logging well is a visitor logbook at every door. If you want to know who entered a building, when they arrived, and which doors they used, you need a consistent record, not a handful of partial notes. Identity logs are that record in cloud environments, because they show who attempted access, who succeeded, and how privileges changed after entry. A logbook that records only successful entries misses the pattern of repeated failures that often precedes compromise, and a logbook that cannot be reconciled across doors makes it impossible to trace movement. The anchor also reinforces that identity logging must exist everywhere, not just at the front door, because attackers often move through side doors such as service identities, federation paths, or token reuse. When the visitor logbook is complete and centralized, investigations become a matter of reading the record rather than inventing the story. That is the core reason identity logs matter so much.

As a mini-review, identity logging should cover authentication events, including failures, MFA prompts, and device context, because that is where compromise signals often begin. It should include session and token events so investigators can understand persistence and unusual token refresh behavior. It must capture role assignments and privilege changes with full metadata, because privilege escalation is a key turning point in many incidents. It should capture policy edits and trust relationship changes consistently, because those changes can create durable backdoors and cross-boundary access paths. It should capture access key creation and usage for nonhuman identities, because automation credentials are high-value targets and often abused quietly. High-signal alerts on privileged changes and new keys provide immediate value, and correlation across geography, timing, and service usage patterns turns raw events into usable investigation timelines. When these elements are present, identity logs support fast, confident response rather than slow, uncertain triage.

To conclude, the most important action is to confirm identity logging is enabled across all accounts, because partial coverage creates blind spots that attackers and accidents will eventually exploit. That confirmation should include both the capture of the critical event types and the centralization needed for investigation and response. It should also include retention that supports the organization’s response, audit, and forensic needs so evidence remains available when incidents are discovered late. Once identity logging is consistently enabled, you can tune alerts, improve correlation, and expand coverage with confidence, because the foundation is reliable. In practice, organizations rarely regret enabling identity logs broadly, but they often regret discovering too late that they did not. Confirm identity logging is enabled across all accounts.