Consultants are often jacks of all trades, hired by multiple businesses — sometimes simultaneously — to solve problems before moving on to the next engagement. This makes them prime targets for attackers. Gain a toehold on a consultant’s desktop and you can gain access potentially to multiple businesses the consultant works for.
Take a recent attack sequence as an example: A consultant was at home relaxing when his computer indicated there was activity on it. He first thought his cat had walked across the keyboard and then realized it was an attacker who had gained access and was attempting to access various resources.
The consultant disconnected his Wi-Fi connection and began analyzing the situation. The attacker had installed Alpha Agent from an MSI file that was sitting in System32. Then, using WinGet, the attacker updated the version of Splashtop Business already on the computer and installed Splashtop Streamer. This gave the attack remote access to the PC itself. The attacker had used a classic toolset of normal processes and existing applications to not trigger any antivirus or defender protections. Then the attacker installed Atera Agent and a custom version of Screen Connect. The connection came from a virtual machine in a hosted datacenter in the US.
The initial entry point for the attack remains unknown. But the end result is a wakeup call for security professionals to identify better ways to protect key workstations from PowerShell scripts, remote access tools, and other techniques used by attackers. The situation is similar to the attack sequence documented by Microsoft earlier this year as part of the BadPilot campaign.
Following are tips to help you prevent your organization from falling prey to a similar campaign.
Adjust your attack surface reduction rules
Geo-blocking is one security measure admins should employ, but in this instance, it would not have been successful because the attackers were residing in an American datacenter.
You should also review your attack surface reduction rules settings to prevent common attack processes by enabling the following rules:
- Block executable content from email client and webmail
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion
- Block execution of potentially obfuscated scripts
- Block JavaScript or VBScript from launching downloaded executable content
- Block process creations originating from PSExec and WMI commands
Log workstation PowerShell commands
Even without Microsoft Defender resources you need to enable basic detections on your workstations, including those of your consultants. For example, on native Windows workstations ensure you enable logging of PowerShell commands.
Here’s how to do so.
Group policy
If you use traditional Active Directory tools, use group policy to enable PowerShell logging. Open the Group Policy Management Console. Create a new Group Policy Object (GPO) or edit an existing one. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell. Locate the setting “Turn on PowerShell Script Block Logging” and set it to Enabled.
Susan Bradley / CSO
This logging allows you to capture the content of all executed scripts, including commands and functions.
Intune
Similarly in Intune perform the following steps: Go to Microsoft Intune Admin Center and find devices. Click on Windows devices and Configuration. Click Create, select New Policy. Select Windows 10 and later, select Settings Catalog under profile type, and click Create. Enter PowerShell Configuration as name, enter a Description if needed, and click Next. Click Add settings, enter PowerShell in the Search for a setting bar, and click Search. Select Administrative TemplatesWindows ComponentsWindows PowerShell, and click Select all these settings, or go through each one and select those you want to monitor.
Susan Bradley / CSO
Once logging is enabled, look for event 4104 in the event logs. Also set up logging for Module Logging. Both settings will ensure you can monitor for suspicious scripts. You’ll want to review for suspicious commands, obfuscation techniques, such as splitting commands or using escape characters, as well as encoded strings that may hide malicious payloads.
Look for the obvious techniques such as scripts with heavy obfuscation, Base64 encoding, or scripts that download or execute content. Have a central repository of content and method of deployment. You’ll want to be alert for abnormal behavior of scripts in your environment.
In addition, review your logging for evidence of scripts attempting to access LSASS (Local Security Authority Subsystem Service) or invoking tools that will attempt to use or access Mimikatz to harvest credentials.
Build documentation and information for your organization as to what sort of processes inside your network is normal to your processes. Follow up as best as you can with those scripts and processes that are not normal to your organization.
Microsoft Defender for Cloud
Microsoft Defender for Cloud can be specifically enabled to look for activity associated with these types of attacks as well. But be aware that these alerts can provide erroneous information, suggesting you are under attack when you are not. Specifically look for alerts that flag communication with a suspicious domain identified by threat intelligence:
- Suspicious PowerShell Activity Detected
- Detected suspicious combination of HTA and PowerShell
- Detected encoded executable in command line data
- Detected obfuscated command line
Next ensure that you have set up alerts in Microsoft Defender endpoint. Log into the console and in the navigation pane, select Settings > Endpoints > General > Email notifications.
It goes without saying that you need to be aware of what remote access tools are in use in your organization. Review if you need to add hunting commands to search for rogue remote access tools. Consider adding a software restriction policy or applocker to restrict use of such tools to only those approved by your organization.
Attackers want to gain a toehold in your organization and remain silent until you are not looking or monitoring your organization. They will target consultants as well as your staff employees. Consider adding additional monitoring for consultant machines that access your internal resources. Attackers are trying to stay one step ahead of us. It’s up to us to do our best to not make it easy for them to do so.
See also: