Fix every scan finding — step by step

SPF — Sender Policy Framework

SPF specifies which mail servers are authorised to send email on behalf of your domain. Missing or misconfigured SPF allows attackers to forge your address in phishing emails, bypass spam filters, and impersonate your brand.

1. Log into your DNS provider and create a TXT record for the root domain (@).
2. Set the value to: v=spf1 include:<your-mail-provider> -all — replace with your actual mail server (e.g. include:_spf.google.com for Google Workspace).
3. Use -all (hard fail) rather than ~all (soft fail) for strict enforcement — soft fail still lets spoofed email through in many configurations.
4. Ensure you do not have more than 10 DNS lookups in the SPF record or it will silently fail.
5. Validate with dig TXT yourdomain.com | grep spf or use an online SPF checker to confirm the record resolves correctly.

DMARC — Domain-based Message Authentication

DMARC builds on SPF and DKIM to instruct receiving mail servers what to do with emails that fail authentication — quarantine or reject them. Without DMARC, even a perfect SPF + DKIM setup cannot prevent spoofing at major mail providers.

1. Publish a TXT record at _dmarc.yourdomain.com.
2. Start with monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — this collects reports without affecting delivery.
3. After reviewing aggregate reports for 2–4 weeks, escalate to p=quarantine (moves failing mail to spam).
4. Once confident, move to p=reject — this fully blocks all spoofed emails pretending to be your domain.
5. Set pct=100 to apply the policy to all messages, not just a sample.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails so receiving servers can verify the message was not altered in transit and genuinely originates from your domain. It is required for DMARC alignment.

1. Generate a DKIM key pair in your email provider's admin panel (Google Workspace, Microsoft 365, Postfix, etc.).
2. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
3. Enable DKIM signing for outbound mail in your provider settings — this is usually a single toggle.
4. Test with dig TXT default._domainkey.yourdomain.com to confirm the DNS record is published.
5. Rotate DKIM keys annually as a security best practice to limit exposure if a key is compromised.

DNSSEC — DNS Security Extensions

DNSSEC adds cryptographic signatures to DNS records, preventing attackers from poisoning DNS caches and silently redirecting your visitors to malicious servers — a attack known as DNS hijacking or cache poisoning.

1. Enable DNSSEC in your DNS provider's control panel — most modern providers (Cloudflare, Route 53, Google Cloud DNS) support one-click activation.
2. Your registrar must support DS record delegation — check their documentation before enabling.
3. Copy the DS record generated by your DNS provider and add it at your domain registrar to complete the chain of trust.
4. Verify with dig +dnssec A yourdomain.com and look for the AD (Authenticated Data) flag in the response.
5. Monitor for key rollover — some providers automate this; others require manual renewal to prevent DNSSEC validation failures.

MX Records — Mail Exchanger

MX records define which servers receive email for your domain. Missing, incorrect, or misconfigured MX records cause email delivery failures — senders receive bounce messages and your domain effectively cannot receive email.

1. Add at least one MX record pointing to your mail server hostname — never point MX records directly at an IP address.
2. Ensure the target hostname has a valid A/AAAA record that resolves correctly.
3. Set a priority value: lower number = higher priority (e.g. 10 for primary, 20 for backup).
4. Test with dig MX yourdomain.com to confirm the records resolve as expected.
5. If using Google Workspace or Microsoft 365, follow their exact MX setup guide as these providers require specific records.

CAA Records — Certification Authority Authorization

CAA records specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. Without CAA, any CA can issue a certificate for your domain — a risk exploited in misissuance attacks.

1. Identify which CA issues your certificates (Let's Encrypt, DigiCert, Sectigo, etc.).
2. Add a CAA DNS record: 0 issue "letsencrypt.org" — replace with your CA's domain.
3. Add a wildcard record if your CA issues wildcard certs: 0 issuewild "letsencrypt.org".
4. Optionally add a violation report record: 0 iodef "mailto:security@yourdomain.com" to receive alerts if an unauthorised CA attempts issuance.
5. Verify with dig CAA yourdomain.com to confirm the records are published correctly.

BIMI — Brand Indicators for Message Identification

BIMI displays your company logo next to emails in supporting clients (Gmail, Apple Mail, Yahoo). It increases brand trust, improves email open rates, and signals to recipients that your email is legitimate.

1. BIMI requires a valid DMARC policy of p=quarantine or p=reject — set this up first.
2. Create an SVG logo in the BIMI-required format: square aspect ratio, under 32KB, using the SVG Tiny PS profile.
3. Host the SVG at a publicly accessible HTTPS URL (e.g. https://yourdomain.com/logo.svg).
4. Publish a TXT record at default._bimi.yourdomain.com with value: v=BIMI1; l=https://your-logo-url.svg.
5. For Gmail support, obtain a Verified Mark Certificate (VMC) from DigiCert or Entrust — this is a paid certificate that verifies logo ownership.

Email Authentication Summary

Email authentication (SPF + DKIM + DMARC) is the foundation of anti-phishing protection. Without all three, anyone can impersonate your domain in email — attackers regularly use this to target your customers and partners.

1. Implement SPF first: publish a v=spf1 include:... TXT record at the root domain.
2. Add DKIM: generate keys in your mail provider and publish the public key in DNS.
3. Add DMARC: publish _dmarc.yourdomain.com with p=none initially to monitor, then escalate.
4. Monitor DMARC aggregate reports (rua) for two weeks before tightening the policy.
5. Set p=reject as the final goal to block all spoofed emails pretending to be your domain.

Certificate Validity

An invalid or untrusted SSL/TLS certificate causes browsers to show hard security warnings that block access. Users cannot bypass these warnings easily, resulting in immediate traffic loss, user distrust, and SEO penalties.

1. Check the certificate chain with: openssl s_client -connect yourdomain.com:443 -showcerts
2. Ensure the certificate is signed by a trusted CA — self-signed certificates are not trusted by browsers.
3. Verify the certificate covers the exact domain name, including www if needed (or use a wildcard cert).
4. If expired or revoked, renew immediately via your CA or use Certbot (Let's Encrypt) for free automatic renewal.
5. Enable OCSP stapling on your web server to speed up revocation checking for visitors.

Certificate Expiry

An expired TLS certificate immediately breaks HTTPS for all visitors. Browsers display a full-screen hard error with no bypass option for end users — your site becomes effectively unreachable until the certificate is renewed.

1. Renew the certificate immediately — most CAs allow renewal 30 days before the expiry date.
2. Use Let's Encrypt with Certbot for free, automatically renewing certificates: certbot renew runs via cron.
3. Set a monitoring alert (PagerDuty, Datadog, UptimeRobot) to fire 30 and 7 days before expiry.
4. After renewal, restart your web server to load the new certificate: nginx -s reload or systemctl restart apache2.
5. Verify the new expiry with: openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Certificate Chain

An incomplete certificate chain means intermediate CA certificates are missing from your server's response. This causes validation failures in some browsers and mobile clients even if your leaf certificate is otherwise valid.

1. Download the full certificate chain bundle from your CA — it typically includes the leaf cert, all intermediate certs, and the root.
2. Nginx: use ssl_certificate pointing to the full chain file (concatenate leaf + intermediates in order).
3. Apache: use SSLCertificateChainFile pointing to the intermediate bundle.
4. Test with: openssl s_client -connect yourdomain.com:443 -verify_return_error — look for "Verify return code: 0 (ok)".
5. Use SSL Labs (ssllabs.com/ssltest) to verify chain completeness and get a full grade breakdown.

TLS Version

TLS 1.0 and 1.1 have known cryptographic vulnerabilities (POODLE, BEAST, ROBOT) and are deprecated by all major browsers. Supporting them exposes users to downgrade attacks and fails PCI-DSS compliance requirements.

1. Nginx: add ssl_protocols TLSv1.2 TLSv1.3; to your server block in nginx.conf.
2. Apache: add SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 to your SSL virtual host config.
3. IIS: disable TLS 1.0/1.1 via the Windows Registry or use IIS Crypto tool for a GUI approach.
4. Enable TLS 1.3 for the best performance — it removes legacy cipher suites and provides forward secrecy by design.
5. Test with SSL Labs to confirm old versions are disabled and the grade reflects the change.

SSL Grade

SSL Labs grades measure the overall quality of your TLS configuration. A grade below A indicates configuration weaknesses — weak cipher suites, short key sizes, or missing modern features — that are exploitable by determined attackers.

1. Run a full SSL Labs test at ssllabs.com/ssltest to get a breakdown of exactly what is lowering your grade.
2. Disable weak cipher suites: RC4, 3DES, export ciphers, and anonymous ciphers must all be removed.
3. Use only strong ciphers — prioritise ECDHE for key exchange to achieve forward secrecy.
4. Use a 2048-bit RSA key minimum; 4096-bit or ECDSA P-256 is recommended for new deployments.
5. Enable HSTS to prevent protocol downgrade attacks, which is required for an A+ grade.

SSL/TLS Setup

TLS encrypts data in transit between your server and users. Without it, credentials, session tokens, form data, and sensitive content are transmitted in plaintext and can be intercepted by anyone on the same network.

1. Install a TLS certificate using Let's Encrypt (free) via Certbot: sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
2. Ensure HTTPS is enforced with a 301 permanent redirect from HTTP to HTTPS on all pages.
3. Configure HSTS to prevent downgrade attacks after enforcing HTTPS.
4. Disable TLS 1.0/1.1 — only allow TLS 1.2 and 1.3.
5. Verify the full setup with SSL Labs and target grade A or A+.

HSTS — HTTP Strict Transport Security

HSTS instructs browsers to always use HTTPS for your domain, preventing man-in-the-middle attacks that strip HTTPS from the initial request. Without HSTS, the very first HTTP request before a redirect is unprotected.

1. Add the header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
2. Start with a short max-age (86400 = 1 day) to test, then increase to 31536000 (1 year) once confirmed working.
3. Add includeSubDomains only after confirming all subdomains support HTTPS — otherwise it will break non-HTTPS subdomains.
4. Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
5. Submit your domain to the HSTS preload list at hstspreload.org for browser-level enforcement before any HTTP request is made.

Content Security Policy (CSP)

CSP is a browser security mechanism that mitigates Cross-Site Scripting (XSS) attacks by declaring exactly which sources of scripts, styles, images, and other resources are trusted. It is the single most powerful anti-XSS control available.

1. Start with report-only mode to understand your existing resource sources: Content-Security-Policy-Report-Only: default-src 'self'
2. Review the violation reports to identify all CDNs, analytics providers, and fonts your site uses.
3. Build the allowlist: Content-Security-Policy: default-src 'self'; script-src 'self' cdn.yourtrustedprovider.com
4. Avoid 'unsafe-inline' and 'unsafe-eval' — refactor inline scripts to external files or use nonces.
5. Use a nonce or hash for any necessary inline scripts, and test with csp-evaluator.withgoogle.com before deploying to production.

X-Frame-Options

X-Frame-Options prevents your site from being embedded in iframes on other domains, blocking clickjacking attacks where attackers overlay your interface with a transparent frame to trick users into performing unintended actions.

1. Add the header: X-Frame-Options: DENY to block all framing, or SAMEORIGIN to allow framing only from your own domain.
2. Nginx: add_header X-Frame-Options "DENY" always;
3. Apache: Header always set X-Frame-Options "DENY"
4. Alternatively, use the CSP frame-ancestors directive which is more flexible: Content-Security-Policy: frame-ancestors 'none'
5. Verify headers are present on all responses using browser devtools or curl -I https://yourdomain.com.

X-Content-Type-Options

X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing response bodies. Without it, browsers may execute a response as a different content type than declared — allowing attackers to serve malicious scripts disguised as images or text files.

1. Add the header: X-Content-Type-Options: nosniff — there is only one valid value.
2. Nginx: add_header X-Content-Type-Options "nosniff" always;
3. Apache: Header always set X-Content-Type-Options "nosniff"
4. Ensure all responses serve the correct Content-Type for their actual file type — this header enforces those declarations.
5. This header has no downside and should always be set — it is a zero-cost hardening step.

Referrer-Policy

Referrer-Policy controls how much referrer information is included in outgoing requests. Without it, sensitive URL parameters — auth tokens, user IDs, internal paths — can leak to third-party analytics, ad platforms, or CDN servers.

1. Set: Referrer-Policy: strict-origin-when-cross-origin — this is the recommended default that balances privacy with analytics needs.
2. For high-privacy apps, use no-referrer or same-origin to prevent any referrer leakage.
3. Nginx: add_header Referrer-Policy "strict-origin-when-cross-origin" always;
4. Apache: Header always set Referrer-Policy "strict-origin-when-cross-origin"
5. Avoid unsafe-url which sends the full URL including query strings to every external site your page references.

Permissions-Policy

Permissions-Policy (formerly Feature-Policy) restricts which browser features your pages can use or grant to embedded iframes. Without it, any embedded iframe can request access to the camera, microphone, or geolocation on behalf of your site.

1. Enumerate which browser features your site actually uses (camera, microphone, geolocation, payment, etc.).
2. Disable all features you do not use: Permissions-Policy: camera=(), microphone=(), geolocation=()
3. If you use specific features, restrict to same-origin: geolocation=(self)
4. Nginx: add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
5. Use the Permissions Policy Playground to generate and test your policy before deploying.

CORS — Cross-Origin Resource Sharing

CORS controls which external origins can make requests to your API. A misconfigured CORS policy — especially Access-Control-Allow-Origin: * on authenticated endpoints — can expose your entire API to any website on the internet.

1. Never use Access-Control-Allow-Origin: * on endpoints that process cookies, session tokens, or sensitive data.
2. Maintain an explicit allowlist of trusted origins and validate incoming Origin headers against it server-side.
3. Do not simply reflect arbitrary Origin headers back without validation — this is a common misconfiguration.
4. Set Access-Control-Allow-Credentials: true only with a specific origin, never combined with a wildcard.
5. Restrict Access-Control-Allow-Methods to only the HTTP methods your API actually uses (GET, POST, etc.).

Security Headers Overview

HTTP security headers are a server-side configuration layer that instructs browsers to enforce security policies. A single block of header configuration can dramatically reduce the impact of XSS, clickjacking, MIME sniffing, and information disclosure attacks.

1. Add at minimum: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy to all HTTP responses.
2. Configure headers at the web server layer (Nginx/Apache) so they apply to all responses — not just pages served by your application.
3. Avoid setting duplicate or conflicting header values across server config and application code.
4. Add Permissions-Policy and remove information-leaking headers: Server, X-Powered-By, X-AspNet-Version.
5. Retest with a security header scanner after every change and aim for an A or A+ rating.

HTTP Security Configuration

General HTTP security encompasses response headers, server configuration, and protocol settings that harden your web server against common browser-based and network attacks. It is the foundation every other security control builds on.

1. Add all recommended security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy — these are the baseline.
2. Remove headers that leak server information: suppress Server, X-Powered-By, and X-Generator from all responses.
3. Disable the HTTP TRACE method to prevent cross-site tracing (XST) attacks: TraceEnable off in Apache, or limit_except in Nginx.
4. Enable session cookie security: all cookies must have the HttpOnly and Secure flags set.
5. Set SameSite=Strict or SameSite=Lax on session cookies to prevent CSRF attacks.

CMS Version

Running an outdated CMS (WordPress, Drupal, Joomla) or framework with known CVEs is one of the most common root causes of web compromise. Automated scanners identify vulnerable versions within hours of a CVE publication.

1. Identify your CMS version and check the vendor's security advisories for known issues.
2. Update to the latest stable version immediately — most CMS platforms provide one-click updates.
3. Enable automatic security updates where available (WordPress: auto-update core + plugins in wp-config.php).
4. Remove unused plugins, themes, and modules — inactive extensions still represent attack surface and are rarely patched.
5. Hide the version number from HTTP headers and HTML source: remove generator meta tags and suppress version query strings.

Server Header Disclosure

The Server response header reveals your web server software and version (e.g. nginx/1.14.0), giving attackers an immediate head start in identifying relevant CVEs to exploit without any additional reconnaissance.

1. Nginx: add server_tokens off; to the http block in nginx.conf — removes the version from the Server header.
2. Apache: set ServerTokens Prod and ServerSignature Off in httpd.conf.
3. IIS: use URL Rewrite or a custom response headers module to suppress or replace the Server header.
4. Also suppress X-Powered-By, X-AspNet-Version, and X-Generator headers using the same server config.
5. Verify with: curl -I https://yourdomain.com — none of Server, X-Powered-By, or version strings should be visible.

Software Disclosure

Software disclosure means your application reveals technology stack details — PHP version, framework names, CMS type — in headers, HTML source, or error pages. Attackers use this to fingerprint your infrastructure and look up targeted CVEs.

1. PHP: set expose_php = Off in php.ini to remove the X-Powered-By: PHP/x.x.x header.
2. Node.js/Express: call app.disable('x-powered-by') to suppress the Express identifier header.
3. ASP.NET: remove the X-Powered-By and X-AspNet-Version headers from web.config.
4. Suppress version strings from error pages — ensure custom 404/500 pages do not reveal technology details.
5. Review HTML source for generator meta tags (WordPress, Drupal, etc.) and remove them via your CMS settings or theme.

CVE Exposure

Exposed CVEs mean your running software has known, publicly-disclosed vulnerabilities. CVE databases are indexed by automated scanners — your specific CVEs may already have public exploit code, making exploitation trivial for low-skilled attackers.

1. Look up each CVE ID from the scan report on the National Vulnerability Database (nvd.nist.gov) to understand severity and impact.
2. Prioritise CVSS ≥ 7.0 (High/Critical) for immediate patching — these are the ones with working exploits in the wild.
3. Update affected software components as quickly as possible — the patch is almost always a version upgrade.
4. If a patch is not yet available, apply vendor-recommended mitigations: WAF rules, config hardening, or disabling the affected feature.
5. Implement a vulnerability management cadence: scan → triage by severity → patch → verify the fix with a rescan.

Active CVE Validation (Nuclei)

SwarmHawk runs 3,000+ active nuclei templates against every domain — not just version lookups. Each template sends a real HTTP/TCP request and checks the response for proof that a specific vulnerability is exploitable. This eliminates false positives from passive NVD version-range matching and surfaces confirmed CVEs, exposed admin panels, misconfigurations, and default credentials that are actually reachable from the internet.

Nuclei results appear in the Checks tab under the "Active CVE Validation" group — the first section in the list. When findings exist, click the row to expand a structured findings table showing:

• Severity badge — Critical (red), High (orange), Medium (yellow), Low/Info (grey)
• Finding name — the nuclei template that matched (e.g. "Apache Log4j RCE")
• CVE ID — e.g. CVE-2021-44228, if the template maps to a known CVE
• CVSS score — numeric severity from 0.0–10.0

The summary line above the table shows the max CVSS and total finding count. Up to 20 findings are displayed in the expanded card; all findings contribute to the score regardless.

The nuclei check contributes a score_impact penalty to the overall risk score (0–100, higher = more risk) based on the worst findings confirmed:

Findings confirmed	Score impact formula	Max penalty
Critical findings	crits × 10 + highs × 5	+25 pts
High findings only	highs × 5	+15 pts
Medium findings only	mediums × 3	+8 pts
Low / Info / None	0	0 pts

In the Score Breakdown panel (next to the hero score), nuclei's penalty rolls up into the CVE & AppSec bar alongside passive CVE correlation, SCA, SAST, IAC, and DAST checks. The Total shown always equals the authoritative backend risk score.

1. Check the CVE ID in the finding (e.g. CVE-2024-1709) on nvd.nist.gov — read the description and look at the CVSS score and attack vector.
2. Check whether the CVE is in the CISA KEV catalog — if it is, treat it as an active threat and patch immediately (attackers are exploiting it today).
3. The matched URL in the finding detail shows exactly which endpoint is vulnerable — patch or restrict access to that specific path first.
4. Update the affected software component. The fix is almost always a version upgrade — check the vendor's security advisory linked from the NVD entry.
5. If no patch exists yet, apply vendor mitigations: WAF rules blocking the vulnerable path, rate limiting on the endpoint, or disabling the feature entirely until a patch ships.
6. Re-scan after patching. Nuclei will confirm the finding is gone — the matched URL should no longer return the exploit signature.

CMS Fingerprinting

Disclosing your CMS name and version in HTTP headers or HTML source lets attackers instantly target known CVEs without any manual reconnaissance. Even knowing it's WordPress vs. Drupal helps attackers choose the right exploit kit.

1. Nginx: set server_tokens off; to suppress the Server header version string.
2. Apache: set ServerTokens Prod and ServerSignature Off to hide the version.
3. PHP: set expose_php = Off in php.ini to remove X-Powered-By: PHP/x.x.
4. WordPress: remove the generator meta tag with add_filter('the_generator', '__return_empty_string') and disable ?ver= query strings on assets.
5. Node/Express: call app.disable('x-powered-by'). Verify with curl -I https://yourdomain.com — none of Server, X-Powered-By, or X-Generator should reveal versions.

Web Application Firewall (WAF)

A WAF filters malicious HTTP traffic — SQL injection, XSS, remote code execution attempts — before it reaches your application. It provides a critical additional defence layer, especially for applications that cannot be patched immediately.

1. If using a CDN, enable their WAF product — Cloudflare WAF (free tier available), AWS WAF, Fastly WAF are all strong options.
2. For self-hosted applications, deploy ModSecurity (open source) with the OWASP Core Rule Set as a starting point.
3. Start in detection/logging mode before enabling blocking — this lets you identify false positives without disrupting legitimate traffic.
4. Tune rules to reduce false positives over the first 1–2 weeks before switching to active blocking mode for production traffic.
5. Monitor WAF logs regularly for attack patterns and adjust rules to block new attack vectors as they emerge.

Open Ports

Unnecessary open ports increase your attack surface. Every exposed service is a potential entry point — particularly if it runs outdated software, uses default credentials, or lacks authentication entirely.

1. Audit all open ports with: nmap -sV -p- yourdomain.com to get a full picture of what is exposed.
2. Close or firewall any ports not required for the service's function — the default stance should be deny-all, allow-specific.
3. Restrict administrative ports (SSH/22, RDP/3389, databases/3306/5432) to specific IP allowlists or a VPN.
4. Move SSH to a non-standard port as a basic noise reduction measure against automated scanners.
5. Use a host-based firewall (ufw, iptables, nftables) as a second layer behind your network or cloud firewall.

Admin Panel Exposure

Publicly accessible admin panels (/wp-admin, /admin, phpMyAdmin) are aggressively targeted by automated scanners running 24/7. A single weak password is all an attacker needs to gain full control of your site or server.

1. Restrict the admin path to specific IP addresses via your firewall or web server config — only trusted IPs should ever reach it.
2. Enable multi-factor authentication (MFA/2FA) on all admin accounts without exception.
3. Rename or move the default admin path if your CMS supports it — obscurity is not security but reduces automated attack noise.
4. Implement login rate limiting and account lockout after N failed attempts to prevent brute-force attacks.
5. Set up an alert for any login attempt from an unexpected IP address or country.

Directory Listing

Directory listing allows anyone to browse your file system through a web browser, potentially exposing configuration files, backup archives, database dumps, credentials, and source code to unauthenticated users.

1. Nginx: ensure autoindex off; is set — it is the default but verify it has not been enabled explicitly in a virtual host config.
2. Apache: add Options -Indexes to your Directory block or .htaccess file in the web root.
3. Remove or relocate sensitive files from the web root: backups, .env files, .git directories, database exports.
4. Set up a catch-all rule to return 403 for any directory access that does not have an index.html or equivalent file.
5. Scan with a tool like gobuster or dirb to confirm no directories are browsable after the fix.

Critical Port Exposure

Database ports, caches, and admin services accessible from the internet are immediate critical risks. Shodan and other scanners index these within minutes of exposure — attackers actively scan for them 24/7 and have automated exploit tooling ready.

1. Immediately firewall database ports: MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379), Elasticsearch (9200) — these must never be internet-facing.
2. Restrict RDP (3389), VNC (5900), and Docker API (2375) to specific IP allowlists or a VPN-only access path.
3. Use your cloud provider's security group or firewall rules to implement deny-all inbound, then explicitly allow only required ports.
4. Place development servers, Jupyter Notebooks (8888), and management UIs behind authentication and restrict them to the internal network.
5. Run a periodic port scan (nmap -sV -p- yourdomain.com) and subscribe to SwarmHawk continuous monitoring to detect drift.

Subdomain Exposure

Exposed subdomains expand your attack surface. Development, staging, and admin subdomains often run older software, weaker credentials, and lack the security hardening applied to production — making them a preferred entry point for attackers.

1. Audit every discovered subdomain — verify it is intentionally public, patched, and serves a current business purpose.
2. Decommission or firewall dev/staging/test/demo subdomains that do not need to be internet-facing.
3. Ensure all public subdomains use HTTPS and are covered by your security headers policy — not just the main domain.
4. Add admin and internal subdomains to an IP allowlist or protect them with VPN or SSO authentication.
5. Subscribe to Certificate Transparency log alerts (via crt.sh or Cloudflare CT Monitor) to detect new subdomains as they are issued certificates.

Shodan Exposure

Shodan continuously indexes internet-facing services and their banners. If Shodan has findings for your IPs, attackers already know about these services and associated CVEs — the information is publicly available and actively used by exploit frameworks.

1. Review the specific findings in your SwarmHawk report — each Shodan finding lists the port, service, and any associated CVEs.
2. Close or firewall any exposed services that should not be internet-facing — prioritise database ports and management UIs first.
3. Update software on any services with associated CVEs — the patch is almost always a version upgrade.
4. Put sensitive services behind a VPN or allowlist specific IPs to prevent them from appearing in Shodan scans in the future.
5. Consider Shodan Monitor alerts (free tier available) for ongoing notification of new exposures on your IP ranges.

VirusTotal Detection

VirusTotal aggregates detections from 70+ antivirus engines and URL scanners. A positive detection means your domain or IP is flagged as malicious by at least one vendor — this can cause browser warnings, email blocking, and search engine penalties.

1. Review the specific engines that flagged your domain and the reason given — malware hosting, phishing, unwanted software, etc.
2. If flagged for malware hosting: scan your server with a security scanner (Sucuri SiteCheck, Wordfence) and remove all injected code.
3. If flagged for phishing: review your site content and submit a false-positive dispute directly to the flagging vendor.
4. Request a re-analysis on VirusTotal after completing remediation — most engines update within 24–48 hours.
5. Monitor ongoing with SwarmHawk scanning to catch new flagging events before they impact users.

URLhaus Listing

URLhaus tracks domains and URLs actively used to distribute malware. If your domain appears here, it has been weaponised — either your server was compromised and is serving malware, or your domain was abused by attackers without direct server access.

1. Review the specific flagged URLs in your SwarmHawk report to understand which pages or paths are implicated.
2. Perform a thorough server audit: check for web shells, injected code, unexpected PHP files, and recently modified files.
3. Review web server access logs for suspicious requests, unusual file upload patterns, and outbound connections to attacker infrastructure.
4. Restore clean files from a verified good backup if a compromise is confirmed — do not just delete the malicious files, as backdoors are often left behind.
5. Contact abuse.ch to request removal after your domain is confirmed clean, and set up monitoring to detect re-compromise.

Spamhaus Blocklist

Spamhaus maintains block lists (SBL, DBL, XBL) used by email servers worldwide. Being listed means many organisations block your outbound email entirely — affecting both transactional email and marketing campaigns.

1. Check your IP and domain at the Spamhaus lookup tool to identify which list you appear on and the listing reason.
2. Identify the root cause: spam sending, malware hosting, compromised server, botnet command-and-control activity.
3. Resolve the underlying issue completely before requesting removal — re-listing occurs quickly if the problem persists.
4. Submit a removal request via the Spamhaus website once the issue is resolved and remediation is complete.
5. Implement SPF, DKIM, and DMARC to reduce future listing risk and signal to mail providers that your domain is properly managed.

Google Safe Browsing

Google Safe Browsing flags sites that serve malware, phishing content, or unwanted software. A listing triggers full-page interstitial warnings in Chrome, Firefox, and Safari — effectively blocking your site for the majority of internet users.

1. Check the exact flagging reason via Google's Transparency Report to understand what triggered the warning.
2. If flagged for malware: scan your site with a security scanner, remove all malicious code, scripts, or redirect rules inserted by attackers.
3. If flagged for phishing: review all your site's content and forms, remove any pages that could be mistaken for impersonation.
4. Request a review via Google Search Console (Security Issues report) after completing remediation.
5. Google typically lifts warnings within 24–72 hours of a successful review — monitor the Security Issues report for confirmation.

Typosquatting

Typosquatting domains mimic your brand with slight misspellings or alternate TLDs. Attackers use them to intercept users who mistype your domain, run phishing campaigns against your customers, or distribute malware under your brand name.

1. Register common misspellings of your domain proactively — prioritise .com, .co, .net, and your country TLD variants.
2. Set up redirects from all registered variants to your canonical domain so any traffic lands on the legitimate site.
3. File UDRP (Uniform Domain-Name Dispute-Resolution Policy) complaints for domains that are clearly abusive — ICANN provides a standardised process.
4. Set up brand monitoring alerts to notify you when new domains similar to yours are registered (certificate transparency logs are a good source).
5. Ensure your DMARC policy (p=reject) prevents phishing emails sent from typosquat domains from reaching your customers.

IP Intelligence

IP intelligence checks whether your server IPs appear on threat intelligence feeds as sources of malicious activity, botnet command-and-control nodes, or known-bad hosting. A listed IP can cause email blocking, API rate limiting, and CDN access denial.

1. Look up each server IP on AbuseIPDB and similar threat intel services to see the listing reason and evidence.
2. If listed for malicious activity: investigate whether your server was compromised or used as a relay/proxy without your knowledge.
3. Review server logs for anomalous outbound traffic, unexpected processes, or connections to known-malicious IPs.
4. Submit delisting requests to each intel provider after cleaning the server and confirming the malicious activity has stopped.
5. Consider migrating to a new IP range if the previous IP has a persistent reputation issue that cannot be resolved through delisting.

Datacenter & Hosting Location

SwarmHawk resolves each domain to its actual server IP and enriches it with city-level geolocation and hosting provider identification (ASN/organisation). This tells you exactly which datacenter and cloud provider hosts the domain — not just the country, but the specific facility: AWS us-east-1 in Ashburn, Cloudflare edge in Frankfurt, OVH Roubaix, Hetzner Falkenstein, etc. This information is critical for NIS2 compliance (supply chain risk), incident response, and understanding your attack surface.

• Resolved IP — the actual server IP address the domain resolves to at scan time
• City / facility — city-level geolocation of the datacenter (e.g. Ashburn, Frankfurt, London)
• Hosting provider / ASN — the autonomous system and organisation name (AWS, Cloudflare, OVH, Hetzner, DigitalOcean, etc.)
• Map precision — visible as a datacenter-precision dot on the SwarmHawk threat map when zoomed in to level 5

1. NIS2 / supply chain risk — if a third-party vendor hosts on a sanctioned cloud, in a high-risk jurisdiction, or on infrastructure shared with known-malicious actors, that is a supply chain exposure you must disclose.
2. Incident response — knowing the exact datacenter means you can contact the hosting provider's abuse team directly and know which jurisdiction's law enforcement to notify.
3. Geo-fencing and compliance — GDPR and sector-specific regulations often require data to remain within specific regions. Hosting location verification is the first step.
4. Shared hosting risk — residential or cheap shared-hosting IPs are more likely to be flagged on threat intel feeds, causing collateral blocking of your emails and API calls.

1. Run dig +short yourdomain.com to see the current A record IP.
2. Look up the IP on bgp.he.net or ipinfo.io to get the ASN, organisation, and city.
3. For CDN-fronted domains (Cloudflare, Fastly, Akamai) the resolved IP is the edge node — the origin server may be in a different location behind the CDN.
4. Check Shodan for open ports and services running on the resolved IP to understand the full hosting footprint.

Credential Leaks

Credential leaks mean email addresses or password hashes from your domain have appeared in known data breaches. Attackers use these in automated credential stuffing attacks — testing leaked passwords against your login endpoints at scale.

1. Identify all affected email addresses from the breach data and force a mandatory password reset for those accounts immediately.
2. Enable multi-factor authentication (MFA) for all accounts — a leaked password is useless if a second factor is required.
3. Integrate a breach monitoring API (HaveIBeenPwned API) into your sign-up/login flow to warn users when they reuse a breached password.
4. Enforce strong unique password requirements and consider implementing a password manager recommendation during signup.
5. Add dark web monitoring for your domain via a threat intelligence service to receive early warning of future breaches.

DAST — Dynamic Application Security Testing

DAST runs live attack simulations against your running application to find exploitable vulnerabilities like SQL injection, XSS, IDOR, and broken authentication. Unlike static analysis, DAST tests the actual behaviour of your application under attack conditions.

1. Run OWASP ZAP or Burp Suite against a staging environment that mirrors production — never run DAST directly against a live production database.
2. Fix any High/Critical severity findings before deploying to production — these have working exploit paths.
3. Address XSS findings by implementing CSP and output-encoding all user-supplied data before rendering it in HTML.
4. Address SQL injection findings by using parameterised queries or an ORM throughout — never interpolate user input into SQL strings.
5. Integrate DAST into your CI/CD pipeline for continuous coverage — schedule automatic scans on every deployment to a staging environment.

Injection (OWASP A03:2021)

Injection flaws occur when untrusted data is sent to an interpreter — SQL, OS, LDAP, template engines — as part of a command or query. SwarmHawk detects injection risk passively and safely: it checks HTTP responses for SQL error messages and stack traces, counts injectable input surfaces, and probes error paths for verbose disclosures. No destructive payloads are ever sent.

• SQL error disclosure — MySQL, PostgreSQL, Oracle, MS SQL, SQLite error strings in responses
• Debug / stack trace disclosure — Python tracebacks, Werkzeug debugger, Django debug mode, Laravel Whoops, .NET yellow screen, Java stack frames
• Injectable input surfaces — count of unprotected text/textarea/email inputs on the main page
• Error verbosity on 404 — crafted path probed to see if the error handler leaks framework or database details

Finding	Impact
SQL error or interactive debugger in response	Critical — up to +20 pts
Stack trace / debug info disclosed	Warning — up to +10 pts
Multiple injectable surfaces, no errors	Warning — up to +5 pts

1. Disable debug mode in production — set DEBUG=False (Django), APP_DEBUG=false (Laravel), or remove app.run(debug=True) (Flask).
2. Use parameterised queries / prepared statements for all database access — never interpolate user input into SQL strings.
3. Enable generic error pages for 4xx/5xx — map all exceptions to a plain "Something went wrong" page. Log details server-side, never send to the client.
4. Use an ORM with auto-escaping (SQLAlchemy, Hibernate, ActiveRecord) rather than raw query strings.
5. Apply input validation at all entry points using an allowlist approach — reject characters that have no business reason to appear in a field.
6. For template engines, use auto-escaping and avoid rendering user input directly into templates without sanitisation.

Authentication Failures (OWASP A07:2021)

Broken authentication allows attackers to compromise passwords, keys, or session tokens — taking over user accounts or gaining admin access. SwarmHawk checks session cookie security flags, login form hardening signals, brute-force protection, and whether sensitive admin panels are reachable without authentication.

• Cookie security flags — HttpOnly (prevents XSS cookie theft), Secure (HTTPS-only transmission), SameSite (CSRF protection)
• Login form hardening — autocomplete="off" on password fields, presence of CAPTCHA or rate-limit headers
• Unauthenticated admin panels — /admin, /wp-admin, /phpmyadmin, /adminer, /manager reachable with a 200 response without credentials
• HTTP Basic auth — base64-only credential protection (trivially captured on the network)
• Password reset exposure — reset forms that may allow account enumeration via differential responses

Finding	Impact
Admin panel open without auth	Critical — up to +20 pts
Insecure cookie flags (HttpOnly/Secure/SameSite missing)	Warning — up to +12 pts
No CAPTCHA/rate-limit on login, autocomplete enabled	Warning — up to +6 pts

1. Set all session cookies with HttpOnly; Secure; SameSite=Lax (or Strict). In Express: cookie: { httpOnly: true, secure: true, sameSite: 'lax' }. In Django: SESSION_COOKIE_HTTPONLY = True, SESSION_COOKIE_SECURE = True, SESSION_COOKIE_SAMESITE = 'Lax'.
2. Add CAPTCHA (reCAPTCHA v3, hCaptcha, Cloudflare Turnstile) to login and password-reset forms.
3. Implement account lockout after 5–10 failed attempts, plus rate limiting with exponential backoff.
4. Add autocomplete="new-password" to password fields in login forms to prevent browser credential caching in shared environments.
5. Protect admin panels behind VPN, IP allowlist, or a second authentication factor (MFA) — never expose them to the open internet.
6. Return identical responses for valid and invalid usernames on password reset to prevent account enumeration.
7. Enforce MFA for all admin accounts and privileged users — hardware keys (WebAuthn/FIDO2) are strongest, TOTP is acceptable.

Software & Data Integrity (OWASP A08:2021)

Integrity failures occur when code or infrastructure is loaded from untrusted sources without verification — CDN scripts without SRI hashes, exposed dependency manifests, unsigned CI/CD pipelines. An attacker who compromises a CDN or package registry can silently inject malicious code into your application. SwarmHawk checks whether external resources are cryptographically pinned and whether your dependency files are publicly accessible.

• Subresource Integrity (SRI) — external CDN scripts and stylesheets (jsDelivr, cdnjs, unpkg, jQuery CDN, Bootstrap CDN, Google APIs) without an integrity="sha384-..." attribute
• Exposed dependency manifests — package.json, package-lock.json, yarn.lock, requirements.txt, Pipfile, Gemfile, composer.json, go.sum, Cargo.lock, .npmrc
• Exposed build configs — go.mod, Cargo.toml, pom.xml, build.gradle (expose full technology and version stack)

Finding	Impact
Exposed lockfile / manifest (package-lock.json, yarn.lock, etc.)	Critical — up to +20 pts
CDN resources without SRI integrity attribute	Warning — up to +10 pts

1. Add SRI to all external CDN scripts and stylesheets. Generate the hash at srihash.org: <script src="https://cdn.example.com/lib.js" integrity="sha384-abc..." crossorigin="anonymous"></script>
2. Block access to manifest and lockfiles via your web server. Nginx: location ~* ^/(package\.json|yarn\.lock|requirements\.txt|Pipfile|composer\.lock|go\.sum)$ { deny all; }
3. For static site deployments, ensure your build pipeline doesn't copy package.json or lockfiles into the public document root.
4. Set a strict Content-Security-Policy with require-sri-for script style to enforce SRI on all subresources browser-side.
5. Pin dependencies in your CI/CD pipeline using exact version lockfiles and verify checksums on every build — never use latest or wide version ranges in production.
6. Protect .npmrc especially — it may contain registry auth tokens. Rotate any tokens if exposure is confirmed.

Server-Side Request Forgery (OWASP A10:2021)

SSRF flaws let attackers trick the server into making HTTP requests to internal infrastructure — cloud metadata endpoints (169.254.169.254), internal databases, or other microservices that aren't internet-facing. It's a critical stepping stone to full cloud compromise. SwarmHawk detects SSRF-prone endpoints, URL-accepting parameters, and confirmed open redirects — without sending any payloads to internal addresses.

• SSRF-prone endpoints — /proxy, /fetch, /url, /redirect, /open, /image, /download, /webhook, /callback and API equivalents
• URL parameters in page links — ?url=, ?link=, ?redirect=, ?next=, ?return=, ?dest=, ?image=, ?webhook=, ?callback= and similar
• Open redirect confirmation — crafted request to redirect-accepting paths with a safe external target (example.com) to confirm unvalidated redirect behaviour
• Webhook/callback endpoints — any endpoint that accepts an arbitrary URL for server-side callbacks

Finding	Confidence	Impact
Confirmed open redirect — crafted request redirects to external host	confirmed	Critical — up to +20 pts
SSRF-prone endpoint paths present (/proxy, /fetch, /redirect …)	informational	0 pts — surface indicator only
URL-accepting parameters in page links (?url=, ?redirect= …)	informational	0 pts — surface indicator only
Webhook/callback endpoints found	informational	0 pts — surface indicator only

Confidence tiers: SwarmHawk distinguishes between confirmed findings (active proof, score penalty applies) and informational findings (attack surface indicators that warrant manual review but do not in themselves prove a vulnerability). Informational findings appear in a collapsed "Surface Area Indicators" section and carry zero score penalty.

1. Implement a strict URL allowlist for any server-side URL fetching — only allow known-good domains and reject private IP ranges (10.x, 172.16–31.x, 192.168.x, 169.254.x, ::1, localhost).
2. Block requests to cloud metadata endpoints. AWS: block 169.254.169.254. GCP: block metadata.google.internal. Azure: block 169.254.169.254. Use IMDSv2 with required session tokens on AWS.
3. Replace open redirect patterns: instead of /redirect?url=X use opaque tokens (/redirect?token=abc) that map to a pre-approved URL server-side.
4. Validate webhook URLs against an allowlist of known integration partners before storing or calling them.
5. Use a dedicated outbound proxy with egress filtering for all server-initiated HTTP requests — the proxy enforces allowlists even if application-level validation is bypassed.
6. Disable unnecessary URL-fetching features entirely if they aren't core functionality (image proxies, link previews, RSS feeds).

Broken Access Control (OWASP A01:2021)

Broken access control is the most common web application vulnerability. It occurs when users can act outside their intended permissions — accessing admin panels without authentication, browsing directory listings, calling APIs without authorisation, or exploiting permissive CORS to read data cross-origin. SwarmHawk maps several existing checks directly to A01 surface.

• admin_panel — probes /admin, /wp-admin, /phpmyadmin, /adminer, /console for unauthenticated 200 responses
• directory_listing — detects web server directory browsing on /, /uploads, /static, /backup and similar paths
• cors — checks Access-Control-Allow-Origin for wildcard (*) or reflected arbitrary origins on authenticated endpoints
• open_ports — surfaces management interfaces (Kubernetes API :6443, Etcd :2379, Redis :6379, MongoDB :27017) reachable from the internet without auth

Finding	Impact
Admin panel reachable without authentication	Critical — up to +20 pts
Directory listing enabled (path traversal, file enumeration)	Critical — up to +20 pts
CORS misconfiguration (wildcard or reflected origin)	Warning — up to +10 pts
Management ports open without authentication	Warning — per open port

1. Move admin interfaces behind VPN or IP allowlist — they must never be reachable from the public internet without network-level access control.
2. Disable directory listing on your web server: Nginx — remove autoindex on; Apache — add Options -Indexes to your virtual host or .htaccess.
3. Audit your CORS policy: only allow specific trusted origins. Never use Access-Control-Allow-Origin: * on endpoints that read or modify authenticated user data.
4. Close or firewall internal management ports (Redis, MongoDB, Etcd, Kubernetes API). Use bind 127.0.0.1 in service configs to prevent internet exposure.
5. Implement server-side authorisation checks on every sensitive route — never rely solely on frontend hiding or URL obscurity.

Cryptographic Failures (OWASP A02:2021)

Cryptographic failures expose data in transit or at rest due to weak algorithms, misconfigured TLS, expired certificates, or missing transport security enforcement. Attackers on the network path can intercept credentials, session tokens, and sensitive API responses. SwarmHawk's full TLS and certificate check suite maps directly to A02.

• tls_version — detects TLS 1.0/1.1 support (POODLE, BEAST) and confirms TLS 1.2/1.3 availability
• ssl_grade — Qualys SSL Labs grade; A or A+ expected; B/C/F indicate weak cipher suites or protocol issues
• cert_valid / cert_expiry / cert_chain — checks certificate validity, days to expiry, and full chain trust
• hsts — verifies Strict-Transport-Security header is present with max-age ≥ 31536000 and includeSubDomains
• https_redirect — confirms HTTP automatically redirects to HTTPS (no mixed-content or HTTP fallback)

Finding	Impact
Expired or invalid certificate	Critical — up to +20 pts
TLS 1.0/1.1 supported (deprecated protocols)	Critical — up to +15 pts
SSL grade B or below / weak cipher suites	Warning — up to +10 pts
HSTS missing or max-age too short	Warning — up to +8 pts
HTTP does not redirect to HTTPS	Warning — up to +5 pts

1. Disable TLS 1.0 and 1.1 at the web server level. Nginx: ssl_protocols TLSv1.2 TLSv1.3;. Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1.
2. Use only strong cipher suites. Nginx: ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:.... Use Mozilla's SSL Config Generator for a current safe list.
3. Renew expiring certificates. Use Let's Encrypt with automatic renewal (certbot renew in cron) to eliminate manual expiry risk.
4. Add HSTS: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Submit to the HSTS preload list once confident.
5. Redirect all HTTP traffic to HTTPS: Nginx — return 301 https://$host$request_uri; in the port 80 server block.
6. Validate your TLS configuration at Qualys SSL Labs — aim for grade A+.

Security Misconfiguration (OWASP A05:2021)

Security misconfiguration is the most widespread category in practice — insecure defaults, missing hardening, unnecessary features enabled, verbose error messages, and overly permissive settings. Attackers enumerate misconfigured services automatically within minutes of deployment. SwarmHawk's header, disclosure, and exposure checks collectively map to A05.

• csp / x_frame_options / x_content_type / referrer_policy / permissions_policy — security response headers that restrict browser attack surface
• server_header / software_disclosure — Server, X-Powered-By, X-Generator headers revealing exact software versions to attackers
• cors — wildcard or overly permissive cross-origin policy
• directory_listing — web server autoindex exposing file structures
• open_ports — unused services and management interfaces publicly reachable
• waf — absence of a web application firewall as a defence-in-depth layer

Finding	Impact
Directory listing / path traversal exposure	Critical — up to +20 pts
Missing security headers (CSP, X-Frame-Options, HSTS, etc.)	Warning — up to +5 pts each
Software/version disclosure in response headers	Warning — up to +8 pts
No WAF detected	Warning — up to +5 pts

1. Add all recommended security response headers. Use securityheaders.com to verify. Minimum: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin.
2. Remove version disclosure from Server and X-Powered-By headers. Nginx: server_tokens off;. Apache: ServerTokens Prod + ServerSignature Off.
3. Disable directory listing (see Broken Access Control — same fix applies).
4. Firewall or disable any port or service that isn't actively needed in production. Audit open ports monthly.
5. Deploy a WAF (Cloudflare, AWS WAF, ModSecurity + OWASP CRS) in front of your application to filter common attack patterns even if application-level checks miss something.
6. Use infrastructure-as-code security scanners (Checkov, Terrascan) on your deployment configs to catch misconfigurations before they reach production.

Vulnerable and Outdated Components (OWASP A06:2021)

Using components with known vulnerabilities is one of the easiest attack vectors — exploit code is often publicly available within hours of a CVE publication. SwarmHawk combines passive version detection with active nuclei validation to identify components that are both detectable and exploitable from the internet.

• cve_exposure — detected software versions matched against the NVD CVE database for known vulnerabilities
• cms_version — WordPress, Drupal, Joomla, Magento version detection and known CVE lookup
• server_header / software_disclosure — web server and framework version extraction from response headers
• nuclei — 3,000+ active templates confirm whether detected CVEs are actually exploitable (not just version-range matches)
• sca — software composition analysis of client-side JavaScript bundles for known vulnerable libraries

Finding	Impact
Nuclei confirmed critical/high CVE (actively exploitable)	Critical — CVSS × 6 pts
Known-vulnerable CMS or server version detected	Critical — up to +20 pts
Version disclosed (enables targeted CVE lookup by attacker)	Warning — up to +8 pts
Vulnerable JavaScript libraries in client-side bundles	Warning — per library

1. Subscribe to security advisories for every component you use — NVD (nvd.nist.gov), GitHub Security Advisories, and vendor mailing lists. Treat high/critical CVEs as incidents requiring same-day response.
2. Keep CMS core, plugins, and themes updated automatically where possible. WordPress: enable automatic background updates. Drupal: use composer update drupal/core.
3. Remove version information from response headers (see Security Misconfiguration — server_header fix). Version disclosure reduces attacker reconnaissance friction.
4. Integrate Dependabot, Renovate, or npm audit / pip-audit into your CI pipeline. Block merges that introduce high/critical dependency vulnerabilities.
5. Maintain an inventory (SBOM — Software Bill of Materials) of all components and versions. OWASP CycloneDX or SPDX format are industry standards.
6. For nuclei findings: patch the specific CVE version referenced in the finding. The nuclei template name links directly to the CVE — check the NVD entry for the patched version.

Attack Surface Analysis — What It Is

Attack Surface Analysis is an on-demand deep reconnaissance that goes far beyond the standard 30+ security checks. It correlates four independent intelligence sources — live Shodan port data, ParanoidLab credential breach databases, your existing scan findings, and Claude AI — to produce a realistic, evidence-backed picture of how an attacker could compromise your domain right now.

1. Exposed Services & CVEs — Shodan is queried for every IP your domain resolves to. All open ports, service banners, product versions, and associated CVE IDs (with CVSS scores) are surfaced.
2. Credential Leaks — ParanoidLab's breach database is searched for your domain. Any leaked emails, hashed or plaintext passwords, and the source breach are included.
3. Breach Path Graph — A MITRE ATT&CK-annotated force-directed graph maps every realistic path from an attacker's entry point to your critical assets.
4. AI Attack Narrative — Claude AI synthesises all evidence into a penetration tester's assessment: a realistic attack chain, risk summary, and prioritised fix list tailored to your exact configuration.
5. Fix Priority — Five numbered remediation steps ranked by the order in which they would most reduce attacker leverage — not just by severity score.

How the Analysis Works — 5 Stages

When you click "Run Analysis", the backend executes five sequential intelligence-gathering stages. Each takes a few seconds; the total analysis typically completes in 15–40 seconds depending on how much data Shodan and ParanoidLab have indexed for your domain.

1. 🌐 DNS Resolution — Your domain is resolved to IPv4 addresses via standard DNS. Up to three IPs are collected. This reveals your hosting infrastructure and ASN, and determines which IPs will be passed to Shodan.
2. 📡 Shodan Intelligence — Each resolved IP is queried against the Shodan search engine API. Shodan continuously crawls the internet and stores banner data, product versions, open ports, and CVE lists for every routable IP. This is exactly the data available to any attacker performing reconnaissance.
3. 🔐 Dark Web Intel via ParanoidLab — ParanoidLab's breach database is queried for credential records associated with your domain. This includes data from thousands of breach dumps, dark web leak channels, and Telegram groups where stolen data is traded.
4. 🤖 AI Threat Analysis via Claude AI — All collected evidence (IPs, ports, CVEs, breach count, existing scan findings, WAF presence, SPF/DMARC status) is passed to Claude AI with a structured penetration tester's prompt. Claude generates a domain-specific attack chain and fix priority list grounded only in the actual evidence — it does not invent vulnerabilities.
5. 🗺 Attack Graph Construction — Each service, IP, and credential leak becomes a node in a MITRE ATT&CK-annotated graph. Edges represent the technique an attacker would use to move between nodes. The graph is rendered as an interactive D3 force simulation — nodes can be dragged and the tooltip shows the full MITRE technique detail for each edge.

Reading the Breach Path Graph

The force-directed graph is the visual centrepiece of the Attack Surface Analysis. Each node and edge has a specific meaning. Understanding the colour coding and edge labels lets you immediately see where your most critical exposures are.

1. Entry Nodes (red) — Services or credential leaks that give an attacker their first foothold. A red node means there is a known, exploitable path in. Examples: a port running software with a known CVE, or a leaked credential set for your domain. The number shown in the legend tells you how many entry vectors exist.
2. Pivot Nodes (amber) — Services or IPs that are not directly exploitable but can be used to move laterally once an attacker has an initial foothold. Examples: an open SSH port on an IP that is not directly vulnerable but can be brute-forced, or a web server that serves as a stepping stone to internal systems.
3. Critical Node (lime) — Your target domain. This is the "crown jewel" — all attack paths ultimately converge here. The risk score displayed is derived from your full scan results.
4. Safe Nodes (blue) — Services that are open but have no known CVEs and are not in MITRE's lateral movement technique list. They still represent attack surface but are lower priority.

1. Count red (Entry) nodes — each one is an independent attack vector. Eliminating one red node removes one path entirely.
2. Read the edge labels — each label is a MITRE ATT&CK technique ID (e.g. T1190). Hover the edge to see the full technique name and description.
3. Drag nodes to explore the graph — the force simulation can be dense for well-exposed domains. Dragging a node pins it so you can inspect its connections clearly.
4. Prioritise paths with the fewest hops — a two-hop path (Entry → Critical) is more dangerous than a four-hop path because it requires less attacker capability to execute.

MITRE ATT&CK — Framework & Techniques Used

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is the globally accepted framework for classifying attacker behaviour. SwarmHawk maps every detected exposure to the specific ATT&CK technique an adversary would use to exploit it, giving you language that is compatible with your SOC, EDR, and SIEM tooling.

1. T1190 Exploit Public-Facing Application — The most common technique. Applies to any port running software with a known CVE (web servers on 80/443, databases on 3306/5432, admin panels). Also applies to exposed Elasticsearch (9200), Redis (6379), and MongoDB (27017) — all frequently found unprotected.
2. T1021 Remote Services — Applies to open SSH (22), Telnet (23), RDP (3389), VNC, NFS (2049), and SMB. Remote service access is the primary lateral movement technique after initial access is achieved.
3. T1021.004 SSH — Specifically mapped for port 22. SSH with weak or default keys is a critical risk, especially on servers that also host web applications.
4. T1021.001 RDP — Mapped for port 3389. Exposed RDP is one of the most aggressively targeted vectors by ransomware operators.
5. T1566 Phishing — Mapped when mail ports (25, 465, 587) are open and SPF/DMARC are misconfigured. Missing email authentication enables sending phishing email that appears to originate from your domain.
6. T1078 Valid Accounts — Mapped when credential leaks are found by ParanoidLab. Leaked passwords enable direct login without any vulnerability exploitation — this is often the fastest path to compromise.
7. T1046 Network Service Discovery — Applied to open ports that do not have a known CVE but are identifiable by Shodan. Attackers use discovered services to plan subsequent exploitation steps.
8. T1590 Gather Victim Network Information — Applied to every resolved IP. The act of resolving your domain and recording the ASN, org, and ISN is the reconnaissance step that precedes all attacks.
9. T1059 Command and Scripting Interpreter — Mapped for port 4444, commonly used by Metasploit and reverse shells. An open port 4444 is a strong indicator of active compromise or a misconfigured development environment.
10. T1102 Web Service (C2) — Mapped for IRC ports (6667). Legacy IRC-based botnets and some modern C2 frameworks use this port for command-and-control communication.

Dark Web Intelligence — ParanoidLab

The Dark Web Intelligence card in your domain report is powered by ParanoidLab, a specialist threat intelligence provider that continuously indexes credential breach data, dark web marketplaces, and Telegram leak channels. Understanding what each metric means helps you triage the risk and respond appropriately.

1. Total Leaks — The number of individual records (rows) in breach databases that contain an email address ending in your domain. Each record represents one user account whose credentials have been exposed. A total of 0 is excellent; 1–10 warrants investigation; 10+ requires immediate password resets and MFA enforcement.
2. With Passwords — Records that include a plaintext or weakly hashed (MD5, SHA1) password alongside the email. These are the highest-risk records because they enable direct credential stuffing — automated tools test these exact username/password combinations against your login endpoints within hours of a breach being published.
3. Telegram Hits — Mentions of your domain in Telegram leak channels or criminal group chats. Telegram is now the primary distribution platform for stolen data. A Telegram hit means your domain's credentials or data are actively being traded or discussed in criminal communities right now.
4. Leak Types — The breakdown of data fields present in the breach records (email, password, hash, username, phone, address, etc.). More field types means more complete attacker intelligence about your users — increasing the risk of targeted spear-phishing and account takeover beyond simple credential stuffing.

1. Force an immediate password reset for every affected email address identified in the breach records — do not wait for users to self-report.
2. Enable multi-factor authentication (MFA) organisation-wide. A leaked password is useless if a second factor is required — MFA eliminates the primary risk from credential exposure.
3. Check your login endpoint logs for credential stuffing patterns: rapid sequential login attempts from the same IP, or login attempts using known-breached email addresses.
4. Integrate the ParanoidLab data with your SIEM — set alerts for when new records appear for your domain so you can respond within hours instead of months.
5. If Telegram hits are shown, treat this as an active incident: the data is being actively distributed. Escalate to your security team and consider engaging an incident response firm if the volume is high.