Security Analysis Guide

What is passive security analysis?

Passive security analysis means examining information that is already publicly available — DNS records, HTTP response headers, TLS certificates, WHOIS data — without sending probes, running exploits, or accessing systems you don't own. It is distinct from active scanning, which makes requests designed to discover vulnerabilities.

ShieldScope never fingerprints, never brute-forces, and never interacts with a target beyond what a normal browser request would do. This means you can analyze any domain or URL — including ones you don't control — legally and without risk. It also means results are based entirely on observable, public data.

Analyzing HTTP security headers

What are HTTP security headers?

HTTP security headers are response headers that instruct browsers how to handle content from your site. When a server responds to a request, it can include headers that tell the browser: don't execute inline scripts, always use HTTPS, refuse to render this page inside an iframe, and limit what browser features this page can access.

Missing or misconfigured security headers are among the most common findings in web application security assessments. They don't require an attacker to exploit a vulnerability — the browser itself becomes the attack surface if headers are absent.

How to run a headers analysis

1. Go to /headers
2. Enter any domain or URL (e.g., example.com or https://example.com)
3. Click Analyze
4. Review the grade and individual header findings

Understanding the grade (A+ to F)

The grade reflects overall HTTP security header coverage. Each header is assessed independently and contributes to a score out of 100.

Key headers and what they protect against

Analyzing email authentication — SPF, DKIM, DMARC

What are SPF, DKIM, and DMARC?

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers and IP addresses authorized to send email for your domain. Receiving mail servers check SPF to verify the sending server is on the authorized list.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email. The signature is verified against a public key published in DNS. It proves the email content was not modified in transit and that it genuinely originated from the claimed domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails — nothing (p=none), quarantine to spam (p=quarantine), or reject outright (p=reject).

Why email authentication matters

Without properly configured SPF, DKIM, and DMARC, attackers can send email that appears to come from your domain — a technique used in phishing attacks and Business Email Compromise (BEC). BEC costs organizations billions annually and almost always begins with impersonation of a trusted domain.

DMARC at p=reject is the only configuration that actively blocks unauthorized senders. p=none is a monitoring mode only and provides no protection.

How to run an email authentication analysis

1. Go to /mail
2. Enter a domain name (e.g., gmail.com or yourcompany.com)
3. Click Analyze
4. Review SPF, DKIM, and DMARC findings individually

Common findings and what they mean

Checking URL safety — redirects, domain age, and phishing patterns

What the URL analyzer checks

Before you click an unfamiliar link — in an email, a message, or a document — you can paste it into the URL tool to understand exactly where it goes and what signals it carries. The analysis is entirely passive: no visit to the destination, no execution of content.

How to check a URL

1. Go to /url
2. Paste the full URL (including https://)
3. Click Analyze
4. Review the risk badge, redirect chain, and individual findings

Understanding the risk score

Red flags to watch for

• Domain registered fewer than 30 days ago
• More than two redirect hops, especially through unrelated domains
• The registered domain in the URL is not what you expect (check the URL decomposition row)
• A well-known brand name appears in the subdomain, not the registered domain
• No SSL, or SSL certificate issued within the past few days

Analyzing password strength and breach exposure

How password strength is measured

Strength is measured by how long a password would survive an offline attack — where an attacker has a stolen password hash and can run billions of guesses per second. ShieldScope estimates crack time at 10 billion hashes per second, which approximates a fast hash (SHA-1/MD5) on modern GPU hardware.

Raw length and character class diversity matter, but pattern-free randomness matters more. Password123! is 12 characters with uppercase, lowercase, numbers, and a symbol — yet it cracks in under a second because it follows the most common pattern in corporate environments. ShieldScope's analysis uses pattern detection to catch these cases.

Patterns that weaken passwords

• Dictionary words — any word in a natural language dictionary, regardless of capitalisation
• Common password sequences — strings that appear in breach databases (1234, qwerty, letmein)
• Keyboard patterns — spatial sequences on the keyboard (qwerty, asdfgh, zxcvb)
• Dates and years — years appended to words (Company2024, Summer1990)
• Repeated characters — aaaa, 1111, !!!!
• Enterprise reuse patterns — Word + 4-digit year + symbol (Welcome2024!)

What is the breach exposure check?

The breach check queries the Have I Been Pwned database — which contains over 10 billion passwords collected from real data breaches — without ever sending your password. This is possible through k-anonymity:

1. Your password is hashed with SHA-1 entirely in your browser
2. Only the first 5 characters of that hash are sent to the API
3. The API returns all hashes starting with those 5 characters
4. Your browser checks locally whether your full hash is in the list

Your actual password never leaves your device. This is the same technique used by Chrome and Firefox's built-in password breach warnings.

Understanding the rating

Using the password generator

The generator creates cryptographically random passwords and passphrases using crypto.getRandomValues() — never Math.random(). No generated password is ever transmitted or stored.

For most use cases, a 20-character random password with all four character classes, or a 5-word passphrase, will achieve a SECURE rating. Passphrases are often easier to remember when you need to type them manually.

Mapping internet-facing attack surface

What the exposure analyzer does

Every organization accumulates internet-facing infrastructure over time — subdomains for old projects, staging environments that were never taken down, admin panels that were meant to be internal, file transfer services that ended up on a public IP. The /exposure tool maps this surface passively, using public data only.

It does not scan for vulnerabilities, attempt exploits, or interact with services beyond what a browser would do. The value is in the classification of what's found — turning a list of hostnames into an organized picture of your external footprint.

How it discovers subdomains

The tool queries HackerTarget's hostsearch API, which aggregates data from certificate transparency logs, DNS records, and passive DNS sources. Certificate transparency logs are public records published by certificate authorities — every TLS certificate ever issued for a domain is logged there. This makes them one of the most comprehensive sources of subdomain data available without active scanning.

An intelligence filter then removes machine-generated CDN routing labels (such as a01.ms.a.example.com or long hex-string hostnames) that are infrastructure noise rather than useful intelligence. The suppressed count is shown in the scope notice so you can see how much was filtered.

How to run an exposure analysis

1. Go to /exposure
2. Enter a registered domain (e.g., example.com)
3. Click Analyze
4. Watch hosts appear progressively as the scan runs
5. Review the summary cards and individual findings

Understanding the summary cards

Understanding the risk levels

What "Confidence: Medium — false positives possible" means

When a finding is classified by hostname pattern alone — without confirming a service via HTTP response — the classification is an inference, not a certainty. A hostname containing dev is more likely to be a development system than a random web asset, but it could also be a product named "dev" or a subdomain that was repurposed. ShieldScope declares this uncertainty explicitly rather than overstating confidence.

Findings where a specific service was detected via HTTP fingerprinting carry Confidence: High — the service name, HTTP title, or server header directly confirmed the classification.

Common findings and what to do about them

What this tool is not

The exposure analyzer is not a vulnerability scanner. It does not test credentials, attempt to access restricted content, exploit software weaknesses, or confirm that a service is actually compromisable. It tells you what is visible from the internet and classifies it — the assessment of risk is yours to make.

Inspecting suspicious scripts, URLs, and email artifacts

What the script analyzer checks

The script analyzer performs static inspection — it reads the code without executing it, applies pattern matching to identify dangerous functions and techniques, decodes base64-encoded strings, and extracts embedded indicators of compromise (IOCs) including URLs, domains, and IP addresses.

This is useful when you encounter a suspicious script attached to a phishing email, found in a user's event logs, or flagged by your EDR. Static analysis gives you a defensible picture of what the script appears to do, without the risk of running it.

Supported languages

ShieldScope auto-detects the language from the script content, or you can select it manually: PowerShell, JavaScript, Batch/CMD, and VBScript. Each language uses a tailored indicator set for its most common malicious patterns.

Key indicators detected

Base64 decoding

ShieldScope automatically finds base64-encoded strings in the script, decodes them, and displays the decoded content. It also scans the decoded text for additional IOCs — so if a URL or domain is hidden inside a base64 payload, it will still appear in the extraction results.

How to run a script inspection

1. Go to /sandbox
2. Select the Script tab
3. Paste the script content into the text area
4. Select the language or leave it on Auto-detect
5. Click Inspect
6. Review the risk level, behavioral summary, findings (with context snippets), extracted IOCs, and decoded base64 strings

Sandbox URL analysis

The URL tab in /sandbox runs the same analysis as the standalone /url tool with two additional signals:

• Domain entropy — measures the randomness of the domain name. High Shannon entropy (above 4.0 bits) is a signal of algorithmically generated domains (DGAs) used by malware to evade blocklists.
• Suspicious file extension — flags URLs ending in executable or archive extensions (.ps1, .exe, .bat, .hta, .dll, .zip) which are frequently observed in malware delivery links.

Email artifact analysis

The Email tab performs static inspection of raw email source — pasted headers, full .eml files, or MIME content. No email account is accessed, no messages are fetched, and no network connections are made to any mail server. Only the text you paste is analyzed.

What the email analyzer checks

Understanding risk states

The email analyzer uses four distinct states that deliberately avoid collapsing unverified-safe with verified-safe:

Confidence labels on findings

Each finding card displays a confidence label alongside the severity badge:

• OBSERVED — the indicator is directly present in the submitted content with high specificity. Example: SPF fail in a parsed Authentication-Results header.
• HEURISTIC — the indicator is inferred from a pattern that is associated with malicious activity but not exclusively so. Example: a brand name appearing in a URL domain that isn't the brand's canonical domain. Requires context from other signals.
• INFERRED — the finding results from the combination of two or more individually observed indicators (correlation). Example: download + execute chain in a script.

Heuristic findings should always be considered in the context of other signals. A single heuristic finding on an otherwise clean email from a known sender may be a false positive — several heuristic findings together with authentication failures are a different picture entirely.

How to run an email analysis

1. Go to /sandbox and select the Email tab
2. Open the suspicious email in your mail client and access its raw source (see note above for each client)
3. Copy the raw email content — headers through body — and paste it into the text area
4. Click Analyze
5. Review the risk level and delivery summary, then the authentication section (SPF/DKIM/DMARC), then individual findings in severity order
6. Check the URLs in Body section for shorteners and suspicious domains, and the Attachments section for file risk classification

Frequently asked questions