Memory_Analysis

Scenario

Analyze memory dump extracted from the Windows machine

Executive Summary

A memory image from a Windows 10 workstation held a process wearing the name of a core Windows component but running from the wrong directory with the wrong parent. Dumping that process’s backing file showed it was a public privilege-escalation enumeration tool renamed to blend in. Its environment block named the interactive account it ran under, and the SAM hashes recovered from the same image let that account’s password fall to a dictionary attack in seconds.

Artifacts

• Memory image: the Windows memory dump in evidence/ → analyse with Volatility 3 (vol)
• Hash cracking: NT hash from windows.hashdump → hashcat -m 1000 with rockyou.txt

Timestamp note: Volatility prints SystemTime in UTC. Submit it as YYYY-MM-DD hh:mm:ss.

Discovery

windows.info reports the kernel build and the SystemTime field, which is the clock value at the moment the image was taken. That is the acquisition time, not the boot time or any process start time.

vol -f <memdump> windows.info

Defense Evasion

Build the tree with windows.pstree and check each process against its expected lineage. The odd one is a process named like a core security component that sits under explorer.exe (PID 7592) instead of wininit.exe/services.exe, and its image path is C:\Windows\System\ rather than C:\Windows\System32\. The genuine one is spawned once at boot by the system, not by a user shell.

vol -f <memdump> windows.pstree

Tip: windows.cmdline | grep -i users/temp and windows.psscan are quick follow-ups for anything running from user-writable paths.

The Q2 process was a masquerade, so the real tool is inside its image. windows.filescan gives the file object address for C:\Windows\System\ and windows.dumpfiles --virtaddr extracts the cached image. Running strings over it surfaces the tool’s own banner and internal names, which belong to a well-known privilege-escalation enumeration scanner. The answer was reasoned from those strings plus the format mask (seven characters, three-letter extension) rather than read from a version resource, and it was the name HTB accepted.

vol -f <memdump> windows.filescan > filescan.txt

vol -f <memdump> windows.dumpfiles --virtaddr 0xdf0e86793960

strings -n 8 file.0xdf0e86793960.*.img | head

Gotcha: Q2 asks for the name the process was running as; Q3 asks what it really is. The two answers are different, so don’t repeat the Q2 name.

Credential Access

The masquerading process runs in a user session, so its environment block names the account. windows.envars --pid 7592 lists USERDOMAIN and USERNAME. Combine them as DOMAIN/USER to match the mask; the domain is the machine name because this is a standalone workstation.

vol -f <memdump> windows.envars --pid 7592

windows.hashdump pulls the SAM hashes out of the image. Take the NT hash for the account from Q4 (a9fdfa038c4b75ebc76dc855dd74f0da) and run it through hashcat mode 1000 against rockyou.txt. It cracks immediately.

vol -f <memdump> windows.hashdump

hashcat -m 1000 h.txt /usr/share/dict/rockyou.txt

Gotcha: Python’s hashlib often lacks MD4, so a hand-rolled NT hash cracker fails on some builds. hashcat avoids the problem.

Attack Summary

Phase	Action
Defense Evasion	Privilege-escalation scanner renamed to lsass.exe and placed in C:\Windows\System\
Execution	Scanner launched from the user’s explorer.exe session (PID 7592)
Credential Access	Account password is weak (password123) and its NT hash is recoverable from SAM

IOCs

Type	Value
Process	lsass.exe (PID 7592, parent explorer.exe)
Path	C:\Windows\System\lsass.exe
Real tool	winpeas.exe
Account	MSEDGEWIN10\CyberJunkie
NT hash	a9fdfa038c4b75ebc76dc855dd74f0da
Password	password123

MITRE ATT&CK

Technique	ID	Description
Masquerading: Match Legitimate Name or Location	T1036.005	Enumeration tool named after lsass.exe and placed in a look-alike system directory
System Owner/User Discovery	T1033	Account recovered from the process environment of the running scanner
OS Credential Dumping: Security Account Manager	T1003.002	NT hash recovered from the SAM via hashdump
Brute Force: Password Cracking	T1110.002	Offline dictionary attack on the NT hash

Defender Takeaways

Check lsass.exe by lineage and path, not name. The genuine process is a child of wininit.exe, runs from System32, and exists once. A copy under explorer.exe from C:\Windows\System\ fails all three. Alert on any lsass.exe whose image path or parent differs.

Memory triage should start with the tree. pstree plus a path check exposed the masquerade without any signature. Pair it with filescan/dumpfiles and strings to name the real tool when the file on disk is renamed.

Weak passwords turn a memory image into a credential leak. An NT hash from SAM cracked against a common wordlist in moments. Enforce length and banned-password lists so a captured hash is not equivalent to the plaintext.

Conclusion

A renamed enumeration scanner hid behind the most trusted process name on Windows, and its own environment block and the SAM in the same image gave up the account and its password. The masquerade was caught by lineage and path alone.