Dump Windows password hashes efficiently - Part 3

[co4ie]

Dump Windows password hashes efficiently - Part 3

In the previous two posts of this series, I discussed how to dump Windows local users' password hashes (SAM) and Windows domain users' password hashes from domain controllers (ntds.dit).

When the password policy setting is configured to enforce password history, Windows stores a certain number of used passwords before an old password can be reused. The following screenshot shows you where this policy can be set.

Local Security Policy (secpol.msc) / Account Policies / Password Policy / Enforce password history

By default on workstations, this value is set to 0 and on domain controllers it is set to 24. This means that when dumping domain users' hashes from active directory's ntds.dit file, there are high chances to dump also the password history allowing you, during the password cracking phase, to recognise patterns used by the target users.

Despite not being current password hashes, pattern identification can lead to further attacks. For instance, ease of guessing passwords used against standalone services at later stages of your post-exploitation. Therefore, never underestimate the added value provided by dumping and cracking the password history.

Many of the tools introduced so far can dump the password history: Cain & Abel, PWDumpX along others. pwhist from Toolcrypt is also a valid option.

LSA secrets

LSA secrets is an area in the registry where Windows stores important information. This includes:

• Account passwords for services that are set to run by operating system users as opposed to Local System, Network Service and Local Service.
  
• Password used to logon to Windows if auto-logon is enabled or, generally, the password of the user logged to the console (DefaultPassword entry).
  

LSA secrets are stored in registry hive HKEY_LOCAL_MACHINE/Security/Policy/Secrets. Each secret has its own key. The parent key, HKEY_LOCAL_MACHINE/Security/Policy, contains the data necessary for accessing and decoding the secrets.

Dump LSA secrets

As per SAM hashes, the LSA secrets can be accessed by DLL injection into the lsass.exe process or from the registry files.

If you are Administrator and the target system is used in production, I recommend you to choose the safe path and copy off the system the registry files: SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel can extract LSA secrets from these files.

Alternatively, there are numerous tools that can be used to dump LSA secrets by injecting into lsass.exe process: gsecdump has proved to be the most reliable for LSA secrets, working across all Windows versions and architectures. On 32-bit architecture, the original lsadump2 has proved to be good too. Despite my expectations, the two NirSoft tools (LSASecretsDump and LSASecretsView) have failed to dump services' account passwords, regardless of the architecture.

Regardless of the technique used, the passwords extracted are UTF-16 encoded. This means that they are in clear-text as opposed to SAM hashes. You can read a detailed description of the LSA secrets format here by moyix.

Follows the output of gsecdump on a server running IBM DB2 and PostgreSQL. Both database management systems run as Windows local users:

 C:\tools>gsecdump.exe -l

        aspnet_WP_PASSWORD

         [...]

        _SC_DB2

        [B] 74 00 65 00 73 00 74 00 70 00 61 00 73 00 73 00  t.e.s.t.p.a.s.s.  testpass
[/B]
        [...]

        _SC_postgresql-9.0

        [B] 74 00 65 00 73 00 74 00 70 00 61 00 73 00 73 00  t.e.s.t.p.a.s.s.  testpass[/B]

        [...]

Threats posed by LSA secrets

Now, imagine that you have compromised a server part of a Windows domain, you have got a shell as Local System. If you want to extend your control over the network perimeter, one of the viable ways is to verify if any service runs as real operating system users and, if so, extract their clear-text password from LSA secrets.

You can run services.msc from Start / Run and sort the entries by Log On As column to check this quickly. Obviously, the built-in sc.exe command can do the same as well as other less known tools.

It is common to identify enterprise software like Veritas Netbackup, Microsoft SQL Server, Microsoft Exchange and others running as real users. More dangerously, sometimes system administrators opt to run services as domain users, if not domain administrators.

This is clearly wrong and poses a high threat to overall security of the target Windows domain because, as an attacker, you can dump the LSA secrets and use the clear-text domain administrator password to login to the root domain controller and takeover the Windows network.

I have added these tools and improved the spread-sheet recently.

Sursa