SC-200 is moving to a refreshed skills outline on October 21, 2026, while the July 28 English version is still current on October 7. Incident investigation remains one of the most stable parts of the role across that transition. Candidates need to move from alert to incident scope, correlate users, devices, mail, cloud activity, and other entities, inspect evidence in Defender XDR and Microsoft Sentinel, and decide what additional data is needed before containment. The blueprint date matters for exam weighting; disciplined evidence collection matters for every version.<\/p>\n
Incident investigation is the part of SC-200<\/a> where every other security-operations skill converges. Detections create alerts, correlation creates incidents, KQL expands evidence, threat intelligence adds context, Defender XDR connects entities, and automation handles repeatable tasks. The analyst still has to answer four questions: what happened, how far it spread, what is still active, and what must be done next.<\/p>\n Read the incident title and summary, but do not let them become your conclusion. Identify affected users, devices, mailboxes, applications, and cloud resources. Note the earliest alert, the highest-severity evidence, and whether containment has already occurred automatically. From that information, write a simple hypothesis such as “phishing led to credential theft and suspicious cloud sign-in” or “a user executed a malicious attachment that launched a downloader.”<\/p>\n A hypothesis gives the investigation direction. It tells you which evidence would support or disprove the story. As new data appears, update it. Good investigators are willing to abandon the first explanation when the timeline does not fit.<\/p>\n Build a timeline before deciding root cause: <\/strong>Chronology is one of the most reliable ways to understand a complex incident. Put authentication, email delivery, process execution, file creation, network connections, privilege changes, and cloud actions on the same mental timeline. The first detected event may occur after the attacker already established access.<\/p>\n Ask what must have happened immediately before each suspicious action. A process cannot execute before the file exists. A privileged cloud change requires an authenticated identity. A lateral movement event requires a source session or credential. Working backward often reveals the entry point that a product summary did not highlight.<\/p>\n Once you have one malicious artifact, search for it elsewhere. Look for the same domain, hash, command line, account, application ID, IP address, or unusual sequence across the environment. Advanced hunting is especially valuable because it lets you test custom questions that are specific to the incident.<\/p>\n Do not stop at exact indicators. Search for behavior too. If the attack used PowerShell with encoded commands, look for similar command-line patterns. If one account created suspicious OAuth consent, look for similar grants. If the attacker moved laterally using a remote-management tool, search for that tool’s execution and network behavior on other systems.<\/p>\n Investigate identities and devices together: <\/strong>Modern attacks frequently cross identity and endpoint boundaries. A stolen token can be used from a clean device. Malware on a workstation can harvest credentials that are then used in cloud services. Review the user’s sign-in history, risk, MFA events, device associations, privilege level, and application activity alongside endpoint evidence.<\/p>\n On the device, inspect process trees, timeline events, network connections, persistence mechanisms, and logged-on users. Determine whether the suspicious identity activity began before or after endpoint compromise. This ordering affects remediation: resetting a password without cleaning the endpoint can simply expose the new credential again.<\/p>\n Check suspicious domains, IPs, URLs, and file hashes, but interpret reputation with care. A high-confidence malware hash is strong evidence. A cloud-hosted IP may be shared. A newly registered domain may be suspicious but not inherently malicious. Combine intelligence with observed behavior in the affected environment.<\/p>\n If an IOC is confirmed, use it to widen the search. Historical sightings can reveal the true start of the incident or additional assets that were not part of the original correlated case.<\/p>\n Look for persistence and privilege change: <\/strong>An incident is not contained merely because the visible process stopped. Search for scheduled tasks, services, startup mechanisms, new accounts, application credentials, OAuth grants, role assignments, mailbox rules, unusual tokens, or configuration changes that could preserve access.<\/p>\n Privilege changes deserve special attention because they can turn a local compromise into an enterprise incident. Determine which identity performed the change, whether the action was expected, and what resources the new privilege can access. If the attacker obtained an admin identity, the investigation scope expands immediately.<\/p>\n Containment should break the attacker’s active paths. That might mean isolating an endpoint, disabling or resetting an account, revoking sessions, removing malicious email, blocking an indicator, or suspending an application credential. The order matters. If the compromised endpoint remains online while you rotate credentials, the attacker may capture the new credential.<\/p>\n High-impact systems require coordination. Isolating a production server or disabling a privileged service account can cause an outage. Security and business teams may need an alternative containment step while evidence is preserved and a controlled recovery is prepared.<\/p>\n Remediation is broader than containment: <\/strong>Containment stops ongoing activity. Remediation removes the attacker’s foothold and closes the weakness that allowed access. Delete persistence, patch exploited vulnerabilities, remove malicious applications or consent grants, reset credentials, correct misconfigurations, and verify clean state. Then monitor for recurrence.<\/p>\n Recovery should be evidence-based. Reconnecting a device because antivirus is quiet is not enough if the root cause was stolen credentials. Restoring a user account without checking delegated permissions can leave attacker access intact.<\/p>\n Record what was investigated, what evidence supports the classification, which entities were impacted, what response actions occurred, and what remains open. Use incident comments and tasks for operational continuity. A case that depends on one analyst’s memory is fragile.<\/p>\nEstablish a working hypothesis quickly<\/h3>\n
Expand the blast radius with KQL<\/h3>\n
Use threat intelligence as context, not proof<\/h3>\n
Contain in an order that prevents re-entry<\/h3>\n
Document decisions so the next analyst can continue<\/h3>\n