How Shield works
Shield is Dynacop’s attack-blocking layer. MFA verifies the person signing in; Shield deals with everyone who fails to.
The pipeline
Section titled “The pipeline”- Watch. The agent reads Windows failed sign-in events (Event 4625) directly from the machine’s event log — including brute-force attempts that never reach an MFA prompt.
- Attribute. Events are enriched to tell services apart: RDP is confirmed with dedicated RDP-stack evidence, and SSH brute-force is captured from the OpenSSH event channel (plain 4625s from SSH carry no IP). Anything unprovable stays honestly labeled network.
- Correlate. Attempts are counted per source IP within a time window.
- Block. When an IP crosses the policy threshold, the agent writes a Windows Firewall rule blocking it, with a time-to-live. Repeat offenders get progressively longer blocks; persistent low-and-slow sources get long-term blocks.
Local by design
Section titled “Local by design”The blocking decision runs on the machine, with policy cached locally — so Shield keeps protecting even if the machine temporarily can’t reach the cloud. Blocks expire on their own; nothing depends on a round-trip.
- Shield blocks brute-force sources on RDP and SSH — the services where an attacker has a network source IP. A local console sign-in has no IP to block.
- MFA (the other half of Dynacop) applies to console and RDP sign-ins.
- Blocking works via Windows Firewall — if the firewall is off, the panel says so honestly instead of pretending protection exists.
Honesty rules you’ll notice
Section titled “Honesty rules you’ll notice”- Service labels are conservative: RDP only when proven, otherwise network; the tooltip explains the evidence.
- The headline “auto-blocks” metric counts automatic blocks only — manual blocks are listed but never inflate the number.
- Old agent versions that can detect but not yet block show block pending rather than a false “blocked”.