Purple Teaming as a Continuous Improvement Model
In cybersecurity, the gap between what we think we can detect and what we actually detect is often wider than we expect. Tools are configured, rules are written, playbooks are drafted, and yet, when a real attack unfolds, the telemetry is incomplete, the alerts are noisy, and the response is slower than it should be.
Purple teaming exists precisely to close that gap continuously, as an operational method embedded into the security program.
This article walks through how we approach purple teaming at Würth IT Italy’s SOC as a concrete reference point.
The Engagement: Enumeration and Scanning
A recent engagement focused on enumeration and scanning techniques against Windows systems and Active Directory environments. The objective was to validate detection rules developed by the SOC in response to techniques observed in real-world customer engagements, reproduced by the Red Team.
The simulation was carried out using a custom PowerShell tool capable of several operation modes: host discovery via ping sweep, port scanning, SMB share testing, and password spraying via both LDAP and RPC. The tool was designed to mimic attacker behavior, including obfuscation techniques.
Obfuscation as a Detection Bypass
Why PowerShell? We needed a repeatable, scriptable tool that could run natively in each Windows environment and be interpreted rather than compiled, in order to avoid being flagged by security or AV measures through detection fingerprinting.
The tool also used PowerShell wildcard glob patterns (called LolGlobs) to obscure cmdlet names from static analysis. Commands like Test-Connection and Invoke-Expression were referenced indirectly via patterns such as T*-C*n and I*ke-E*. This is a realistic evasion technique that bypasses signature-based detection.
Three Scan Profiles, One Detection Challenge
One of the more interesting aspects of this engagement was running the same attack scenario across three different intensity profiles. The Silent scan introduced significant delays between actions, up to 60 seconds per step (randomly), distributing the attack over several hours to evade threshold-based detections. The Medium scan compressed the timeline considerably. The Aggressive scan ran in under two minutes.
The practical implication for detection engineering is significant: a rule tuned to catch aggressive scanning may completely miss a patient attacker operating in silent mode. Effective detection requires logic that accounts for distributed, low-frequency activity and not just burst patterns.
Password Spraying: LDAP vs. RPC
The password spray phase ran in two distinct modes. The RPC method used wmic.exe to validate credentials, a classic LOLBin technique that abuses a legitimate Windows binary to avoid introducing attacker tooling. The LDAP method used .NET DirectoryEntry bindings, which are less likely to trigger process-based detection heuristics.
A particularly useful finding emerged from the user enumeration component: a dedicated detection rule for username enumeration only triggers at a threshold of 10 or more tested users. In this exercise, only five usernames were included in the spray list: enough to conduct a realistic attack, but below the alert threshold. This is exactly the kind of gap a purple team exercise surfaces that a theoretical review never would. Below is a section of the Password Spray timeline.
The spray was also designed to rotate across domain controllers, distributing failed logon events to avoid per-DC threshold alerts. This reinforced the need for cross-DC aggregation in detection logic.
The Feedback Loop: Where Improvement Actually Happens
The real value of purple teaming is in what happens afterwards.
In our debriefing session, we reviewed each technique against its detection outcome, analyzed the root causes of missed detections, and defined concrete next steps. Some examples from this engagement:
- Expanding enumeration coverage: The command
net localgroup administratorsdoesn’t generate AD-side telemetry. To detect this more robustly, we identified that querying Active Directory directly, rather than running local commands, produces Event IDs which our existing rules can leverage. This became a test case for the next engagement cycle. - ESQL migration: Several detection rules are being converted to ESQL format to provide greater flexibility in expressing conditions like cross-source aggregation and time-windowed thresholds.
Detection Engineering as a Living Practice
One thing this engagement reinforced is that detection engineering is not a configuration task. It’s a continuous practice. Rules that are correct today may be insufficient tomorrow, not because the rule is wrong, but because attacker behavior has shifted, a new evasion technique has emerged, or the environment has changed in ways that alter baseline noise levels. This small section of the Detection timeline shown below could be used, for example, as a starting point to improve future detection rules.
Purple teaming creates the conditions for detection logic to evolve. By executing real techniques against the production environment in a controlled way, we can generate some precious telemetry. We know exactly what was executed, when, and from where, and we can measure detection coverage against that known baseline.
Conclusion
The purple teaming engagement validated several detection capabilities, surfaced concrete gaps, and generated a clear set of improvements to be implemented before the new cycle begins.
More importantly, it did what purple teaming is designed to do: Turning assumptions into evidence. The best way to know what your rules actually catch is to run the attacks yourself, under controlled conditions, with full visibility into both the offensive and defensive sides of the operation.
These Solutions are Engineered by Humans
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find cybersecurity issues interesting, maybe you could start in a cybersecurity or similar position here at Würth IT Italy.
Patrick Di Fazio
Author
