Skip to content

syntax-auth.md

Latest commit

 

History

History
137 lines (110 loc) · 10.3 KB

syntax-auth.md

File metadata and controls

137 lines (110 loc) · 10.3 KB

Authentication

All commands within Titanis that authenticate over the network accept a uniform set of authentication parameters that supports a variety of authentication scenarios. When building an authentication context, Titanis attempts to build a context for both NTLM and Kerberos. If both contexts are available, Titanis wraps them in an SP-Nego context. If only one context is available, Titanis does not wrap it in SP-Nego unless the application protocol requires it (such as SMB2).

Other than the system clock, Titanis uses only the information in the command line and certain environment variables for authentication; it does not use any information from your current session, such as the name of your user account or the name of your workstation. Use -Workstation to specify the name to report as your workstation during authentication (NTLM and Kerberos).

Quick Reference

Notes

  1. Commands have built-in support for Kerberos; you do not need to request tickets prior to running a command.
  2. All commands accept tickets as either a .kirbi or .ccache file. No conversion necessary is necessary.
  3. The -TicketCache parameter may be specified either explicitly on the command line or taken from the KRB5CCNAME environment variable.
    1. Titanis commands work best if you maintain a ticket cache per user and set KRB5CCNAME to this file.
    2. Tickets are requested as necessary and added to the ticket file and reused in subsequent commands.
    3. If a ticket file contains tickets for multiple users, use -UserName to filter which tickets are used.
    4. Titanis skips tickets that are outside their validity period.
  4. Ticket files specified with -Tgt or -Ticket are never modified.
    1. If a file contains both a TGT and a service ticket, you may specify the same file for both parameters.
  5. If you specify a ticket file (-Tgt, -Ticket, or -TicketCache) without specifying a user name or realm, Titanis searches for the first usable ticket. 1.
  6. Ticket files specified with -TicketCache are updated to include any tickets requested during authentication.
    1. If the file doesn't exist, it is created. If the extension is .ccache it is created as a ccache file; otherwise as a kirbi file.
    2. If it does exist, Titanis detects and retains the format of the file regardless of the extension.
    3. If the file is modified outside of the Titanis command (detected by last modified time) while the Titanis command is running, Titanis does NOT overwrite the file.
  7. If a command requires multiple tickets, it will use the tickets in the specified ticket files and request missing tickets from the KDC (if specified).
  8. Titanis automatically handles inter-realm referrals.
    1. It determines the KDC of the next realm by resolving the realm name using DNS; it does not query for the SRV record.
  9. When a certificate is specified, the certificate may be in either .pfx or .pem format. If the .pem file does not contain the key, there is a corresponding -XxKey argument (e.g. -UserCert and -UserKey).
If you have... then use... Supports Notes
Nothing -Anonymous NTLM Use with -vv to get the domain and computer name of a server.
User name with... -UserName <username> The domain is inferred from the NTLM_CHALLENGE message.
  ...password -Password <password> NTLM Be sure to escape special characters as required by your shell.
  ...NTLM hash -NtlmHash <hex-encoded hash> NTLM Use just the NTLM hash; no colons
User name and domain with... -UserName <domain>\<username> You may need to escape the backslash depending on your shell. The domain name may be either the NetBIOS name or FQDN.
-UserName <username>@<domain>
-UserName <username> -UserDomain <domain>
  ...password -Password <password> NTLM, Kerberos Be sure to escape special characters as required by your shell.
  ...NTLM hash -NtlmHash <hex-encoded hash> NTLM, Kerberos (RC4 HMAC only) Use just the NTLM hash; no colons.
  ...AES 128 key -AesKey <hex-encoded hash> Kerberos (AES128) AES 128 and AES 256 are distinguished by the size of the key.
  ...AES 256 key -AesKey <hex-encoded hash> Kerberos (AES256)
Ticket-granting ticket and KDC -Tgt <TGT file name> -Kdc <endpoint> Kerberos Titanis requests the necessary service tickets from the KDC.
-TicketCache <TGT file name> -Kdc <endpoint> Kerberos Titanis requests the necessary service tickets from the KDC.
Service ticket -Ticket <ticket file name> Kerberos The SPN of the ticket must match what the command requires.
-TicketCache <ticket file name> Kerberos The SPN of the ticket must match what the command requires.
Certificate file as a ...
  ... .pfx with certificate and key -UserCert <.pfx file> -UserKeyPassword <passphrase> Kerberos -UserKeyPassword is used to decrypt the file and is only required if the file is encrypted.
  ... .pem with certificate and key -UserCert <.pem file> -UserKeyPassword <passphrase> Kerberos -UserKeyPassword is used to decrypt the file and is only required if the file is encrypted.
  ... .pem with certificate and separate .key -UserCert <.pem file> -UserKey <.key file> -UserKeyPassword <passphrase> Kerberos -UserKeyPassword is used to decrypt the file and is only required if the file is encrypted.

The Authentication parameter group defines parameters that specify how the tool is to authenticate with the target. Most protocols exchange security tokens to build a security context to authenticate the user and provide message security services, such as signing and sealing. The parameters specify how to build this security context. Titanis supports the following security protocols:

  • NTLM
  • Kerberos
  • SPNEGO

Some protocols require a specific security protocol. For example, SMB2 requires SPNEGO, which itself may enclose both NTLM and Kerberos. Some protocols, such as RPC, will accept a number of security protocols along with a field in the header that specifies how to interpret the tokens. Titanis will use the provided parameters to build the appropriate type of security context. If the parameters support multiple security protocols and the application protocol supports SPNEGO, Titanis prepares a security context for each supported security protocol and wraps them in an SPNEGO context.

In general, to use Kerberos, you must specify the KDC address with -Kdc. If no ticket is in the cache, Titanis will attempt to contact the KDC to request a ticket.

Other Parameters

Parameter Description
-Workstation <name> Name of the workstation to send along with the authentication request. Windows uses this to evaluate logon restrictions and usually includes it in the event log record for the authentication request.
-NtlmVersion <m.n.b.r> Version number to send in NTLM

Service for User (S4U)

Titanis commands integrate support for Service-for-user-to-self (S4U2self) and Service-for-user-to-proxy (S4U2proxy) scenarios. S4U allows you to use a service account to obtain a service ticket for and impersonate a user account when you don't have credentials for that user account.

Parameter Description Note
-S4UserName <user name> Name of user to impersonate If the user name does not include the domain, then the domain of the service is assumed.
-S4UserCert <certificate file name> X.509 certificate identifying user to impersonate
-S4ProxyService <service account> Name of service account to proxy through May be specified as <class>/<host> or <account name>

Notes

  1. Only one of -S4UserName or -S4UserCert are required for S4U.
    1. If both are specified, they must agree.
  2. The presence of -S4ProxyService indicates S4U2proxy.
    1. Otherwise, S4U2self is used.
  3. S4U may be combined with any Kerberos authentication scenario above.
    1. The provided credentials must be for the service account, not the user to impersonate.
    2. At each step in the sequence, Titanis checks the ticket files provided by -Tgt, -Ticket, and -TicketCache for the desired ticket.
    3. If the desired ticket is found, it is used, and the KDC is not contacted for that step.

To test S4U (or any authentication scenario), consider using Lsa whoami. This command prints name of the user that authenticates to it. It accepts the usual authentication parameters.

S4U2self Sequence

The full S4U2self sequence is as follows:

  1. Request TGT for -UserName using credential specified by -Password, -NtlmHash, or -AesKey.
  2. Use TGT to request a service ticket to the service required by the command.
  3. Use S4U2self to request a ticket for the user specified by -S4User* to the service required by the command.

S4U2proxy Sequence

The full S4U2proxy sequence is as follows:

  1. Request TGT for -UserName using credential specified by -Password, -NtlmHash, or -AesKey.
  2. Use TGT to request a service ticket to the service specified by -S4ProxyService.
  3. Use S4U2self to request a ticket for the user specified by -S4User* to the service specified by -S4ProxyService.
  4. Use S4U2proxy to request a ticket for the user specified by -S4User* to the service required by the command.

Example

Let's say you have a TGT for COBEL-WKS$ and wish to impersonate user milchick.

Smb2Client ls \\LUMON-FS1\C$ -UserName allentown@LUMON -Password password -Kdc 10.66.0.11 -S4UserName milchick -S4ProxyService host/allentown

This command:

  1. Requests a TGT for user allentown (or retrieves one from the cache)
  2. Requests a service ticket for user milchick to the proxy service host/allentown using S4U2self.
  3. Using the S4U2self ticket from above, requests a service ticket for user milchick to cifs/LUMON-FS1.

Notes

  1. You may specify one or both of the -S4User* parameters. If you specify both -S4UserName and -S4UserCert, they must match; otherwise, the KDC will likely fail the request.
  2. During testing, when specifying -S4UserCert, the DC takes considerably longer to respond (around 10 seconds).
  3. The name supplied to -S4ProxyService may be of the form <class>/<instance> or simply the service account name.