This document summarizes techniques for privilege escalation using the Metasploit framework. It begins by explaining why Metasploit is useful and why privilege escalation is important for gaining more access and control. It then provides examples of how to write Metasploit modules for local privilege escalation exploits, including generating payloads, including the necessary Metasploit mixins, and interacting with sessions post-exploitation. Specific local privilege escalation techniques demonstrated include exploiting vulnerable setuid binaries like Nmap, modifying Windows scheduled tasks, and relaying Windows authentication. The document concludes by discussing future work to improve Metasploit module development.
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
Privilege Escalation with Metasploit Framework
1. PRIVILEGE ESCALATION WITH THE
METASPLOIT FRAMEWORK
For when you absolutely, positively,
have to have root (and don't mind
the occasional kernel panic).
13. HIGH IS BETTER THAN LOW
Persistence
• Backdoor login facilities, add users
Stealth
• Modify logs to conceal presence
• More options for hiding files/processes
Various nefarious activity
• Inject into other users' processes
• Capture packets
16. MSF::EXPLOIT::LOCAL
• Inherit from Exploit
– Provides payloads and handlers
• Include Exploit mixins
– Most useful right now is Exploit::EXE
• Include Post mixins
– Provides session interaction
– Write files, manipulate registry, etc
17. CONTRIVED EXPLOIT (1/2)
include Msf::Exploit::EXE
include Msf::Post::Common
include Msf::Post::File
...
'Platform' => 'linux',
'Arch' => ARCH_X86,
...
20. REAL-WORLD* EXAMPLE -- NMAP
• Nmap is a security tool
• It needs root for some things
• Sometimes admins chmod +s it for
convenience
* This is not a default configuration and the
Nmap man page tells you it's stupid
21. NMAP SCRIPTING ENGINE
• Scan stuff with LUA
• Very powerful
• Fast and easy to write (compared to C++ for
hacking on Nmap itself)
22. NSE-FLAVORED LUA
• Has a specific structure
• API expects you to have an action function
and several fields
– Complains if they aren't there
27. MS10_092_SCHELEVATOR
• Stuxnet 0day
• Schtasks stores tasks as XML files
– Readable/Writable by user that created task
• Uses CRC32 to verify integrity
29. MODIFY IT TO RUN AS SYSTEM…
content.gsub!(
'LeastPrivilege',
'HighestAvailable'
)
content.gsub!(
/<UserId>.*</UserId>/,
'<UserId>S-1-5-18</UserId>'
)
34. COMPILING/ASSEMBLING WITH METASM
• Can compile C for x86/x86_64
• Assemble x86, x64, mips, arm, ppc and more
• Executables or shared objects
35. COMPILED C DEV PROCESS*
• Develop on a system with headers
• "Factorize" structs, #defines, etc
– There are gotchas with this
• Builds dynamic executables
[*] Subject to change without notice
36. LINUX/LOCAL/UDEV_NETLINK
• UDEV gets events from the kernel
• On multicast netlink sockets
– Which can only be sent by root
• Doesn't mind getting unicast
– Which can be sent by unpriv users
53. SMB RELAY
• Well-known attack
• Some mitigations break it, but largely still
useful and will be for a long time
54. Drop LNK file (post/windows/escalate/droplnk)
Setup a relay (exploit/windows/smb/smb_relay)
Wait for an Admin to open
that directory
File Server
Compromised
Attacker
Target
Create LNK file
Victim
SMB RELAY + LNK FILE
55. AUTOMATIC DOMAIN AUTH
• Windows stores creds in memory and does
NTLM auth using your current token
• When you do something in the GUI that
requires auth, it happens transparently using
those creds
• If your user has Local Admin on another box,
you can create/start services (usually)
60. FUTURE WORK
1. Compile to shellcode
2. Upload in memory
3. Fork (prevents parent session crash)
4. Child jumps to shellcode
5. Do the root dance
61. FUTURE WORK
• Port all the stuff in post/*/escalate/ to
Exploit::Local
• Pull more code up into mixins
62. CONCLUSIONS
• Shells are awesome
• Root shells are better
• Metasploit is awesomesauce
• If it doesn't already do what you need, it's
easy to add new modules
I’m egypt. I like Comic Sans and I don’t care who knows it
I’m not Egypt
I’ve never used my beard to take over a country. But I'm working on it.
I work on a really cool project that makes it easier to get shells.
Metasploit was created in 2003, I started using it circa 2004, started contributing in 2007. HDM gave me commit access in April 2008, we released 3.2 under a BSD license in October 2008. Acquired by Rapid7 in Oct 2009. Currently 10 full-time employees on the Metasploit. Literally hundreds of contributors.
Metasploit is a framework, first and foremost. It's not just a bunch of exploits, it's everything you need to write exploits; it's a clearinghouse for compromised machines; it's a means of automating reconnaissance, compromise, post-compromise, and pivoting.
3 main reasons
First, It's already great at getting shells.
We have nearly a thousand exploits and support dozens of protocols.
OSS. I mention this every chance I get because I think it’s worth repeating. You have the source code. It’s BSD-licensed. It’s pretty darned easy to write your own stuff to work with it. Ruby is an easy language to learn and even if you don’t like Ruby because you love terrorists and hate freedom, it’s easy to interface with RPC. If you write something awesome that you want the world to see, getting it in the Metasploit trunk gives you an instant userbase of over 150,000 hackers.
Lastly, it's usually faster and easier to write Ruby vs C. Sometimes you have to hand-assemble a payload, sometimes you can save hours by writing it in C. Ruby can save you even more. When you have to get down and dirty, you can use metasm to write C or assembly.
This should be fairly obvious, root is better than no privs, but why?
In general higher privileges give you more options. More places to hide, more
Can also include Auxiliary and Exploit mixins, of course.
Lots of public exploits exist for this bug, discovered by Tavis Ormandy and Julien Tinnes. spender did a lot to publicize, rcvalle wrote a version for PPC. It's interesting in part because it effects a wide range of kernel versions: 2.4.4 -> 2.4.37.4 and 2.6.0 -> 2.6.30.4
That's all kernels from May 2001, through August 2009.
This is a well-known attack. I'll explain it briefly to give you some background.
If Victim is Local Admin on Target, you can get a SYSTEM shell via psexec.
It used to be even more useful before ms08-068, which broke the ability to relay back to the victim. Coffee shops and airports were overflowing with free shells. A good time was had by most.
Create an LNK file on a share you have access to, post/windows/escalate/droplnk
Set up exploit/windows/smb/smb_relay pointing at Target
Go get coffee while you wait for an Admin to look at the file share.
The first point is how WCE, mimikatz, fgdump, et al can grab password hashes out of memory. That's still important, but if you don't need the hash to authenticate (since you're already authenticated), why bother uploading a tool that will get caught by AV? Much better to use built-in Windows functionality.
"lpMachineName [in, optional]
The name of the target computer. If the pointer is NULL or points to an empty string, the function connects to the service control manager on the local computer."
If you provide a hostname/address here, does the normal NTLM authentication song and dance and lets you transparently modify the remote service system.
"lpBinaryPathName [in, optional]
If you specify a path on another computer, the share must be accessible by the computer account of the local computer because this is the security context used in the remote call. However, this requirement allows any potential vulnerabilities in the remote computer to affect the local computer. Therefore, it is best to use a local file."
Most places in Windows that expect a path can take a UNC path which will cause Windows to transparently authenticate to whatever host you specify.
I struggled a bit with where to put this module. It requires a payload, so it's an exploit. It requires a session so it's a post. Good candidate for Exploit::Local, but it's really a remote.
And exploit/windows/local/remote/ is a bit awkward