Category: Sysinternals

Some interesting sites:


Reference articles to secure a Windows domain:

Sysinternals sysmon:!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow


Securing Domain Controllers to Improve Active Directory Security


Download sysmon:

NEW: Sysmon 6.0 is available ! :  and how to use it:

Installation and usage:

List of web resources concerning Sysmon:

Mark russinovitch’s RSA conference:!2843&ithint=file%2cpptx&app=PowerPoint&authkey=!AMvCRTKB_V1J5ow

Sysmon config files explained:

View story at

Else other install guides:

Sysinternals Sysmon unleashed


Detecting APT with Sysmon:

Sysmon with Splunk:

Sysmon log analyzer/parsing sysmon event log:


logparser GUI:

Behind this catchy title is a real need. As a system administrator, it may be worthwhile to audit all of your organization’s Active Directory accounts to assess the level of security for user accounts. Let’s see how we do it!

Web resources and Methods:

How to improve Windows DNS logging (audit and analytics):


DNS logging (audit and analytics):

Free tool:

Scripts to parse DNS debug logs:


Anyone who has worked with Security Incident and Event Management (SIEM) or Intrusion Detection/Prevention System (IDS/IPS) alerts knows it can be very, very difficult to track down the actual source of the network traffic. Tracking the source becomes even more difficult when it comes to finding the machine that attempted resolution of a known bad or suspicious domain.

The Cause: DNS architecture

The Domain Name System (DNS) architecture is the primary reason why it can be so hard to find the machine attempting to resolve a bad or suspicious domain. Most organizations are Microsoft based and rely on their domain controllers to perform DNS resolution. These domain controllers are configured to act as recursive resolvers, meaning they perform resolution on behalf of the client. Because of this, when you get a SIEM or IDS/IPS alert, the source IP address will generally belong to the domain controller. This causes problems, as it usually is not the domain controller that is infected, but some client behind it. Even if you are not a Microsoft based organization, there is usually some form of a recursive resolver in place, which is at a lower level in the network than the edge IDS/IPS that detects the activity.

Why do most organizations use a recursive resolver? The answer is simple: so the internet does not see all the internal client addresses as they resolve domains. If you use NAT on your firewall, it limits what the world is able to see, but makes managing of the firewall rules for DNS more difficult. It also causes more network traffic as these recursive servers are generally caching as well. In addition, it puts more control around the name resolution service to help spot anomalies and control behavior.

The Solution: Implement DNS logging or network architecture approach

Performance considerations

DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 and Windows Server 2016 Technical Preview is designed to have a very low impact on performance. The following sections discuss DNS server performance considerations when additional logging is enabled.


Prior to the introduction of DNS analytic logs, DNS debug logging was an available method to monitor DNS transactions. DNS debug logging is not the same as the enhanced DNS logging and diagnostics feature discussed in this topic. Debug logging is discussed here because it is also a tool that is available for DNS logging and diagnostics. See Using server debugging logging options for more information about DNS debug logging. The DNS debug log provides extremely detailed data about all DNS information that is sent and received by the DNS server, similar to the data that can be gathered using packet capture tools such as network monitor. Debug logging can affect overall server performance and also consumes disk space, therefore it is recommended to enable debug logging only temporarily when detailed DNS transaction information is needed.


Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default, and typically will only affect DNS server performance at very high DNS query rates. For example, a DNS server running on modern hardware that is receiving 100,000 queries per second (QPS) can experience a performance degradation of 5% when analytic logs are enabled. There is no apparent performance impact for query rates of 50,000 QPS and lower. However, it is always advisable to monitor DNS server performance whenever additional logging is enabled.


DNS Server logging must be enabled to record events from all DNS server functions

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Press Windows Key + R, execute dnsmgmt.msc.

Right-click the DNS server, select Properties.

Click on the Event Logging tab. By default, all events are logged.

Verify “Errors and warnings” or “All events” is selected.

If any option other than “Errors and warnings” or “All events” is selected, this is a finding

Log on to the DNS server using the Domain Admin or Enterprise Admin account.

Open an elevated Windows PowerShell prompt on the DNS server to which event logging needs to be enabled.

Use the Get-DnsServerDiagnostics cmdlet to view the status of individual diagnostic events.

All diagnostic events should be set to “True”.

If all diagnostic events are not set to “True”, this is a finding

Use the Set-DnsServerDiagnostics cmdlet to enable all diagnostic events at once.

Set-DnsServerDiagnostics -All $true

Also enable debug log rollover.

Set-DnsServerDiagnostics – EnableLogFileRollover $true

The NSA released a PDF entitled “Spotting the Adversary with Windows Event Log Monitoring” earlier this year. The good news is it’s probably one of the most detailed documents I’ve seen in a long time. Everything from setting up Event Subscriptions, to a hardened use of Windows Remote Management, including the use of authentication and firewalls, this document tells you how to securely setup an environment where you can natively consolidate and monitor event log based entries. In addition, the NSA goes onto cover a number of areas that should be monitored – complete with event IDs:

Event forwarding guidance:

Malware archeology cheat sheets:

Machine-specific issues – which can be indications of malicious activity

  • Application Crashes
  • System or Service Failures
  • Kernel and Device Signing
  • The Windows Firewall

Administrator Activity – specific actions performed that may be suspect

  • Clearing of Event Logs
  • Software and Service Installation
  • Remote Desktop Logon
  • Account Usage

The bad news is you’re still left to sort out a TON of event log detail and interpret whether the entries are a problem or not.

Additionally: Changes to Group Policy only show up in the events as a change to the policy, but lack detail on exactly what was changed within the Group Policy.

To truly have a grasp on whether you have an “adversary” within or not and, if so, what that adversary is doing, you’re going to require a solution that not only collects events, but can correlate them into something intelligent. Your solution should:

  • Consolidate events
  • Focus on the events you are concerned about
  • Provide comprehensive detail about the changes to your systems, security and data

Three software solutions:

  • Netwrix Auditor for AD
  • Dell change auditor for AD
  • IBM QRadar (SIEM)

Splunk (SIEM)  : Splunk Windows Auditing using the NSA guide:

MS white-paper best practices to secure AD:

MS Advanced threat analytics (MS ATA):

Windows Event IDs useful for intrusion detection:

Windows Vista events and above

Category Event ID Description
User Account Changes 4720 Created
4722 Enabled
4723 User changed own password
4724 Privileged User changed this user’s password
4725 Disabled
4726 Deleted
4738 Changed
4740 Locked out
4767 Unlocked
4781 Name change
Domain Controller Authentication Events 4768 TGT was requested
4771 Kerberos pre-auth failed
4772 TGT request failed
Logon Session Events 4624 Successful logon
4647 User initiated logoff
4625 Logon failure
4776 NTLM logon failed
4778 Remote desktop session reconnected
4779 Remote desktop session disconnected
4800 Workstation locked
4801 Workstation unlocked
Domain Group Policy 4739 Domain GPO changed
5136 GPO changed
5137 GPO created
5141 GPO deleted
Security 1102 Event log cleared
Software and Service Installation 6 New Kernel Filter Driver
7045 New Windows Service
1022, 1033 New MSI File Installed
903, 904 New Application Installation
905, 906 Updated Application
907, 908 Removed Application
4688 New Process Created
4697 New Service Installed
4698 New Scheduled Task
External Media Detection 43 New Device Information
400 New Mass Storage Installation
410 New Mass Storage Installation
Group Changes Created Changed Deleted Members
Added Removed
Security Local 4731 4737 4734 4732 4733
Global 4727 4735 4730 4728 4729
Universal 4754 4755 4758 4756 4757
Distribution Local 4744 4745 4748 4746 4747
Global 4749 4750 4753 4751 4752
Universal 4759 4760 4763 4761 4762

Remotely enable PSRemoting and Unrestricted PowerShell Execution using PsExec and PSSession, then run PSRecon

Option 1 — WMI:
PS C:\> wmic /node:”″ process call create “powershell -noprofile -command Enable-PsRemoting -Force” -Credential Get-Credential

Option 2 – PsExec:
PS C:\> PsExec.exe \\ -u [admin account name] -p [admin account password] -h -d powershell.exe “Enable-PSRemoting -Force”


PS C:\> Test-WSMan
PS C:\> Enter-PSSession
[]: PS C:\> Set-ExecutionPolicy Unrestricted -Force


Option 1 — Execute locally in-memory, push evidence to a share, and lock the host down:
[]: PS C:\> IEX (New-Object Net.WebClient).DownloadString(‘’)
[]: PS C:\> Copy-Item PSRecon_* -Recurse [network share]
[]: PS C:\> rm PSRecon_* -Recurse -Force
[]: PS C:\> Invoke-Lockdown; exit

Option 2 — Exit PSSession, execute PSRecon remotely, send the report out via email, and lock the host down:
[]: PS C:\> exit
PS C:\> .\psrecon.ps1 -remote -target -sendEmail -smtpServer -emailTo greg.foss[at] -emailFrom psrecon[at] -lockdown

Be careful! This will open the system up to unnecessary risk!!
You could also inadvertently expose administrative credentials when authenticating to a compromised host.
If the host isn’t taken offline, PSRemoting should be disabled along with disallowing Unrestricted PowerShell execution following PSRecon


Identifies the account that requested the logon – NOT the user who just attempted logged on. Subject is usually Null or one of the Service principals and not usually useful information. See New Logon for who just logged on to the system.

  • Security ID
  • Account Name
  • Account Domain
  • Logon ID

Logon Type:

This is a valuable piece of information as it tells you HOW the user just logged on:  See 4624 for a table of logon type codes.

Account For Which Logon Failed:

This identifies the user that attempted to logon and failed.

  • Security ID:  The SID of the account that attempted to logon. This blank or NULL SID if a valid account was not identified – such as where the username specified does not correspond to a valid account logon name.
  • Account Name: The account logon name specified in the logon attempt.
  • Account Domain: The domain or – in the case of local accounts – computer name.

Failure Information:

The section explains why the logon failed.

  • Failure Reason: textual explanation of logon failure.
  • Status and Sub Status: Hexadecimal codes explaining the logon failure reason. Sometimes Sub Status is filled in and sometimes not. Below are the codes we have observed.
Status and Sub Status Codes Description (not checked against “Failure Reason:”) 
0xC0000064 user name does not exist
0xC000006A user name is correct but the password is wrong
0xC0000234 user is currently locked out
0xC0000072 account is currently disabled
0xC000006F user tried to logon outside his day of week or time of day restrictions
0xC0000070 workstation restriction
0xC0000193 account expiration
0xC0000071 expired password
0xC0000133 clocks between DC and other computer too far out of sync
0xC0000224 user is required to change password at next logon
0xC0000225 evidently a bug in Windows and not a risk
0xc000015b The user has not been granted the requested logon type (aka logon right) at this machine

Process Information:

  • Caller Process ID: The process ID specified when the executable started as logged in 4688.
  • Caller Process Name: Identifies the program executable that processed the logon. This is one of the trusted logon processes identified by 4611.

Network Information:

This section identifies where the user was when he logged on. Of course if logon is initiated from the same computer this information will either be blank or reflect the same local computers.

  • Workstation Name: The computer name of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. Workstation may also not be filled in for some Kerberos logons since the Kerberos protocol doesn’t really care about the computer account in the case of user logons and therefore lacks any field for carrying workstation name in the ticket request message.
  • Source Network Address: The IP address of the computer where the user is physically present in most cases unless this logon was initiated by a server application acting on behalf of the user. If this logon is initiated locally the IP address will sometimes be instead of the local computer’s actual IP address.  This field is also blank sometimes because Microsoft says “Not every code path in Windows Server 2003 is instrumented for IP address, so it’s not always filled out.”
  • Source Port: Identifies the source TCP port of the logon request which seems useless since with most protocols’ source ports are random.

Detailed Authentication Information:

  • Logon Process: (see 4611)
  • Authentication Package: (see 4610 or 4622)
  • Transited Services: This has to do with server applications that need to accept some other type of authentication from the client and then transition to Kerberos for accessing other resources on behalf of the client.  See
  • Package name: If this logon was authenticated via the NTLM protocol (instead of Kerberos for instance) this field tells you which version of NTLM was used.  See security option “Network security: LAN Manager authentication level”
  • Key Length: Length of key protecting the “secure channel”.  See security option “Domain Member: Require strong (Windows 2000 or later) session key”.  If value is 0 this would indicate security option “Domain Member: Digitally encrypt secure channel data (when possible)” failed

 Obviously, you need to find a hack before you can take measures to stop the attack and recover from it. Where do you begin? Every hack is unique, but you should always check certain places first. Here are the key locations in which to start your search.

Registry subkeys. If you suspect that a particular machine has been hacked, check the Run subkeys in that machine’s registry first. Look for any unfamiliar programs that load from these subkeys. Not only do attackers favor the Run subkeys as a launching point for rogue programs, but intruders can launch viruses from those subkeys as well. The subkeys apply to Windows Server 2003, Windows XP, Windows 2000, Windows NT, Windows Me, and Windows 9x. The specific subkeys to check are:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

If you’re running Windows 2003, XP, Win2K, or NT systems, you also need to check the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Policies\Explorer\Run subkey.

Any program that you don’t recognize is a potential hacking program. Use Google or a similar search engine to search the Internet for the program name and determine whether the program is legitimate. You should be especially suspicious of programs that load from C:, C:\windows, and C:\windows\system32. I strongly suggest that you make a habit of regularly reviewing these registry keys so you become familiar with all the programs that are set to automatically load on your computers.

The following subkeys are less commonly used to launch hacking programs, but you need to check them also. These subkeys apply to all Windows OSs. If the default registry key contains a value other than “%1” %*, the program is most likely a hacker program.

  • HKEY_CLASSES_ROOT\batfile\shell\open\command
  • HKEY_CLASSES_ROOT\comfile\shell\open\command
  • HKEY_CLASSES_ROOT\exefile\shell\open\command
  • HKEY_CLASSES_ROOT\htafile\shell\open\command
  • HKEY_CLASSES_ROOT\piffile\shell\open\command
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\batfile\shell\open\command
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\comfile\shell\open\command
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile\shell\open\command
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htafila\shell\open\command
  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes\piffile\shell\open\command

Services. Review the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry subkey on all Windows OSs. The entries under this subkey specify the services that are defined on your computer. I suggest that you look directly in the registry instead of using Windows’ Services GUI because some services (e.g., Type 1 services) don’t show up in the Services GUI. Again, check for programs you don’t recognize. If possible, compare the Services subkey entries and values to a machine that you know is hack-free and investigate any differences you find.

Startup Folder. Check the C:\Documents and Settings\All Users\Start Menu\Programs\Startup and C:\Documents and Settings\user_name>\Start Menu\Programs\Startup folders for unfamiliar programs and hidden files. To display a list of hidden files in the current folder and any subfolders, at a command prompt, enter

dir /a h /s

Task Scheduler. Check the C:\windows\tasks folder for unauthorized tasks. Investigate any scheduled task that you don’t recognize.

Win.ini. Malicious users can load hacking programs automatically from C:\windows\win.ini. Look in the following section of the win.ini file:

\[windows\]                              Run=                              Load=

Any program listed after Run= or Load= will load automatically when Windows starts.

System.ini. Intruders can use shell commands to load programs in C:\windows\system.ini. Search system.ini for:

\[boot\]                              shell=explorer.exe

Any program listed after explorer.exe will load automatically when Windows starts.

Other locations exist from which a hacker can automatically load programs to launch when Windows starts. Sysinternals’ Autoruns freeware utility shows you which programs are configured to load during startup on NT and later systems. You can download the tool from

Open Ports and Unauthorized Users
After you’ve run your initial key-locations check for hacking activity, look for unexpected or suspicious open ports.

Windows forensics:

Powershell windows forensics:

Powershell windows forensics:

Powershell windows forensics:


The situation was pretty straight-forward; a system (Win7SP1) had been identified as having been infected with malware at one point.  What had been determined from the initial analysis that had been conducted was that the system have been infected in Sept, 2014.  As it turned out, the malware in question had been deleted by an AV scan around mid-Aug, 2015, and the image had been acquired near the end of Sept, 2015.  Two user profiles had been identified as having been involved in the initial infection.

The goal of this analysis was pretty simple.  Essentially, the initial analysis work had already been done, and a report had been delivered to the client. My objective for this analysis was to gain greater insight into the infection process, and to see if I could develop threat intelligence from anything else that I found.

I performed all of my work using free and open-source tools.

I conducted my analysis using Notepad++.

I created a timeline of system activity using:

  • File system metadata
  • Selected Windows Event Logs
  • Registry hives (Software, System, Security)
  • NTUSER.DAT and USRCLASS.DAT from the two profiles of interest
  • User WebCacheV01.DAT IE browser history files

The process I used to create my timeline is pretty much exactly what’s listed in Windows Forensic Analysis 4/e, in ch. 7.  The process took only a couple of minutes to put together a timeline and begin analyzing it.  From the time I opened the image in FTK Imager, I had a timeline in less than 30 min. Also, something I really like about it is that the process can be used in such a manner that only those files required are sent to another analyst to construct a timeline.

The system did have Prefetch files but given the time frame, there were no files of interest in the Prefetch folder.

Once I created the timeline, I was able to easily add context to what I was looking at using other tools.  For example, I parsed the user’s WebCacheV01.dat files initially using esedbexport.exe, and then using ESEDatabaseView.  An important take-away from this is data interpretation…entries have several time stamps associated with each visited URL, and the incorrect identification and interpretation of those time stamps can significantly impact your findings.  For example, the visited URL has an expiry date time stamp; assuming that this is when the site was last accessed can have a significant (and perhaps detrimental) impact on your overall analysis.

I took a look at IE session recovery files using the Structured Storage Viewer; I got what I needed out of the particular streams of interest, and added notes to my timeline.

Mapping the user’s TypedURLs values with the TypedURLsTime values was pretty fascinating, although all it really did was support findings that didn’t pertain directly to the malware.  Still…it was pretty cool.

User shellbags proved to be very illuminating, and the UserAssist information added additional context to what I was seeing.  In the case of one user profile, the combination of those two artifacts illustrated intentional, purposeful activity…the user navigated to a specific subfolder, and double-clicked a specific .exe file, launching it.  File system and Registry events following this activity indicated the execution of the application.

Hibernation File
It turned out that the system was a laptop, and had a hibernation file.  I extracted the file, and used Volatility 2.5 to convert it to raw format.  The “imageinfo” command told me that the hibernation file had been created on 13 Sept 2015,  a bit before the image was acquired.  I didn’t expect to find anything of value from the memory image, but I ran a couple of commands (pslist, psxview) anyway.  Doing so essentially validated my suspicions, but better to do it than not.  Besides, I wasn’t stopping my other analysis…the command prompt where I ran the commands simply went to the background, and I examined the output files when the commands completed.

The previous analysis had indicated that strings/IOCs associated with the malware had been found in the hibernation file.  I used strings.exe, and then the Volatility ‘strings’ command, and found that those strings were in free space.

Working with VSCs
A quick check of the image indicated that there were volume shadow copies (VSCs) available, which was great.  Most corporate systems I’ve dealt with for the past couple of years have had VSCs disabled for some reason, and here was one that didn’t.  I ran vhdtool.exe to “convert” the image, which essentially added a footer to the file.  As my analysis system is Windows 10, I renamed the file to have the “.vhd” file extension.  I opened the Disk Management utility and attached the newly-created VHD, and used the following command to list the available VSCs:

vssadmin list shadows /for=g:

Interestingly, I basically followed the process laid out in this blog post.  The output of the vssadmin command showed me that there was a VSC that had been created on 13 Jul 2015, which was about a month prior to the malware being detected and quarantined by AV.  I linked the VSC to a folder on my analysis system, and added the contents of the folder to FTK Imager; however, this didn’t give me the level of access I wanted, as I wanted to get, among other things, a copy of the $MFT from the VSC.

That’s where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:\, which appeared as a RAM image.  I then added the logical volume to FTK Imager, and was able to extract the $MFT, as well as other files.   By creating a timeline using files extracted from the VSC, I was able to create a bit more context around the

Creating the timeline in the manner that I did allowed me to get started on my analysis in fairly short order, identify what needed a closer look, and then add context and notes to the timeline.  I didn’t have to wait for an automated tool to complete, and then trudge through a lot of data that didn’t pertain to what I was trying to determine.  I admit, I had a bit of a leg up because of the initial analysis that had been conducted, but the process I used would have led me to the initial indicators pretty quickly.  Specifically, the use of eventmap.txt in parsing Windows Event Logs allows for a number of event records to be auto-tagged, and then easily searched for in the timeline.  Searching the timeline for the “[MalDetect]” tag would’ve taken me to the “Symantec Endpoint Protection Client” event ID 51 record that identified what would be my initial pivot point.

As it turns out, there were a number of “Symantec Endpoint Protection Client/51” events in the timeline, so an easy fix to that would have been to do something like this:

type events.txt | find “[MalDetect]” > av_events.txt

The above command runs through the events file and locates all malware detection events, putting them into a separate file.  From there, I could have run:

parse -f av_events.txt > av_tln.txt

This would give me a nano-timeline of just AV detection events, giving me a much smaller set of data to analyze, and on which I could pivot.  This would also pick up all malware detection events, for any such events mapped in the eventmap.txt file.

Accessing the shadow volume allowed me to collect copies of files that were not otherwise accessible, as well as get a look at the state of the system prior to the malware being removed.  In this case, the malware employed two persistence mechanisms, which meant that two copies of the malware existed on the system.  My initial timeline provided an indication of this, as immediately prior to the AV writing it’s detection and quarantine message to the Windows Event Log, there were changes to two locations within the file system, and to one Registry key.  Accessing the shadow volume from a time when the malware existed on the system allowed me to confirm what I had suspected.  It only took a few minutes, and to be honest, it was worth time to close the loop on the speculation.

I should note that I exported the hibernation file from the shadow volume, but once I converted it to raw format, the “imageinfo” command showed me that it had the same “image date and time” as the one from the image.  Running “pslist” and “psxview” gave me the exact same information as running those commands on the original hibernation file.  I need to look into this more, but it seems that the hibernation file is not tracked in shadow volumes, although the $MFT is.

To prevent hackers to spread active payload between your computers, you can block at the network perimeter the following ports:

TCP 135

TCP 3389


TCP 3268





TCP 1433

TCP 5985


Also the reference of MS for ports and services: