Pentesting Windows environments: remote delivery of PowerShell payloads

PowerShell is an amazing post-exploitation tool available to the attacker during engagements in Windows environments. Tools like PowerSploit or PowerShell Empire help out a lot during internal test. Problem is, restrictive execution policy is enabled by default on windows machines which makes it problematic to run ps1 scripts. Not having admin rights on the target machine means you basically confine yourself to executing PowerShell one-liners which have length restrictions (cmd.exe has a limit of 8191 characters).

One way to bypass execution policy is to gain admin rights on the target and "unrestrict" the execution of PowerShell scripts with Set-ExecutionPolicy cmdlet. It's a global settings so don't forget to change in back.

Another cool trick is to write a simple command that evaluates expression, effectively executing it in memory. You can evaluate a whole ps1 script no matter how large it is. Here's an example of downloading powercat code and evaluating it in one line:

Execution policy does not apply to one-line PowerShell scripts. We can go one step further and read data contents from file, evaluate it and run our payload. But why not automate this? In my case I was looking for a way to remotely execute Invoke-Mimikatz.ps1 on a number of windows machines without having to tediously upload the script via smbclient, run psexec to disable execution policy, run the script itself and then reverting execution restrictions.

The idea is quite simple. We deliver our payload via single bat file. PowerShell script is encoded in base64 and placed in comment section of bat. Comments are followed by a small one-liner that reads the same file, and decodes our payload and runs it. You can use a python script to quickly convert your favorite PowerShell script to bat file. Again, execution policy doesn't matter in because you are only executing a PowerShell one-liner.

Now we can pass this file to psexec.py  with "-c" switch and get the results. Running remote mimikatz is now a one-liner and is perfectly scriptable if you want to do a mass-harvesting of credentials in domain :)

    More mimikatz magic - enable multiple RDP connections on a workstation:

You can find the script here - https://github.com/artkond/bat-armor

Pivoting kerberos golden tickets in Linux

Kerberos golden ticket allows attacker to establish persistent and covert authenticated access to Windows domain. The attack works as follows:

1. Attacker gains administrator privileges in domain
2. Attacker extracts ntlm hash of a domain user "krbtgt" and obtains SID of the target domain
3. The attacker forges kerberos ticket
4. This ticket is used to authenticate in domain with privileges of domain administrator

Here's a detailed walkthough on how to use golden tickets on Kali Linux.

Let's start with obtaining krbtgt ntlm hash. I use an encoded version of mimikatz utility that gets me krbtgt hash without alerting AV (https://github.com/artkond/bat-armor/blob/master/examples/krbtgt.bat):

 Stripping last number from krbtgt SID (in out case 502) we obtain domain SID S-1-5-21-3251500307-1840725093-2229733580.

Now to generate the ticket we use ticketer.py utility from Impacket (https://github.com/CoreSecurity/impacket/blob/master/examples/ticketer.py):

Almost ready. Just need to export system variable, so impacket's psexec.py can use the ticket. When running psexec.py use -k key for kerberos authentication

Same thing goes for other impacket tools such as wmiexec.py (which is more covert than psexec.py as it does not upload any binaries and start no services) or atexec.py (uses scheduled tasks to exec your code):

Now that's all fine but what if you want to upload some files? Most probably you'll want to use smbclient for this task. Using kerberos with smbclient is a bit more complicated. You have to add your kerberos realm to config file located @ /etc/krb5.conf. In case you don't have krb5.conf you might want to install krb5-user package from your distro's repo.

[realms]

    PENTESTO.LOC = {
        kdc = tcp/dc01:88
    }

TCP is preferable as you will be able to tunnel your requests to kerberos server over socks proxy if you decide to do some fun pivoting. Notice that realm should be uppercase.

Pivoting

Using kerberos ticket over socks tunnel requires a bit more extra work. Most likely you don't have direct access to active directory name servers so you have to edit /etc/hosts file. Add target server, domain controller (which is also kerberos server), and domain's FQDN. This is mandatory because kerberos only works with hostnames and will fail if you specify IP-address.

$ cat /etc/hosts

...

10.0.0.89  pentesto.loc

10.0.0.89  dc01

...

I my case target server is the domain controller. Edit proxychains. Add your socks proxy and comment proxy_dns directive:

$ cat proxychains.conf

...

#Proxy DNS requests - no leak for DNS data

#proxy_dns 

...

[ProxyList]

# add proxy here ...

# meanwile

# defaults set to "tor"

socks4  172.16.46.157 3128

In case you've set up /etc/hosts and /etc/krb5.conf correctly there should be no trouble running smbclient or psexec.py over socks:

Note that psexec.py is sensitive to the info you provide. Domain name and username should be exact same you entered when forging ticket with ticketer.py.