Meridian Logistics Group represents a common and dangerous gap in mid-size organisations: infrastructure that was provisioned for a specific business need, Remote Desktop Protocol (RDP) access for a contractor, and never properly decommissioned once that need ended. An exposed jump host with a local admin account and no monitoring in place is not a hypothetical risk. It is one of the most frequently exploited entry points in real-world ransomware and initial access incidents, precisely because it requires no phishing, no malware, and no social engineering. It only requires patience and a credential list.
The core challenge in this lab is twofold. First, Meridian has no visibility into authentication activity on the jump host at all, so a sustained brute-force campaign of roughly 4,000 attempts could run for days without anyone noticing. Second, once credentials are compromised, the same lack of monitoring means a pivot toward the domain controller using valid credentials would look like normal activity rather than an attack, since there is no baseline or alerting logic in place to flag it.
This lab addresses that gap by building detection from the ground up: enabling the right log sources, writing detection logic that recognises the specific pattern of high-frequency failed logons followed by a success, and proving that logic works against a real simulated attack rather than a theoretical one.
The approach mirrors what Meridian's retainer requires: detection within 15 minutes of brute-force success, with supporting evidence. To achieve that, this lab:
A brute-force detection capability like this is one of the highest-value, lowest-complexity controls a SOC can deploy, and it is exactly the kind of control that gets skipped in real environments because it is overlooked. In production, the difference between having this detection in place and not having it is the difference between catching a credential-stuffing campaign in minutes and discovering it weeks later during a post-breach forensic review, by which point the attacker may already hold domain admin rights.
The frequency-based approach used here also generalizes well beyond RDP. The same logic, high volume of failures followed by a success from one source, applies to VPN gateways, web application logins, and cloud identity providers. Building it correctly once, with an understanding of false-positive sources like password rotation events, means it can be adapted rather than rebuilt for every new authentication surface an organization introduces.
Wazuh is the detection and alerting engine for this lab. It is already deployed as the SIEM backbone across my entire home SOC, so using it for the live, operational rule keeps the detection consistent with everything else that has been built rather than introducing a second parallel alerting path. Its frequency-based rule syntax (frequency, timeframe, and correlation by source IP) is purpose-built for exactly this kind of pattern, repeated failures from one source culminating in a success, without needing external tooling to do the correlation.
Sysmon provides the process-level context around the authentication events. While Windows Security logs confirm that a logon attempt happened, Sysmon shows what happened immediately after a successful one, such as any process spawned under the compromised account. This matters for the lab's containment and impact assessment, since a successful brute-force login is only the first half of the story.
Sigma is included to build vendor-neutral detection authoring skills. Real-world detection engineering rarely stays locked to one platform, and being able to write a rule once in Sigma's format and convert it to whatever backend a given employer uses (Wazuh, Elastic, Splunk, Microsoft Sentinel) is a worthwhile skill. In this lab, the Sigma rule is authored properly and converted into its Wazuh format for live use, with the Elastic-equivalent query documented alongside it, providing a working proof of the conversion process without the resource cost of standing up a second live stack on constrained lab hardware.
Elastic is represented in this lab as a documented detection target rather than a deployed stack. The deliverable still demonstrates fluency with Elastic's query syntax (KQL/EQL) since the converted rule is written out and explained, which satisfies the learning objective of understanding how the same logic maps across SIEM platforms, without risking the stability of the existing Wazuh deployment on my hardware resource that has no spare capacity to absorb a second heavyweight service.