7 Threat Analysis Practice

Purpose and limits of threat analysis

Threat analysis turns incomplete technical evidence into decisions about what may be happening, what is at risk, and what to do first. An indicator does not by itself prove that an incident occurred, and neither an indicator nor a single alert proves who is responsible. Analysts correlate evidence, build a timeline, and revise their assessment as new facts emerge.

Build an evidence-based assessment

Begin by identifying the systems, accounts, data, and services that may be affected. Consider what interruption, theft, or alteration of each could mean for the organization.

Keep observed facts separate from inferences. For example, record a new mailbox rule as an observation and account takeover as a hypothesis, rather than treating the hypothesis as established fact.

Develop a threat hypothesis by considering plausible motives, including financial gain, espionage, disruption, or insider misuse, along with likely attack methods. State the confidence level and alternatives. Identifying likely behaviors generally requires less evidence than attributing activity to a particular group.

Look for related signs across the attack chain: initial access, execution, credential access, persistence, lateral movement, collection, exfiltration, or impact. MITRE ATT&CK can help organize this investigation by tactics and techniques, but it does not prove who carried out the activity.

Correlate indicators and build a timeline

Indicators can include unusual sign-ins, unexpected account or configuration changes, suspicious processes, disabled security tools, and unexplained outbound data transfers. A single indicator may have a legitimate explanation; combinations of indicators and their timing provide more useful context.

Collect and correlate logs, document findings, and update the investigation scope as evidence develops. Use the evidence to build a timeline and assess whether observed events may be connected, while keeping facts distinct from interpretations.

Prioritize risk and order response

Assess risk by considering both likelihood and impact. Adjust the assessment for exposure, evidence of active exploitation, asset criticality, scope, and available safeguards. A qualitative scale of critical, high, moderate, or low can help communicate priority, but explain the reasons rather than relying on a score alone.

Prioritize according to active harm, business impact, exposure, and potential scope—not a single alert or indicator. Recommendations should be ordered to contain active harm, protect affected accounts and systems, preserve evidence, remove the cause, recover safely, and improve detection and prevention. Coordinate with incident-response leadership and follow organizational procedures.

Case: Changed payroll account

A payroll employee approved an unexpected multifactor-authentication prompt. Sign-in logs showed access from an unfamiliar location, and a new inbox-forwarding rule appeared shortly afterward. Then a request arrived to change a supplier’s payment details.

Together, the prompt approval, unfamiliar sign-in, and mailbox rule support an account-compromise hypothesis. The payment-change request suggests possible financial fraud, while the forwarding rule may expose future correspondence. A financially motivated criminal is plausible, but the evidence does not identify a specific actor. The employee’s account and the payment workflow are at immediate risk.

Treat the incident as high priority because the account may still be usable and fraudulent payment could cause direct loss. Contact the employee through a trusted channel; disable or secure the account, revoke active sessions and tokens, reset credentials, remove unauthorized rules, and review recent sign-ins and mailbox activity. Pause payment changes and verify them independently.

Preserve relevant logs and messages, then check for other affected accounts. Strengthen authentication, especially with phishing-resistant multifactor authentication where feasible, and require independent approval for payment changes.

Case: Exposed remote-access appliance

An internet-facing remote-access appliance was running an outdated version with a known security flaw. Its logs showed unusual requests followed by creation of a new administrator account. Soon afterward, the appliance connected to an unfamiliar external address.

The unpatched software is a vulnerability; the suspicious requests, new account, and unexpected connection are potential indicators of compromise. Together, they support a hypothesis of exploitation followed by persistence or remote control. An opportunistic attacker is possible, but targeted activity cannot be ruled out. Because the appliance is exposed and may provide access to internal systems, the potential blast radius is large.

Treat the incident as critical until investigated. Follow incident procedures to restrict or isolate the appliance without destroying evidence, and involve the system owner and security team. Preserve logs and configuration, investigate whether the account or connection is unauthorized, and assess related accounts and internal systems.

From a clean management path, apply the vendor’s fix or replace the appliance, remove unauthorized access, rotate potentially exposed credentials, and review remote-access permissions. Add monitoring for unusual administrative changes and sign-ins. Software exploitation is one possible route to credential access, and software updates are a mitigation.

Case: Vendor update and unavailable backups

After a routine software update, several servers began contacting unfamiliar domains. A service account ran the updated software across multiple systems, endpoint protection stopped reporting from two servers, and one backup repository became inaccessible.

The timing raises a supply-chain compromise hypothesis, but a faulty update, configuration change, or separate intrusion could also explain the signs. Multiple affected servers, reduced visibility, and inaccessible backups suggest possible expansion and impact. The service account may provide a route across systems. Establish whether the update is authentic, which systems received it, and whether the network activity and backup changes are authorized.

Treat the incident as critical because core systems and recovery capability may be at risk. Escalate to incident response and contact the vendor through trusted channels. Contain affected systems in a way that preserves evidence; protect unaffected backups and verify their integrity from a separate, trusted environment.

Review endpoint, network, identity, and vendor-update records to establish a timeline and scope. Disable or rotate the service account if evidence supports compromise. Restore only after the environment is understood and controlled, and test recovery. Improve vendor-notification requirements, software approval, protected logging, and regularly tested backups. Incident-response plans should be practiced, security logs collected and protected, and backups stored separately and tested on a recurring basis.

Apply the core principles

Effective threat analysis distinguishes vulnerabilities from indicators, correlates evidence before drawing conclusions, and treats actor attribution cautiously. Prioritize according to active harm, business impact, exposure, and potential scope. Contain and investigate promptly, preserve useful evidence, close the exploited weakness, and verify recovery. Frameworks such as MITRE ATT&CK help describe observed behaviors and support analysis, but do not by themselves establish who attacked.

• indicator of compromise (IOC)

• account compromise