Author: Rt.
I recently came across a CTF challenges with following problem statement:
Oh no, our Active Directory domain controller got hacked!
For some weird reason, now any account in our company can be accessed with the same password. Which password exactly?
The file provided in the challenge can be downloaded from here and it was part of Hack & Learn Initiative 2021 https://hli.spbctf.com
The full memory dump when downloaded is of size 2 GB
We will start by gathering more information about the type of this memory dump, and it’s needless to say that Volatility will be the tool of our choice here.
To get more information about the dump we use the plugin “windows.info.Info“
PS C:\> py .\vol.py -f D:\memory.dmp windows.info.Info
Progress: 100.00 PDB scanning finished
Variable Value
Kernel Base 0xf8000dc74000
DTB 0x1a7000
Symbols file:///D:/volatility3/symbols/windows/ntkrnlmp.pdb/6066913DFBAD4EF6B754E136C12BECA3-1.json.xz
Is64Bit True
IsPAE False
primary 0 WindowsIntel32e
memory_layer 1 WindowsCrashDump64Layer
base_layer 2 FileLayer
KdDebuggerDataBlock 0xf8000df0ba20
NTBuildLab 9600.17031.amd64fre.winblue_gdr.
CSDVersion 0
KdVersionBlock 0xf8000df0bd80
Major/Minor 15.9600
MachineType 34404
KeNumberProcessors 4
SystemTime 2021-10-22 21:06:36
NtSystemRoot C:\Windows
NtProductType NtProductLanManNt
NtMajorVersion 6
NtMinorVersion 3
PE MajorOperatingSystemVersion 6
PE MinorOperatingSystemVersion 3
PE Machine 34404
PE TimeDateStamp Sat Feb 22 08:08:18 2014The above command helps us to identify it as Windows 64 Full Crash Dump.
Since the problem is related to authentication, we can guess that something got messed up in LSASS.EXE which deals with this task. For the time being we will not discuss about already known malware that was exactly responsible for such an attack on Active Directory server but we will try to reach there step by step.
We start our analysis by running the “windows.malfind.Malfind” plugin on the crash dump and inspect its output.
PS C:\> py .\vol.py -f D:\memory.dmp windows.malfind.Malfind
Volatility 3 Framework 1.0.1
Progress: 100.00 PDB scanning finished
PID Process Start VPN End VPN Tag Protection CommitCharge PrivateMemory File output HexdumpDisasm
504 lsass.exe 0x65e820000 0x65e820fff VadS PAGE_EXECUTE_READWRITE 1 1 Disabled
4c 89 4c 24 20 44 89 44 L.L$.D.D
24 18 89 54 24 10 48 89 $..T$.H.
4c 24 08 48 83 ec 58 c7 L$.H..X.
44 24 20 9a 00 00 c0 c7 D$......
44 24 38 84 21 09 d1 c7 D$8.!...
44 24 3c 92 3a bf 06 c7 D$<.:...
44 24 40 2b 72 75 7a c7 D$@+ruz.
44 24 44 b5 ac b8 25 ba D$D...%.
0x65e820000: mov qword ptr [rsp + 0x20], r9
0x65e820005: mov dword ptr [rsp + 0x18], r8d
0x65e82000a: mov dword ptr [rsp + 0x10], edx
0x65e82000e: mov qword ptr [rsp + 8], rcx
0x65e820013: sub rsp, 0x58
0x65e820017: mov dword ptr [rsp + 0x20], 0xc000009a
0x65e82001f: mov dword ptr [rsp + 0x38], 0xd1092184
0x65e820027: mov dword ptr [rsp + 0x3c], 0x6bf3a92
0x65e82002f: mov dword ptr [rsp + 0x40], 0x7a75722b
0x65e820037: mov dword ptr [rsp + 0x44], 0x25b8acb5
1600 Microsoft.Acti 0xe3ee8d0000 0xe3ee8dffff VadS PAGE_EXECUTE_READWRITE 2 1 Disabled
00 00 00 00 00 00 00 00 ........
61 ba 35 55 73 99 00 01 a.5Us...
ee ff ee ff 02 00 00 00 ........
20 01 8d ee e3 00 00 00 ........
20 01 8d ee e3 00 00 00 ........
00 00 8d ee e3 00 00 00 ........
00 00 8d ee e3 00 00 00 ........
0f 00 00 00 00 00 00 00 ........
0xe3ee8d0000: add byte ptr [rax], al
0xe3ee8d0002: add byte ptr [rax], al
0xe3ee8d0004: add byte ptr [rax], al
0xe3ee8d0006: add byte ptr [rax], al
1600 Microsoft.Acti 0xe3ef2b0000 0xe3ef2c9fff VadS PAGE_EXECUTE_READWRITE 1 1 Disabled
00 00 00 00 00 00 00 00 ........
08 00 2b ef e3 00 00 00 ..+.....
08 00 2b ef e3 00 00 00 ..+.....Very well, our suspicion about malicious modification of LSASS.EXE was correct and it’s time to analyze the injected code that we see in this process. To do this we will dump this memory address starting at address “0x65e820000” as pointed out in the output of malfind plugin.
Let’s dump this memory by making use of “windows.vadinfo.VadInfo“
PS C:\> py .\vol.py -f D:\memory.dmp windows.vadinfo.VadInfo --address 0x65e820000 --dump
Volatility 3 Framework 1.0.1
Progress: 100.00 PDB scanning finished
PID Process Offset Start VPN End VPN Tag Protection CommitCharge PrivateMemory Parent File File output
504 lsass.exe 0xe001085950e0 0x65e820000 0x65e820fff VadS PAGE_EXECUTE_READWRITE 1 1 0xffffe00106576960 N/A pid.504.vad.0x65e820000-0x65e820fff.dmpThe needed memory is now dumped in the current location as “pid.504.vad.0x65e820000-0x65e820fff.dmp“. Just open it with a dissembler of your choice. and convert to 64bit code.
This look as like a valid shell code which is moving some bytes onto the stack and making indirect calls to multiple functions.But what are these functions? To know about it we will make use of WinDBG.
Load the file in WinDBG, fix the symbols and navigate to the memory address 0x65e820000 that was pointed by malfind plugin previously. We now see those indirect calls functions with resolved symbol names as shown in image below
Now we do a quick google search for one of the interesting function rc4HmacInitialize. We get top relevant results which is very similar to the problem statement described in the CTF challenge.
Once we read more about the use of this function from the article it gets clear that this case is exactly the same as the Skeleton Key malware attack that was first identified by Dell Secureworks.
This malware basically downgrades the Windows authentication to use a weaker encryption algorithm which is RC4_HMAC instead of AES. It also hooks the function responsible to check validity of user’s password to provide HACKER’s implanted NTLM hash for verification instead of NTML hash provided by SAM database in case of failed login attempts.
What it basically achieves by doing this is it can add extra password (or say a master password) that will be compared for unlocking any account in case the first actual login attempt check by original Window’s function fails.
There is more detailed explanation on how this malware work in a research paper here.
With this understanding in place we now have to retrieve the HACKER’s NTLM hash for getting the master password. The needed NTLM hash is what we see as the first few bytes that are saved into local variables and used to initialise the rc4_hmac function shown below.
The NTML Hash is “842109d1” + “923abf06” + “2b72757a” + “b5acb825” = “842109d1923abf062b72757ab5acb825“. Let’s use https://hashes.com/ to crack this NTML hash.
And there we go, our Master Password is: “mybaby22” and this is also the FLAG for the CTF challenge.
RE 