Forensics traces of NTDS.dit dumping using ntdsutil utility

Active Directory stores information about members of the domain including devices and users to verify credentials and define access rights. The Active Directory domain database is stored in the NTDS.dit file. By default the NTDS file will be located in %SystemRoot%\NTDS\Ntds.dit of a domain controller.

The following tools and techniques can be used to enumerate the NTDS file and the contents of the entire Active Directory hashes.

• Volume Shadow Copy
• secretsdump.py
• Using the in-built Windows tool, ntdsutil.exe
• Invoke-NinjaCopy

In this post we will test in-built command ntdsutil.exe (Windows 2008 and later) that does a backup of the crucial NTDS.dit file, and the SYSTEM file (containing the key required to extract the password hashes), without the need to use VB Script, third-party tools or injecting into running processes.

All you need is a command prompt running with administrator privileges, and the following commands:

This same technique is implemented in one of OilRig/APT34 post exploitation tools named Gon.exe (xHunt campaign) described here by Unit42:

Upon execution, Gon.exe process will create a process "cmd.exe /c" with following commandline:

Threat hunters can create a real time detection for this by monitoring cmd.exe with similar command line and ntdsutil execution.

Checking Domain Controller default application event logs, we come accross an interesting set of events that can be used as a forensic indicator for this technique:

• Log Name: Application
• Provider Name: "ESENT"
• EventIDs of interest: 325, 326, 327 and 216

Below example of traces of the NTDS.dit copy creation:

As can be seen above the same volume snapshot path is reported in both screenshots (Event Log and Gon.exe console).

More related events capturing other interesting details:

The path of the created ntds.dit copy is also captured in eventids 325 and 327. Eventid 216 also shows the creation of  a fresh copy of ntds.dit.

The only limitation of those events is their highvolatility in time, as the application events logs get filled quickly thus chances finding them post compromise are lower (it's recommended to augment the size of all event logs in general).

MITRE ATT&CK Mapping:

Tactic: Crednetial Access

Technique: Credential Dumping

Technique ID: T1003

Procedure: Ntdsutil 

References:

https://www.cyberis.co.uk/2014/02/obtaining-ntdsdit-using-in-built.html

https://attack.mitre.org/techniques/T1003/

https://unit42.paloaltonetworks.com/xhunt-campaign-attacks-on-kuwait-shipping-and-transportation-organizations/

Hunting for suspicious use of TeamViewer - Part 1/2

N.B: TeamViewer (TV) is a great Remote Support (++) tool, and the objective of this post is to share some threat hunting ideas that could help spot malicious or abnormal usage of such tools (same principles can be applied to other third party legit Remote Support Tools).

Tools such as TV are used in a lot of environment for legit/justified business reasons, and for us as defenders we need to find ways to detect if indeed those tools are used as expected and what are the forensics and real time artefacts that we can leverage to get a better visibility level.

TV Components (High Level):

• TeamViewer_Service.exe: TV core process which install itself as a standalone service (System Integrity Level)
• TeamViewer.exe: is the main process for TV user GUI functions (Medium Integrity Level)
• tv_w32.exe & tv_x64.exe: both used for TV logging (lock access to log file) and hooking specific functions (High IL)
• TeamViewer_Desktop.exe: executes only when there is an active incoming remote support session via unattended access (System IL)

In term of networking, with exception of TeamViewer_Service.exe, all other processes connect to local host as a form of IPC between TV processes:

TV Netcon behavior can be summarized as below:

teamviwer_desktop.exe|teamviewer.exe:[localhost:high port] <-> teamviewer_service.exe [5939]<->*.teamviewer.com:5938 

In term of logging TV creates the following main "log" files:

• tvchatfiledownloadhistory.db (encrypted)
• TeamViewer**_Logfile.log: where * is indicative of TV version, 2 files with same file name one in program files and 2nd is in appdata\roaming)
• Connections_Incoming.txt : logs time, userid and TV Session ID which can be used to correlate events - incoming connections.
• Connections_Outgoing.txt: logs time, userid and TV Session ID which can be used to correlate events - outgoing connections.

The most verbose/useful log file is the TeamViwer**_Logfile.log within program files folder and with a DACL set to deny users from writing or changing the content of the file (administrators can of course delete the whole log file).

Logging is ON by default but can be turned off via GUI or setting propoerly certain registry values:

Once the logging is truned off (e.g. via GUI), following registry values get created (by default they get created only if you want to disable logging):

In this 1st part we will be covering the following hunting scenarios:

1. Tampering attempts with TV logging
2. File Transfer from attacker machine to TV client
3. Request to autorize a new device (by default TV send email notification for the 1st time a new device connects to a TV client)

a) Defense Evasion - TV Logging Disabled:

b) File Transfer:

• If tansfer is done using TV transfer files feature then the file creation on destination machine (TV client) will be logged as following:

While reviweing File Creation activity using production historical data, it shows that TeamViewer.exe usually create few files and majority of them are caching related files in:

• AppData\Local\Microsoft\Windows\INetCache\IE\*
• AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData\*

So if you are interested to be informed of what files were dropped via TeamViewer File Transfer then use Sysmon or your EDR to monitor/hunt file creation activities by process name TeamViewer.exe.  We can also see traces ("FileDataSinkFileListWin::CreateFileInternal" and PID of TeamViewer.exe) of file transfer activity in the TeamViewer**_LogFile.log:

Unfortunately if the file was dropped via Drag and drop it's logged as being created by explorer.exe:

Looking at traces of file transfer within TeamViewer**_Logfile.log (program files) we can clearly see the explorer.exe PID (5244) and also clues ("DragInterceptor: Interception successful") about a file transfer activity:

For outbound file transfer (from TV client to attacker machine), Teamviewer.exe will read the file, then send it over the IPC netcon (port 5939) to TeamViewer_service.exe which send it to the *.teamviewer.com (port 5938)

All the transfered file names are not captured in the "TeamViewer**_LogFile.log", but high likely are captured in the tvchatfiledownloadhistory.db (encrypted/protected - will be covered in part 2).

c) New Device Autorization:

If the online (TV unattended access) credentials were compromised, once the attacker will try to logon for first time and supposedly that TV account is linked to the corporate email address, then high likely you can detect this notification email via your mail security gateway (custom message filter) which can be of huge value at warning your SOC and the TV account owner to reset the password before the damage is done (btw: enable TV 2FA ASAP!)

As a conclusion for this 1st part, you will need to understand it's usage mode (incoming or outgoing) as well as file transfer activity (needed/no) which can be disabled if not needed, alert on TV log file tampering including the log file deletion (if your EDR supports file deletion logging) and lastly make sure to enable 2FA for this kind of Remote Support tools even if it's rarely used.

That's all for this part, see you in part 2.