PowerShell: Great Ransomware Tool or Greatest Ransomware Tool?
Part 1 of a 3 Part Series
It is almost impossible to talk about ransomware attacks without talking about PowerShell. The use of PowerShell is ubiquitous in ransomware campaigns at almost all phases of attack from initial access, to network scanning, to data theft and even encryption.
This is the first of a 3 part series. In this post I am going to go over how IABs and Ransomware operators use PowerShell during attacks. The next post will cover how to limit access to PowerShell in your network and the 3rd post will cover how to threat hunt for malicious PowerShell usage.
The use of PowerShell starts with initial access. For example, Palo Alto’s Unit 42 documented IcedID’s use of PowerShell during the installation phase. After a victim downloads the trojanized malware it executes a PowerShell script to download the IcedID loader.
The Ukraine Cert documents the use of PowerShell during the installation of SmokeLoader. The installation includes a JavaScript file that uses a PowerShell script to download the malicious executable.
On the ransomware operator side, CISA reports that the BianLian ransomware group uses PowerShell to disable security tools using the following code:
[Ref].Assembly.GetType(‘System.Management .Automation.AmsiUtils’).GetField(‘amsiInitFaile d’,’NonPublic,* Static’).SetValue($null,$true)Unit 42 also documents how Vice Society used a PowerShell script to automate the process of exfiltrating files from victim networks.
LockBit has also used PowerShell to distribute and execute their ransomware payload. The team at Packt does a nice job of documenting those LockBit scripts.
While these examples are specific to these ransomware groups, the reality is that many different groups use PowerShell to carry out the same tasks and more. Securing PowerShell in your network and hunting for malicious used of PowerShell can go a long way to protect you from ransomware attacks. I’ll talk more about how to do that in the next two posts.