RedTide: Automated Attack Simulations for Endpoint Security Validation

Modern endpoint security platforms pack a serious amount of capability into a single agent. Antivirus, behavior monitoring, exploit protection, network filtering, EDR behavioral alerts, and more. And for every one of those capabilities, there is a documented way to test it. The test procedures exist. The problem is actually going through them.

If you have ever tried to validate endpoint protection on a VM, you know the drill. Download a test file, tweak a security setting, run the test, open your EDR console, wait for the alert to show up, then undo the setting so the VM is back to normal. Now repeat that for the next capability. And the next one. Thirteen times total if you want decent coverage. If you forget to restore a setting along the way, the VM ends up in an inconsistent state, and you might not realize it until the next validation run gives you unexpected results.

I kept running into this. Every time I needed to validate endpoint security configurations on a VM, it was the same manual loop. It was not hard, just slow and repetitive, the kind of work where you inevitably skip a step or forget to undo something. So I built a tool to automate it.

The name comes from the ocean. A red tide is a natural phenomenon where algae bloom and release toxins into the water, invisible until the damage is done. It felt like the right metaphor: the simulations look like real threats to your endpoint security stack, they trigger the same detection logic, but there is nothing actually harmful in the water. And if you spend enough time diving, the way I do, you learn to respect anything that tests whether your environment can handle what is coming.

What RedTide does

RedTide is a PowerShell toolkit that automates 13 attack simulations for endpoint security validation. It targets a Windows Azure VM and uses Invoke-AzVMRunCommand to deploy each simulation remotely. You can run it from your own workstation, from a jump box, from another VM in the same network, or directly on the target VM itself. No agent to install, no special setup on the source machine.

Before running any simulation, it checks that everything is in place: Azure PowerShell modules installed, Azure login active, target VM exists and is running, Windows OS confirmed, endpoint agent onboarded, Run Command permissions verified. If anything is missing, it offers to fix it.

Each simulation comes with a briefing card. It tells you what the test does, what files it creates on the VM, what security alert to expect, and how long the alert typically takes to appear. Some simulations are fully automated. Others deploy artifacts and then tell you to complete a manual step via RDP, for example opening a URL in Edge to trigger SmartScreen.

When you are done, a single cleanup command restores every security setting to its pre-simulation state using a baseline snapshot captured at the start of the session.

The 13 simulations

I organized the simulations into three capability areas:

How it works

When you launch RedTide, the welcome screen gives you two paths: run pre-flight checks (recommended for first use) or skip straight to simulations.

Pre-flight checks validate nine things: Az PowerShell modules, Azure login, subscription context, resource group, VM existence, VM power state, VM agent status, Windows OS, and Run Command permissions (RBAC). Each check shows a pass/fail indicator. If something is wrong, it tells you what to do about it.

VM readiness checks run on the target VM itself: antivirus service running, real-time protection enabled, behavior monitoring enabled, antivirus signature age, and EDR sensor running.

Once everything passes, a connection card summarizes the target: VM name, resource group, subscription, location, OS type, power state, signed-in user, and RBAC role. This is designed so you can confirm at a glance that you are pointed at the right VM before running anything.

The simulation menu uses a tree-style layout organized by capability area. Arrow keys to navigate, number keys to jump, Esc to go back. I wanted this to feel fast, not like clicking through a wizard.

Before each simulation runs, a briefing card explains what will happen: what the test does, what files it creates on the VM, what security configuration it changes, what alert to expect, and how long to wait. For scenarios that require manual steps (like opening a URL in Edge), the card lists the exact steps. I included these because I wanted someone to be able to use the tool without reading any external documentation.

During deployment, each step shows a spinner with elapsed time. When a step completes, the spinner is replaced with a pass/fail indicator.

After deployment, a results card shows the expected alert name, where to find it in your EDR console, a KQL query for Advanced Hunting (if applicable), and navigation options: run another simulation, go back to the main menu, or exit.

CLI mode

You do not have to use the interactive menu. RedTide supports direct invocation for automation scenarios:

.\Start-RedTide.ps1 `
  -Scenario CloudProtection `
  -ResourceGroup "security-lab-rg" `
  -VMName "test-win11"

Use -WhatIf to preview what the tool would do without actually executing on the VM. Use -SkipChecks to bypass pre-flight validation when you know the environment is ready. These make it practical to integrate into CI/CD pipelines or scheduled validation runs.

Design decisions

A few things that shaped how this was built:

No real malware. Every simulation relies on industry-standard test techniques: EICAR test strings, the documented AMSI test GUID, Microsoft test URLs from demo.smartscreen.msft.net, Microsoft test files from go.microsoft.com and demo.wd.microsoft.com, and suspicious command patterns that trigger behavioral detection. Nothing that puts a real payload on the VM.

Baseline and restore. Before any simulation runs, RedTide captures a snapshot of the VM's security configuration. The cleanup command restores every modified setting from this baseline. This was important to me. I did not want a tool that changed things and left you guessing about what was different afterward.

One file per simulation. Each of the 13 simulations lives in its own strike module file. They all follow the same pattern: a single exported function, a standard parameter set, and structured output. If you want to add a 14th simulation, you copy one of the existing ones and modify it.

Background jobs with context serialization. Run Command calls can take 30 to 60 seconds. Rather than freezing the console, the tool serializes the Azure context, passes it into a background job, and shows a spinner with elapsed time. When the job completes, it deserializes the result and continues. This keeps the UX responsive without requiring async PowerShell.

Tech stack