DFIR Field Reference // v1.33 — 2026-11-07

Two Windows application-control features write the block and audit events above, and each one has an audit mode and an enforced mode. Find the line for the feature and the kind of file, then read across: the column tells you whether the file ran.

1. AppLocker — EXE and DLL rules log 8003 (allowed, but would have been blocked) and 8004 (blocked) in AppLocker/EXE and DLL. MSI and script rules log 8006 / 8007 in AppLocker/MSI and Script.
2. App Control for Business (WDAC) — files log 3076 (audit mode, would have been blocked) and 3077 (enforced, blocked) in CodeIntegrity/Operational, plus one 3089 for each signature of the file; match them on the Correlation ActivityID in the System data. Scripts and MSI files checked by script hosts log 8028 / 8029, with signatures in 8038, in AppLocker/MSI and Script.

Audit mode stops nothing, so 3076 and 8003 are a list of unapproved code that actually loaded or ran on the host. An 8029 is a block, but the script can still run in restricted mode. None of these events exist unless a policy is deployed, so an empty log is not evidence that nothing ran.

Each RDP event above answers one question about one stage of the session, and each stage writes to a different log on the RDP host. Read the figure left to right as time, top to bottom as log files.

1. Connect: 98 / 131 (RdpCoreTS) show the TCP connection and client IP; 1149 shows a user and source IP reached the host, but fires before authentication.
2. Authenticate: 4624 type 10 in Security is the RDP logon; failures land in 4625.
3. Session: 21 / 22 (LocalSessionManager) confirm the session logon and shell start.
4. Disconnect / reconnect: 4778 / 4779 and 23 / 24 / 25 mark the session dropping and resuming, then 4634 / 4647 and 23 close it. Pair them with the logon to get session duration.

On the client, RDP client MRU, RDP bitmap cache, Sysmon 3 and 4648 show where the session went and with which credentials. If logs were cleared selectively, 98 / 131 in RdpCoreTS can still show the connection.

One hop from host A (source) to host B (destination) is recorded in two places. Use the destination to prove that something arrived and the source to learn who or what launched it.

1. Destination (B) — the logon (4624 type 3 for SMB/WMI/WinRM, type 10 for RDP), the share touched (5140 / 5145), and the method's own trail: RDP 1149, 21 / 22, 98 / 131; WinRM 91 / 168; service install 7045 / 4697 (PsExec writes PSEXESVC).
2. Source (A) — explicit-credential use (4648), the process that opened the connection (Sysmon 3), and the RDP client MRU in NTUSER.DAT.

Pivot between hosts on the source IP in 4624/5140 and on the account name. Row-by-row detail is in the tables below.

Sysmon is a boot-start driver plus a service that write to their own event log. It records; it does not block, except for Sysmon 27 and Sysmon 28. The XML config decides what is kept, so the same event ID can be complete on one host and filtered out on the next.

1. Start at Sysmon 1: command line, parent, user, hashes and a ProcessGuid that stays unique even when Windows reuses the PID.
2. Follow the ProcessGuid into the stage events in the figure: files and DNS on delivery, DLLs and injection on execution, registry, WMI and drivers for persistence, Sysmon 10 on LSASS, connections and pipes for lateral movement.
3. Check Sysmon itself: Sysmon 4 (service state), Sysmon 16 (config change) and Sysmon 255 (errors) tell you whether the record is complete for your time window.

Before calling something absent, read the active config (sysmon64 -c). An exclude rule is not evidence of innocence.

The Logon Type field in 4624 / 4625 tells you how the session was created, so read it before the account name. Group the types by route: at the keyboard (2, 7, 11, 13), over the network (3, 8), remote desktop (10, 12), started by the system (4, 5) and alternate outbound credentials (9).

The last column of the table matters for scoping: types that leave credentials in memory (2, 4, 5, 9, 10) can be harvested from that host; Type 3 usually does not; Type 8 exposes the password itself. Types 7, 11, 12 and 13 are marked “—” in the table.

1. AS exchange — the client proves who it is to the DC and gets a TGT. The DC logs 4768 (or 4771 if pre-auth fails).
2. TGS exchange — the client presents the TGT and asks for a ticket to one service (SPN). The DC logs 4769.
3. AP exchange — the client hands the service ticket to the target server, which logs the logon itself (e.g. 4624 type 3). The DC never sees this hop.

Forged tickets show up as gaps in this chain: a Golden Ticket skips hop 1 (4769 with no 4768); a Silver Ticket skips hops 1–2 on the DC (only the service logs anything).

All three attacks change an object in Active Directory instead of stealing a password, so the first evidence is a directory change on the DC, not a logon.

1. Shadow Credentials — write to the target's msDS-KeyCredentialLink (logged as 5136), then authenticate with a certificate (PKINIT) and a 4768 carrying certificate info. No password changes.
2. AdminSDHolder / SDProp — an ACE is added to CN=AdminSDHolder,CN=System (5136, needs SACL / DS Changes auditing); SDProp (about every 60 min) copies it to all protected accounts and groups.
3. BadSuccessor (dMSA abuse) — on Windows Server 2025, create a delegated Managed Service Account in an OU (5137), then set msDS-ManagedAccountPrecededByLink to a privileged account and msDS-DelegatedMSAState = 2 (5136; both need a SACL). The KDC then issues the dMSA a TGT carrying the target's privileges, recorded as 2946 in the DC's Directory Service log.

Hunt the 5136 first, then the follow-on: PKINIT 4768s for accounts that never use certificates, or adminCount=1 accounts no longer in privileged groups, or a 2946 for a dMSA whose link points at a privileged account. For BadSuccessor, also check who holds CreateChild on OUs.

SIDs in an account's sIDHistory attribute travel with that account when it logs on, so whoever controls the attribute can give an ordinary user the rights of another SID, such as Domain Admins (RID 512). The same change can reach the directory two ways, and only one of them is logged.

1. Written on a DC — the DC records it under Audit User Account Management: 4765 when SID History is added, 4766 when the attempt fails, and the changed value also on 4738. Subject is who did it; Target Account, Source Account and SID List say to whom and what.
2. Pushed by a rogue DC (DCShadow) — the attacker registers a host as a Domain Controller (a GC/ SPN on its computer account, 4742 or 5136; an nTDSDSA object, 5137), replicates the change to a real DC, then unregisters (5141). The change arrives as replication, so there is no 4765 and the usual 5136 for it can be missing. Look instead for 4928 / 4929, replication RPC from a non-DC and a DRS SPN left behind.

Because one path is silent, check the directory itself as well: list every account with SID History (Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory) and use repadmin /showobjmeta to find changes whose originating DSA is not a known DC. An offline edit of ntds.dit also writes no 4765, and the same sweep finds it.

Microsoft Defender writes a plain-text troubleshooting log, MPLog-*.log, under C:\ProgramData\Microsoft\Windows Defender\Support\. It was not built as evidence, but it often still names a tool after Prefetch, the event logs and the binary itself are gone. Read it in three steps:

1. Search it first. String-search the log for the tool name, for example rclone.exe. It is plain text, so grep or a community parser both work.
2. Read the two kinds of line. An EstimatedImpact line names a ProcessImageName with scan Count / TotalTime / MaxTime: the process ran and touched files. A detection line records the file, the process and the Defender threat name.
3. Weigh it, then corroborate. It is a troubleshooting log, not a documented audit trail: entries are not complete and how far back it reaches varies, so a missing entry does not prove a tool never ran. Collect it together with the Defender event logs (1116 / 1117) and Quarantine.

The table below lists persistence mechanisms; the diagram groups the same rows by when they fire. Boot items run in system context before anyone logs on. Logon items run as the user when a session starts. Trigger items wait for a schedule, event or a particular program to launch. Use it as a sweep checklist: tick one location per column, then compare against a baseline. Grouping is a rough guide; some mechanisms (e.g. tasks) can also be set to run at boot or logon.

Windows lets LSA hand every new password to the DLLs listed in one registry value before it accepts the change. A legitimate filter enforces a password policy or syncs passwords; a rogue one simply keeps a copy. Read the figure in three steps:

1. What a filter sees. On a password change or reset, LSA asks each DLL in Notification Packages to validate the new password and passes it the plaintext: local accounts on any host, domain accounts on a domain controller.
2. Check the value. Read HKLM\SYSTEM\CurrentControlSet\Control\Lsa → Notification Packages (REG_MULTI_SZ, names without .dll). The default is usually only scecli. Any other name, unless it is a known password-policy or sync product, is a lead: find the DLL in C:\Windows\System32, hash it and check its signer.
3. Mind the timing. A new filter works only after LSA restarts (a reboot). Check the value on every DC before remediation resets passwords, or a rogue filter captures the new ones too. The same key holds the LSA / SSP packages values, which catch credentials at logon instead.

Every NTFS file has a record in the $MFT with two sets of timestamps. Timestomping tools rewrite the $STANDARD_INFORMATION ($SI) set, the one Explorer and most tools show. The $FILE_NAME ($FN) set is updated by the kernel (e.g. on rename/move), so it often keeps the real history. Compare the two, then check sources the attacker did not touch ($UsnJrnl, Prefetch, Amcache, event logs).

No single key answers "who used this stick, when, and for what". Each artifact answers one question and hands a key to the next:

1. USB — USBSTOR: which device. Vendor, product and serial number; the serial is the thread through everything else.
2. USB — first/last connect: when. setupapi.dev.log gives the first install time; the Enum key timestamps and the 0064 / 0066 / 0067 properties give the connect times.
3. USB — drive letter map: which letter and volume. MountedDevices (plus EMDMgmt before Windows 10 and Windows Portable Devices) ties the serial to a drive letter, volume name and volume GUID.
4. USB — user linkage: which user. The MountPoints2 {GUID} in a user's NTUSER.DAT matches the volume GUID in MountedDevices.

Then ask what was opened from it: LNK files record the volume serial and drive type (removable), Shellbags show folders browsed on removable media, and Office MRU and PCA list documents and programs opened from removable paths. Correlate the device serial across hosts to see where else the stick went.

Evidence disappears at different speeds. RAM and live network state change by the second and vanish on shutdown; files on disk persist. So you collect in order of volatility: capture memory first, then network state, running processes, disk triage, and a full image last. The checklist table below is the disk-triage step in detail; its Memory image row (“capture BEFORE shutdown”) is step 1. Record hashes and times as you go for chain of custody.

Start with the process view, then follow what looks wrong into the other plugins:

1. pslist / pstree for the tree, then psscan — a process present in psscan but missing from pslist is unlinked or terminated.
2. cmdline and netscan for what each suspicious process ran and talked to.
3. malfind, dlllist / ldrmodules and handles for injection, unlinked DLLs and lsass access.
4. filescan + dumpfiles to extract what you found; hashdump / lsadump / cachedump to scope credential exposure.

At any step, compare memory with the disk: svcscan finds memory-only service records, registry.hivelist / printkey shows Run keys as they were at capture time, and modscan / driverirp finds rootkit drivers.

The table below is ordered by artifact; the diagram groups the same rows by when the attacker's code runs. Boot items start with the system (units, kernel modules, a preloaded library, legacy RC scripts). Login / shell items run when a user session, shell or authentication happens. Trigger items wait for a schedule or a device event. Standing access items are not launchers: they are accounts, setuid binaries or sudo rules left behind so the attacker can return with privilege. Sweep one row per column, then compare file mtimes and package ownership. Grouping is a rough guide; a systemd unit can also be started by a timer.

RC scripts (rc.local / init.d) are the legacy boot launcher. On systemd before v260 an executable /etc/rc.local runs through rc-local.service and /etc/init.d scripts get generated units; systemd v260 removed both, so check systemctl --version before calling a script live, and check package ownership either way.

XDG autostart entries are the login launcher of Linux desktops: a .desktop file in ~/.config/autostart (one user) or /etc/xdg/autostart (every user) runs its Exec= command each time the graphical session starts, so they matter only on hosts with a desktop login. A user file with the same name overrides the system-wide one. Read the Exec= line and check package ownership of the system-wide entries.

The chips under the diagram open the row behind each box.

Package managers run other people's code as root by design, which makes their hooks a quiet place to persist: nothing new starts at boot, the command simply runs the next time someone updates or installs software. Two mechanisms matter. Read them in four steps:

1. Know what fires. APT reads every file in /etc/apt/apt.conf.d/: commands in APT::Update::Pre-Invoke run when package indexes are updated, and commands in DPkg::Pre-Invoke / DPkg::Post-Invoke run around each dpkg call, each one through /bin/sh as root. Separately, dpkg and rpm maintainer scripts (preinst, postinst, prerm, postrm) run as root whenever their package is installed, upgraded or removed. On dnf hosts, also sweep /etc/dnf/plugins/.
2. Sweep, then check who owns each file. grep -rn Invoke /etc/apt/apt.conf.d/ lists the APT hooks and rpm -qa --scripts prints the rpm scriptlets. Ask dpkg -S / rpm -qf which package owns each hook file. Files from a package, from your config management (Puppet, Chef, Ansible) or from a vendor agent are the usual false positive.
3. Read the command. An Invoke entry that calls curl or wget, a shell one-liner, or a script in a temp or hidden directory is suspicious, and so is dpkg -i of a local .deb started by an unusual parent process (T1546.016).
4. Time it. Package logs show when packages were installed or removed, that is, when the hooks had a chance to run; Temp & staging dirs hold the scripts a hook calls; the Audit log has the execve trail if auditd rules cover it.

The message of the day on Debian and Ubuntu is not a static file: it is built by scripts, and those scripts run as root at every SSH or console login, whoever logs in. That makes /etc/update-motd.d/ a login-triggered persistence point that needs no change to any user's shell files (T1037). Read it in four steps:

1. Know what fires. At login, pam_motd runs every executable script in /etc/update-motd.d/ through run-parts, in name order, as root, and caches the output in /run/motd.dynamic (/etc/motd is usually a symlink to it). A legitimate script is an NN-name file that only prints text.
2. Sweep, then check who owns each script. ls -la --time-style=full-iso /etc/update-motd.d/ gives the scripts and their full timestamps; dpkg -S /etc/update-motd.d/* names the package behind each one. Packages, cloud images and container runtimes add legitimate scripts, so compare an owned script with its package; a script no package owns needs reading.
3. Read the script. One that calls curl, wget or nc, opens a reverse shell or runs a file from a temp or hidden directory is persistence, and so is a MOTD run that spawns network tools or shells.
4. Time it. Every login in the Auth logs is one more run of every script; Temp & staging dirs hold the files a script calls; the Audit log has the execve trail if auditd rules cover it.

The table below is a flat list; the map groups the same rows by the question each one answers. Most incidents start with something arriving: Quarantine events and Safari history give the source URL and the time a file came in. Use that time as the pivot and walk the other groups.

1. Ran or used: the Unified log for process, auth, sudo and TCC activity; KnowledgeC.db and Biome streams for app usage and pattern of life (newer macOS moves data to Biome, so check both).
2. Typed: zsh history and Terminal's per-session files, which can hold commands the main history file lacks.
3. Files touched: FSEvents keeps create, modify, delete and rename history even after deletion, but without the process; recent items list documents, apps and servers a user opened, and .DS_Store lists names Finder has seen, which proves browsing, not execution. The Spotlight store indexes paths, timestamps and document attributes per volume; its entries can outlive the file, and a store on removable media can list the paths that were on it. Corroborate it with FSEvents.
4. Stays: launchd plists and the background task database (sfltool dumpbtm); compare one against the other. Also check the legacy launchers, Login / logout hooks & StartupItems: deprecated, but they still run as root.
5. Allowed: TCC.db shows current grants; the tccd lines in the unified log show the moment of a grant, even if the database row is later removed.

Collect live first: Info/Debug unified-log messages and tccd entries age out quickly, and Safari's database needs its -wal file. Many of these paths need Full Disk Access.

A container incident leaves evidence on four layers, and each one disappears on a different trigger. The pod holds the writable layer (Docker overlay diff) and the mounted service account token, and loses the writable layer when the container is removed. The node holds runtime state and kubelet / containerd logs until rotation or node recycle. The control plane holds the K8s API audit log, but only if audit logging was enabled. The cloud holds API logs for any cloud identity mapped to a service account.

1. Preserve from the top down: cordon the node and copy the writable layer and node logs before the pod or node is recycled.
2. Follow the attacker's reach down the stack: a privileged, hostPID or hostPath pod reaches the node; a stolen service account token reaches the API server; IRSA / Workload Identity carries that identity into the cloud.
3. Check the audit trail before scoping: a token minted with TokenRequest leaves no file on disk, so the API audit log is the only witness.

ESXi is a separate stack. Its logs live on a ramdisk and are lost on reboot unless remote syslog or persistent scratch is configured. For the same reason most system files do not survive a reboot, which makes ESXi boot persistence (local.sh) one of the few places a backdoor can live: diff it against a clean host of the same build.

kubectl exec, attach and port-forward change no object in the cluster: they open a stream to a pod that is already running. The API server records each one in the K8s API audit log as a request on the pods resource with a subresource (exec, attach or portforward). Read it in three steps:

1. Match both verbs. Older SPDY clients send an HTTP POST, logged as verb create. WebSocket clients send an HTTP GET, logged as verb get, and WebSocket is the kubectl default since 1.31. A hunt for create alone misses them.
2. Read who, from where and what. user.username is who ran it, sourceIPs is where from, and requestURI carries the command= arguments, so it shows what was started in which pod and namespace.
3. Know where it stops. Commands typed inside an interactive shell are not logged: the event shows the shell being opened, not what was done in it. The audit policy must log the pods/exec subresource at Metadata or Request level, or there is no event at all.

An exec by a human user or an unexpected service account into a production pod is hands-on-keyboard activity (T1609).

In Kubernetes RBAC a role lists permissions, and a binding gives that role to subjects (users, groups or service accounts). Creating or changing a binding is how an identity gains rights, so every create, update or patch on clusterrolebindings or rolebindings (API group rbac.authorization.k8s.io) in the K8s API audit log is worth reading. Read it in three steps:

1. Read the binding. user.username is who made the change, requestObject.subjects is who receives the role and requestObject.roleRef.name is which role. A ClusterRoleBinding grants it across the whole cluster; a RoleBinding grants it inside one namespace.
2. Spot the bindings that hand over the cluster. cluster-admin bound to a namespace service account, or any role bound to system:anonymous / system:unauthenticated. A new cluster-admin binding made by a service account or an unexpected user is privilege escalation and persistence (T1098.006). Bootstrap, upgrade and recovery tooling re-creating bindings is the usual false positive.
3. Follow the subject. From the binding's timestamp on, hunt what the subject did next: secret reads, privileged pods, DaemonSets. A service account appears in user.username as system:serviceaccount:<namespace>:<name>.

A cloud sign-in leaves evidence in several separate logs. The sign-in log is the starting point, but it is not the whole story.

1. Start in the sign-in log and note the linkable identifiers: User ID, Session ID, Unique Token Identifier, Resource Tenant ID.
2. Search the workload audit logs (M365 UAL, resource-side logs) for the same values. This separates what the stolen token did from what the real user did on the same account.
3. Corroborate with Graph activity logs (AppId, UserId, IP, RequestUri), if they were enabled before the incident.

Token replay keeps the same session ID across different IPs, so pivot on session/token ID, not just the UPN. If the sign-in log shows nothing, that is not proof of no access: check the other sources.

An illicit consent grant does not need the user's password. The user (or an admin) clicks Accept on an app's permission prompt, and the app (its service principal) then gets tokens of its own for the scopes it asked for.

1. Find the grant: search the Entra audit log / UAL for the activity Consent to application (Entra illicit consent grant). Note who consented, which app, and ConsentAction.Permissions. IsAdminConsent or OnBehalfOfAll = True means tenant-wide access.
2. Judge the scopes: offline_access gives the app a refresh token; together with Mail.ReadWrite, Files.ReadWrite.All or Chat.Read it fits mailbox and file theft.
3. Follow what the app did: search Microsoft Graph activity logs by the app's AppId, if they were enabled before the incident.
4. Evict it: revoke the grant and the service principal. Resetting the user's password does not remove it.

The same lesson applies to three other rows: a user-managed key from GCP service account key creation, a client secret or certificate found through Entra app / service principal credential added, and a rogue external MFA provider found through Entra Authentication Methods Policy audit all keep working after a password reset. Remove each one on its own. The UAL entry for a consent can take 30 min to 24 h to appear.

Run Command pushes a script into a VM through the VM agent, from the Azure control plane. There is no RDP or SSH logon on the host, so a hunt that starts from logon events misses it. The evidence is split between Azure and the VM:

1. Find the call in the control plane: in the Azure Activity Log, look for MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION. Note the caller (UPN or SPN), caller IP, time and correlationId.
2. Collect the result from the VM: the Azure VM Run Command plugin folder holds the downloaded script and its status or output, and the extension log records the run. On Windows the script runs as SYSTEM.
3. Pivot on the caller: the Activity Log is separate from the Entra logs, so look up how that UPN or SPN signed in through the Entra ID sign-in logs.

Two gaps decide the order of work: the Activity Log does not hold the script text, and it is kept only 90 days in Azure. Export the Activity Log and collect the plugin folder from the VM early.

In GCP an attacker often acts as a service account, not as themselves, and the calls that follow name the service account. A typical path has three steps, and each one is logged in a different place:

1. Grant: a role that lets a principal act as a service account (for example roles/iam.serviceAccountTokenCreator) is added. Find it through GCP IAM policy change (role grant): the Admin Activity log is always on, and bindingDeltas.action="ADD" lists every new grant.
2. Impersonate: the principal mints a short-lived token or signature as the service account. GCP service account impersonation covers these iamcredentials.googleapis.com calls, which are in the Data Access log only if it was enabled for the IAM API.
3. Act: calls made with the token show the service account as the principal. Read serviceAccountDelegationInfo for the human or workload behind it, and pivot from there.

If Data Access logging was off, step 2 left no record: work from the grant in step 1 and the delegation info in step 3, where the service records it. A GCP service account key creation is the long-lived alternative to step 2: the key keeps working after a credential reset until it is deleted or disabled.

AWS VPC Flow Logs record metadata about traffic, not the traffic itself. Each record answers four questions for one network interface (ENI) in one aggregation window of 1 or 10 minutes:

1. Which interface: account-id and interface-id tie the record to an ENI, and so to the instance behind it.
2. Who talked to whom: the 5-tuple srcaddr dstaddr srcport dstport protocol. Traffic to other hosts in the VPC shows lateral movement, traffic to outside addresses shows C2.
3. How much and when: packets and bytes between start and end, which is how exfiltration volume shows up.
4. Allowed or not: action (ACCEPT / REJECT) and log-status.

Some traffic is never logged, even with flow logs on: the Amazon DNS resolver, instance metadata (169.254.169.254), Amazon Time Sync, DHCP and ARP. Records hold no DNS names either, so for DNS use Route 53 Resolver query logs. Flow logs are off by default, not retroactive, and records can be skipped under capacity limits, so a missing record is not proof of no traffic. Removal of a flow log shows in AWS CloudTrail as DeleteFlowLogs.

One request to an S3 bucket can leave a record in up to three places, and which ones exist depends on what was switched on before the incident:

1. AWS CloudTrail management events: bucket configuration calls such as PutBucketLogging, kept 90 days in event history. Reading an object is not a management event, so it is not here.
2. CloudTrail S3 data events: object-level calls with the usual CloudTrail fields (userIdentity.arn, sourceIPAddress). Opt-in, so they exist only if a trail was already collecting them.
3. AWS S3 server access logs: one record per request to the bucket, including anonymous requests and requests that failed authorization (AccessDenied). Off by default.

A server access log record answers who (requester canonical user ID, authentication type), from where (remote IP), did what (operation such as REST.GET.OBJECT, and the key) and with what result (HTTP status, bytes sent). Runs of AccessDenied or anonymous requests point to bucket enumeration; successful GETs with bytes sent point to object download. Delivery is best-effort, so a missing record is not proof that no request was made. If logging stopped mid-incident, look for PutBucketLogging in CloudTrail.

An EBS snapshot is a full copy of a volume. Sharing it is a permission change: the recipient account then reads the disk in its own account, outside your logs. What you can see is in AWS CloudTrail (ec2.amazonaws.com), in three steps:

1. Make the copy: CreateSnapshot or CopySnapshot. A copy can carry a different KMS key, so note which key the shared snapshot uses and which call produced it.
2. Share it: ModifySnapshotAttribute with a createVolumePermission add. A user ID is the recipient account; group all makes the snapshot public. For an AMI the call is ModifyImageAttribute with launchPermission.
3. Use it: the recipient copies the snapshot or creates a volume from it. That runs in their account, but your trail gets the owner-side SharedSnapshotCopyInitiated / SharedSnapshotVolumeCreated events.

The snapshot's key decides what can leave: an unencrypted snapshot can be shared with any account or made public, an encrypted one can never be made public, and one encrypted with the default KMS key cannot be shared with other accounts at all. An add for an account outside your organization, or for group all, is exfiltration of a whole volume; sharing inside the organization is the usual false positive. The row is AWS EBS snapshot / AMI sharing.

In AWS IAM, what an identity can do and who may become a role are set by two different policies, and an attacker can change either one. Every change is an AWS CloudTrail event from iam.amazonaws.com, recorded in us-east-1 whatever Region the workload runs in.

1. The permissions policy (what it can do). Three ways to add rights: attach a managed policy (AttachUserPolicy / AttachRolePolicy / AttachGroupPolicy; requestParameters.policyArn names it), write an inline policy (PutUserPolicy / PutRolePolicy), or add a new version of a managed policy with CreatePolicyVersion and setAsDefault, which changes it for every identity it is attached to.
2. The trust policy (who may become this role). UpdateAssumeRolePolicy replaces it, and requestParameters.policyDocument holds the new version. An outside account ID or a broad principal there lets that account call AssumeRole into the role from outside; later use shows as AssumeRole events against the role ARN.

AdministratorAccess (or *:* inline) attached by a non-admin pipeline identity, or an external account added to a trust policy, is privilege escalation and persistence (T1098.003). IaC tooling (Terraform, CloudFormation user agents) is the usual false positive. Compare the old and new trust policy and restore it. New access keys and console passwords are the other way to keep access: see AWS IAM credential persistence.

Conditional Access policies decide which sign-ins must meet which controls, such as MFA or a trusted location. An attacker with enough rights can weaken them instead of fighting them, and every add, update or delete is recorded in the Entra ID audit logs (Service Conditional Access, Category Policy). Read it in three steps:

1. Find the change before it ages out. The activities are Add conditional access policy, Update conditional access policy and Delete conditional access policy; in Log Analytics they are in AuditLogs under OperationName. The audit log is kept 30 days by default unless it is exported through a diagnostic setting.
2. Diff old and new. TargetResources > modifiedProperties holds the policy JSON before and after the change. A new trusted IP range or named location, a removed MFA grant, a new user or group exclusion, or a policy switched to report-only or off is persistence and defense evasion (T1556.009).
3. Correlate with the actor's sign-ins. Check the Entra ID sign-in logs of the account that made the change, and the sign-ins the weakened policy now lets through.

A federated domain hands sign-in to an outside identity provider (IdP): the tenant accepts any SAML token signed by the certificate it trusts for that domain. Whoever controls that trust can sign in as any user in the domain without knowing a password, which is the trust change APT29 made in the SolarWinds campaign (T1484.002). Read it in three steps:

1. Find the change. In the Entra ID audit logs (Category DirectoryManagement, also in the UAL and in Log Analytics AuditLogs under OperationName), Set domain authentication converts a domain to federated and Set federation settings on domain changes the trust of a domain that is already federated. For a new domain, Add unverified domain and Verify domain come first.
2. Pull the configuration the event leaves out. The event names the domain but not the new settings. Run Get-MgDomainFederationConfiguration and compare the issuer URI and the signing certificates with your real IdP.
3. Treat any surprise as tenant-wide. Federation changes are rare: an unexpected one, a new secondary signing certificate, or a newly verified domain set to federated is a backdoor for every account in that domain, and resetting a user's password does not close it.

Opening an S3 bucket to an outsider takes a configuration change, and configuration changes are CloudTrail management events, so they are on record even when nobody was logging object reads. The "Who read the bucket?" diagram earlier in this section follows the reads; this one answers who opened the bucket. Read it in three steps:

1. Find the changes. In AWS CloudTrail (eventSource s3.amazonaws.com, 90 days in event history) look for PutBucketPolicy and PutBucketAcl, and for the Block Public Access calls that often come first: PutBucketPublicAccessBlock for one bucket, PutAccountPublicAccessBlock for the whole account. The bucket is in requestParameters.bucketName.
2. Read the grant. The policy JSON or the ACL grant in requestParameters names who was let in. A Block Public Access call that sets BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy or RestrictPublicBuckets to false removes a guard rail. An Allow for an account outside your organization, "Principal": "*", an AllUsers / AuthenticatedUsers ACL grant, or Block Public Access weakened shortly before a policy change is a bucket backdoored for exfiltration. Partner and vendor cross-account access is the usual false positive.
3. Follow the actor, then the reads. Pivot on userIdentity.arn and source IP. The reads that followed are data events, absent unless a trail was already collecting them; otherwise check AWS S3 server access logs, if logging was on.

In Google Cloud every log entry passes through the Log Router, which sends it on through sinks. Two are built in: _Required, which holds the Admin Activity and System Event audit logs, cannot be changed, excluded or deleted, and keeps 400 days; and _Default. The export sinks that feed a SIEM, BigQuery or Storage are the ones an attacker turns off. Read the figure in three steps:

1. Find the change. In the Admin Activity audit log (GCP Cloud Audit Logs, logging.googleapis.com) look for protoPayload.methodName google.logging.v2.ConfigServiceV2.DeleteSink, UpdateSink or DeleteBucket. Admin Activity entries go to _Required, so the tampering call itself stays on record.
2. Work out what was lost. A deleted or rewritten export sink stops logs reaching the SIEM, BigQuery or Storage export. Exclusion filters on the _Default sink override its inclusion filters, so an added or edited exclusion silently drops logs. A deleted log bucket stays pending for 7 days and can be restored.
3. Close the gap. Sink changes are not retroactive: logs routed while the sink was gone or filtered are never exported later, so read _Required for that window. List the sinks as they are now with gcloud logging sinks list. Infrastructure-as-code service accounts are the usual false positive.

Mailbox delegation gives a second account rights over someone else's mailbox. It is a quiet way to keep reading mail after the victim's account is cleaned up. Read the figure in three steps:

1. Four separate grants. FullAccess (Add-MailboxPermission) reads the whole mailbox but does not include Send As (Add-RecipientPermission) or Send on Behalf (Set-Mailbox -GrantSendOnBehalfTo). Folder permissions (Add-MailboxFolderPermission / Set-MailboxFolderPermission) given to Default or Anonymous on the root or Inbox let other accounts keep reading those folders. Check all four.
2. Read the ExchangeAdmin record. In the Unified Audit Log the target mailbox is in Parameters.Identity, the grantee in User / Trustee, the right in AccessRights and the caller in UserId. A FullAccess grant made with -AutoMapping $false does not appear in the grantee's Outlook: a quiet grant.
3. Remove the grant, not just the password. Delegation is tied to the grantee, so a password reset and session revocation on the victim leave it in place. List grants with Get-MailboxPermission / Get-RecipientPermission and remove them. The M365 Unified Audit Log row covers what else lands in the same log.