Digital forensics focuses on the past: it recovers and analyzes electronic evidence to reconstruct what happened during an incident, usually to support investigation, remediation, or legal proceedings. Threat intelligence focuses on the future and present: it collects and analyzes information about adversaries, their tools, and their intentions so defenders can anticipate and prevent attacks. The two disciplines complement each other. Forensic findings reveal the indicators and techniques an attacker used, which feed intelligence products. Intelligence about current campaigns helps investigators know what to look for. A security team handling a ransomware event may use forensics to determine the entry point and intelligence to identify the attacking group and its known tactics.
Evidence integrity means that digital material remains in the same state from collection through analysis and presentation. Investigators demonstrate this by creating a forensic image, a bit-for-bit copy of a storage device, and calculating cryptographic hash values such as SHA-256 for the original and the copy. Matching hashes show that the copy is identical to the source. Every subsequent working copy is verified the same way, and all hashes are recorded. A chain of custody log documents who handled the evidence, when, and why. Analysts work only on copies, write-blockers prevent accidental modification of source media, and any unavoidable change is documented so a court or reviewer can assess its impact.
Volatile memory, such as RAM, is erased when a system is powered down, so it must be captured early in an investigation before the machine is shut off or rebooted. Memory captures can reveal running processes, open network connections, loaded drivers, decrypted data, encryption keys, command histories, and injected code that exists only in memory. Many fileless attacks leave little on disk, making memory analysis especially valuable. Collection tools must be run from trusted media to avoid being fooled by compromised system utilities. Responders record the time and method of acquisition because the act of collecting memory alters the system slightly. Capturing volatile data first is a standard order-of-volatility principle in incident response practice.
File system metadata, including creation, modification, access, and change timestamps, records when files were touched and provides structure for reconstructing events. Analysts parse the file system, such as NTFS, ext4, or APFS, to extract file listings, deleted entries, and allocation information. Combining these artifacts into a timeline allows investigators to correlate file activity with logins, program execution, and network events. For example, a timeline may show a suspicious executable being written to a temporary folder minutes before a scheduled task was created. Deleted files can sometimes be recovered through carving or residual directory entries. Because timestamps can be altered by attackers or by normal system operations, analysts corroborate them with other artifacts rather than relying on any single value.
Windows systems retain numerous artifacts that show what programs ran and what users did. Prefetch files indicate that an application was executed and how often. The Amcache and Shimcache artifacts record executable paths and metadata. Registry hives contain user activity data such as recent documents, typed paths, and the UserAssist records of launched programs. Event logs record logons, service installations, and process creation when auditing is enabled. Jump lists and LNK files show recently opened items. Because each artifact has different retention behavior and can be cleared or overwritten, analysts examine several sources together. Interpreting them requires understanding how each artifact is written, which is why reliable conclusions depend on documented methodology and tool validation.
On Linux, key sources include authentication logs such as auth.log or secure, system logs in the journal, shell histories, cron and systemd configurations, and SSH authorized keys files. Investigators also check modified binaries, unexpected setuid files, and persistence through init scripts or user profiles. On macOS, analysts examine unified logs, launch agents and daemons, the quarantine and download database, and browser artifacts. Both platforms store login records and network configuration that help establish timelines. Attackers often attempt to edit or delete logs, so analysts compare local records with centralized logging where available. Because operating system versions change log formats and locations, examiners confirm the artifact behavior for the specific version under review before drawing conclusions from it.
Network forensics examines packet captures, flow records, DNS queries, proxy logs, and firewall data to reconstruct communications between hosts and external systems. Analysts can identify command and control channels, data exfiltration volumes, lateral movement between internal machines, and the domains or addresses contacted. Flow metadata often remains available even when payloads are encrypted, which is valuable because most modern traffic is encrypted. Limitations include incomplete capture coverage, short retention periods, and the difficulty of attributing traffic to a specific user when addresses are shared or translated. Analysts therefore correlate network data with endpoint evidence. A DNS query to an unusual domain, followed by a large outbound transfer from the same host, is a far stronger indicator than either event alone.
The threat intelligence lifecycle typically includes planning and direction, collection, processing, analysis, dissemination, and feedback. Planning defines the questions stakeholders need answered, such as which threats target the organization's sector. Collection gathers data from sources including open-source reporting, sharing communities, malware repositories, and internal telemetry. Processing normalizes and organizes raw data. Analysis interprets it to assess adversary intent, capability, and likelihood of targeting. Dissemination delivers findings in forms suited to each audience, from detailed indicators for analysts to strategic briefings for executives. Feedback evaluates whether the output met requirements and refines future collection. Treating the cycle as continuous rather than a one-time report keeps intelligence relevant as adversaries change tactics.
9
Indicators and TTPs
What is the difference between an indicator of compromise and a tactic, technique, or procedure, and why does the distinction matter?
An indicator of compromise is a specific observable artifact, such as a file hash, IP address, domain name, or registry key associated with malicious activity. Indicators are precise and easy to automate, but they are also short-lived because adversaries can change infrastructure and recompile tools quickly. Tactics, techniques, and procedures describe adversary behavior at a higher level: the goals they pursue, the methods they use to achieve them, and the specific ways they implement those methods. The MITRE ATT and CK framework is a widely used catalog of such behaviors. Defenders value TTP-level intelligence because detections built on behavior remain effective even when indicators change, though it usually requires more analytical effort to develop and validate.
Static analysis examines a sample without executing it. Analysts inspect file format, embedded strings, imported functions, packing indicators, digital signatures, and disassembled code to form hypotheses about capabilities such as network communication or credential access. Dynamic analysis runs the sample in a controlled, isolated environment and observes its behavior through system monitoring, network capture, and debugging. The two approaches complement each other: static analysis can reveal hidden code paths that dynamic runs miss, while dynamic analysis reveals runtime decisions, configuration retrieved from servers, and actual effects. Analysts use isolated virtual machines and restricted networks to prevent accidental spread. Results are documented carefully because malware authors frequently detect analysis environments and alter behavior when they suspect observation.
Automated sandboxes provide quick behavioral reports, but they have important limitations. Malware may detect virtualization artifacts, sleep for long periods, or wait for user interaction and then stay dormant, producing a misleading clean result. Sandboxes often simulate only a limited set of software and network conditions, so behaviors tied to specific configurations may not appear. Network responses may be unavailable if command servers are offline when the sample runs. Reports can also be misread when analysts treat a generated score as a verdict. Responsible use treats sandbox output as one input that guides further analysis. Teams compare results across tools, verify key behaviors manually for high-impact cases, and communicate uncertainty clearly to stakeholders who make decisions based on the findings.
Chain of custody is the documented history of how evidence was collected, handled, stored, transferred, and analyzed. It establishes that the material presented in a hearing, a regulatory review, or an internal disciplinary process is the same material that was originally seized and has not been tampered with. A complete record includes unique evidence identifiers, descriptions and serial numbers, the names and roles of everyone who handled the item, dates and times, the locations where it was stored, the purpose of each access, and the hash values verified at each stage. Gaps in this record can undermine otherwise strong findings. Organizations should maintain standardized forms or case management systems so records are consistent, and they should train staff that even brief undocumented access can weaken a case.
Mobile devices present distinct challenges. Their storage is often encrypted by default, with keys tied to user authentication and secure hardware, so acquiring full data may be impossible without authorized access or specialized methods. Operating system updates frequently change data structures, and many applications store information in proprietary databases or cloud services that are not local to the device. Cloud synchronization means that the device may reflect data that lives elsewhere, raising questions about jurisdiction and scope. Legally, examiners must respect privacy expectations and obtain proper authority before accessing personal content. Remote wipe or auto-lock features can destroy evidence if a device is connected to a network or left unattended. Examiners therefore isolate devices promptly and follow established procedures specific to the device and jurisdiction.
In cloud environments, investigators usually lack physical access to hardware and cannot image the underlying disks directly. Evidence must instead be obtained through provider-supplied logs, control plane audit trails, snapshots, storage metadata, and tenant-level configurations. The shared responsibility model determines what the customer controls and what the provider retains. Investigators must act quickly because logs may have short retention periods, and resources can be scaled, terminated, or recreated automatically. Data may also be distributed across regions, which complicates legal process and jurisdiction. Organizations prepare by enabling comprehensive logging, retaining it according to policy, defining response roles in advance, and understanding contractual rights to request evidence. Practical cloud forensics is therefore as much about configuration and governance as about analysis tools.
Structured incident response commonly follows preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Forensic activities contribute most directly to detection and analysis, where evidence confirms the scope, timeline, and attacker actions, and to eradication, where forensic findings identify all persistence mechanisms and compromised accounts. Evidence collection must be balanced against containment, since waiting for a full examination can allow continued damage. Responders therefore often capture critical volatile data and key logs before isolating systems. Recovery decisions, such as whether a host can be rebuilt or only reimaged, depend on forensic certainty. The lessons learned phase uses findings to improve detection rules and controls. Forensic work that is documented and integrated into this cycle is far more valuable than analysis performed in isolation.
Translating intelligence into detection begins with identifying observable behaviors and data sources, such as process creation events, authentication patterns, or network connections, that the adversary behavior would produce. Analysts then write rules or queries in formats like Sigma or the logic of a specific security information platform, testing them against historical data to measure both detection value and noise. Threshold tuning, allowlisting of known legitimate tools, and contextual enrichment with asset criticality reduce false positives. Indicators should be combined with behavioral logic because single indicators are easily changed. Detections should be documented with their intent, expected data sources, and known blind spots. Periodic review confirms that rules remain effective as environments and adversary methods evolve.
Centralized log collection gathers records from endpoints, servers, network devices, identity systems, and cloud services into a common repository. This matters for forensics because attackers frequently tamper with or delete logs on the systems they compromise, and centralized copies written to a separate, protected location preserve an independent record. For detection, correlation across sources reveals multi-stage attacks that no single log would show, such as a suspicious login followed by privilege escalation and data access. Effective log management requires agreed retention periods aligned with regulatory and investigative needs, consistent time synchronization so timelines are accurate, and enough storage and parsing capacity to handle volume. Teams should also monitor the logging pipeline itself, since a silent collection failure creates blind spots that attackers may exploit.
Investigators must have lawful authority before collecting or examining digital evidence, which may come from consent, organizational policy for company-owned systems, a warrant or court order, or applicable statutory provisions. The scope of authority determines what may be accessed, and exceeding it can render evidence inadmissible and expose the investigator to liability. Privacy considerations require minimizing collection of unrelated personal data and protecting it appropriately. Jurisdictional rules affect which laws govern cross-border data and cloud storage. Because requirements vary significantly by country and sector, investigators should consult qualified legal counsel and follow their organization's approved procedures. This educational overview cannot substitute for licensed legal advice or professional judgment on a specific matter, and practitioners should verify current requirements before acting.
Several widely referenced frameworks support consistent practice. ISO and IEC 27037 provides guidelines for identifying, collecting, acquiring, and preserving digital evidence. ISO and IEC 27041 and 27042 address assurance and analysis methods. The NIST Special Publication 800-86 and the more recent NIST computer security incident handling guidance describe forensic and response processes. The MITRE ATT and CK framework organizes adversary behavior for both intelligence and detection work. Organizations use these references to build internal procedures, justify methodology in reports, and align with audit expectations. Applying a framework does not guarantee a particular outcome, but it provides a defensible structure. Practitioners should check the current version of each standard, since guidance is revised over time, and adapt it to their legal and operational context.
Forensic conclusions are only as reliable as the tools and methods that produced them. Software can contain parsing errors, misinterpret artifacts, or omit data, and different tools may report different results for the same input. Validation involves testing a tool against known datasets with expected outcomes, confirming that outputs match, and recording the version and configuration used. Documentation allows another examiner to reproduce the work and explain how each conclusion was reached, which is essential when findings are challenged. Examiners should also understand the limitations of each tool and avoid presenting interpretations as certainties. Regular revalidation is needed after software updates. Rigorous validation protects both the investigation and the credibility of the examiner who presents the findings.