Documentation

What Shieldome Siege actually does

Siege runs authorized penetration tests through a fixed, deliberate sequence: define an engagement's scope from your signed ROE, run recon and vulnerability identification against only what's in that scope, review what it found, and - if you choose to escalate a finding - get a human's explicit approval before anything actually confirms or exploits it. Every step is written to a tamper-evident audit log as it happens.

Accounts & access

There's no self-registration. Your organization's admin creates your account from Manage Users in the left-hand rail, with a temporary password you'll change on first login.

Signing in & two-factor authentication

Sign in at app.shieldomesiege.com. We strongly recommend enabling 2FA from Two-Factor Auth in the rail - scan the QR code with any TOTP app (Google Authenticator, Microsoft Authenticator, 1Password, Authy) and confirm with a live code. Once enabled, every login asks for a fresh code as a second step. If you lose your authenticator, ask your organization's admin to reset it from Manage Users.

Getting "Incorrect code" repeatedly during setup almost always means your authenticator app's clock has drifted from real time. Microsoft Authenticator in particular keeps its own internal clock separate from your phone's system time - open its time-sync setting (or confirm your phone's date & time is set automatically) and try again with a freshly generated code.

Change your password any time from Change Password - you'll need your current one.

Engagements & scope

An engagement is one authorized testing window against one client, defined by its Rules of Engagement (ROE). Create one from + New Engagement on the dashboard:

1. Name & client - whatever you'd recognize it by later.
2. ROE reference - a free-text pointer to the signed document (not the file itself - Siege doesn't store contracts).
3. Authorized scope - one entry per line: an IP, a CIDR range (203.0.113.0/24), a domain, or a wildcard subdomain (*.example.com).
4. Exclusions - anything inside that scope that's explicitly off-limits (a third-party-hosted subdomain the client can't authorize, for example). Exclusions always win over inclusions.
5. Testing window - start and end date/time. Nothing runs outside it, even if the scope is otherwise correct.

Recon & vulnerability identification

From an engagement's Recon & Scanning tab, against one target at a time:

• Run Recon - passive checks plus an nmap port/service scan.
• Vulnerability Identification - template-based detection via nuclei, with an optional severity filter (e.g. medium,high,critical) to narrow what gets checked.

A further set of buttons runs active testing - sending real payloads and checking the actual response, not just matching a signature:

• XSS - injects and verifies actual reflected payloads (via dalfox), not a pattern match.
• Access Control Test (IDOR) - fetches the same resources as two configured identities and flags responses that differ only by whose credentials were used. Requires both identities set up first, under Authenticated Scanning.
• SSTI, Path Traversal, XXE - injects known payload sets and checks for server-side evaluation or file disclosure, including an out-of-band callback for XXE cases that never return anything in the response body.
• SSRF - probes parameters that plausibly trigger a server-side fetch, using an out-of-band callback back to Siege's own public endpoint to catch blind cases too.
• CSRF - checks state-changing forms for a verifiable anti-CSRF token.
• Race Conditions - fires a burst of concurrent requests at race-prone endpoints (checkout, redemption, one-time actions) and flags more successes than a correctly-guarded endpoint should allow.
• JWT Analysis - decodes the engagement's configured bearer token, checks its claims, tests common weak HMAC secrets, and tests whether alg: none is accepted.
• GraphQL - checks common endpoint paths for introspection left enabled in production.
• WAF/CDN Fingerprint - identifies the vendor in front of the target from response headers and a blocked-request probe.
• Subdomain Takeover - enumerates subdomains via certificate transparency logs and flags any whose CNAME points at a de-provisioned third-party service.
• Secrets Scan - fetches every JavaScript file the page loads and checks it for hardcoded API keys, tokens, and credentials.
• OS Command Injection - injects sleep payloads and flags a response delay that scales with two independently-requested durations.
• Cloud Storage Exposure - checks AWS S3, Google Cloud Storage, and Azure Blob's public listing endpoints for buckets named after the target's own domain.
• Exposed Container/Orchestration APIs - checks for an unauthenticated Docker daemon API, Kubernetes kubelet API, or etcd.
• Breach Exposure Lookup - checks common role mailboxes (admin@, webmaster@, etc.) at the target's domain against Have I Been Pwned. Requires an HIBP API key, set at Settings → Organization → Integrations - returns a clear "not configured" result until one is saved.
• File Upload Validation - submits a harmless probe file (real image content, a dangerous extension) to every discovered upload form and flags one that accepts it. Not part of Run All Active Tests below - it uploads a real, self-identifying file to the target, so it's a deliberate, standalone action.
• Default Credentials - checks common admin paths that challenge with HTTP Basic Auth against a short list of default credential pairs. Deliberately never a login form, to avoid any account-lockout risk.

Run All Active Tests runs every scan above in sequence against one target (except File Upload Validation, run separately by design) - so you don't have to click through them individually, and one scan crashing doesn't stop the rest from running.

All of the above run in the background; watch progress in the History tab's live feed. Everything writes its results as Findings. Most active-testing results land at "possible" confidence pending human review; dalfox-verified XSS is the exception, reported as confirmed since it verified an actual reflected payload. Nothing here executes an exploit against the target beyond the payload needed to detect the issue itself.

Findings

The Findings tab lists everything detected so far, with severity, confidence, source, and target. Use the All / Needs Review / Confirmed filter to separate the "possible"-confidence heuristic hits that still need a human look from confirmed findings. A SQL injection indicator detected via passive recon gets a Propose Confirmation button right on its row - that's the on-ramp into the exploit-confirmation flow described next. Every other finding is informational at this stage; review it, and decide with your client whether it needs deeper manual work outside Siege.

Set CVSS on a finding row opens the standard 8-metric CVSS v3.1 calculator - Siege computes the base score with the official FIRST.org formula once you've made the calls only a human reviewing the finding in context can make; it's never auto-guessed. If your organization has a Jira, Linear, or GitHub token configured (Integrations in the rail), a matching Create Ticket button appears too - one click opens a real issue there with the finding's summary, and the button becomes View Ticket afterward so it's never created twice.

Exploit confirmation & approvals

Two independent paths land in the same place - the Exploitation tab:

SQL injection confirmation

Click Propose Confirmation on an eligible finding (in the Findings tab). Siege parses a boolean-based true/false payload pair from the finding's own evidence and creates a pending approval - it does not send anything yet.

Metasploit module confirmation

In the Exploitation tab's Metasploit panel: search modules by name, CVE, or product; pick one; fill in the target (and port, if relevant); Siege fetches that module's real options and its safe payloads only - single-shot command execution, never a persistent shell/meterpreter/reverse-connect family, regardless of what the module technically supports. Choose a payload and one of a fixed menu of proof commands (id, whoami, hostname, uname -a), then create the approval.

Metasploit's module database spans thousands of modules, most of them written for one specific product and version (a router model, a CMS plugin, an appliance firmware). Searching by keyword can surface a module that matches the vulnerability class but not the actual target - before approving, read the module description Siege shows at the proposal step; it names the exact product the module was written for. If an approved module is later rejected with "no job was created," that almost always means the module didn't apply to this target, not that Siege malfunctioned - pick a more generic module (or a different one matching the target's real product) and try again. A rejected Metasploit module also doesn't invalidate the underlying finding - if the finding already has its own passive evidence (e.g. a path traversal that already shows a file read), that evidence stands on its own and no Metasploit confirmation is required.

Metasploit data-gathering modules (Active Directory enumeration, etc.)

The same Metasploit panel also covers auxiliary and post modules - reconnaissance and enumeration actions (LDAP queries, Kerberoasting, and similar) that don't take a payload the way an exploit module does. Search and select one exactly like an exploit module; Siege recognizes it has no payload to choose and skips straight to creating the approval from its options alone. Still human-approval-gated, still re-checked against scope and the time window at execution time - the same rules as exploit confirmation, just without a payload step in between.

Deciding an approval

Anyone with an admin or operator account in your organization can review a pending approval - the exact request or module/payload/proof-command is shown in full - and Approve & Execute or Deny. Approving re-checks scope and the time window one more time before anything actually runs, in case either changed since the finding was proposed.

Reports

The Reports tab generates a narrative summary of an engagement's findings on demand, and a Download PDF Report button produces a formatted document with that narrative, the full findings table, and who actually did the testing (pulled automatically from the audit log, not typed in by hand).

White-label reports

By default every PDF carries Shieldome Siege's own branding. An organization admin can turn on white-label reports from Report Branding in the rail - upload your own logo, pick a header color, and set the company name shown on the report. Once enabled, Shieldome's own branding is dropped entirely, not co-branded - your client sees your name on it, not ours.

Client status link

Generate Client Status Link (also on the Reports tab) creates a no-login, read-only URL you can hand to your client so they can check progress themselves - finding counts by severity and a name/severity/status table, never evidence, PoC text, or anything from the Exploitation or History tabs. Rotate Link replaces it (the old URL stops working immediately); Revoke Link turns it off. The full technical report is still the PDF above, sent deliberately, not handed out through a standing link.

Notifications & ticket integrations

Slack & Discord notifications

From Integrations in the rail, an organization admin can paste a Slack incoming-webhook URL and/or a Discord webhook URL. Once saved, your workspace gets notified on:

• New findings at or above a severity threshold you choose (default: medium and up, to keep routine low/info recon noise out of the channel).
• An approval that needs a decision - the one notification that actually calls for someone to act.
• A decision being made, and an exploit confirmation finishing, with its result.

Use Send Test Notification to confirm a pasted webhook actually works before relying on it.

Ticket integrations

Also from Integrations: connect Jira (site URL, account email, API token, project key), Linear (API key, team ID), and/or GitHub Issues (personal access token, owner/repo) - any combination, independently. Once connected, a matching Create Ticket button appears on every finding row.

Breach exposure lookup

A Have I Been Pwned API key (also here) powers the Breach Exposure scan on the Recon & Scanning tab - see that tab's own section above for what it checks.

Single sign-on (OIDC)

From Single Sign-On in the rail, an organization admin can connect an identity provider (Okta, Azure AD/Entra, Google Workspace, or anything else that speaks OIDC) so your team signs in with it instead of a Siege password. That page shows your organization's own login URL and its own Organization ID - share both with your team, and give your identity provider the callback URL shown there too.

Scheduled scans

The Scheduled Scans panel at the top of Recon & Scanning lets you set any scan to run automatically against a target every N days, instead of clicking it by hand. A scheduled run uses the exact same code path as its own button - same scope check, same findings, same audit trail - just triggered by a timer instead of an operator. File upload testing can't be scheduled (it uploads a real file to the target, so it stays a deliberate, manual action); everything else can. Pause/Resume keeps a rule without deleting it; Delete removes it for good.

Triggering scans from a pipeline

From API Tokens in the rail, an organization admin can create a bearer token scoped to detection only - recon, vulnerability identification, and every active-testing scanner below. It never reaches exploit confirmation, which always stays human-approval-gated in the app regardless of how a scan was started. The full token is shown exactly once, at creation.

curl -X POST https://app.shieldomesiege.com/api/v1/engagements/<id>/recon \
  -H "Authorization: Bearer siege_..." \
  -H "Content-Type: application/json" \
  -d '{"target": "example.com"}'

The vulnerability-identification equivalent is the same shape, at /api/v1/engagements/<id>/vuln-id, and accepts an optional "severity" field to filter which Nuclei severity to run. Both return immediately with {"started": true, "target": "..."} - the scan runs in the background exactly as it would from the UI, and shows up in the same live feed and audit log, attributed to the token's name rather than a person.

Every other active-testing scanner is reachable the same way, at /api/v1/engagements/<id>/scans/<kind> - kind is the scan's short name (xss, ssti, cmdi, cloud_storage, and so on, matching the Recon & Scanning tab's own buttons). File upload testing isn't offered here, same reasoning as its exclusion from Run All and from scheduling.

GET /api/v1/engagements/<id>/findings reads findings back out as JSON - the other half of a fully API-driven integration, for a dashboard or pipeline step that needs to act on results rather than just trigger a scan.

A target outside the engagement's scope, or an engagement belonging to a different organization than the token's, behaves exactly as it does in the UI: rejected and logged, not silently skipped.

Platform admin guide

Creating an organization

From Platform Admin in the rail: set a name, choose a starting trust tier (recon_only or full), and create the organization's first admin account and password in the same step. There's no self-service signup - this is the only way a new tenant comes into existence.

Trust tier

recon_only organizations can run recon and vulnerability identification, but proposing any exploit confirmation is rejected outright. Raise an organization to full from the same organizations list once you're comfortable extending exploit access to them.

Dedicated worker VM

Every organization runs on the shared control-plane host by default, at no extra infrastructure cost. Toggling dedicated worker on for a specific organization gives it its own OVH VM for recon/exploit workloads instead - a real, recurring cost, so this is explicit and per-organization, never automatic. The VM provisions lazily on that organization's first action after being enabled, and idles down after inactivity.

Organization detail view

Click an organization's name in the list for its info, users, engagements, a merged cross-engagement activity feed, and OVH worker-VM usage in billed hours - infrastructure-cost visibility, not an invoice (Siege has no billing/payment system of its own).

FAQ

Can Siege run anything without a human approving it first?

Detection, yes - recon, vulnerability identification, and every active-testing scanner run within scope as soon as you start them (or on their own schedule), no separate approval needed. Exploitation is the line: every exploit confirmation - SQL injection or Metasploit - requires an explicit approval of the exact action about to run.

What happens if scope changes mid-engagement?

Every action re-checks scope and the time window at the moment it actually runs, not just when it was first proposed - a scope change or an engagement ending is caught even for a proposal that's been sitting pending for a while.

Can I export findings as something other than a PDF?

The full client-facing report is still PDF-only. Findings themselves can also be read as JSON through the API (GET /api/v1/engagements/<id>/findings) for your own tooling, and a read-only summary is available through a client status link - neither replaces the PDF as the formal deliverable.

Does connecting SSO automatically create accounts for anyone at my identity provider?

No. SSO only signs in an account that already exists in Siege, matched by email - add each person under Team first. Someone your identity provider would authenticate, but who has no matching Siege account, is turned away with a clear message, not signed in.

Can I trigger every scan type from a script, not just recon?

Yes - every active-testing scanner has an API equivalent at /api/v1/engagements/<id>/scans/<kind>, and scans can also run on a recurring schedule without any script at all. See the API and Scheduled Scans sections above.

Does the audit log ever get edited retroactively?

Every entry is hash-chained to the one before it; the Verify Audit Chain button re-derives every hash and reports the first point of divergence if anything was altered after the fact.

I forgot my password.

Ask your organization's admin to reset your account, or contact [email protected] if you're the only admin.