Obtaining and Utilizing User Credentials

Core Impact can collect user credentials from a compromised host through a deployed agent. These Identities can later be used for cracking password hashes, if necessary, and then installing additional agents as a valid user. It is fairly typical of most network setups that certain usernames and passwords are shared among multiple components. If some of the passwords for these accounts can be cracked, Core Impact provides functionality to deploy additional agents using this information.

About Identities in Core Impact

An Identity is a token that could be used by an Identity Verifier in an authentication transaction.

Any Identities that are found by Core Impact are stored in the Entity Database (Network and Web). Any Core Impact module that uses Identities, will have an IDENTITY parameter for faster selection. There will also be USER/PASSWORD and NTLM Hashes parameters available in situations where you want to use a custom identity not present in the database.

Below are examples of modules that use Identities (this is an abbreviated list):

  • WMI Shell
  • Windows Service Manager
  • Windows Secrets Dump
  • Install Agent Using SMB
  • Install Agent Using WMI

Obtaining the Password Hashes from a Compromised Host

In the case of a UNIX-like system such as Linux, the agent can be used to download the /etc/shadow file from the target. This file can then be used to download password hashes to be fed to a password cracker. This can be done easily using the File Browser within the agent's context menu, or by using the "get" command from the mini-shell. Please note that in a normal setup, the agent will have to be running with root privileges on the system to be able to access the /etc/shadow file.

In the case of Windows systems, the password hashes are stored in the machine's SAM (Security Accounts Manager) and NTDS.DIT for Active Directory configurations. The files holding this data are locked while the OS is running and cannot be accessed directly by the user. However, it is possible to access this information with different approaches.

Exporting the SAM hives and Volume Shadow Copy restore NTDS.DIT

This approach is the least intrusive (since no injection takes place) and can be achieved with the Windows Secrets Dump module. This module can be run remotely (if you have Administrative Identities against the target host) or locally under an agent running as Administrator or SYSTEM.

Injecting code directly into the LSASS process

This procedure is more intrusive and must be used if the previous one didn't work.

  1. Start with an agent deployed on the Windows machine from which you want to recover the password hashes. The agent has to be running as SYSTEM for this procedure to be successful. If the agent is not currently running as SYSTEM, use the Privilege Escalation step on the RPT view (see Privilege Escalation).
  2. Select this agent on the Entity View.
  3. Run the Password Dump from SAM module from the Information Gathering/Local folder in the Modules Panel. If the agent is currently running as part of the LSASS process (i.e., it was deployed with an exploit for a vulnerability within LSASS), then simply running the module will collect all the user's password hashes. If this is not the case, then the Agent process injector module will automatically be executed, injecting a new agent into the LSASS process from which the Password Dump from SAM module will be able to collect password hashes.

In additional to the Password Hashes stored in the compromised host, there are usually Identities present in memory as well. Sometimes those identities are even in clear-text form. In order to access these identities use the Mimikatz local module.

Kerboros Golden & Silver Tickets

Core Impact allows users to create Kerberos tickets that can be used in a penetration testing campaign. You can use the following modules:

  • Create Kerberos Golden Ticket: creates a Kerberos Golden Ticket for a designated user
  • Create Kerberos Silver Ticket: creates a Kerberos Silver Ticket for a designated user
  • New Kerberos Identity: creates a new identity to test against a Kerberos KDC