Most engineers think…
Most people think endpoint detection is 'a list of bad file hashes the antivirus checks against'. That mental model is exactly what modern attackers defeat for breakfast.
Falcon's detection engine is behaviour-first. It still blocks known-bad with IOCs (hashes, IPs, domains), but its edge is Indicators of Attack (IOAs) — the chain of actions an attack must perform (execute, hide, persist, reach out) — plus on-sensor and cloud machine learning for unknown malware, exploit mitigation for memory tricks, and EDR continuous recording that catches anything prevention misses. Attackers can repack a file in seconds, but they cannot avoid the behaviours the attack requires. Understanding that is what lets you explain 'why behaviour beats signatures' in an interview.
① IOA vs IOC — behaviour and intent vs leftover clues
Start with the one comparison every interviewer loves. An IOC is a clue an attacker left behind — a file hash, a malicious IP or domain, a registry key. It is evidence the security of a system was breached. The problem: it is reactive. By the time you have the hash, the damage may be done, and the attacker only has to repack the file to get a brand-new hash.
An IOA is different: it describes what the attacker is trying to do, regardless of the malware or exploit used. A successful attack must perform a chain of actions — run code, hide in memory, gain persistence across reboots, call out to a command-and-control server. IOAs watch for that behaviour in real time.
Why behaviour beats signatures
CrowdStrike's classic line: IOCs are like a witness describing a bank robber's purple van and cap — useless the moment he switches to a red car and a crowbar. IOAs catch the robbery itself. Attackers change files constantly, but they cannot avoid the actions an attack requires. That is why a behaviour-first engine catches fileless and never-seen-before threats that pure signature matching misses entirely.
Which statement best captures the IOA vs IOC difference?
② NGAV & machine learning — blocking known and unknown malware
NGAV (Falcon Prevent) is the prevention front line, and it works in layers. The fast, cheap layer is known-malware blocking: matching file hashes and other IOCs against CrowdStrike intelligence and your own custom IOC lists. If it is known-bad, it never runs.
The real upgrade is machine learning for malware nobody has seen before. Falcon runs ML in two places. On-sensor ML scores a file's maliciousness locally, so it can block a brand-new binary even when the endpoint is offline. Cloud ML, trained on the rich telemetry of the Security Cloud, adds a deeper verdict and continuously improves without a fleet-wide reinstall.
Sensitivity is a dial, not a switch
The ML engines have sensitivity levels — typically Disabled, Cautious, Moderate, Aggressive and Extra Aggressive. Higher levels catch more but risk more false positives. Crucially, you set the level separately for detection and for prevention: you can let Falcon detect aggressively while it only blocks at a more conservative level until you trust it.
Describes attacker behaviour and intent — the chain of actions an attack must perform. Catches an attack regardless of the file used, in real time.
A forensic artifact left behind — a hash, IP or domain. Useful after the fact, but easy for an attacker to change by repacking the file.
On-sensor ML scores unknown files locally (even offline); cloud ML adds a deeper verdict trained on the Security Cloud. Sensitivity is a dial set per policy.
Falcon Insight records endpoint activity like a DVR, so threats that slip past prevention are still detected and can be replayed step by step.
In an interview, this one line nails IOA vs IOC: an attacker can repack a file to defeat any hash/IOC in seconds, but cannot avoid the actions an attack requires — execute, hide, persist, call out. IOAs watch those actions, which is why behaviour-first detection beats signatures on fileless and never-seen threats.
How does Falcon NGAV catch brand-new malware that has no known hash?
③ Behaviour & EDR — IOAs, exploit mitigation and continuous recording
On top of ML sits the behavioural layer. Behavioural IOAs watch sequences of actions — a document spawning PowerShell that downloads and runs a payload, a process injecting into another, an attempt to disable defences — and block the chain even when every individual file looks clean. AI-powered IOAs extend this: cloud ML analyses events at runtime, generates new behavioural detections and pushes them to the sensor, which correlates them with local events to decide maliciousness. Exploit mitigation covers memory-based tricks like buffer overflows and code injection that never drop a file at all.
Prevention is never perfect, so Falcon also records. EDR (Falcon Insight) acts like a DVR on the endpoint, capturing process starts, network connections, file writes and registry changes.
Why the recorder matters
Because it records everything, EDR catches the threat that slipped past prevention: applying behavioural analytics over the stream, it raises a detection and lets an analyst replay exactly what happened — who, what, in what order — instead of guessing from a single quarantined file.
Prevention is never 100 percent. The reason EDR records everything like a DVR is precisely to catch what slips past NGAV. Treating EDR as optional means a fileless or living-off-the-land attack that dodges prevention leaves no trail to investigate. Always pair prevention with continuous recording.
▶ Watch a fileless attack get caught by behaviour, not signature
How a clean-looking document becomes a blocked detection. Press Play for the healthy path, then Break it to see the classic failure.
A clean-looking document spawns PowerShell that downloads and runs a payload, with no known-bad file involved. What stops it?
④ How a detection is scored — and how to tune policy without drowning
Every signal — an IOC hit, an ML verdict, an IOA chain, an exploit attempt — is scored for confidence and assigned a severity (informational through critical). Falcon then surfaces a detection in the console with the full process tree, the technique (often mapped to MITRE ATT&CK), the user and the host, so an analyst can triage by severity rather than wade through raw events.
Detection vs prevention is the key toggle
This is the setting people get wrong. Detection means Falcon watches and alerts; prevention means it actively blocks, quarantines or kills. They are separate controls, set per policy. Smart rollout: enable sensor visibility and detection first, watch what fires, then promote trusted detections to prevention. Turn on quarantine so blocked files are isolated (note quarantine is not available on Linux), set exploit mitigation, and apply different policies to different groups — finance, developers and production servers each need their own risk balance.
The failure everyone hits is flipping every slider to Extra Aggressive and full prevention on day one — an instant false-positive storm that blocks legitimate tools. Start in detection, baseline, then enforce.
Priya, a SOC analyst in Hyderabad, faces this
After flipping the new prevention policy to full block with ML on Extra Aggressive, the helpdesk is flooded — a custom finance macro and a developer's build tool are being quarantined as malicious.
Prevention was turned on at maximum sensitivity with no detection-first baseline, so high-confidence-but-benign behaviours got blocked.
Open the detections list — the 'malicious' hits are internal, signed tools whose behaviour looks attack-like; they are false positives, not a real intrusion.
Falcon console ▸ Endpoint security ▸ Prevention policies + DetectionsDial ML prevention back to Moderate, keep detection at Aggressive to stay visible, add tuned exclusions or allowlist entries for the verified internal tools, baseline, then re-raise prevention.
Re-test: the finance macro and build tool run, the helpdesk queue clears, and the detections list now shows only genuine suspicious behaviour.
Never close a Falcon ticket on 'looks fine'. The detection shows the scored confidence, the severity, the full process tree and the MITRE ATT&CK technique. That single view tells you whether it was an IOC hit, an ML verdict or a behavioural IOA — and whether it was a real attack or a false positive to tune.
What is the safest way to roll out a new Falcon prevention policy?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why does CrowdStrike say 'behaviour beats signatures', and where do IOAs, ML and EDR each fit? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Indicator of Attack (IOA)
- A description of attacker behaviour and intent — the chain of actions an attack must perform (execute, hide, persist, command-and-control), caught in real time regardless of the file used.
- Indicator of Compromise (IOC)
- A forensic artifact left behind after an intrusion, such as a file hash, IP address or domain. Useful after the fact, but easy for an attacker to change.
- NGAV (Falcon Prevent)
- Next-generation antivirus that replaces signature-only AV with IOC/hash blocking, machine learning and behavioural IOAs in one lightweight agent.
- On-sensor machine learning
- ML that runs locally on the endpoint to score an unknown file's maliciousness, so it can block brand-new malware even when offline.
- Cloud machine learning
- ML models trained on the Security Cloud's telemetry that add a deeper verdict on files and behaviour and improve continuously without a reinstall.
- AI-powered IOAs
- Behavioural detections generated by cloud-native ML at runtime and pushed to the sensor, which correlates them with local events to assess maliciousness.
- Behavioural prevention
- Blocking based on the sequence of actions a process takes (the attack chain) rather than the file itself, catching fileless and living-off-the-land attacks.
- Exploit mitigation
- Protection against memory-based attacks such as buffer overflows and code injection that never drop a file to disk.
- EDR (Falcon Insight)
- Endpoint detection and response that records endpoint activity like a DVR, so threats that evade prevention are still detected and can be replayed.
- Detection vs prevention
- Separate policy toggles: detection watches and alerts; prevention actively blocks, quarantines or kills. Each has its own ML sensitivity level.
📚 Sources
- CrowdStrike — IOA vs IOC: Understanding the Differences. crowdstrike.com/cybersecurity-101/threat-intelligence/ioa-vs-ioc
- CrowdStrike Blog — Introducing AI-Powered Indicators of Attack (cloud ML generating and pushing IOAs to the sensor). crowdstrike.com/blog/introducing-ai-powered-indicators-of-attack-ioas
- CrowdStrike — Falcon Prevent: next-generation antivirus (machine learning, exploit blocking and IOA behavioural protection). crowdstrike.com/products/endpoint-security/falcon-prevent
- CrowdStrike — What is EDR? Endpoint Detection and Response Defined (DVR-like continuous recording). crowdstrike.com/cybersecurity-101/endpoint-security/endpoint-detection-and-response-edr
- CrowdStrike — Falcon Insight EDR data sheet: continuous endpoint visibility and automated detection. crowdstrike.com
- CrowdStrike Falcon docs — Prevention policy settings: detection vs prevention, ML sensitivity levels, quarantine and exploit mitigation. falcon.crowdstrike.com
What's next?
Got how detections are made? Next, zoom out to the Falcon architecture — the single lightweight sensor, the cloud-native Security Cloud and the Threat Graph that correlates trillions of events behind every one of these detections.