What hash does an attacker need to forge a Golden Ticket?

Correct: b. A Golden Ticket requires the KRBTGT account's hash — the master key for signing all Kerberos TGTs in a domain. With it, an attacker can forge tickets offline for any user and any service, valid for any lifetime they choose.

Why can a next-gen firewall NOT detect a Pass-the-Hash attack?

Correct: c. A Pass-the-Hash authentication uses a valid NTLM hash, so the traffic looks identical to a normal NTLM login. Only a tool with per-identity behavioural context — like FIP — can detect that this account never uses NTLM from this source.

You deploy Falcon Identity Protection but only install the sensor on your three primary DCs, not two secondary ones. What is the risk?

Correct: b. FIP detection depends on sensors reading live authentication events. A DC without a sensor is a blind spot — an attacker who routes NTLM or Kerberos traffic through it evades detection. Every DC must be covered.

A service account that normally uses Kerberos suddenly sends an NTLM handshake to a DC it has never accessed, from a new IP, at 3 am. Which FIP signals indicate this is malicious?

Correct: a. FIP correlates multiple signals against the identity's baseline: wrong protocol, new target DC, unknown source host, and unusual time all individually raise the risk score. Their combination pushes it into the block/alert threshold.

After a confirmed Golden Ticket incident, security rotates the KRBTGT password once and declares the environment clean. What is wrong with this approach?

Correct: c. Kerberos caches tickets for their baked-in lifetime. One KRBTGT rotation changes the signing key going forward but existing forged tickets can still be accepted until they expire. Rotating twice ensures both the old and new keys are invalidated, cutting off any outstanding forged tickets.

A CISO asks why deploying Falcon Identity Protection is better than adding identity-based SIEM rules. What is the strongest argument?

Correct: d. Wait — this option is incorrect. The correct answer is option C: FIP enforces inline prevention (block or MFA step-up before the session is granted) while SIEM detection is retrospective. Prevention before the session is the defining advantage of ITDR over log-based detection.

CrowdStrike Falcon Identity Protection — ITDR, AD & Entra Visibility (2026)

Q: What makes Falcon Identity Protection different from a SIEM analysing AD logs?

Correct: b. SIEM log analysis is retrospective — it sees events minutes to hours after they occur. FIP sensors read live authentication traffic on domain controllers and can enforce decisions (block, MFA) before a session is granted.

Q: Which protocol does a Pass-the-Hash attack primarily abuse?

Correct: c. Pass-the-Hash reuses the NTLM hash of a credential without knowing the plaintext password. Kerberos is harder to abuse in the same way because it requires ticket-granting tickets, not raw hashes.

Q: A domain admin's risk score spikes to 85 after their workstation runs a suspicious process. What should the FIP policy do?

Correct: c. A risk score above the configured high-risk threshold (e.g. 70–80) should trigger real-time enforcement — MFA step-up or block — combined with a high-severity incident so the SOC can investigate the suspicious endpoint activity.

Q: An attacker forges a Kerberos TGT offline using the KRBTGT hash. What anomaly does FIP use to detect this Golden Ticket?

Correct: b. Offline-forged Golden Tickets often have abnormally long lifetimes (10 years is common), use older encryption types, or request access to services the account has never touched. FIP's protocol intelligence and behaviour baseline flag all three patterns.

Most engineers think…

Most security teams assume their SIEM or firewall will catch credential attacks. That assumption fails — a Golden Ticket looks like a perfectly valid Kerberos TGT on the wire, and NTLM Pass-the-Hash never shows a bad password.

Falcon Identity Protection solves this by sitting directly on the authentication plane: a lightweight sensor on every domain controller reads every Kerberos, NTLM and LDAP event, compares it against a learned behaviour baseline, assigns a risk score, and — if you configure it — blocks or step-up challenges the session before it succeeds. That is ITDR done right: prevention, not just alerting.

① What Falcon Identity Protection actually is — ITDR on the authentication plane

Falcon Identity Protection (FIP) is CrowdStrike's identity threat detection and response (ITDR) solution. Where most tools wait for a SIEM alert after a breach, FIP sits inline on the authentication path: a sensor deployed on every domain controller reads every authentication event in real time and shares that telemetry with the Falcon platform for analysis.

FIP covers both on-premises Active Directory (AD) and cloud-based Microsoft Entra ID (formerly Azure AD). For Entra ID, CrowdStrike integrates via Microsoft's External Authentication Method (EAM), placing Falcon inline with every Entra sign-in so it can enforce decisions before the token is issued.

The key mental model: FIP is not a log analyser. It reads live authentication traffic — Kerberos, NTLM, LDAP/S — and acts on it, not on logs written minutes later. That is what lets it stop attacks in progress rather than just record them.

Figure 1 — FIP real-time auth intercept loop

Every authentication event in AD or Entra ID passes through Falcon Identity Protection before the session is granted.

Figure 2 — FIP coverage: AD + Entra + SaaS

Falcon Identity Protection unifies on-prem AD, cloud Entra ID, and SaaS app authentication under one risk engine.

Quick check · Q1 of 10 · Understand

What makes Falcon Identity Protection different from a SIEM analysing AD logs?

a) FIP stores more logs than a SIEMb) FIP reads authentication events as they happen and can block inline, not after the factc) FIP replaces Active Directory entirelyd) FIP only works on cloud identities

Correct: b. SIEM log analysis is retrospective — it sees events minutes to hours after they occur. FIP sensors read live authentication traffic on domain controllers and can enforce decisions (block, MFA) before a session is granted.

👉 So far: Falcon Identity Protection = ITDR inline on the authentication plane — sensor on every DC reads live Kerberos, NTLM and LDAP events for both AD and Entra ID.

② The visibility layer — Kerberos, NTLM, LDAP and behaviour baselines

The FIP sensor on a domain controller captures every authentication event at the protocol level: Kerberos ticket requests and grants, NTLM challenge-response handshakes, and LDAP/LDAPS directory queries. Traditional tools cannot see inside these flows — firewalls see IP headers and NGFWs see application metadata, but neither can inspect a Kerberos Ticket Granting Ticket (TGT) for signs of forgery.

FIP builds a behaviour baseline per identity — which services an account normally authenticates to, at what hours, from which devices and locations. Every new authentication is compared against that baseline. Anomalies — a service account authenticating to a domain controller it has never touched, an admin account producing Kerberos tickets at 3 am from a new source IP — raise the risk score immediately.

Protocol intelligence that matters

FIP specifically understands Golden Ticket anomalies (ticket lifetime or encryption mismatch vs AD norms), Pass-the-Hash patterns (NTLM auth from an account that normally uses Kerberos), and Kerberoasting (sudden burst of service-ticket requests for accounts with SPNs). This protocol-level intelligence is impossible to replicate with a plain SIEM log parser.

Figure 3 — One risk engine, every protocol

FIP ingests telemetry from every authentication protocol and feeds one central AI risk engine that scores each identity.

🎫

Golden Ticket

tap to flip

A forged Kerberos TGT created offline using the stolen KRBTGT hash. Valid for years unless KRBTGT is rotated twice. FIP detects it via ticket lifetime and encryption anomalies.

🔑

Pass-the-Hash

tap to flip

Reusing a credential's NTLM hash to authenticate without the plaintext password. FIP catches it by spotting NTLM where Kerberos is expected, plus a mismatched device fingerprint.

📊

Identity Risk Score

tap to flip

A 0–100 AI score CrowdStrike computes per identity, combining auth anomalies, endpoint health, peer-group behaviour and threat intel. Drives block/MFA/allow decisions inline.

🛡️

Conditional Access

tap to flip

FIP enforces policy inline: score below threshold = allow; medium = MFA step-up; high = block. Works for both AD and Entra ID via Microsoft's EAM integration.

Name the three identity protocols in your answer

In any interview question about AD security, explicitly name Kerberos, NTLM and LDAP/S as the three protocol layers FIP monitors. Examiners distinguish candidates who know 'identity visibility' from those who can name the actual wire protocols — and explain why each one matters for a different attack class.

Quick check · Q2 of 10 · Remember

Which protocol does a Pass-the-Hash attack primarily abuse?

a) Kerberos TGT requestsb) LDAP directory queriesc) NTLM authenticationd) RADIUS RADIUS accounting

Correct: c. Pass-the-Hash reuses the NTLM hash of a credential without knowing the plaintext password. Kerberos is harder to abuse in the same way because it requires ticket-granting tickets, not raw hashes.

👉 So far: FIP builds a per-identity behaviour baseline and spots protocol anomalies — Golden Ticket lifetimes, NTLM-where-Kerberos-expected, Kerberoasting bursts — that SIEMs and firewalls cannot see.

③ AI risk scoring and conditional-access enforcement

Every identity in FIP carries a dynamic risk score computed by CrowdStrike's AI engine. The score combines authentication anomalies, endpoint health signals from the Falcon sensor, threat-intelligence indicators, and peer-group behaviour. A domain admin who logs in from a known device at normal hours may score 10; the same account suddenly authenticating via NTLM from an unmanaged host at midnight after a suspicious process runs on the endpoint could spike to 90.

The risk score is not just a dashboard number — it drives conditional-access enforcement inline. FIP integrates with AD's authentication infrastructure and with Entra ID via EAM to take real-time actions: allow, block, or step-up MFA challenge. Security teams configure risk-threshold policies: score > 70 triggers MFA; score > 90 blocks the session outright and raises a Priority 1 incident in the Falcon console.

Because Falcon combines identity and endpoint telemetry in one platform, the conditional-access decision is richer than any standalone identity provider can make. A risky authentication from a device that just ran a known credential-dumping tool gets blocked; the same credential from a healthy managed device and a normal location is allowed through without friction.

Figure 4 — Risk score: low vs high — response differs

The same identity gets a different enforcement action based on the computed risk score and configured policy thresholds.

'Identity protection is just MFA' under-sell

MFA is a preventive control, not a detection one. An attacker who has already stolen a valid TGT or NTLM hash can bypass MFA entirely — the authentication looks legitimate. FIP's risk scoring catches the behavioural anomaly around that stolen credential even when the factor was already satisfied.

▶ Watch a Pass-the-Hash lateral movement get blocked

An attacker uses a stolen NTLM hash to move from a compromised workstation to a domain controller. Press Play for the detection path, then Break it to see the failure mode.

① Hash stolenMimikatz extracts the NTLM hash of a domain admin account from LSASS memory on a compromised workstation.

▼

② PtH attemptThe attacker uses the hash to authenticate via NTLM to a domain controller — no password required.

▼

③ FIP detectsFIP sensor flags: NTLM where Kerberos is expected, unknown source host, risk score jumps from 8 to 91.

▼

④ Block + incidentFIP blocks the session inline and raises a Priority 1 incident in the Falcon console with the full identity timeline.

Press Play to step through the Pass-the-Hash block path. Then press Break it.

Quick check · Q3 of 10 · Apply

A domain admin's risk score spikes to 85 after their workstation runs a suspicious process. What should the FIP policy do?

a) Allow the session — the admin may have a legitimate reasonb) Delete the admin account immediatelyc) Trigger a MFA step-up challenge or block, then raise a Priority incidentd) Send a warning email and log the event

Correct: c. A risk score above the configured high-risk threshold (e.g. 70–80) should trigger real-time enforcement — MFA step-up or block — combined with a high-severity incident so the SOC can investigate the suspicious endpoint activity.

👉 So far: Every identity carries an AI risk score combining auth anomalies, endpoint health and threat intel. Thresholds drive inline policy: allow, MFA step-up, or block — before the session succeeds.

④ Attack scenarios — Golden Ticket, Pass-the-Hash, and stopping lateral movement

The most dangerous identity attacks exploit Kerberos and NTLM because both can be abused with stolen hashes or forged tickets that look valid on the wire. FIP counters each pattern specifically.

A Golden Ticket attack starts when an adversary extracts the KRBTGT account hash from a domain controller and uses it to forge Kerberos TGTs offline. FIP detects Golden Tickets through anomalies the forger cannot avoid: tickets with abnormally long lifetimes, mismatched encryption types, or requests for services the issuing account has no business accessing. Once detected, FIP raises a high-severity incident and can block the forged ticket from being accepted.

A Pass-the-Hash (PtH) attack reuses a credential's NTLM hash to authenticate without knowing the plaintext password. FIP spots PtH by comparing the authentication protocol used (NTLM where Kerberos is expected) against the identity's baseline and flagging the mismatched device fingerprint. Lateral movement — moving from one host to another using valid or stolen credentials — is detected as a sequence of anomalous authentications: new source hosts, unusual service accounts accessing admin shares, and RDP sessions outside normal patterns. FIP correlates these across the kill chain and surfaces a unified incident with the full movement path.

Figure 5 — Golden Ticket — detect, block, respond

FIP detects a Golden Ticket by protocol anomaly and blocks the forged ticket before lateral movement succeeds.

Vikram at a Mumbai financial services firm faces this

SOC receives an alert that a service account used for scheduled backups is suddenly authenticating to five domain controllers via NTLM at 2 am and accessing the finance file share — behaviour it has never shown before.

Likely cause

An attacker extracted the account's NTLM hash from a compromised backup server and is using Pass-the-Hash to move laterally toward the domain controllers.

Diagnosis

Falcon Identity Protection flags the NTLM authentication (account normally uses Kerberos), the new source hosts, and the spike in the account's risk score from 12 to 88 — all visible in one unified timeline in the Falcon console.

Falcon Console ▸ Identity ▸ Incidents ▸ select incident ▸ Identity Timeline

Fix

Block the service account session inline via FIP policy; reset the account credential and NTLM hash; remediate the compromised backup server; rotate KRBTGT twice to invalidate any forged tickets created from the same foothold.

Verify

Re-check the Falcon Identity incident queue — no further anomalous NTLM sessions from the service account; risk score returns to baseline; lateral movement path terminated.

Rotate KRBTGT twice after a Golden Ticket

A single KRBTGT password rotation does not immediately invalidate existing Golden Tickets — forged tickets remain valid for their baked-in lifetime. Best practice (and Microsoft guidance) is to rotate KRBTGT twice in rapid succession. Confirm via the Falcon console that no further anomalous Kerberos tickets are being presented from the affected domain.

Quick check · Q4 of 10 · Analyze

An attacker forges a Kerberos TGT offline using the KRBTGT hash. What anomaly does FIP use to detect this Golden Ticket?

a) The ticket contains the attacker's real usernameb) The forged ticket has abnormal lifetime, encryption type mismatches or accesses services inconsistent with the accountc) The attacker always uses HTTP to present the ticketd) Golden Tickets cannot be detected; only KRBTGT rotation stops them

Correct: b. Offline-forged Golden Tickets often have abnormally long lifetimes (10 years is common), use older encryption types, or request access to services the account has never touched. FIP's protocol intelligence and behaviour baseline flag all three patterns.

👉 So far: Golden Ticket = forged TGT detected by lifetime/enc anomaly. Pass-the-Hash = NTLM misuse caught by protocol baseline. Both stop at the enforcement layer — rotate KRBTGT twice post-compromise.

🤖 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.

🧠 In your own words

Type one line: why can a Golden Ticket attack go undetected for years in traditional environments — and what does Falcon Identity Protection check that standard tools miss? Then compare with the expert version.

Expert version: A Golden Ticket is forged offline using the KRBTGT hash, so it never appears in AD's normal ticket-issuance logs and looks valid on the wire. Standard tools — SIEMs, firewalls, even the identity provider itself — have no baseline for what a 'normal' Kerberos ticket looks like for a given account. Falcon Identity Protection checks the protocol-level anomalies the forger cannot suppress: ticket lifetime (attackers set them to 10 years), encryption type mismatches vs AD defaults, and the fact that the account is suddenly accessing services it has never touched. Combine that with the endpoint context from the Falcon sensor and you catch the attack in motion rather than discovering it months later in a log review.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on CrowdStrike Falcon at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

ITDR (Identity Threat Detection and Response): A security discipline focused on detecting and responding to attacks targeting identity systems — Active Directory, Entra ID, SaaS SSO — in real time.
Golden Ticket: A Kerberos TGT forged offline using the stolen KRBTGT domain account hash. Valid for any user, any service, for any lifetime the attacker sets.
Pass-the-Hash (PtH): Authenticating with a credential's NTLM hash rather than the plaintext password, using tools like Mimikatz to extract the hash from LSASS memory.
KRBTGT: The Key Distribution Center service account whose hash signs all Kerberos TGTs in a domain. Compromising it enables Golden Ticket attacks; rotating it twice is the remediation.
Conditional Access (FIP): FIP's inline enforcement layer: policies that evaluate a risk score and apply allow, MFA step-up, or block decisions before a session token is issued.
External Authentication Method (EAM): A Microsoft Entra ID integration point that allows external providers like CrowdStrike Falcon to sit inline with every Entra sign-in and enforce custom authentication policies.
Behaviour Baseline: FIP's per-identity model of normal authentication patterns — typical protocols, source hosts, target services and time windows — used to score anomalies.
Kerberoasting: An attack that requests Kerberos service tickets for accounts with Service Principal Names (SPNs) and cracks them offline. FIP detects the sudden burst of TGS requests.

📚 Sources

CrowdStrike — Falcon Identity Protection product page (ITDR). crowdstrike.com/en-us/platform/next-gen-identity-security/itdr/
CrowdStrike — Falcon Identity Protection for Microsoft Entra ID: real-time inline protection via EAM. crowdstrike.com/en-us/blog/crowdstrike-extends-real-time-protection-for-entra-id/
CrowdStrike — Falcon Identity Protection expanded with Active Directory auditing. crowdstrike.com/en-us/blog/falcon-identity-protection-active-directory-auditing-expansion/
CrowdStrike — Golden Ticket attack explained: detection & prevention. crowdstrike.com/en-us/cybersecurity-101/cyberattacks/golden-ticket-attack/
CrowdStrike — 8 types of identity-based attacks including Pass-the-Hash and lateral movement. crowdstrike.com/en-us/cybersecurity-101/cyberattacks/identity-attack/
CrowdStrike — Falcon Next-Gen Identity Security innovations: FalconID and unified hybrid identity protection (2026). crowdstrike.com/en-us/press-releases/falcon-next-gen-identity-security-innovations-expand-unified-protection-for-every-identity/

What's next?

Got Identity Protection? Next, go deep on Falcon Threat Intelligence — adversary attribution, indicator management, and how CrowdStrike's Counter Adversary Operations unit maps nation-state campaigns.

Next · All interview lessons → Practice on exam.techclick.in →

CrowdStrike Falcon Identity Protection — ITDR, AD & Entra Visibility

🎯 By the end you will be able to

Pick where you want to start

What it is

Visibility layer

Risk & enforcement

Attack scenarios

① What Falcon Identity Protection actually is — ITDR on the authentication plane

② The visibility layer — Kerberos, NTLM, LDAP and behaviour baselines

Protocol intelligence that matters

③ AI risk scoring and conditional-access enforcement

▶ Watch a Pass-the-Hash lateral movement get blocked

④ Attack scenarios — Golden Ticket, Pass-the-Hash, and stopping lateral movement

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?