NTLM vs Kerberos: How to Tell Which One Your Logs Are Showing You
NTLM vs Kerberos for SOC analysts: the 4624, 4776 and 4769 fields that name the protocol, why Windows falls back to NTLM, and queries that catch a downgrade.
NTLM vs Kerberos comes down to who does the checking. NTLM is a challenge-response exchange the resource server forwards to a domain controller for validation. Kerberos hands the client a ticket from the domain controller up front, and the server verifies it locally. In a 4624, the Authentication Package and Logon Process fields tell you which one happened.
That is the short version. With a queue in front of you, you need the longer one: which fields on which host prove the protocol, what each event leaves out, why a domain account reached a domain-joined server over NTLM at all, and which attack families live on each side.
What each protocol does
The two protocols answer the same question, "does this client know the password for this account", by different routes, and the route is what shows up in your logs.
NTLM is a family, not one protocol. Microsoft's NTLM overview (accessed 2026-09-14) describes it as the set of protocols inside Msv1_0.dll: LAN Manager versions 1 and 2, and NTLM versions 1 and 2. All of them are challenge-response. The server sends a random challenge, the client encrypts it with a hash derived from the password, and the server needs someone to check the answer. For a domain account that someone is a domain controller, reached over the server's secure channel. For a local account it is the local SAM. The overview is blunt about where that still matters: NTLM is required for workgroup members and for local logon on non-domain controllers, and Kerberos v5 is the preferred method in Active Directory.
Kerberos moves the check to the front. The client authenticates to the domain controller once and receives a ticket-granting ticket. When it wants a file share, it asks the domain controller for a service ticket for that specific server, named by its service principal name, and presents the ticket to the server. The server decrypts it with its own key and never talks to the DC for that logon. Microsoft's AskDS write-up (an April 2024 repost of a 2018 article, accessed 2026-09-14) lists the two dependencies that make this work: both sides on the same or a trusted domain, and an SPN registered in AD for the service the client is reaching.
Those two dependencies are also the causes of NTLM fallback, covered below.
The field-level decoder
For a single logon there are two places to look: the machine that was reached, and the domain controller that validated the credential. They tell you different things and neither is complete on its own.
On the destination: event 4624
Every successful logon writes a 4624 on the machine that granted the session. Four fields in it name the protocol, and Microsoft's 4624 reference (accessed 2026-09-14) defines each of them.
| Field | NTLM logon | Kerberos logon | Notes |
|---|---|---|---|
Authentication Package | NTLM | Kerberos | Negotiate means the package chose for you; Microsoft says it selects Kerberos unless one side cannot use it or the caller gave it too little to work with |
Logon Process | NtLmSsp | Kerberos | Interactive logons show User32; Negotiat (truncated) appears when the Negotiate provider handled it |
Package Name (NTLM only) | NTLM V1, NTLM V2 or LM | - | Only populated when the package is NTLM. This is the sub-protocol |
Key Length | 128 or 56 | 0 | Always 0 for Kerberos, including Kerberos via Negotiate. 56 is a weak session key |
Read Authentication Package first, then confirm with Logon Process. If the package says NTLM, the next two fields tell you how bad the NTLM was.
What the 4624 does not tell you is where the client was, reliably. The same page says that LSASS audits whatever the authenticating service hands it, so "network logons with Kerberos likely have no workstation information, and NTLM logons have no TCP/IP details". The documentation does not promise either field, so a blank Source Network Address or a - in Workstation Name is a gap in the record rather than evidence of a local logon. The logon type sits next to these fields and tells you how the session was built, not which protocol built it.
On the domain controller: 4776 versus 4768 and 4769
The DC side splits by event ID, so the event number itself is the protocol.
NTLM validation writes 4776. Microsoft's 4776 reference (accessed 2026-09-14) says it generates on the computer that is authoritative for the credential: the DC for domain accounts, the local machine for local accounts. Three properties of this event decide how useful it is:
Authentication Packageis alwaysMICROSOFT_AUTHENTICATION_PACKAGE_V1_0. It does not vary. Filter on the event ID, not on this field.- It records only
Source Workstation, the machine the attempt came from. Microsoft's example is explicit: authenticate from CLIENT-1 to SERVER-1 and the event shows CLIENT-1, with no information about SERVER-1 at all. A DC full of 4776 events tells you which workstations used NTLM and for which accounts. It cannot tell you what they reached. - It does not fire when a domain account logs on locally to a DC, and it does fire on workstation unlock, which inflates the count for accounts that lock their screen a lot.
The Error Code on a 4776 failure is the field that turns a pile of failures into a shape. The values Microsoft documents that you will actually use:
| Error Code | Meaning (per Microsoft) | Shape it usually belongs to |
|---|---|---|
0xC000006A | Bad password | Spraying or brute force when spread across accounts; a stale credential when it is one account, one source, all day |
0xC0000064 | Bad username | Account enumeration, especially against critical account names |
0xC0000234 | Account locked | The tail end of spraying; correlate with 4740 on the DC |
0xC000006D | Generic failure, including a LAN Manager authentication level mismatch | A client and server that disagree on NTLM version; a downgrade attempt looks the same |
0xC0000072 | Account disabled | A disabled account being tried is worth a look on its own |
0xC0000071 | Expired password | Usually a person, occasionally a service nobody rotated |
Kerberos writes 4768 and 4769. The 4768 reference (accessed 2026-09-14) covers the TGT request: the DC-only event that records Account Name, Client Address, Ticket Encryption Type, Pre-Authentication Type and a Result Code. The 4769 reference (accessed 2026-09-14) covers the service ticket request, and this is the one that carries the destination: Service Name is the account or computer the ticket was issued for, so a 4769 for FS01$ is a client about to reach FS01. Two values matter on both events:
Ticket Encryption Type. Microsoft's table lists0x12as AES256-CTS-HMAC-SHA1-96,0x11as AES128, and0x17as RC4-HMAC, described as the default suite for operating systems before Windows Server 2008 and Windows Vista.0xFFFFFFFFshows in audit failures.Pre-Authentication Typeon 4768.2(PA-ENC-TIMESTAMP) is normal password authentication,15and16are smart card, and0means no pre-authentication, which Microsoft's monitoring table flags as a risk because only accounts explicitly configured to skip it will show it.
The 4769 also carries a Logon GUID, and Microsoft documents it as the correlation key to the 4624 on the target host. When it is populated on both sides, that is the cleanest join you get between a DC event and a destination event. The NTLM path has no equivalent: nothing in a 4776 links to a specific 4624 except the account name and the timestamp.
The same user, the same server, twice
Here is what the decoder looks like on real-shaped records. One user, j.alvarez, on workstation WS-2214, opens a share on FS01.corp.example twice inside a minute. The first time she connects by hostname and gets Kerberos. The second time an application on her workstation connects by IP address and gets NTLM.
Kerberos path. On the file server:
Computer: FS01.corp.example
EventID: 4624
New Logon\Account Name: j.alvarez
New Logon\Account Domain: CORP
New Logon\Logon ID: 0x4C21F7
Logon GUID: {7f3b2a10-9c4e-4d2b-8a61-2e5f0c9d1b44}
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Package Name (NTLM only): -
Key Length: 0
Workstation Name: -
Source Network Address: 10.20.4.87
Source Port: 52117Simulated example generated by SOCSimulator Research.
On the domain controller, a few milliseconds earlier:
Computer: DC01.corp.example
EventID: 4769
Account Name: j.alvarez@CORP.EXAMPLE
Account Domain: CORP.EXAMPLE
Logon GUID: {7f3b2a10-9c4e-4d2b-8a61-2e5f0c9d1b44}
Service Name: FS01$
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Client Address: ::ffff:10.20.4.87
Failure Code: 0x0Simulated example generated by SOCSimulator Research.
NTLM path. On the file server, forty seconds later:
Computer: FS01.corp.example
EventID: 4624
New Logon\Account Name: j.alvarez
New Logon\Account Domain: CORP
New Logon\Logon ID: 0x4C2A9E
Logon GUID: {00000000-0000-0000-0000-000000000000}
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Package Name (NTLM only): NTLM V2
Key Length: 128
Workstation Name: WS-2214
Source Network Address: 10.20.4.87
Source Port: 52140Simulated example generated by SOCSimulator Research.
On the domain controller:
Computer: DC01.corp.example
EventID: 4776
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: j.alvarez
Source Workstation: WS-2214
Error Code: 0x0Simulated example generated by SOCSimulator Research.
Put the two pairs side by side. The Kerberos pair names the destination on the DC (Service Name: FS01$) and carries a shared Logon GUID you can join on, but the 4624 has no workstation name. The NTLM pair names the workstation on both sides, the Logon GUID is all zeros, and the DC has no idea FS01 was involved. If your investigation starts from the DC, an NTLM logon gives you the source and the account and nothing else. You have to go to the destination to find out what was touched.
Both records are for the same person, from the same machine, reaching the same share, and both are legitimate. The protocol changed because the connection string did. That is why NTLM by itself is not a finding.
Why it fell back to NTLM
Microsoft's Windows IT Pro post on the evolution of Windows authentication (Matthew Palko, 11 October 2023, accessed 2026-09-14) lists three reasons NTLM survives: it does not need a network connection to a domain controller, it is the only protocol supported for local accounts, and it works when the client does not know who the target server is. The 4624 documentation adds the fourth in its definition of Negotiate: the calling application "didn't provide sufficient information to use Kerberos". Every row in the table below is one of those four.
| Cause | What you see | Benign or suspicious |
|---|---|---|
| Client connected by IP address instead of hostname | 4624 with NtLmSsp / NTLM to a domain-joined host; often a 4769 for the same account moments earlier with a different Service Name, or none at all | Usually benign: scripts, monitoring tools, mapped drives by IP. Worth fixing, rarely worth paging |
| No line of sight to a domain controller | NTLM from VPN clients, DMZ hosts, segmented networks; the 4776 lands on the DC via the server's secure channel | Benign if the topology explains it. A workstation inside the LAN with no path to a DC is a question for the network team |
| Local account on the destination | 4624 with Account Domain equal to the computer name; 4776 written on that host, not on a DC | Benign for break-glass and build accounts. Suspicious when a local admin account is used over the network from a workstation, which is the classic lateral movement pattern |
| Workgroup or non-domain machine | Every logon is NTLM; no 4768/4769 anywhere | Expected. Microsoft's overview says NTLM must be used here |
| Application hardcoded to NTLM | The same process on the same host always produces NTLM regardless of how it names the target | Benign but a policy problem. The 2023 post warns that turning NTLM off breaks applications that hardcoded it |
| Missing or duplicate SPN | 4769 failure with 0x7 (server not found) or 0x8 (principal not unique), then a successful NTLM 4624 to the same host | Benign misconfiguration most of the time. Check who registered a duplicate before dismissing it |
| Credential replay (pass-the-hash) | NTLM from a host that normally uses Kerberos, for an account that normally uses Kerberos, often type 3 against a server the account has never touched, sometimes preceded by a type 9 logon on the source | Suspicious. A classic pass-the-hash replays the NT hash inside the NTLM exchange, so it shows up as NTLM. The same hash also works as the RC4 Kerberos key (overpass-the-hash), which produces 4768/4769 instead, so the RC4 query below matters too |
Six of the seven causes are configuration. The seventh is an attacker, and the only way to tell it from the other six is context: does this account, from this host, to this destination, normally use NTLM? A new triple over NTLM is the signal. An old triple over NTLM is Tuesday.
Detection queries
Four questions, each written in SPL against the Splunk Windows add-on and in KQL against the Sentinel SecurityEvent table. The Splunk field names below are the classic message-parsed ones (Authentication_Package, Package_Name__NTLM_only_, Key_Length). If your inputs render XML, use the AuthenticationPackageName / LmPackageName / KeyLength names instead, which are the same names KQL uses. If the KQL operators are unfamiliar, the KQL walkthrough covers summarize, make_set and dcount.
Privileged account, logon type 3, NTLM
let PrivAccounts = dynamic(["Administrator", "a-jalvarez", "svc_backup", "da_helpdesk"]);
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4624 and LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where TargetUserName in~ (PrivAccounts)
| summarize Logons = count(), Workstations = make_set(WorkstationName, 20), Sources = make_set(IpAddress, 20)
by Computer, TargetUserName, LmPackageName
| order by Logons descindex=windows sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=3 Authentication_Package=NTLM
| eval target=mvindex(Account_Name,-1)
| search target IN ("Administrator", "a-*", "svc_*", "da_*")
| stats count AS logons, values(Workstation_Name) AS workstations, values(Source_Network_Address) AS sources
BY host, target, Package_Name__NTLM_only_
| sort -logonsThe mvindex(Account_Name,-1) matters in Splunk: 4624 carries two account names and the extraction returns both in one multivalue field. Replace the hardcoded list with your tiering lookup. Pair each hit with 4672 on the same host and logon ID to confirm the session was granted sensitive privileges.
NTLMv1, LM, or a weak session key
Microsoft's 4624 monitoring recommendations say it directly: if a particular NTLM version is standard in your organisation, alert when Package Name (NTLM only) is not NTLM V2, and if the package is NTLM, alert when Key Length is not 128, because every Windows since 2000 supports the 128-bit key.
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4624 and AuthenticationPackageName == "NTLM"
| where LmPackageName in ("NTLM V1", "LM") or KeyLength != 128
| summarize Logons = count(), FirstSeen = min(TimeGenerated), Sources = make_set(IpAddress, 20)
by Computer, TargetUserName, LmPackageName, KeyLength
| order by Logons descindex=windows sourcetype="WinEventLog:Security" EventCode=4624 Authentication_Package=NTLM
| where Package_Name__NTLM_only_ IN ("NTLM V1", "LM") OR Key_Length!=128
| eval target=mvindex(Account_Name,-1)
| stats count AS logons, earliest(_time) AS first_seen, values(Source_Network_Address) AS sources
BY host, target, Package_Name__NTLM_only_, Key_Length
| convert ctime(first_seen)
| sort -logonsOn a healthy modern domain this returns a short list of old appliances, printers and one application server somebody forgot. Every row is a device that will break when NTLMv1 disappears, and every row is a device an adversary-in-the-middle relay would love, because NTLMv1 responses crack quickly. Write the list down before you need it.
4776 failures by source, with the reason decoded
This is the spraying-versus-enumeration-versus-lockout split, and it lives on the DC.
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4776 and Status != "0x0"
| extend Reason = case(
tolower(Status) == "0xc000006a", "bad password",
tolower(Status) == "0xc0000064", "bad username",
tolower(Status) == "0xc0000234", "locked out",
tolower(Status) == "0xc000006d", "generic or LM level mismatch",
tolower(Status) == "0xc0000072", "disabled",
"other")
| summarize Failures = count(), Accounts = dcount(TargetUserName), FirstSeen = min(TimeGenerated)
by Workstation, Reason
| where Failures > 10 // unbaselined; run without this line for a fortnight first
| order by Workstation asc, Failures descindex=windows sourcetype="WinEventLog:Security" EventCode=4776 Error_Code!=0x0
| eval code=lower(Error_Code)
| eval reason=case(code=="0xc000006a", "bad password", code=="0xc0000064", "bad username",
code=="0xc0000234", "locked out", code=="0xc000006d", "generic or LM level mismatch",
code=="0xc0000072", "disabled", true(), "other")
| stats count AS failures, dc(Logon_Account) AS accounts, earliest(_time) AS first_seen
BY Source_Workstation, reason
| where failures > 10
| convert ctime(first_seen)
| sort Source_Workstation, -failuresRead the output as three shapes. Many accounts with bad username from one workstation is enumeration: somebody guessing names. Many accounts with bad password and a low count per account is password spraying. One account, one workstation, bad password all day, then locked out, is a stale credential in a service or a mapped drive, and the matching 4625 on the destination will name the process. The > 10 is a placeholder, not a threshold. Microsoft's own page phrases the recommendation as "N events in the last N minutes" and leaves N to you.
4769 with RC4 for service accounts
The Kerberos-side downgrade. A service ticket encrypted with RC4 (0x17) for a service account that is a user account, not a computer account, is exactly the ticket Kerberoasting takes offline. Microsoft's Kerberoasting guidance (11 October 2024, accessed 2026-09-14) explains why RC4 is the target: it "uses no salt or iterated hash when converting a password to an encryption key", so RC4 tickets crack faster than AES ones.
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4769 and Status == "0x0"
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$" and ServiceName != "krbtgt"
| summarize Requests = count(), Requesters = dcount(TargetUserName), Sources = make_set(IpAddress, 20)
by ServiceName
| order by Requesters descindex=windows sourcetype="WinEventLog:Security" EventCode=4769 Ticket_Encryption_Type=0x17 Failure_Code=0x0
| search NOT Service_Name="*$" NOT Service_Name="krbtgt"
| stats count AS requests, dc(Account_Name) AS requesters, values(Client_Address) AS sources
BY Service_Name
| sort -requestersTwo things separate an attack from an inventory problem here. A service account that always gets RC4 tickets from the same three application servers is a service account that needs an AES key rotation. A single client requesting RC4 tickets for ten different service accounts inside a minute is a tool enumerating SPNs, and the Sources column will show it. Sort by requesters, not by count.
The deprecation timeline
Every date below is taken from the linked Microsoft page. Nothing here is extrapolated.
| When | What | Source |
|---|---|---|
| 2000 | Kerberos becomes the default Windows authentication protocol | Stated in the October 2023 Windows IT Pro post |
| 11 October 2023 | Microsoft announces IAKerb and a local KDC for Windows 11, improved NTLM auditing, and the stated end goal of "eliminating the need to use NTLM at all" | The evolution of Windows authentication |
| Windows Server 2025 | NTLMv1 removed. LANMAN and NTLMv2 deprecated: "NTLMv2 will continue to work but will be removed from Windows Server in a future release. Replace calls to NTLM with calls to Negotiate" | Features removed or deprecated in Windows Server 2025 |
| Windows Server 2025 | RC4 usage in the Kerberos authentication protocol deprecated; the page calls RC4 "a weak algorithm that can be abused for stealing credentials" and points to AES | Same page |
The 2023 post is worth reading in full because it explains the mechanism behind the deprecation rather than just the date. IAKerb lets a client with no line of sight to a DC authenticate with Kerberos through a server that has one. The local KDC gives local accounts a Kerberos path. Between them they remove two of the three reasons NTLM survives, and the post is explicit that NTLM stays available as a fallback until usage data says it is safe to disable. Nothing in any of these sources gives a date for NTLMv2's removal, and you should be suspicious of anyone who quotes one.
What this means in an investigation
The protocol does not tell you whether a logon was malicious. It tells you which attack family to consider, and that narrows the next ten minutes considerably.
NTLM alone is not an alert. The fallback table above has six benign rows and one bad one, and on most domains the benign rows outnumber the bad one by thousands to one. An alert on Authentication Package == NTLM produces a queue nobody reads. The combination is the alert: a privileged account, logon type 3, NTLM, reaching a domain-joined host that the source could have named. If the destination is reachable by hostname and the source is a domain member with a DC in sight, there was no reason for Negotiate to fall back, and the two remaining explanations are a hardcoded application or a replayed credential.
NTLM is where relay and pass-the-hash live. Pass-the-hash works because the NTLMv2 response is computed from the NT hash keyed over the username, the domain, the server challenge and a client blob, and at no point needs the password itself, so possessing the hash is as good as possessing the password. An NTLM relay attack forwards the challenge-response between a victim and a target in real time. Kerberos has its own versions (overpass-the-hash turns the NT hash into a TGT request, and Kerberos relay exists), but the plain replay and the plain relay are NTLM traffic. When you see NTLM where Kerberos was possible, look upstream for how the hash was obtained: 4648 on the source host for explicit-credential use, a type 9 logon with seclogo as the logon process, and the credential dumping indicators on the same box.
Kerberos is where roasting lives. Kerberoasting requests service tickets for SPN-bearing accounts and cracks them offline, which is why the RC4 query above filters on user-style service names. AS-REP roasting targets accounts that skip pre-authentication, which is what Pre-Authentication Type: 0 on a 4768 exposes. Both sit under T1558 and both leave DC events, not destination events, because the attacker never reaches the service. If your hunt starts from a suspicious 4769 there is no 4624 to find, and that absence is expected rather than a gap.
The DC and the destination answer different questions. For NTLM, the DC knows the account and the source workstation, and only the destination knows what was reached. For Kerberos, the DC's 4769 names the destination in Service Name, and the destination's 4624 often lacks the workstation name. Whichever side you start from, you will need the other, and the Logon GUID on the Kerberos path is the only field that joins them cleanly. On the NTLM path you are joining on account and timestamp, so pull a window, not an exact match.
Note
A ten-minute exercise that pays off on the next incident: run the NTLMv1-or-weak-key query and the RC4 service ticket query against the last 30 days and save both result sets. That is your downgrade baseline. The next time either query returns a host or a service account that is not on the list, you have a finding, and the list is what lets you say so in a sentence instead of an afternoon.
Free
Train on real alerts, with zero consequences
Practice triage on realistic alert volume in a live SOC console. Free.
Reading the protocol out of a 4624 takes a few seconds once you know the four fields. Knowing whether that NTLM logon at 02:40 was a monitoring script connecting by IP or a replayed hash from a compromised workstation takes the rest of the record, the matching DC event, and a baseline you built before the night it mattered. SOCSimulator drills that second skill against Windows authentication telemetry with the fallbacks left in.
Frequently Asked Questions
- Is NTLM still used?
- Yes, on every supported Windows version. Microsoft's NTLM overview says it is still required for workgroup members and for local logon on any machine that is not a domain controller, and the October 2023 Windows IT Pro post lists the three cases where Kerberos cannot help: no line of sight to a domain controller, a local account, or a target the client cannot name. Add applications that hardcode NTLM and you have most of the NTLM traffic on a typical domain. It is shrinking, and it is not gone.
- Why does Windows fall back to NTLM when Kerberos is available?
- Because Negotiate only picks Kerberos when both sides can use it and the caller gave it enough to work with. Kerberos needs a service principal name to request a ticket for, and it needs to reach a domain controller. Connect by IP address instead of hostname, hit a service whose SPN is missing or duplicated, use a local account, or run an application that asked for NTLM by name, and Negotiate takes the fallback. The Kerberos side of that failure often leaves a 4769 with a non-zero failure code on the DC.
- How can I tell whether a logon used NTLM or Kerberos?
- Open the 4624 on the machine that was reached and read three fields. Authentication Package says NTLM, Kerberos or Negotiate. Logon Process says NtLmSsp for NTLM and Kerberos for Kerberos. Package Name (NTLM only) is populated with NTLM V2, NTLM V1 or LM only when the package was NTLM, and Key Length is always 0 for Kerberos. On the domain controller the split is by event ID: NTLM validation writes 4776, Kerberos writes 4768 for the TGT and 4769 for the service ticket.
- Is NTLM deprecated?
- Partly removed and partly deprecated. Microsoft's removed and deprecated features page for Windows Server 2025 states that NTLMv1 is removed, that LANMAN and NTLMv2 are no longer under active feature development and are deprecated, and that NTLMv2 will continue to work but will be removed in a future release. The same page deprecates RC4 in Kerberos. The stated replacement is calling Negotiate, which tries Kerberos and falls back to NTLM only when it must. There is no announced date for the final removal of NTLMv2.
- What is the difference between NTLMv1 and NTLMv2?
- Both are challenge-response protocols in the same Msv1_0 family, along with LM. Microsoft's own comparison in the AskDS post says NTLMv1 responses are fixed length and unsalted, so they crack in seconds, while NTLMv2 responses vary in length and are salted, which slows offline cracking without making the protocol safe. In a 4624 the version shows in Package Name (NTLM only) as NTLM V1 or NTLM V2, and Key Length below 128 is a second sign of a weak negotiation. On Windows Server 2025 NTLMv1 is gone entirely.
Field notes
New walkthroughs and detections, in your inbox
A short email when we publish something worth your time. No spam, unsubscribe in one click.
Community
Continue the conversation
Discuss this with analysts who are actively training and working in the field.
Related Articles
How to Read Windows Event Logs: A SOC Analyst Guide
How to read Windows event logs in Event Viewer: pick the right channel, decode the XML view, and triage the Security events analysts see every shift.
Writing a SOC Playbook an Analyst Will Follow at 3 a.m.
What separates a SOC playbook analysts follow from a document that rots in a wiki: every step names a tool and a query, every branch carries a threshold.
Web Shell Detection: How to Find One, and Why Most Rules Miss It
Triage and detection logic for web shells: the process-parent rule, its real false positives, IIS log tells, and an ordered first 30 minutes.