Fraud Management & Cybercrime , Next-Generation Technologies & Secure Development

Locking Down PowerShell to Foil Attackers: 3 Essentials

Microsoft Taps Machine Learning to Better Combat Fileless Malware
Locking Down PowerShell to Foil Attackers: 3 Essentials
IT managers love PowerShell, pictured, a task-based command-line shell and scripting language. Unfortunately, so do hackers. (Source: Microsoft)

Microsoft's PowerShell scripting language, which debuted in 2006, has proved to be extremely popular with IT administrators for managing machines. But a dozen years after its birth, hackers are increasingly embracing it too.

See Also: Unified SASE: The Third Era of Network Security

The powerful, open source scripting language has proved to be the perfect lateral movement tool for attackers once they have compromised a network. And PowerShell scripts may run only in memory, giving rise to the term "fileless" malware.

Malicious PowerShell scripts can be difficult to detect and harder to investigate because they may leave few digital forensic traces. Further, because PowerShell is a legitimate tool, the challenge for network defenders is clear: How do you stop bad people from using a good tool?

The focus on malicious PowerShell scripts increased about two years ago, says Zaid Arafeh, senior program manager for the Windows Defender Research team. That's when fileless malware, such as PowerWare and PowerSniff, emerged, he says.

To deploy the malware, attackers still needed to compromise a machine first, either through credential theft or exploits. But PowerShell makes it faster and easier to move around once they gain access.

"PowerShell is so powerful and versatile in the sense that it has access to the .NET framework; it has access to WMI; it has access to virtually any part of the machine they desire," Arafeh says, referring to Windows Management Instrumentation, the infrastructure for management data and operations on Windows-based operating systems. "They can script the whole attack."

In response, Microsoft has been working on a variety of security technologies that help administrators halt PowerShell abuse. The aim is to reduce the ability of attackers to "live off the land," or bend legitimate tools to malicious aims.

Numerous resources are available offering tips on how to better secure PowerShell, such as a guide from the Australian Signals Directorate.

"PowerShell is so powerful and versatile in the sense that it has access to the .NET framework; it has access to WMI; it has access to virtually any part of the machine they desire."
—Zaid Arafeh, Microsoft

Following are three good tips to keep in mind, as well as a description of how Microsoft is looking to machine learning to better detect malicious scripts.

Constrained Language Mode

PowerShell is a loquacious tool: It can do a lot of things, not all of which probably need to be enabled on every machine on which it's installed.

But admins can set PowerShell's constrained language feature, which cuts off potentially dangerous actions, such as calling on arbitrary Windows APIs. But that doesn't stop attackers from simply launching another instance of PowerShell with the full language capabilities.

Microsoft's solution is for the constrained language mode to be used with application control software, such as Device Guard User Mode Code Integrity. That way, when PowerShell detects a UMCI policy, it will stay in constrained language mode.

"These lockdown policies are important for high-value systems that need to be protected against malicious administrators or compromised administrator credentials, according to a Microsoft blog post from November. "With a policy enforced, even administrators are limited to what they can do on the system."

Deep Logging

Over the years, Microsoft has steadily improved the logging capabilities around PowerShell. One of these improvements is called deep script block logging.

The feature will record all block scripts that PowerShell processes, including those that employ dynamic code generation, which may be an attempt to evade detection.

By default, PowerShell records script blocks the first time one is used, but it can be set to record every time even the same one runs. That can lead to a voluminous record of events, so you've been forewarned. But the logs later could provide some scope around what attackers were trying to do.

"Most companies only realize the need to enable script block logging after it is too late," Microsoft says. "To provide some recourse in this situation, PowerShell automatically logs script blocks when they have content often used by malicious scripts. This automatic script block logging is not intended to replace antivirus or full script block logging - it only serves as a record of last resort."

Anti-Malware Scanning Interface

In Windows 10, Microsoft added a security feature called the Anti-Malware Scanning Interface, or AMSI, which is intended to help unwind and analyze obfuscated or encrypted scripts.

Scrambling scripts is one way that attackers hope their code won't get caught. But at the end of the line, obfuscated scripts have to be untangled to run in the script engine.

Applications can call on the AMSI API to check the deobfuscated PowerShell script. Many anti-virus vendors now also leverage AMSI, and Microsoft uses it in several products, including Windows Defender AV and Windows Defender EDR, it's post-exploitation security tool for exploring attacks that weren't initially caught.

"As long as the anti-malware can use AMSI to look at the content of the script, then you have the ability to learn about what the script is doing and to block any malicious behavior," Arafeh says.

Looking Ahead: Machine Learning

Microsoft is already using machine learning for detecting fileless attacks but will have new features in the next version of Windows, Arafeh says. Many of the machine learning models now deal with portable executables, and in the future they'll also deal with other types of code.

"We do have a very solid road map for what ML [machine learning] will be capable of doing in the next release of Windows and the types of files it can ingest," Arafeh says.

The company is making significant investments in the endpoint protection platform stack for Windows Defender around machine learning as well as content and behavior scanning, says Tanmay Ganacharya, principal group manager for the Windows Defender research team.

Last fall, Microsoft upgraded Windows Defender and Windows Defender ATP with new machine learning algorithms that enable those applications to take feeds from AMSI and better classify whether something is malicious.

Microsoft published a postmortem last week on how it stopped an Emotet outbreak earlier this month through what it terms layered machine learning. Windows Defender AV employs machine learning models right on the client, which stopped the attack.

A diagram of Microsoft's layered protection model that incorporates machine learning. (Source: Microsoft)

But to gather further information, a client can also call on Microsoft's cloud analysis, which uses 30 machine learning models to detect malicious activity. The company's back end then figured out what family of malware had attacked the machines. The process takes from a few milliseconds on the client to a few minutes if the company's full cloud analysis suite is called on, Ganacharya says.

"I believe we have industry's best scale in terms of now many calls to the cloud that we are able to answer," Ganacharya says. "We are doing I believe 3 to 4 billion calls a day every day."


About the Author

Jeremy Kirk

Jeremy Kirk

Executive Editor, Security and Technology, ISMG

Kirk was executive editor for security and technology for Information Security Media Group. Reporting from Sydney, Australia, he created "The Ransomware Files" podcast, which tells the harrowing stories of IT pros who have fought back against ransomware.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.asia, you agree to our use of cookies.