This article is part of a series that aims to educate cyber security professionals on the lessons learned by breach victims. Each lesson will include simple recommendations, many of which do not require organizations to purchase any tools.
As noted in the Sophos Active Adversary Playbook 2021, adversaries are turning to tools that are commonly used by IT administrators and security professionals, making it harder to identify suspicious actions. Many of these tools are detected by security products as ‘potentially unwanted applications’ (or PUAs/PUPs/RiskWare/RiskTool) and are needed for everyday use by IT teams. Defenders need to ask two important questions: (1) Do all my users need to be able to use these utilities? (2) Do these utilities need to be able to run on every device?
What is a PUA?
Let’s dig into what is a ‘Potentially Unwanted Application’, and how best to use them safely. The administration tools that are bundled with an operating system, like PowerShell, provide ways to automate and manage devices across a network. There are also additional and third-party tools that are frequently used to extend functionality such as port scanning, packet captures, scripting, monitoring, security tools, compression and archiving, encryption, debugging, penetration testing, network administration, and remote access. Most of these applications run with System or Root level access.
When installed and used internally by your own IT team these applications are useful tools. When installed and used by anyone else, they are considered Potentially Unwanted Applications (PUAs) and are often flagged as such by reputable endpoint security solutions. To enable them to use these tools unhindered, many administrators simply add the ones they use to a Global Exclusion or Allow List in their endpoint security configuration. Unfortunately, this method of exclusion also allows the installation and use of the tools by unauthorized persons, often without any type of monitoring, alerts or notifications.
Some of the most common PUAs found and used by adversaries include:
- PSExec – “…a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PSExec’s most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.”
- PSKill – can “kill processes on remote systems. You don’t even have to install a client on the target computer to use PSKill to terminate a remote process.”
- Process Hacker – a resource monitoring tool, that is often used to terminate security and logging software.
- Anydesk/TeamViewer/RDPWrap – or any tool designed for remote access, especially over the internet, can be used by a threat actor.
- GMER – built as an anti-rootkit tool, threat actors leverage its capabilities to ‘unhook’ security process.
- 7Zip/GZip/WinRar – Compression tools are used by adversaries to combine, shrink and exfiltrate your data – usually for extortion.
- Nirsoft tools – a collection of tools for password recovery, software uninstallation, and the ability run command-line tools without displaying a user interface.
- IOBit – has powerful uninstallation capabilities and is often used to remove security software.
- ProcDump – a debugging tool that can dump memory to disk, allowing a threat actor to expose in-memory data, such as credentials.
Threat actor usage of PUAs
Configuring security policy to allow PUAs needs to be handled carefully. Excluding anything will expose the tools to your IT administrators and threat actors alike, and you’ll have no visibility into the use of the tool, or the intent or context.
If a tool has been excluded a threat actor can still attempt to install and use it even if it’s not already installed on a particular device. The set of adversarial techniques known as “living off the land” involve threat actors using pre-existing features and tools to avoid detection for as long as possible. They allow threat actors to carry out discovery, credential access, privilege escalation, defense evasion, persistence, lateral movement, collection and exfiltration without a single red flag being raised.
By the time the adversary is ready to deploy the last stage of the attack – impact (for example, the ransomware payload) – it is too late; your security tools have already been disabled (by PSKill or IOBit?), a high level of credential access has been obtained (by GMER or ProcDump?), your data has already been transferred to the dark web (in 7Zip files?) and the malware pre-positioned on key systems (or worse, domain-level file shares like SYSVOL or NETLOGON) ready for execution (by PSExec?). The more PUAs the attackers can find, the greater the attack surface they have to work with.
Allowing PUAs in your organization
The first step is to review your current global exclusions. Do they need to be there? Is there a reason cited for the exclusion – or has it just ‘always been there’? Conduct some research in to why the security product detected the PUA in the first place – could be it be used maliciously? Do the exclusions really need to apply to ALL servers and end user devices? Is the admin tool still required, or can we use a built-in function? Do you need more than one tool to achieve the same outcome?
Our recommendation is to allow PUAs on a very controlled basis – specific application, specific machines, specific times, and specific users. This can be achieved via a policy with the required exclusion, which is applied and then removed as needed. Any detected usage of PUAs which is not expected should be investigated as it may indicate that a threat actor has access to your environment.
Who needs to use these tools, and when? It is almost like asking: “Who needs a USB stick for their work?”. But do keep asking those questions!