AI-augmented tradecraft is changing the threat landscape that defenders have operated in.
For years, defenders have relied on identifying the signatures and behaviors of off-the-shelf offensive tooling, like BloodHound, PowerSploit, or Cobalt Strike. But a new trend is emerging—"vibe coded" malware—and this is shifting how the attacker and detection landscapes operate.
Vibe coding is the process of writing software not by manually typing syntax but by iteratively prompting AI with natural language until the output matches the desired function. It has equipped mediocre threat actors with the ability to generate bespoke, single-use scripts.
We recently got a first-hand look at this when we recovered a PowerShell script used by a threat actor as part of an incident on June 3. A deep dive into its contents reveals a fascinating case study of how cybercriminals are weaponising AI to map Active Directory (AD) environments.
In this blog, we offer a breakdown of the script, why it is undeniably AI-generated, and what this means for the future of threat detection.
The attack chain with an AI-assisted twist
One thing to emphasize here is that AI isn't changing the game by any means during this incident. The underlying attack chain still resembles the tried-and-tested smash-and-grab playbook we've seen for years. This core methodology has remained consistent, but it is now being selectively augmented by AI. This hybrid approach prioritises aggression and speed over stealth, allowing threat actors to execute highly damaging campaigns faster than ever.
The RDP Pivot: The attack kicked off when the threat actor established RDP access (context suggested initial access via the VPN) onto a domain-joined Windows Server with a set of pre-compromised credentials.
The Tool Staging: Operating via interactive command prompts, the attacker staged their operations and toolsets in (C:\ProgramData\), which is a nefariously common staging area.
The Vibe-Coded Recon: Within minutes of establishing the RDP session, the attacker dropped and executed their bespoke, AI-generated payload (C:\ProgramData\Untitled1.ps1). This was their opening move, to map the Active Directory environment.
The Smash-and-Grab: Roughly half an hour later, they deployed C:\ProgramData\s5cmd.exe. s5cmd is a legitimate, high-speed command-line tool for Amazon S3 operations, which we have seen being abused frequently for data exfiltration.
The Second Bite: After securing the initial payload from the compromised server, the attacker went back to the well. They deployed SharpShares.exe, a known enumeration tool, deliberately filtering out common administrative shares to hunt for further user-accessible data repositories.
While investigating the incident, we identified and fully recreated Untitled1.ps1 using Huntress SIEM telemetry—Event ID 4104 in the Microsoft-Windows-PowerShell/Operational, which contains blocks of PowerShell scripts that have been deployed.
Here's what we found (and for those who would like to follow along themselves, you can find the full script at:
Anatomy of the AI-Generated recon tool
The script, enthusiastically titled "100% Working AD Information Gathering Script - FULLY FIXED", is a highly aggressive, noisy, custom-built AD enumeration tool. It doesn't try to hide its functions, and has a number of distinct and interesting phases.
The "try everything" discovery phase
The script begins by attempting to identify the domain and the primary Domain Controller. Rather than using a single, robust method, the script utilizes an over-engineered, five-step cascading fallback mechanism. It tries DNS, nltest, the AD module, and environment variables before finally hitting a hardcoded fallback.
Figure 1: Script extract of over-engineered Domain Controller identification
Repetitive data collection
Once the DC is located, the script initiates a massive data collection routine. It uses heavily structured, repetitive try/catch blocks to systematically dump AD Users, Computers, Groups, OUs, and Trusts into a newly created staging directory.
There is an aesthetic focus to this script, highlighting text in the command line to the operator (more on this later).
Figure 2: Script extract of enumeration collection and saved output in CSV
Polished exfiltration prep
The final phase of the script is surprisingly focused on presentation. Instead of simply zipping the CSV files and exiting, it writes an entire HTML file to summarise the data theft.
Why does a threat actor need a beautiful HTML report, you ask? We thought the same. It's likely a "helpful" inject from the LLM that the attacker simply went along with, rather than being intentionally authored into the script.
Figure 3: Script extract of HTML report creation
Figure 4: Example of resulting HTML report
Throughout the script, the following are created:
Creates directory C:\AD_Reports_<datetime>
Creates the following files: AD_Users.csv, AD_Computers.csv, AD_Groups.csv, AD_OUs.csv, AD_Subnets.csv, AD_Trusts.csv, AD_Users_With_Email.csv, AD_Simple_Users.csv, DNS_Subnets.txt
It creates a AD_Report.html, which shows how successful enum was
Zips the entire folder up into C:\AD_Reports_<datetime>.zip
Figure 5: Attacker script deployed in lab
The smoking guns: Evidence of AI generation
The internal structure contains several distinct hallmarks of LLM generation:
The "prompt iteration" title
Figure 6: Extract of Script title
This is a classic artifact of prompt engineering. It strongly implies the attacker had a back-and-forth conversation with an LLM, encountering errors, pasting the errors back into the chat, and finally copying out the "fully fixed" version.
The literal placeholder
The most glaring piece of evidence is found in the DC discovery fallback block:
Figure 7: Extract of unedited template boilerplate
This is a literal LLM placeholder. The AI generated the script based on a specific prompt, including an example server name, and the attacker blindly copy-pasted the code without updating the variable.
Over-engineering and boilerplate
The five distinct methods to find a Domain Controller scream "AI generation". A human writing this script would typically pick the best one or two methods. An LLM, when told "make sure it doesn't fail to find the DC," will exhaustively generate every method in its training data.
Aesthetic focus
LLMs love to make console output look pretty (same to be fair, but I'm not AI). The excessive use of cyan, green, red, and yellow Write-Host outputs (as seen in the Snippets above) is a common trait of an AI trying to be "helpful" to the prompter.
Detection implications in a vibe-coded world
The transition from off-the-shelf frameworks to customized, home-made AI tooling represents a significant challenge for blue teams.
Historically, AVs and EDR platforms have relied heavily on file hashes and static string signatures. If an attacker drops SharpHound, security tools instantly recognize the binary. However, vibe-coded scripts are inherently unique. Untitled1.ps1 has never existed before and will likely never be compiled in this exact configuration again.
Defenders must shift their focus to the fundamental behaviors of the attack lifecycle. AI can change the code syntax, but it cannot easily change the underlying mechanics of Active Directory enumeration.
Fortunately, Huntress' SIEM has the visibility to catch evolving AI-tradecraft. While AI can easily generate new scripts to defeat legacy hash-matching heuristics, it cannot hide the operational footprint required to actually interact with the operating system.
Figure 8: Extract of Huntress SIEM identifying the tradecraft deployed
Conclusion
Vibe coding lowers the barrier to entry for cybercrime, allowing unsophisticated actors to generate highly capable, evasive tooling on the fly. While the code itself may be messy, over-engineered, and filled with AI hallmarks like left-behind comments, the threat it poses is very real. To combat this, defenders must abandon rigid, signature-based thinking and embrace behavioral analytics to catch the underlying actions that no LLM can hide.
