Digital Forensics and Threat Intelligence

01Purpose and scope

• This manual supports the course Digital Forensics and Threat Intelligence. It describes how practitioners in security operations, incident response, and investigations actually carry out the work: preserving and examining digital evidence, recovering what happened on a system or network, and converting what was learned into intelligence that others can act on.
• The two disciplines overlap but serve different questions. Forensics asks what happened, in what order, by whom or what, and can the finding be shown to a third party. Threat intelligence asks who is likely to act against us, how they operate, what they are using right now, and what we should watch for next. A good analyst moves between the two, but the outputs differ. Forensic work produces a defensible account of specific events. Intelligence produces indicators, actor profiles, and assessments that are useful beyond one incident.
• This manual covers endpoints, servers, cloud workloads, mobile devices, and network captures. It does not cover forensic work on industrial control systems, medical devices, or vehicles, which need specialized procedures and vendor guidance. It also does not replace legal advice. Whether a finding can be used in a labor dispute, a civil case, or a criminal matter depends on jurisdiction, contract terms, and rules of evidence. Check the current requirements with counsel and the authoritative source for your region.

02Core principles

• Preserve before you touch. Every examination changes something, even a simple mount or a file listing that updates access times. Work from a verified copy or a read-only image wherever possible, and record the hash values of the original and the copy so that later reviewers can confirm nothing drifted.
• Document what you did, not only what you found. A finding without a record of the tools, versions, commands, and settings used is hard to reproduce and easy to challenge. Keep notes contemporaneously, not from memory at the end of a shift.
• Separate facts from interpretation. A file timestamp, a registry key, or a network connection is an observation. A statement that an employee exfiltrated data is an inference. Write observations in plain terms and label inferences with the evidence that supports them and the confidence you place in them.
• Treat intelligence as a claim with an expiry date. An indicator such as an IP address or file hash may be useful for days or may be obsolete within hours, especially when infrastructure is rented or shared. Assess how quickly each indicator degrades and how it was sourced.
• Limit the blast radius of your own work. Analysts with administrative access to a compromised host can destroy evidence or alert an adversary. Coordinate containment with the incident lead before running tools on live systems, and prefer collection methods that do not require installing software on the affected machine.

03Planning and preparation

• Start by confirming authority. Know who asked for the work, what they want answered, and whether you have written permission to access the systems, accounts, and data involved. For employee devices or personal accounts, the permission chain may involve HR, legal, and privacy staff, and the rules differ widely by country and by employment contract. If authority is unclear, stop and escalate.
• Define the question before collecting anything. Requests such as look into this host are too broad. A workable question is whether credentials from the finance server were used to log in to the file share between two specific dates, or which process created the scheduled task found on the workstation. A narrow question limits collection, shortens review, and makes the final report easier to judge.
• Prepare the kit before the incident. Typical items include write blockers for physical drives, forensic imaging hardware or validated software, a clean analysis workstation isolated from production networks, evidence bags or labeled storage with tamper seals, hash utilities, a timeline tool, and a secure case repository with access logging. Keep versions recorded because tool output can change between releases.
• Set up the case record at the start. Assign a case identifier, list the systems in scope, name the custodian of each item, and note the initial state of each system as it was found, including power status, logged-in users, and any visible messages. This baseline matters later when someone asks why a system was rebooted.
• Recognize the limits of your sources. Threat intelligence often depends on commercial feeds, open reporting, information sharing groups, and your own telemetry. Each source has coverage gaps and its own bias. Decide in advance how you will score sources, and how you will handle material that cannot be verified, such as an anonymous claim in a forum.

04Recommended workflow

1. 1
   : Triage and scope. Read the alert or request, identify affected assets, and decide whether the situation needs immediate containment. Record the first observed indicators and the time you first learned of them. Escalate to the incident lead if there is evidence of ongoing activity against critical systems.
2. 2
   : Preserve volatile and persistent data in the right order. Capture memory, active network connections, running processes, and logged-in sessions before shutting down a live host, because these disappear on reboot. Then image disks, collect logs, and export cloud audit records while retention windows are still open. Verify each acquisition with a hash and log the method.
3. 3
   : Establish chain of custody. Every transfer of evidence, from collection to analysis to storage, is recorded with the date and time, the person handling the item, the purpose, and the location. Gaps in custody give opposing parties grounds to question the evidence, so treat this record as part of the evidence itself.
4. 4
   : Analyze artifacts against the question. Examine file system metadata, registry or configuration data, event logs, browser and application histories, email, and memory. Build a timeline that merges sources and mark where times come from different clocks or time zones. Clock skew between a firewall and a domain controller is common and can mislead a timeline if ignored.
5. 5
   : Extract and test indicators. Pull file hashes, domains, IP addresses, mutexes, registry keys, and command line patterns from the analysis. Test them against your own telemetry for prior occurrences before assuming a new infection. Record the result, including negative results, because the absence of an indicator in past logs narrows the window of compromise.
6. 6
   : Map behavior to a framework. Describe observed techniques using a common vocabulary such as MITRE ATT&CK, which catalogs adversary tactics and techniques. Mapping helps teams compare incidents and identify detection gaps, but a mapping should reflect what the evidence supports and not what the analyst expects to see.
7. 7
   : Assess attribution and confidence. Attribution to a named group or person is often uncertain and sometimes impossible. State the evidence for and against each hypothesis, and use graded confidence language. A statement that the activity is consistent with a known group using the same tooling is different from a statement that the group conducted the activity.
8. 8
   : Package outputs for the audience. Technical responders need indicators, timelines, and containment steps. Executives need impact, decisions required, and residual risk. Investigators and counsel need the evidence trail, the methods, and the limits of the findings. Share intelligence outside the organization only under agreed rules, such as Traffic Light Protocol markings, and remove anything that identifies victims or staff without authorization.
9. 9
   : Close out and hand over. Confirm that evidence storage meets retention requirements, that temporary copies are destroyed where policy requires, and that open questions are logged with owners. Brief the incident lead, update detection rules, and schedule a lessons learned review.

05Quality checks, risk controls and compliance

• Verify every tool result with a second method where the finding matters. Parsing a log with one tool and confirming the key entries in raw form is a simple habit that catches parsing errors, encoding problems, and misread timestamps. Record which verification you used.
• Run peer review before any finding leaves the team. A reviewer should be able to follow the timeline, reproduce the hashes, and understand why each conclusion follows from the evidence. Reviewers should be someone who did not perform the original acquisition where practical.
• Control access to evidence and intelligence. Case repositories need role-based permissions, audit logging, and encryption at rest. Restrict personal data within evidence to people with a need to know, and apply your organization's data protection rules, which may impose specific obligations depending on where the data subjects live.
• Manage malware and adversary material carefully. Analysis of live samples should happen in isolated environments with no route to production networks. Do not send suspected malicious files to public scanning services when the file contains confidential information, because the upload can disclose it and alert the actor.
• Observe legal and regulatory requirements. Searches of personal devices, monitoring of employee communications, and cross-border transfers of evidence are governed by statutes and case law that vary by jurisdiction. Regulated sectors such as health care, finance, and critical infrastructure may also have breach notification duties with short deadlines. This guidance does not replace qualified legal or compliance judgment, approved internal procedures, or the written authorization required for the specific activity. Consult counsel and the current authoritative source before acting.
• Use recognized standards as a baseline and adapt them. ISO/IEC 27037 describes practices for identifying, collecting, acquiring, and preserving digital evidence. NIST Special Publication 800-86 describes integrating forensic techniques into incident response. NIST Special Publication 800-61 covers incident handling. Confirm the current edition before citing any of them in a report, and note where your procedure departs from them.

06Collaboration and documentation

• Agree on roles at the start. A typical incident has an incident lead who makes containment decisions, a forensic examiner who collects and analyzes evidence, an intelligence analyst who assesses indicators and actors, a system administrator who provides access and logs, and a legal or privacy contact who advises on constraints. One person may hold more than one role in a small team, but the functions should stay distinct in the record.
• Keep a single source of truth for the case. Shared spreadsheets and chat threads drift quickly. Use a case management system where timelines, indicators, tasks, and evidence references are linked, and where edits are versioned. Export a snapshot at major milestones.
• Write the report for the reader who will be asked questions later. Include the scope and question, the sources examined, the methods and tool versions, the timeline, the findings with confidence levels, the limits of the work, and the open items. Avoid the words that suggest certainty you do not have, and avoid speculation presented as fact.
• Share intelligence with defined rules. Sharing groups such as sector information sharing and analysis centers exchange indicators and reports under agreed terms. Before sharing, remove internal hostnames, personal data, and details that would identify the victim unless the recipients need them and are authorized to receive them. Record what was shared, with whom, and under which marking.
• Coordinate with external parties with care. Law enforcement, regulators, insurers, and vendors each have different expectations about what they need and when. Route external communication through the designated spokesperson or counsel, and keep a log of what was disclosed so that later statements stay consistent.

07Measures and continuous improvement

• Track measures that reflect real performance rather than activity counts. Useful indicators include time from alert to triage, time from triage to containment, percentage of acquisitions with verified hashes, share of findings that passed peer review without rework, number of detection rules created from case work, and rate at which intelligence indicators produce true positives in later monitoring. Set targets only after you have a baseline from your own records.
• Be cautious with volume measures. A rising count of indicators may mean better collection or it may mean noisy feeds. Track how many indicators were retired as stale and how many led to a confirmed detection. Metrics such as these are most useful when reviewed alongside individual cases rather than in isolation.
• Run structured lessons learned reviews after significant cases. Ask what the team knew at each point, what information arrived late, which tools slowed the work, where documentation was incomplete, and what would have shortened the investigation. Assign owners to changes and check whether they happened.
• Tune intelligence sources over time. Review which feeds contributed indicators that were actually useful, which produced false positives, and which arrived too late to matter. Drop sources that do not earn their place, and document the reason so that the decision can be revisited.
• Adjust practice to context. A small organization without a dedicated forensic lab may rely on external responders and cloud provider tools, accepting less depth in exchange for speed. A large enterprise may invest in automated collection and in-house malware analysis, which brings higher maintenance costs and more responsibility for keeping skills current. Each approach has trade-offs in cost, speed, and evidentiary strength.

08Common mistakes and how to prevent them

• Rebooting or powering off a live system without capturing volatile data. Prevent this by making memory and live state collection a required step before any shutdown decision, and by stating in the case record who authorized the shutdown.
• Working directly on original evidence. Analysts sometimes open the original disk image in a tool that writes to it. Prevent this by mounting evidence read-only, keeping originals in a locked store, and checking hash values before and after analysis.
• Treating an indicator as proof of compromise. A single hash match or a single IP connection rarely proves intent or full compromise. Prevent this by requiring corroborating artifacts and by labeling the confidence level in every finding.
• Letting the timeline rest on unverified clocks. Mismatched time zones, unsynchronized devices, and manual edits to logs produce false sequences. Prevent this by recording the time source for each artifact and noting any known offset.
• Losing track of who touched what. Informal copying of files to personal drives or emailing excerpts breaks custody and exposes data. Prevent this by routing all transfers through the case repository and reviewing access logs periodically.
• Sharing too much or too little intelligence. Oversharing can expose personal data or sensitive details, while undersharing leaves peers exposed to the same campaign. Prevent this by applying a written sharing standard with markings and by reviewing each release against it.
• Overstating attribution. Naming an actor in an internal report can drive costly decisions and external statements. Prevent this by separating the evidence for technical overlap from any claim about who is responsible, and by requiring a second reviewer for any attribution language.

09Practical checklist

• Confirm written authority, scope, and the specific question before collecting data.
• Record the initial state of each system, including power, users, and visible messages.
• Capture volatile data such as memory, connections, and processes before any shutdown.
• Image or export persistent sources and verify each copy with a recorded hash.
• Maintain chain of custody for every transfer, storage location, and handler.
• Work only on verified copies or read-only mounts of evidence.
• Record the time source for each artifact and note any known clock offset.
• Test indicators against historical telemetry and record negative results.
• State confidence levels for each finding and separate facts from inferences.
• Obtain peer review for conclusions that will be relied on or shared.
• Confirm sharing markings and remove personal or victim identifiers before release.
• Log open items with owners and schedule a lessons learned review.

★Learning sources

• Micro Degree: Digital Forensics and Threat Intelligence
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics