Initial OfficeCom Sentinel client and deployment assets

docs/attacktracer-analysis.md

@@ -0,0 +1,74 @@
+# AttackTracer Reverse Engineering Notes
+
+## What the legacy app does
+
+`AttackTracer` is a .NET Framework 4.5 WinForms application installed under `Servolutions\BotFence`.
+
+Its main behavior is:
+
+- scan Windows Event Logs for failed logins
+  - Security `4625` for Windows logons
+  - Application `18456` for SQL Server login failures
+  - Application `1035` for Exchange-related login failures
+- scan IIS/FTP logs under `C:\inetpub\logs\LogFiles` and `D:\inetpub\logs\LogFiles`
+- scan FileZilla Server logs under both `C:` and `D:`
+- aggregate attacks by source IP
+- geolocate IPs through `http://www.autotimezone.net/atzonline/atz.svc`
+- render a top-10 result list and an HTML report
+- optionally email the report through `http://pulse.serverpulse.com/PulseCounter/notifications.svc`
+
+## Important weaknesses in the old design
+
+- UI-first architecture
+  - the app is a desktop WinForms tool instead of a background service or scheduled automation
+- hard-coded paths
+  - it only checks a few fixed IIS and FileZilla folders
+- legacy external dependencies
+  - geolocation and email both depend on old unauthenticated HTTP WCF endpoints
+- weak integration model
+  - results are shown locally or emailed, but not pushed into a central operations system
+- mixed responsibilities
+  - scanning, aggregation, rendering, and notification all live inside the same form workflow
+
+## Meaningful direction for a NinjaOne-connected replacement
+
+Instead of reviving the WinForms app, the better replacement is a small service or scheduled CLI with this split:
+
+1. collectors
+   - Windows Security/Event Log collector
+   - IIS/FTP log collector
+   - FileZilla collector
+2. normalization
+   - normalize all findings into one event schema like:
+     - `timestamp`
+     - `sourceIp`
+     - `targetType`
+     - `username`
+     - `source`
+3. correlation
+   - aggregate by IP and time window
+   - compute severity, velocity, and repeated targets
+4. outputs
+   - JSON report on disk
+   - HTML report if needed
+   - NinjaOne-facing output channel
+
+## Suggested NinjaOne integration patterns
+
+Because there is no NinjaOne code in this repository yet, the safest first integration targets are:
+
+- write a machine-readable JSON summary that a NinjaOne script can collect
+- emit a plain-text summary to stdout for script-result capture
+- optionally write a CSV or HTML artifact for technicians
+- keep notification transport separate so we can later swap in a NinjaOne API client, webhook, or custom-field updater
+
+## Practical next step
+
+Build a new `AttackTracer` replacement around a headless scanner first, then add the NinjaOne transport as a separate adapter.
+
+That lets us preserve the useful detection logic while dropping:
+
+- WinForms
+- WCF
+- external HTTP dependencies
+- vendor-specific mail plumbing