Technical indicators provide concrete, searchable artifacts that can be systematically hunted across the environment:

File-based Indicators: These indicators include malware hashes, suspicious filenames, or specific file paths used by attackers. A single malicious executable discovered on one system should trigger searches across all systems for the same file hash, similar filenames, or files in unusual locations.

Network Indicators: These indicators are broad but particularly valuable, allowing organizations to leverage investigative insight to quickly assess a large number of systems. Network indicators include IP addresses, domain names, URLs, network signatures, and other network anomalies (often characterized by Network Detection and Response (NDR) platforms), including unusual network activity patterns. For example, if an investigation reveals anomalous network activity attributed to an attacker command-and-control (C2) server, scoping should identify all systems that have communicated with that attacker infrastructure. This level of analysis may reveal additional compromised systems not yet exhibiting obvious symptoms.

Process and Service Indicators: These indicators include suspicious process names, service names, scheduled task names, command-line arguments, and any other process-launch configuration details. Attackers often use consistent naming patterns across compromised systems, making these valuable for scoping. Randomly-named processes or services can also be valuable indicators, since they deviate from normal system behavior.

Registry and Configuration Indicators: These indicators involve specific keys, values, or configuration changes within the system registry. PowerShell scripts stored in registry values, WMI event subscriptions, or modified system settings can serve as IOCs for broader searches. Similarly, non-Windows systems may have comparable indicators revealed in configuration files (e.g., ASCII-based or encoded data, including macOS property list files).

Account-based Indicators: These indicators include unauthorized user accounts, suspicious account usage patterns, or privilege escalations. An attacker-created account on one system warrants immediate investigation for similar accounts throughout the organization.

Beyond static technical indicators, behavioral patterns can reveal attacker activity that may not be captured by traditional IOCs. Behavioral indicators often require more sophisticated analysis but can uncover widespread compromise that static indicators miss.

Temporal Patterns: Temporal patterns observed in logging data, SIEM trend analysis, or aggregate network investigations may indicate coordinated activity across multiple systems. Simultaneous logons, synchronized file modifications, or regular beacon intervals can indicate widespread compromise even when individual events appear benign. Attackers often operate on consistent schedules, creating predictable patterns that become visible when analyzed across the environment.

Data Movement Patterns: These patterns show unusual data flows between systems or to external destinations. Large data transfers, especially during off-hours, may indicate exfiltration activities. Systems that do not typically communicate but are suddenly transferring large amounts of data warrant investigation as potential indicators of data staging or exfiltration.

Lateral Movement Indicators: These indicators include authentication, remote access, or service usage patterns that indicate an attacker moving between systems. Pass-the-hash attacks, remote desktop sessions, or WMI usage for remote execution leave distinctive patterns that differ from normal administrative activity. Multiple authentication attempts across many systems in a short timeframe often reveal automated lateral movement tools.

After identifying an IOC, analysts should search for matching evidence across the organization. This analysis should start with centralized log analysis tools, including SIEM platforms, log aggregation systems, or other data resources to quickly search collected logging data across the environment. Starting with log analysis typically provides rapid initial results, though it requires that the organization already have comprehensive log collection in place.

Endpoint Detection and Response (EDR) platforms are also particularly valuable for searching and identifying IOCs across all managed endpoints. Modern EDR tools enable analysts to run complex queries that can find files, processes, network connections, and registry modifications across thousands of systems. When EDR systems are not available, analysts should consider inventory management tools, active scanning tools to probe systems for IOCs, network scans to identify specific services (such as open ports), authenticated scans for file presence, or specialized compromise assessment tools including custom PowerShell or shell scripts.

For comprehensive scoping, analysts should use threat-hunting platforms that combine multiple data sources into a single interface. Platforms that integrate endpoint, network, and logging data provide the broadest view of potential compromise indicators. By combining these data sources in a single platform, analysts can use overlapping analysis coverage to reduce the chance of missing compromised systems.

Given resource limitations, scoping often proceeds in phases rather than attempting to investigate the entire environment simultaneously.

Critical Asset Prioritization: This approach focuses initial scoping on high-value systems, including domain controllers, file servers, databases, and systems containing sensitive data. These systems warrant immediate attention regardless of initial IOC location. Sometimes referred to as pivoting in an investigation, critical asset prioritization ensures that the most important organizational assets are quickly assessed and protected.

Lateral Expansion: This phase extends scoping to systems directly connected to known-compromised hosts, including those on the same network segment, those with recent authentication from compromised accounts, and those sharing administrative credentials. Lateral expansion follows the likely paths an attacker would take to move through the environment.

Environmental Sweep: This phase eventually extends to all systems in the environment, ensuring no compromised systems remain undiscovered. Environmental sweeps may occur over days or weeks for large organizations.

Organizations rarely have complete visibility across their entire environment, creating blind spots that attackers can exploit. Unmanaged systems including Bring Your Own Device (BYOD) endpoints, shadow IT infrastructure, and legacy systems may harbor compromise and escape standard scoping tools. These systems often exist outside the organization’s asset inventory, making them difficult to assess during incident response. Even when analysts know these systems exist, they may lack the necessary access credentials or management tools to search for IOCs.

Limited logging on certain systems or classes of systems presents another visibility challenge. This is particularly true for legacy systems, embedded devices, and industrial control system (ICS) platforms that lack robust logging capabilities. Network devices, printers, and Internet of Things (IoT) devices often generate minimal logs or store logs only temporarily, restricting the ability to scope historical compromise. When analyzing these systems, responders should look for alternative evidence sources including network flow data, authentication logs from connected systems, or physical evidence of unauthorized access.

For example, consider the Siemens S7-1200, a widely-deployed programmable logic controller used in manufacturing, water treatment, building automation, and other industrial control environments. Despite having a built-in Ethernet interface, a full TCP/IP stack, and an integrated web server for diagnostics, the S7-1200 lacks the centralized logging capabilities found in modern IT systems. While the PLC maintains internal diagnostics including connection tables and error counters accessible through its web interface, it does not generate syslog events, forward logs to SIEM platforms, or provide the historical audit trails that incident responders rely on for timeline reconstruction. For many organizations, network flow data becomes the primary source of evidence for determining whether industrial control systems like the S7-1200 have been accessed or manipulated during an incident, making comprehensive network visibility essential in ICS environments.

While network flow data is valuable, it has its own limitations. Most enterprise switches export flow data using packet sampling by default, often at ratios of 1:1000 or higher. Sampling at these rates can miss short-lived connections or the low-volume C2 beaconing characteristic of targeted attacks. Analysts should verify the configured sampling rate for network flow capture devices and, where feasible, request unsampled export on paths carrying high-value traffic.

OT environments face a more severe constraint: many industrial switches lack the processing capacity to generate flow data at all, and those that do often produce sampled output that misses the low-volume protocol traffic typical of ICS. Purpose-built OT monitoring tools provide passive protocol-aware visibility without imposing load on the control network, parsing industrial protocols such as Modbus, DNP3, and S7comm to extract asset inventories and communication baselines that general-purpose flow tools cannot produce. Commercial platforms such as Dragos provide turnkey capabilities for threat analysis, and open-source alternatives include Malcolm from Idaho National Laboratory and Zeek extended with the ICS Network Protocol Parsers (ICSNPP) package. See Incident Response for Operational Technology for guidance on scoping in OT environments.

Cloud and hybrid environments require different scoping approaches than traditional on-premises infrastructure. Serverless functions, containers, and cloud-native services may not be visible to traditional scoping tools designed for Windows endpoints. Organizations should ensure their scoping strategies include cloud-specific tools and techniques, such as cloud provider APIs, container runtime security tools, and cloud-native logging services. The ephemeral nature of many cloud resources means that evidence can disappear when resources are deallocated, making timely scoping critical.

Sophisticated attackers actively work to impede scoping efforts by employing anti-forensic techniques to hide their presence and confuse investigators. Recognizing these techniques helps responders develop counter-strategies and avoid drawing incorrect conclusions from manipulated evidence.

Log deletion or modification removes evidence of attacker activity, creating gaps in timeline reconstruction and making it difficult to identify all compromised systems. Attackers may delete specific log entries related to their activities or clear entire log files to cover their tracks. To counter this, analysts should look for evidence of log manipulation itself, including gaps in log timestamps, unusual log file sizes, or security events indicating log clearing. An example of a Windows Event Log indicating log deletion is shown in Figure 4.

Collecting logs from multiple sources can also help reconstruct attacker activity even when some logs have been deleted. When multiple log sources are not available, analysts can sometimes infer deleted events by correlating with network logs or other system events. For example, on Windows systems, each logging event is assigned a sequentially incrementing event record ID (viewable in Event Viewer by clicking Details | XML View). Gaps in event ID sequences may indicate deleted log entries.

Sophisticated attackers may also manipulate logs without deleting them. Log replay and flooding techniques pollute the log stream to obscure malicious activity, for example, by replaying legitimate events to make an attacker session blend with normal traffic, flooding the SIEM to cause event drops, or spacing detectable events below alert thresholds. Countering these techniques requires baseline understanding of expected log volumes, alerting on sudden surges or unusual quiet periods, and correlation across independent log sources that are unlikely to be manipulated in a coordinated way.

Timestomping modifies file timestamps to hide the timing of malware installations or blend malicious files with legitimate system files. Attackers use timestomping to make recently installed malware appear as though it has been present since system installation. When analyzing systems where timestomping is suspected, analysts should examine alternative timestamp sources including filesystem metadata ($MFT entries on Windows), backup system records, or network detection timestamps for file downloads.

Encryption and obfuscation hide indicators from automated scanning tools, requiring manual analysis to identify compromise. Attackers may encrypt malware payloads, obfuscate PowerShell commands, or use packing techniques to avoid signature-based detection. Network traffic encryption can similarly hide C2 communications from network-based scoping tools. Behavioral analysis and memory forensics often prove more effective than signature matching when dealing with encrypted or obfuscated threats.

Living-off-the-land techniques use legitimate system tools like PowerShell, Windows Management Instrumentation (WMI) utilities including wmic.exe and mofcomp.exe, and .NET Framework tools (csc.exe, installutil.exe, and others), making it difficult to distinguish malicious activity from normal administrative operations. Attackers choose these techniques specifically to blend in with normal activity and avoid detection during scoping. Analyzing command-line arguments, execution context, and temporal patterns helps identify malicious use of legitimate tools. Establishing baselines of normal administrative activity provides a reference point for identifying anomalies, and behavioral detections augmented with machine learning can surface deviations that static rules miss.

Large, complex environments present practical scoping challenges that can overwhelm even well-resourced incident response teams. Organizations should develop strategies to manage these challenges while maintaining comprehensive scoping.

The sheer volume of data generated during scoping can overwhelm analysis capabilities and delay incident response. Searching for IOCs across thousands of systems generates significant volumes of log data, file listings, and process information requiring analysis. Analysts should prioritize scoping efforts using the progressive scoping methodology described earlier, focusing first on high-value targets and known-compromised systems before expanding to the broader environment. Automation tools can help process large data volumes, though analysts should still validate automated findings to avoid missing sophisticated attacks.

False positives from legitimate software or normal activity that matches IOC patterns complicate scoping and consume investigative resources. Each potential match requires investigation to determine whether it represents a genuine compromise or benign activity. For example, searching for a malware filename might match legitimate software that happens to use a similar name, or network IOC searches might identify VPN connections that look suspicious but are actually legitimate. Documenting known false positive sources helps streamline future investigations and reduce analysis time.

Dynamic environments where systems are constantly created, modified, or destroyed present unique scoping challenges, particularly in cloud environments using auto-scaling or containerized workloads. Compromised systems may be automatically destroyed before analysts can examine them, and new systems may be created with embedded compromise from tainted images. In these environments, analysts should focus scoping efforts on examining system images, container registries, and infrastructure-as-code templates in addition to running systems. Organizations should implement logging solutions that capture system state even for short-lived resources, ensuring evidence persists after system destruction.

Cloud scoping often requires querying audit logs to trace compromised identities and unauthorized resource activity. Each major cloud provider offers equivalent audit log capabilities with different query syntax. Table 1 provides a quick reference for translating common audit log queries across providers.

These commands provide a starting point for cross-platform audit log analysis during scoping investigations.

Renee is an incident response analyst supporting a mid-sized SaaS company. A product manager reported suspicious activity on her workstation after opening a document received through a LinkedIn direct message from someone claiming to be an industry analyst. The document promised a leaked competitive analysis of the company’s closest rival. Renee was asked to analyze the document and determine whether it contained any malicious content.

Renee performed initial analysis of the document using a dedicated workstation isolated from the corporate network, beginning with file size, hash, and file type identification using the Fileutils file command, as shown in Listing 2.

The document appeared to be a standard PDF file, but Renee wasn’t yet ready to open it in a PDF viewer. She extracted summary information about the PDF structure using Pdfinfo, as shown in Listing 3.

The output of pdfid.py revealed that the PDF is a single page, but includes six embedded URIs. Renee extracted the URIs using pdf-parser.py, as shown in Listing 4.

Renee noted three suspicious URLs embedded in the PDF across six references. The URLs pointed to a DuckDNS dynamic DNS domain and a suspicious domain hosting two executable files. With this new insight, Renee noted several elements to use for subsequent scoping activities:

Renee documented the scoping indicators she had identified so far and continued her analysis of the PDF document while searching for additional impacted systems across the organization.

Priya is a cloud security analyst for a financial services company that uses Azure for both production applications and data storage. She received an automated alert from Microsoft Defender for Cloud indicating a new Blob Storage container named backup-data-archive-2025 was created in the stcorpdata01 storage account three days ago. She double-checked Teams, but there was no associated change order for the new container. The container name followed common internal naming conventions, but the creation timestamp showed it was created at 11:47 PM on a Saturday, well outside normal business hours. Priya began her investigation to determine if this was an IOC.

Priya started by examining the contents of the suspicious container using the Azure CLI, as shown in Listing 5.

The container held 47 blobs totaling approximately 8.2 GiB. The filenames indicated highly sensitive internal data, including payroll information, customer data, intellectual property, and legal contracts. The directory structure (HR/, Finance/, CustomerData/, Engineering/, Legal/) matched the organization’s internal file server layout exactly. All blobs showed upload timestamps within a twenty-minute window on the same Saturday night the container was created.

Next, Priya investigated who created the container by querying the Azure Activity Log, as shown in Listing 6.

The Activity Log event was disconcerting. Priya cross-referenced the caller’s object ID with Entra ID and confirmed it was the svc-automation service principal, a legitimate identity used by various automated processes throughout the organization. However, the source IP address 203.0.113.88 was neither an internal system nor a known Azure resource. She noted this as a possible indicator that the service principal credentials had been compromised and were being used by an external attacker.

Priya expanded her investigation to identify all activity performed by the compromised service principal, as shown in Listing 7.

The compromised service principal showed extensive unauthorized activity over five days. The caller enumerated role assignments, performed reconnaissance of existing virtual machines, obtained storage account access keys, and granted the service principal additional permissions through a new role assignment. Then they modified network security group rules, launched a virtual machine, and created the unauthorized container. Priya also queried the storage account’s diagnostic logs and identified 47 blob upload operations on October 19th corresponding to the files in the unauthorized container.

Priya performed additional Activity Log and storage diagnostic log queries to trace the source of the blob uploads. She discovered that while the container was created from the external IP address 203.0.113.88, the uploads originated from a virtual machine at internal IP address 10.0.50.15 within the organization’s Azure virtual network. This event matched the virtual machine created on October 17th, indicating the caller had established infrastructure within the Azure environment to facilitate data exfiltration from internal resources.

Confident she was looking at the actions of an attacker who had compromised the svc-automation service principal, Priya documented the indicators of compromise discovered during her investigation:

With these IOCs identified, Priya initiated enterprise-wide scoping activities to determine the full extent of compromise and exfiltration across the Azure environment, as shown in Table 2.

The extended activity search revealed that the service principal had been accessed from the external IP address as early as October 8th, more than a week before the first management operations Priya had initially identified. The role assignment query confirmed that the attacker had granted the service principal Contributor access to a second resource group, rg-analytics-eastus2, expanding the potential scope of compromise beyond the production environment.

Priya compiled a summary of her scoping findings for the incident commander, including the confirmed timeline of attacker activity, the scope of compromised resources across both resource groups, an assessment of the volume and sensitivity of exfiltrated data, and recommended next steps for containment. This summary provided leadership with the context needed to make informed decisions about notification obligations, containment priorities, and resource allocation as the investigation continued.

Categorize the IOCs handed off from verify and triage into the canonical inventory used for sweeps. Representative IOC categories include:

This is the IOC-driven sweep during a verified incident, distinct from the standing hypothesis-driven hunting program owned by detect. Representative activities include:

Representative activities include:

Scope owns the canonical attack-progression timeline; subsequent activities annotate it (eradicate adds eradication-sequencing markers; debrief consolidates into the final narrative). Representative activities include:

Representative activities include:

Representative activities include:

Hand off the scoped system list, the canonical IOC inventory (Step 1), and the attack-progression timeline (Step 4) so each downstream activity can build on settled artifacts rather than re-derive them.