Sunday, February 2, 2014

Attacker Methodology Intro Part Deux (PrivEsc and Propagation)

Background and Assumptions

This is not an in-depth treatment of the subject matter, this is meant as a quick and dirty intro to attacker methodology. The goal is that folks that read or review this will have a basic understanding of how attackers think, and/or some of the challenges that they will face trying to defend a network. There are some notes in here for CTF/CCDC style competitions as well.

Local Privilege Escalation

Starting access level: non-privileged access to a single host in the network
End goal: privileged access to the host
Attacker Steps: Gain information about the local machine and exploit a misconfiguration or software vulnerability to elevate privileges

Background

So... when you compromise a target you gain code execution within the context of the software or user you just exploited. That means that if you just pwnd a web server you're running with the privs of that web server process on the remote server. On the client side that means that you're running code within the privs of the user you just popped. In the days prior to Windows XP, it was pretty routine that one would compromise a target just to find that they were running as an administrator on the local machine and well they didn't need/use anything in this section. 

There's a big difference as an attacker to running in (especially) the different Windows integrity levels - specifically stuff that you can't do:
Low Integrity
  • Pretty much the only thing you can do here is write to a virtual filesystem / registry
  • No cross-boot persistence (can't write to any fun reg. keys etc.)
Medium Integrity
  • You get cross-boot persistence, but only for when one user logs in
  • You can keylog (only the user that your originally popped)
  • No cached password dumping, no dumping hashes from the local host
  • No computer-wide keylogging
  • No computer-wide persistence
  • No packet crafting or MITM attacks
  • I *would* like to point out that you can still PTH by generating the token on your (remote) attack machine and then just port-forwarding the authentication traffic (135-139,445)
High Integrity
  • Pretty much everything since you're a local administrator on the box, still some files and reg. keys that are "untouchable"
NTAUTHORITY\SYSTEM
  • Prior to Windows Vista this is god-mode
  • WinVista + you can't touch anything that's owned by the TrustedInstaller group
NTAUTHORITY\TRUSTEDINSTALLER
  • TrustedInstaller is a service that runs to install patches / updates to the OS that was introduced in Windows Vista
  • welcome to god-mode

Step 1 - Situational Awareness:

Good attackers don't do anything until they know what's going on with the host that they're executing code on, which at a minimum includes enumerating ( I like these because none require admin privs to run ) :
  • What user they are running as
    • whoami
    • set
    • net user <NAMEOFUSER> /domain
  • Who uses the system
    • net localgroup users
    • net localgroup adminsitrators 
  • What the system is for
    • net statistics /workstation
    • net statistics /server
  • What else is hanging around
    • ipconfig /all
    • ipconfig /displaydns
    • arp -a

Step 2 - Misconfigurations:

A whole lot of the time you don't need a software vulnerability as an attacker to privesc on Windows or Linux due to the high difficulty of hardening and monitoring changes off of a baseline for every system in a network. Most of the time the misconfigurations are either:
  • Permission issues
  • 3rd party software and insecure directory permissions
  • service configuration issues
  • Domain-specifc configs (startup scripts, 
  • passwords stored improperly on the system ( in registry keys, 3rd party software, config scripts 
Ways to check for these...

Step 3 - Software Vulnerabilities:

OH: " patches ? we don't need no stinking patches "
Umm... turns out that patches are kind of important to not getting easily pwnd. Using Windows Update is a good way to make sure that you get / have patches. Other ways include looking at add/remove programs, wmic and other administration tools

Read More

TrustedInstaller

TrustedInstaller

PrivEsc

Encylopedia of Windows PrivEsc
AT is the new Black *

Lateral Movement

Starting access level: Access to a single host in the network
End goal: Access to other hosts in the network
Attacker Steps: Gain information about the network, leverage password re-use, network permissions or network misconfiguration to traverse the network

Situational Awareness (it's back):


Local Credentials only go so far ... unless everyone's got the same local credentials
  • If the network will allow you - local admin password re-use is a great way to bounce from machine to machine
  • If all of the local passwords are different ... then you should look at Group Policy Preferences (GPP)... there's this thing called the CPassword attribute which, when certain policies are active will store most-all of the local passwords for machines in the domain in a plaintext-equivalent fashion
  • Look at network shares and do what you can with read or write access (.LNK files

Methods for executing code remotely

Running code remotely... there really aren't that many ways to do it
  • PSExec
  • MOF (managed object format)
  • Remote task scheduling
  • PowerShell Remoting
  • Remote Registry Modification
  • Service executable replacement (remote)
  • RDP ( which isn't turned on by default and is really only on servers )
  • Malicious update server
  • WPAD
  • Network Ninja Time / MITM

Network PrivEsc

Starting access level: Access to multiple system on the network 
End goal: Access to other hosts in the network
Attacker Steps: Gain information about the network, leverage password re-use, network permissions or network misconfiguration to traverse the network

Elevating privs on the network may not be necessary depending on how an attack gained access to the target network. On the one hand if the initial compromise is a server, it's usually just a matter of dumping cached credentials and bouncing around around the different servers until a set of creds show up for the DC and then it's game over. 

Moving from a workstation to more privileged access in the domain can be quite a bit more challenging, especially in networks that have good separation (don't have flat domain / enterprise structures), restrictive OU's, and responsible admins (that use low-priv accounts to manage the workstations / do support tasks).

Situational Awareness

  • Using LDAP / DSQuery to pull all of the relevant domain information
    • All admins for the workstation that you're on
    • OU's, Groups and separations in the network
    • All admins in the network - enumerating built-in and other groups in the network
  • Use nltest (from the ntreskit) to determine trust relationships
  • note: these tools can be a pain in the arse to get running in a customer networks (they're not installed by default) and all of this can be better accomplished through PowerShell and the net commands will get it done in a pinch

Pulling yourself up by your bootstraps

Once you have some level of access to other assets in the network, a lot of the work comes down to figuring out which assets in the network belong to network admins, targeting their workstations is usually the most effective way of elevating privs in the network. Misconfiguration of network deployment and scanning tools is a another quick method of escalating privs as they often do not securely manage authentication remotely (the credentials can be stolen) or securely store credentials. Some examples of this include:
  • C:\unattend.txt
  • C:\sysprep.inf
  • C:\sysprep\sysprep.xml
  • VNC
  • SNMP parameters
Service Accounts...
  • Service accounts are *traditionally* accounts used for non-interactive tasks that need to be run in a network 
  • The easiest way to set this up is making a domain user account not associated with an actual user which is good for attackers and problematic for admins because:
    • the password has to be managed by the network administrators
    • it's really hard to change the password because usually these accounts are critical for the operation of the domain
    • more times than I'd like to count, these passwords end up being variations on p@$$w0rd1 or QAZWSXEDCRFV (keyboard walks)
  • MSA's aren't really good news for attackers, the accounts have privs for one computer, but aren't really useful for moving around the network. 

More Reading


* this is an aggregate source which may not credit all sources

No comments:

Post a Comment