You download a single-file agent for your OS: a Python script (macOS/Linux via curl) or a .bat wrapper (Windows). The .bat downloads the Python agent via PowerShell, sets UTF-8 encoding, and launches it.

• macOS/Linux: curl | python3 — one-liner, no installer required
• Windows: .bat wrapper uses PowerShell iwr to download the agent, then runs it with PYTHONIOENCODING=utf-8
• Agent is a self-contained ~1,000-line Python script served dynamically from /api/monitor/agent/download
• No admin / root required for most checks — those that need elevation are clearly marked
• Agent source is open: download the .py file directly from the server to inspect before running

The agent runs a fixed list of CIS Level 1 & 2 checks using only OS-native commands (systemctl, defaults read, reg query, netstat). Each check is parsed by a deterministic rule — no AI involved.

• macOS: SIP, Gatekeeper, FileVault, firewall, screen lock, auto-login, guest account, SSH, Bluetooth, AirDrop, Safari, NTP, login banner
• Linux: UFW/iptables, SSH hardening, auditd, AppArmor/SELinux, kernel parameters (ASLR, SYN cookies), /etc/shadow permissions, LUKS encryption, NTP
• Windows: registry-based BitLocker, Windows Firewall, Windows Defender, UAC, open ports (netstat -an -p TCP), RDP, auto-login, screensaver timeout
• Each check has a timeout (8s on Windows, 15s on other platforms) — hung commands don't stall the scan
• Results include PASS/FAIL status, the raw command output as evidence, and a plain-English remediation step

The agent starts a local HTTP server (random port) and opens your browser to it. As each check runs, results stream to the browser via Server-Sent Events — you see the log fill in live.

• _TeeOutput wraps stdout: every print() call is teed to the browser SSE queue and the terminal simultaneously
• SSE stream uses event types: 'init' (hostname/OS), 'log' (check output), 'complete' (final score + findings)
• Python stays alive via _sse_delivered.wait(timeout=30) until the browser acknowledges the 'complete' event
• On Windows: 3-second delay before scan starts to give Edge/Chrome time to open and establish the SSE connection
• Scan errors surfaced in browser: any unhandled exception is caught and sent directly to the SSE queue as a visible error

After all checks complete, findings are uploaded to the CyberSec Tools server where Claude analyses the results, generates a risk score and prioritised remediation plan, and saves them to your dashboard.

• Upload payload: hostname, OS, list of findings (CIS ID, status, evidence, remediation)
• Claude generates a plain-English executive summary + top-5 priority fixes
• Results stored in Supabase — viewable at /security-monitor with full finding history
• Re-scan diffs: subsequent scans show new vs resolved findings from the previous run
• Domain-grouped findings: 9 domains (OS & System, Encryption, Network, SSH, Logging, Auth, File System, Privacy) with one-click filter pills

The pentester probes the endpoint to map the full API surface before any attack.

• Sends introspection query to map all types, queries, mutations, and subscriptions
• Identifies framework (Apollo, Hasura, graphql-yoga) from response headers and error shapes
• Extracts field names, argument types, and nested relationships
• Flags introspection-enabled endpoints as an info disclosure finding

Sends crafted payloads through every string argument to test for injection flaws.

• SQL injection — UNION SELECT, boolean blind, time-based payloads
• NoSQL injection — $gt, $ne, $regex operators in JSON arguments
• XSS reflection — script tags, event handlers, encoded payloads in responses
• Each test checks response for error signatures, data leaks, or behavior changes

Tests for broken auth, IDOR, and privilege escalation.

• Sends queries without auth tokens to detect unprotected resolvers
• Flags sensitive queries/mutations (user, admin, delete, payment) accessible without auth
• IDOR testing — enumerates sequential IDs on user-scoped queries
• Checks if different user contexts can access each other's data

Tests whether the API enforces query complexity and rate limits.

• Query depth attack — sends deeply nested queries (10+ levels)
• Alias overloading — duplicates expensive fields with 50+ aliases
• Batch query attack — sends 100+ queries in a single request
• Rate limit testing — 20 parallel requests to detect missing throttling
• Checks for query cost analysis headers (Apollo, Hasura patterns)

Probes for server-side request forgery and common misconfigurations.

• SSRF — injects internal IPs (169.254.169.254, localhost) into URL-type arguments
• CORS — tests origin reflection and wildcard configurations
• Field suggestions — checks if disabled (info leak via typo correction)
• Persisted queries — tests if arbitrary queries bypass allowlists

All findings are compiled into a report with CWE/OWASP mapping and framework-specific fixes.

• Each finding includes: severity, confidence, CWE ID, OWASP category
• Full request/response evidence for every test
• Framework-specific remediation (Apollo, graphql-yoga, Hasura, etc.)
• Export as JSON, Markdown, or CSV for CI/CD integration

Describe a suspicious message, call, or email — or upload a screenshot.

• Text input — paste the message or describe what happened
• Image upload — screenshot of a suspicious email, SMS, or website
• Both inputs accepted together for richer context
• No account or login required

Before any AI call, a deterministic engine instantly checks for known scam patterns. If it matches, no data ever leaves the server.

• 40+ rules covering CRA scams, bank fraud, tech support, romance, lottery, job scams
• Pattern matches on phrases, urgency cues, payment demands (gift cards, crypto)
• Impersonation detection: CRA, RCMP, Microsoft, Apple, banks, Amazon, Netflix
• High-confidence rule match → verdict returned immediately, zero API calls

If no rule matches, your text is sanitized before leaving the server — personal details are replaced with placeholders.

• Phone numbers → [PHONE]
• Canadian SINs (NNN NNN NNN format) → [SIN]
• Email addresses → [EMAIL]
• Credit/debit card numbers → [CARD]
• Bank account numbers → [ACCOUNT]
• Street addresses → [ADDRESS]
• Names with titles (Mr./Mrs./Dr.) → [NAME]
• The scam context (tactics, urgency cues, platform) is preserved — your identity is not

The sanitized text is sent to Google Gemini for semantic analysis. Raw images are never sent — only the OCR-extracted, PII-stripped text.

• Gemini receives: sanitized text only — no raw image bytes, no PII
• Screenshot text is extracted locally by Tesseract OCR (runs in-browser via WebAssembly)
• PII stripped from OCR output before the text is sent to Gemini
• Detects brand impersonation, urgency manipulation, social engineering patterns
• Returns structured JSON: verdict, risk level, red flags, safe steps
• OpenAI GPT-4o-mini used as fallback if Gemini is unavailable

Results are classified into one of four verdicts with a matching risk level and source badge.

• SCAM — confirmed scam patterns detected, high/critical risk
• LIKELY SCAM — strong indicators present, medium-high risk
• LIKELY SAFE — no significant patterns found, low risk
• SAFE — no scam indicators detected
• Result card shows whether verdict came from local rules or Gemini AI

Every result includes plain-language next steps tailored to the specific scam type.

• What to do now — safe immediate actions (don't click, don't pay, hang up)
• What to never do — scam-specific warnings (never buy gift cards, never give remote access)
• Where to report — Canadian Anti-Fraud Centre, RCMP, bank fraud lines, CISA
• Scan history stored locally in your browser only — never sent to any server

Drag and drop or browse for any photo. Previewed locally in your browser before anything is sent.

• Supported formats: JPEG, PNG, WebP, GIF, HEIC
• Preview renders locally — image not sent until you click Analyze
• No size limit enforced by the UI, but Gemini has a practical limit (~20MB)

The image is uploaded to Google Gemini Vision with a structured forensics prompt. Your image is sent to Google's servers.

• Image converted to base64 and POSTed to Gemini's generativelanguage.googleapis.com endpoint
• Prompt asks for AI generation signals AND post-processing/editing detection simultaneously
• Gemini returns structured JSON — verdict, confidence, signals, artifacts, likely tool, editing clues
• Google processes the image but does not store it after the API call completes

Classified on a 5-point scale from AI_GENERATED to REAL, with a confidence score and per-signal breakdown.

• AI_GENERATED — near-certain AI origin (Midjourney, DALL-E, Stable Diffusion, Flux, Firefly, Sora)
• LIKELY_AI — strong indicators but some ambiguity
• UNCERTAIN — mixed signals, could be either
• LIKELY_REAL — probably a real photo
• REAL — almost certainly taken by a camera
• Each signal shown with weight (high/medium/low) and flag (AI / real / neutral)

Simultaneously checks for post-processing manipulation — even on photos that started as real camera shots.

• Detects: face swap, object removal/insertion, deepfake compositing, retouching, inpainting
• 5-level editing verdict: HEAVILY_EDITED → ORIGINAL
• Lists specific editing techniques detected (clone stamping, liquify, AI inpainting, etc.)
• Highlights suspicious regions (background, face, hands, text areas)
• Forensic clues shown with severity and plain-English explanation

Upload any audio clip. It is sent to your server for processing — no third-party AI API is involved at any point.

• Supported: MP3, WAV, M4A, AAC, OGG, FLAC, WEBM
• File is transcoded to 44.1kHz mono PCM WAV using ffmpeg server-side
• Temp file is deleted immediately after analysis
• No audio is stored or logged

Pick how deep you want the analysis to go. All three models run purely in signal processing — no AI API.

• Acoustic Heuristics (Fast) — 6 classic checks: silence ratio, pause rhythm, ZCR, pitch (YIN), spectral flux, amplitude dynamics
• Acoustic + Deep DSP (Recommended) — all 12 checks: above + MFCC stationarity, CPP, HNR, micro-timing jitter, spectral centroid drift
• Deep DSP Only (Modern TTS) — 5 deep checks targeting ElevenLabs/VITS/WaveNet artifacts

The WAV is analyzed frame-by-frame across acoustic and spectral dimensions that TTS systems struggle to replicate.

• Zero-Crossing Rate — TTS audio often too clean (abnormally low ZCR variance)
• Pitch trajectory (YIN algorithm) — robotic pitch or unnatural smoothness
• Spectral flux — TTS lacks organic transient dynamics between frames
• MFCC stationarity — TTS mel-cepstral coefficients show unnatural smoothness over time
• Cepstral Peak Prominence (CPP) — measures vocal clarity; TTS often too perfect
• Harmonic-to-Noise Ratio — real voices have organic breathiness TTS lacks
• Micro-timing jitter — natural speech has tiny timing irregularities; TTS is too consistent

Each check votes with a weight. Votes are combined into a confidence score and overall verdict.

• DEEPFAKE — high confidence the audio was generated by TTS or voice cloning
• LIKELY_DEEPFAKE — strong indicators present
• UNCERTAIN — mixed signals
• LIKELY_REAL — probably a real human voice
• REAL — natural speech detected with high confidence
• Each indicator card shows: label, severity, your value vs. expected range, and what it means

The tool requests microphone access via the browser's MediaStream API. Audio is captured locally — it is never sent to a third party.

• Uses navigator.mediaDevices.getUserMedia() — standard browser API
• Audio stays in the browser and is POSTed to your own server only
• You can stop recording at any time; mic access is released immediately

Audio is captured in 2-second chunks and analyzed in near-real-time as you listen to the call.

• MediaRecorder buffers 2 seconds of audio at a time
• Each chunk is POSTed to /api/live-call-chunk on your server
• Server transcodes chunk to WAV and runs DSP analysis — same engine as Audio Deepfake Detector
• Result returned in ~1–2 seconds, giving near-real-time feedback

Each chunk's verdict is plotted on a live timeline. The rolling average tells you if the voice changed mid-call.

• Same 3 detection models as Audio Deepfake Detector (Acoustic / Acoustic+Deep / Deep DSP)
• Timeline chart shows deepfake probability over time — spikes indicate possible voice switching
• Running verdict updates every 2 seconds
• Helpful for detecting real-time voice changers or AI voice injection into a live call

When you stop recording, a full session summary is shown with timeline, peak confidence, and per-indicator breakdown.

• Total chunks analyzed, average deepfake probability, peak confidence
• Full indicator breakdown for the most suspicious chunk
• Timeline exported or reviewed in-page
• No audio or results are stored after the session ends

Paste a URL (YouTube, TikTok, Instagram, X, Facebook) or upload a file directly. The video is downloaded server-side via yt-dlp and stored in a secure temp file.

• yt-dlp handles URL extraction — supports 1000+ platforms including Instagram Reels and TikTok
• File uploads accepted up to 100MB: MP4, MOV, WebM, AVI
• Temp file deleted immediately after analysis completes
• Video never stored, logged, or associated with any account

The full video is sent to Google Gemini Vision for semantic and visual analysis. Gemini watches the video as a whole and returns a structured forensics report.

• Prompt instructs Gemini to look for: skin texture unnaturalness, hair/teeth rendering artifacts, eye blinking anomalies
• Checks for perfectly static backgrounds — a hallmark of HeyGen, D-ID, and Synthesia avatar tools
• Jewelry and hair movement analysis: AI avatars often have earrings and hair that don't move with head motion
• Detects over-smooth skin, uncanny valley facial expressions, and temporally inconsistent lighting
• Returns: verdict (REAL/LIKELY_REAL/UNCERTAIN/LIKELY_AI/AI_GENERATED), confidence 0–100, and a list of signals
• Gemini processes but does not store the video after the API call

10 key frames are extracted from across the video and analyzed individually by Gemini Vision, looking for per-frame artifacts Gemini might miss when watching at speed.

• ffmpeg extracts 10 evenly-spaced frames as PNG images
• Each frame sent to Gemini with a focused face-swap and deepfake artifact prompt
• Frame-level checks: facial boundary artifacts, unnatural skin smoothing, inconsistent lighting per frame
• Frame AI probability averaged across all 10 samples
• Helps catch videos where AI artifacts are only visible in specific frames (e.g., during motion)

ffmpeg runs low-level signal processing on the video to detect technical signatures that AI generators and compositing pipelines leave behind.

• YDIF (inter-frame luma difference) — measures how much the pixel brightness changes between frames. Real cameras always have noise. AI compositing of a face onto a static background gives near-zero YDIF
• PSNR analysis — infinite PSNR between frames = pixel-perfect copies = background is being duplicated (AI compositor fingerprint)
• Freeze detection — identifies frozen regions (static background while face moves = talking-head tool)
• Crop/padding detection — black bars or aspect ratio anomalies common in re-encoded AI content
• Codec analysis — VP9/H.264 at suspiciously low bitrate for facial content = re-encoded synthetic media
• Duration heuristic — 6–15 second clips at exactly 24fps are the default output of HeyGen, D-ID, Synthesia

A dedicated scoring pass specifically targeting AI avatar tools (HeyGen, D-ID, Synthesia, Wav2Lip) — the hardest category to detect because they use real backgrounds and real audio.

• Combines YDIF avg < 3.0 + freeze score > 0.3 + 24fps + 6–15s duration → talking-head pattern
• Assigned a dedicated talking_head_score (0–100) that boosts the final combined score independently
• These tools are hardest to catch because the background is real, the audio is real — only the face is synthetic
• Score ≥ 50 triggers a dedicated 'Avatar/Talking-Head' warning in results

All four layer scores are combined with weighted averaging. If technical forensics strongly contradict Gemini's visual verdict, the engine overrides Gemini.

• Base score = (Gemini × 0.40) + (Frame × 0.25) + (Pixel × 0.20) + (Avatar × 0.15)
• Talking-head override: if avatar score ≥ 70 AND pixel score ≥ 60 → score boosted to minimum 65
• Strong-signal boost: if any single layer score ≥ 85 → +10 to combined score
• Convergence boost: if 3+ layers all score ≥ 50 → +8 to combined score
• Verdict thresholds: ≥85 = AI GENERATED · 65–84 = LIKELY AI · 45–64 = UNCERTAIN · 25–44 = LIKELY REAL · <25 = REAL
• Signal override banner shown in UI when technical forensics overruled Gemini's visual analysis

TapIn is an iOS app (App Store, iOS 16+) that creates ephemeral chat rooms based on your GPS location. Only people within 300 metres of you are placed in your room.

• Available on the App Store for iOS 16+ — not a browser tool
• 300m GPS radius room discovery — the room changes as you move
• Account required to join — no anonymous access
• Room membership is determined server-side based on GPS coordinates
• No room codes or invites — presence in the area is the only key

Messages are routed through TapIn's server — not peer-to-peer. They are ephemeral: when you leave the room (close the app or move out of range), the message history disappears.

• Messages stored server-side only for the duration of the session
• Leaving the room permanently deletes your message history from the server
• No export, no screenshot protection — designed for transient, in-person conversation
• Server enforces the 300m proximity requirement — spoofed GPS is rejected

TapIn messages are ephemeral — they disappear when you leave the room.

• Messages exist on server only during your session — leaving the room purges them
• Account required — no anonymous access
• No permanent message history stored
• App Store available — iOS 16+

Enter any domain (e.g. yourcompany.com) to scan for lookalike variants attackers may have registered to impersonate your brand in BEC attacks.

• No authentication required — scan any domain instantly
• SLD and TLD are parsed separately to generate targeted variants
• Domain is never stored or logged

The engine generates over 120 domain variants across four attack categories used in real BEC campaigns.

• TLD swaps — .net, .org, .co, .io, .ai + 9 additional TLDs
• BEC keywords — login, secure, support, helpdesk, 365, portal variants with and without hyphens
• Typosquats — character transpositions, missing characters, doubled characters
• Homoglyphs — character substitutions (0→o, 1→l, 3→e, rn→m, etc.)

All variants are probed simultaneously via Cloudflare DNS-over-HTTPS. The browser never touches target domains directly.

• A record lookup — detects if the domain has a live web server
• MX record lookup — detects if the domain is configured to send or receive email
• Up to 120+ parallel requests via Promise.allSettled — scan completes in seconds
• All DNS queries go through Cloudflare's 1.1.1.1 DoH endpoint

Each registered lookalike is classified into one of three risk tiers based on the combination of web and email presence. An MSSP action list is auto-generated.

• CRITICAL — domain has both A record (live website) and MX record (email-capable) — active BEC threat
• HIGH — domain has A record but no MX — live website, could host phishing login pages
• MEDIUM — domain has MX record but no A — email-capable, potential spoofed sender domain
• MSSP action list: mail gateway blocklist entries, registrar abuse report template, defensive registration recommendations
• Unregistered high-value variants listed in collapsible panel — register them defensively before attackers do

All DNS queries are performed via Cloudflare DNS-over-HTTPS from the server. The target domain's email security records are fetched without any browser involvement.

• SPF: TXT record query on the root domain
• DKIM: TXT record queries on 20 common selectors simultaneously
• DMARC: TXT record query on _dmarc.domain
• BIMI: TXT record query on default._bimi.domain
• MTA-STS: TXT on _mta-sts.domain + HTTPS fetch of /.well-known/mta-sts.txt
• TLS-RPT: TXT record query on _smtp._tls.domain

The SPF record is parsed mechanism by mechanism. Common misconfigurations are flagged with specific remediation.

• +all mechanism detected as CRITICAL — allows any server to send mail as your domain
• Missing -all (hard fail) flagged — without it, SPF is informational only
• DNS lookup count checked against RFC 7208 limit of 10 — exceeding it breaks SPF validation
• include: mechanisms validated for legitimate mail providers (Google, Microsoft, SendGrid, etc.)

DKIM is probed across 20 common selectors in parallel. Most tools only check 'default' — checking all common selectors ensures accurate pass/fail.

• Selectors probed: google, selector1, selector2, default, mail, dkim, k1, s1, s2, em, smtp, sendgrid, amazonses, zoho, pm, mimecast, proofpoint, egress, mailgun, mandrill
• Key size checked — RSA 1024 flagged as weak, RSA 2048+ recommended
• Pass shown with the matched selector name and public key size

Three advanced email security protocols checked in parallel — each adds a layer beyond basic SPF/DKIM.

• DMARC: p=none flagged — quarantine or reject required for enforcement. pct= percentage and rua= aggregate report addresses shown
• BIMI: checks for brand logo display in Gmail/Apple Mail. VMC (Verified Mark Certificate) presence detected
• MTA-STS: enforces TLS encryption on all SMTP connections — mode (enforce/testing/none) and max_age shown
• TLS-RPT: SMTP failure report destination — confirms visibility into email delivery failures

Each protocol contributes a weighted score (SPF 25pts, DKIM 20pts, DMARC 30pts, BIMI 5pts, MTA-STS 5pts, TLS-RPT 5pts). A priority fix list with copy-ready DNS values is auto-generated for any score under 75.

• A (90–100): Full enforcement with reporting configured
• B (75–89): Good posture, minor gaps
• C (60–74): DMARC not enforcing or SPF weak
• D (40–59): Missing critical records
• F (<40): No SPF, DKIM, or DMARC
• Priority fix section includes copy-ready DNS record values for every failing check

Paste any suspicious URL for triage. The browser never contacts the URL — all probing is done server-side to protect the analyst from malicious content.

• Designed for MSSP triage — paste URLs from phishing reports, email headers, or threat intel feeds
• Example patterns: GoPhish tracker (?rid=), Evilginx lure path (/o/{id}), brand clone domains
• Domain automatically extracted for RDAP and DNS checks

The URL is fetched server-side. HTML body, response headers, and JS source are retrieved and analyzed without exposing the analyst's browser to malicious content.

• HTTP response headers analyzed: X-Powered-By, Server fingerprint (Express.js, PHP, nginx)
• HTML body parsed for brand impersonation markers, credential capture JS, and Telegram Bot API references
• Redirect chain followed server-side to reach the final landing page
• 3-second timeout — hung or unreachable URLs handled gracefully

HTML, JS, and URL structure are matched against known phishing kit signatures to identify the toolkit behind the infrastructure.

• Bluekit — Telegram exfil endpoint (t.me or api.telegram.org), Express.js backend, session capture JS patterns
• Evilginx2/3 — AiTM lure path pattern /o/{id} for session hijack attacks
• GoPhish — ?rid= tracking parameter in URL — identifies GoPhish campaign tracking links
• Modlishka — ?pl= lure link parameter — open-source AiTM reverse proxy
• Naked pages — Microsoft, DocuSign, OneDrive HTML/CSS clone template detection

The domain is enriched with domain age, DNS policy, and live threat intelligence databases.

• RDAP — domain registration date fetched. Newly registered domains (< 30 days) flagged as critical
• SPF + DMARC via Cloudflare DoH — missing email authentication is a strong phishing indicator
• URLhaus — malicious URL database from abuse.ch
• ThreatFox — IOC database matching known threat actor infrastructure

All signals are combined into a 0–100 risk score with a four-tier verdict, displayed with full evidence for each contributing signal.

• HIGH RISK (score ≥ 70) — kit signature confirmed or multiple critical signals
• LIKELY PHISHING (score ≥ 40) — strong indicators, kit not positively identified
• SUSPICIOUS (score ≥ 15) — anomalous signals, investigate further
• CLEAN (score < 15) — no phishing indicators detected
• Each signal shown with severity, category, and plain-English explanation

The target site is fetched server-side so the browser avoids CORS restrictions. Only HTTP response headers are captured — no body content is stored.

• HEAD request attempted first; falls back to GET if HEAD is blocked
• HTTPS enforced — HTTP URLs automatically upgraded
• Redirect chain followed up to 3 hops
• Response body is discarded — only headers are processed

The CSP header is parsed directive by directive. Dangerous values that bypass CSP protection are flagged with specific explanations.

• unsafe-inline in script-src — allows inline JS, defeats most XSS protections
• unsafe-eval in script-src — allows eval() and Function() constructor
• Wildcard sources (*) in script-src or object-src — effectively disables origin restrictions
• Missing object-src directive — allows Flash/plugin code execution
• Missing base-uri — allows base tag injection to redirect relative URLs

Ten security response headers are checked and scored. Each contributes points toward the overall A–F grade.

• HSTS — max-age threshold checks (30d / 180d / 1yr), includeSubDomains and preload flags
• X-Frame-Options — clickjacking protection; deprecated ALLOW-FROM flagged
• X-Content-Type-Options — enforces nosniff, prevents MIME-type sniffing
• Referrer-Policy — unsafe-url leakage detected; strict-origin-when-cross-origin recommended
• Permissions-Policy — camera, microphone, and geolocation restriction enforcement
• COEP + COOP — cross-origin isolation headers required for Spectre mitigation
• Server header — version string disclosure detection (e.g. Apache/2.4.18 leaks server version)

A priority fix section auto-generates recommended header values for every failing check — copy-paste ready for your nginx, Apache, or Cloudflare config.

• Each recommended header value shown with a copy button
• Severity: Critical → High → Medium — fixes listed in priority order
• Notable headers panel: x-powered-by, x-aspnet-version tagged as information disclosure
• X-XSS-Protection: deprecated — flagged if mode=block, with recommendation to use CSP instead

A real TLS handshake is performed server-side using Node.js tls.connect(). The full certificate chain and negotiated cipher suite are extracted without any browser involvement.

• Connects to target:443 using Node.js native TLS — same as how a browser connects
• Full certificate chain extracted: leaf cert, intermediates, root
• Negotiated TLS version and cipher suite captured from the handshake
• Connection closed immediately after handshake — no data sent to the target
• SNI (Server Name Indication) used to support virtual hosting

The leaf certificate and chain are analyzed for expiry, issuer identity, domain coverage, key strength, and tampering indicators.

• Expiry countdown bar — color-coded green → yellow → orange → red as expiry approaches
• Subject Alternative Names (SANs) — all domains covered, wildcard certificate detection
• Issuer and CA chain — identifies issuer, flags self-signed certificates
• Key size and algorithm — RSA < 2048 or EC < 256 flagged as weak
• Fingerprint (SHA-256) and serial number with copy button
• Future not-before date or epoch timestamp = likely tampered or misconfigured binary

The negotiated TLS version and cipher suite are graded against current best practices.

• TLS 1.3 — best (contributes A): perfect forward secrecy by default, no weak cipher options
• TLS 1.2 — acceptable (B): secure only if modern cipher (AES-256-GCM, ChaCha20)
• TLS 1.1 — deprecated (D): critical flag, must disable immediately
• TLS 1.0 — deprecated (D): PCI DSS non-compliant since 2018
• Weak ciphers below 128-bit flagged as critical. AES-256-GCM and ChaCha20-Poly1305 highlighted

Two supplementary checks run alongside the TLS analysis — HSTS from the HTTP response and CAA from DNS.

• HSTS header: max-age checked against 180-day and 1-year thresholds, includeSubDomains and preload flags shown
• CAA (Certification Authority Authorization): DNS record lookup via Cloudflare DoH showing authorised CAs
• Missing CAA: example record shown (0 issue 'letsencrypt.org') — copy-ready DNS entry to add protection
• Copy-ready nginx and Apache directives for adding HSTS

The scanner probes 60+ common subdomain prefixes in parallel — the same list attackers use when hunting for takeover opportunities.

• Probed subdomains: www, api, staging, dev, cdn, blog, admin, portal, app, mail, status, docs, static, assets, media, shop, store, support, help, careers, beta, test, sandbox, demo, dashboard, login, auth
• Both root domain and each subdomain are checked simultaneously
• All 60+ probes run in parallel via Promise.allSettled

Each subdomain is queried for CNAME records via Cloudflare DNS-over-HTTPS. The browser never touches the target domain.

• CNAME target extracted (e.g. myapp.azurewebsites.net, username.github.io)
• CNAME chain resolved to the final canonical target
• A record lookup on the CNAME target — no A record = dangling pointer, potential takeover
• All queries via Cloudflare 1.1.1.1 DoH

CNAME target domains are matched against 28 known cloud service patterns. Matched patterns trigger an HTTP confirmation step.

• GitHub Pages, Heroku, Netlify, Vercel, Azure, Azure CDN, AWS S3, Shopify, Fastly
• Tumblr, Ghost, Zendesk, HubSpot, Freshdesk, Surge.sh, Pantheon, WP Engine, Kinsta
• Each service has a known unclaimed response string (e.g. 'There isn't a GitHub Pages site here', 'No such app' for Heroku)

For matching CNAMEs, the subdomain is fetched via HTTP to confirm the unclaimed service response string is present in the body.

• HTTP GET sent to the subdomain URL
• Response body checked for the service-specific unclaimed fingerprint string
• Confirmed Vulnerable — fingerprint found in HTTP response body
• Likely Vulnerable — CNAME matches a known service pattern but HTTP body could not be confirmed

Findings are classified into three tiers with specific remediation steps for each confirmed or likely-vulnerable subdomain.

• Confirmed Vulnerable — HTTP body confirms unclaimed service; immediate action required
• Likely Vulnerable — CNAME points to cloud service; takeover likely possible
• Dangling CNAME — CNAME target has no A record; attacker can claim the service
• Remediation: remove the CNAME record, claim the resource on the cloud service, or audit access logs if already exploited

Enter OAuth scopes or paste a Microsoft OAuth consent URL. A deterministic rule engine scores each scope for risk level — no AI involved.

• 50+ scope rules covering Microsoft Graph, GitHub, Vercel, Slack, and Google Workspace
• Critical scopes: Mail.Send, MailboxSettings.ReadWrite (inbox rule manipulation), Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory
• High scopes: Files.Read.All, offline_access (persistent refresh token), Mail.Read, Calendars.ReadWrite
• Suspicious redirect_uri detection — non-Microsoft redirect domains flagged as primary consent phishing indicator
• Entra ID Tenant Scan: paste a Graph access token → scans all authorized OAuth apps in tenant. Token goes browser → graph.microsoft.com directly — never touches our server

When scope rules fire, the app name is matched against a curated knowledge base of 18 real vendor breach incidents. Full-text search — no embeddings or LLM needed.

• Snowflake (2024) — 165+ organizations breached including AT&T and Ticketmaster via stolen OAuth credentials
• Mintlify (2024) — GitHub OAuth token exposure leading to source code access
• Polyfill.io (2024) — CDN supply chain attack, 100K+ sites injected with malicious JS
• tj-actions/SpotBugs (2025) — GitHub Actions supply chain attack chain
• Microsoft Storm-0558 (2023) — Forged Azure AD tokens used to access US government email
• 6 new 2024–2025 incidents including Vercel/Context AI attack case study

8 production-ready KQL queries for Microsoft Sentinel detect OAuth consent attacks in real time — from first consent event to post-compromise data access.

• New Consent to High-Risk Scopes — fires when any user grants consent to mail, files, or admin permissions
• Consent by Unverified Publisher — detects consent where app publisher hasn't completed Microsoft's Publisher Verification
• Targeted Consent (≤3 users + high-risk scope) — attackers target few users to stay under the radar
• Post-Consent Mail Access via App Token — correlates consent events with MailItemsAccessed using the same AppId
• Consent → Immediate Data Access (15-min Correlation) — highest-confidence signal for active attacks
• MailboxSettings.ReadWrite + offline_access — detects inbox forwarding setup (attacker persistence mechanism)

A structured incident response playbook walks through triage, containment, and recovery for a confirmed OAuth consent phishing incident.

• Triage (0–15 min): confirm the alert, identify affected users, pull consent log from Entra ID
• Contain (15–30 min): revoke OAuth app consent, block AppId in Conditional Access, reset refresh tokens
• Investigate (30–45 min): hunt for data accessed via app token, check for inbox forwarding rules
• Recover (45–60 min): notify affected users, update app inventory, add AppId to Sentinel watchlist
• 5-layer readiness model: Prevention, Detection, Investigation, Response, Governance with per-layer checklist

Create a worker profile with their role, department, and the SaaS tools they need access to. WorkSecure generates a unique alias email for each assigned app.

• Worker profile: name, role, department, start date, MFA status
• Each worker gets a unique alias per SaaS platform — real email never shared with vendors
• Onboarding audit log entry created automatically with timestamp
• Works standalone or alongside your existing IdP — no SSO integration required

Each worker gets a unique catchall alias per SaaS application — containing blast radius if any vendor is breached.

• Format: worker+app-hash@yourdomain.com — unique per worker per app
• If a vendor is breached, only that alias is exposed — not the worker's real email or other apps
• Phishing sent to a vendor alias can be quarantined before reaching the worker's real mailbox
• Instant deactivation: disabling an alias stops all mail to that app immediately
• Full audit trail: every alias assignment, deactivation, and re-activation logged with timestamp

High-risk SaaS apps are routed through browser isolation — the worker sees the app normally but no code executes on their device.

• Supported isolation providers: Cloudflare Browser Isolation, Zscaler ZIA, Menlo Security
• On-prem email integration: configure Postfix or Exchange transport rules to rewrite email links at delivery time
• Every link a worker clicks passes through the isolation proxy before their browser loads it — zero-day protection with no UX friction
• Read-only isolation mode available for contractors with high data-exfiltration risk
• Session recording option for audit and incident response

When a worker leaves, one click revokes all their aliases, logs the offboarding event, and provides an OAuth revocation checklist.

• All aliases deactivated simultaneously — no app-by-app offboarding checklist needed
• OAuth token revocation guidance generated automatically for any apps with OAuth grants
• Offboarding audit record with timestamp stored in dashboard
• AI Offboarding Agent: describe the worker to the chat assistant — it handles the workflow end-to-end
• Re-onboarding: restore a worker with one click, all previous aliases and app assignments reinstated