Opening a Word file got lsass read. Remember 0x1410.

The scenario is fictional (RFC 5737 IPs). Sysmon details come from the book, not a live test. Detection only.

User jdoe opened a Word document at 09:12. Forty seconds later, lsass.exe memory was read. The number to remember is 0x1410.

What you'll learn

• Why lsass is targeted and what Sysmon EID 10 records
• Normal vs. attack GrantedAccess values
• Reading CallTrace
• Rule ideas for Wazuh and Elastic, and false positives

The story at a glance (WS01)

Time	Sysmon	Event
09:12:01	E1	WINWORD.EXE -> powershell -enc
09:12:04	E3	connect to 198.51.100.5:443
09:12:20	E11	C:\Users\Public\svc_update.exe created
09:12:40	E10	lsass access, GrantedAccess 0x1410
09:13:05	E13	Run key Updater
09:13:40	E3	10.0.0.31:445
09:14:02	E4	Sysmon stopped

0x1410

0x1000 = limited info (typical EDR, normal). 0x1410 includes PROCESS_VM_READ (0x10): the right to read process memory, which legitimate software rarely needs for lsass.

CallTrace

UNKNOWN(...) frames mean code that maps to no module on disk: likely in-memory code.

Check three things: target lsass.exe; GrantedAccess 0x1410 family (0x1010, 0x143a, 0x1fffff); unfamiliar SourceImage or UNKNOWN in CallTrace.

Rules

Wazuh (book rule 100501): target lsass\.exe$, access 0x1010|0x1410|0x143a|0x1fffff, T1003.001. Elastic EQL: Office parent -> script host -> process access to lsass. Sequences beat single events.

False positives

EDR/AV: allow-list SourceImage and expected GrantedAccess and clean CallTrace. Name-only allow-lists can be imitated.

Takeaways

Treat Sysmon stopping as an alert too, and ship logs off-host immediately.

Next: AD attacks that look like normal logs.

---

Adapted from chapter 20 and Scenario B of my Japanese book on server defense.