Thursday, February 18, 2016

Post-Exploitation Shellcode

Recently I was experimenting with Office Macro shellcode. And it kept getting flagged/caught by EMET!

Increasingly I find myself needing Post-Exploit Shellcode fragments...
I realized, if I am executing shellcode Post-Exploit, there really is no reason to scan memory for kernel32.dll , loadlibary, and getprocadress etc...

I already HAVE access to the API in Office Macros and PowerShell.

I know, I'm slow... Should have dawned on me earlier...

Realize I am trying to exec stub shellcode to preserve existing infrastructure... Metasploit or CobaltStrike for example

There is a lot that could be done Post-Exploit

So, Post-Exploit shellcode execution has a different set of requirements/capabilities.


So early this morning I wrote a quick proof of concept found here:

We can let the Macro or PowerShell provide the handle to the necessary calls, in a way more natural, that is more difficult to pick up by EMET.

Again, this is a really rough draft, an area I continue to experiment with. But I suspect, there is a lot more to this.

Probably has application to the way we call Invoke-Shellcode.ps1, etc...

These are all Post-Exploit calls.

Time to crank out some more asm.
Thats all for now.


Cheers,
Casey @subt0x10

Tuesday, February 2, 2016

Application Whitelisting Quick Reference Guide

Okay, I know, I normally post about how to circumvent Whitelisting...
Now for something all together different.

Are you familiar with the concept of a Cyber Defense Exercise or Competition.
If not start here: http://www.nationalccdc.org/

This will be a succinct list of things to read and quick guidance.

I hope to make the case that Application Whitelisting is a tool that can be used effectively to defend.

It is not meant to be comprehensive or thorough.  I discuss AppLocker since it is free with the certain versions of the Windows Operating System.

Why consider Application Whitelisting?

1. Prevent unauthorized binaries from executing.
2. Prevent unauthorized persistence mechanisms like services.
3. Force your attackers to use different perhaps unfamiliar toolsets.
4. It can increase your visibility (even if not blocking) to new binaries, new executions.
    (See Section below on Sysmon)
5. Monitor execution of arbitrary/unnecessary command/tools.
    http://blog.jpcert.or.jp/.s/2016/01/windows-commands-abused-by-attackers.html
6. Increases noise/tracks generated by attackers. ex -binaries copied around network
7. It really not as hard as you think. Try it on, at a minimum servers and static hosts.


How can attackers circumvent this Defense?

1. PowerShell...PowerShell can load and execute .NET binaries in memory. And so much more...
    http://www.powershellmagazine.com/2014/07/16/investigating-powershell-attacks/
2. Scheduled Tasks and Event Log Triggers.
3. Abuse of .NET utilities. (InstallUtil, RegSvcs, RegAsm)
4. Reflective DLL Injection - Executing Post-Exploitation from memory
5. Office Applications - Macros, executing inside of Excel.exe process for example.
6. Abuse of Native/Trusted Tools - "Living Off The Land", ex -: wmic, netsh, sethc types of attacks.
7. Exploitation - Memory Resisdence/ File-less. ex-  browser exploit, migrate into explorer.


What else can I do?
(This may be out of scope for CCDC, not sure)
1. You need deeper visibility and analytics, consider a free tool like Sysmon
     https://technet.microsoft.com/en-us/sysinternals/sysmon
     http://joshuadlewis.blogspot.com/2014/10/advanced-threat-detection-with-sysmon_74.html
     http://www.darkoperator.com/blog/2014/8/8/sysinternals-sysmon

My guidance:
(Ongoing, expect more updates here)
1. Don't accept the default AppLocker Rules.
2. Avoid Path Rules. These lead to holes that will be quickly discovered.
3. Use Publisher/Cert approvals to get to a hardened state quicker. Example-allow Signed by Microsoft
4. Specifically ban files you know to be suspiciuos or that are not required for administration



.

Closing Thoughts:
One of Application Whitelisting's strength is in preventing initial compromise. It can be useful to resist/constrain lateral movement as well. It will not be a perfect defense.
There is no perfect defense...
Hopefully you will consider deploying this as part of your design. I'm happy to answer specific questions as I have time. You can contact me on Twitter - https://twitter.com/subTee

What did I miss?  Let me know.



References:
AppLocker Overview:
https://technet.microsoft.com/library/hh831440.aspx
AppLocker Configuration:
https://technet.microsoft.com/en-us/library/dd759123.aspx
AppLocker Security Considerations:
https://technet.microsoft.com/en-us/library/ee844118.aspx
AppLocker Step-By-Step Guides:
https://technet.microsoft.com/en-us/library/ee791835(v=ws.10).aspx

Additional Reading:
[PDF] http://www.bitnuts.de/KernelBasedMonitoring.pdf
I've tried to keep a current list here:
https://github.com/subTee/ApplicationWhitelistBypassTechniques


Good Luck Blue Teams!




Cheers,

Casey
@subTee