Attack Surface Monitor

Phase 1: Subdomain Discovery Engine

Most companies know their main website, but many do not know every internet-facing asset tied to their domain. Forgotten portals, staging environments, old admin panels, and newly exposed subdomains often become the first thing attackers discover.

That’s the idea behind CySentra ASM a Python-based External Attack Surface Monitoring project designed to help organizations understand what they expose to the internet.

What Phase 1 Focused On

The first step was building a Subdomain Discovery Engine.

Input:

example.com

Output:

[+] Subdomains generated: 15

Examples:

admin.example.com
api.example.com
vpn.example.com
www.example.com

Why This Matters

Before validating live hosts, checking SSL, or detecting risky exposure, you first need visibility into what may exist.

Phase 2: DNS Resolution & Validation

In Phase 1, I built a subdomain discovery engine that generates likely internet-facing assets from a target domain. In Phase 2, I extended the project with a DNS validation layer to determine which candidates actually resolve and which ones are just noise. This step matters because attack surface monitoring is not about collecting random names it is about identifying real assets tied to a company’s external perimeter. The Phase 2 module resolves candidate subdomains, extracts IP addresses, and classifies whether an asset points to a public IP, giving the project a more realistic inventory of live external infrastructure. Next, I’ll move into HTTP/HTTPS fingerprinting so the platform can inspect web behavior, headers, and exposed login surfaces.

Phase 3: HTTP/HTTPS Fingerprinting

After generating candidate subdomains and validating which ones resolve in DNS, the next step in CySentra ASM was to inspect what those live assets actually expose over the web. In this phase, I added an HTTP/HTTPS fingerprinting layer that checks reachable hosts, follows redirects, records status codes, extracts page titles, and captures selected server and security headers. This moves the project beyond asset discovery into real external visibility, helping show not just which assets exist, but what kind of web-facing behavior they present. Next, I’ll build storage and change tracking so the platform can compare scans over time and highlight newly exposed or altered assets.

Phase 4: Storage and Change Detection

In Phase 4, I turned ASM from a one-time scanner into a monitoring system. I added SQLite-based storage for scan snapshots and built a diff engine that compares the latest scan with the previous one for the same target. This allows the platform to detect newly exposed assets, removed hosts, and changes in fields such as HTTP status, titles, and server headers. With this step, the project now supports historical visibility, which is one of the core ideas behind real attack surface monitoring.

Cylab

Phase 5: Risk Scoring and Executive Reporting

In Phase 5, I added a scoring engine that converts technical scan results into prioritized findings. Instead of only showing subdomains and HTTP responses, the platform now identifies exposed login portals, newly discovered assets, insecure web exposure, and unusual behavior, then assigns severity levels such as High, Medium, or Low. This makes the project more useful for decision-makers by translating raw technical data into actionable security priorities.

Phase 6: Real Subdomain Enumeration

In Phase 6, the tool now combines three discovery sources: a built-in wordlist, certificate transparency data from crt.sh, and Amass passive enumeration. This significantly improves asset discovery because real organizations often expose systems that are not obvious from common names like www, api, or admin. By merging and deduplicating results from multiple passive sources, the platform now produces a more realistic external asset inventory while staying safer and more appropriate for authorized security assessments.

Phase 7: Security Header Analysis

In Phase 7, I added security header analysis to CySentra ASM. After discovering and fingerprinting reachable web assets, the platform now checks for important defensive headers such as Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy. This turns basic web fingerprinting into more actionable security review output by identifying configuration gaps that can increase exposure to risks such as clickjacking, content injection, insecure transport behavior, and information leakage.

Phase 8: TLS Certificate Intelligence

In Phase 8, I added TLS certificate intelligence to CySentra ASM. The platform now checks HTTPS-enabled assets for certificate issuer, subject, validity period, expiry date, days until expiration, and Subject Alternative Names. This adds an important operational security layer because expired or misconfigured certificates can affect availability, trust, and compliance readiness. Combined with discovery, DNS validation, web fingerprinting, change detection, and header analysis, CySentra ASM is now moving closer to a practical external attack surface monitoring product.

Phase 9: Client Reporting Exports

In Phase 9, I transformed CySentra ASM from an engineering scanner into a more client-ready product by adding CSV and HTML reporting exports. The platform can now convert technical findings into structured deliverables that summarize risk levels, affected assets, and recommended next steps. This is important because organizations and decision-makers need readable outputs, not raw JSON or terminal logs. With this phase, CySentra ASM becomes more practical for consulting engagements, recurring security reviews, and executive communicatio

CySentra ASM v1.0 COMPLETE

A Python-based External Attack Surface Monitoring platform built for asset discovery, DNS validation, web fingerprinting, TLS analysis, risk scoring, and client-ready reporting.

Built as a practical cybersecurity engineering and consulting-focused project.