Welcome back, aspiring investigators!
The longer we stay in an environment that feels stable, the easier it becomes to assume that it is also safe. Over time, comfort turns into routine, and routine slowly erodes caution. Many organizations fall into the trap of believing that serious cyberattacks only happen to other large enterprises, careless companies, or targets that are somehow “more interesting.” Unfortunately, reality does not work that way. Cyberattacks are not rare disasters. They are growing and increasingly automated.
To put this into perspective, during 2025 global cyberattack activity reached staggering levels. Estimates ranged from roughly 2,200 to more than 4,000 attacks per day worldwide. That means, on average, an attack occurred every 39 seconds. Organizations faced over 2,000 attacks per week, driven by a sharp rise in ransomware operations, AI-assisted phishing campaigns that increased by more than 1,200 percent in some cases, large-scale DDoS attacks, and supply-chain compromises. The economic impact was equally dramatic, with global cybercrime costs estimated at around 10.5 trillion dollars for the year. And this trend is not slowing down. As new attack vectors appear and artificial intelligence becomes a force multiplier for attackers, every stage of the kill chain becomes faster and more efficient. This means defenders must adapt just as quickly. The larger an organization becomes, the higher the probability that someone will eventually find a weak configuration or a small vulnerability that can be chained into a full domain compromise.
To actually do something about this threat landscape, let’s look at two PowerShell tools that can give you a lot more visibility into your security setup. The first is a workstation security audit script, and the second is an Active Directory ACL scanner. Both target areas that teams often miss.
Audit
Repository: https://github.com/mr-r3b00t/windows_audit
This audit script was published recently by @UK_Daniel_Card, and its primary goal is to provide a comprehensive view of a workstation’s security posture in a clean, readable HTML report. Rather than focusing on a single control or setting, the script evaluates the system across multiple dimensions, including password security, network protocols, patch levels, exploit protection, and many other areas.
One of the strongest aspects of this report is how the findings are organized. Under each category, issues are presented in a hierarchical manner based on their criticality. High-impact findings are clearly marked, while lower-severity issues are still documented with practical recommendations. When no problems are detected in a specific area, the report provides informational messages confirming that the configuration is acceptable.
For example, the report may highlight a critical issue such as an account without password expiration or an excessive number of local administrators. In many environments, three local administrators is considered a reasonable baseline. Anything beyond that deserves closer attention. At the same time, the report also points out low-level issues that can significantly improve security over time.
A good example is the recommendation to deploy Sysmon for enhanced logging. Sysmon, or System Monitor, is a Windows system service and driver developed by Microsoft that provides detailed visibility into process creation, network connections, file creation, and other low-level activities. In security operations, Sysmon is commonly used to enrich endpoint telemetry and feed high-quality data into a SIEM. While it does not replace antivirus or EDR solutions, it significantly improves detection capabilities when combined with proper logging and alerting rules.
Default Windows configurations are not designed with maximum security in mind. They are meant to balance usability and performance. The audit script shows optional Windows features that can introduce significant risk if left enabled. One common example is PowerShell version 2, which lacks modern security features such as script block logging. In the PowerShell for Hackers series, we discussed how attackers intentionally downgrade to PowerShell v2 to bypass logging and evade detection. If your detection pipeline does not explicitly look for downgrade attacks, malicious activity can fly under the radar.
At the very beginning of the report, the script provides a high-level overview summarizing the system’s overall security health. This quick snapshot helps responders and administrators immediately understand whether they are dealing with minor hygiene issues or system weaknesses. In our test environment, the results clearly showed that the system was far from perfect. This is far more common than most organizations would like to admit.
Scan
Using the audit script is straightforward. The script can be downloaded directly from GitHub and executed locally. Upon execution, it prompts you with a simple question asking whether you want to obfuscate sensitive details such as MAC addresses, usernames, and hostnames in the report. In most internal environments, obfuscation is not necessary.
PS > .\audit.ps1
Once started, the script begins auditing the system automatically. Depending on the configuration and system performance, this may take some time. If you plan to deploy this script across an entire domain using Group Policy, it is recommended to adjust it to fit your environment. In a well-designed setup, the script would execute via GPO and write its output to a central file share for later analysis. Each report includes the hostname, making navigation and correlation simple.
When the audit completes, you receive the report filename along with a short summary. Take the time to analyze the findings carefully and treat them as a roadmap for improving your security baseline.
AD ACL Scanner
Repository: https://github.com/canix1/ADACLScanner
While endpoint security issues are often visible, DACL abuse in Active Directory is another dangerous problem that many incident responders miss entirely. A DACL, or Discretionary Access Control List, defines who is allowed or denied access to an object in Active Directory and what actions they can perform. DACL abuse occurs when attackers manipulate these permissions to grant themselves persistent and often invisible control.
Detecting DACL abuse is difficult unless you are closely monitoring changes to high-value AD objects. However, monitoring everything is unrealistic. Excessive alerts overwhelm SIEM platforms and exhaust SOC teams, increasing the likelihood that true positives are ignored. Attackers understand this very well. That is why many of them aim to persist at the DACL level. If they control permissions, they control recovery.
You might discover a compromised workstation, isolate it, and reset all credentials. On the surface, the incident appears contained. But if the attacker granted themselves GenericAll rights over key AD objects, they can undo your remediation steps using what looks like a normal domain computer account or even a deactivated user object.
AdminSDHolder
We have covered AdminSDHolder in offensive security articles such as the Sliver series, but here we must look at it from a defensive perspective. Every Active Directory environment contains the AdminSDHolder object. Its purpose is to protect privileged accounts and groups by enforcing a consistent security descriptor. Periodically, the SDProp process applies this descriptor to protected objects.
Hackers like AdminSDHolder because gaining GenericAll permissions over it effectively grants long-term control over privileged accounts. Abuse often happens using tools such as BloodyAD, which make modifying permissions easy once sufficient access is obtained.
Attackers prefer persistence that does not depend on active users. User accounts can have their passwords changed, making them unreliable persistence mechanisms. Instead, attackers often rely on deactivated users or domain computer objects. By default, every domain user has a Machine Account Quota (MAQ) of 10, meaning they can create up to 10 computer objects in Active Directory. This feature exists to simplify legitimate workstation joins, but it also enables multiple attack paths. Reducing MAQ to zero removes a large number of Active Directory attack vectors. Attacks such as resource-based constrained delegation abuse, shadow credentials, and certain persistence techniques rely directly on the ability to create computer objects.
The good news is that the ACL scanner script can identify these critical misconfigurations and compare them either against a trusted baseline or default Windows Server configurations.
Scan
The script supports both GUI and CLI usage. In this article, we focus on the GUI. After downloading and executing the script, a new window appears.
PS > Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/canix1/ADACLScanner/refs/heads/master/ADACLScan.ps1' -OutFile ADACLScan.ps1
PS > .\ADACLScan.ps1
At first glance, the interface may look intimidating due to the number of available options. Selecting the options you see above is sufficient to perform a scan. You may notice both DACL and SACL scan types. DACLs define permissions (who can do what), while SACLs define auditing rules, specifying which access attempts should be logged in the Windows Event Log, regardless of success or failure.
The first step is connecting to your domain. If you are running the script as a domain user, no additional credentials are required. Use List Domains on the left-hand side to select the correct domain, which is helpful in environments with multiple trusts. Once connected, expand the node and select the desired objects. In the Assessments tab, enable coloring to make navigating the report easier.
Click Run Scan to start the analysis. When the scan completes, the results open in an HTML report.
In our case, the report immediately flags a critical situation. Scrolling down reveals that the user lowpriv has Full Control over AdminSDHolder.
The same user also has full control over the Administrators group.
This account appears completely benign during manual inspection. It is not a member of any privileged group, yet it controls all of them. This is why it’s important to monitor DACLs.
Comparison
Once you establish a trusted DACL or SACL baseline, you can regularly compare the current state of Active Directory against it. This allows you to detect changes early.
If needed, you can also compare things against default configurations.
Summary
Security audits and ACL scans are foundational elements of a mature security program. Endpoint misconfigurations and hidden permission abuses often coexist, reinforcing each other in ways that are easy to miss. By routinely auditing systems, establishing trusted baselines, and understanding how attackers persist beyond credentials, defenders can move from reactive cleanup to proactive control.
We are also preparing dedicated PowerShell training that will be valuable for both defenders and red teamers. This training will focus on practical, real-world PowerShell usage in both offensive and defensive security operations and will be available to Subscriber and Subscriber Pro students from March 10-12.
Source: HackersArise
Source Link: https://hackers-arise.com/powershell-for-dfir-part-3-audits-and-acl-security/