ECIH common mistakes
ECIH · Understand the traps and how to avoid them.
When a scenario describes an action (isolating a switch port, blocking an IP, reimaging a host, restoring from backup), the candidate labels the phase by the tool or technique used rather than by the phase objective - for example calling disk imaging 'eradication' or calling a firewall block 'recovery'.
They memorized the phase names as a vocabulary list and never attached a decision rule to each one; the exam deliberately uses actions that could plausibly sit in two phases.
What to do instead
For each phase write down the single question it answers (Preparation: are we ready? Identification: what happened and how far did it spread? Containment: how do we stop the spread now? Eradication: how do we remove the cause? Recovery: how do we return to normal? Lessons Learned: what do we change?). Then classify 20 action statements against those questions and justify each in one sentence.
They answer as if the process always flows straight through the phases in order, so when a scenario says new hosts were found beaconing during eradication, they still choose 'proceed to recovery' instead of looping back to identification and containment.
The lifecycle diagram is drawn as a sequential arrow chain, and candidates study it as a checklist rather than as a loop with feedback paths.
What to do instead
Redraw the lifecycle yourself with the explicit back-edges (eradication to identification when new scope appears, recovery to containment when re-infection occurs, lessons learned feeding preparation). Practice scenarios that include a mid-course discovery and state out loud which phase you re-enter and why.
In a first-response scenario involving a suspected compromised workstation that is still powered on, they choose to unplug it or pull the drive to 'preserve evidence' before capturing memory.
Television-style forensics intuition says secure the hardware first, and candidates do not connect power loss to the loss of volatile data and encryption keys.
What to do instead
Memorize the order of volatility as a ranked list you can recite (registers/cache, RAM and running processes, network connections, swap/pagefile, temporary files, disk, remote logs, backups) and drill the rule that a live system is isolated at the network layer, not powered down, unless there is an active destructive process you cannot otherwise stop.
They treat deleting the malicious executable (or running a full antivirus scan and rebooting) as complete eradication, without identifying or removing the persistence mechanism, and without checking whether the host spread the infection.
The visible artifact is the file the user reported, so the mental model equates 'the file is gone' with 'the cause is gone'; persistence locations and lateral movement are less concrete and easy to skip.
What to do instead
Adopt a fixed eradication checklist per host: autoruns (Run/RunOnce keys, services, scheduled tasks, WMI subscriptions), newly created accounts, browser extensions, DLL search-order and sideloaded libraries, plus a lateral-movement review of authentication logs. Only call eradication complete when you can name the initial vector, the persistence used, and the scope of affected hosts.
They judge sender authenticity from the visible display name or From address alone - declaring a message legitimate because it shows a known vendor - and never inspect Return-Path, Received chain ordering, or the SPF/DKIM/DMARC results in the headers.
Mail clients hide headers by default, so candidates evaluate the message the way an end user sees it rather than the way a mail gateway sees it.
What to do instead
Practice reading raw headers bottom-up: identify the originating IP from the lowest Received line, compare the envelope sender with the header From, and read the Authentication-Results for SPF, DKIM and DMARC outcomes. For a lookalike-domain message, also check whether a valid DMARC pass actually covers the visible From domain rather than a different aligned domain.
On a C2 beaconing scenario they propose blocking the single external IP as full containment and stop the analysis there.
Blocking is the most familiar and most visible action, so it becomes the answer; scoping (how many internal hosts are talking out, on what protocol, to what else) is never enumerated.
What to do instead
Write containment answers in two parts: scope first (identify every internal host communicating with the indicator via proxy, DNS and flow logs; look for the same beacon pattern on other destinations) then contain (block at the enforcement point that covers all of them, keep the original traffic evidence, and expect the adversary to switch infrastructure so domain/IP indicators alone are insufficient).
They read the web access log literally - counting every HTTP 200 as proof that an attack succeeded and dismissing every 404 or 500 as harmless noise - or they identify SQL injection versus XSS from the response code rather than from the request payload and response body.
Status codes feel like a pass/fail signal, and candidates have not internalized that a successful injection often returns 200 with an anomaly in body length, while a failed one can also return 200.
What to do instead
Correlate four things per request: decoded payload in the URL or body, parameter name, response size deviation from the baseline for that endpoint, and what the client requested next. Build a small baseline table of normal response lengths for key endpoints, and remember that reconnaissance probes generate 404s and 500s that are still attack evidence.
On a compromised cloud workload they propose on-premises style actions such as seizing or imaging the physical machine, or they claim no host-level evidence exists because 'the provider owns the hardware'.
On-prem habits carry over and the shared responsibility split between customer and provider is studied as a slogan rather than as a concrete list of who can collect what.
What to do instead
For each major provider service, list the customer-side evidence sources you can actually obtain: control-plane audit logs, network flow logs, object storage access logs, workload-level agent logs, and snapshots taken before termination. State explicitly that terminating or rebuilding an instance destroys volatile evidence and that identity/API-key activity is often the primary evidence in cloud incidents.
In an insider-threat scenario they recommend immediately confronting or interviewing the suspected employee, disabling the account outright, or telling the employee's manager, before evidence is preserved and before HR and legal are involved.
The candidate treats the case like a malware incident where speed of containment dominates, and the technical indicators feel weaker than the human suspicion so they move to resolve the ambiguity.
What to do instead
Apply an insider-specific sequence: coordinate with HR and legal first, preserve logs and mailbox/endpoint evidence covertly so the subject is not alerted, use least-disruptive monitoring, and only then take account actions with a documented justification. Also practice naming behavioral indicators (off-hours access, bulk downloads, access to records unrelated to the role) rather than malware indicators.
They assert that a program executed because a Prefetch file exists, or they cite an artifact that does not apply to the system in the scenario (Prefetch or an Amcache entry on a server OS where the feature is disabled, user-profile artifacts for a service account that never logged on interactively).
Endpoint artifacts are memorized as a flat list of 'what proves execution' without the conditions under which each artifact is created or retained.
What to do instead
Build an artifact matrix with three columns: artifact, which OS editions/configurations produce it, and what question it answers. Note explicitly that Prefetch is disabled by default on server editions, that ShimCache indicates presence rather than execution on modern Windows, and that network connections and process trees from EDR or live response are needed to establish execution on servers.