SentinelOps is a local-first Windows security log analyzer and SOC dashboard. This repository keeps the original project and the upgraded Phase 6 edition as two clearly separated applications.
| Version | Purpose | Run | Address |
|---|---|---|---|
| SentinelOps v1.0 | Original security log analyzer and SOC dashboard | .\start-v1.ps1 |
http://127.0.0.1:8080 |
| SentinelOps v2.0 | Modular Phase 6 threat hunting and incident platform | .\start-v2.ps1 |
http://127.0.0.1:8081 |
The original application analyzes real Windows event logs, detects common attack patterns, maps findings to MITRE ATT&CK, calculates risk, and stores history locally.
The upgraded application adds a modular Python backend, expanded Windows and Sysmon detections, incident case management, evidence-grounded AI summaries, threat hunting, local IOC matching, Sigma import, an ATT&CK heatmap, investigation timelines, and HTML/PDF reports.
| Incident Workbench | Threat Hunting |
|---|---|
 |
 |
| Detection Studio Simple Mode | Detection Studio Advanced Mode |
|---|---|
 |
 |
SentinelOps/
|-- v1.0/ Original stable application
|-- v2.0/ Latest Phase 6 application
|-- start-v1.ps1 v1.0 launcher
|-- start-v2.ps1 v2.0 launcher
`-- verify-elevated.ps1 Checks Security log collection when elevated
- Windows 10 or Windows 11
- PowerShell 5.1 or newer
- Python 3.10 or newer
If PowerShell blocks a launcher, allow scripts only for the current terminal:
Set-ExecutionPolicy -Scope Process BypassWindows restricts the Security event log to elevated processes. That log is the source of the logon, privilege, and account events these tools are built around, so start SentinelOps from an elevated PowerShell window to analyze it:
Start-Process powershell -Verb RunAsBeing signed in as an Administrator is not sufficient on its own. Under User Account Control, an ordinary PowerShell window runs with a filtered standard-user token even for an administrator account, and the Security log is denied to it. Check which case you are in with:
[Security.Principal.WindowsPrincipal]::new([Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)False means the window is not elevated, regardless of your account type.
To confirm elevated collection actually works, run this from an elevated window:
.\verify-elevated.ps1It checks Get-WinEvent directly, then starts each application on a temporary
port and database and collects from the Security channel through both APIs,
cleaning up afterwards. It refuses to run unelevated rather than reporting a
misleading pass. The automated test suite cannot cover this path, because it
requires rights the test runner does not have.
Without elevation everything else still works. The System, Application,
PowerShell, Defender, and Sysmon channels are readable normally, EVTX
import is unaffected, and a collection from Security returns a clear
"requires Administrator rights" error rather than an empty result. Both
/api/status and /api/v2/status report elevated and restrictedChannels
so you can tell before running a collection.
SentinelOps is a local-first, single-user analyst tool. It has no authentication, authorization, or multi-user model.
- Both applications bind to
127.0.0.1only, and both reject requests whoseHostorOriginheader is not the local service. That blocks cross-site requests and DNS rebinding from a malicious web page, onGET,HEAD, andPOSTalike. - SQLite databases stay on the local computer and are excluded from Git.
- Do not expose either service to a network or the internet. Every API endpoint is anonymous, and on Windows both collection endpoints read local event logs. Remote exposure would require an authentication layer that this project does not implement.
- Do not publish databases or logs collected from real systems, because they may contain sensitive information.
SentinelOps source code is available under the MIT License.