惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

A
About on SuperTechFans
博客园 - 聂微东
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 司徒正美
宝玉的分享
宝玉的分享
美团技术团队
量子位
The Cloudflare Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
IT之家
IT之家
爱范儿
爱范儿
J
Java Code Geeks
博客园 - Franky
Last Week in AI
Last Week in AI
B
Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
I
InfoQ
GbyAI
GbyAI
Recent Announcements
Recent Announcements
小众软件
小众软件
H
Help Net Security
Microsoft Azure Blog
Microsoft Azure Blog
MyScale Blog
MyScale Blog

Black Hills Information Security, Inc.

Bad Habits: An ANTISOC Operation Same Problem, Different Angles: When Red Team and Blue Team Actually Talk to Each Other How to Identify and Exploit New Vulnerabilities Swapper – A Pure Regex Match/Replace Burp Extension A Practical Guide to BloodHound Data Collection Network Engineering Basics Signed, Trusted, and Abused: Proxy Execution via WebView2 Getting Started In Pentesting – Advice From The BHIS Pentest Lead Cloud Security: Tips and Resources for Securing the Cloud Lessons From A Chatbot Incident How to Lead Effective Tabletops Understanding GRC: How to Navigate Risks and Compliance Standards The “P” in PAM is for Persistence: Linux Persistence Technique Malware Analysis: How to Analyze and Understand Malware OSINT: How to Find, Use, and Control Open-Source Intelligence What to Do with Your First Home Lab When the SOC Goes to Deadwood: A Night to Remember Social Engineering and Microsoft SSPR: The Road to Pwnage is Paved with Good Intentions Common Cyber Threats Finding the Right Penetration Testing Company Deceptive-Auditing: An Active Directory Honeypots Tool The Curious Case of the Comburglar How to Set Smart Goals (That Actually Work For You) Inside the BHIS SOC: A Conversation with Hayden Covington Abusing Delegation with Impacket (Part 3): Resource-Based Constrained Delegation Why You Got Hacked – 2025 Super Edition Abusing Delegation with Impacket (Part 2): Constrained Delegation Abusing Delegation with Impacket (Part 1): Unconstrained Delegation GoSpoof – Turning Attacks into Intel Model Context Protocol (MCP)
Commonly Abused Administrative Utilities: A Hidden Risk t...
BHIS · 2025-08-27 · via Black Hills Information Security, Inc.

Dale spent over 20 years working as an enterprise defender before joining Black Hills Information Security as a penetration tester in 2020.

When we look at an organization’s defensive strategy, we often see a common theme — unauthorized or excessive access to commonly abused administrative utilities.  

Organizations tend to focus a significant amount of their efforts on external threats, such as phishing and ransomware, but they often overlook one of the most dangerous attack vectors on their internal networks. 

Many built-in tools are essential for IT operations and troubleshooting, so naturally, permissions have to be granted in order for the right people to use them. But when those permissions aren’t groomed or are left to their default settings, they become exposed and unmanaged liabilities that are easily weaponized by an attacker who gains a foothold on a system in your environment. Attackers today spend less time relying on custom malware and exploits, and more time abusing these trusted administrative utilities that are built into the operating system to execute their attacks. This is especially true on Windows-based systems. As a defender, it’s crucial that you understand how these utilities can be used against you and the risks associated with improper management of them. 

What Are Administrative Utilities? 

Simply put, administrative utilities are tools that are built into the operating system. Their intended purpose is to enable a system administrator to perform tasks related to system configuration, automation, or remote management of a system.  

You’ll notice that I said, “intended purpose”! These utilities are trusted components of the operating system, and they’re essential for legitimate system administration. That (unfortunately) means that they’re rarely flagged by antivirus software or endpoint detection solutions. This allows their usage to blend in with normal day-to-day system activity and makes them a prime target for abuse by attackers trying to perform reconnaissance, execute malicious code, move laterally across systems, and establish persistence without relying on traditional malware. 

Now that we’ve touched on what administrative utilities are, let’s look at some of the most used (and often mis-managed) utilities on a Microsoft Windows based system. 

First up is PowerShell, a built-in command-line shell and scripting language that is used primarily by system admins to perform tasks like automation or configuration management. Because it provides such deep access to the internals of the Windows operating system, PowerShell is extremely useful for legitimate tasks. But beware: the same capabilities that make PowerShell valuable to an admin also make it a prime target for abuse by an attacker.  

PowerShell ISE is a GUI for PowerShell that offers some extra features that you don’t get with basic PowerShell. Multiline editing is one example.  

The Windows command prompt (cmd.exe) is a legacy shell used to run batch scripts and system commands. Although it’s largely been replaced by PowerShell, it’s deeply integrated into every current version of Microsoft Windows and remains a common utility for executing system-level tasks. Much like PowerShell, its capabilities can be exploited by attackers during various phases of an attack. 

Windows Management Instrumentation (WMI) is a framework that allows an admin to query and modify system settings, manage services, and gather information about various system components. It also enables remote management capabilities, making it a frequent target for lateral movement by attackers. Because of its stealth, power, and versatility, WMI is a commonly abused tool, enabling nearly invisible system interaction and lateral movement without dropping any new files to disk. 

Remote Desktop Protocol (RDP) is a communication protocol that allows users to connect to, and control, a Windows computer remotely via a graphical interface. It’s commonly used by system admins, help desk staff, and remote workers to access servers or workstations from another location. It also poses a serious security risk if misconfigured or exposed to the internet because it offers direct, interactive access to a system, making it highly appealing to an attacker.  

In addition to these commonly known tools, there are some lesser-known binaries that are frequently abused by attackers because of due to their ability to execute code or load external content: 

  • mshta.exe – Executes HTML applications (HTA files) and can be used to run scripts from remote sources. 
  • regsvr32.exe – Used to register DLLs and execute code from specially crafted scripts or remote COM objects. 
  • cscript.exe and wscript.exe – Windows Script Host executables for running VBScript and JScript files. 
  • installutil.exe, msbuild.exe, regasm.exe – .NET utilities that can execute code during installation or build processes, often bypassing traditional defenses. 

While each of these tools is essential for legitimate system administration, one of the key reasons they’re so appealing is that they allow an attacker to “live off the land.” Since they’re Microsoft-signed and widely used for legitimate purposes, their activity often goes unnoticed or is mistaken for legitimate behavior. Even in environments with strict application controls, they’re often allowlisted by default, giving attackers a way to slip through your defenses. 

Common Abuse Scenarios 

Tools like PowerShell and WMI are often abused by an attacker during the recon phase of an attack to enumerate users, local and domain groups, organizational units, network shares, and domain trust relationships without triggering alerts. Since this activity often mimics normal administrative behavior, it typically goes unnoticed, especially in environments that lack proper logging or behavioral analysis. 

Once an attacker has established a foothold on a system, they’ll almost always attempt to move laterally across the environment with the goal of gaining access to more valuable assets, searching for systems with elevated privileges or sensitive data. This is how they gradually escalate their level of access within the environment. By leveraging stolen or guessed credentials, they can use RDP to log into remote systems and interact with them by impersonating legitimate users. This can be difficult to detect because it so closely resembles normal user behavior.  

In addition to recon and lateral movement, an attacker will almost always attempt to maintain persistence to ensure they can regain access to the environment if their initial point of access is discovered and removed. This is where utilities like msbuild.exe and installutil.exe come into play: They can be used to execute malicious payloads or install backdoors without writing conventional malware to disk. To add insult to injury, these utilities are signed by Microsoft and are often used in development and deployment workflows, which means they’re rarely blocked and are routinely overlooked by security tools. 

Even lesser-known binaries such as regsvr32.exe can be weaponized. For example, regsvr32.exe can be used to register DLLs or execute code from malicious script files. This can potentially enable command-and-control (C2) communication and authorize an attacker to maintain persistence to a compromised system or even exfiltrate sensitive data. This frequently flies under the radar because the utilities involved are, as a matter of course, assumed to be safe and necessary for normal system operation. 

Security Implications & Strategy 

If you’re starting to panic, step back and take a deep breath! There are several things you can do to limit an attacker’s ability to misuse these tools.  

First and foremost is proactively restricting access to these tools. In doing so, you significantly reduce the options available to an attacker when they do compromise a system. Generally speaking, blocking access for your unprivileged users poses no risk because they typically don’t need to use them in the first place. Afterall, they are administrative tools and last time I checked, an unprivileged user does not perform administrative tasks. That said, before outright blocking them, it’s best to test any restrictions before applying them to your users to avoid disruptions and to identify any legitimate use cases that may require an exception. 

There are also several ways to restrict access to these tools. If you’re a smaller shop with very little budget, then you may want to look into Microsoft AppLocker or Windows Defender Application Control. Both are free tools built into Windows 10, 11, and Server 2026. Alternatively, you can use Group Policy to prevent unprivileged users from running these tools. If you have a larger budget, several commercial products out there are highly effective.  

While these tools can be used to connect to other systems, a host-based firewall will allow you to limit which systems they can connect to, and if there’s no legitimate business need to connect to other systems, you can block them outright. At a minimum, you’ll want to consider blocking their ability to initiate connections to other systems that aren’t explicitly required for their day-to-day activities to prevent data exfiltration and command-and-control attempts. Just like restricting access to the tools, make sure you thoroughly test any network restrictions you put in place to minimize disruptions to any legitimate processes. This requires that you know what all your processes are in the first place, but that’s a topic for a different day. 

I once heard someone say, “Prevention is ideal but detection is a must!”. This is absolutely true, and any strategy worth its salt includes solid monitoring and logging capabilities. It’s great that you are preventing or restricting the tools from running, but it’s imperative that you also log and alert on any attempts to use them! Not only will this tell you if you’ve overlooked a legitimate use case, but it’ll also alert you if your users are up to no good—or worse, if an attacker’s in your network. At a minimum you’ll want to enable PowerShell logging, which includes ScriptBlock, Module and Transcription logging. This can be done using Group Policy, and if you’re fortunate enough to have a SIEM (Security Information and Event Management), you can collect, analyze, and alert on any activity related to these tools.  

Final Thoughts 

Any tool that can be used for good can also be used for evil, and these built-in administrative tools are no exception. While they’re necessary for day-to-day operations, they also pose a significant threat if left open to misuse. Effectively managing them requires a delicate balance between functionality and security by locking down what’s unnecessary and closely monitoring whatever remains. Just because you’re a small team with a small budget doesn’t mean you don’t have options. There are many free or relatively cheap options that even the smallest organizations can take advantage of to limit or altogether prevent access to these often overlooked tools.  

At the end of the day, it’s probably not going to be some fancy malware or cutting-edge exploit that takes down your network. More than likely, it’ll be the everyday tools that already exist in your environment that were not properly managed and are begging to be misused. Think of it like locking your front door but leaving the windows wide open. If you’re not properly managing these powerful built-in utilities, you’re giving attackers an easy way in. So before chasing after the next big threat, make sure your own tools and access points aren’t leaving you open to intruders.