Analyzing Bluekeep Rdp Event Logs

Common Pitfalls

• Over-broad IOC matching (observed in all 3 runs): using OR-heavy filters pulled in extra IPs and failed test_correct_attack_sources.
• “Up to 5” misread as “always return 5”: all failures included extra IPs; verifier expected only the true attacker set.
• No normal-pattern exclusion: internal/test-like sources with partial IOC overlap contaminated ATTACK_SOURCES.
• Weak confidence threshold for source attribution: counting any ms_t120 hit as an attacker inflated false positives.
• Relying on truncated previews: partial sed output hid full distribution details; full-file parsing is required.

Verification Strategy

1. Schema check before grading
   • File exists, non-empty.
   • Exactly 3 lines.
   • Exact prefixes:
     • VULNERABLE_SYSTEMS:
     • ATTACK_SOURCES:
     • SUCCESSFUL_EXPLOITS:
2. Logic check
   • Recompute unpatched-target intersection independently (second command/script).
   • Recompute attacker frequency from only high-confidence exploit events.
   • Confirm each reported attacker has repeated exploit-pattern evidence.
3. False-positive guardrail (critical from failures)
   • Remove low-confidence/normal-pattern-adjacent sources before finalizing ATTACK_SOURCES.
   • Prefer a shorter, high-confidence list over filling to max length.
4. Run verifier/tests (pytest /tests/test_outputs.py -rA) when available.

References to Load On Demand

• IOC/normal parsing snippets (awk/Python) for structured field extraction.
• A reusable “two-pass” parser:
  1. classify event confidence,
  2. aggregate source/destination/success metrics from high-confidence subset only.