Intermediate·300 points·1 solve

Credential Dumping Investigation

Learn why the first detection every SOC writes for credential theft is also the first one it mutes, and what to write instead. You will decode Windows access-rights bitmasks by hand, separate processes that merely queried a target from those that could read its memory, reason about which readers are legitimate, and recognise credential theft carried out entirely with signed operating-system binaries.

The vulnerability

The Local Security Authority process holds credential material in memory, so it is the target of choice for credential theft — and it is also opened constantly and legitimately. The antimalware engine scans it. The EDR sensor reads it. Management tooling queries it. The session and service subsystems touch it during normal operation. In this estate that is a continuous, high-volume stream from about a dozen distinct processes, which is exactly why the "something opened LSASS" rule was switched off. The evidence is in the GrantedAccess field, which is not a label but a bitmask of Windows access rights OR'd together. Only some of those bits permit reading another process's memory, and a process that was never granted that right cannot have copied a single byte out, whatever else it did. Decoding the mask is the first step and it is mechanical. It is also not sufficient on its own: a legitimate security product requests exactly the same rights, for exactly the same reason, dozens of times a day. So the second step is judgement — of the processes that could have read memory, which one has no business doing so? Expect no malware. Credential theft does not require a tool you can find on disk; several signed Microsoft binaries will write a full process dump if asked, and a dump taken away and parsed elsewhere yields the same material a dedicated tool would. Evidence is in /var/log/soc: incident-brief.md, sysmon.log, asset-inventory.csv, and access-mask-reference.md, which explains the bitmask.

Your tasks

Read the brief, then measure the noise

incident-brief.md explains why this was escalated by a human rather than by an alert, and it quotes how many events the muted rule produced in this window. Confirm that number yourself from sysmon.log, then count how many DISTINCT processes are responsible. That second figure is one of the answers, and it is the argument for why the original rule was hopeless.

Decode the access masks

Read access-mask-reference.md and work out which bit permits reading another process's memory. Then test every access event against it — a one-line python3 bitwise AND is enough. Most of the traffic fails that test outright and can be set aside permanently: those processes could not have read a byte of the target, so they cannot have taken credentials, whatever else they were doing.

Judge the survivors

A small number of processes remain. Do not stop at the mask — more than one of them holds memory-read rights entirely legitimately, and at least one requests the exact same value as your suspect, so filtering on the mask value alone will not separate them. Check asset-inventory.csv for which security products are deployed here and what they do. For each survivor ask whether reading process memory is part of its documented job. Exactly one has no such justification; record its image name and the mask it was granted. Note that this process is an ordinary Windows utility that also runs benignly elsewhere in the log, so grepping its name will not isolate anything.

Establish what it ran, and as whom

Two places name the mechanism. The access event's CallTrace shows which modules were loaded on the stack at the moment of the call, and the corresponding process-creation event carries the full command line. Both identify the library that did the work — a component that ships with Windows and is signed by Microsoft, which is why no malware search would ever have found this. Note the account it ran under and check asset-inventory.csv for what that account is supposed to be used for.

Find what it left behind, and map it

Something was written to disk moments later, recorded as a separate event with its own hash. Record its full path and the exact time. Then map the activity to a single ATT&CK technique — the one that covers extracting credential material from an operating system, not the one that covers running a program. Finally, be ready to say what the containment steps are: the answer is not only "remove the file", because if the dump left this host then every credential that was in that process is now untrusted.

Answer the questions

Start the lab, investigate the evidence in the terminal, and answer the questions here.

Hints

Loading…

Official write-up

Loading…

Frequently Asked Questions

What is credential dumping?

Credential dumping is the extraction of password hashes, tickets or plaintext secrets from a system, often by reading LSASS memory on Windows. Attackers then reuse them to move laterally or escalate privileges.

How do you detect LSASS credential dumping?

Monitor process access to lsass.exe, such as Sysmon event ID 10, and filter known benign tools. Pay attention to unusual access masks, unsigned callers and rare parent processes rather than every access.

Is this credential dumping lab free?

Yes. You review a day of raw telemetry in the browser to find the event a muted rule would have missed.

NEW350+ rooms now have a live terminal, so you can learn by typing the commands, right in your browser.Learn in a live terminal. 350+ rooms.Try a labCodelivly is 100% free, no paywall. If it helped you, chip in to keep it running.100% free. Help keep it so.Support us