NiamonX Tools WiKi

NiamonX Tools WiKi is the central knowledge hub that provides detailed documentation, usage guides, and technical insights into all tools, modules, and research utilities developed within the NiamonX ecosystem.
It serves as a unified reference point for engineers, researchers, and security analysts working with NiamonX technologies in the fields of AI, data intelligence, cybersecurity, and OSINT.

Data Breach Search

Data Breach Search

Public Breached Search | Public Breaches (140+ Billion Records)

image.png


Overview of the Service

The platform available at dash.niamonx.io/breaches_search is a professional-grade Public Breached Data Search System designed for verifying whether specific personal identifiers have appeared in any known public data leaks across the Internet.
It operates on an aggregated dataset exceeding 140 billion records collected from over 4,500 public breach sources, making it one of the most extensive publicly searchable breach databases in existence.

🔍 How the Search Works

When a user enters a query — such as an email address, username, phone number, IP, or domain — the system performs a real-time lookup across its encrypted, indexed data clusters.
The query is normalized, tokenized, and securely matched against hashed or pseudonymized datasets to locate potential breach entries.

The search engine uses multi-vector indexing optimized for text, numeric, and composite keys (e.g., email + password, name + city), allowing flexible combined searches.

To maintain integrity and performance:

You can look up:

The system structures results into logical “groups” that may include:

Sensitive fields like passwords remain masked until explicitly revealed by the user.

🛡️ Security & Ethics

All stored data and query logs are encrypted using modern cryptographic algorithms.
Only aggregated metadata — not full confidential strings — is retained in request history for transparency and analytics.

Additional safeguards:

The service is intended for ethical use only — such as checking whether your credentials or company assets appear in public leaks and taking appropriate security measures (e.g., password changes, MFA setup).

📊 Extra Features

In summary, NiamonX Breach Search acts as a secure, encrypted intelligence platform that enables professionals and individuals to verify their exposure in public breaches responsibly. It prioritizes data protection, cryptographic integrity, and ethical transparency, providing actionable insights while maintaining user and data privacy.

📬 Contact Information

For any inquiries, users can contact the project team directly:

An alternative contact channel is the official Helpdesk:
🔗 https://support.niamonx.io/

Data Breach Search

ULP (Infostealer Logs) | Public Breached ULP Search

sdadsadasdas_clean_clean.jpg

Overview of the Service

The platform available at dash.niamonx.io/ulp_search — known as ULP Search — is a specialized Data Breach Search Engine developed by NiamonX for identifying credential exposures in public and infostealer leak datasets.
It provides professionals and security researchers with a structured, secure, and ethical way to verify whether specific login credentials have been compromised online.

The ULP database currently indexes over 19 billion credential records, continuously updated and refined through automated pipelines, ensuring freshness, accuracy, and de-duplication.

🧩 What is ULP?

ULP stands for URL · LOGIN · PASSWORD, representing a credential triple extracted from public or infostealer data sources.

Each record typically contains:

This triplet allows correlation between breached accounts, reused passwords, and compromised domains, forming the foundation of forensic credential analysis within NiamonX’s breach intelligence system.

🔍 How the Search Works

Users can query the database using any of the following parameters:

The system automatically detects the query type (Auto mode) or allows manual selection for more specific searches.
Searches are conducted in real-time against encrypted datasets, and results are filtered and ranked by confidence and relevance.

Key operational details:

If search performance temporarily decreases, it may indicate active deduplication or dataset reindexing — repeating the search after a few minutes ensures access to the freshest possible data.

🧠 Key Features

🛡️ Security, Privacy & Ethics

Every search request is fully encrypted end-to-end, ensuring that user queries and results remain private.
The system never shares, resells, or exposes query data — even internally.

Ethical principles:

📈 Technical Highlights

📬 Contact Information

For support, inquiries, or privacy-related requests, the NiamonX team can be reached directly via:

Alternative contact channel:
🔗 Helpdesk: https://support.niamonx.io/

In summary, NiamonX ULP Search is a cryptographically secure and ethically governed breach intelligence system designed for professional credential analysis.
It provides deep visibility into compromised login data from billions of records — while maintaining the highest standards of security, privacy, and responsible use.

Data Breach Search

PBS v2 (Beta Search) | Public Breached Search V2

image.png

Overview of the Service

The platform available at dash.niamonx.io/breaches_s_v2 — known as Public Breached Search V2 — is an advanced, security-focused version of the NiamonX breach intelligence engine.
It enables users to safely and privately search for publicly available leaked records (emails, usernames, phone numbers, or hashes) through a fully encrypted channel, using an enhanced privacy-preserving architecture.

This system is designed for individuals, analysts, and cybersecurity teams who need to verify whether specific identifiers have been compromised — without exposing their search queries or retrieved data.

🔍 How the Search Works

When a user submits a query — such as an email address, username, phone number, or hash — the system performs a real-time lookup across an alternative, minimized index of public breach data.
The search is executed through a closed security network using end-to-end encryption and a master key–based decryption layer. This ensures that:

This approach provides maximum privacy, ensuring that no third party — including NiamonX infrastructure — can access raw search data or results.

Supported input types:

Unlike the standard Breached Search engine, V2 does not support URLs, domains, or combined queries. It focuses exclusively on personal identifiers and cryptographic hashes to maintain precision and data hygiene.

Passwords found in results are hidden (masked) by default. Users may reveal them manually if needed for verification, but they must not redistribute or publicly display that information.

🧠 Key Features

🛡️ Security, Privacy & Ethics

The service is built with security-first architecture and strict privacy guarantees:

Users are strongly encouraged to practice digital hygiene — for example, by changing passwords, enabling MFA, and avoiding credential reuse.

⚙️ Technical Highlights

📬 Contact Information

For any technical, legal, or privacy-related inquiries, users can reach the NiamonX team directly via:

Alternative contact channel:
🔗 Helpdesk: https://support.niamonx.io/

In summary, NiamonX Public Breached Search V2 is a secure, privacy-preserving intelligence system that enables safe and encrypted lookup of breach data.
It prioritizes user confidentiality, cryptographic protection, and ethical operation, ensuring that every search remains private, traceable only to the authorized user, and never exposed beyond their secure session.

Data Breach Search

Public Breached Search Fast (80+B) | Fast Public Breach Intelligence Search

image.png

The platform available at dash.niamonx.io/breaches_search_fast

Overview of the Service

Public Breached Search Fast (80+B) is a high-speed breach intelligence tool available within the NiamonX platform. It enables users to search across 80+ billion public records collected from publicly available breach datasets and alternative intelligence channels.

The system is designed for individuals, analysts, security researchers, compliance teams, and cybersecurity departments that need to quickly verify whether specific identifiers, accounts, or technical indicators appear in compromised public datasets.

Unlike the encrypted PBS v2 engine, Public Breached Search Fast focuses on speed, broad query coverage, source diversity, graph analysis, and flexible exports. It supports a wide range of identifiers, including emails, usernames, phone numbers, names, domains, IP addresses, vehicle identifiers, social media IDs, and composite queries.

The service is intended strictly for lawful security analysis, personal data verification, incident response, and defensive investigations.

🔍 How the Search Works

When a user enters a search value, the system performs a fast lookup across a large alternative breach index containing more than 80 billion public records.

The user can either allow the system to automatically detect the query type or manually select a specific type, such as email, phone number, domain, VIN, passport, Telegram, VK, or composite query.

The platform then returns available matches, grouped and structured by source, data type, and related metadata.

Important behavior:

This approach allows the system to prioritize both speed and broad source discovery while keeping sensitive information controlled.

Public Breached Search Fast supports 22 query types with automatic detection.

Supported query types:

The search input supports values from 2 to 500 characters.

Users should enter only the value itself, not a full URL. For example, enter a domain name instead of a full website address.

⚙️ Search Interface

The search interface includes the following main fields:

Search Value

The identifier or value to search for.

Examples of supported values:

Query Type

The user may select a specific query type or use Auto-detect.

Auto-detection helps identify the most likely input type and route the search through the correct lookup logic.

Limit

The user can specify the maximum number of results to retrieve.

Free users are limited to 200 visible results with sensitive information masked. Paid users may access higher result limits and full visibility depending on their subscription level and permissions.

🧠 Key Features

Fast Search Across 80+ Billion Records

The system is optimized for quick lookups across a very large public breach index.

22 Query Types

Public Breached Search Fast supports a wide range of identifiers, including personal, technical, vehicle-related, and social media identifiers.

Auto-Detection

The platform can automatically detect the type of query entered by the user.

Overview Section

Search results include a structured overview of discovered matches, source distribution, and available metadata.

Results View

Matched records are displayed in a readable format with source highlighting and structured fields.

Graph View

The tool can visualize relationships between identifiers, sources, and connected records using graph-based analysis.

AI Audit

The AI Audit feature helps summarize and interpret the search results from a security and risk perspective.

Offline Graph Export

Users can export graph analysis as an offline HTML file for local review, reporting, or internal investigations.

Cluster and Expand

The system can cluster related records and expand connected entities to help analysts understand relationships between data points.

Source Highlighting

Sources are visually highlighted to make it easier to identify where specific records were found.

Flexible Export

Results can be exported in multiple formats:

Export functionality is intended for lawful internal use, incident response, compliance checks, and security reporting.

📊 Results, Graph, and AI Audit

Public Breached Search Fast provides multiple result analysis layers.

Overview

The overview section summarizes key information about the query, such as:

Results

The results section displays matching records from available public breach sources.

Depending on the user’s access level, some sensitive fields may be masked.

Graph

The graph view helps users analyze relationships between identifiers and sources.

This is useful for:

AI Audit

The AI Audit feature provides an automated interpretation of the findings.

It may help identify:

AI Audit is intended to support analyst decision-making and should not be treated as a final legal or forensic conclusion.

📤 Export Options

Public Breached Search Fast supports several export formats:

Sensitive fields may be masked or excluded depending on account permissions, subscription level, and platform security rules.

Users must not redistribute personal or sensitive data obtained from the system.

⚠️ Important Notes About Sources

A single leak may have many different source references.

Because sources are updated daily, repeated searches may show different or additional sources that were not included in earlier results.

This behavior is normal and reflects the dynamic nature of the breach intelligence index.

Users should treat results as intelligence indicators and verify important findings through proper security, legal, or compliance workflows before taking action.

🛡️ Security, Privacy & Ethics

Public Breached Search Fast is built for defensive cybersecurity, personal security verification, and lawful intelligence analysis.

Users must follow strict ethical rules:

Abuse of the system may result in account restriction, suspension, or termination.

⚙️ Technical Highlights

📌 Query Types Reference

Query Type Description
auto Auto-detect
email Email
email_local Email local part
email_domain Email domain
phone Phone
fullname Full name
nickname Nickname / Username
password Password
ip IP address
domain Domain
car_plate Car plate
vin VIN
passport Passport
snils SNILS
inn INN
vk VKontakte
telegram Telegram
facebook Facebook
instagram Instagram
composite Composite multi-field query
fullname_dob Full name + date of birth
numeric_id Numeric ID

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Public Breached Search Fast (80+B) is a high-speed public breach intelligence tool designed for fast, broad, and structured searches across more than 80 billion public records.

It supports 22 query types, automatic detection, source highlighting, graph analysis, AI-assisted audit, offline graph export, and multiple export formats.

The tool is intended for lawful cybersecurity investigations, personal exposure checks, compliance workflows, and defensive threat intelligence. It combines speed, large-scale coverage, and flexible analysis features while enforcing masking, access control, and ethical usage requirements.

Data Breach Search

Dark Web Search | Underground Threat Intelligence Monitoring

image.png

The platform available at dash.niamonx.io/dark_web_search

Overview of the Service

Dark Web Search is a cybersecurity intelligence tool within the NiamonX platform designed to search for mentions of companies, domains, IP addresses, employee credentials, usernames, email addresses, cryptocurrency wallets, CVEs, and other security-relevant indicators across underground forums, dark web communities, and marketplace-related sources.

The tool helps organizations detect early signs of exposure, leaked credentials, threat actor discussions, infrastructure mentions, and possible compromise indicators.

It is designed for security teams, SOC analysts, threat intelligence researchers, compliance departments, and company owners who need to monitor whether their organization, assets, or employees are being discussed or exposed in underground environments.

The results are informational and should always be validated through further investigation before taking operational, legal, or security actions.

🔍 How the Search Works

When a user submits a search query, such as a company name, domain, IP address, email address, username, BTC wallet, or CVE identifier, the system searches across indexed dark web and underground forum data.

In Simple Mode, the tool searches both:

Results are sorted by ingestion date, meaning the newest collected items appear first.

The platform uses real-time forum scraping and NiamonX Radar intelligence capabilities to detect fresh mentions and newly ingested underground content.

Supported search examples include:

The system is intended to help users identify possible risks, not to provide final conclusions without manual validation.

Dark Web Search supports keyword-based searches related to organizational and technical exposure.

Common searchable values include:

The tool is flexible and can be used for both broad monitoring and focused investigation.

For example:

🧠 Key Features

Real-Time Forum Scraping

The tool continuously collects and processes data from monitored underground sources, allowing users to discover recently ingested mentions.

Search Across Dark Web Forums and Marketplaces

Dark Web Search helps identify mentions across underground communities, forums, marketplaces, and related intelligence sources.

5+ Source Groups

The platform currently provides access to more than five monitored source groups, with collected data updated through the NiamonX Radar intelligence infrastructure.

Simple Search Mode

Simple Mode searches across both post titles and post content, making it easier to find relevant mentions without advanced query syntax.

Ingestion Date Sorting

Results are sorted by ingestion date, allowing analysts to focus on the newest discovered content first.

AI Threat Summary

The platform can generate an AI-assisted threat summary to help users quickly understand the possible risk, context, and relevance of discovered mentions.

IOC Extraction

The system can extract Indicators of Compromise from discovered content.

Possible IOCs may include:

Risk Score

The risk score is calculated based on signals such as:

The score is intended as an analyst support metric and should not be treated as a final determination.

Bookmarks

Users can save searches and individual leak records as bookmarks.

Bookmarks are stored locally in the browser and can be opened from the side panel.

Search History

The tool keeps local browser-based history for easier access to previous searches.

Daily Request Limits

Daily request limits depend on the user’s current plan.

For example, a plan may include:

📊 Results and Threat Context

Dark Web Search results are designed to help analysts quickly understand what was found and why it may matter.

A result may include:

The system helps users identify whether the discovered mention is likely related to:

All findings should be reviewed manually and correlated with internal logs, SIEM data, EDR alerts, access history, and other trusted security sources.

🤖 AI Threat Summary

The AI Threat Summary feature helps convert raw underground data into readable intelligence.

It may assist with:

AI-generated summaries are intended to support human analysts and should not replace professional review.

🧬 IOC Extraction

Dark Web Search can automatically extract security indicators from discovered content.

Extracted indicators may include:

IOC Type Description
IP address Possible infrastructure, victim system, or attacker-controlled host
Domain Mentioned corporate, phishing, malware, or infrastructure domain
Email Exposed account, contact, or credential-related identifier
Hash Malware, file, or credential-related hash
CVE Vulnerability identifier discussed in underground content
Wallet Cryptocurrency wallet connected to scams, ransomware, or illicit activity
Username Forum handle, employee account, or leaked login
URL Mentioned website, panel, leak page, or infrastructure reference

IOC extraction helps analysts move from raw search results to actionable threat intelligence.

🔖 Bookmarks and Local Storage

The bookmark system allows users to save important findings for later review.

Bookmarks may include:

Saved searches and leaks are stored locally in the browser and can be opened from the side panel.

This allows analysts to keep track of investigations without relying on external notes or repeated manual searches.

🚦 Daily Requests and Plan Limits

Dark Web Search uses daily request limits based on the user’s subscription plan.

The interface may show:

Example:

Daily Requests
0 / 1000
1000 remaining

These limits help control usage, protect infrastructure stability, and prevent abuse of the intelligence system.

🧠 Risk Score Logic

The risk score is calculated using several intelligence signals.

Main scoring factors include:

A higher risk score may indicate stronger relevance, higher exposure, or more urgent investigation priority.

However, risk scores should be interpreted as guidance, not as absolute proof of compromise.

🛡️ Security, Privacy & Ethics

Dark Web Search is intended for defensive cybersecurity, threat intelligence, brand monitoring, and lawful corporate security investigations.

Users must follow strict ethical and legal rules:

Abuse of the platform may result in account restriction, suspension, or termination.

⚙️ Technical Highlights

🔌 NiamonX Radar API

Dark Web Search is powered by NiamonX Radar, an advanced OSINT and cybersecurity intelligence API.

NiamonX Radar provides access to modern intelligence services through a REST API and supports automated security workflows.

The API can be used for:

Developers and security teams can explore the full API documentation, authentication methods, available endpoints, examples, and integration guides at:

🔗 https://radar.niamonx.io/

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Dark Web Search is a threat intelligence and monitoring tool that helps users detect mentions of companies, domains, IP addresses, employee credentials, wallets, CVEs, and other security indicators across underground forums and marketplace-related sources.

It provides real-time forum scraping, ingestion-date sorting, AI threat summaries, IOC extraction, bookmarks, local history, risk scoring, and integration support through the NiamonX Radar API.

The tool is designed for lawful defensive cybersecurity, corporate monitoring, incident response, threat intelligence, and exposure validation. All results should be treated as intelligence leads and confirmed through further investigation before taking action.

OSINT Tools

OSINT Tools

Visual Osint (FotoForensics / ExifTool / Risk Score)

rec.JPG

Overview of the Service

The Visual OSINT module — available as part of the NiamonX investigation suite — is an advanced photo forensics and metadata analysis tool that helps identify image manipulation, origin, and authenticity indicators.
It integrates multiple forensic technologies — including FotoForensics-style artifact analysis, ExifTool-based metadata extraction, and CASIA AI prediction — to deliver a complete visual intelligence assessment for investigators, journalists, and security analysts.

🧩 What the Tool Does

Visual OSINT performs a deep, server-side forensic analysis of uploaded images, combining pixel-level inspection, metadata parsing, and AI-driven anomaly detection.

Supported file types: JPEG, PNG, WebP (up to 25 MB).
Each file is securely uploaded to NiamonX’s processing server, analyzed through a FotoForensics-like API, and returned with visual and statistical breakdowns.

The system enforces a cooldown of 30 seconds per request and allows up to 90 seconds for processing.

🔍 Core Analysis Features

  1. Image Forensics (Visual Analysis)
    The tool generates multiple forensic artifacts and comparisons:

    • Original / Compressed Copy

    • Diff & Amplified Diff (highlights pixel-level differences)

    • Overlay & Artifact Grid (visualizes edited regions)

    • ELA (Error Level Analysis) — identifies compression and tampering zones

    • Noise Map — isolates sensor and noise inconsistencies

    • CASIA Prediction — AI model inference from CASIA dataset to detect manipulation patterns

  2. EXIF & Metadata Extraction
    Metadata is extracted using PHP EXIF and ExifTool modules, including:

    • Camera and software data

    • Creation timestamps

    • GPS coordinates (if embedded)

    • Editing traces and unusual tags

    • Hidden text or string data (binary text extraction)

  3. String Analysis
    The tool detects embedded ASCII or Unicode strings, sometimes hidden within images.
    Long strings can indicate metadata injection or hidden payloads.

  4. GPS & Geolocation
    If available, GPS coordinates are extracted and highlighted for quick mapping or cross-verification.

⚖️ Risk Score System

Each image receives a heuristic Risk Score, assessing the likelihood of manipulation or sensitive content presence:

⚠️ The score is heuristic — not absolute proof — and should be interpreted as an analytical indicator rather than forensic certification.

🧠 Tips for Use

image.png

💾 Request History

🛡️ Security & Privacy

All image uploads and forensic analyses are processed via secure, encrypted channels.
The service never retains or shares the uploaded files or results.
Each request is isolated and deleted after processing to maintain strict data confidentiality and user privacy.

Users are encouraged to perform analyses only on legally obtained images and to respect privacy and consent regulations when handling visual materials.

image.png

📬 Contact Information

For inquiries, assistance, or data-related requests, contact the NiamonX team:

Alternative contact channel:
🔗 Helpdesk: https://support.niamonx.io/

In summary, NiamonX Visual OSINT is a comprehensive image forensics platform combining traditional EXIF metadata inspection, advanced artifact visualization, and AI-driven manipulation detection.
It provides investigators with reliable insights into image authenticity and integrity — while maintaining the highest standards of security, privacy, and digital ethics.

OSINT Tools

Social Media Search

image.png

Social Media Search — NiamonX

Link: https://dash.niamonx.io/social_msearch

What it is
The Social Media Search tool is a focused OSINT utility that generates and runs specialized search queries across social media domains using Google Programmable Search Engine (GPSE) combined with NiamonX query logic. It helps investigators, analysts, and researchers locate public social footprints quickly by applying network-specific filters, modifiers and heuristics — without scraping protected APIs.

Key functionality

How the search works (high level)

  1. You enter a basic query (username, email, keywords).

  2. NiamonX constructs network-aware GPSE queries (site:facebook.com “username”, site:twitter.com @user, etc.) and applies modifiers you selected.

  3. GPSE executes the search and returns results; NiamonX post-processes them with heuristic filters and presents ranked results in the UI.

  4. You can switch tabs to view results restricted to a given social domain or view aggregated results in All mode.

Because the tool relies on Google’s index, results depend on what Google has crawled and indexed for each social network.

What you can search for

Limitations & important notes

Best-practice tips

Privacy & security

Contact / support

For any questions, reporting issues, or compliance requests, contact the NiamonX team:

Alternative channel: Helpdesk → https://support.niamonx.io/

OSINT Tools

Brand Reputation

image.png

Brand Reputation — NiamonX

Link: https://dash.niamonx.io/brand_reputation

What it is
The Brand Reputation module is a next-generation AI-powered system for brand perception auditing, sentiment tracking, and trust assessment. It automatically gathers and analyzes public mentions of any company or brand name, evaluates overall tone and credibility, and generates a structured analytical report in under 90 seconds.

Built on top of NiamonX SearchGPT AI, it processes large datasets from multiple open sources, performing sentiment analysis, contextual clustering, and reputation scoring — all securely and locally processed with end-to-end encryption.

Key Functionality

How It Works

  1. You enter a brand or company name (e.g., “Alphabet Inc.” or “NiamonX”).

  2. The engine collects relevant mentions from public data sources.

  3. NiamonX AI performs a multi-layer audit: text clustering, tone detection, quote extraction, and trust scoring.

  4. Within 30–90 seconds, you receive a detailed Markdown report summarizing findings with sentiment breakdown, trend indicators, and confidence ratings.

What You Can Analyze

Report Contents

Markdown rendering ensures each report is visually clear, structured, and ready for presentation.

Privacy & Security

Tips for Best Results

Example Use Cases

Contact / Support

For issues, assistance, or legal inquiries:

Helpdesk: https://support.niamonx.io

OSINT Tools

Reverse Image Search 18+ (OSINT) | Adult Public Model Image Intelligence

image.png

The platform available at https://dash.niamonx.io/reverse_image_search — known as Reverse Image Search 18+ (OSINT) — is a specialized 18+ image intelligence module within the NiamonX platform. It is designed to perform reverse image search against public adult-model sources and return structured, analyst-friendly matches for moderation, brand protection, content verification, and lawful OSINT analysis.

18+ Important Notice

Users may only upload or submit images when they have a lawful and ethical right to analyze them. Any illegal, abusive, non-consensual, exploitative, or privacy-invasive use is strictly prohibited.

The service is intended for:

The service must not be used for stalking, harassment, doxxing, deanonymization of private individuals, non-consensual identification, or analysis of minors. Any content involving minors is strictly prohibited. Misuse of the tool may result in immediate account blocking or termination.

Overview of the Service

Reverse Image Search 18+ (OSINT) allows users to search for visual matches across public adult webcam and model-related platforms. The tool accepts either an image URL or a local file upload and attempts to find visually similar public model records.

The system returns a structured report containing potential matches, platform statistics, gender indicators, probability ratings, distance metrics, seen timestamps, account-seen timestamps, risk score, and links to available match views.

The tool is built for analysts who need a clean, controlled, and reviewable interface for checking whether an adult public-model image appears across supported 18+ sources.

Results are heuristic and should be interpreted carefully. A visual match does not automatically prove identity, ownership, consent status, or account control.

🔍 How the Search Works

A user can start a search in one of two ways:

Supported upload formats include:

Maximum file size:

10 MB

If both a URL and a file are specified, the uploaded file has priority.

After the request is submitted, the backend creates a search job, processes the image, compares it against supported public 18+ model sources, and returns a ranked list of possible matches.

The tool supports reverse image analysis for adult public-model content only.

Accepted inputs:

Input Type Description
Image URL Direct or supported image URL
Local file upload JPEG, PNG, WebP, or GIF file
Adult public-model images Images that the user is authorized to analyze

Unsupported or prohibited inputs:

Users must ensure that every submitted image is lawful, authorized, and appropriate for adult-public-model analysis.

⚙️ Search Interface

The main search interface includes several core controls.

URL Images

Users can paste an image URL.

Example format:

https://...

URL searches may use short-term caching for repeatability.

File Upload

Users can upload a local image file.

Supported formats:

jpeg / png / webp / gif

Maximum size:

10 MB

If both URL and file are provided, the file upload is processed first.

Search Limit

The interface displays the current request limit and reset time.

Example:

Limit: 59 / reset 600s

This helps users understand remaining availability and rate-limit reset timing.

📊 Results Section

After a job is completed, the tool displays a structured results panel.

Possible result fields include:

Field Description
Matches Total number of returned matches
Job ID Unique backend job identifier
Status Processing status, such as finished
Created Job creation timestamp
Duration Backend processing duration
Risk Internal risk score
Risk level Low, medium, high, or another internal level
Platform statistics Match distribution by platform
Probability distribution Probability summary
Gender distribution f / m / c / u indicators
Distance metrics Minimum, average, and maximum distance
Job link Link to the job report, when available

Example status structure:

Status: finished
Duration: 1987 ms
Matches: 20
Risk: 25 Low

The results should be treated as investigative leads and manually reviewed.

🧠 Key Features

Reverse Image Search for 18+ OSINT

The tool performs visual search against public adult-model sources and returns possible matches.

Users can submit an image URL or upload a local file.

File Priority Logic

If both URL and file are submitted, the uploaded file is prioritized.

Short-Term URL Cache

URL searches may use an approximately five-minute cache window to improve repeatability and reduce unnecessary repeated processing.

Job-Based Processing

Each search creates a backend job with its own status, ID, creation timestamp, duration, and result set.

Platform Statistics

The system summarizes matches by source platform.

Example platform statistics may appear in a compact format such as:

cb:10 mfc:3 c4:3 bc:2 sc:1 sm:1

Platform labels are internal or source-specific abbreviations and should be interpreted according to the platform documentation or analyst context.

Distance Metrics

The tool provides distance values to help estimate visual similarity.

The smaller the distance value, the closer the match according to the system’s heuristic.

Probability Rating

The probability field shows an external or backend-provided rating.

This value may often be “low” and should not be treated as a final confidence conclusion by itself.

Risk Score

The risk score is a simple internal evaluation based on the saturation and characteristics of returned matches.

It is intended for triage and prioritization, not as a legal or identity conclusion.

Filtering

Users can filter results by:

Export

The current results table can be exported to CSV for internal review or case documentation.

Metadata-Only History

Request history stores only metadata such as URL hash or file hash. Images are not saved.

📋 Results Table

The results table displays potential visual matches in a structured format.

Main columns may include:

Column Description
# Result position
Platform Source platform abbreviation
Model Public model/account name returned by the system
Gender Gender indicator
Distance Visual similarity distance
Probability Probability rating
Seen First or related seen timestamp
AccountSeen Account-level seen timestamp
Links Available match views, such as Face or Full

📏 Distance Interpretation

The Distance value is one of the most important technical indicators in the report.

General interpretation:

Distance Meaning
Lower value Closer visual match
Higher value Weaker visual similarity
Similar range Requires manual comparison

Distance is heuristic. It does not prove identity, model ownership, account control, consent, or exact duplication.

Analysts should compare multiple factors before making conclusions:

🎯 Probability Interpretation

The Probability field reflects an external or backend-provided rating.

Common values may include:

In many cases, returned results may be marked as “low,” even when the visual distance is close. Probability should therefore be interpreted together with distance, source platform, result rank, and manual review.

A low probability does not automatically mean the result is irrelevant. A high probability does not automatically prove identity.

🚦 Risk Score

The Risk value is an internal evaluation that helps summarize the saturation and possible relevance of returned matches.

Example:

Risk 25 Low

Risk may consider signals such as:

Risk is intended for triage. It should not be used as a final judgment.

🧬 Gender Indicators

The results may include gender indicators.

Common values:

Indicator Meaning
f Female
m Male
c Couple
u Unknown

Gender indicators are source or model metadata signals and may not always be accurate. They should be treated as descriptive metadata, not identity verification.

🌐 Platform Statistics

The platform statistics section summarizes how results are distributed across supported source platforms.

Example:

Platforms
cb:10 mfc:3 c4:3 bc:2 sc:1 sm:1

This helps analysts understand whether matches are concentrated on one source or spread across multiple platforms.

A high number of matches on one platform may suggest repeated appearances, duplicate records, or platform-specific similarity clustering.

A broad spread across multiple platforms may require closer manual review.

🕒 Seen and AccountSeen

The report may include two timestamp fields.

Seen

The Seen value usually refers to when a specific visual match, image, or record was observed by the source system.

AccountSeen

The AccountSeen value usually refers to when the related account or model profile was observed.

These timestamps are useful for understanding historical presence and recency.

They do not prove that the account is currently active.

Results may provide links such as:

Face

A face-focused view may help compare facial similarity.

Full

A full-image view may help compare broader context, body position, background, outfit, image composition, or duplicated content.

Analysts should use both views when available and avoid relying on a single visual cue.

💾 Request History

The Request History (18+) section stores previous search metadata.

Important privacy behavior:

Only stores search metadata (URL SHA1 / file SHA1). Images are not saved.

History may include:

This allows users to review past searches without storing the original uploaded images.

Request history should still be treated as sensitive metadata because it may reveal investigative activity.

📤 Export

The export function dumps the current results table into CSV.

CSV export may include:

Exported files should be stored securely and shared only with authorized recipients.

When used for moderation, compliance, or investigation, exports should follow internal data-handling policies.

A careful review process should follow these steps.

1. Confirm Authorization

Before uploading any image, confirm that the image is lawful to analyze and belongs to an adult public model or an authorized moderation workflow.

2. Choose Input Method

Use either a URL or a local file. If both are submitted, remember that the file takes priority.

Submit the request and wait for the job to finish.

4. Review the Summary

Check match count, job status, duration, risk score, platform distribution, probability distribution, gender distribution, and distance range.

5. Sort by Distance

Prioritize lower-distance results for manual review.

6. Check Face and Full Views

Use both visual perspectives where available.

7. Compare Context

Compare visual details, platform names, timestamps, and repeated matches.

8. Avoid Overclaiming

Use cautious language such as “possible match,” “visual similarity,” or “candidate result” unless verified by additional evidence.

9. Export Only When Needed

Export CSV only for authorized internal workflows.

10. Store Evidence Securely

Treat all results, links, hashes, and exports as sensitive investigation material.

🛡️ Security, Privacy & Ethics

Reverse Image Search 18+ is a sensitive tool and must be used responsibly.

Strictly prohibited use includes:

Acceptable use cases include:

Users must manually verify results and interpret them as technical similarity signals, not final identity conclusions.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Reverse Image Search 18+ (OSINT) is a specialized reverse image search tool for adult public-model intelligence, analytics, and moderation. It supports URL and file-based searches, compares images against supported public 18+ model sources, and returns structured results with platform statistics, visual distance metrics, probability ratings, gender indicators, risk score, timestamps, and review links.

The tool is designed for lawful, ethical, adult-only analysis. It must never be used for private-person identification, non-consensual searches, minors, harassment, doxxing, or abuse. All matches should be treated as heuristic visual-similarity leads and manually verified before any conclusion or action.

OSINT Tools

Exif Remove and Metadata Privacy | Local Image Metadata Cleaner

image.png

The platform available at https://dash.niamonx.io/exif_remove — known as Exif Remove and Metadata Privacy — is a privacy-focused image metadata inspection and cleaning tool within the NiamonX platform. It allows users to view, assess, export, and remove EXIF / metadata from images directly inside the browser, without sending image files to the server.

Overview of the Service

Exif Remove and Metadata Privacy is designed to help users protect themselves from accidental metadata exposure before publishing or sharing images online.

Images often contain hidden technical metadata, including device model, camera settings, software name, creation date, orientation, thumbnails, GPS coordinates, serial numbers, and editing history. This information can reveal sensitive details about the person, device, location, or workflow behind the image.

The tool allows users to inspect this metadata locally, assess privacy risk, remove metadata, optionally re-encode the image, and download a cleaned version.

The main privacy advantage of this module is that processing happens locally in the user’s browser. Images are not uploaded to the NiamonX server for metadata extraction or deletion.

🔍 How the Tool Works

When a user selects or drags an image into the tool, the browser reads the file locally and extracts available metadata.

The tool then displays detected tags, risk indicators, file type, file size, and metadata categories. The user can review the information before cleaning the file.

When metadata removal is requested, the tool redraws the image through the browser Canvas API. This creates a new image output without the original embedded EXIF metadata.

Depending on the selected output settings, the tool can:

The cleaned file can then be downloaded and safely used for publishing, sharing, reporting, or documentation.

🧩 Supported File Types

Exif Remove and Metadata Privacy supports common web image formats.

Supported formats:

The interface may also accept common browser-supported image representations depending on browser capabilities, but the recommended formats are JPEG, PNG, and WebP.

Up to approximately 50 MB per file

Unsupported or limited formats:

Newer formats such as HEIC and RAW are not supported on the Canvas side.

📁 Uploading Images

The upload area allows users to drag files into the interface or click to select files manually.

Example interface text:

Drag files here or click to select

Metadata is extracted locally after the file is selected.

Important privacy behavior:

Images are not sent to the server.
Metadata is extracted locally.

This makes the tool suitable for privacy-sensitive workflows where users need to inspect image metadata before publishing or transferring files.

⚙️ Output Settings

The tool provides several output configuration options.

Output Format

Users can choose how the cleaned file should be saved.

Typical option:

As the Original (auto)

This means the tool attempts to preserve the original format where possible.

Other possible output formats may include:

Format choice affects file size, quality, transparency, and compatibility.

Quality

For JPEG and WebP outputs, users can select image quality.

Example:

92%

Recommended privacy-friendly and quality-balanced range:

90–95%

Higher quality preserves more visual detail but may produce larger files. Lower quality reduces size but can introduce compression artifacts.

Limit the Long Side

Users can resize the image by limiting its longest side in pixels.

Example:

Without scaling

A practical option before publishing online is to reduce the long side to a value such as:

2048 px

This can reduce file size and limit unnecessary visual detail while preserving enough quality for web publishing.

Auto-Orientation

The tool can apply image orientation based on the original Orientation metadata.

This is important because many photos rely on EXIF Orientation to display correctly. If metadata is removed without applying orientation, the image may appear rotated incorrectly.

Auto-orientation helps preserve the visible appearance of the image after cleaning.

Keep Transparency

For images with transparency, such as PNG files, the tool can preserve alpha transparency when possible.

Important note:

If PNG is converted to JPEG, transparency is lost because JPEG does not support alpha channels.

Delete Only

The “Delete only” option avoids unnecessary transcoding when the output format matches the original format.

This is useful when the user wants to remove metadata with minimal visual change.

However, depending on the browser and image format, some re-encoding may still be required to fully remove embedded metadata.

📊 File Summary

After upload, the tool displays a quick summary.

Example structure:

Files: 1
Cleaned: 0
Tags: 15

For each image, the interface may show:

Example file information:

Type: image/jpeg
Size: 1.2 MB
Metadata: 15 tags

🧾 Metadata Viewer

The metadata viewer displays detected EXIF and image metadata in a structured format.

Possible metadata fields include:

Example metadata categories:

Software
Orientation
PixelXDimension
PixelYDimension
thumbnail

The metadata view is useful because it allows users to understand exactly what hidden information exists before removing it.

🚨 Why Metadata Removal Matters

Image metadata can reveal more information than expected.

Possible privacy-sensitive metadata:

Metadata Type Privacy Risk
GPS coordinates Can reveal home, workplace, travel route, or private location
Device model Can identify the camera or phone used
Serial number Can link multiple images to the same physical device
Creation date/time Can reveal when the photo was taken
Software name Can reveal editing tools or workflow
Embedded thumbnail Can contain an older version of the image
Orientation and dimensions Usually low risk but still technical metadata
Author or copyright fields Can reveal identity or organization
File history May reveal editing or export chain

Before publishing images online, it is strongly recommended to check for GPS coordinates, serial numbers, device model, and creation time.

🧠 Risk Assessment

The tool includes a metadata risk assessment system.

Risk levels help users understand how sensitive the detected metadata may be.

High Risk

High-risk metadata may include:

Example risk interpretation:

High: GPS coordinates, exact time + serial number

High-risk images should be cleaned before publishing or sharing.

Medium Risk

Medium-risk metadata may include:

Example risk interpretation:

Medium: Device model, software, creation date

Medium-risk fields may not reveal location directly, but they can still support tracking, correlation, or device fingerprinting.

Info

Informational metadata may include:

Example risk interpretation:

Info: Size, orientation, basic tags

Informational metadata is usually lower risk but can still be removed for maximum privacy.

🧹 Metadata Removal Method

Exif Remove and Metadata Privacy removes metadata by redrawing the image in the browser Canvas.

This process creates a clean image output from pixel data rather than copying the original file structure with embedded metadata.

In practice, this helps remove:

Important note:

Some browser-generated outputs may still contain minimal format-level information required for valid images, but sensitive EXIF metadata is removed through the redraw/export process.

🔐 Local Processing and Privacy

The tool is designed around local browser-side processing.

Main privacy guarantees:

This makes the tool suitable for privacy-conscious users, journalists, investigators, security teams, and anyone who needs to clean images before sharing them.

🕓 Request History

The tool includes a local request history panel.

Important behavior:

Stored only locally in the browser.
No files or metadata are sent to the server.

The history may store up to a limited number of recent entries, such as:

Up to 50 entries

History entries may include:

Example categories shown in history may include:

The history is useful for reviewing recent local cleaning activity, but it should still be treated as sensitive local metadata on shared devices.

📤 JSON Export

The tool can export detected metadata as JSON.

This is useful for:

JSON exports may contain sensitive metadata. They should be stored securely and deleted when no longer needed.

📦 ZIP Upload and Bulk Processing

The tool supports ZIP upload or bulk processing workflows when available.

Bulk processing is useful when users need to clean multiple images before:

When cleaning many files, users should still review high-risk images manually, especially those that may contain GPS or device identifiers.

📉 Size Comparison

After cleaning or re-encoding images, the tool can help compare original and output file sizes.

Size differences may occur because of:

A cleaned image may be much smaller if the original file contained large embedded metadata or thumbnail previews.

🖼️ Format and Quality Considerations

JPEG

Best for photos and general publishing.

Pros:

Cons:

PNG

Best for screenshots, logos, graphics, and transparency.

Pros:

Cons:

WebP

Best for modern web publishing.

Pros:

Cons:

⚠️ Re-Compression Warning

Repeated compression can degrade image quality.

For best results:

A careful image-cleaning workflow should follow these steps.

1. Upload the Image Locally

Drag the file into the tool or select it manually.

2. Review Metadata

Check all detected metadata before cleaning.

3. Look for High-Risk Tags

Prioritize GPS, serial number, device model, creation time, and embedded thumbnails.

4. Choose Output Settings

Select format, quality, orientation, resizing, and transparency options.

5. Remove Metadata

Generate the cleaned image.

6. Compare File Size

Review whether the cleaned image size changed significantly.

7. Download the Cleaned File

Use the cleaned version for publishing or sharing.

8. Recheck If Needed

Upload the cleaned image again to confirm that metadata was removed.

9. Store Originals Safely

Keep original images private if they contain sensitive metadata.

10. Clear Local History on Shared Devices

If using a shared or public computer, clear browser history and local storage after processing.

🛡️ Security, Privacy & Ethics

Exif Remove and Metadata Privacy is designed for privacy protection, responsible publishing, and safe image sharing.

Acceptable use cases include:

Users should use the tool responsibly:

For forensic or legal investigations, metadata removal should be performed only on working copies, never on original evidence.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Exif Remove and Metadata Privacy is a local browser-based privacy tool for inspecting and removing EXIF / metadata from JPEG, PNG, and WebP images.

It helps users detect sensitive metadata such as GPS coordinates, device model, serial number, software, creation time, thumbnails, and other hidden tags before publishing images online.

The tool processes files locally, does not send images or metadata to the server, supports output format and quality control, provides risk assessment, enables JSON export, and stores only local browser history. It is designed for privacy protection, safer publishing, security workflows, and responsible image handling.

OSINT Tools

Flight Information | Flight Search & Aviation Intelligence

image.png

The platform available at https://dash.niamonx.io/flightinfo — known as Flight Information — is an aviation intelligence and flight lookup tool within the NiamonX platform. It allows users to search for flight information by IATA or ICAO flight number and receive a structured report with route, status, departure details, arrival details, aircraft data, telemetry fields, timestamps, and local browser-based request history.

Overview of the Service

Flight Information is designed to help users quickly check the current or recent status of a commercial or private flight using standard aviation flight identifiers.

The tool supports both IATA and ICAO flight number formats and can automatically detect the correct query mode. It returns a clean, structured flight summary that is useful for aviation monitoring, travel verification, logistics coordination, OSINT workflows, executive protection, airport operations review, and general flight status checks.

The interface is built to be simple and fast. A user enters a flight number, selects or keeps auto-detection mode, and receives a readable flight report containing departure and arrival airports, gates, terminals, scheduled or updated times, status, route, and available aircraft or telemetry fields.

Access depends on the user’s plan and daily tool limits.

🔍 How the Search Works

When a user enters a flight number, the tool checks the query using the selected mode.

Available modes include:

In Auto detect mode, the system attempts to determine whether the entered value is an IATA-style or ICAO-style flight number.

Examples:

AA6

AAL6

The backend then returns available flight information and displays it in a structured format.

If the flight is found, the report may include:

Flight Information is intended for flight number lookup.

Supported query types:

Query Type Example Description
IATA flight number AA6 Airline IATA code + flight number
ICAO flight number AAL6 Airline ICAO code + flight number
Auto-detected flight number IB8539 The system detects the likely mode

The user should enter only the flight identifier.

IB8539

SK2624

SAS2624

Unsupported input examples:

Miami to Newark

MIA EWR 17 June

https://example.com/flight/IB8539

American Airlines flight from Miami tomorrow

For best results, users should enter a clean IATA or ICAO flight number.

⚙️ Controls and Interface

The Flight Information interface includes several core sections.

Controls

The controls area shows search mode, filters, query limits, and client-side interface status.

Example indicators:

Auto-detect · Filters
Client-side

Query Counter

The query counter shows remaining and total daily requests.

Example:

148 / 150
Queries remaining / total
Plan: Sentinel

This helps users understand how many flight searches remain under the current plan.

Find Flight

The Find Flight section is the main search area.

It contains:

Example:

Mode: Auto detect
Query: IB8539

📊 Flight Result Summary

After a successful lookup, the tool displays the flight route and status.

Example structure:

IB8539
MIA → EWR
Status: en-route
2026-06-17 18:46:52 UTC

The summary helps the user quickly understand:

Common flight statuses may include:

The exact statuses depend on the data returned by the backend source.

🛫 Departure Section

The Departure section contains information about the origin airport and departure event.

Possible fields include:

Field Description
Airport Departure airport in IATA and ICAO format
Terminal Departure terminal
Gate Departure gate
Time local Local departure time at the airport
Time UTC Departure time converted to UTC
Updated UTC Last update timestamp for departure data

Example departure structure:

Airport: MIA (KMIA)
Terminal: N
Gate: D10
Time local: 2026-06-17 13:35
Time UTC: 2026-06-17 17:35
Updated UTC: 2026-06-17 17:30

This section is useful for confirming where the flight departed from, whether gate or terminal information is available, and whether departure timing has been updated.

🛬 Arrival Section

The Arrival section contains information about the destination airport and arrival event.

Possible fields include:

Field Description
Airport Arrival airport in IATA and ICAO format
Terminal Arrival terminal
Gate Arrival gate
Baggage Baggage belt or claim area
Time local Local arrival time at the airport
Time UTC Arrival time converted to UTC
Updated UTC Last update timestamp for arrival data

Example arrival structure:

Airport: EWR (KEWR)
Terminal: A
Gate: 11
Baggage: 4
Time local: 2026-06-17 16:39
Time UTC: 2026-06-17 20:39
Updated UTC: 2026-06-17 20:23

This section is especially useful for travel coordination, passenger pickup planning, logistics, and airport operations review.

✈️ Aircraft Section

The Aircraft section displays available aircraft-related information.

Possible fields include:

Field Description
Registration Aircraft tail number or registration
ICAO Type ICAO aircraft type code
Model Aircraft model
Manufacturer Aircraft manufacturer
Engines Engine information
Built / Age Build year and aircraft age
HEX Aircraft Mode-S / ADS-B hex identifier
MSN Manufacturer serial number

Some fields may be unavailable depending on the data provider, flight type, aircraft tracking availability, or privacy restrictions.

If aircraft details are unavailable, the interface may show:

—

This means the field was not returned or could not be confirmed for the selected flight.

📡 Telemetry Section

The Telemetry section displays live or recent aircraft movement data when available.

Possible telemetry fields include:

Field Description
Position Current or last known position
Heading Direction of travel
Altitude Current or last known altitude
Speed Ground speed or reported speed
V-Speed Vertical speed
Squawk Transponder squawk code

If telemetry is unavailable, the tool may display empty fields or placeholder values.

Telemetry availability can depend on:

Telemetry should be treated as informational and may not always be real-time.

🧾 Result Table

The tool may also display a compact row-based result table.

A row may include:

Example compact format:

IB8539    MIA → EWR    en-route    2026-06-17 17:35    2026-06-17 20:39

The table can help users compare repeated lookups or scan recent results quickly.

Users can click a column header to sort results when sorting is available in the interface.

🕓 Request History

The Request History section stores recent searches locally in the user’s browser.

Example history behavior:

Stores last 100 queries in your browser.

History entries may include:

Example history item:

auto
IB8539
MIA → EWR
17.06.2026, 21:35:37

Request history is useful for quickly revisiting previous flight checks without retyping the flight number.

Because the history is stored in the browser, it may be cleared if the user deletes browser data, switches devices, or uses another browser profile.

🧠 Key Features

The tool supports both common flight identifier formats.

Auto-Detection

Auto mode attempts to detect whether the query is IATA or ICAO.

Structured Flight Report

Results are displayed in a readable layout with departure, arrival, aircraft, and telemetry sections.

Local and UTC Times

The report shows both local airport time and UTC time when available.

Gate, Terminal, and Baggage Details

The tool can display airport operation details such as terminal, gate, and baggage claim.

Aircraft Details

When available, the report includes aircraft registration, type, model, manufacturer, engines, HEX, and MSN.

Telemetry Fields

The tool can display position, heading, altitude, speed, vertical speed, and squawk when available.

Client-Side Controls

Filtering and interface controls are handled client-side for a fast user experience.

Request History

The last 100 queries are stored locally in the browser.

Plan-Based Access

Daily query limits depend on the user’s plan.

🚦 Daily Queries and Plan Limits

Flight Information uses plan-based daily query limits.

Example:

148 / 150
Queries remaining / total
Plan: Sentinel

Limits help control usage, protect backend availability, and provide predictable access across user plans.

Users should monitor the remaining query counter when performing multiple searches.

🧭 IATA vs ICAO

Flight Information supports both IATA and ICAO flight identifiers.

IATA Flight Number

IATA flight numbers usually use a two-character airline code followed by a flight number.

Example:

AA6

ICAO Flight Number

ICAO flight numbers usually use a three-letter airline code followed by a flight number.

Example:

AAL6

Auto Detect

Auto-detect mode tries to determine the correct format automatically.

If the result seems incorrect or no flight is found, users can manually switch between IATA and ICAO mode.

🧠 Result Interpretation

Flight data should be interpreted carefully.

Important interpretation notes:

The tool is useful for fast lookup and monitoring, but critical operational decisions should be confirmed with the airline, airport, or official aviation data source when necessary.

A practical flight lookup workflow should follow these steps.

1. Enter the Flight Number

Use a clean IATA or ICAO flight number.

2. Start With Auto Detect

Use Auto detect first unless you already know the identifier type.

3. Review the Route

Confirm that the origin and destination match the expected flight.

4. Check the Status

Look for status such as scheduled, en-route, landed, delayed, or cancelled.

5. Review Departure Details

Check departure airport, terminal, gate, local time, UTC time, and update timestamp.

6. Review Arrival Details

Check arrival airport, terminal, gate, baggage belt, local time, UTC time, and update timestamp.

7. Check Aircraft and Telemetry

Use aircraft and telemetry fields when available, but remember that they may be incomplete.

8. Save or Reuse History

Use local request history to revisit previous queries.

9. Verify Critical Details

For time-sensitive travel, logistics, or operational decisions, confirm with official airline or airport sources.

🛡️ Security, Privacy & Responsible Use

Flight Information is intended for lawful aviation information lookup and operational awareness.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Flight Information is a flight lookup and aviation intelligence tool that allows users to search for flights by IATA or ICAO identifier and receive a structured report with route, status, departure details, arrival details, aircraft fields, telemetry fields, timestamps, and local request history.

The tool is designed for travel verification, logistics support, aviation OSINT, corporate monitoring, passenger coordination, and operational awareness. Results should be treated as informational and verified with official airline or airport sources for critical decisions.

OSINT Tools

Flight Schedules | Departures, Arrivals & Airline Schedule Intelligence

image.png

The platform available at https://dash.niamonx.io/flight_schedules — known as Flight Schedules — is a flight schedule intelligence tool within the NiamonX platform. It allows users to search real-time airport schedules by departure airport, arrival airport, airline, specific flight number, flight status, and delay filters.

Overview of the Service

Flight Schedules provides a structured view of current and near-future flight movements. The tool is designed to show departure and arrival queues for up to approximately 12 hours ahead, depending on the available data source and selected filters.

Unlike a single-flight lookup tool, Flight Schedules is built for broader schedule monitoring. It helps users analyze groups of flights from or to a specific airport, filter by airline, search for a specific flight, review operational status, identify delays, and export results for further analysis.

The module is useful for travel coordination, logistics, aviation OSINT, airport monitoring, corporate travel tracking, incident response support, executive protection workflows, and operational awareness.

Access depends on the user’s plan and daily tool limits.

🔍 How the Search Works

The user selects one or more search fields and submits a schedule query. The system then searches the flight schedule database and returns matching flights in a structured table.

The tool supports multi-criteria search, meaning users can combine multiple filters to narrow results.

Example search combinations:

For example, a user can search all departures from Miami International Airport using:

Departure IATA: MIA

Or combine filters such as:

Departure IATA: MIA
Airline IATA: AA
Status: active

The result is a schedule table with flight numbers, route, airline, status, departure and arrival times, terminal and gate details, flight duration, and delay indicators when available.

Flight Schedules supports several search fields.

Departure Airport

Users can search by departure airport using either IATA or ICAO code.

Examples:

MIA

KMIA

Arrival Airport

Users can search by arrival airport using either IATA or ICAO code.

Examples:

SFO

KSFO

Airline

Users can filter by airline using IATA or ICAO airline code.

Examples:

AA

AAL

Multiple airlines can be entered as a comma-separated list.

Example:

AA,BA,DL

Flight Number

Users can search for a specific flight by IATA or ICAO flight number.

Examples:

AA2421

AAL2421

Status

Users can filter schedules by operational status.

Possible values may include:

The exact available statuses depend on backend data.

Delay Filter

Users can search for flights with delay greater than or equal to a selected number of minutes.

Example:

Delay ≥ 30

This is useful for quickly identifying disrupted flights.

⚙️ Search Interface

The Flight Schedules interface contains several main search controls.

Departure IATA

Search by departure airport IATA code.

Example:

MIA

Departure ICAO

Search by departure airport ICAO code.

Example:

KMIA

Arrival IATA

Search by arrival airport IATA code.

Example:

SFO

Arrival ICAO

Search by arrival airport ICAO code.

Example:

KSFO

Airline IATA

Filter by one or more airline IATA codes.

Example:

AA,BA

Airline ICAO

Filter by one or more airline ICAO codes.

Example:

AAL,BAW

Flight IATA

Search by IATA-style flight number.

Example:

AA2421

Flight ICAO

Search by ICAO-style flight number.

Example:

AAL2421

Status

Filter by flight status.

Default value:

Any

Delay ≥

Filter flights with a delay greater than or equal to the selected number of minutes.

Example:

30

📊 Schedule Results

After a successful search, the tool displays a schedule summary and a table of matching flights.

The summary may include:

Example summary structure:

DEP_IATA: MIA
Results: 100
Airlines: 37
From: MIA
To: DTW, DCA, MCO, MGA, PHL, BWI, YYZ
Window: 2026-06-17 13:00 UTC → 2026-06-18 00:08 UTC

This gives users a fast overview of the searched airport schedule and the range of returned flights.

📋 Results Table

The main results table displays flight records in a compact operational format.

Typical columns may include:

Column Description
Flight Flight number
Airline Airline IATA code
Route Departure and arrival airports
Status Flight status
Departure time Scheduled or updated departure time
Arrival time Scheduled or updated arrival time
Departure terminal / gate Departure terminal and gate
Arrival terminal / gate Arrival terminal and gate
Duration Flight duration in minutes
Departure delay Departure delay, if available
Arrival delay Arrival delay, if available

Example row:

AA3310    AA    MIA → DCA    active    2026-06-17 17:41    2026-06-17 20:25    N / D38    2 / C32    164

The table is intended for quick scanning and comparison.

Users can click column headers to sort results when sorting is available.

🛫 Departures

When searching by departure airport, the tool shows flights leaving the selected airport within the current schedule window.

Departure-focused use cases:

Example:

Departure IATA: MIA

This returns flights departing from Miami International Airport.

🛬 Arrivals

When searching by arrival airport, the tool shows flights arriving at the selected airport within the current schedule window.

Arrival-focused use cases:

Example:

Arrival IATA: EWR

This returns flights arriving at Newark Liberty International Airport.

🏢 Airline Filtering

The tool supports airline filtering by IATA or ICAO code.

This is useful when users need to focus on one airline or a group of airlines.

Example:

Airline IATA: AA,BA

This can return only flights operated or listed under American Airlines and British Airways codes, depending on backend data.

Airline filtering is especially useful for:

✈️ Flight Number Search

Users can search for a specific flight using IATA or ICAO flight number fields.

Examples:

Flight IATA: EK164

Flight ICAO: UAE164

This is useful when a user wants schedule-table context for one specific flight rather than a full airport queue.

If the exact flight is not found, users should verify whether the flight number is IATA or ICAO and try the matching field.

⏱️ Time Window

Flight Schedules shows the current queue for up to approximately 12 hours ahead.

The result summary may show the schedule window in UTC.

Example:

Window: 2026-06-17 13:00 UTC → 2026-06-18 00:08 UTC

The time window helps users understand which period is covered by the returned results.

Important interpretation notes:

🧠 Key Features

Multi-Criteria Search

Users can combine departure airport, arrival airport, airline, flight number, status, and delay filters.

Departure and Arrival Monitoring

The tool supports both outbound and inbound schedule analysis.

Airline Filtering

Users can filter by one or more airlines using comma-separated codes.

Specific Flight Lookup

The module supports direct flight number filtering.

Status Filtering

Users can narrow results by operational status.

Delay Filtering

The delay filter helps identify flights with disruption above a selected threshold.

Sortable Results

Users can sort schedule rows by table columns.

CSV Export

Schedule results can be exported to CSV for spreadsheets, reporting, or operational workflows.

TXT Export

Flight codes can be exported as TXT for simple lists, scripts, or copy-paste workflows.

Local Request History

The last 100 schedule queries are stored locally in the browser.

Plan-Based Limits

Daily query limits depend on the user’s subscription plan and are enforced server-side.

📤 Export Options

Flight Schedules supports export for operational and analytical workflows.

CSV Export

CSV export is useful for:

TXT Export

TXT export can provide a plain list of flight codes.

This is useful for:

Exported files should be stored appropriately when they contain operationally sensitive travel information.

🕓 Request History

The Request History section stores the last 100 queries in the user’s browser.

History entries may include:

Example history entry:

MIA → —
Airlines: any
Flight: any
17.06.2026, 21:37:41

Request history is stored locally and helps users quickly repeat previous searches.

Because it is browser-based, history may be cleared when the user deletes local browser data or switches devices.

🚦 Daily Queries and Plan Limits

Flight Schedules uses plan-based query limits.

Example:

148 / 150
Queries remaining / total
Plan: Sentinel

Important points:

🧭 IATA and ICAO Codes

The tool supports both IATA and ICAO code formats.

Airport Codes

IATA airport codes are usually three letters.

Examples:

MIA
SFO
EWR

ICAO airport codes are usually four letters.

Examples:

KMIA
KSFO
KEWR

Airline Codes

IATA airline codes are usually two characters.

Examples:

AA
BA
DL

ICAO airline codes are usually three letters.

Examples:

AAL
BAW
DAL

Flight Numbers

IATA flight numbers usually start with an IATA airline code.

Example:

AA2421

ICAO flight numbers usually start with an ICAO airline code.

Example:

AAL2421

Using the correct code type improves result accuracy.

🧠 Result Interpretation

Flight schedule data should be interpreted as operational information that may change quickly.

Important notes:

Codeshare behavior is especially important. Multiple airlines may show identical route, time, terminal, and gate information because they refer to the same operating flight under different marketing flight numbers.

A practical schedule search workflow should follow these steps.

Select whether you want to search by departure, arrival, airline, flight number, status, or delay.

2. Enter Airport or Airline Codes

Use IATA or ICAO codes depending on the field.

3. Combine Filters When Needed

For example, use departure airport plus airline code to narrow results.

4. Review the Summary

Check number of results, airlines, route coverage, and time window.

5. Sort the Table

Sort by departure time, arrival time, status, airline, route, or delay.

6. Identify Codeshares

Look for rows with identical route and times but different airline codes.

7. Check Delays

Use the delay filter or delay columns to identify disruptions.

8. Export Results

Export CSV for structured analysis or TXT for flight code lists.

9. Use History for Repeated Queries

Open recent searches from browser history when checking the same airport repeatedly.

10. Verify Critical Data

Confirm important travel or operational decisions through official sources.

🛡️ Security, Privacy & Responsible Use

Flight Schedules is intended for lawful aviation schedule lookup and operational awareness.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Flight Schedules is a real-time flight schedule intelligence tool for searching departures, arrivals, airlines, specific flights, statuses, and delays.

It supports multi-criteria search by airport IATA / ICAO, airline IATA / ICAO, flight IATA / ICAO, operational status, and minimum delay. The tool returns structured schedule tables with routes, times, terminals, gates, durations, delays, result summaries, export options, and browser-based request history.

Flight Schedules is designed for travel coordination, airport monitoring, aviation OSINT, logistics, corporate travel visibility, and operational awareness. Results should be treated as informational and verified with official airline or airport sources when used for critical decisions.

OSINT Tools

Flight Delay | Real-Time Flight Delay Monitoring

image.png

The platform available at https://dash.niamonx.io/flight_delay — known as Flight Delay — is a real-time aviation delay monitoring tool within the NiamonX platform. It allows users to track delayed departures and arrivals worldwide, filter results by airport, airline, flight number, status, and minimum delay threshold, and export delay intelligence for operational analysis.

Overview of the Service

Flight Delay is designed to help users monitor current flight disruptions in real time. The tool provides a structured view of delayed flights and allows users to focus on departures, arrivals, specific airports, airlines, routes, or individual flight numbers.

Unlike general flight search, which focuses on one flight, and flight schedules, which shows a broader airport queue, Flight Delay is optimized for disruption monitoring. It highlights flights affected by delay conditions and helps analysts quickly identify where operational problems are occurring.

The tool is useful for:

Results reflect current operations and should be treated as operational intelligence that may change quickly.

🔍 How the Tool Works

The user selects whether they want to monitor Departures or Arrivals, sets a minimum delay threshold, and optionally adds filters such as airport, airline, flight number, or status.

The system then searches real-time delay data and returns matching flights in a structured table.

Example search configuration:

Type: Departures
Min delay: 60 minutes
Status: Any

The result table may include flights from many airports and airlines when no specific airport filter is applied. When airport, airline, or flight filters are added, the output becomes more focused.

The tool supports multi-criteria filtering, so users can combine several conditions for precise monitoring.

Example combinations:

Departures
Minimum delay: 60 minutes
Departure IATA: MIA
Airline IATA: AA

Arrivals
Minimum delay: 30 minutes
Arrival IATA: JFK
Status: active

Departures
Flight number: 2421
Minimum delay: 30 minutes

🧩 What Can Be Monitored

Flight Delay can monitor delayed flights using several types of filters.

Supported monitoring dimensions:

This allows users to monitor delays globally or narrow the view to a specific route, airline, airport, or flight.

⚙️ Filter Interface

The Flight Delay interface contains a set of filter controls.

Type

The user selects the delay type to monitor.

Available modes:

Departures focuses on delayed outbound flights.

Arrivals focuses on delayed inbound flights.

Min Delay

The minimum delay threshold determines which flights appear in the results.

Example:

Min delay: 60

This means only flights with a delay greater than or equal to 60 minutes should be returned.

The interface may also show quick helper text such as:

≥ 30 minutes

Common threshold examples:

Threshold Use Case
15 minutes Minor delay monitoring
30 minutes Standard disruption monitoring
60 minutes Significant delay monitoring
90 minutes Serious operational disruption
120+ minutes Major delay review

A higher threshold produces fewer but more severe results.

Departure IATA

Filters results by departure airport using a three-letter IATA airport code.

Example:

MIA

Use this when monitoring delays for flights departing from a specific airport.

Departure ICAO

Filters results by departure airport using a four-letter ICAO airport code.

Example:

KMIA

ICAO codes are useful when IATA codes are ambiguous or when working with aviation-specific systems.

Arrival IATA

Filters results by arrival airport using a three-letter IATA airport code.

Example:

SFO

Use this when monitoring delayed flights arriving at a specific airport.

Arrival ICAO

Filters results by arrival airport using a four-letter ICAO airport code.

Example:

KSFO

Airline IATA

Filters results by airline using one or more IATA airline codes.

Example:

AA,BA

Comma-separated values are allowed, which makes it possible to monitor several airlines in one query.

Airline ICAO

Filters results by airline using one or more ICAO airline codes.

Example:

AAL,BAW

This is useful for aviation analysts who work with ICAO identifiers.

Flight IATA

Filters results by a full IATA-style flight code.

Example:

AA2421

Flight ICAO

Filters results by a full ICAO-style flight code.

Example:

AAL2421

Flight Number

Filters results by the numeric flight number only.

Example:

2421

This can be useful when the airline code is uncertain or when comparing codeshare flights.

Status Filter

Filters flights by operational status.

Default value:

Any

Possible status values may include:

The exact returned statuses depend on the backend aviation data source.

📊 Delay Results Summary

After a search is completed, the tool displays a summary of the returned delay data.

The summary may include:

Example summary structure:

DEPARTURES, ≥ 60 min
Results: 100
Max delay: 1000 min
Airlines: 52

This summary helps users quickly understand the scale of current delays and whether the result set is broad or focused.

📋 Results Table

The results table displays delayed flights in a compact operational format.

Typical columns include:

Column Description
Flight Flight code
Airline Airline IATA code
Route Departure and arrival airport
Status Current operational status
Departure time Scheduled or updated departure time
Arrival time Scheduled or updated arrival time
Departure terminal / gate Departure terminal and gate, if available
Arrival terminal / gate Arrival terminal and gate, if available
Duration Flight duration or scheduled travel time in minutes
Departure delay Departure delay in minutes
Arrival delay Arrival delay in minutes

Example row format:

AA5395    AA    SDF → CLT    landed    2026-06-17 16:00    2026-06-17 17:37    B2    E43    102    102    95

The table is designed for fast scanning, sorting, and export.

🛫 Departure Delay Monitoring

When the type is set to Departures, the tool focuses on delayed outbound flights.

This mode is useful for:

Example use case:

Show all departures delayed by at least 60 minutes.

With additional filters:

Show all MIA departures delayed by at least 60 minutes.

🛬 Arrival Delay Monitoring

When the type is set to Arrivals, the tool focuses on delayed inbound flights.

This mode is useful for:

Example use case:

Show all arrivals into JFK delayed by at least 30 minutes.

🏢 Airline Delay Filtering

The tool supports airline-based filtering using IATA or ICAO airline codes.

This is useful for identifying whether delays are concentrated around a specific carrier.

Example:

Airline IATA: AA,BA,DL

Airline filtering can help with:

Because codeshares may appear as multiple flight numbers for the same physical flight, analysts should review rows with identical routes, times, gates, and delay values carefully.

✈️ Flight-Specific Delay Search

Users can filter by a specific flight using:

Examples:

Flight IATA: AA2421

Flight ICAO: AAL2421

Flight number: 2421

This is useful when monitoring a particular flight that may be delayed, cancelled, or affected by operational changes.

⏱️ Delay Values

Delay values are shown in minutes.

The table may include several delay-related columns, depending on the returned data.

Common delay indicators:

Delay Field Meaning
Main delay Overall delay value used for filtering
Departure delay Delay affecting departure
Arrival delay Delay affecting arrival

For departures, the departure delay is usually most relevant.

For arrivals, the arrival delay is usually most relevant.

However, both values can be useful because a flight may depart late and recover some time en route, or depart with a small delay and arrive with a larger delay due to routing, congestion, weather, or holding patterns.

🚨 Max Delay

The summary may show a maximum delay value.

Example:

Max delay: 1000 min

This helps users quickly identify the severity of the largest delay in the current result set.

A very high delay value should be reviewed carefully because it may indicate:

For critical use, high-delay records should be validated with official airline or airport sources.

🧠 Key Features

Real-Time Delay Monitoring

The tool monitors current delayed flights and returns operationally relevant results.

Departures and Arrivals

Users can choose whether to focus on delayed departures or delayed arrivals.

Configurable Delay Threshold

Minimum delay can be adjusted to focus on minor, moderate, or severe disruptions.

Airport Filters

Users can filter by departure or arrival airport using IATA or ICAO codes.

Airline Filters

Users can filter by one or more airlines using comma-separated IATA or ICAO codes.

Flight Filters

Users can search by full IATA flight code, full ICAO flight code, or numeric flight number.

Status Filtering

Results can be filtered by operational status.

Sortable Table

Users can click table headers to sort results.

CSV Export

Results can be exported to CSV for structured analysis.

TXT Export

Flight lists can be exported to TXT for quick operational use.

Local Request History

Recent queries are stored locally in the browser.

Plan-Based Limits

Daily query limits are enforced server-side according to the user’s plan.

📤 Export Options

Flight Delay supports export for operational and analytical workflows.

CSV Export

CSV export is useful for:

TXT Export

TXT export is useful when users need a plain list of delayed flight numbers.

Possible use cases:

Exported delay data may contain operationally sensitive travel information and should be stored appropriately.

🕓 Request History

The Request History section stores recent delay searches locally in the browser.

Example behavior:

Stores last 100 queries in your browser.

History entries may include:

Example history format:

DEPARTURES
— → —
≥ 60 min
Airline: any
Flight: any
17.06.2026, 21:40:19

Local history helps users repeat common monitoring queries quickly.

Because it is browser-local, history may be cleared by deleting browser data or using another device.

🚦 Query Limits and Plan Access

Flight Delay uses plan-based query limits.

Example:

149 / 150
Queries remaining / total
Plan: Sentinel

Important points:

🧭 IATA and ICAO Reference

The tool supports both IATA and ICAO identifiers.

Airport IATA

Three-letter airport code.

Examples:

MIA
JFK
SFO

Airport ICAO

Four-letter airport code.

Examples:

KMIA
KJFK
KSFO

Airline IATA

Two-character airline code.

Examples:

AA
BA
DL

Airline ICAO

Three-letter airline code.

Examples:

AAL
BAW
DAL

Flight IATA

IATA airline code plus flight number.

Example:

AA2421

Flight ICAO

ICAO airline code plus flight number.

Example:

AAL2421

Using the correct identifier type improves result accuracy.

🧠 Result Interpretation

Flight delay data should be interpreted carefully because flight operations change quickly.

Important interpretation rules:

The tool is designed for monitoring and analysis, not as a single source of truth for safety-critical decisions.

A practical delay monitoring workflow should follow these steps.

1. Select Delay Type

Choose Departures or Arrivals depending on the monitoring objective.

2. Set Minimum Delay

Use 30 minutes for general disruption monitoring or 60+ minutes for more serious delay analysis.

3. Add Airport Filters

Use departure or arrival IATA / ICAO codes to focus on a specific airport.

4. Add Airline Filters

Use airline filters to monitor one or more carriers.

5. Add Flight Filters When Needed

Use full flight codes or numeric flight number for a specific flight.

6. Review Summary

Check result count, maximum delay, airlines, and route spread.

7. Sort the Table

Sort by delay, departure time, arrival time, route, airline, or status.

8. Identify Codeshares

Look for identical routes, times, and delays under different flight numbers.

9. Export Results

Use CSV for structured analysis or TXT for simple flight lists.

10. Verify Critical Cases

Confirm severe delays, cancellations, and passenger-impacting events with official sources.

🛡️ Security, Privacy & Responsible Use

Flight Delay is intended for lawful aviation monitoring and operational awareness.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Flight Delay is a real-time delay monitoring tool for tracking delayed departures and arrivals worldwide.

It supports configurable minimum delay thresholds, airport filters, airline filters, flight filters, status filtering, sortable tables, CSV export, TXT flight-list export, local browser history, and plan-based query limits.

The tool is designed for aviation operations, travel coordination, airport disruption monitoring, logistics, corporate travel visibility, aviation OSINT, and incident response support. Results should be treated as current operational intelligence and verified with official airline or airport sources for critical decisions.

OSINT Tools

Flight Tracker | Real-Time ADS-B Flight Monitoring

image.png

The platform available at https://dash.niamonx.io/flight_tracker — known as Flight Tracker — is a real-time flight tracking and aviation intelligence tool within the NiamonX platform. It allows users to monitor active flights using live ADS-B data and filter aircraft by map region, flight code, airline, route, aircraft identifier, speed, altitude, country flag, and operational status.

Overview of the Service

Flight Tracker is designed to provide a live operational view of active flights worldwide. The tool collects and displays real-time aircraft movement data, allowing users to track individual flights or analyze broader air traffic activity across selected regions.

Unlike static schedule tools, Flight Tracker focuses on aircraft that are currently active or recently observed through live aviation telemetry. It provides position, speed, altitude, heading, aircraft type, registration, route, airline, and update timestamp when available.

The tool is useful for:

No raw upstream data is shown in the interface. Results are cleaned and displayed in an analyst-friendly table.

🔍 How the Tool Works

The user can run a broad search for all active flights or narrow the query using one or more filters.

Supported filtering options include:

The backend returns matching active flights, and the interface displays them in a sortable table.

All active flights

Example filtered search:

Airline IATA: BA
Dep IATA / ICAO: LHR
Arr IATA / ICAO: JFK

Example regional search:

Bounding box: 40.5,-74.5,41.2,-73.2

This makes it possible to monitor either one specific aircraft or thousands of active flights across a larger region.

🧩 What Can Be Tracked

Flight Tracker can be used to track or filter flights by several aviation identifiers.

Supported search and filter types:

Filter Type Example Description
Bounding box 40.5,-74.5,41.2,-73.2 Limits results to a map region
Flight IATA AA100 IATA-style flight code
Flight ICAO AAL100 ICAO-style flight code
Flight number 100 Numeric flight number
HEX / Reg A1B2C3 or N123AA ICAO24 hex or aircraft registration
Airline IATA AA,BA One or more airline IATA codes
Airline ICAO AAL,BAW One or more airline ICAO codes
Flag US,GB Aircraft or operator country flag
Departure airport JFK or KJFK Departure airport IATA / ICAO
Arrival airport LHR or EGLL Arrival airport IATA / ICAO
Status Any Operational status filter

The tool can be used for both single-flight lookups and wide-area monitoring.

⚙️ Tracking Interface

The Flight Tracker interface contains several main sections.

Controls

The controls panel shows that the tool supports:

BBox · Flight · Airline
Client-side

This means users can filter by geographic bounding box, flight identifiers, and airline-related fields.

Query Counter

The interface displays current daily query limits.

Example:

149 / 150
Queries remaining / total
Plan: Sentinel

Daily access depends on the user’s plan, and limits are enforced server-side.

Track Flights

The main tracking panel contains all filters used to search live flight data.

🗺️ Bounding Box Filter

The Bounding Box filter limits results to a selected geographic region.

Input format:

SW lat, SW lng, NE lat, NE lng

Example:

40.5,-74.5,41.2,-73.2

This means:

Bounding boxes are useful for:

Example use case:

Show active flights around New York airspace.

🔎 Zoom

The Zoom option helps control how map or regional results are interpreted.

Default value:

Auto

Auto zoom allows the interface to choose an appropriate view based on the query and returned data.

Zoom is most useful when combined with a bounding box or map-based workflow.

🚀 Minimum Speed Filter

The Min speed filter allows users to return only flights above a selected speed.

Unit:

km/h

This is useful for excluding stationary or slow-moving aircraft.

Example use cases:

🛫 Minimum Altitude Filter

The Min altitude filter allows users to return only aircraft above a selected altitude.

Unit:

m

This is useful for:

✈️ Flight Filters

Flight Tracker supports several flight-level filters.

Flight IATA

Search by IATA-style flight code.

Example:

AA100

Flight ICAO

Search by ICAO-style flight code.

Example:

AAL100

Flight Number

Search by numeric flight number only.

Example:

100

Flight number filtering is useful when the airline code is unknown or when checking possible codeshare variants.

🛩️ Aircraft HEX / Registration

The HEX / Reg field allows tracking by aircraft identifier.

Supported examples:

ICAO24 HEX

Aircraft registration

This is useful for tracking a specific aircraft rather than a scheduled flight number.

Possible use cases:

🏢 Airline Filters

The tool supports filtering by airline IATA or ICAO codes.

Airline IATA

Example:

AA,BA

Comma-separated values are allowed.

Airline ICAO

Example:

AAL,BAW

Airline filters are useful for:

🏳️ Flag Filter

The Flag filter accepts ISO-2 country codes.

Example:

US,GB

This can help filter aircraft or flights associated with specific countries, depending on the returned aviation data.

Use cases:

Flag signals should be interpreted carefully because aircraft registration country, airline nationality, and route geography may differ.

🧭 Departure and Arrival Filters

Flight Tracker supports filtering by departure and arrival airports.

Input can be IATA or ICAO.

Examples:

JFK

KJFK

LHR

EGLL

These filters are useful for:

📊 Real-Time Results Summary

After a query is completed, the tool displays a summary of returned live flights.

The summary may include:

Example summary:

All active flights
Flights: 7656
Airlines: 498
Speed: 0 → 1155 km/h
Altitude: -60 → 15039 m
Updated: 19:28–19:43 UTC

This summary gives users a quick overview of the size and freshness of the returned data.

📋 Results Table

The results table displays active flights in a compact operational format.

Typical columns include:

Column Description
Flight Flight code
Airline Airline code
Route Departure and arrival airports
Status Current operational status
Latitude Current or last known latitude
Longitude Current or last known longitude
Altitude Current or last known altitude in meters
Speed Current or last known speed in km/h
Heading Direction of travel
Vertical speed Climb or descent indicator, when available
Squawk Transponder squawk code, when available
Aircraft type ICAO aircraft type code
Registration Aircraft registration
Updated Last update timestamp

Example row structure:

BA299    BA    LHR → ORD    en-route    43.225991    -82.839675    10992    698    249    0    B77W    G-STBG

The table is designed for sorting, filtering, and export.

📍 Position Data

Flight Tracker returns latitude and longitude when available.

Position data helps users understand where an aircraft was last observed.

Important notes:

Position should be treated as near-real-time operational data, not as a safety-critical navigation source.

🧭 Heading

The heading value shows the aircraft’s direction of travel.

Example:

Heading: 249

Heading is usually expressed in degrees, where:

Heading is useful for understanding aircraft movement direction and confirming whether a flight is moving toward its expected destination.

🛫 Altitude

Altitude is displayed in meters.

Example:

Altitude: 10992 m

Altitude can help distinguish:

The summary may show a range such as:

Altitude: -60 → 15039 m

Negative or unusual altitude values may appear due to data source behavior, airport elevation handling, sensor anomalies, or ground-level interpretation.

🚀 Speed

Speed is displayed in kilometers per hour.

Example:

Speed: 698 km/h

Speed helps identify whether an aircraft is airborne, taxiing, stationary, climbing, cruising, or descending.

The summary may show the observed speed range across returned flights.

📡 Squawk

The squawk field displays the aircraft transponder code when available.

Squawk may be empty or unavailable for many flights.

Common interpretation:

The tool should not be used as a sole source for emergency interpretation.

🛩️ Aircraft Type and Registration

Flight Tracker may display:

Examples:

B738
A359
A21N

G-STBG
N19951
PH-BXC

Aircraft type and registration are useful for:

Some aircraft may not return registration or type information.

🧠 Key Features

Real-Time ADS-B Monitoring

The tool provides live or near-live active flight data based on ADS-B-style telemetry.

Track Individual Flights

Users can filter by flight code, flight number, aircraft HEX, or registration.

Monitor All Active Flights

The tool can return a broad global list of active flights.

Bounding Box Filtering

Users can limit results to a specific map region.

Airline Filtering

Users can filter by one or more airlines.

Route Filtering

Users can filter by departure and arrival airport.

Speed and Altitude Filtering

Users can focus on aircraft above specific speed or altitude thresholds.

Country Flag Filtering

Users can filter by ISO-2 country flag when supported.

Status Filtering

Users can filter by operational status.

Sortable Table

Any column can be sorted for faster analysis.

CSV Export

Users can export the flight list to CSV.

TXT Export

Users can export flight lists to plain text.

Pagination

Large result sets are paginated for readability.

Local Request History

The last 100 queries are stored locally in the browser.

📄 Pagination

Large result sets may span multiple pages.

Example:

Showing 1–100 of 7656
1 / 77

Pagination allows the interface to handle thousands of active flights without overwhelming the browser.

Users can navigate through pages to review additional aircraft.

📤 Export Options

Flight Tracker supports export for operational and analytical workflows.

CSV Export

CSV export is useful for:

TXT Export

TXT export is useful for:

Exported data may contain operationally sensitive flight information and should be stored responsibly.

🕓 Request History

The Request History section stores recent tracking queries locally in the user’s browser.

Example behavior:

Stores last 100 queries in your browser.

History entries may include:

Example history entry:

— → —
BBOX: —
ZOOM: auto
Airline: any
Flight: any
17.06.2026, 21:43:32

Request history helps users repeat previous monitoring queries quickly.

Because it is stored locally, it may be cleared if the user deletes browser data or switches devices.

🚦 Query Limits and Plan Access

Flight Tracker uses plan-based query limits.

Example:

149 / 150
Queries remaining / total
Plan: Sentinel

Important points:

🧭 IATA, ICAO, HEX, and Registration Reference

Flight IATA

IATA-style flight code.

Example:

AA100

Flight ICAO

ICAO-style flight code.

Example:

AAL100

Airline IATA

Two-character airline code.

Example:

AA
BA
DL

Airline ICAO

Three-letter airline code.

Example:

AAL
BAW
DAL

Airport IATA

Three-letter airport code.

Example:

JFK
LHR
MIA

Airport ICAO

Four-letter airport code.

Example:

KJFK
EGLL
KMIA

ICAO24 HEX

Aircraft transponder hexadecimal identifier.

Example:

A1B2C3

Registration

Aircraft tail number or national registration.

Example:

N123AA
G-STBG
PH-BXC

🧠 Result Interpretation

Flight Tracker data should be interpreted carefully.

Important interpretation rules:

The tool is designed for monitoring and intelligence, not for safety-critical navigation or official air traffic control use.

A practical Flight Tracker workflow should follow these steps.

1. Choose Monitoring Scope

Decide whether to monitor all active flights, a region, a route, an airline, or a specific aircraft.

2. Use Bounding Box for Regions

Enter SW and NE coordinates to limit results to a map area.

3. Add Airline or Route Filters

Use airline, departure, and arrival filters to reduce result volume.

4. Use Speed and Altitude Filters

Exclude ground traffic or focus on airborne flights.

5. Search by Flight or Registration

For a specific aircraft, use flight code, HEX, or registration.

6. Review the Summary

Check total flights, airlines, speed range, altitude range, and update time range.

7. Sort the Results

Sort by altitude, speed, updated time, airline, route, or aircraft type.

8. Review Aircraft Details

Check type, registration, route, and position.

9. Export When Needed

Export CSV for analysis or TXT for flight lists.

10. Verify Critical Findings

Confirm important operational conclusions with official aviation sources when needed.

🛡️ Security, Privacy & Responsible Use

Flight Tracker is intended for lawful aviation awareness and operational monitoring.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Flight Tracker is a real-time ADS-B flight monitoring tool for tracking active flights worldwide. It supports broad traffic monitoring, region-based tracking, individual flight lookup, airline filtering, route filtering, speed and altitude filtering, aircraft HEX / registration search, status filtering, pagination, CSV export, TXT export, and local browser request history.

The tool is designed for aviation OSINT, operational awareness, logistics, corporate travel monitoring, airspace observation, and real-time flight intelligence. Results should be treated as near-real-time aviation signals and verified with official sources for critical decisions.

ULP (Infostealer Logs)

ULP (Infostealer Logs)

ULP (Infostealer Logs)

Public Breached ULP Search | Email / Username Leak Intelligence

image.png

The platform available at dash.niamonx.io/ulp_account_search

Overview of the Service

Public Breached ULP Search is a dedicated NiamonX search module designed to check whether an email address or username appears in public leak datasets processed by the NiamonX ULP Engine.

The tool allows users to quickly verify exposure in large-scale public breach collections, with a focus on records related to emails, usernames, URLs, hosts, and associated credentials.

This module is specifically optimized for email and username lookups only. Domain search, URL search, and advanced search will be implemented separately through dedicated controllers and pages.

Public Breached ULP Search is intended for individuals, security analysts, SOC teams, compliance departments, and organizations that need to verify whether accounts, employees, or user identifiers have appeared in public leaked datasets.

🔍 How the Search Works

When a user enters an email address or username, the system performs a lookup through the NiamonX ULP Engine.

The search checks whether the submitted identifier appears in indexed public leak records. If matches are found, the system displays structured results containing related fields such as:

The search is designed to return results in seconds and supports large result pages for paid plans.

Free preview access remains limited, while paid plans can load significantly more records per page.

Public Breached ULP Search currently supports only two main identifier types:

Examples:

test@example.org

username

This module does not support the following search types inside the current page:

These features may be available through separate NiamonX tools or future dedicated search pages.

⚙️ Search Interface

The interface contains several key search and filtering controls.

Email or Username

The main input field where the user enters an email address or username.

Example values:

Match Mode

The current matching mode is:

Exact matching helps reduce noise and ensures that results are directly related to the submitted email address or username.

Page Limit

The user can define how many records should be loaded per page.

Example:

Page limit: 500

Paid plans can load up to 10,000 records per page.

Free preview access remains limited to 100 records.

Example Email

A quick-fill example for testing email-based search.

Example Username

A quick-fill example for testing username-based search.

📊 Dataset Scale

Public Breached ULP Search is powered by the NiamonX ULP Engine and currently works with a large-scale leak intelligence index.

Main dataset indicator:

19B+ Data points

This means the system can check identifiers against more than 19 billion indexed data points related to public leak datasets.

The number may grow over time as new data is processed, cleaned, normalized, and indexed by the platform.

🧠 Key Features

Email and Username Search

The tool is focused specifically on checking whether an email or username appears in public leak datasets.

NiamonX ULP Engine

The module is powered by the internal NiamonX ULP Engine, which processes and indexes large-scale leak records for fast lookup.

Fast Lookup

Users can check exposure in seconds, depending on dataset size, search value, and current system load.

Exact Match Mode

Exact matching helps ensure that the returned records directly correspond to the searched identifier.

Large Page Limits for Paid Plans

Paid users can load up to 10,000 records per page, making the tool suitable for large-scale security investigations and enterprise workflows.

Free Preview Mode

Free preview access is limited to 100 records, allowing users to verify the presence of results before upgrading.

Structured Results Table

Search results are displayed in a structured table with fields such as URL, type, email or username, password, indexed date, and actions.

Password Visibility Control

Passwords are visible by default during a secured session and can be hidden with one click.

This allows analysts to verify exposure while still maintaining control over sensitive display fields.

Filtering System

Users can filter loaded results by:

Saved Records

Important records can be saved for later review and investigation.

Daily Query Limits

The tool displays daily query usage based on the user’s current plan.

Example:

Daily queries
300000 / 300000
Used today: 0
Plan: Sentinel
Date: 2026-06-17

📋 Results Table

After a successful search, results are displayed in a table.

Main columns include:

Column Description
URL The URL connected to the leaked record
Type The detected record type
Email / Username The matched email address or username
Password Associated password field, if available
Indexed at Date or timestamp when the record was indexed
Actions Available actions for the record

If no search has been performed, the interface displays:

Run a search to see breach records.
No results loaded.

📈 Search Statistics

The interface provides quick summary indicators after a search.

Available statistics include:

Found

Shows the total number of matching records discovered.

Loaded

Shows the number of records currently loaded into the interface.

Hosts

Shows the number of unique hosts connected to the results.

Root Domains

Shows the number of unique root domains identified in the loaded records.

With Password

Shows how many matched records contain a password field.

These counters help users quickly understand the scope and severity of the exposure.

🔎 Filtering and Record Review

The tool includes a filtering field for quickly narrowing down results.

Users can filter by:

This is useful when a single email or username appears across many records and the analyst needs to focus on specific services, domains, or data types.

Example use cases:

🔐 Password Handling

Some records may include associated password fields.

In this secured session, passwords are visible by default and can be hidden with one click.

Users must handle password data carefully.

Passwords must only be used for defensive verification, account recovery, password reset decisions, or authorized security investigations.

Users must not:

🛡️ Security, Privacy & Ethics

Public Breached ULP Search is designed for lawful defensive cybersecurity work.

Acceptable use cases include:

Users must follow strict ethical rules:

Abuse of the system may result in account restriction, suspension, or termination.

⚙️ Technical Highlights

🚦 Plan Limits and Access

The module uses plan-based limits for daily queries and result loading.

Example plan information:

Daily queries: 300000 / 300000
Used today: 0
Plan: Sentinel
Date: 2026-06-17

Access differences may include:

Access Level Limitation
Free preview Up to 100 records
Paid plans Up to 10,000 records per page
Plan-based access Daily query limits depend on subscription

These limits help protect system stability, prevent abuse, and ensure fair access to large-scale breach intelligence.

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Public Breached ULP Search is a dedicated email and username leak intelligence module powered by the NiamonX ULP Engine.

It allows users to check in seconds whether an email address or username appears in large-scale public leak datasets containing more than 19 billion indexed data points.

The tool supports exact matching, structured results, password visibility control, filtering, saved records, plan-based daily query limits, and large page sizes for paid plans.

It is designed for lawful security checks, credential exposure validation, incident response, compliance reviews, and defensive cybersecurity investigations.

ULP (Infostealer Logs)

Public Breached ULP Domain / IP Search | Domain and IP Breach Intelligence

image.png

The platform available at dash.niamonx.io/ulp_domain_ip_search

Overview of the Service

Public Breached ULP Domain / IP Search is a consolidated breach intelligence module within the NiamonX platform. It is designed to scan public leak datasets for records related to a specific domain or IP address and generate a structured security report.

The tool is powered by NiamonX Domain Intelligence and the NiamonX ULP Engine, allowing users to analyze compromised accounts, exposed URLs, affected subdomains, employee-related records, third-party identities, customer-style username records, and password-related exposure.

This module is intended for companies, SOC teams, security analysts, incident response teams, compliance departments, and authorized cybersecurity researchers who need to understand whether a corporate domain or IP address appears in large-scale public leak datasets.

The search is focused on exact domains and IP addresses only.

Examples:

example.com

203.0.113.10

Users must not enter full URLs, URL paths, emails, wildcards, or unrelated search values in this module.

image.png

🔍 How the Search Works

When a user enters a domain or IP address, the system performs an exact search across indexed ULP leak records.

For domain-based searches, subdomains are automatically normalized to the root domain before searching.

For example:

auth.example.com

is normalized and searched as:

example.com

This allows the system to consolidate breach intelligence across all related subdomains and hosts under the same root domain.

The search returns a consolidated report that may include:

The total number of compromised accounts is taken directly from the API when available, while category cards describe only the rows loaded in the current browser session. Hidden category totals are not guessed.

This module supports only exact domain and IP address searches.

Supported values:

Examples of valid searches:

example.com

company.org

203.0.113.10

Examples of invalid input for this module:

https://example.com/login

example.com/login

user@example.com

*.example.com

example

Domain, URL, email, username, and advanced search are handled through separate NiamonX modules or dedicated pages.

⚙️ Search Interface

The interface contains several core controls and report indicators.

Domain or IP

The main input field where the user enters an exact domain or IP address.

Example:

tesla.com

The field is intended only for domains or IP addresses. Users should not enter URLs, paths, emails, or wildcards.

Match Mode

The current match mode is:

Exact

Exact matching helps reduce noise and ensures that the report is generated around the submitted domain, normalized root domain, or IP address.

Limit

The result limit controls how many rows can be loaded into the current browser session.

Example:

10,000

The report may show an exact total from the API while loading only a limited number of rows into the current session.

Daily Queries

The interface displays daily query limits based on the user’s plan.

Example:

Daily queries
299998 / 300000
Used today: 2
Cooldown: 1s
Plan: Sentinel

Daily limits help control usage, ensure platform stability, and prevent abuse.

📊 Dataset Scale

Public Breached ULP Domain / IP Search is powered by a large-scale ULP intelligence dataset.

Main dataset indicator:

19B+ ULP rows

This means the module can search across more than 19 billion indexed ULP rows related to public leak datasets.

The dataset may include records containing URLs, hosts, emails, usernames, passwords, timestamps, and other leak-related metadata.

🧠 Key Features

Domain and IP Intelligence

The module provides consolidated breach intelligence for a specific domain or IP address.

Root Domain Normalization

Subdomains are normalized to the root domain before searching, allowing the tool to detect exposure across related hosts.

Exact matching helps ensure that the report is focused on the selected domain or IP address.

Consolidated Security Report

The tool generates a structured security report with key metrics, categories, and exposure indicators.

Exact API Total

The total number of compromised accounts can be displayed as an exact value from the API.

Loaded Session Rows

The report clearly separates the exact total from the rows currently loaded in the browser session.

Employee Detection

The system identifies employee-related records where the email domain matches the searched root domain or its subdomains.

Third-Party Detection

The system identifies external email domains that authenticated on the target domain or related services.

Customer / Username-Only Records

The module separates username-only records or identities without a corporate email domain.

Password Strength Distribution

Loaded compromised accounts are grouped by password strength.

Common categories include:

URL and Host Analysis

The report highlights top URLs, unique endpoints, unique hosts, and subdomains discovered in loaded records.

Graph and AI Module

The tool includes a Graph / AI section for visual analysis and AI-assisted interpretation of the breach report.

image.png

Saved Records

Important records can be saved for later review and investigation.

📈 Security Report Structure

After a search is completed, the module generates a structured report.

Example report header:

Security Report for example.com
Root domain • 2026-06-17 • 10,000 loaded rows

The report may include the following cards and sections.

📌 Compromised Accounts

The Compromised Accounts card shows the total number of compromised accounts related to the searched domain or IP.

Example:

Compromised Accounts (Exact API Total)
45,837

This value represents the exact total returned by the API.

The category cards below the total describe only the rows loaded in the current browser session. The system does not guess hidden category totals.

📥 Loaded Rows

The Loaded rows card shows how many records are currently loaded in the browser session.

Example:

Loaded rows
10,000
current cursor session

This is important because the full API total may be higher than the number of records loaded into the interface.

For large reports, users may need to load additional pages or use cursor-based pagination.

🌐 Unique Hosts, URLs, and Subdomains

The report summarizes infrastructure-related indicators.

Unique Hosts

Shows how many unique hosts were parsed from URL hosts.

Example:

Unique hosts
41

URLs

Shows how many unique endpoints were found.

Example:

URLs
250

Subdomains

Shows how many unique subdomains or hosts were detected in the loaded rows.

Example:

Subdomains
41

These indicators help analysts understand which services, login pages, applications, or infrastructure components are most commonly associated with leaked records.

👥 Employee Exposure

The Employees section identifies records where the email domain matches the searched root domain or one of its subdomains.

Example:

Employees
Loaded compromised accounts: 221

Employee records are important because they may indicate direct corporate account exposure.

The section may also include password strength distribution:

Password Strength Description
Too weak Very risky passwords that may be simple, reused, or easily guessed
Weak Low-strength passwords requiring urgent review
Medium Moderate-strength passwords that may still require reset depending on context
Strong Stronger passwords, but still considered exposed if found in leaks

Example distribution:

Strength Count
Too weak 22
Weak 3
Medium 50
Strong 146

Even strong passwords should be reset if they appear in breach records.

🏢 Third-Party Exposure

The Third-Parties section identifies external email domains that authenticated on the searched target.

Example:

Third-Parties
Loaded compromised accounts: 8,127

These records may represent:

Third-party exposure is important because attackers may use compromised external accounts to access company systems, partner portals, support panels, or customer-facing services.

Example password strength distribution:

Strength Count
Too weak 148
Weak 82
Medium 2,769
Strong 5,113

👤 Customer and Username-Only Records

The Customers section includes username-only records or identities without a corporate email domain.

Example:

Customers
Loaded compromised accounts: 1,652

These records may represent:

Example password strength distribution:

Strength Count
Too weak 84
Weak 60
Medium 594
Strong 843

This section helps organizations understand user exposure beyond direct employee email accounts.

🔐 Password Exposure

The report highlights how many loaded records contain passwords.

Example:

With passwords
9,914
loaded rows

Password exposure is one of the most important risk indicators.

If passwords are present, users should treat the affected records as sensitive security intelligence.

Passwords must never be used for unauthorized access, credential stuffing, phishing, fraud, or social engineering.

📧 Email and Username Records

The report separates loaded rows by identity type.

Example:

Email records
8,348
loaded rows

Username records
1,652
loaded rows

Email records usually provide stronger identity correlation because they are connected to a specific domain or user account.

Username records may require additional validation because usernames can be reused across multiple services and may not always uniquely identify one person.

🔗 Top URLs from Loaded Rows

The report displays the most common URLs found in the loaded records.

Example:

URL Count
auth.example.com 3,299
auth.example.com/oauth2/v1/authorize 1,463
auth.example.com/oauth2/v1/register 941
auth.example.com/login 609
auth.example.com/register 506
example.com 424
sso.example.com 104

This section helps analysts identify the most affected endpoints.

Common findings may include:

High counts on authentication endpoints may indicate credential exposure involving login flows.

🧭 Top Subdomains from Loaded Rows

The report also displays the most common subdomains or hosts found in loaded records.

Example:

Subdomain Count
auth.example.com 8,328
example.com 1,215
sso.example.com 239
accounts.example.com 109
apps.example.com 10
toolbox.example.com 6

This section helps security teams identify which parts of the organization’s infrastructure are most represented in public leak data.

High-risk subdomains may include:

🧠 Graph / AI Analysis

The Graph / AI section provides visual and AI-assisted analysis of the domain or IP exposure.

It may help users understand:

The AI component can assist with summarizing the report and highlighting important risks, but it should not replace manual analyst validation.

💾 Saved Records

The Saved records section allows users to store important findings for later review.

Saved records may be useful for:

Saved records should be handled as sensitive security data.

🚦 Pagination and Cursor State

Large reports may contain more records than are loaded into the current browser session.

The interface may show cursor-related information, such as:

Next page
NaN
cursor state

This indicates the current pagination or cursor state for loading additional records.

The exact API total and the currently loaded rows should always be interpreted separately.

Example:

Exact API Total: 45,837
Loaded rows: 10,000

This means the API reports 45,837 total compromised accounts, while the browser currently displays and analyzes 10,000 rows.

🛡️ Security, Privacy & Ethics

Public Breached ULP Domain / IP Search is designed for lawful defensive cybersecurity and authorized breach intelligence analysis.

Acceptable use cases include:

Users must follow strict ethical rules:

Abuse of the platform may result in account restriction, suspension, or termination.

When exposure is found, security teams should follow a structured remediation process.

1. Validate the Report

Confirm that the domain or IP belongs to the organization and that the records are relevant.

2. Prioritize Employee Accounts

Employee records should be reviewed first because they may represent direct corporate access risk.

3. Check Password Exposure

Focus on records with passwords, especially weak and very weak passwords.

4. Enforce Password Resets

Reset exposed passwords and prevent reuse through password policy controls.

5. Enable MFA

Require multi-factor authentication for affected accounts and critical systems.

6. Review Login Logs

Check SIEM, IAM, VPN, SSO, email, and application logs for suspicious activity.

7. Investigate Affected URLs

Review the top URLs and subdomains to identify exposed authentication surfaces.

8. Review Third-Party Exposure

Check whether external accounts belong to vendors, partners, contractors, or customers.

9. Notify Stakeholders

Inform internal security, legal, compliance, and affected users where appropriate.

10. Monitor Continuously

Repeat checks periodically and monitor for new exposure.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Public Breached ULP Domain / IP Search is a consolidated domain and IP breach intelligence module designed to scan public leak datasets and generate a structured security report.

It searches across more than 19 billion ULP rows, normalizes subdomains to the root domain, calculates exact compromised account totals from the API, and analyzes loaded rows by employees, third parties, customers, URLs, hosts, subdomains, password exposure, and password strength.

The tool is built for lawful defensive cybersecurity, domain exposure monitoring, SOC workflows, incident response, and compliance investigations. All findings should be validated before action and handled as sensitive security intelligence.

Identity Intelligence

Identity Intelligence

Identity Intelligence

Identity360 Report | Digital Footprint Intelligence

image.png

The platform available at dash.niamonx.io/identity360_report

Overview of the Service

Digital Footprint Intelligence is an advanced identity intelligence tool within the NiamonX platform. The main report generated by this module is called Identity360 Report.

Identity360 Report provides a unified digital identity overview by combining results from multiple NiamonX intelligence modules:

The tool is designed to help individuals, cybersecurity analysts, SOC teams, compliance departments, investigators, and authorized security professionals understand how a specific email address or username appears across public breach datasets, stealer log evidence, public account traces, username reconnaissance sources, and Google ecosystem signals.

The report is built as a consolidated identity profile. Instead of checking each module manually, the user starts one report and receives a structured overview of exposure, related identifiers, public accounts, evidence links, breach blocks, ULP records, and analytical risk indicators.

🔍 How the Report Works

When a user creates an Identity360 report, the platform starts a multi-module investigation for the submitted target.

Supported target types:

For email-based targets, the system may also derive the email local part and run username-focused modules against it as a correlation lead.

For example, if the target is:

example.name@domain.com

the platform may also check:

example.name

This derived username should be treated only as a correlation lead, not as confirmed ownership.

One billed request starts the report. After that, the browser checks the report progress through AJAX polling every few seconds. Status checks do not consume additional daily tool quota, and polling stops permanently after the final report is ready.

This design allows long-running intelligence modules to continue processing while the user sees real-time progress inside the interface.

🧩 Main Purpose

Identity360 Report helps answer questions such as:

The tool is especially useful for identity exposure analysis, account compromise investigation, personal digital footprint review, employee risk monitoring, and incident response.

⚙️ Report Creation Interface

The report creation interface includes the following main elements.

Available Requests Today

Shows the number of remaining report requests available under the current plan.

Example format:

Available requests today
597 / 600
Used today: 3
Plan: Sentinel
Date: 2026-06-17

Create Report

Starts a new Identity360 report.

Target Type

The user selects or enters an email address or username.

Supported examples:

user@example.com

username

Email Local-Part Correlation

For email targets, the system can also run username modules against the email local part.

This is useful because many users reuse the same nickname across multiple public platforms.

However, these matches must be interpreted carefully.

A username match does not automatically prove that the account belongs to the same person.

📊 Report Progress

After the report starts, the interface displays processing status.

Example status elements:

Processing report… 60%
Report ID: ************
Executive summary: running

The report may show:

The report is considered final only after all required modules finish, fail, or are skipped according to the backend state.

🧠 Processing Modules

Identity360 Report combines several intelligence modules into one unified profile.

Public Breached Search

Public Breached Search checks indexed public breach datasets for the submitted target.

It may return:

This module is useful for understanding whether the target appears in historical public breach collections.

ULP Account Search checks stealer-log and ULP-style account evidence by email or username.

It may return:

This module is especially important because ULP records may indicate that credentials were captured from infected devices, browser storage, or other compromise sources.

Alias Radar

Alias Radar performs detailed username reconnaissance across public platforms.

It may return:

When Alias Radar is run from an email local part, matches should be treated as possible correlation leads rather than confirmed identity ownership.

Google Footprint

Google Footprint checks public Google account and Google ecosystem signals.

It may return:

If the module is skipped, pending, or incomplete, the report should clearly show that Google Footprint data is not available yet.

CrossTrace

CrossTrace performs fast public account-presence checks by email or username.

It may return:

CrossTrace is useful for fast identity correlation across public platforms.

📌 Executive Summary

The Executive Summary provides a high-level interpretation of the report.

It may include:

The summary helps users quickly understand whether the target has low, medium, high, or critical exposure.

🚨 Analytical Risk Score

Identity360 Report includes an Analytical Risk Score.

The score is calculated from multiple risk drivers, such as:

Example risk levels may include:

A critical score means that the report contains strong exposure indicators, such as credential-related records, multiple breach appearances, or high-confidence public identity traces.

The risk score is an analytical indicator. It should support investigation, not replace human validation.

👤 Profile Summary

The Profile Summary aggregates identifiers discovered during the report.

Possible identifier types include:

This section helps analysts understand the broader digital identity graph connected to the target.

🌐 Public Accounts and Traces

The Public Accounts and Traces section displays public profile or account-presence findings.

A result may include:

Field Description
Platform Name of the detected service or platform
Category Social, media, Google, other, or another category
Display name Public name found on the platform
Username Username or handle, if available
Source module Alias Radar, CrossTrace, or another module
Confidence Estimated confidence score
Profile link Link for manual validation

Confidence scores help analysts prioritize review.

For example:

Public account traces do not always prove ownership. They should be validated before being used in legal, compliance, or operational decisions.

🧱 Breach Exposure

The Breach Exposure section summarizes public breach dataset appearances.

It may include:

A breach block represents a structured group of fields from a particular breach source or collection.

Credential blocks are especially important because they may contain password-related evidence or login-related exposure.

🔐 ULP Account Evidence

The ULP Account Evidence section shows stealer-log or ULP-style account records connected to the target.

It may include:

Column Description
Date Indexed or observed date
Host Related service, domain, or application
Identity Matched email or username
Password Password field, if available and permitted
URL Evidence or related service URL

The section may also show summary counters:

ULP evidence should be considered high-risk because it may indicate credential capture, malware compromise, browser credential theft, or reused credentials.

🔎 Filtering and Review

The report interface may include filters for accounts, traces, records, and evidence.

Users can review:

Filtering helps analysts focus on the most relevant signals, especially in large reports with many records.

🧾 Clean Report JSON

Identity360 Report can expose a clean structured JSON representation of the report.

This JSON may include:

Clean JSON is useful for:

Sensitive values should be masked or protected depending on user permissions, session security, and export policy.

🕒 Timeline

The report may include a timeline of discovered events and sources.

Timeline entries may include:

This helps analysts understand the chronological order of exposure indicators.

For example, ULP evidence dated recently may require more urgent response than older historical breach appearances.

🖼️ Photos and Avatars

Some modules may detect public profile images or avatars.

These may come from:

Profile images are useful for manual correlation, but they must not be treated as proof of identity without additional evidence.

🧠 Correlation Logic

Identity360 Report is built around correlation, not blind certainty.

The system combines multiple signal types:

Strong findings usually come from multiple independent signals pointing to the same target.

Weak findings may be useful leads but should be validated before action.

🔐 Password and Sensitive Data Handling

Some records may contain password evidence or other sensitive fields.

Users must handle this data carefully.

Passwords and sensitive values must only be used for:

Users must not:

When screen sharing, reporting, or exporting, sensitive values should be masked unless full visibility is strictly required and authorized.

🛡️ Security, Privacy & Ethics

Digital Footprint Intelligence is intended for lawful security work and authorized identity exposure analysis.

Acceptable use cases include:

Users must follow strict rules:

Abuse of the system may result in account restriction, suspension, or termination.

When the report shows meaningful exposure, users should follow a structured response process.

1. Review the Executive Summary

Start with the risk score, risk level, and risk drivers.

2. Check Credential Blocks

Prioritize breach blocks that contain credential exposure.

3. Review ULP Evidence

ULP records with passwords should be treated as high priority.

4. Validate Public Accounts

Check public accounts and traces manually before drawing conclusions.

5. Reset Exposed Passwords

Reset affected passwords and remove reused credentials.

6. Enable MFA

Enable or enforce multi-factor authentication on affected accounts.

7. Review Login History

Check account activity, IAM logs, SSO events, VPN access, email logs, and cloud service logs.

8. Check for Password Reuse

Identify whether exposed passwords were reused across corporate or personal accounts.

9. Notify Affected Users

Notify the affected person or internal team when appropriate and legally permitted.

10. Save Evidence Securely

Store the report only in secure internal systems with restricted access.

11. Continue Monitoring

Repeat checks periodically or enable continuous monitoring for high-risk identities.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Digital Footprint Intelligence / Identity360 Report is a unified identity exposure report that combines breach intelligence, ULP account evidence, public username reconnaissance, Google ecosystem signals, and public account tracing into one structured profile.

The tool helps users understand whether an email or username is connected to public breaches, credential exposure, stealer-log records, public accounts, evidence links, and cross-platform identity traces.

It is designed for lawful defensive cybersecurity, personal exposure checks, employee risk monitoring, incident response, compliance review, and digital footprint analysis. All findings should be validated before action and handled as sensitive security intelligence.

Identity Intelligence

Alias Radar | Username Intelligence

image.png

The platform available at dash.niamonx.io/alias_radar — known as Alias Radar — is an advanced username intelligence module within the NiamonX platform. It is designed to discover public username traces across social networks, forums, gaming platforms, developer communities, media services, financial platforms, OSINT sources, and other publicly accessible digital spaces.

Overview of the Service

Alias Radar helps analysts investigate whether a username appears across public platforms and online communities. The tool performs a backend-powered username scan, tracks progress in real time, removes duplicate and technical scanner noise, and returns a clean analyst-friendly report with meaningful account matches only.

The service is intended for cybersecurity analysts, OSINT researchers, SOC teams, fraud investigators, compliance teams, brand protection specialists, and authorized users who need to identify public username presence across multiple online sources.

Alias Radar is not designed to prove identity ownership automatically. A matching username should be treated as an investigative lead and verified manually by comparing public profile content, avatars, creation dates, platform IDs, bios, linked accounts, activity patterns, and other contextual signals.

🔍 How the Scan Works

When a user submits a username, Alias Radar starts a backend scan through the NiamonX infrastructure.

The scan checks the submitted username across thousands of supported sites and services. The system then processes raw matches, removes technical API noise, deduplicates repeated results, enriches profiles where possible, and presents only useful clickable findings.

One request is consumed only when the scan starts. Live status checks do not consume additional tool quota.

The browser checks scan progress every few seconds and stops polling permanently after the backend returns a final status.

Typical scan flow:

  1. User enters a username.

  2. The scan request is sent to the NiamonX backend.

  3. The backend checks supported public platforms.

  4. Live progress is displayed in the browser.

  5. Raw results are cleaned and deduplicated.

  6. Enriched account details are extracted when available.

  7. The final report is generated with categories, scores, identifiers, and profile links.

Alias Radar accepts usernames only.

Valid examples:

niamonx

@niamonx

If a username starts with @, the symbol is accepted and removed automatically before scanning.

The tool does not accept:

Input rules:

Rule Requirement
Input type Username only
Allowed characters Letters, numbers, dot, underscore, hyphen
Length 2–64 characters
Leading @ Accepted and removed automatically
URLs Not allowed
Email addresses Not allowed

⚙️ Scan Interface

The Alias Radar interface contains the following main sections.

New Username Scan

This section allows the user to start a new scan.

Main fields:

The interface reminds users to enter a username without a URL.

Advanced Scan Options

Advanced scan options may allow the system to adjust how the username scan is performed.

Depending on platform configuration, these options may control scan depth, enrichment behavior, supported source groups, or backend processing preferences.

Advanced settings are designed for users who need more detailed reconnaissance while keeping the final output clean and analyst-friendly.

Live Scan Status

The live scan status panel shows the current state of the scan.

It may display:

Example status values:

DONE

Polling off

100%
2499 / 2499 sites

Polling runs once every few seconds and stops permanently after a final scan status is received.

image.png

📊 Summary Section

After a scan is completed, Alias Radar generates a structured summary.

The summary may include:

Example summary structure:

Tool: alias_radar
Status: DONE
Found accounts: 22
Progress: 100%
Elapsed time: 1m 50s
Extended profiles: 6
Raw matches cleaned: 66 → 22

The “raw matches cleaned” value is important because automated username scans often return noisy technical responses. Alias Radar filters those raw results and keeps only useful public matches.

🧠 Key Features

Public Username Reconnaissance

Alias Radar checks whether a username appears across public platforms and online communities.

Large Source Coverage

The scan can check thousands of supported sites and services.

Example interface output may show:

2499 / 2499 sites

Live Progress Tracking

The user can follow the scan in real time while the backend processes supported platforms.

Quota-Safe Polling

Only the initial scan request consumes tool quota. Status polling does not consume additional daily requests.

Cleaned Results

Technical API noise, duplicate records, scanner definitions, and low-value diagnostic responses are removed before the final report is displayed.

Deduplication

The system merges duplicate matches and presents clean account-level findings.

Analyst-Friendly Report

Results are displayed as readable account cards with profile links, categories, scores, and extracted details.

Enriched Account Details

Where available, Alias Radar extracts useful public metadata, such as:

Categories and Interest Tags

The tool groups results by categories and interest tags to help analysts understand the target’s public footprint.

Possible categories may include:

Country Signals

When available, the report may show country indicators inferred from public platform data or source metadata.

Country signals should be treated as contextual hints, not confirmed residence or nationality.

Extracted Identifiers

Alias Radar extracts useful identifiers from public profiles and enriched records.

Examples:

Copyable Report and Clean JSON

The tool can provide a copyable analyst report and clean JSON output without raw API URLs, scanner logs, or noisy technical definitions.

📋 Found Accounts

The Found Accounts section displays cleaned and deduplicated public matches only.

Each account card may include:

Field Description
Site Platform or service where the username was found
Category Platform category such as Social, Code, Gaming, Forum, Finance, or Media
Display name Public name shown on the profile, if available
Username Matched username
Score Confidence or relevance score
Avatar Public profile image, if available
Profile link Clickable link to the public profile
Metadata Extracted public details returned by the backend

The interface may also include a filter field.

Users can filter results by:

🧮 Score and Confidence

Each found account may include a score.

The score helps analysts prioritize results.

Higher scores usually indicate stronger signals, such as:

Lower scores may still be useful but should be reviewed more carefully.

Example interpretation:

Score Range Meaning
90–100 Strong match or highly relevant public profile
70–89 Good match, usually worth manual review
50–69 Possible match or weaker public signal
Below 50 Low-confidence signal, if shown

A score does not prove that all accounts belong to the same person. It only helps prioritize manual investigation.

🧬 Extended Profiles

Some platforms return richer public data than others.

An extended profile may include:

Examples of enriched platforms may include social networks, developer communities, gaming platforms, media services, and avatar providers.

Extended profiles are especially useful for correlation because they provide additional public context beyond a simple username match.

🏷️ Categories and Interest Tags

Alias Radar groups discovered accounts into categories and interest tags.

Categories help analysts understand where the username appears.

Possible categories:

Category Description
Social Social networking platforms
Code Developer platforms and code communities
Gaming Gaming profiles and game-related services
Forum Public forums and discussion boards
Messaging Messaging or communication platforms
Video Video platforms
Streaming Streaming services
Finance Finance, trading, donation, or payment-related platforms
Media Media, avatar, and content platforms
Security Cybersecurity, breach, or OSINT-related sources
Other Platforms that do not fit a primary category

Interest tags help summarize the visible public footprint.

Example tags may include:

These tags are useful for quick triage but should not be treated as personal conclusions without validation.

🌍 Country Signals

Alias Radar may show country indicators when country-related signals are available.

Example format:

Countries: us, ru

Country indicators can come from public platform data, source metadata, or backend enrichment.

They should be interpreted carefully. A country signal may reflect platform region, profile metadata, content language, account history, or source classification. It does not necessarily confirm the person’s nationality, current location, or legal residence.

🔎 Extracted Identifiers

The Extracted Identifiers section collects useful identifiers discovered during the scan.

Possible extracted identifiers include:

Identifier Type Example Use
Username Confirms the matched alias
Steam ID Useful for gaming profile correlation
GitHub ID Useful for developer profile correlation
Twitch Channel ID Useful for streaming or gaming analysis
Gravatar hash Useful for avatar and email-hash correlation
Platform UID Stable account identifier on a specific service
Profile URL Direct link for manual verification

Extracted identifiers help analysts connect results across platforms, but they must be validated before conclusions are made.

💾 Clean Analyst Report

Alias Radar is designed to provide a clean report that can be copied into internal notes, SOC cases, OSINT documentation, or compliance workflows.

The report may include:

The clean report intentionally avoids unnecessary scanner internals, noisy logs, raw API definitions, and irrelevant technical records.

🧾 Clean JSON Output

In addition to the visual report, Alias Radar can provide clean JSON output.

This is useful for:

Clean JSON should contain meaningful normalized results rather than noisy low-level scanner output.

🚦 Daily Quota

Alias Radar uses daily plan-based request limits.

The interface may display:

Available requests today: 999
Daily limit: 1000
Used today: 1

Important quota behavior:

This design allows users to monitor long-running scans without wasting quota on status checks.

🛡️ Implementation Security

Alias Radar includes several security and reliability protections.

Quota Protection

Only the initial scan request is billed against the tool quota. Repeated status checks are not counted as additional scan requests.

Controlled Polling

Polling runs at a fixed interval and stops permanently after a final status is received.

Input Normalization

Leading @ symbols are automatically removed.

Input Restriction

The tool accepts only usernames with allowed characters and length limits.

Noise Reduction

Technical scanner noise, duplicated raw matches, rate-limit artifacts, and irrelevant diagnostic records are removed from the final view.

Analyst-Safe Output

The final report focuses on public account traces and avoids exposing unnecessary backend internals.

📌 Result Interpretation

Alias Radar results are public technical signals.

A matching username does not prove that all accounts belong to the same person.

Users should treat each result as a lead and validate it manually.

Some platforms may block automated checks, enforce rate limits, return uncertain responses, or expose only partial public data. Alias Radar hides noisy diagnostic records and focuses on useful clickable findings.

A careful review process should follow these steps.

1. Start With High-Score Results

Review accounts with the highest scores first.

2. Check Enriched Profiles

Prioritize profiles with avatars, bios, creation dates, public IDs, or activity metadata.

3. Compare Public Signals

Compare usernames, display names, avatars, links, and platform identifiers.

4. Separate Confirmed Signals From Leads

Do not treat every username match as confirmed ownership.

5. Review Categories

Use categories to understand whether the username appears mostly in social, gaming, code, forum, finance, or media contexts.

6. Extract Stable Identifiers

Record stable IDs such as Steam ID, GitHub ID, Gravatar hash, or platform UID.

7. Preserve Evidence Carefully

Save only what is necessary and permitted under applicable policy and law.

8. Avoid Overclaiming

Use cautious wording such as “possible match,” “public trace,” or “correlation lead” unless ownership is verified.

🧠 Common Use Cases

Alias Radar can support many legitimate workflows.

Personal Digital Footprint Review

Users can check where their own username appears publicly.

Cybersecurity Investigation

Security teams can identify public platform presence connected to known aliases.

Threat Intelligence

Analysts can map usernames used in forums, developer spaces, gaming communities, or public OSINT sources.

Fraud and Abuse Investigation

Authorized teams can investigate suspicious aliases connected to fraud, spam, impersonation, or account abuse.

Brand and Executive Protection

Organizations can monitor usernames related to executives, employees, projects, or brands.

SOC and Incident Response

Alias Radar can help correlate usernames found in logs, breach records, stealer logs, or suspicious activity.

Compliance and Risk Review

Teams can document public account exposure in a structured and repeatable format.

🛡️ Security, Privacy & Ethics

Alias Radar is intended for lawful OSINT, defensive cybersecurity, fraud prevention, compliance, and authorized investigation.

Users must follow strict ethical rules:

Responsible use is essential because username reconnaissance can create false positives if interpreted incorrectly.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Alias Radar is a username intelligence tool that discovers public username traces across social networks, forums, gaming platforms, developer communities, media services, finance-related platforms, security sources, and OSINT databases.

It starts a backend scan, tracks progress live, removes duplicate and technical records, enriches account details when available, extracts identifiers, groups results by category, and produces a clean analyst-friendly report.

The tool is designed for lawful OSINT, defensive cybersecurity, identity correlation, fraud prevention, SOC workflows, and digital footprint analysis. Results should always be treated as public technical signals and manually verified before making conclusions about identity or ownership.

Identity Intelligence

Google Footprint | Google Account & Drive Intelligence

image.png

The platform available at dash.niamonx.io/google_footprint — known as Google Footprint — is a specialized intelligence module within the NiamonX platform designed to analyze public and technical traces of Google accounts, Gaia IDs, Google Drive files, and Google Sheets documents through the backend NiamonX API.

Overview of the Service

Google Footprint helps users collect a structured footprint of a Google identity or shared Google file. The tool can analyze a Gmail or Google email address, a Gaia ID, or a Google Drive / Google Sheets file identifier and return available public and technical signals.

The module is designed for cybersecurity analysts, OSINT researchers, SOC teams, compliance departments, fraud investigators, and authorized security professionals who need to validate Google-related public traces during an investigation.

Google Footprint can return information such as Google profile metadata, Gaia ID, avatar status, account type indicators, Google Chat signals, Maps profile availability, public contribution indicators, Drive file metadata, file owners, sharing role, technical JSON, and backend response diagnostics.

The tool does not provide unauthorized access to private Google data. It only returns signals available through supported public, technical, or backend-accessible checks.

🔍 How the Analysis Works

When a user starts a new analysis, the platform sends the selected input to the NiamonX backend API.

Supported input types include:

Before the external request is performed, the system validates the input format. This helps prevent invalid requests, malformed values, unsupported identifiers, and accidental submission of unrelated data.

The backend then performs the supported checks and returns a structured response. The interface displays a summary, account profile information, Google service signals, Maps indicators, Drive metadata, links, and technical JSON when requested.

The result can be returned from cache or generated through a fresh backend check, depending on the request options and backend support.

🧩 What Can Be Analyzed

Google Footprint supports several Google-related input types.

Email

A Gmail or Google account email address.

Example:

alex@gmail.com

This mode checks the detected Google Account footprint and may return a Gaia ID when available through the API.

image.png

Gaia ID

A numeric Google Account identifier.

Example:

112085282135050284090

This mode is useful when the analyst already has a Gaia ID and needs to check related public or technical signals.

image.png

Google Drive / Google Sheets

A Google Drive or Google Sheets file can be analyzed by pasting either the file ID or the full URL.

Example file ID:

1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgvE2upms

Example supported inputs may include:

The tool may return file metadata, sharing role, owners, MIME type, checksum, title, size, creation date, modification date, and technical JSON depending on backend availability and file visibility.

image.png

⚙️ New Analysis Interface

The New Analysis section allows the user to choose the input type and submit the request to the backend API.

Main interface elements:

Field Description
Input type Email, Gaia ID, Google Drive, or Google Sheets
Target value The email, Gaia ID, file ID, or file URL to analyze
Request include_raw Includes technical raw data for diagnostics and deeper analysis
Refresh without cache Requests a fresh backend check when supported
Backend indicator Shows that the request is processed through the NiamonX API

🧠 Key Features

Google Account Analysis

The tool can analyze Google account signals connected to a Gmail or Google email address.

Possible returned fields include:

Gaia ID Detection

When available, the tool returns the Google account’s Gaia ID.

A Gaia ID is a stable Google account identifier that can help analysts correlate technical Google signals across different public or semi-public contexts.

Avatar Analysis

Google Footprint can identify whether the account uses a custom avatar or a default Google avatar.

Possible values:

A custom avatar can be useful for manual correlation, but it should not be treated as proof of identity by itself.

Google Services Signals

The module may check for available signals connected to Google services.

Possible services and indicators include:

Some service indicators may not be returned for every request type. If activated services are not found or not returned, the interface should clearly display that no service data was available for that request.

Google Maps / Contributions

The module can show available Google Maps public footprint signals.

Possible fields include:

The presence of a Maps profile does not prove current activity. It only indicates that a public or technical Maps-related signal was detected.

Google Drive / Sheets Metadata

For Google Drive or Google Sheets targets, the tool may return file-level metadata.

Possible fields include:

This is useful for validating public files, checking exposed shared documents, reviewing ownership indicators, and documenting Drive-related evidence.

Technical JSON

The tool can expose technical JSON for deeper diagnostics.

This is useful for:

Raw technical output should be handled carefully and shared only with authorized users.

📊 Summary Section

After an analysis is completed, Google Footprint displays a structured summary.

The summary may include:

Example structure:

Status: OK
Type: EMAIL
Cache: fresh
Module: email
API duration: 2044 ms
Total request time: 2048.92 ms
Cache: No
stderr: —

This section helps analysts understand how the result was generated and whether the response came from a fresh backend check or cached data.

👤 Google Account Section

The Google Account section displays the primary account-level findings.

Possible fields include:

Field Description
Email Google or Gmail address analyzed by the tool
Gaia ID Google account identifier returned by the backend
Avatar Avatar status or profile picture availability
Custom avatar Indicates whether a custom avatar exists
Default avatar Indicates whether the account uses the default avatar
Profile edit Last detected profile edit timestamp, when available
User type Google account type signal
Google Chat Chat entity signal, such as PERSON
Enterprise user Indicates whether enterprise-related account signals are detected
Play Games profile Indicates whether Play Games profile data was found
Public calendar Indicates whether public calendar signals were found

The exact returned fields depend on the input type, backend support, Google-side availability, and cache/fresh request behavior.

🧬 Google User Types and Signals

Google Footprint may return technical account-type indicators.

Example signal:

GOOGLE_USER

This indicates that the checked identity is detected as a Google user through the supported backend logic.

Other service-related fields may show whether specific Google ecosystem signals were available.

Important: these indicators are technical signals. They should not be interpreted as complete account activity logs or proof that the user is currently active.

🖼️ Avatar and Profile Picture Analysis

Avatar data can help analysts correlate a Google account with other public identity traces.

Possible avatar-related indicators:

A custom avatar may be useful for manual comparison with other platforms, but it should always be validated with additional context.

Avatar matching alone should not be treated as identity proof.

🗺️ Google Maps / Contributions

The Google Maps / Contributions section helps identify whether Maps-related public signals are available.

Possible fields include:

Field Description
Profile page Indicates whether a Maps profile page is available
Reviews Review data or count, if available
Ratings Rating data or count, if available
Photos Public contribution photos, if available
Contributions Public contribution indicators

If the report shows that a profile page is available but reviews or ratings are empty, it means that a Maps profile signal exists but no review or rating details were returned for that request.

This section is useful for OSINT, fraud analysis, identity correlation, and digital footprint review.

📁 Google Drive and Google Sheets Analysis

When a Google Drive or Google Sheets file is submitted, the module can check public and technical metadata associated with the file.

Possible metadata includes:

This feature is useful for:

The tool does not bypass Google permissions. Returned data depends on what is available to the backend check.

Users should avoid opening suspicious or unknown links outside a safe analysis environment.

🧾 Request Options

Google Footprint includes additional request options for deeper analysis and diagnostics.

include_raw

The include_raw option returns additional technical data when supported.

Use cases:

Raw output may contain verbose or sensitive technical details and should be handled carefully.

Refresh Without Cache

The refresh option requests a fresh backend check when supported.

This is useful when:

Important: forcing refresh requests a fresh result, but the final behavior depends on backend API support and Google-side response behavior.

💾 Local Request History

Google Footprint stores request history locally in the user’s browser through localStorage.

This helps users access recent checks without server-side history navigation.

Local storage may include:

Because the history is browser-local, it may be cleared if the user clears browser data, switches devices, or uses another browser profile.

Sensitive targets should be handled carefully, especially on shared devices.

🚦 Cache and Fresh Results

The interface may show whether a result was returned from cache or generated fresh.

Possible cache states:

State Meaning
cached The API returned a previously stored result
fresh A new check was performed or fresh data was returned
no cache The result was not served from cache
force refresh The user requested a fresh check

A cached result can be useful for speed and stability, but it may not reflect the latest available state.

A force-refresh request asks the backend to perform a fresh check, but backend rules, provider limitations, and Google-side behavior may still affect the final response.

🧠 Result Interpretation

Google Footprint results should be interpreted as technical footprint signals.

The presence of a profile, Gaia ID, avatar, service signal, Maps page, or Drive metadata does not prove that the account is currently active.

Important interpretation rules:

Analysts should combine Google Footprint results with other evidence, such as breach data, public profiles, account activity logs, OSINT findings, and internal investigation context.

A careful analysis process should follow these steps.

1. Select the Correct Input Type

Use Email for Gmail or Google account addresses, Gaia ID for known numeric identifiers, and Drive / Sheets for file investigations.

2. Validate the Target

Make sure the submitted value is correctly formatted before running the check.

3. Review the Summary

Check status, cache state, API duration, total request time, and backend diagnostics.

4. Review Google Account Signals

Look for Gaia ID, avatar status, user type, profile modification date, and service indicators.

5. Check Maps and Service Data

Review Maps profile availability, contribution signals, Calendar, Chat, Play Games, and enterprise flags.

6. Analyze Drive Metadata

For file targets, review title, MIME type, owners, sharing role, creation date, modification date, and links.

7. Use Raw JSON Carefully

Enable raw output only when technical details are needed for deeper analysis.

8. Compare With Other Sources

Correlate results with Alias Radar, CrossTrace, breach intelligence, ULP data, and manual OSINT checks.

9. Avoid Overclaiming

Treat all signals as technical indicators unless supported by additional evidence.

10. Store Evidence Securely

Keep reports and JSON output in secure internal systems when used for investigations.

🛡️ Security, Privacy & Ethics

Google Footprint is intended for lawful OSINT, defensive cybersecurity, fraud prevention, compliance review, and authorized investigation.

Users must follow strict ethical rules:

The tool provides technical footprint intelligence. Responsible interpretation is required to avoid false positives and privacy harm.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Google Footprint is a Google account and file intelligence module that helps collect structured public and technical signals for Gmail accounts, Gaia IDs, Google Drive files, and Google Sheets documents.

It can return account metadata, Gaia identifiers, avatar information, Google service signals, Maps profile indicators, Drive file metadata, owners, links, timing information, cache state, and technical JSON.

The tool is designed for lawful OSINT, defensive cybersecurity, fraud analysis, compliance checks, SOC workflows, and digital footprint investigations. All findings should be treated as technical signals and validated with additional context before making conclusions.

Identity Intelligence

CrossTrace | Username & Email Intelligence

image.png

The platform available at dash.niamonx.io/cross_trace — known as CrossTrace — is a fast public identity intelligence module within the NiamonX platform. It is designed to search for public account traces connected to a username or email address and convert raw discovery signals into a clean, analyst-friendly report.

Overview of the Service

CrossTrace helps users discover public account-presence signals and profile traces associated with a single username or email address. The tool checks multiple public sources through the NiamonX backend, tracks scan progress live, removes technical scanner noise, and displays only readable, useful findings.

The module is designed for cybersecurity analysts, OSINT researchers, SOC teams, fraud investigators, compliance departments, brand protection teams, and authorized users who need to quickly understand where a username or email may appear across public platforms.

CrossTrace supports two main investigation modes:

The final report may include clickable public profiles, account-presence indicators, avatars, platform categories, confidence scores, extracted public details, clean JSON, and a copyable analyst report.

CrossTrace is not intended to prove account ownership automatically. A username match or email-presence signal should be treated as an investigative lead and manually verified using additional context.

🔍 How the Scan Works

When a user starts a CrossTrace scan, the system creates one backend job through the NiamonX infrastructure.

The backend checks supported public sources for traces linked to the submitted username or email address. While the job is running, the browser checks the scan status every few seconds using the existing scan ID.

Only the initial scan consumes one daily request. Live status checks do not consume additional tool quota.

Typical workflow:

  1. The user enters a username or email address.

  2. CrossTrace validates and normalizes the input.

  3. A backend scan starts.

  4. The interface displays live scan progress.

  5. The backend checks supported public sources.

  6. Raw scanner responses are cleaned and deduplicated.

  7. Technical API endpoints, debug data, and noisy records are hidden.

  8. The final report displays public traces, profile links, presence signals, categories, avatars, and scores.

Polling stops immediately after a final status is reached, such as Done, failed, cancelled, or error.

CrossTrace supports two target types.

Username

A username can be entered with or without a leading @.

Examples:

niamonx

@niamonx

If the username starts with @, the symbol is accepted and removed automatically.

Allowed username characters:

The user should not enter a URL.

Email

A complete email address can be submitted as an email target.

Example:

name@example.com

CrossTrace automatically detects the target as an email when the submitted value is a valid email address.

🚫 Unsupported Input

CrossTrace is focused on usernames and email addresses only.

The user should not submit:

For domain, IP, breach, ULP, Google, or advanced identity reports, users should use the appropriate dedicated NiamonX module.

⚙️ New CrossTrace Scan Interface

The scan interface contains the main controls required to start a new investigation.

Main fields and panels:

Element Description
Username or email address Main target input field
Scan options Optional scan configuration
Recent targets Quick access to recent local targets
Live scan status Real-time backend job progress
Summary Final report statistics
Found traces Cleaned and deduplicated results
Daily quota Plan-based request usage

The interface clearly states that one daily request is consumed only when a scan starts. Live status checks do not consume tool quota.

📡 Live Scan Status

The Live Scan Status section shows real-time progress until the scan reaches a final state.

It may display:

Example status structure:

DONE
Polling off
Scan completed
9 status checks
100%
732 / 732 sources

Polling behavior:

This makes CrossTrace suitable for live interactive analysis without wasting daily request limits on status checks.

📊 Summary Section

After the scan completes, CrossTrace generates a summary of the discovered traces.

The summary may include:

Example summary format:

Tool: cross_trace
Target: username
Target type: Username
Status: DONE
Found traces: 12
Profile links: 10
Presence signals: 2
Progress: 100%
Elapsed time: 41s
Cached result: No
Unique sites: 12
Avatars: 2

The summary helps analysts quickly understand how many useful public traces were found and how many of them include direct profile links.

image.png

🧠 Key Features

Username and Email Intelligence

CrossTrace can search public traces for both usernames and email addresses.

Fast Backend Scan

The tool starts one backend job and tracks it until completion.

Live Progress

The user can monitor scan progress in real time.

Quota-Safe Status Checks

Only the initial scan is quota-billed. Status checks use the existing scan ID and do not call the tool quota runner.

Cleaned Results

CrossTrace removes raw scanner endpoints, technical API data, debug logs, credentials, and noisy low-value records.

Deduplication

Repeated matches are merged into clean, unique traces.

When the scanner returns or safely derives a human-readable public profile URL, CrossTrace displays it as a clickable profile link.

Account-Presence Signals

Some services expose only whether an account appears to exist. CrossTrace labels these as account-presence signals.

Avatars

When available, public avatars are displayed for easier manual correlation.

Categories

Results are grouped into useful categories such as Identity, Streaming, Developer, Gaming, Social, Payments, Security, and Other.

Confidence Scores

Each trace may include a score to help analysts prioritize review.

Clean JSON and Copyable Report

CrossTrace can produce clean JSON and a copyable analyst report without raw API endpoints, job logs, scanner debug data, or credentials.

📋 Found Traces

The Found Traces section displays cleaned and deduplicated results only.

Each trace card may include:

Field Description
Site Platform or source where the trace was found
Category Source category, such as Identity, Gaming, Developer, or Social
Name Public name or username shown by the source
Signal type Direct profile or account-presence signal
Score Confidence or relevance score
Avatar Public avatar, if available
Details Extra public metadata, if returned
Profile link Clickable profile URL, when available

The interface may also include filtering by:

This helps analysts focus on specific source types or high-value findings.

CrossTrace separates findings into two important types.

A public profile link is a human-readable URL that can be opened and manually reviewed.

Examples of profile-link evidence may include:

Account-Presence Signals

An account-presence signal means the system detected that a username or email appears to be associated with a service, but a public profile link may not be available.

This may happen when:

CrossTrace labels these results clearly as account signals.

Presence signals are useful leads, but they should be interpreted more cautiously than direct profile links.

🧮 Score and Confidence

Each trace may include a score.

The score helps prioritize review and indicates the strength of the public signal.

Example interpretation:

Score Range Interpretation
90–100 Very strong trace, usually a direct or enriched profile
80–89 Strong trace, often a direct profile with reliable matching
70–79 Useful trace, worth manual validation
60–69 Presence signal or weaker public account indicator
Below 60 Low-confidence signal, if displayed

A high score does not prove account ownership. It only indicates that the trace is technically strong or relevant enough to review first.

🏷️ Categories

CrossTrace groups results into categories to make the report easier to understand.

Common categories include:

Category Description
Identity Identity or avatar-related services
Streaming Streaming and creator platforms
Developer Code, developer, and repository platforms
Gaming Gaming accounts and game-related platforms
Social Social networking services
Payments Payment, donation, or monetization platforms
Security Cybersecurity, breach, or threat-intelligence related sources
Other Sources that do not fit a main category

Categories help analysts understand the type of public footprint connected to the target.

For example, a username appearing across Developer and Gaming categories may suggest reuse across technical and gaming communities, while Identity or avatar services may help with cross-platform correlation.

🖼️ Avatars and Public Images

Some CrossTrace results may include public avatars.

Avatars can help analysts compare public profiles across platforms.

Useful avatar-based correlation signals:

Avatar similarity should not be treated as proof of identity by itself. It should be combined with usernames, platform IDs, profile content, timelines, and additional evidence.

🧬 Enriched Metadata

When available, CrossTrace may show enriched metadata for a trace.

Possible metadata includes:

Some traces may return no extra public details. In that case, the interface clearly indicates that no extra public details were returned for that trace.

This keeps the report transparent and avoids inventing unsupported information.

🧾 Clean JSON and Analyst Report

CrossTrace can provide export-ready evidence summaries.

The clean report may include:

The clean JSON output is useful for:

The output intentionally excludes raw API endpoints, job logs, scanner debug data, and credentials.

🚦 Daily Quota

CrossTrace uses plan-based daily request limits.

Example quota display:

Available requests today: 999
Daily limit: 1000
Used today: 1
Plan: Sentinel

Quota behavior:

This prevents unnecessary quota usage while still allowing live progress tracking.

💾 Recent Targets

The interface may include a Recent Targets section.

This helps users quickly rerun or review recent username and email checks.

Recent target history should be treated carefully because usernames and emails may be sensitive in an investigation context.

On shared devices, users should clear local browser data when necessary.

🧠 Result Interpretation

CrossTrace results are public technical signals.

A username match or email-presence signal does not prove that an account belongs to a specific person.

Each result should be treated as a lead.

Some services expose only account availability signals. CrossTrace labels those as account signals and hides technical endpoints to keep the report safe and readable.

A careful CrossTrace investigation should follow this process.

1. Choose the Correct Target Type

Use a username for alias-based checks or a complete email address for email-based traces.

2. Start the Scan

Submit the target and let the backend job complete.

3. Review the Summary

Check found traces, profile links, presence signals, unique sites, avatars, elapsed time, and cache status.

4. Prioritize Direct Profiles

Start with direct profile links because they allow manual review.

5. Review High-Score Results

High-score traces should be checked first.

6. Separate Profile Links From Presence Signals

Presence signals are useful but weaker than direct public profile links.

7. Compare Public Details

Use avatars, display names, usernames, linked accounts, and identifiers for correlation.

8. Avoid Overclaiming

Use cautious wording such as “possible trace,” “public signal,” or “account-presence indicator” unless ownership is verified.

9. Export Evidence

Use clean JSON or the copyable analyst report for internal documentation.

10. Store Results Securely

Treat reports as sensitive investigation data, especially when they contain emails, usernames, avatars, or account-presence signals.

🛡️ Security, Privacy & Ethics

CrossTrace is intended for lawful OSINT, defensive cybersecurity, fraud prevention, brand protection, compliance, and authorized investigation.

Users must follow strict ethical rules:

Responsible interpretation is essential because public account discovery can produce false positives, especially when usernames are reused by different people.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Data Removal / Privacy Takedown Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX CrossTrace is a fast username and email intelligence module that searches for public account traces and account-presence signals across supported public sources.

It starts one backend scan, tracks progress live, cleans and deduplicates raw results, hides technical scanner data, and presents a readable analyst report with profile links, presence signals, avatars, categories, scores, clean JSON, and export-ready summaries.

The tool is designed for lawful OSINT, defensive cybersecurity, fraud investigation, brand protection, SOC workflows, compliance review, and identity correlation. All results should be treated as public technical signals and manually verified before making conclusions about identity or ownership.

Networks and WiFi

Networks and WiFi

Networks and WiFi

Wifi Map & Data Search | WiFi Hotspot Intelligence

image.png

The platform available at https://dash.niamonx.io/wifi_data — known as Wifi Map & Data Search — is a WiFi hotspot intelligence and research tool within the NiamonX platform. It allows authorized users to search publicly available WiFi hotspot datasets by BSSID, ESSID, or WiFi key indicators and visualize matching access points on an interactive map.

Overview of the Service

Wifi Map & Data Search is designed for research, security analysis, wireless exposure review, and OSINT-style investigation of publicly available WiFi hotspot records.

The tool allows users to search known hotspot data using several search modes, including BSSID, ESSID, and WiFi key. Results may include network identifiers, security type, weak-key indicators, approximate coordinates, and map visualization.

The service is intended strictly for lawful research, defensive security, infrastructure audit, and awareness purposes. It must not be used to access networks without authorization.

WiFi data can be sensitive because it may include network names, access point identifiers, approximate locations, and historical credential-like values. Users must handle results responsibly and comply with local laws.

🔍 How the Search Works

When a user enters a query, the system searches a publicly available WiFi hotspot dataset using the selected mode.

Supported search modes include:

The backend returns matching records, and the interface displays them in a structured results table. If coordinates are available, matching points can also be shown on a Leaflet map powered by OpenStreetMap.

The system supports rate limiting and short-term caching. Cache is typically valid for a few minutes, which helps reduce repeated backend requests for identical queries.

Example search flow:

  1. Select a search mode.

  2. Enter a BSSID, ESSID, or WiFi key indicator.

  3. Submit the query.

  4. Review matching hotspot records.

  5. Check security type and weak-key indicators.

  6. View approximate location on the map when coordinates are available.

  7. Export visible rows when needed.

  8. Use results only for lawful and authorized research.

Wifi Map & Data Search supports several query types.

BSSID

BSSID is the MAC address of a wireless access point.

Example format:

00:11:22:33:44:55

BSSID search is useful when the analyst has a known access point identifier and wants to check whether it appears in the dataset.

ESSID

ESSID is the public WiFi network name, often shown as the visible WiFi name on devices.

Example:

Office_WiFi

ESSID searches may support different match modes:

This allows users to search for networks by full name, prefix, or partial string.

WiFi Key

WiFi key search allows checking whether a specific known key value appears in the dataset.

This mode should be used carefully and only for defensive or authorized research, such as verifying whether a weak or reused test password appears in public data.

Sensitive keys should be masked in documentation, reports, screenshots, and exports.

Example masked format:

********

⚙️ Search Modes

The tool supports multiple modes depending on the type of value being searched.

Mode Description
bssid Search by access point MAC address
essid Search by WiFi network name
wifikey / password Search by WiFi key indicator

Depending on the interface version, the WiFi key mode may be shown as password, wifikey, or similar internal naming.

🔎 ESSID Match Modes

ESSID search can use different matching modes.

Match Mode Description
substr Finds ESSIDs containing the entered text
prefix Finds ESSIDs starting with the entered text
exact Finds only exact ESSID matches

Examples:

substr: finds "Office_WiFi_Main" when searching "WiFi"

prefix: finds "Office_5G" when searching "Office"

exact: finds only "Office_WiFi"

Using exact mode reduces noise. Substring mode is useful for broad discovery but may return unrelated results.

📊 Results Table

After a successful search, matching records are shown in a structured table.

Typical columns include:

Column Description
BSSID Numeric or internal BSSID representation
BSSID string Standard MAC address format
ESSID WiFi network name
WiFi Key Key value, if present and permitted
Security Detected or inferred security type
Weak Weak-key or weak-security indicator
Coords Latitude and longitude, if available
Actions Available record actions

Sensitive fields such as WiFi keys should be masked when screenshots, reports, or documentation are shared.

Example safe display format:

BSSID: 00:11:22:33:44:55
ESSID: Example_Network
WiFi Key: ********
Security: WPA2/WPA3
Coords: 47.0000, 35.0000

🗺️ Map View

The tool includes a map view for records with coordinates.

The map is based on Leaflet and OpenStreetMap.

The interface may display up to a limited number of points, for example:

Map: up to 200 points

The map helps users visually understand the geographic distribution of matching access points.

Map use cases:

Coordinates should be treated as sensitive. They may represent approximate or historical locations and should not be used for harassment, trespassing, or unauthorized access.

🧠 Key Features

Public WiFi Dataset Search

The tool searches publicly available WiFi hotspot records for research and analysis.

BSSID Lookup

Users can search for a specific access point MAC address.

ESSID Lookup

Users can search by network name with substring, prefix, or exact matching.

WiFi Key Indicator Search

Users can check whether known key values appear in the dataset for authorized security review.

Security Heuristics

The tool displays inferred security information such as WPA2, WPA3, WEP, or open-network indicators when available.

Weak Indicator

The system may mark a record as weak when the key is empty, simple, reused, or when the detected security configuration appears low-security.

Coordinates

Records may include latitude and longitude.

Leaflet Map

Matching records with coordinates can be visualized on an interactive map.

Rate Limit

The interface shows remaining requests and reset timing.

Cache

Repeated searches may be cached for a short time.

Local Request History

Recent searches are stored locally in the browser.

CSV Export

Visible rows can be exported to CSV.

🚦 Rate Limit and Cache

Wifi Map & Data Search includes rate limiting and caching.

Example rate-limit format:

Limit: 119 left / reset 600s

This means the user has a certain number of requests remaining until the reset window.

Cache behavior:

Cache is valid for approximately 3 minutes.

Caching helps reduce repeated backend lookups for identical queries and improves response speed.

Rate limits help protect the service from abuse and ensure fair access.

🕓 Request History

The Request History panel stores recent searches locally in the browser.

History entries may include:

Example safe history format:

bssid
00:11:22:33:44:55
17.06.2026, 21:47:35

Local history is useful for repeating previous searches, but it may contain sensitive search values.

Users should clear browser data or local history when working on shared or public devices.

📤 CSV Export

The tool can export visible rows to CSV.

CSV export may include:

Sensitive values such as WiFi keys should be masked or excluded before sharing externally.

CSV exports should be stored securely and used only for authorized research, reporting, or internal audit workflows.

🔐 Security Field Interpretation

The Security column is based on heuristics and available dataset values.

Possible security labels may include:

Some internal numeric values may map to security guesses.

Example interpretation:

128 = possible WEP / Open
225 = possible WPA2

These values are heuristic and should not be treated as guaranteed technical truth.

Manual validation is recommended for security audits.

⚠️ Weak Indicator

The Weak field helps identify potentially risky hotspot records.

A network may be marked weak when:

Weak indicators should be treated as triage signals, not final conclusions.

Organizations should review their own networks and replace weak configurations with strong WPA2/WPA3 security and unique passwords.

🧠 Result Interpretation

WiFi dataset results should be interpreted carefully.

Important notes:

The tool should be used for research, verification, and defensive awareness, not for intrusion or unauthorized connectivity.

A responsible workflow should follow these steps.

1. Select the Correct Mode

Use BSSID for access point identifiers, ESSID for network names, and WiFi key search only for authorized security review.

2. Use Exact Search When Possible

Exact search reduces false positives, especially for ESSID values.

3. Review Security and Weak Indicators

Check whether the record suggests weak security or risky configuration.

4. Check Coordinates Carefully

Use map data as approximate context, not absolute proof.

5. Avoid Exposing Keys

Mask WiFi keys in reports, screenshots, and documentation.

6. Export Only What Is Needed

Use CSV export only for authorized workflows.

7. Remediate Owned Networks

If a network you control appears with a weak key or exposed record, rotate credentials and update security settings.

8. Validate Before Action

Do not assume that dataset records are current or fully accurate.

🛡️ Security, Privacy & Responsible Use

Wifi Map & Data Search is a sensitive OSINT and research tool. It must be used responsibly.

Acceptable use cases include:

Strictly prohibited use includes:

Users must comply with the laws of their jurisdiction and platform rules. Misuse may result in account restriction or termination.

🔧 Remediation Recommendations

If an owned or authorized network appears in search results with risky data, recommended actions include:

Change the WiFi Password

Immediately rotate exposed or weak credentials.

Use WPA2/WPA3

Avoid WEP, open networks, and outdated encryption.

Use a Strong Unique Key

Use a long, random password that is not reused elsewhere.

Disable WPS

WPS can introduce additional attack surface.

Rename Sensitive ESSIDs

Avoid exposing company names, addresses, personal names, or device roles in the ESSID.

Segment Guest Networks

Keep guest WiFi separate from internal systems.

Review Router Firmware

Update access point firmware and apply security patches.

Monitor for Re-Exposure

Recheck periodically after remediation.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Wifi Map & Data Search is a WiFi hotspot intelligence tool for searching publicly available hotspot records by BSSID, ESSID, or WiFi key indicators. It provides structured results, security heuristics, weak-key indicators, coordinates, Leaflet map visualization, rate limiting, short-term caching, local browser history, and CSV export.

The tool is intended for lawful research, wireless security auditing, OSINT analysis, exposure review, and defensive remediation. It must never be used for unauthorized network access, harassment, credential misuse, or privacy-invasive activity.

Networks and WiFi

IP Intelligence Search | Global IP Lookup

image.png

The platform available at https://dash.niamonx.io/global_iplookup — known as IP Intelligence Search (Global IP Lookup) — is a global IP intelligence and infrastructure analysis tool within the NiamonX platform. It allows users to search detailed information about IPv4 and IPv6 addresses using the NiamonX Crawler database catalog and receive structured data about geolocation, ASN, organization, ISP, open ports, services, hostnames, domains, vulnerabilities, fingerprints, and raw service metadata.

Overview of the Service

IP Intelligence Search (Global IP Lookup) is designed for analysts, SOC teams, cybersecurity researchers, incident responders, infrastructure owners, and OSINT specialists who need to understand what is publicly observable about a specific IP address.

The tool provides a consolidated view of an IP address from a global crawler database. It can show the IP’s network ownership, ASN, organization, ISP, country, region, city, coordinates, related hostnames, associated domains, exposed ports, detected products, service banners, HTTP metadata, SSL-related data when available, vulnerability aggregation, CVSS scoring, tags, labels, and raw JSON for deeper inspection.

The module accepts only IP addresses. Domains, URLs, paths, and search operators are not valid inputs.

🔍 How the Search Works

When a user enters an IPv4 or IPv6 address, the tool queries the global crawler database catalog and returns the available record for that IP.

The returned information may include:

The tool displays general information first, then provides a detailed services and ports table. Large service responses are rendered lazily, meaning details are shown only when the user expands a specific service row. This reduces browser and DOM load, especially for IPs with many open services.

Global IP Lookup supports:

Valid examples:

1.1.1.1

8.8.8.8

2001:4860:4860::8888

Unsupported inputs:

example.com

https://example.com

example.com/login

1.1.1.1:443

The tool expects only a clean IPv4 or IPv6 value.

⚙️ Search Interface

The interface contains the main input and optional historical data setting.

IP Address

The main field where the user enters an IPv4 or IPv6 address.

Example:

1.1.1.1

The interface clearly states:

Only IPv4 or IPv6. No domains or URLs.

Historical Data

The Historical Data option allows the server to return archival information when supported.

Historical layers may include older observations, previous ports, older banners, previous technologies, or past service states.

Important: historical data is returned only when available and supported by the backend.

📊 General Information

After a successful lookup, the tool displays a general information panel for the IP address.

Possible fields include:

Field Description
IP Queried IPv4 or IPv6 address
ASN Autonomous System Number
Organization Network owner or responsible organization
ISP Internet Service Provider
Country Country and country code
Region / City Geographic region and city
Coordinates Latitude and longitude
Ports Number of observed ports
Services Number of service records
Hosts Number of hostnames
Domains Number of related domains
Tags Number of tags or labels

Example structure:

IP: 1.1.1.1
ASN: AS13335
Organization: Example Network Project
ISP: Example ISP
Country: Australia (AU)
Region / City: QLD / Brisbane
Coordinates: -27.48159, 153.0175
Ports: 11
Services: 12
Vulns: 0

This section gives users a quick operational overview of the IP address before reviewing individual services.

🗺️ Geolocation and Map

The tool includes a geolocation map powered by Leaflet and OpenStreetMap.

The map displays the approximate location of the IP address based on geolocation data returned by the crawler database.

Possible location fields:

Important interpretation notes:

Geolocation should be used as context, not as precise physical attribution.

🏷️ Tags and Labels

The tool can display tags and labels returned by the crawler database.

Examples of possible tags:

If no tags are returned, the interface may display:

No

Tags help analysts quickly classify the IP, but they should be treated as metadata rather than final conclusions.

🌐 Hostnames and Domains

The tool displays hostnames and domains associated with the IP address when available.

Hostnames

Hostnames may include DNS names, reverse DNS names, or observed service names.

Example:

one.one.one.one

Domains

Domains may include root domains or associated domains found in the crawler data.

Example:

one.one

Important notes:

🔌 Services and Ports

The Services / Ports section displays observed open ports and detected services.

The table may include:

Column Description
Port Port number
Protocol TCP or UDP
Product / Version Detected product and version
CVEs Number of linked CVEs
Max CVSS Maximum vulnerability severity score
Scan Scan date

Example service rows:

53    TCP    —           0    —    2026-06-17
443   TCP    CloudFlare  0    —    2026-06-17
8880  TCP    CloudFlare  0    —    2026-06-17

The table can be filtered by port or product name, allowing analysts to quickly find relevant services.

🔎 Service Filtering and Sorting

The services table supports quick filtering.

Users can search by:

Example:

Filter: 443

Filter: CloudFlare

Sorting by columns helps analysts prioritize:

🧾 Service Details

Clicking the disclosure button on a service row opens detailed service information.

The details view may include:

Main

HTTP

Location

Vulnerabilities

Raw JSON

This drill-down structure allows the interface to remain fast while still providing deep technical visibility when needed.

🌐 HTTP Metadata

For HTTP or HTTPS services, the tool may show HTTP-level metadata.

Possible fields include:

Field Description
Status HTTP status code
Server Server response header
Title HTML page title
Location Redirect target
WAF Web application firewall or CDN indicator
Components Detected technologies
HTML hash Hash of returned HTML
Headers hash Hash of headers
DOM hash DOM fingerprint
Security.txt Security policy file data, if found
Robots.txt Robots file data, if found
Sitemap Sitemap data, if found

Example:

Status: 301
Server: cloudflare
Title: 301 Moved Permanently
Location: /

HTTP metadata is useful for web service fingerprinting, CDN detection, redirect analysis, and change tracking.

🧬 Hashes and Fingerprints

The tool may display multiple hashes and fingerprints.

Examples:

These hashes are useful for:

A hash does not identify a service by itself. It is a technical fingerprint that should be interpreted with context.

🛡️ Vulnerability Aggregation

The tool aggregates vulnerability data for services when CVEs are available.

The service table may show:

CVSS Color Labels

The interface may use color labels based on CVSS score.

General interpretation:

CVSS Range Severity
≤ 4 Low
4–7 Medium
≥ 7 High

The Max CVSS field shows the maximum vulnerability score associated with the service.

Important: a CVE association does not always prove exploitability. Product detection, version accuracy, configuration, and exposure context must be validated manually.

📦 Raw JSON Viewer

Each service can include a raw JSON view.

Raw JSON may contain:

Raw JSON is useful for:

Raw data should be handled carefully because it may include detailed infrastructure fingerprints.

🕓 Historical Data

When the Historical Data option is enabled, the backend may return archival information if supported.

Historical data can help analysts understand:

Important interpretation:

When History is enabled, the server may return historical layers if supported.

Historical data may not be available for every IP address and should be clearly separated from current observations.

📤 Export and Copy Options

The tool supports analyst-friendly export and copy workflows.

Possible output options include:

CSV export is useful for:

Exports should be stored securely, especially when they include infrastructure fingerprints or vulnerability data.

🕘 Request History

The tool may store entered IPs in local browser history through LocalStorage.

History can help users quickly repeat previous lookups.

Local history may include:

Because this history is browser-local, it may be cleared when users delete browser data or switch devices.

On shared devices, local history should be cleared after sensitive investigations.

🧠 Key Features

Global IP Lookup

Search detailed information about IPv4 and IPv6 addresses.

NiamonX Crawler Database

Results come from the global crawler database catalog.

General IP Intelligence

Shows ASN, organization, ISP, country, region, city, coordinates, ports, services, hostnames, domains, and tags.

Geolocation Map

Displays approximate location on a Leaflet / OpenStreetMap map.

Service and Port Inventory

Lists observed open ports, protocols, products, versions, scan dates, CVE counts, and Max CVSS.

Vulnerability Aggregation

Aggregates CVE and CVSS data per service when available.

Raw JSON

Allows detailed inspection of service-level raw records.

Lazy Rendering

Large service details are rendered only when opened, reducing browser load.

Historical Data

Can request archival information when supported.

Filtering and Sorting

Users can search services by port or product name and sort columns.

Export

Supports summary / JSON copy and CSV export.

Local History

Stores previously entered IPs locally in the browser.

A practical IP investigation workflow should follow these steps.

1. Enter a Clean IP Address

Use only IPv4 or IPv6. Do not include domains, URLs, ports, or paths.

2. Review General Information

Check ASN, organization, ISP, country, region, city, coordinates, ports, services, hostnames, and domains.

3. Check Geolocation

Use the map for approximate context, but do not treat it as exact physical attribution.

4. Review Open Ports

Sort and filter services by port, product, scan date, or CVSS score.

5. Expand Important Services

Open details for exposed web services, remote access services, databases, or unusual ports.

6. Review Vulnerability Data

Check CVE count and Max CVSS, but validate product and version accuracy before making conclusions.

7. Inspect Raw JSON When Needed

Use raw data for deeper technical analysis or integration workflows.

8. Compare Current and Historical Data

Enable historical data when investigating exposure changes over time.

9. Export Evidence

Use CSV or JSON export for internal reporting.

10. Validate Before Action

Confirm important findings with additional tools, asset owners, or direct authorized scans.

🛡️ Security, Privacy & Responsible Use

IP Intelligence Search is intended for lawful cybersecurity, OSINT, asset analysis, incident response, and exposure management.

Acceptable use cases include:

Users must follow responsible use rules:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX IP Intelligence Search (Global IP Lookup) is a global IP intelligence tool for analyzing IPv4 and IPv6 addresses through the NiamonX Crawler database catalog.

It provides ASN, organization, ISP, geolocation, hostnames, domains, open ports, services, products, HTTP metadata, fingerprints, CVEs, CVSS scores, historical layers, raw JSON, filtering, sorting, CSV export, and local lookup history.

The tool is designed for lawful OSINT, SOC triage, threat intelligence, vulnerability review, asset monitoring, compliance, and incident response. Results should be treated as intelligence signals and validated before operational or security decisions.

Networks and WiFi

IP Calculator | IPv4 Subnet, Converter & Network Toolkit

image.png

The platform available at https://dash.niamonx.io/ipcalc_net — known as IP Calculator — is a universal IPv4 network toolkit within the NiamonX platform. It helps users calculate subnets, convert IPv4 values between different representations, derive subnet masks, check address ranges, calculate usable hosts, work with wildcard masks, and perform practical network planning tasks.

Overview of the Service

IP Calculator is designed for network engineers, system administrators, cybersecurity analysts, DevOps teams, students, and technical users who need a fast and reliable way to calculate IPv4 subnet information.

The tool combines several network utilities in one interface:

It can calculate network address, broadcast address, subnet mask, wildcard mask, first host, last host, total addresses, usable hosts, IP class, private range status, decimal representation, binary representation, hexadecimal representation, and mask representations.

All computations are performed server-side, and access is controlled through plan-based query limits.

🔍 How the Tool Works

The user can either enter a full CIDR value or provide an IP address and prefix separately.

Example CIDR input:

10.0.0.1/24

The tool parses the address, applies the prefix, and calculates the full subnet range.

For example, for:

10.0.0.1/24

the tool returns:

Network: 10.0.0.0
Broadcast: 10.0.0.255
Mask: 255.255.255.0
First host: 10.0.0.1
Last host: 10.0.0.254
Total: 256
Usable: 254

The interface also shows technical representations of both the IP address and subnet mask in decimal, binary, and hexadecimal formats.

🧩 Main Tool Modules

IP Calculator includes several practical modules.

Subnet Calculator

Calculates subnet boundaries and host ranges from an IPv4 address and CIDR prefix.

Useful for:

Base Converter

Converts IPv4 values between different formats.

Supported conversion types may include:

Mask Calculator

Calculates subnet mask and prefix information.

It can also derive the minimal prefix required for a desired number of hosts.

Network Tools

Provides additional utilities for CIDR aggregation, range operations, and membership checks.

CIDR Aggregation

Helps combine compatible networks into a shorter aggregated CIDR block when possible.

IP Membership Check

Checks whether a specific IP address belongs to a selected subnet or range.

⚙️ Interface Structure

The interface is divided into practical tabs and panels.

Main sections:

Section Purpose
Subnet Calculator Calculate subnet range and host information
Base Converter Convert IP values between decimal, binary, hex, and CIDR formats
Mask Calculator Calculate prefix, mask, wildcard, and host capacity
Network Tools Work with aggregation, ranges, and membership checks
Request History Review recent local calculations

The interface also displays daily query limits based on the current plan.

Example:

59999 / 60000
Queries remaining / total
Plan: Sentinel

🧮 Subnet Calculator

The Subnet Calculator is the main module for IPv4 subnet analysis.

Users can provide input in two ways:

CIDR Input

Example:

10.0.0.1/24

IP + Prefix Input

Example:

IP: 192.168.1.10
Prefix: /24

Both input methods produce the same type of subnet output.

📊 Subnet Output Fields

After calculation, the tool displays the subnet details.

Field Description
Network First address of the subnet
Broadcast Broadcast address of the subnet
Mask Subnet mask in dotted decimal format
Prefix CIDR prefix length
Wildcard Inverse subnet mask
First host First usable host address
Last host Last usable host address
Total Total number of addresses in the subnet
Usable Number of usable host addresses
Class IPv4 class
Private Whether the address belongs to a private range

Example result:

Network: 10.0.0.0
Broadcast: 10.0.0.255
Mask: 255.255.255.0
Prefix: 24
Wildcard: 0.0.0.255
First host: 10.0.0.1
Last host: 10.0.0.254
Total: 256
Usable: 254
Class: A
Private: Yes

🌐 Network Address

The Network field shows the first address of the subnet.

Example:

10.0.0.0

The network address identifies the subnet itself and is normally not assigned to a regular host.

📡 Broadcast Address

The Broadcast field shows the last address of the subnet.

Example:

10.0.0.255

In traditional IPv4 networking, the broadcast address is used to send packets to all hosts in the subnet.

For most standard subnets, the broadcast address is not assigned to a normal host.

🎭 Subnet Mask

The Mask field shows the subnet mask in dotted decimal notation.

Example:

255.255.255.0

A subnet mask defines which part of the IP address belongs to the network and which part belongs to host addressing.

🧱 Prefix

The Prefix field shows the CIDR prefix length.

Example:

/24

The prefix indicates how many bits are used for the network portion.

Common prefixes:

Prefix Mask Typical Use
/8 255.0.0.0 Large private or enterprise blocks
/16 255.255.0.0 Medium-sized internal networks
/24 255.255.255.0 Common LAN subnet
/30 255.255.255.252 Point-to-point links
/31 255.255.255.254 Point-to-point links with special handling
/32 255.255.255.255 Single host route

🃏 Wildcard Mask

The Wildcard field shows the inverse of the subnet mask.

Example:

000000FF (0.0.0.255)

Wildcard masks are commonly used in:

For a /24 subnet, the mask is:

255.255.255.0

and the wildcard is:

0.0.0.255

🖥️ First and Last Host

The tool calculates the usable host range.

Example for /24:

First host: 10.0.0.1
Last host: 10.0.0.254

These are the first and last usable IP addresses in the subnet.

For special prefixes such as /31 and /32, usable host logic is handled as an edge case.

🔢 Total and Usable Addresses

The Total field shows the total number of addresses in the subnet.

The Usable field shows how many addresses can typically be assigned to hosts.

Example:

Total: 256
Usable: 254

For most IPv4 subnets, usable addresses exclude the network and broadcast addresses.

Special cases:

The tool accounts for usable host count in these edge cases.

🏷️ Class Detection

The tool detects the traditional IPv4 class of the entered address.

IPv4 class ranges:

Class Range Notes
A 1.0.0.0 – 126.255.255.255 Large networks
B 128.0.0.0 – 191.255.255.255 Medium networks
C 192.0.0.0 – 223.255.255.255 Smaller networks
D 224.0.0.0 – 239.255.255.255 Multicast
E 240.0.0.0 – 255.255.255.255 Reserved / experimental

Class detection is useful for educational and compatibility contexts, although modern networking primarily uses CIDR.

🔐 Private Range Check

The Private field indicates whether the IP belongs to a private IPv4 range.

Private IPv4 ranges:

Range CIDR
10.0.0.0 – 10.255.255.255 10.0.0.0/8
172.16.0.0 – 172.31.255.255 172.16.0.0/12
192.168.0.0 – 192.168.255.255 192.168.0.0/16

Example:

Private: Yes

Private addresses are normally used inside internal networks and are not directly routed on the public Internet.

🔄 Representations

The Representations section shows the IP address and mask in multiple numeric bases.

For the IP:

10.0.0.1

the tool may show:

IP (dec): 167772161
IP (bin): 00001010000000000000000000000001
IP (hex): 0A000001

For the mask:

255.255.255.0

the tool may show:

Mask (dec): 4294967040
Mask (bin): 11111111111111111111111100000000
Mask (hex): FFFFFF00

These representations are useful for:

🔢 Base Converter

The Base Converter supports conversion between IP-related formats.

Supported values may include:

Example decimal value:

4294967295

Example binary value:

11111111111111111111111111111111

Example hexadecimal value:

FFFFFFFF

The converter helps users move between human-readable IP formats and machine-level representations.

🎯 Mask Calculator

The Mask Calculator can derive subnet information from a prefix or from required host capacity.

Example prefix input:

prefix = 24

Expected output:

/24
255.255.255.0

The mask calculator can also derive the minimal prefix for a required number of hosts.

Example use case:

Required hosts: 200

The tool calculates the smallest subnet that can contain the requested number of usable addresses.

This is useful for:

🧩 CIDR Aggregation

CIDR aggregation helps combine adjacent networks into a shorter summary route when possible.

Example use cases:

Aggregation should be used carefully because an overly broad summary may include addresses that should not be covered by a rule.

✅ IP Membership Check

The membership check helps determine whether an IP belongs to a given subnet.

Example question:

Does 192.168.1.50 belong to 192.168.1.0/24?

Expected result:

Yes

This is useful for:

🕓 Request History

The tool stores recent calculations locally in the user’s browser.

Example behavior:

We store the last 200 queries locally in your browser.

History entries may include:

Example history item:

subnet
10.0.0.1/24
10.0.0.0..10.0.0.255
17.06.2026, 21:53:23

Request history is useful for repeating calculations, reviewing previous subnet work, and documenting network planning sessions.

Because history is stored locally in the browser, it may be cleared by deleting browser data or using another device.

🚦 Query Limits and Plan Access

IP Calculator uses plan-based query limits.

Example:

59999 / 60000
Queries remaining / total
Plan: Sentinel

Important points:

🧠 Key Features

Universal IPv4 Toolkit

Combines subnet calculation, conversion, mask calculation, and network utilities.

CIDR Support

Accepts CIDR notation such as:

192.168.1.10/24

IP + Prefix Input

Users can enter IP and prefix separately.

Subnet Range Calculation

Returns network, broadcast, first host, last host, total addresses, and usable addresses.

Wildcard Mask

Calculates wildcard mask in hexadecimal and dotted decimal formats.

Base Conversion

Converts IP and mask values to decimal, binary, and hexadecimal.

Class Detection

Detects traditional IPv4 class.

Private Range Detection

Checks whether an IP belongs to RFC1918-style private address ranges.

Edge Case Handling

Handles usable host calculations for /31 and /32.

Mask Calculator

Derives prefix and mask values, including host-based sizing.

CIDR Aggregation

Supports network summarization workflows.

Membership Check

Checks whether an IP belongs to a specific subnet.

Local Request History

Stores up to 200 recent calculations in the browser.

📌 Practical Examples

Example 1: Standard LAN Subnet

Input:

192.168.1.10/24

Result:

Network: 192.168.1.0
Broadcast: 192.168.1.255
Mask: 255.255.255.0
Usable hosts: 254
Private: Yes

Use case:

Example 2: Larger Private Subnet

Input:

192.168.1.10/20

Result:

Network: 192.168.0.0
Broadcast: 192.168.15.255

Use case:

Example 3: Decimal Conversion

Input:

4294967295

Possible output:

IP: 255.255.255.255
Binary: 11111111111111111111111111111111
Hex: FFFFFFFF

Use case:

Example 4: Prefix to Mask

Input:

prefix: 24

Output:

/24
255.255.255.0
Wildcard: 0.0.0.255

Use case:

A practical workflow depends on the user’s goal.

For Subnet Planning

  1. Enter CIDR notation or IP + prefix.

  2. Review network and broadcast address.

  3. Check usable host count.

  4. Confirm private/public status.

  5. Copy mask and wildcard values for configuration.

For Firewall Rules

  1. Calculate subnet and wildcard mask.

  2. Validate range boundaries.

  3. Check membership for test IPs.

  4. Avoid overly broad CIDR blocks.

For Cloud Networking

  1. Calculate required host capacity.

  2. Use Mask Calculator to derive minimal prefix.

  3. Reserve space for growth.

  4. Validate non-overlap with existing networks.

For Troubleshooting

  1. Convert IPs to binary or decimal.

  2. Compare masks.

  3. Check IP membership.

  4. Confirm network boundaries.

🛡️ Security and Responsible Use

IP Calculator is a technical utility intended for legitimate network planning, education, administration, and cybersecurity workflows.

Acceptable use cases include:

Users should apply results carefully:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX IP Calculator is a universal IPv4 subnet and conversion toolkit for calculating network ranges, broadcast addresses, subnet masks, wildcard masks, usable hosts, decimal / binary / hexadecimal representations, CIDR aggregation, and IP membership.

It is designed for network planning, routing, firewall configuration, cloud infrastructure, SOC workflows, DevOps, education, and troubleshooting. The tool performs calculations server-side, enforces plan-based limits, and stores the last 200 queries locally in the browser for convenience.

Networks and WiFi

IP / Domain Explorer | IP and Domain Geolocation & Network Intelligence

image.png

The platform available at https://dash.niamonx.io/ipexplorer — known as IP / Domain Explorer — is a lightweight IP and domain intelligence tool within the NiamonX platform. It allows users to check geographic, network, ASN, ISP, reverse DNS, and infrastructure attributes for an IPv4 address, IPv6 address, or domain name.

Overview of the Service

IP / Domain Explorer is designed to quickly identify where an IP address or domain is located from a network intelligence perspective and which organization, ISP, Autonomous System, and infrastructure attributes are associated with it.

The tool combines internal NiamonX systems with public databases to provide a structured overview of IP or domain metadata. It is useful for cybersecurity analysts, SOC teams, system administrators, fraud investigators, OSINT researchers, compliance teams, and technical users who need a fast way to understand the basic network profile of an address or domain.

The module supports:

The result includes location, coordinates, timezone, currency, network ownership, ASN, reverse DNS, and classification flags such as proxy, hosting, or mobile network.

🔍 How the Tool Works

When a user enters an IP address or domain name, IP / Domain Explorer performs a lookup through internal systems and public intelligence databases.

For domain input, the tool resolves or analyzes the domain and returns the available network and geolocation information. For IP input, the tool directly checks the IP address against available IP intelligence sources.

The returned result is displayed as a structured report containing:

The result is intended to provide quick situational awareness, not a final legal or attribution conclusion.

IP / Domain Explorer accepts the following input types.

IPv4 Address

Example:

1.1.1.1

IPv6 Address

Example:

2606:4700:4700::1111

Domain Name

Example:

example.com

Internationalized Domain Name

Domains with Unicode characters are supported when accepted by the backend.

Example:

пример.рф

The tool should not be used with full URLs, URL paths, or unrelated search operators.

Invalid examples:

https://example.com/login

example.com/path/page.html

1.1.1.1:443

For best results, users should enter only a clean IP address or domain name.

⚙️ Search Interface

The main interface contains a simple input field.

IP Address or Domain

The user enters an IPv4 address, IPv6 address, or domain.

Example:

1.1.1.1

The interface indicates that IPv4, IPv6, and domains are supported, including IDN domains entered in Unicode.

After submission, the tool returns a structured result panel.

📊 Result Overview

A successful lookup displays a short summary at the top of the result.

Example structure:

Successfully: 1.1.1.1
Location: Australia, Queensland, South Brisbane
Coordinates: -27.476600, 153.016600
Network: Cloudflare, Inc / APNIC and Cloudflare DNS Resolver project
AS: AS13335 Cloudflare, Inc. - CLOUDFLARENET
Flags: Hosting

This summary gives the user a quick understanding of:

🌍 Location Information

The tool returns geographic fields associated with the IP or resolved domain.

Possible location fields include:

Field Description
Continent Continent name
Continent code Short continent code
Country Country name
Country code ISO country code
Region code Short region or state code
Region name Full region or state name
City City associated with the IP
District District or area, if available
Postal code Postal or ZIP code, if available
Latitude Approximate latitude
Longitude Approximate longitude

Example:

Continent: Oceania
Country: Australia
Region: Queensland
City: South Brisbane
Latitude: -27.476600
Longitude: 153.016600

Geolocation data should be treated as approximate. It may represent a network registration location, provider infrastructure, routing endpoint, cloud region, or database estimate rather than the exact physical location of a device or user.

🗺️ Coordinates and Map

When latitude and longitude are available, the result can show a map link or map view.

Coordinates are useful for:

Important interpretation:

Coordinates should be used as context, not as proof of physical presence.

🏢 Network and Organization

The tool displays network ownership and provider details.

Possible fields include:

Field Description
ISP Internet Service Provider
Organization Organization associated with the IP
AS Autonomous System Number and organization
AS Name Autonomous System name
Network Combined provider and organization information

Example:

ISP: Cloudflare, Inc
Organization: APNIC and Cloudflare DNS Resolver project
AS: AS13335 Cloudflare, Inc.
AS Name: CLOUDFLARENET

This information is useful for identifying whether an address belongs to a hosting provider, corporate network, residential ISP, CDN, DNS resolver, mobile operator, cloud platform, or other infrastructure type.

🔢 ASN Information

The AS field identifies the Autonomous System associated with the IP.

An Autonomous System is a network or group of networks operated under a single routing policy.

Example:

AS13335 Cloudflare, Inc.

ASN information is useful for:

ASN ownership should not be confused with end-user identity. Many users, services, and customers can share infrastructure under the same ASN.

🔁 Reverse DNS

The Reverse DNS field shows the PTR hostname associated with the IP address when available.

Example:

one.one.one.one

Reverse DNS is useful for:

Reverse DNS is not always present, and when present, it may be outdated, generic, or controlled by the network operator.

🏷️ Flags and Attributes

IP / Domain Explorer can display infrastructure attributes.

Common flags include:

Flag Meaning
Mobile Network Indicates whether the IP appears to belong to a mobile network
Proxy Indicates whether the IP may be associated with proxy infrastructure
Hosting Indicates whether the IP appears to belong to hosting, cloud, CDN, or data center infrastructure

Example:

Mobile Network: false
Proxy: false
Hosting: true

These attributes help users quickly understand the type of infrastructure behind an IP.

Important: flags are based on available intelligence and heuristics. They should be used as indicators, not absolute proof.

🕒 Time Zone and UTC Offset

The tool returns timezone information based on the geolocation result.

Possible fields:

Example:

Time zone: Australia/Brisbane
Offset: UTC+10

Timezone information is useful for:

Because IP geolocation may be approximate, timezone data should also be treated as contextual.

💱 Currency

The result may include the local currency for the detected country.

Example:

Currency: AUD

Currency is useful for enrichment and regional context, especially in fraud analysis, compliance workflows, and user-location review.

🌐 HTTP Code and Source

The result can include request-level metadata such as HTTP code and data source.

Example:

HTTP Code: 200
Source: niamonx.io

The HTTP code indicates whether the lookup request succeeded at the service level.

The source field identifies the platform or internal lookup provider used for the result display.

🧠 Key Features

IP and Domain Lookup

Supports IPv4, IPv6, and domain names.

IDN Support

Internationalized domain names can be entered in Unicode when supported.

Geolocation

Returns continent, country, region, city, postal code, latitude, and longitude.

Coordinates can be used for map-based location review.

Network Ownership

Shows ISP, organization, ASN, and AS name.

Reverse DNS

Returns PTR hostname when available.

Infrastructure Flags

Displays proxy, hosting, and mobile network indicators.

Timezone and Currency

Adds regional context for investigations and analysis.

Local Request History

The interface includes request history for previous lookups.

Regularly Updated Data

Data is updated regularly through internal systems and public databases.

🧾 Results Table

The detailed results table provides field-by-field explanations.

Typical fields include:

Field Meaning
Continent Geographic continent
Continent code Short continent identifier
Country Country name
Country code ISO country code
Region code State or region abbreviation
Region name Full state or region
City City name
District District, if available
Postal code Postal code, if available
Latitude Approximate latitude
Longitude Approximate longitude
Time zone Timezone name
Offset UTC UTC offset
Currency Local currency
ISP Internet service provider
Organization Owning or related organization
AS Autonomous System
AS Name AS network name
Reverse DNS PTR hostname
Mobile Network Mobile network indicator
Proxy Proxy indicator
Hosting Hosting / cloud / data center indicator
Requested Original query
HTTP Code Lookup response code
Source Data source identifier

The table is useful for copying values into reports, incident notes, or enrichment workflows.

🔍 Common Use Cases

IP / Domain Explorer can support many legitimate workflows.

SOC Triage

Quickly enrich suspicious IPs from alerts, logs, SIEM events, or EDR telemetry.

Threat Intelligence

Identify ASN, organization, and hosting flags for IPs connected to suspicious infrastructure.

Fraud Analysis

Check whether a user IP appears to be a proxy, hosting provider, or mobile network.

Access Review

Compare login IP geolocation with expected user location.

Infrastructure Audit

Check how owned domains or IPs appear in public geolocation and network databases.

Abuse Reporting

Identify the responsible ISP or ASN before submitting abuse reports.

OSINT Investigation

Enrich IPs and domains during lawful public-source investigations.

Compliance and Risk Review

Document regional and infrastructure attributes of network indicators.

🧠 Result Interpretation

IP and domain intelligence should be interpreted carefully.

Important notes:

The tool is best used as an enrichment layer, not as a single source of truth.

A practical workflow should follow these steps.

1. Enter the IP or Domain

Use a clean IPv4 address, IPv6 address, or domain name.

2. Review Location

Check country, region, city, coordinates, timezone, and map.

3. Review Network Ownership

Check ISP, organization, ASN, and AS name.

4. Check Flags

Look for hosting, proxy, or mobile network indicators.

5. Review Reverse DNS

Use PTR data to understand service naming or provider context.

6. Compare With Logs

Correlate the lookup result with timestamps, user activity, SIEM events, or application logs.

7. Avoid Overclaiming

Do not treat geolocation as exact physical attribution.

8. Document Findings

Use the field table in reports or case notes when appropriate.

9. Repeat if DNS Changes

For domains, repeat the lookup if DNS records may have changed.

10. Validate Critical Conclusions

Use additional sources before making security, compliance, or legal decisions.

🛡️ Security, Privacy & Responsible Use

IP / Domain Explorer is intended for lawful network intelligence, cybersecurity, troubleshooting, and OSINT enrichment.

Acceptable use cases include:

Users should follow responsible use rules:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX IP / Domain Explorer is a fast IP and domain intelligence tool for checking geolocation, ASN, ISP, organization, reverse DNS, proxy status, hosting status, mobile network status, timezone, currency, and related network metadata.

It supports IPv4, IPv6, standard domains, and Unicode IDN domains. The tool is designed for SOC triage, OSINT enrichment, fraud analysis, infrastructure review, network troubleshooting, and compliance workflows. Results should be interpreted as contextual intelligence and validated with additional sources when used for important decisions.

Networks and WiFi

GlobeLine Ping | High-Level IP Availability & RTT Check

image.png

The platform available at https://dash.niamonx.io/gl_ping — known as GlobeLine Ping — is a high-level network availability and latency diagnostic tool within the NiamonX platform. It allows users to check whether an IPv4 or IPv6 address is reachable and measure connection quality through network echo requests.

Overview of the Service

GlobeLine Ping is designed to provide a fast and clear health check for an IP address. The tool sends several network echo requests to the selected IP and calculates key network quality metrics, including availability, packet loss, minimum latency, average latency, maximum latency, jitter, and individual RTT values.

The tool is useful for system administrators, SOC analysts, DevOps engineers, network engineers, infrastructure owners, cybersecurity teams, and technical users who need to quickly verify whether a host is online and how stable the connection is from the checking location.

GlobeLine Ping is a high-level diagnostic utility. It does not perform port scanning, service enumeration, exploitation, or deep packet inspection. It only checks reachability and latency characteristics for the submitted IP address.

🔍 How the Tool Works

When a user enters an IPv4 or IPv6 address, GlobeLine Ping sends several network echo requests from the NiamonX checking infrastructure.

The tool then calculates and displays:

Example result summary:

ONLINE
1.59 ms
Packets: 3/3
Losses: 0%
MIN RTT: 1.291 ms
AVG RTT: 1.588 ms
MAX RTT: 1.795 ms
JITTER: 0.264 ms
Source Location: Santa Clara, US

This gives the user a quick understanding of whether the IP is reachable and whether the connection appears stable.

🧩 What Can Be Checked

GlobeLine Ping supports direct IP address checks.

Supported input types:

Examples:

1.1.1.1

8.8.8.8

2606:4700:4700::1111

Unsupported input types:

example.com

https://example.com

1.1.1.1:443

example.com/path

The tool expects only a clean IPv4 or IPv6 address. Domains and URLs are not accepted in this module.

⚙️ Search Interface

The interface contains a simple IP input field.

IP Address

The user enters the target IP address.

Example:

1.1.1.1

The interface states that IPv4 and IPv6 are supported and that the user should enter only the IP address, without domains or URLs.

After the check is completed, GlobeLine Ping displays the result status, summary metrics, packet statistics, RTT table, and source location.

📊 Result Overview

The main result panel gives a fast status summary.

Possible status values:

Status Meaning
ONLINE The IP responded to the network echo requests
OFFLINE The IP did not respond or could not be reached
UNKNOWN The result could not be confidently determined

Example:

ONLINE
1.59 ms

The large latency value shown next to the status usually represents the average RTT or primary response time.

📦 Packet Statistics

The tool displays packet delivery statistics.

Example:

Packages received/sent: 3/3
Losses: 0%

Received / Sent

Shows how many echo responses were received compared to how many requests were sent.

Example:

3/3

This means all three requests received responses.

Packet Loss

Packet loss shows the percentage of requests that did not receive a response.

Example:

0%

Packet loss is one of the most important indicators of connection reliability.

⏱️ RTT Metrics

RTT means Round-Trip Time. It measures how long it takes for a request to reach the target and for the response to return.

GlobeLine Ping calculates several RTT values.

Minimum RTT

The fastest response time observed during the check.

Example:

MIN RTT: 1.291 ms

Average RTT

The average response time across all received packets.

Example:

AVG RTT: 1.588 ms

Maximum RTT

The slowest response time observed during the check.

Example:

MAX RTT: 1.795 ms

Together, these values help users understand the connection’s speed and stability.

📉 Jitter

Jitter measures variation between response times.

Example:

JITTER: 0.264 ms

Low jitter means responses are consistent.

High jitter means latency is unstable, which may indicate:

Jitter is especially important for real-time services such as VoIP, video calls, gaming, remote desktops, and streaming.

🌍 Source Location

The result may include the source location of the check.

Example:

Source Location: Santa Clara, US

This tells the user where the ping check was performed from.

Source location matters because latency depends strongly on distance and routing. A target may respond quickly from one region and slowly from another.

For example:

📊 Individual RTT Table

GlobeLine Ping displays individual packet measurements.

Example table:

# RTT ms Δ from AVG Category
1 1.795 +0.207 MID
2 1.291 -0.298 OK
3 1.679 +0.091 OK

RTT

The measured round-trip time for each individual request.

Δ from AVG

Shows how far the individual RTT differs from the average RTT.

Positive values mean the packet was slower than average.

Negative values mean the packet was faster than average.

Category

A simple quality label for the individual response.

Possible labels may include:

The exact label depends on the tool’s internal classification logic.

📶 Packet Loss Bar

The packet loss bar visualizes the percentage of lost packets.

Example:

Packet Loss: 0%

Interpretation:

Packet Loss Meaning
0% Excellent packet delivery
1–2% Minor loss, usually acceptable but worth watching
3–5% Noticeable instability
5–10% Significant network quality issue
10%+ Serious connectivity problem

Even small packet loss can affect real-time applications.

🧠 Latency Interpretation

RTT values depend on distance, routing, network congestion, and target infrastructure.

General interpretation:

Average RTT Interpretation
0–20 ms Very low latency
20–60 ms Good latency
60–120 ms Moderate latency
120–250 ms High but often normal for long-distance routing
250–300+ ms Very high latency, often intercontinental or problematic
Timeout / no response Host may be offline, filtered, or blocking echo requests

RTT values above 250–300 ms often indicate intercontinental routing, unstable paths, overloaded networks, or problematic channels.

Important: a high RTT does not always mean the target is broken. It may simply be far away or routed through a distant network path.

🧠 Key Features

IP Availability Check

The tool determines whether an IP address appears reachable.

IPv4 and IPv6 Support

Both modern IPv4 and IPv6 targets are supported.

High-Level Ping

The tool performs several echo requests and calculates summary statistics.

RTT Measurement

Minimum, average, and maximum round-trip time are displayed.

Packet Loss Calculation

The tool shows packet delivery success and loss percentage.

Jitter Calculation

Latency variation is calculated to help evaluate connection stability.

Individual Packet Details

Each request is listed with RTT, difference from average, and quality category.

Source Location

The origin location of the check is shown when available.

Local Request History

Search history is stored locally in the browser through LocalStorage.

Lightweight Diagnostic Design

The tool is simple, fast, and focused on availability and latency rather than deep service analysis.

🕓 Request History

GlobeLine Ping stores request history locally in the user’s browser.

Important behavior:

The history is stored locally in your browser and is not sent to the server.

History may include:

Because history is local, it may be cleared if the user clears browser data, switches devices, or uses another browser profile.

On shared devices, users should clear browser history or LocalStorage when ping targets are sensitive.

A practical troubleshooting workflow should follow these steps.

1. Enter the IP Address

Use only IPv4 or IPv6. Do not enter a domain, URL, port, or path.

2. Check Availability

Look at the main status: ONLINE or OFFLINE.

3. Review Packet Loss

If packet loss is above 0%, repeat the test and compare results.

4. Review RTT Values

Check minimum, average, and maximum RTT.

5. Review Jitter

High jitter may indicate unstable routing or network congestion.

6. Check Individual Packets

Look for spikes, inconsistent values, or lost responses.

7. Consider Source Location

Compare the source region with the target’s expected location.

8. Repeat From Other Tools if Needed

If the result is critical, verify from another network or monitoring system.

9. Correlate With Other Signals

Use logs, traceroute, service checks, uptime monitoring, firewall rules, and provider status pages to confirm the issue.

10. Document the Result

Use the metrics in incident notes or troubleshooting reports.

🔎 Common Use Cases

GlobeLine Ping can support many technical workflows.

Server Availability Check

Quickly confirm whether a server IP responds.

Network Troubleshooting

Check whether latency or packet loss is affecting connectivity.

Incident Response

Verify if an IP is reachable during outage investigation.

Route Quality Review

Use RTT and jitter as a first indicator of network path quality.

Infrastructure Monitoring

Perform quick spot checks on public infrastructure.

CDN and Anycast Testing

Compare response behavior from the tool’s source location.

Firewall Validation

Determine whether ICMP-style echo requests are allowed or blocked.

ISP or Hosting Issue Review

Use packet loss and RTT data as basic evidence for support tickets.

⚠️ Result Interpretation Notes

Ping results should be interpreted carefully.

Important limitations:

For critical systems, use additional checks such as TCP connection tests, HTTP status checks, traceroute, DNS checks, and continuous monitoring.

🛡️ Security, Privacy & Responsible Use

GlobeLine Ping is intended for lawful network diagnostics and infrastructure monitoring.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX GlobeLine Ping is a high-level IP availability and latency diagnostic tool for IPv4 and IPv6 addresses. It sends several network echo requests, determines whether the target is online, and calculates packet loss, minimum RTT, average RTT, maximum RTT, jitter, individual response times, and source location.

The tool is designed for lawful network diagnostics, infrastructure monitoring, DevOps workflows, SOC triage, and incident response. Results should be interpreted as quick network health indicators and confirmed with additional diagnostics when used for critical decisions.

Networks and WiFi

GeoPing | Multi-Location IP Availability & Latency Check

image.png

The platform available at https://dash.niamonx.io/geoping — known as GeoPing — is a multi-location network diagnostic tool within the NiamonX platform. It allows users to check IPv4 and IPv6 availability from several geographic locations at the same time and compare latency, packet loss, jitter, and route quality by region.

Overview of the Service

GeoPing is designed to help users understand how reachable and responsive an IP address is from different parts of the world.

Unlike a single-location ping test, GeoPing performs parallel checks from multiple geographic nodes and aggregates the results into a structured report. This makes it useful for identifying regional connectivity differences, routing problems, CDN behavior, network instability, and global availability issues.

The tool is intended for network engineers, DevOps teams, SOC analysts, system administrators, infrastructure owners, hosting providers, cybersecurity teams, and technical users who need to evaluate IP-level connectivity from several locations.

GeoPing supports:

The tool accepts only IP addresses. Domains, URLs, ports, and paths are not supported in this module.

🔍 How the Tool Works

When a user enters an IPv4 or IPv6 address, GeoPing launches parallel availability checks from several geographic locations.

Each location sends multiple network echo requests to the target IP. The tool then calculates per-location metrics and global aggregated statistics.

The result includes:

Example summary:

Total: 5
ONLINE: 5
OFFLINE: 0
Host: 1.1.1.1
Locations: 5
AVG: 1.716 ms
Median AVG: 1.580 ms
Global MIN: 0.982 ms
Global MAX: 3.134 ms
Average Loss: 0.00%
Best: Singapore, SG
Worst: London, GB

This allows users to quickly understand whether the IP is globally reachable and whether any region has unusual latency or packet loss.

🧩 What Can Be Checked

GeoPing supports direct IP address checks.

Supported input types:

Valid examples:

1.1.1.1

8.8.8.8

2606:4700:4700::1111

Unsupported input examples:

example.com

https://example.com

1.1.1.1:443

example.com/path

GeoPing expects only a clean IPv4 or IPv6 address.

⚙️ Check Interface

The GeoPing interface contains a simple input field and result sections.

IP Address

The user enters the target IP address.

Example:

1.1.1.1

The interface indicates that IPv4 and IPv6 are supported and that only an IP address should be entered.

After the request is processed, the tool displays:

📊 Summary Section

The Summary section provides a global view of the test.

Typical fields include:

Field Description
Total Total number of locations used for the test
ONLINE Number of locations where the IP responded
OFFLINE Number of locations where the IP did not respond
Host Checked IP address
Locations Number of geographic test sources
AVG Average latency across test locations
Median AVG Median of per-location average RTT values
Global MIN Lowest RTT measured across all packets and locations
Global MAX Highest RTT measured across all packets and locations
Average Loss Average packet loss across all locations
Best Location with the lowest average RTT
Worst Location with the highest average RTT

Example:

ONLINE: 5
OFFLINE: 0
AVG: 1.716 ms
Average Loss: 0.00%
Best: Singapore, SG
Worst: London, GB

This block helps users quickly identify whether the target is reachable globally and which regions have the best or worst connectivity.

🌍 Multi-Location Testing

GeoPing runs checks from multiple geographic locations.

Example locations may include:

Each location has its own result card showing availability and latency metrics.

This is useful because network performance can vary significantly by region.

For example:

✅ Availability Status

Each location returns an availability status.

Common statuses:

Status Meaning
ONLINE The IP responded from that location
OFFLINE No response was received from that location
UNKNOWN The result could not be confidently determined

Example:

ONLINE
1.83 ms
Location: Clifton, US

If the IP is online from some regions and offline from others, this may indicate routing filters, regional firewall rules, DDoS protection behavior, provider issues, or temporary network problems.

⏱️ RTT Metrics

RTT means Round-Trip Time. It measures how long a packet takes to travel from the test location to the target IP and back.

Each location card may include:

Example:

Location: Frankfurt am Main, DE
MIN: 0.982 ms
AVG: 1.580 ms
MAX: 2.166 ms
JITTER: 0.592 ms
Packets: 3/3
Losses: 0%

Minimum RTT

The fastest response observed from that location.

Average RTT

The average response time from that location.

Maximum RTT

The slowest response observed from that location.

RTT List

The individual response times for each packet.

Example:

RTT list: 1.250, 1.188, 1.250

📉 Jitter

Jitter measures the variation between individual RTT values.

Low jitter means the connection is stable.

High jitter may indicate:

Example:

JITTER: 0.036 ms

A low jitter value is especially important for real-time applications such as VoIP, video calls, gaming, streaming, remote desktops, and interactive services.

📦 Packet Loss

Packet loss shows how many requests failed compared to how many were sent.

Example:

Packages received/sent: 3/3
Losses: 0%

Packet loss interpretation:

Packet Loss Meaning
0% Excellent delivery
1–2% Minor loss, usually acceptable but should be monitored
3–5% Noticeable instability
5–10% Significant network problem
10%+ Severe connectivity issue

Packet loss from one region but not others may indicate a regional routing problem or filtering issue.

🏆 Best and Worst Locations

GeoPing automatically identifies the best and worst locations by average RTT.

Example:

The Best: Singapore, SG (1.229 ms)
The Worst: London, GB (2.515 ms)

Best Location

The location with the lowest average RTT.

This usually indicates the shortest or most efficient route from the test source to the target.

Worst Location

The location with the highest average RTT.

This may indicate longer routing distance, less efficient routing, congestion, filtering, or provider-level latency.

The best and worst labels are comparative within the current test, not absolute judgments of the target infrastructure.

📊 Aggregated Metrics

GeoPing includes global aggregated metrics across all locations.

Global Average

Shows the overall average latency across test sources.

Median Average

Shows the median of per-location average RTT values.

Median is useful because it is less affected by one unusually slow or fast location.

Global Minimum

Shows the fastest observed response from all locations.

Global Maximum

Shows the slowest observed response from all locations.

Average Loss

Shows the average packet loss across all test locations.

These metrics help users understand global route quality at a glance.

🧠 Latency Interpretation

Latency depends on geography, routing, peering, infrastructure, congestion, and target configuration.

General RTT interpretation:

Average RTT Interpretation
0–20 ms Very low latency
20–60 ms Good latency
60–120 ms Moderate latency
120–250 ms High latency
250–300+ ms Very high latency, often intercontinental or problematic
Timeout No response, filtering, or target unavailable

Important: low latency from multiple regions may indicate anycast routing, CDN edge infrastructure, or globally distributed network design.

High latency from one region may not mean the target is down. It may simply reflect distance, routing path, or provider differences.

🛰️ Anycast and CDN Interpretation

GeoPing is especially useful for checking anycast and CDN-style infrastructure.

For anycast services, the same IP address can be routed to different physical or logical locations depending on where the request originates.

This can explain why an IP may show very low latency from multiple regions at the same time.

Possible interpretations:

GeoPing does not prove the exact physical destination server. It shows observed connectivity from each test source.

🕓 Request History

GeoPing stores entered IP addresses in the user’s browser through LocalStorage.

Important behavior:

The history of entered IP addresses is stored in your browser.

History may include:

The history is local to the browser and may be cleared when the user deletes browser data, switches devices, or uses another browser profile.

On shared devices, users should clear local history when checked IPs are sensitive.

🧠 Key Features

Multi-Location Ping

Checks the same IP address from multiple geographic test sources.

IPv4 and IPv6 Support

Supports both IPv4 and IPv6 targets.

Parallel Availability Checks

Runs availability checks across several regions.

Per-Location Results

Each location shows status, RTT metrics, jitter, packets, loss, and RTT list.

Aggregated Summary

Shows global metrics such as average RTT, median, global min, global max, and average loss.

Best / Worst Location Detection

Automatically identifies the fastest and slowest test locations by average RTT.

Packet Loss Analysis

Displays packet loss per location and average loss globally.

Jitter Measurement

Shows latency stability for each geographic source.

Local History

Stores entered IPs locally in the browser.

Regional Route Insight

Helps compare network performance by geography.

A practical GeoPing workflow should follow these steps.

1. Enter the IP Address

Use only IPv4 or IPv6. Do not enter domains, URLs, ports, or paths.

2. Review Global Summary

Check total locations, online count, offline count, average RTT, median RTT, and average packet loss.

3. Identify Best and Worst Locations

Compare the fastest and slowest regions.

4. Review Per-Location Cards

Check each location’s minimum, average, maximum RTT, jitter, and packet loss.

5. Look for Regional Problems

Identify locations with high RTT, high jitter, packet loss, or offline status.

6. Compare With Expected Geography

Consider whether the target is expected to be close to the fastest region.

7. Repeat if Needed

Run another check if the issue appears temporary or inconsistent.

8. Correlate With Other Tools

Use traceroute, HTTP checks, DNS checks, CDN monitoring, firewall logs, and provider status pages for deeper analysis.

9. Document Findings

Use the summary and per-location metrics in troubleshooting reports or incident notes.

10. Validate Critical Issues

Confirm important outages or routing problems with additional monitoring sources.

🔎 Common Use Cases

GeoPing can support many technical workflows.

Global Availability Check

Confirm whether an IP is reachable from multiple regions.

CDN and Anycast Testing

Check how an anycast IP behaves from different geographic sources.

Regional Routing Diagnostics

Identify whether latency or packet loss affects specific regions.

Incident Response

Quickly determine whether an outage is global or region-specific.

Hosting Provider Comparison

Compare responsiveness of infrastructure from different test locations.

Network Performance Review

Evaluate latency consistency and jitter across regions.

Firewall and Filtering Validation

Check whether an IP responds from some countries but not others.

SLA and Monitoring Support

Use multi-location metrics as supporting evidence for service-quality review.

⚠️ Result Interpretation Notes

GeoPing results should be interpreted carefully.

Important limitations:

For critical production systems, GeoPing should be combined with continuous monitoring and application-level checks.

🛡️ Security, Privacy & Responsible Use

GeoPing is intended for lawful network diagnostics and infrastructure monitoring.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX GeoPing is a multi-location IP availability and latency diagnostic tool for IPv4 and IPv6 addresses. It performs parallel checks from several geographic locations and returns global availability, per-location RTT metrics, packet loss, jitter, individual response times, best and worst locations, median latency, and aggregated performance indicators.

The tool is designed for global availability checks, CDN and anycast validation, routing diagnostics, incident response, DevOps workflows, SOC triage, and infrastructure monitoring. Results should be treated as a regional network-performance snapshot and validated with additional diagnostics for critical decisions.

Networks and WiFi

GlobeLine DNS | DNS Query & Record Intelligence

image.png

The platform available at https://dash.niamonx.io/gl_dns — known as GlobeLine DNS — is a DNS intelligence and domain record lookup tool within the NiamonX platform. It allows users to perform DNS queries for a domain name and aggregate the returned records by type, including A, AAAA, MX, NS, TXT, and other records when available in the raw response.

Overview of the Service

GlobeLine DNS is designed to help users quickly inspect DNS configuration for a domain or subdomain.

The tool performs DNS queries through the NiamonX resolver infrastructure and presents the results in a clean, structured format. It shows which record types were requested, which record types were resolved, how many records were found, request timing, resolver information, and individual DNS records grouped by type.

GlobeLine DNS is useful for:

The tool accepts domain names only. Users should enter a clean domain or subdomain without protocol, slashes, paths, or URL parameters.

🔍 How the Tool Works

When a user enters a domain name, GlobeLine DNS performs DNS queries for the selected record types.

Supported record types include:

If no record type is selected, the tool automatically uses type A.

After the request is completed, the interface displays:

Example result summary:

SUCCESS
Records: 11
Domain: niamonx.io
Request Time: 328.03 ms
Requested: A, AAAA, MX, NS, TXT
Resolved: A, AAAA, MX, NS, TXT

🧩 What Can Be Checked

GlobeLine DNS supports domain and subdomain checks.

Valid examples:

example.com

sub.example.com

niamonx.io

Unsupported input examples:

https://example.com

example.com/path

https://example.com/login?x=1

1.1.1.1

The tool is intended for domain names only. IP lookup, ping, geolocation, and service discovery are handled by separate NiamonX modules.

⚙️ Query Interface

The GlobeLine DNS interface includes a domain input field and record type selection controls.

Domain Name

The user enters a domain or subdomain.

Example:

niamonx.io

The interface indicates:

Domain only — without protocol and slashes.

Types of Records

Users can select one or more DNS record types.

Available primary types:

Quick controls may include:

If nothing is selected, type A is used automatically.

📌 Supported Record Types

A Record

An A record maps a domain name to an IPv4 address.

Example:

A 172.67.153.184

A records are commonly used to route a domain to a web server, CDN edge, proxy, or hosting infrastructure.

AAAA Record

An AAAA record maps a domain name to an IPv6 address.

Example:

AAAA 2606:4700:3033::6815:ce7

AAAA records are used for IPv6-enabled services.

MX Record

An MX record identifies mail servers responsible for receiving email for the domain.

Example:

MX mx.zoho.eu.

MX records are important for checking whether email delivery is configured correctly.

NS Record

An NS record identifies authoritative name servers for the domain.

Example:

NS abdullah.ns.cloudflare.com.

NS records show which DNS provider or authoritative DNS infrastructure controls the domain zone.

TXT Record

A TXT record stores text-based DNS values.

Common uses include:

Example:

TXT v=spf1 include:zohomail.eu -all

TXT records are especially important for mail security and domain verification.

📊 Results Summary

After a successful query, the tool displays a summary block.

Typical fields include:

Field Description
Status Query result status
Records Total number of returned records
Domain Queried domain
Request Time Total DNS query duration
Resolver Resolver or source used for the request
Requested DNS record types requested by the user
Resolved DNS record types successfully returned
Type counters Number of records per type
TTL average Average TTL per record type when available

Example:

SUCCESS
Records: 11
Request Time: 328.03 ms
Resolver: niamonx.io
Requested: A, AAAA, MX, NS, TXT
Resolved: A, AAAA, MX, NS, TXT

This helps users quickly understand whether DNS resolution succeeded and which record types were returned.

📋 Results Table

DNS records are displayed in a structured table.

Typical columns include:

Column Description
Type DNS record type
Meaning / Parameters Returned DNS value
TTL Time To Live value when available

Example table rows:

A     172.67.153.184
AAAA  2606:4700:3033::6815:ce7
MX    mx.zoho.eu.
NS    abdullah.ns.cloudflare.com.
TXT   v=spf1 include:zohomail.eu -all

When available, the tool may also show resolver-side or source-location context for records.

Example:

loc: Santa Clara, US

⏱️ TTL Interpretation

TTL means Time To Live. It tells DNS resolvers how long they may cache a record before checking again.

A low TTL may indicate:

A high TTL may indicate:

If TTL is unavailable, the interface may show:

-

TTL availability depends on the DNS response and backend resolver behavior.

📬 Mail Configuration Review

MX and TXT records are especially important for email security and delivery.

GlobeLine DNS can help review:

Example SPF record:

v=spf1 include:zohomail.eu -all

An SPF record defines which mail servers are authorized to send email for the domain.

Security teams can use TXT records to check whether the domain has proper anti-spoofing configuration.

🛡️ Security-Relevant DNS Checks

GlobeLine DNS can support several defensive security checks.

SPF Review

Check TXT records for SPF configuration.

Look for records starting with:

v=spf1

DKIM Review

Check for DKIM selector records when querying specific DKIM subdomains.

Example format:

selector._domainkey.example.com

DMARC Review

Check the DMARC policy by querying:

_dmarc.example.com

Name Server Review

Check NS records to confirm which provider controls authoritative DNS.

Address Review

Check A and AAAA records to confirm where the domain resolves.

Mail Provider Review

Check MX records to identify the active mail provider.

🌍 Resolver and Location Context

The results may include resolver or location context.

Example:

Resolver: niamonx.io
loc: Santa Clara, US

This helps users understand where the DNS request was resolved from or what infrastructure was used for the lookup.

DNS responses can vary by location due to:

For global infrastructure, results from one resolver location should be treated as one perspective.

🕓 Request History

GlobeLine DNS stores domain queries and selected record types in the browser.

The history may include:

Important behavior:

The history of domains and the selection of types is stored in the browser.

Local history helps users repeat common DNS checks quickly.

On shared or public devices, users should clear browser data when domain lookup history is sensitive.

🧠 Key Features

DNS Query Tool

Performs DNS queries for selected record types.

Domain and Subdomain Support

Accepts clean domain names and subdomains.

Multiple Record Types

Supports A, AAAA, MX, NS, and TXT.

Automatic A Fallback

If no type is selected, A is used automatically.

Aggregated Results

Groups returned data by DNS record type.

Requested vs Resolved Types

Shows which types were requested and which types returned results.

Request Timing

Displays DNS request duration.

TTL Display

Shows TTL values when available.

Resolver Context

Displays resolver/source information.

Local History

Stores domains and record type selections in the browser.

Security Review Support

Useful for SPF, MX, NS, and TXT-based security checks.

A practical DNS review workflow should follow these steps.

1. Enter a Clean Domain

Use only the domain or subdomain without protocol, slashes, or paths.

2. Select Record Types

Choose A, AAAA, MX, NS, TXT, or use All for a broader check.

3. Review Query Status

Confirm that the result status is SUCCESS.

4. Check Requested and Resolved Types

Verify whether the requested record types returned data.

5. Review Address Records

Check A and AAAA records for web or infrastructure routing.

6. Review Mail Records

Check MX records for mail server configuration.

7. Review TXT Records

Look for SPF, DKIM, DMARC, verification, and other security records.

8. Review Name Servers

Check NS records to identify authoritative DNS providers.

9. Consider Resolver Perspective

Remember that DNS responses can vary by geography, resolver, and cache state.

10. Document Findings

Use returned records in reports, migration notes, incident response, or security reviews.

🔎 Common Use Cases

GlobeLine DNS can support many technical workflows.

Domain Troubleshooting

Check whether a domain resolves correctly.

Mail Delivery Debugging

Review MX and SPF-related TXT records.

DNS Migration Validation

Confirm that records have changed after a provider or hosting migration.

Security Audit

Check SPF, DKIM, DMARC, NS, and exposed address records.

OSINT Enrichment

Collect DNS infrastructure indicators for a domain.

Incident Response

Review DNS changes, suspicious TXT records, or unexpected IP addresses.

Infrastructure Documentation

Create a quick snapshot of domain DNS configuration.

CDN and Hosting Review

Identify whether a domain points to CDN, cloud, or hosting infrastructure.

⚠️ Result Interpretation Notes

DNS results should be interpreted carefully.

Important points:

For critical DNS changes, compare results with authoritative DNS tools and multiple resolvers.

🛡️ Security, Privacy & Responsible Use

GlobeLine DNS is intended for lawful DNS troubleshooting, security analysis, domain administration, OSINT enrichment, and infrastructure review.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX GlobeLine DNS is a DNS query and domain record intelligence tool for checking A, AAAA, MX, NS, and TXT records.

It accepts clean domain or subdomain input, performs selected DNS queries, aggregates results by type, shows requested and resolved record groups, displays request time, resolver context, record counts, TTL values when available, and stores query history locally in the browser.

The tool is designed for DNS troubleshooting, mail configuration review, SPF and TXT analysis, infrastructure documentation, SOC triage, OSINT enrichment, and domain security workflows.

Networks and WiFi

GeoDNS | Geographic DNS Response Intelligence

image.png

The platform available at https://dash.niamonx.io/geodns — known as GeoDNS — is a multi-location DNS intelligence tool within the NiamonX platform. It allows users to query DNS records for a domain from several geographic locations and compare how responses differ across regions.

Overview of the Service

GeoDNS is designed to help users understand how a domain resolves from different parts of the world.

Unlike a standard DNS lookup, which checks records from a single resolver or location, GeoDNS performs DNS queries from multiple geographic test points. This makes it possible to detect regional DNS differences, CDN routing behavior, GeoDNS configuration, DNS propagation issues, resolver inconsistencies, and location-based infrastructure allocation.

The tool supports common DNS record types, including:

GeoDNS is useful for system administrators, DevOps teams, SOC analysts, cybersecurity researchers, infrastructure owners, domain administrators, compliance teams, and OSINT analysts who need to verify DNS behavior across multiple regions.

🔍 How the Tool Works

When a user enters a domain name and selects DNS record types, GeoDNS sends DNS queries from multiple geographic locations.

Each location performs the selected DNS requests and returns the records visible from that region. The tool then aggregates all responses and displays:

If no record type is selected, the tool automatically uses A records.

Example flow:

  1. User enters a domain.

  2. User selects one or more DNS record types.

  3. GeoDNS queries the domain from several locations.

  4. Responses are grouped by geographic source.

  5. Unique DNS values are counted by type.

  6. The final report shows global and regional DNS behavior.

🧩 What Can Be Checked

GeoDNS accepts clean domain and subdomain names only.

Valid examples:

example.com

sub.example.com

niamonx.io

Invalid examples:

https://example.com

example.com/path

https://example.com/login

1.1.1.1

The tool is intended for DNS checks of domains and subdomains. It should not be used with URLs, protocols, paths, query strings, IP addresses, or ports.

⚙️ Query Interface

The GeoDNS interface contains a domain input field and DNS record type controls.

Domain Name

The user enters a clean domain or subdomain.

Example:

niamonx.io

The interface expects the domain only, without:

Types of Requests

Users can select one or more DNS record types.

Supported types:

Quick controls may include:

If nothing is selected, the system automatically uses type A.

📌 Supported DNS Record Types

A Records

An A record maps a domain to an IPv4 address.

Example:

A 172.67.153.184

A records are commonly used for websites, APIs, CDNs, proxies, and IPv4 infrastructure.

AAAA Records

An AAAA record maps a domain to an IPv6 address.

Example:

AAAA 2606:4700:3033::6815:ce7

AAAA records are used for IPv6-enabled services.

MX Records

An MX record identifies mail servers responsible for receiving email for the domain.

Example:

MX mx.zoho.eu.

MX records are important for mail routing, email delivery, and mail-provider verification.

NS Records

An NS record identifies authoritative name servers for the domain.

Example:

NS abdullah.ns.cloudflare.com.

NS records show which DNS provider or authoritative DNS infrastructure controls the zone.

TXT Records

A TXT record stores text-based DNS data.

Common TXT record uses include:

Example:

TXT v=spf1 include:zohomail.eu -all

TXT records are often important for domain security and compliance checks.

📊 Summary Section

After a successful query, GeoDNS displays a global summary.

Typical fields include:

Field Description
Status Overall query result status
Locations Number of geographic locations used
Responses Total number of returned DNS answers
Domain Queried domain
Time Total request duration
Requested Record types requested by the user
Resolved Record types successfully returned
Unique A Number of unique IPv4 answers
Unique AAAA Number of unique IPv6 answers
Unique MX Number of unique mail server answers
Unique NS Number of unique name server answers
Unique TXT Number of unique TXT answers

Example summary:

SUCCESS
Locations: 5
Responses: 55
Domain: niamonx.io
Time: 2297.86 ms
Requested: A, AAAA, MX, NS, TXT
Resolved: A, AAAA, MX, NS, TXT
Unique A: 2
Unique AAAA: 2
Unique MX: 3
Unique NS: 2
Unique TXT: 2

This summary helps users quickly understand whether DNS records are consistent globally and how many unique values were observed.

🌍 Per-Location Results

GeoDNS displays DNS answers separately for each test location.

Each location block may include:

Example location block:

#1
Location: Clifton, US
Coordinates: 40.8584, -74.1638
Answers:
A 172.67.153.184
A 104.21.12.231
AAAA 2606:4700:3030::ac43:99b8
MX mx.zoho.eu.
NS abdullah.ns.cloudflare.com.
TXT v=spf1 include:zohomail.eu -all

Per-location results are the core value of GeoDNS. They allow analysts to compare regional DNS behavior instead of relying on a single resolver response.

🗺️ Geographic Test Locations

GeoDNS uses multiple geographic sources for DNS resolution.

Example locations may include:

Each location can return the same or different DNS answers depending on the domain’s DNS configuration, CDN provider, resolver behavior, cache state, or regional routing policy.

Geographic DNS results are especially useful for domains using:

🔁 Requested vs Resolved Types

GeoDNS clearly shows which record types were requested and which were actually resolved.

Example:

Requested: A, AAAA, MX, NS, TXT
Resolved: A, AAAA, MX, NS, TXT

If some requested types do not return answers, the status may be partial.

Example:

Requested: A, AAAA, MX, NS, TXT
Resolved: A, NS, TXT
Status: partial

This helps analysts quickly identify missing or unavailable DNS records.

⚠️ Partial Status

If some selected record types do not match or do not return from all locations, the query may be marked as partial.

A partial result may indicate:

A partial status is not always an error. It means the user should review the per-location answers and resolved types carefully.

🧮 Unique Values by Type

GeoDNS calculates unique DNS answers by record type.

Example:

Unique A: 2
Unique AAAA: 2
Unique MX: 3
Unique NS: 2
Unique TXT: 2

This is useful for identifying whether all locations returned the same values or whether responses vary geographically.

Low Unique Count

A low unique count usually means the DNS response is consistent globally.

High Unique Count

A high unique count may indicate:

🌐 GeoDNS and CDN Behavior

Many modern domains use CDNs or geographically distributed DNS infrastructure. GeoDNS helps detect this behavior.

Possible patterns:

Same Records Everywhere

If all locations return the same A and AAAA values, the domain likely has globally consistent DNS responses.

Different A / AAAA Records by Region

If locations return different IPs, the domain may use GeoDNS, CDN edge routing, regional load balancing, or DNS steering.

Same MX / NS Everywhere

Mail and authoritative DNS records are often globally consistent.

TXT Differences

TXT records are usually consistent, but differences may indicate propagation delay, configuration drift, or resolver cache differences.

📬 Mail and Security Record Review

GeoDNS can be used to check whether mail and security-related DNS records are globally visible.

Important record types:

Common TXT checks:

Example SPF record:

v=spf1 include:zohomail.eu -all

To check DMARC, users should query:

_dmarc.example.com

To check DKIM, users should query the specific selector subdomain, such as:

selector._domainkey.example.com

📦 Raw JSON

The tool can show Raw JSON with additional technical details.

Raw JSON may include:

Raw JSON is useful for:

Raw output should be handled carefully when it contains internal investigation details.

🕓 Request History

GeoDNS stores domain query history and selected record types locally in the browser.

The history may include:

Local history helps users repeat previous checks quickly.

Because it is browser-local, it may be cleared when browser data is deleted or when another browser profile is used.

On shared devices, users should clear local history if domain checks are sensitive.

🧠 Key Features

Multi-Location DNS Queries

Runs DNS checks from several geographic locations.

Domain and Subdomain Support

Accepts clean domain and subdomain names.

Common DNS Record Types

Supports A, AAAA, MX, NS, and TXT.

Automatic A Fallback

If no type is selected, A is used automatically.

Regional Response Comparison

Displays DNS answers separately by location.

Unique Value Aggregation

Counts unique DNS responses per record type.

Requested and Resolved Summary

Shows what was requested and what was returned.

Partial Status Detection

Highlights cases where not all requested types were resolved.

Raw JSON View

Allows technical review of additional response details.

Local History

Stores query history and selected types locally in the browser.

A practical GeoDNS workflow should follow these steps.

1. Enter a Clean Domain

Use only a domain or subdomain. Do not include protocol, path, or URL parameters.

2. Select Record Types

Choose A, AAAA, MX, NS, TXT, or use All for a broad overview.

3. Review the Summary

Check status, locations, responses, requested types, resolved types, and unique counts.

4. Compare Locations

Look for differences between Clifton, London, Amsterdam, Frankfurt, Singapore, or other returned locations.

5. Review Unique Values

Check whether unique A / AAAA values differ across regions.

6. Validate Mail Records

Review MX and TXT records for mail and verification consistency.

7. Investigate Partial Results

If status is partial, check which locations or record types did not return expected results.

8. Use Raw JSON When Needed

Open Raw JSON for deeper diagnostics.

9. Repeat After DNS Changes

Run another check after DNS updates, migrations, or propagation windows.

10. Confirm Critical Issues

Use authoritative DNS tools and multiple resolvers before making production decisions.

🔎 Common Use Cases

GeoDNS supports many technical workflows.

DNS Propagation Check

Verify whether DNS updates are visible from multiple locations.

CDN Validation

Check whether a CDN returns different IPs by region.

GeoDNS Testing

Confirm location-based DNS allocation.

Mail Configuration Review

Check MX and TXT record consistency globally.

Domain Migration Validation

Verify that records changed correctly after moving DNS providers or hosting.

Incident Response

Investigate DNS hijacking, unexpected records, or inconsistent resolver behavior.

SOC and OSINT Enrichment

Collect regional DNS evidence for suspicious domains.

Infrastructure Monitoring

Track whether critical DNS records remain stable across locations.

⚠️ Result Interpretation Notes

GeoDNS results should be interpreted carefully.

Important points:

For production DNS decisions, compare GeoDNS results with authoritative DNS checks and monitoring tools.

🛡️ Security, Privacy & Responsible Use

GeoDNS is intended for lawful DNS troubleshooting, infrastructure analysis, security review, OSINT enrichment, and domain administration.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX GeoDNS is a multi-location DNS intelligence tool that checks DNS records from several geographic locations and shows how domain responses are distributed globally.

It supports A, AAAA, MX, NS, and TXT queries, displays requested and resolved record types, counts unique values by type, groups answers by location, provides Raw JSON for deeper analysis, and stores query history locally in the browser.

The tool is designed for DNS propagation checks, GeoDNS validation, CDN behavior analysis, mail configuration review, SOC triage, OSINT enrichment, domain migration validation, and infrastructure monitoring.

Networks and WiFi

DNS Resolver / Reverse | Forward and Reverse DNS Resolution

image.png

The platform available at https://dash.niamonx.io/dns_rrsv — known as DNS Resolver / Reverse — is a DNS resolution utility within the NiamonX platform. It allows users to perform forward DNS resolution from a domain name to IP address and reverse DNS resolution from an IP address to PTR hostname.

Overview of the Service

DNS Resolver / Reverse is designed for fast, simple, and structured DNS resolution checks.

The tool supports two core workflows:

It is useful for system administrators, SOC analysts, cybersecurity researchers, developers, DevOps engineers, infrastructure owners, incident responders, and OSINT analysts who need to quickly verify how a domain resolves or which reverse DNS name is associated with an IP address.

The tool provides both a human-readable result table and a JSON output, making it suitable for manual analysis, documentation, troubleshooting, and lightweight technical workflows.

🔍 How the Tool Works

The user selects a mode and enters the appropriate value.

In Resolve mode, the user enters a domain or hostname. The tool returns one or more IPv4 / IPv6 addresses associated with that name.

Example:

google.com → 172.253.63.138

In Reverse mode, the user enters an IPv4 or IPv6 address. The tool performs a reverse DNS lookup and returns the PTR hostname when available.

Example:

8.8.8.8 → dns.google

The output is displayed in a compact result block, a request / answer table, and raw JSON format.

The history of lookups is stored locally in the browser through LocalStorage and is not sent to the server.

🧩 Supported Modes

DNS Resolver / Reverse supports two main modes.

Resolve Mode

Resolve mode performs forward DNS resolution.

Direction:

Domain → IP

This mode accepts a clean domain or hostname.

Examples:

example.com

api.example.com

google.com

Resolve mode may return:

Reverse Mode

Reverse mode performs reverse DNS resolution.

Direction:

IP → PTR

This mode accepts IPv4 or IPv6 addresses.

Examples:

8.8.8.8

1.1.1.1

2606:4700:4700::1111

Reverse mode may return a PTR hostname if one exists.

Not every IP address has reverse DNS configured. If no PTR record exists, the tool may return an empty result, error state, or no answer depending on backend behavior.

🚫 Input Rules

The tool validates input depending on the selected mode.

Resolve Mode Input

Allowed:

Examples:

example.com

api.example.com

Not allowed:

https://example.com

example.com/path

example.com:443

http://api.example.com/v1

Protocols and paths are discarded or rejected depending on validation behavior. For best results, users should enter only the clean domain or hostname.

Reverse Mode Input

Allowed:

Examples:

1.1.1.1

2001:4860:4860::8888

Not allowed:

example.com

https://1.1.1.1

1.1.1.1:443

Reverse mode expects only a clean IP address.

⚙️ Interface Structure

The DNS Resolver / Reverse interface contains the following main elements.

Mode

The user selects the lookup mode.

Available modes:

Example:

Mode: Resolve (Domain → IP)

Domain / Hostname

In Resolve mode, the user enters a domain or hostname.

Example:

google.com

IP Address

In Reverse mode, the user enters an IPv4 or IPv6 address.

Example:

8.8.8.8

Request History

The interface includes local request history with mode filtering.

Users can filter history by:

This helps quickly review previous DNS checks.

📊 Result Summary

After a lookup is completed, the tool displays a result summary.

Example:

RESOLVE
Answers: 1
Request: google.com
Line: 1
Total Responses: 1

The summary helps users quickly understand:

📋 Request / Answer Table

The result table displays the original request and the returned answer or answers.

Example:

Request Answer(s)
google.com 172.253.63.138

For domains with multiple results, the answer field may contain several IP addresses.

Example:

Request Answer(s)
example.com 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946

For reverse lookups, the table may show:

Request Answer(s)
8.8.8.8 dns.google

This format is designed for quick copying into tickets, reports, notes, or troubleshooting documentation.

🧾 JSON Output

The tool also provides a raw JSON-style result.

Example:

{
  "result": {
    "google.com": "172.253.63.138"
  }
}

JSON output is useful for:

When multiple answers are returned, the JSON may include arrays or multiple values depending on backend output.

🔁 Forward Resolution

Forward DNS resolution maps a domain name to one or more IP addresses.

Common use cases:

Example:

api.example.com → 203.0.113.10

Forward resolution may return IPv4, IPv6, or both depending on the records available.

🔄 Reverse Resolution

Reverse DNS resolution maps an IP address to a hostname using PTR records.

Common use cases:

Example:

1.1.1.1 → one.one.one.one

Reverse DNS is optional. Many IP addresses do not have PTR records, and some PTR records may be generic or outdated.

🧠 Key Features

Forward DNS Resolution

Resolves a domain or hostname to IP address data.

Reverse DNS Resolution

Resolves an IP address to PTR hostname when available.

IPv4 and IPv6 Support

Reverse mode supports both IPv4 and IPv6.

Multiple Responses

The tool supports multiple returned responses, including A / AAAA-style arrays.

Human-Readable Summary

Results are displayed in a clean request / answer format.

JSON Output

Structured JSON output is available for technical workflows.

Mode-Based History

Query history can be filtered by lookup mode.

LocalStorage Privacy

History is stored locally in the browser and is not sent to the server.

Input Validation

Resolve mode validates domain input, while reverse mode validates IPv4 / IPv6 input.

🕓 Request History

The request history stores previous lookups locally in the browser.

Important behavior:

The history is stored in LocalStorage and is not sent to the server.

History may include:

History is useful for repeating checks and reviewing recent troubleshooting activity.

Because it is browser-local, it may be cleared if the user clears browser data, switches devices, or uses a different browser profile.

On shared devices, users should clear local history when lookup targets are sensitive.

🔎 Common Use Cases

DNS Resolver / Reverse can support many technical workflows.

Domain Troubleshooting

Check whether a domain or subdomain resolves to an IP address.

Reverse DNS Verification

Check whether an IP address has a PTR hostname.

Mail Server Review

Verify reverse DNS for mail infrastructure.

SOC Triage

Enrich suspicious domains or IPs during alert analysis.

Incident Response

Quickly map domains to IPs or IPs to hostnames.

Infrastructure Migration

Validate whether DNS changes resolve as expected.

OSINT Enrichment

Collect basic resolution data for public indicators.

Developer Debugging

Confirm whether an application hostname resolves correctly.

📬 Mail and Reverse DNS

Reverse DNS is especially important for email infrastructure.

Mail servers often require properly configured PTR records to improve deliverability and reduce spam classification risk.

Example checks:

mail.example.com → 203.0.113.25
203.0.113.25 → mail.example.com

A clean forward-confirmed reverse DNS setup can help validate that the hostname and IP align.

However, this tool performs direct resolve and reverse checks only. Full mail authentication review should also include MX, SPF, DKIM, DMARC, and SMTP banner validation.

⚠️ Result Interpretation Notes

DNS resolution results should be interpreted carefully.

Important points:

For critical infrastructure decisions, users should compare results with authoritative DNS data and multiple resolvers.

A practical DNS resolution workflow should follow these steps.

1. Choose the Correct Mode

Use Resolve for domain-to-IP checks and Reverse for IP-to-hostname checks.

2. Enter a Clean Value

Use only a domain in Resolve mode or only an IP in Reverse mode.

3. Review the Summary

Check mode, answer count, request value, and total responses.

4. Review the Table

Copy the request / answer pair if needed.

5. Check JSON Output

Use JSON for structured documentation or technical workflows.

6. Compare With Other DNS Tools

For critical results, verify using authoritative DNS or multi-location DNS tools.

7. Review Local History

Use the mode filter to find previous checks.

8. Clear History on Shared Devices

Remove LocalStorage history if the lookup values are sensitive.

🛡️ Security, Privacy & Responsible Use

DNS Resolver / Reverse is intended for lawful DNS troubleshooting, system administration, cybersecurity analysis, OSINT enrichment, and infrastructure review.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX DNS Resolver / Reverse is a lightweight DNS utility for forward and reverse resolution. It resolves domains and hostnames to IPv4 / IPv6 addresses, resolves IP addresses to PTR hostnames, supports multiple responses, displays results in both human-readable and JSON formats, and stores lookup history locally in the browser.

The tool is designed for DNS troubleshooting, infrastructure validation, SOC triage, OSINT enrichment, mail server review, DevOps workflows, and technical documentation.

Networks and WiFi

Reverse IP Lookup | Passive Reverse IP Domain Intelligence

image.png

The platform available at https://dash.niamonx.io/ripip — known as Reverse IP Lookup — is a passive reverse IP intelligence tool within the NiamonX platform. It allows users to search for domain names associated with a specific IPv4 or IPv6 address using passive DNS and reverse DNS-style intelligence sources.

Overview of the Service

Reverse IP Lookup is designed to help analysts identify which domains have been observed resolving to the same IP address.

The tool is useful for cybersecurity analysts, SOC teams, OSINT researchers, infrastructure owners, incident responders, fraud investigators, domain researchers, and compliance teams who need to understand the domain footprint connected to a specific IP.

A single IP address can host one domain, many unrelated domains, parked domains, generated domains, CDN-backed assets, customer websites, phishing infrastructure, malware infrastructure, or shared hosting environments. Reverse IP Lookup helps expose these relationships in a clean and structured format.

The tool performs Passive Reverse IP analysis, meaning it collects known or observed domain associations for the IP rather than actively scanning the server.

🔍 How the Tool Works

When a user enters an IP address, Reverse IP Lookup searches passive DNS / reverse intelligence data for domains that have been observed resolving to that IP.

The result contains a summary and a domain table.

The system may return:

Example input:

95.130.254.22

Example result summary:

IP: 95.130.254.22
Domains: 1
Unique TLD: 1
MaxLen: 19
Average Length: 19.0
Top TLD: com(1)

This gives users a quick view of how many domains are connected to the IP and what kind of domain distribution was observed.

Reverse IP Lookup supports IP-based lookup.

Supported input types:

Valid examples:

95.130.254.22

1.1.1.1

2001:4860:4860::8888

Unsupported input examples:

example.com

https://example.com

95.130.254.22:443

example.com/path

The tool expects only a clean IPv4 or IPv6 address. Domain-to-IP resolution should be performed in a separate DNS or IP / Domain Explorer module before using Reverse IP Lookup.

📌 What Passive Reverse IP Means

Passive Reverse IP means that the tool uses collected or observed DNS intelligence to identify domains linked to an IP address.

It is different from:

Passive Reverse IP focuses on known domain-to-IP associations.

This approach is useful because it allows analysts to understand the visible domain footprint of an IP without directly interacting with hosted websites or services.

⚙️ Interface Structure

The Reverse IP Lookup interface contains several key areas.

IP Address Input

The main field where the user enters an IPv4 or IPv6 address.

Example:

95.130.254.22

The interface supports IPv4 and IPv6.

Request History

Displays previous IP lookups stored locally in the browser.

Summary

Shows total domain statistics for the queried IP.

Domains Table

Displays the domain names associated with the IP.

TLD Filter

Allows users to filter domains by top-level domain.

Search Filter

Allows users to search within the returned domain list.

Raw JSON

Provides structured technical output for advanced analysis.

📊 Summary Section

The summary section provides a quick statistical overview of the IP’s domain footprint.

Typical fields include:

Field Description
IP Queried IPv4 or IPv6 address
Domains Total number of returned domain names
Domain Names Count of domain records
Unique TLD Number of unique top-level domains
Maximum Lengths Longest domain length in the result set
Average Lengths Average domain length
TOP TLD Most frequent TLDs and their counts
Timestamp Time when the lookup was performed

Example:

IP: 95.130.254.22
Domain Names: 1
Unique TLD: 1
Maximum Lengths: 19
Average Lengths: 19.0
TOP TLD: com(1)

This helps users quickly determine whether the IP is associated with a small, focused set of domains or a large, diverse hosting footprint.

🌐 Domains Table

The Domains table displays the domains associated with the queried IP.

Typical columns include:

Column Description
# Row number
Domain Domain name observed on the IP
TLD Top-level domain
Length Domain length

Example safe table format:

# Domain TLD Length
1 example-host.example.com com 24

The table is designed for filtering, review, pagination, and export.

🏷️ TLD Statistics

Reverse IP Lookup calculates TLD distribution from returned domains.

Example:

TOP TLD: com(1)

The TLD is calculated based on the last segment of the domain.

Examples:

Domain Calculated TLD
example.com com
test.org org
site.co.uk uk
portal.net net

TLD distribution helps analysts quickly understand the profile of domains on an IP.

For example:

📏 Domain Length Metrics

The tool calculates maximum and average domain length.

Fields:

Long domains may be useful signals during investigation.

Possible interpretations of unusually long domains:

Important: long domain length alone does not prove malicious activity. It is a triage signal that should be reviewed with additional context.

🔎 Filtering and Search

The interface includes filtering tools to make large result sets easier to analyze.

Users can filter by:

Example use cases:

Filtering is especially useful when an IP has many associated domains.

📄 Pagination

Reverse IP Lookup supports pagination for large result sets.

The user can control how many rows are shown per page.

Example:

25

Pagination helps keep the interface fast and readable when many domains are returned.

For very large responses, the number of domains may be truncated during the audit. Users should use TLD filtering and export options for deeper analysis.

📤 Export

The tool supports export for further analysis.

Export is useful for:

Exported data may include:

Exported results should be stored securely when they are used in investigations.

🧾 Raw JSON

Reverse IP Lookup can expose raw JSON output.

Raw JSON may include:

Raw JSON is useful for:

Raw JSON should be handled carefully when it contains sensitive investigation context.

🕓 Request History

The tool stores IP lookup history locally in the user’s browser.

Important behavior:

History is stored in the user's browser.

History may include:

Local history is useful for repeating checks and reviewing previous analysis.

Because it is stored locally, it may be cleared when the user deletes browser data, switches devices, or uses another browser profile.

On shared devices, users should clear local history when IP investigations are sensitive.

🧠 Key Features

Passive Reverse IP Lookup

Finds domains observed resolving to the same IP address.

IPv4 and IPv6 Support

Supports both IPv4 and IPv6 inputs.

Domain List

Displays associated domains in a structured table.

TLD Statistics

Calculates unique TLD count and top TLD distribution.

Domain Length Metrics

Shows maximum and average domain length.

Allows filtering by domain text and TLD.

Pagination

Supports large result sets through paginated display.

Export

Allows results to be exported for further analysis.

Raw JSON

Provides structured technical output for advanced users.

Local History

Stores IP lookup history locally in the browser.

🔍 Common Use Cases

Reverse IP Lookup supports many cybersecurity and OSINT workflows.

Shared Hosting Analysis

Identify domains hosted on the same IP address.

Threat Intelligence

Incident Response

Check whether a malicious IP hosts other domains that may be part of the same campaign.

Brand Protection

Search for domains on suspicious hosting infrastructure that may imitate a brand.

Phishing Investigation

Identify clusters of domains hosted on the same IP.

Infrastructure Mapping

Understand which domains are connected to an owned or third-party IP.

Asset Discovery

Find forgotten or related domains pointing to company infrastructure.

Fraud Investigation

Identify domains linked to suspicious hosting or repeated abuse patterns.

Malware Infrastructure Review

Check whether C2, landing, or payload domains share the same IP.

Compliance and Audit

Document domain exposure associated with organizational IPs.

🧠 Result Interpretation

Reverse IP data should be interpreted carefully.

Important notes:

Reverse IP Lookup should be used as an intelligence enrichment tool and correlated with DNS, WHOIS, TLS, HTTP, crawler, and reputation data.

🚨 Server Errors and Truncated Data

The tool notes that the number of domains may be truncated during the audit.

This means returned results may represent only part of the full available dataset.

If a server error occurs, such as a 500 response, users should repeat the request.

A practical reverse IP investigation should follow these steps.

1. Enter a Clean IP Address

Use only an IPv4 or IPv6 address.

2. Review the Summary

Check total domains, unique TLDs, maximum length, average length, and top TLDs.

3. Inspect the Domain Table

Review domain names and look for obvious patterns.

4. Use Search and TLD Filters

Filter by suspicious terms, brand names, TLDs, or naming structures.

5. Review Long Domains

Long or unusual domains may indicate generated, parked, or campaign-style infrastructure.

6. Export Results

Use export for bulk verification or deeper investigation.

7. Correlate With Other Tools

Check interesting domains with DNS, GeoDNS, WHOIS, TLS, IP intelligence, web fingerprinting, or reputation tools.

8. Validate Current Resolution

Confirm whether selected domains still resolve to the IP.

9. Preserve Evidence

Save relevant records and timestamps for reports or incident cases.

10. Avoid Overclaiming

Treat associations as leads until confirmed by additional evidence.

🛡️ Security, Privacy & Responsible Use

Reverse IP Lookup is intended for lawful cybersecurity, OSINT, infrastructure analysis, incident response, and defensive research.

Acceptable use cases include:

Users should follow responsible use rules:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Reverse IP Lookup is a passive reverse IP intelligence tool that identifies domains observed resolving to the same IPv4 or IPv6 address.

It provides domain counts, unique TLD statistics, top TLD distribution, domain length metrics, filtering, search, pagination, export, Raw JSON, and local browser history.

The tool is designed for lawful OSINT, SOC triage, threat intelligence enrichment, phishing investigation, malware infrastructure analysis, asset discovery, brand protection, and infrastructure mapping. Results should be treated as passive intelligence leads and validated before conclusions or action.

Networks and WiFi

ASN Information | Autonomous System Intelligence

image.png

The platform available at https://dash.niamonx.io/asnchecked — known as ASN Information — is an autonomous system intelligence tool within the NiamonX platform. It allows users to check detailed public information about an Autonomous System Number, including organization profile, country, routing scope, traffic category, IPv4 and IPv6 prefix counts, contact information, abuse contacts, RIR status, owner address, policies, website, and raw ASN metadata.

Overview of the Service

ASN Information is designed to help analysts, network engineers, SOC teams, infrastructure owners, cybersecurity researchers, and OSINT specialists quickly understand the public profile of an Autonomous System.

An Autonomous System, or AS, is a network or group of networks operated under a single routing policy on the Internet. Each AS is identified by an ASN, such as:

AS13335

or:

47215

The tool accepts ASN values with or without the AS prefix and returns a structured report containing routing, ownership, policy, contact, traffic, and organization information.

ASN Information is useful for network attribution, abuse reporting, infrastructure mapping, threat intelligence enrichment, routing analysis, vendor review, hosting-provider identification, and incident response.

🔍 How the Tool Works

When a user enters an ASN, the tool queries public and internal intelligence sources and returns the available ASN profile.

The result may include:

Data may be aggregated from public routing, RIR, IANA, peering, WHOIS, and organization sources. Because ASN data can come from multiple public datasets, it should be treated as intelligence context and validated before critical decisions.

🧩 What Can Be Checked

ASN Information accepts Autonomous System Numbers.

Supported input examples:

AS47215

47215

The AS prefix is optional.

Unsupported input examples:

example.com

1.1.1.1

https://example.com

AS47215/example

For IP addresses, domains, ports, or service-level intelligence, users should use the relevant NiamonX IP or DNS modules.

⚙️ Interface Structure

The ASN Information interface contains several main areas.

ASN Input

The user enters an Autonomous System Number.

Example:

AS47215

The tool normalizes the value and performs the lookup.

History ASN

The interface includes ASN history stored locally in the browser. This allows users to quickly repeat previous ASN checks.

Summary

The summary card shows the most important ASN profile fields.

ASN Info

The ASN Info section displays technical routing, policy, and network metadata.

Organization

The Organization section displays owner-related information such as name, address, country, website, and public organization metadata.

Prefixes

The Prefixes section lists IPv4 and IPv6 ranges associated with the ASN when available.

Raw JSON

Raw JSON provides the structured technical response for advanced analysis and integrations.

📊 Summary Section

The summary section gives a fast overview of the ASN.

Typical fields include:

Field Description
ASN Autonomous System Number
Name Organization or network name
Country Country code associated with the ASN
Traffic ratio Estimated traffic direction profile
Abuse contacts Number of abuse contact emails
Email contacts Number of general public email contacts
Owner address lines Number of owner address lines available
Updated Last profile update timestamp
Website Official website, if available
Description Short organization or ASN description

Example summary format:

ASN: AS47215
Name: Example Network GmbH
Country: DE
Traffic ratio: Mostly Outbound
Abuse contacts: 0
Email contacts: 0
Updated: 2024-06-26 04:47:55
Website: https://example.com/

This section is useful for quick triage before reviewing the full technical profile.

🏢 Organization Information

The Organization section displays the entity associated with the ASN.

Possible fields include:

Field Description
Name Organization name
Name long Extended organization name, if available
AKA Alternative names
Address Owner address lines
City Organization city
State State or region
Zipcode Postal code
Country Country code
Website Organization website
Social media Public organization links
Notes Additional public notes
Status Organization status

The owner address can help analysts understand the legal or operational entity behind the ASN. However, organization address data may be incomplete, outdated, or formatted differently depending on the source.

🌐 ASN Info Section

The ASN Info section contains technical and routing-related metadata.

Possible fields include:

Field Description
info_ipv6 Whether IPv6 information is available
info_multicast Whether multicast is indicated
info_unicast Whether unicast routing is indicated
info_prefixes4 Number of IPv4 prefixes
info_prefixes6 Number of IPv6 prefixes
info_ratio Traffic direction category
info_scope Geographic or routing scope
info_traffic Approximate traffic category
info_types Network type labels
irr_as_set IRR AS-SET value
policy_general General peering policy
policy_locations Peering location requirement
policy_contracts Contract requirement
policy_ratio Ratio policy indicator
policy_url Policy URL, if available
rir_status RIR status
rir_status_updated Last RIR status update
route_server Route server information
looking_glass Looking glass URL, if available
website Website URL

This information helps users understand how the ASN participates in Internet routing, peering, traffic exchange, and prefix advertisement.

🛣️ Prefixes

The Prefixes section lists network ranges associated with the ASN.

Example format:

109.75.176.0/20
141.101.32.0/21
185.13.210.0/23
185.134.240.0/24

Prefixes are useful for:

Important: prefix lists can change over time. Always validate current route announcements with routing tools, RIR data, or BGP sources when making operational decisions.

📡 IPv4 and IPv6 Support Indicators

ASN Information may show whether IPv4 and IPv6 routing data is available.

Example fields:

info_prefixes4: 30
info_prefixes6: 5
info_ipv6: true

IPv4 Prefix Count

Shows how many IPv4 prefixes are associated with the ASN in the returned profile.

IPv6 Prefix Count

Shows how many IPv6 prefixes are associated with the ASN in the returned profile.

IPv6 Indicator

Shows whether the ASN has IPv6-related information or support in the returned dataset.

These fields are useful for understanding the network’s routing footprint and protocol support.

📈 Traffic Ratio

The traffic_ratio or info_ratio field describes the estimated direction of network traffic.

Example:

Mostly Outbound

Possible categories may include:

This value is an assessment and should be treated as a routing or peering profile indicator, not as a precise measurement.

Interpretation

A Mostly Outbound network may primarily send more traffic than it receives. This can be common for hosting providers, content providers, certain infrastructure operators, or networks serving outbound-heavy workloads.

A Mostly Inbound network may receive more traffic, which can be common for access networks, eyeball networks, or consumer ISPs.

🌍 Scope and Traffic Category

The tool may show routing scope and traffic volume category.

Example fields:

info_scope: Europe
info_traffic: 1-5Gbps

Scope

Indicates the likely geographic or operational scope of the network.

Examples:

Traffic Category

Shows approximate traffic volume category.

Examples:

These fields are estimates and should not be interpreted as guaranteed real-time bandwidth measurements.

🧾 Contacts

ASN Information may display contact counts and contact-related fields.

Important contact types:

Contact Type Description
Abuse contacts Email addresses for abuse reporting
Email contacts General public contact emails
Contact export Exportable contact information when available

Abuse Contacts

abuse_contacts are used to report abuse such as spam, phishing, malware, scanning, botnet traffic, or other malicious activity.

Example use cases:

Email Contacts

email_contacts may include additional public email addresses for administrative or technical communication.

Contact data may be incomplete or missing depending on the source.

🏛️ IANA and RIR Data

The tool may include IANA and RIR-related fields.

Possible data includes:

RIR Status

The RIR status indicates whether the ASN profile appears valid or active in the returned registry data.

Example:

rir_status: ok
rir_status_updated: 2024-06-26 04:47:55

Regional Internet Registries include organizations such as RIPE NCC, ARIN, APNIC, LACNIC, and AFRINIC.

This data is important for attribution, validation, and abuse-reporting workflows.

🤝 Peering and Routing Policy

The ASN profile may include policy-related fields.

Possible fields:

Field Description
policy_general General peering policy
policy_locations Peering location requirements
policy_contracts Contract requirements
policy_ratio Whether traffic ratio is considered in policy
policy_url URL to public peering policy
irr_as_set IRR AS-SET for routing policy
route_server Route server participation
looking_glass Looking glass system, if available

Example:

policy_general: Open
policy_contracts: Not Required
irr_as_set: AS-FILOO

These fields are useful for peering research, network operations, IX participation analysis, and BGP routing review.

🔎 IRR AS-SET

An IRR AS-SET is a routing registry object that groups ASNs or routes for routing policy purposes.

Example:

AS-FILOO

IRR AS-SET values are useful for:

IRR data should be validated because registry objects can become outdated.

🔭 Looking Glass

A looking glass is a public network diagnostic tool offered by some network operators.

It may allow users to check:

If a looking glass URL is available, the ASN Information tool may show it in the profile.

If it is not available, the field may show:

—

🧬 Raw JSON

The tool provides Raw JSON for advanced analysis.

Raw JSON may include:

Raw JSON is useful for:

Raw data should be handled carefully when used in investigations or internal reports.

🕓 ASN History

The tool stores ASN lookup history locally in the browser.

History entries may include:

Local history helps users repeat previous ASN checks and compare recent lookups.

Because it is stored locally, it may be cleared when the user clears browser data, switches devices, or uses a different browser profile.

On shared devices, users should clear local history if ASN investigations are sensitive.

🧠 Key Features

ASN Lookup

Checks Autonomous System information by ASN.

Optional AS Prefix

Accepts ASN values with or without the AS prefix.

Organization Profile

Displays organization name, website, address, country, and related fields.

Country and Scope

Shows country code and routing scope.

Traffic Ratio

Displays estimated traffic direction, such as Mostly Outbound.

Prefix Overview

Shows IPv4 and IPv6 prefix counts and prefix lists.

Contact Parsing

Displays abuse contact counts and public email contact counts when available.

IANA / RIR Data

Includes registry status and update timestamps.

Policy Metadata

Shows peering and routing policy fields where available.

IRR AS-SET

Displays routing registry AS-SET information.

Contact Export

Supports contact export when contact data is available.

Raw JSON

Provides structured technical output for advanced workflows.

ASN History

Stores recent ASN checks locally in the browser.

🔍 Common Use Cases

ASN Information can support many technical and security workflows.

Network Attribution

Identify which organization operates an ASN.

Abuse Reporting

Find abuse contacts or organization information for reporting malicious traffic.

Threat Intelligence

Enrich suspicious IPs by mapping them to ASN ownership and prefix ranges.

SOC Triage

Quickly understand whether an alert involves hosting, access, cloud, or network service provider infrastructure.

BGP and Routing Research

Review prefixes, AS-SET, scope, policy, and traffic ratio.

Vendor and Provider Review

Understand network providers, hosting companies, and traffic profiles.

Infrastructure Mapping

Identify IP ranges associated with an organization.

Compliance and Risk Review

Document ASN ownership and routing metadata for audit workflows.

Incident Response

Determine who to contact and which prefixes may be related to an incident.

⚠️ Result Interpretation Notes

ASN data should be interpreted carefully.

Important points:

If a server-side 500 error occurs during lookup, repeat the request.

A practical ASN investigation should follow these steps.

1. Enter the ASN

Use either AS47215 or 47215.

2. Review the Summary

Check organization name, country, traffic ratio, contacts, update date, and website.

3. Check Contact Data

Look for abuse contacts and public email contacts.

4. Review Organization Details

Check address, country, website, and status.

5. Review ASN Info

Inspect IPv4 / IPv6 support, prefix counts, traffic category, routing scope, network type, and policy fields.

6. Review Prefixes

Use prefix lists for mapping, filtering, or threat intelligence enrichment.

7. Check RIR Status

Review registry status and update timestamp.

8. Use Raw JSON

Open Raw JSON for deeper technical workflows or export.

9. Correlate With Other Tools

Use IP lookup, reverse IP, DNS, BGP, WHOIS, and vulnerability tools for deeper analysis.

10. Validate Before Action

Confirm important conclusions before contacting providers, blocking ranges, or publishing reports.

🛡️ Security, Privacy & Responsible Use

ASN Information is intended for lawful network intelligence, security analysis, routing research, abuse reporting, and infrastructure review.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX ASN Information is an autonomous system intelligence tool for checking public ASN profile data, organization information, routing scope, traffic ratio, prefix lists, abuse contacts, RIR status, peering policy, website, owner address, and Raw JSON.

It is designed for lawful network intelligence, SOC triage, OSINT enrichment, abuse reporting, routing research, infrastructure mapping, compliance, and incident response. Data may be aggregated from public sources and should be validated before critical operational or legal decisions.

Website and Host Analysis

Website and Host Analysis

Website and Host Analysis

Phishing Check | URL Threat Inspection

image.png

The platform available at https://dash.niamonx.io/phishing_check — known as Phishing Check — is a URL threat inspection tool within the NiamonX platform. It checks submitted URLs against known phishing, malware, unwanted software, and social engineering indicators using NiamonX threat intelligence data and Google Safe Browsing signals.

Overview of the Service

Phishing Check helps users quickly evaluate whether a URL appears in known threat datasets.

The tool is designed for cybersecurity analysts, SOC teams, incident responders, fraud investigators, compliance teams, brand protection specialists, and general users who need to inspect suspicious links before opening, sharing, or escalating them.

Phishing Check returns a structured result that includes:

The tool is informational. A SAFE result does not guarantee that the resource is harmless, and an UNSAFE result should be validated with additional sources before high-impact decisions.

🔍 How the Tool Works

The user enters a full URL, including protocol.

Example:

https://example.com/

or:

http://testsafebrowsing.appspot.com/apiv4/ANY_PLATFORM/MALWARE/URL/

The tool checks the URL against threat intelligence sources, including:

The system then returns a result such as:

If matches are found, the tool displays threat type, affected platform, match details, risk score, and cache information.

🧩 What Can Be Checked

Phishing Check accepts full URLs.

Supported input format:

http://example.com/path

https://sub.example.com/login

The URL must include:

Subdomains are taken into account during inspection.

Unsupported or invalid inputs:

example.com

sub.example.com/login

1.1.1.1

just-text

For accurate inspection, users should paste the complete URL exactly as received.

⚙️ Interface Structure

The Phishing Check interface contains several main areas.

URL for Inspection

The input field where the user enters the full URL.

Example:

https://example.com/

The interface reminds users to enter the full URL with http:// or https://.

Examples of Queries

The interface may provide example URLs for testing safe browsing behavior or known test patterns.

Result Panel

The result panel displays:

Request History

The request history stores previous URL checks locally in the browser.

📊 Result Status

The main result status indicates whether the submitted URL matched known threat intelligence data.

Common statuses:

Status Meaning
SAFE No known threat match was found
UNSAFE One or more threat matches were found
UNKNOWN The result could not be clearly determined
ERROR The check failed or backend response was unavailable

Example unsafe result:

UNSAFE
Risk 40
Elevated
Coincidences: 1

Example safe result:

SAFE
Risk 0
None

A safe result should not be interpreted as a guarantee of security. It means the URL did not match the known threat sources used for that check.

🚦 Risk Score

The tool calculates a heuristic risk score based on detected threats.

Example:

Risk 40 (Elevated)

Risk score may consider:

Example interpretation:

Risk Level Meaning
None No known threat match
Low Weak or limited indicators
Elevated Known threat match or moderate risk
High Strong threat evidence
Critical Severe or multiple high-confidence indicators

The exact score is calculated by the platform’s internal heuristic logic.

🧬 Threat Types

The Types of Threats section lists the threat categories found for the URL.

Possible threat types may include:

Example:

Types of Threats
MALWARE

Threat type helps analysts understand the nature of the risk.

Malware

The URL may be associated with malware delivery, payload hosting, infection chains, or malicious downloads.

Social Engineering / Phishing

The URL may be associated with credential theft, impersonation, fake login pages, payment fraud, or deceptive content.

Potentially Harmful Application

The URL may be associated with harmful applications or mobile threats.

🖥️ Platform Types

The Platforms section shows which platform category the threat applies to.

Example:

ANY_PLATFORM

Possible platform values may include:

ANY_PLATFORM means the threat is not limited to a specific operating system or device type.

🎯 Coincidences / Matches

The Coincidences section displays detailed matches returned by the threat intelligence check.

A match may include:

Field Description
Threat type Malware, phishing, social engineering, or other category
Platform Affected platform category
Entry type URL or other supported indicator type
Threat URL URL that matched threat intelligence
Metadata Additional threat details, if available
Cache Cache duration, when returned

Example match:

Threat Type: Malware
Platform: ANY_PLATFORM
Entry Type: URL
Threat URL: http://example.test/malware/

The match details help analysts understand exactly what triggered the unsafe classification.

🧾 Metadata

The metadata section indicates whether additional metadata was returned.

Example:

Metadata: No

When metadata is available, it may contain additional context such as:

Metadata availability depends on the backend source and threat type.

🕒 Cache

The tool may show cache duration for the result.

Example:

Cache: 300s

Cache duration means the result may be reused for a short period to reduce repeated lookups and improve performance.

Important notes:

🧾 Raw JSON

The tool can provide Raw JSON when needed.

Raw JSON may include:

Raw JSON is useful for:

Raw output should be handled carefully when it contains suspicious URLs, investigation notes, or threat indicators.

🕓 Request History

Phishing Check stores URL check history locally in the browser.

History entries may include:

Example history item:

https://example.com/
SAFE
Risk 0
None

Important privacy behavior:

History does not go to the server.

Local history is useful for repeating checks and reviewing past inspections.

Because the history is browser-local, it may be cleared when users delete browser data or switch devices.

On shared devices, users should clear local history when checked URLs are sensitive.

🧠 Key Features

URL Threat Check

Checks full URLs against known threat indicators.

NiamonX Database

Uses NiamonX threat intelligence data.

Google Safe Browsing Signals

Uses Google Safe Browsing-style threat classifications.

Status and Risk

Shows SAFE / UNSAFE status, risk score, and risk level.

Detailed Matches

Displays threat type, platform type, entry type, and matched threat URL.

Aggregations

Shows threat type and platform aggregations.

Cache Awareness

Displays cache duration when available.

Metadata Support

Shows metadata when returned by the backend.

Local History

Stores previous URL checks locally in the browser.

Raw JSON

Provides structured technical data for advanced review.

Summary Copy

Allows copying a brief report for sharing or documentation.

🔎 Common Use Cases

Phishing Check can support many defensive workflows.

Check a URL before opening it.

SOC Triage

Inspect URLs from alerts, emails, chat messages, endpoint logs, or proxy logs.

Phishing Investigation

Confirm whether a URL is associated with social engineering or credential theft.

Malware URL Review

User Report Validation

Analyze URLs reported by employees or customers.

Brand Protection

Check suspicious domains or URLs impersonating a company.

Incident Response

Document known malicious URLs during security incidents.

Email Security Review

Threat Intelligence Enrichment

Add URL reputation information to internal cases or watchlists.

⚠️ Result Interpretation

Phishing Check results should be interpreted carefully.

Important points:

For high-risk cases, combine Phishing Check with sandbox analysis, DNS review, WHOIS, certificate inspection, HTTP header review, screenshot analysis, and endpoint telemetry.

A practical phishing review workflow should follow these steps.

1. Copy the Full URL

Include the full http:// or https:// URL exactly as received.

2. Run the Check

Submit the URL for inspection.

3. Review Status

Check whether the result is SAFE or UNSAFE.

4. Review Risk Score

Use risk score and level for triage.

5. Check Threat Types

Identify whether the match is malware, phishing, social engineering, or another category.

6. Review Platform Types

Check whether the threat is platform-specific or applies to any platform.

7. Inspect Coincidences

Review detailed match objects and threat URL.

8. Copy Summary

Use the summary copy function for tickets or incident reports.

9. Use Raw JSON When Needed

Open Raw JSON for automation, evidence, or deeper analysis.

10. Validate With Additional Sources

Use multiple security sources before making final decisions.

🛡️ Security, Privacy & Responsible Use

Phishing Check is intended for lawful cybersecurity, fraud prevention, incident response, and URL safety analysis.

Acceptable use cases include:

Users should follow responsible use rules:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Phishing Check is a URL threat inspection tool that checks full URLs against NiamonX Database and Google Safe Browsing signals.

It returns SAFE / UNSAFE status, heuristic risk score, risk level, threat types, platform types, detailed matches, cache information, metadata, local history, summary copy, and Raw JSON.

The tool is designed for phishing investigation, malware URL review, SOC triage, brand protection, incident response, email security analysis, and threat intelligence enrichment. Results are informational and should be validated with additional sources before final decisions.

Website and Host Analysis

Host Diagnostics | Multi-Protocol Network Diagnostic Tool

image.png

The platform available at https://dash.niamonx.io/host_diagnostics — known as Host Diagnostics — is a combined network diagnostic tool within the NiamonX platform. It allows users to check a host, IP address, or domain across multiple network layers using Ping, HTTP, TCP, DNS, and UDP diagnostics from distributed public nodes.

Overview of the Service

Host Diagnostics is designed to provide a structured, multi-protocol view of host availability and network behavior.

Unlike a single ping or DNS lookup, this tool performs several types of checks in one workflow. It can verify whether a target responds to ICMP-style ping checks, whether HTTP is reachable, whether TCP connectivity works, whether DNS resolution is available, and whether UDP responses are received from selected diagnostic nodes.

The tool is useful for:

The data depends on public diagnostic nodes used by the service. Results should be treated as network diagnostics and validated with additional tools for critical infrastructure decisions.

🔍 How the Tool Works

The user enters a target host, IP address, or domain and selects one or more diagnostic check types.

Supported target types:

Supported check types:

At least one check type must be enabled. The user can also define how many diagnostic nodes should be used and optionally specify node names manually.

After the request is submitted, the backend starts one or more diagnostic jobs. Each selected check type receives its own request ID and progresses independently until it reaches a final state such as complete, partial, failed, or timeout.

The final result is displayed as a combined diagnostic report with aggregated metrics and detailed node tables.

🧩 What Can Be Checked

Host Diagnostics supports three main categories of targets.

IPv4 Address

Example:

1.1.1.1

IPv6 Address

Example:

2606:4700:4700::1111

Domain or Hostname

Example:

niamonx.io

api.example.com

The tool should not be used with full URLs, paths, or query strings unless a specific check type supports that behavior. For best results, users should enter only the clean host, IP, or domain.

⚙️ Diagnostic Interface

The interface includes several key controls.

Host / IP

The main input field where the user enters the target.

Example:

1.1.1.1

Supported formats:

Types of Checks

Users can enable or disable diagnostic types by clicking the corresponding buttons.

Available checks:

At least one type must remain selected.

Max Nodes

Controls how many nodes should be used for each check.

Example:

Max nodes: 3

Using more nodes provides broader geographic visibility but may increase processing time.

Nodes Optional

Users can optionally specify node names manually.

Example format:

ua1.node,us1.node

Up to 20 node names may be entered as a comma-separated list, depending on backend limits.

If the field is empty, the system selects nodes automatically.

Initial Survey Cycles

Controls whether the request should return immediately with a request ID or wait briefly for partial or full readiness.

Example:

Initial survey cycles: 1

Interpretation:

Value Meaning
0 Return request ID immediately
1–8 Wait for polling until partial or full readiness

This option can make the first response more useful by allowing the backend to collect initial data before returning results.

📊 Combined Diagnostics Status

The main diagnostics panel displays the global status of the selected checks.

Example:

Diagnostics
COMPLETE
Updated: 22:25:28

Possible status values may include:

Status Meaning
COMPLETE All selected checks reached a final completed state
PARTIAL Some checks or nodes returned results, while others did not
RUNNING Checks are still in progress
FAILED The diagnostic job failed
TIMEOUT The check did not complete within the expected time
ERROR Backend or parsing error occurred

A complete status means the requested checks finished, not necessarily that every service responded successfully.

🛰️ Node-Based Diagnostics

Host Diagnostics uses external nodes to test the target from different network locations.

Each node may return different results because of:

Node-based diagnostics are especially useful when a host works from one region but fails from another.

📡 Ping Check

The Ping check measures basic network reachability and latency.

Example summary:

PING: nodes=3 avg/min/max=252.56/1.60/3000.34 ms samples=12

The Ping section may include:

Example table:

Node Samples Avg ms
br1.node.check-host.net 4 751.31
hk1.node.check-host.net 4 2.45
nl2.node.check-host.net 4 3.93

Ping Interpretation

Ping is useful for checking:

High ping values may indicate long-distance routing, congestion, packet loss, or regional network problems.

A failed ping does not always mean the host is down. Some hosts block ICMP-style traffic while still serving HTTP, TCP, or DNS normally.

🌐 HTTP Check

The HTTP check verifies whether the target responds over HTTP or HTTPS-style web checks, depending on backend behavior.

Example summary:

HTTP: nodes=3 codes=301 t(avg/min/max)=0.124/0.040/0.170s

The HTTP section may include:

Example table:

Node Code Status Time s IP
ir5.node.check-host.net 301 Moved Permanently 0.164 1.1.1.1
ir7.node.check-host.net 301 Moved Permanently 0.170 1.1.1.1
si1.node.check-host.net 301 Moved Permanently 0.040 1.1.1.1

HTTP Interpretation

HTTP diagnostics are useful for checking:

Common HTTP codes:

Code Meaning
200 OK
301 Moved Permanently
302 Found / temporary redirect
403 Forbidden
404 Not Found
500 Server error
502 / 503 / 504 Gateway or service availability problem

A successful HTTP response does not always mean the application is healthy. It only confirms that an HTTP-level response was returned.

🔌 TCP Check

The TCP check tests whether a TCP connection can be established.

Example summary:

TCP: success=3/3 t=0.004/0.001/0.010s

The TCP section may include:

Example table:

Node Status Time s
ae1.node.check-host.net OK 0.010
es1.node.check-host.net OK 0.002
in3.node.check-host.net OK 0.001

TCP Interpretation

TCP checks are useful for verifying:

A successful TCP check means the node could establish a connection. It does not necessarily validate the full application protocol.

🧭 DNS Check

The DNS check verifies DNS resolution from selected diagnostic nodes.

Example summary:

DNS: nodes=3 A=0 AAAA=0 TTL(min/max)=1001/1523

The DNS section may include:

Example table:

Node A AAAA TTL
nl1.node.check-host.net - - 1523
nl2.node.check-host.net - - 1509
rs1.node.check-host.net - - 1001

DNS Interpretation

DNS diagnostics are useful for:

If the target is an IP address rather than a domain, DNS results may be limited or empty depending on backend behavior.

📦 UDP Check

The UDP check attempts UDP-level diagnostics from selected nodes.

Example summary:

UDP: answers=0/3 0.0% timeouts=3

The UDP section may include:

Example table:

Node Result
bg1.node.check-host.net Timeout
pt1.node.check-host.net Timeout
rs1.node.check-host.net Timeout

UDP Interpretation

UDP diagnostics are useful for checking:

UDP is connectionless, so timeouts are common and may not always indicate failure. Many services do not respond to generic UDP probes.

📋 Aggregated Metrics

Host Diagnostics provides summaries for each check type.

Examples:

PING: avg/min/max
HTTP: status codes and response time
TCP: success rate and connection time
DNS: A/AAAA and TTL
UDP: answers and timeouts

Aggregated metrics help analysts quickly identify which layer is failing.

For example:

🧾 Request IDs

Each check type may receive its own request ID.

Example:

Req: 42298127k877

Request IDs help track individual diagnostic jobs and are useful when polling, debugging, or comparing results.

🧪 Initial Survey Cycles

The Initial survey cycles setting controls how quickly the initial response is returned.

0 Cycles

The tool returns the request ID immediately.

This is useful for asynchronous workflows where the user or interface will poll later.

1–8 Cycles

The tool waits briefly for partial or complete readiness before returning the result.

This can speed up the user experience because initial data may already be available when the result appears.

🧠 Key Features

Combined Network Diagnostics

Runs Ping, HTTP, TCP, DNS, and UDP checks from one interface.

Flexible Type Selection

Users can enable or disable check types as needed.

Multi-Node Testing

Checks can run from several public diagnostic nodes.

Automatic Node Selection

If no nodes are specified, the system selects nodes automatically.

Manual Node Selection

Advanced users can specify node names manually.

Aggregated Metrics

Each check type includes summarized performance and availability data.

Detailed Node Tables

Per-node results show regional differences and diagnostic details.

Summary Copy

The tool can provide a copyable summary for reports or tickets.

Export Support

Diagnostic results can be copied or exported for documentation.

Local History

Previous checks are stored locally in the browser.

Raw Output

Raw data can be used for format debugging and deeper troubleshooting.

🕓 Request History

The Request History section stores previous diagnostic checks locally in the browser.

History entries may include:

Example history item:

1.1.1.1
dns,http,ping,tcp,udp
OK
17.06.2026, 22:25:28

Possible history statuses:

Status Meaning
OK Diagnostic completed successfully
PART Partial result
FAIL Failed result
ERROR Error occurred

Local history helps repeat previous diagnostics and compare results over time.

Because it is stored in the browser, it may be cleared when users delete browser data or switch devices.

🔧 Raw Output

The tool may provide raw output for format debugging.

Raw data can help developers and analysts understand:

Raw output is useful for technical troubleshooting but should not be necessary for normal users.

A practical host diagnostic workflow should follow these steps.

1. Enter the Target

Use an IPv4 address, IPv6 address, domain, or hostname.

2. Select Check Types

Enable Ping, HTTP, TCP, DNS, UDP, or only the checks relevant to the issue.

3. Set Max Nodes

Use 3 nodes for quick checks or more nodes for broader regional diagnostics.

4. Specify Nodes If Needed

Enter node names manually when testing from specific regions.

5. Choose Initial Survey Cycles

Use 1 for a balanced interactive result or 0 for immediate request ID return.

6. Review Global Status

Check whether the overall result is complete, partial, failed, or still running.

7. Analyze Each Layer

Review Ping, HTTP, TCP, DNS, and UDP independently.

8. Compare Nodes

Look for regions where one node fails while others succeed.

9. Identify the Failing Layer

Use differences between protocols to isolate DNS, web, TCP, UDP, or routing problems.

10. Copy or Export Results

Use summaries for incident tickets, reports, or support communication.

🔎 Common Use Cases

Host Diagnostics can support many technical workflows.

Website Availability Check

Use HTTP and DNS checks to confirm whether a website is reachable.

Network Reachability Check

Use Ping and TCP checks to verify basic connectivity.

DNS Propagation Review

Use DNS checks across nodes to compare A, AAAA, and TTL values.

Firewall Troubleshooting

Compare TCP / UDP / Ping behavior to identify filtering.

Incident Response

Quickly determine whether a target is globally down or regionally affected.

DevOps Monitoring

Use repeated diagnostics to investigate deployment, DNS, or routing issues.

SOC Triage

Check suspicious hosts or infrastructure indicators from multiple layers.

Regional Connectivity Analysis

Use node-level results to identify geographic network problems.

⚠️ Result Interpretation Notes

Host Diagnostics results should be interpreted carefully.

Important limitations:

For production incidents, combine Host Diagnostics with server logs, application monitoring, traceroute, firewall logs, DNS provider dashboards, and cloud provider status pages.

🛡️ Security, Privacy & Responsible Use

Host Diagnostics is intended for lawful network diagnostics, troubleshooting, uptime checks, incident response, and infrastructure analysis.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Host Diagnostics is a combined multi-protocol network diagnostic tool for checking IPv4 addresses, IPv6 addresses, domains, and hostnames across Ping, HTTP, TCP, DNS, and UDP layers.

It supports flexible check selection, multi-node testing, automatic or manual node selection, initial survey cycles, per-check request IDs, aggregated metrics, node-level tables, summary copy, export support, local browser history, and raw output for debugging.

The tool is designed for network troubleshooting, DevOps workflows, SOC triage, incident response, website availability checks, DNS diagnostics, firewall validation, and regional connectivity analysis. Results should be interpreted as diagnostic signals and validated with additional monitoring sources for critical decisions.

Website and Host Analysis

Domain WHOIS Checker | WHOIS / RDAP Domain Intelligence

image.png

The platform available at https://dash.niamonx.io/domain_whois — known as Domain WHOIS Checker — is a domain intelligence and registration analysis tool within the NiamonX platform. It allows users to check WHOIS / RDAP information for a domain name, normalize raw registry responses, extract key ownership and registration fields, assess domain risk, and review domain age, expiration, registrar, name servers, statuses, abuse contacts, and parsed technical data.

Overview of the Service

Domain WHOIS Checker is designed to help users quickly understand the registration profile of a domain.

The tool collects and normalizes WHOIS / RDAP-style data and displays it in a clean, structured format. Instead of forcing the user to manually read raw WHOIS text, the system extracts the most important fields and presents them as a readable domain report.

The module is useful for:

The tool displays domain status, registrar, WHOIS server, IANA registrar ID, DNSSEC status, creation date, update date, expiration date, name servers, registry statuses, contact emails, raw WHOIS, extra text, and parsed JSON.

All data is provided “as is” and should be validated with official registrar or registry sources when used for critical decisions.

🔍 How the Tool Works

The user enters a domain name and selects optional normalization settings.

Example input:

google.com

The tool then performs a WHOIS / RDAP lookup and parses the returned response.

The result may include:

The tool also calculates high-level metrics such as domain age and remaining expiration time, which help analysts quickly understand whether the domain appears newly registered, mature, expiring soon, or stable.

🧩 What Can Be Checked

Domain WHOIS Checker accepts domain names.

Valid examples:

google.com

cloudflare.com

niamonx.io

github.io

Invalid examples:

https://google.com

google.com/search

https://example.com/login

1.1.1.1

The tool is intended for domain names only. IP lookup, DNS resolution, reverse IP, ASN, and service intelligence are handled by separate NiamonX modules.

⚙️ Interface Structure

The Domain WHOIS Checker interface contains several main sections.

Domain

The input field where the user enters the domain name.

Example:

google.com

Options

The tool provides optional processing settings.

Available options may include:

These options help normalize input and protect sensitive contact details in the displayed report.

Results

The result panel displays the normalized domain report.

General

The General section shows core WHOIS / RDAP fields.

Dates

The Dates section displays creation, update, and expiration timestamps.

Name Servers

The Name Servers section lists authoritative name servers returned by the registry or registrar.

Statuses

The Statuses section shows domain registry status flags.

Emails

The Emails section shows detected contact or abuse emails, depending on WHOIS availability and masking settings.

Raw WHOIS

Displays the original raw WHOIS response.

Extra Text

Displays additional unstructured text returned by the WHOIS source.

Parsed JSON

Displays the normalized structured representation of the WHOIS result.

Request History

Stores recent domain checks locally in the browser.

🛠️ Input Normalization Options

Domain WHOIS Checker includes options that help prepare and sanitize the input or output.

Lower-case

Converts the submitted domain to lowercase.

Example:

GOOGLE.COM → google.com

This improves consistency because domain names are case-insensitive in normal DNS usage.

Trim

Removes extra spaces before and after the domain.

Example:

  google.com   → google.com

This prevents accidental lookup errors caused by copied whitespace.

Mask Email

Masks or partially hides email addresses in the displayed result.

This is useful when:

When full contact details are needed for an authorized workflow, users should handle them carefully.

📊 Result Summary

After a successful lookup, the tool displays a high-level summary.

Example structure:

google.com
Active
Risk 0 Low
Age 10502d
Exp 819d
Registrar: MarkMonitor Inc.
NS Count: 4

The summary helps users quickly understand:

🚦 Domain Status

The result may show a general domain state, such as:

Active

This means the domain appears to have valid registration data and is not obviously expired or unavailable in the returned WHOIS / RDAP response.

Possible domain states may include:

The exact state depends on the registry data and parser output.

⚠️ Risk Score

Domain WHOIS Checker calculates a risk score and risk level.

Example:

Risk 0 Low

The risk score is an analytical indicator. It may consider factors such as:

Risk score helps with triage, but it is not a final reputation verdict.

A low risk score does not guarantee that the domain is safe. A higher score does not automatically prove malicious activity.

📅 Domain Age

The Age metric shows how many days have passed since the domain creation date.

Example:

Age 10502d

Domain age is useful for reputation analysis.

General interpretation:

Domain Age Possible Interpretation
0–30 days Newly registered domain; review carefully
31–180 days Young domain; may require context
181–365 days Established but still relatively new
1–5 years More mature domain
5+ years Long-running domain, often lower registration-age risk

Newly registered domains are often important in phishing, scam, malware, and impersonation investigations, but domain age alone is not proof of malicious activity.

⏳ Expiration Metric

The Exp metric shows how many days remain until the domain expiration date.

Example:

Exp 819d

Expiration data is useful for:

A domain close to expiration may represent operational risk if it belongs to an organization.

For suspicious domains, short expiration windows may indicate temporary infrastructure, but this must be interpreted with other signals.

🏢 Registrar Information

The Registrar field shows which registrar manages the domain registration.

Example:

Registrar: MarkMonitor Inc.

The General section may also show:

Field Description
Registrar Registrar name
WHOIS Server Registrar WHOIS server
IANA ID Registrar identifier assigned by IANA
DNSSEC DNSSEC status

Example:

Whois Server: whois.markmonitor.com
IANA ID: 292
DNSSEC: unsigned

Registrar data is useful for:

🔐 DNSSEC Status

The DNSSEC field shows whether the domain has DNSSEC configured according to the returned data.

Example:

DNSSEC: unsigned

Possible values may include:

DNSSEC helps protect DNS integrity by allowing cryptographic validation of DNS responses. However, lack of DNSSEC does not automatically mean a domain is malicious.

📅 Dates Section

The Dates section displays key lifecycle timestamps.

Common fields:

Field Description
Creation Date When the domain was first registered
Updated Date When the registration record was last updated
Expiration Date When the domain is scheduled to expire

Example:

Creation Date: 1997-09-15T04:00:00Z
Updated Date: 2019-09-09T15:39:04Z
Expiration Date: 2028-09-14T04:00:00Z

Creation Date

Useful for domain age analysis.

Updated Date

Useful for detecting recent registration changes, registrar transfers, DNS changes, or administrative updates.

Expiration Date

Useful for lifecycle monitoring and risk assessment.

🌐 Name Servers

The Name Servers section lists authoritative DNS servers for the domain.

Example:

NS1.GOOGLE.COM
NS2.GOOGLE.COM
NS3.GOOGLE.COM
NS4.GOOGLE.COM

Name servers are useful for:

A sudden change in name servers may indicate migration, takeover, compromise, or operational change depending on context.

🏷️ Registry Statuses

Domain statuses show registry-level restrictions or lifecycle states.

Example statuses:

clientDeleteProhibited
clientTransferProhibited
clientUpdateProhibited
serverDeleteProhibited
serverTransferProhibited
serverUpdateProhibited

Common statuses include:

Status Meaning
clientTransferProhibited Registrar-level transfer lock
clientDeleteProhibited Registrar-level delete protection
clientUpdateProhibited Registrar-level update restriction
serverTransferProhibited Registry-level transfer restriction
serverDeleteProhibited Registry-level delete restriction
serverUpdateProhibited Registry-level update restriction
ok Standard active state
pendingDelete Domain is pending deletion
redemptionPeriod Domain is in redemption period
clientHold Domain may be prevented from resolving
serverHold Registry-level hold

Status codes help analysts understand domain protection, lifecycle, and administrative restrictions.

📧 Emails and Contacts

The tool extracts visible email addresses from the WHOIS / RDAP response when available.

Example:

abusecomplaints@example-registrar.com

Email fields may include:

Due to privacy rules and redaction practices, many WHOIS records no longer expose registrant personal email addresses.

If Mask email is enabled, emails may be hidden or partially masked in the interface.

Contact emails are useful for:

🧾 Raw WHOIS

The Raw WHOIS section displays the original unnormalized WHOIS response.

Raw WHOIS is useful when:

Raw WHOIS may contain unstructured text, registry disclaimers, contact fields, status lines, name servers, and timestamps.

📄 Extra Text

The Extra Text section displays additional unstructured content that may not fit into standard parsed fields.

This may include:

Extra Text can be useful when investigating unusual registry responses.

🧬 Parsed JSON

The Parsed JSON section displays structured normalized data extracted from WHOIS / RDAP.

Parsed JSON may include:

Parsed JSON is useful for:

🕓 Request History

The tool stores recent domain checks in the browser.

History entries may include:

Example history format:

google.com
active
R0
A:10502d
E:819d
17.06.2026, 22:28:54

History is useful for quickly repeating previous checks and comparing how domain age, expiration, and risk score change over time.

Because history is browser-local, it may be cleared when users delete browser data or switch devices.

On shared devices, users should clear history when investigated domains are sensitive.

🧠 Key Features

WHOIS / RDAP Lookup

Checks domain registration data using WHOIS / RDAP-style sources.

Normalization

Normalizes non-standard keys and inconsistent registry responses.

Risk Assessment

Calculates domain risk score and risk level.

Domain Age

Calculates how many days have passed since creation.

Expiration Tracking

Calculates how many days remain until expiration.

Registrar Information

Shows registrar, WHOIS server, and IANA ID.

DNSSEC Status

Displays DNSSEC signing state when available.

Name Server Extraction

Lists authoritative name servers.

Status Extraction

Displays registry and registrar status codes.

Email Extraction and Masking

Extracts contact emails and supports masking.

Raw WHOIS

Allows manual review of original response.

Parsed JSON

Provides structured technical data.

Request History

Stores recent checks locally in the browser.

Export Support

Supports history and result export workflows when available.

🔎 Common Use Cases

Domain WHOIS Checker supports many investigative and operational workflows.

Phishing Investigation

Check whether a suspicious domain is newly registered or has risky lifecycle signals.

Brand Protection

Monitor domains that imitate a company, product, or executive name.

Abuse Reporting

Find registrar and abuse contact information.

SOC Triage

Enrich suspicious domains from alerts, emails, logs, or SIEM events.

Domain Lifecycle Monitoring

Check expiration dates for owned or critical domains.

Infrastructure Review

Identify registrar, name servers, and DNSSEC status.

Threat Intelligence

Collect registration metadata for suspicious infrastructure.

Compliance and Documentation

Document domain ownership and registration details.

Fraud Analysis

Review domain age, registrar, and status flags for suspicious websites.

⚠️ Result Interpretation

WHOIS / RDAP data should be interpreted carefully.

Important points:

For legal, takedown, or high-impact security actions, validate with the registrar, registry, RDAP, DNS, certificate transparency, passive DNS, and content analysis.

A practical WHOIS investigation should follow these steps.

1. Enter a Clean Domain

Use only the domain name without protocol or path.

2. Enable Normalization Options

Use lower-case and trim to avoid input mistakes.

3. Enable Email Masking When Sharing

Mask email addresses before screenshots or external reports.

4. Review the Summary

Check activity status, risk, age, expiration, registrar, name server count, and detected emails.

5. Review Dates

Check creation, update, and expiration dates.

6. Review Registrar

Identify registrar, WHOIS server, and IANA ID.

7. Review Name Servers

Check whether name servers match expected infrastructure.

8. Review Status Codes

Look for transfer locks, holds, pending deletion, or lifecycle restrictions.

9. Inspect Raw WHOIS

Use raw WHOIS when parser output looks incomplete or unusual.

10. Use Parsed JSON

Use structured JSON for reports, automation, or case management.

🛡️ Security, Privacy & Responsible Use

Domain WHOIS Checker is intended for lawful domain intelligence, cybersecurity analysis, infrastructure review, and abuse reporting.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Domain WHOIS Checker is a WHOIS / RDAP domain intelligence tool that normalizes raw registry responses and displays key domain registration metrics, including status, risk, age, expiration, registrar, WHOIS server, IANA ID, DNSSEC, name servers, statuses, emails, raw WHOIS, extra text, parsed JSON, and request history.

The tool is designed for phishing investigation, SOC triage, OSINT enrichment, brand protection, abuse reporting, domain lifecycle monitoring, compliance review, and infrastructure analysis. Results are provided “as is” and should be validated with official registrar, registry, DNS, and security sources when used for important decisions.

Website and Host Analysis

WebSite Screenshot | Web Capture & Device Emulation Tool

image.png

The platform available at https://dash.niamonx.io/webscreen — known as WebSite Screenshot — is a universal web screenshot and page-capture tool within the NiamonX platform. It allows users to capture visual snapshots of websites using desktop, phone, or tablet emulation, with support for viewport screenshots, full-page screenshots, DOM element capture, selector-based interaction, crop areas, custom headers, cookies, language settings, zoom, delay, cache control, and multiple output formats.

Overview of the Service

WebSite Screenshot is designed to help users capture accurate visual evidence of web pages, interfaces, landing pages, dashboards, public websites, suspicious pages, phishing pages, brand impersonation pages, documentation pages, and web content that needs to be reviewed, archived, or shared.

The tool can emulate different devices and screen sizes, wait for dynamic content to load, hide unwanted elements, click selectors before capture, crop a specific area, or capture the entire page. It is useful for OSINT analysts, SOC teams, brand protection teams, compliance departments, QA engineers, developers, investigators, content reviewers, and support teams.

The module supports several capture modes and configuration options, making it suitable for both quick screenshots and more controlled technical captures.

🔍 How the Tool Works

When a user enters a website URL and selects capture settings, WebSite Screenshot loads the page in a controlled rendering environment and creates a screenshot based on the selected options.

The tool can capture:

The result is returned as an image file with size, format, cache key, timestamp, and screenshot preview.

Example capture configuration:

Website URL: https://niamonx.io/en/
Device: Desktop
Dimension: 1024x768
Format: JPG
Delay: 200 ms
Zoom: 100%

Example result:

JPG
110.6 KB
Key: 40285e67
17.06.2026, 22:32:30

🧩 What Can Be Captured

WebSite Screenshot supports full website URLs.

Valid examples:

https://niamonx.io/en/

https://example.com/

https://docs.example.com/page

Unsupported or invalid examples:

example.com

niamonx.io/en/

localhost

file:///C:/page.html

For best results, users should enter a complete URL with http:// or https://.

⚙️ Capture Settings

The Capture Settings panel contains the main screenshot configuration options.

Website URL

The full URL of the page to capture.

Example:

https://niamonx.io/en/

The URL should include the protocol and should point to a page that can be loaded by the screenshot backend.

Device

The device setting controls browser emulation.

Available device modes may include:

Device emulation affects viewport size, user-agent behavior, layout rendering, and responsive design.

Example:

Device: Desktop

Dimension

The dimension field defines viewport width and height.

Example:

1024 x 768

Supported examples:

1024x768
480x800
1024xfull

The full height mode captures the full page instead of only the visible viewport.

Format

The output format controls the image type.

Example:

Format: JPG

Possible output formats may include:

JPG is usually best for smaller file size. PNG is useful when sharper UI text, transparency, or lossless output is required.

Delay

Delay controls how long the tool waits before taking the screenshot.

Example:

Delay: 200 ms

Supported delay values may include:

0, 200, 400, ..., 10000

Delay is useful for pages that load content dynamically, show animations, fetch API data, display cookie banners, or need time for layout stabilization.

Page Type Suggested Delay
Static page 0–400 ms
Normal dynamic website 1000–2000 ms
Heavy page / animations 2000–5000 ms
Full-page capture 2000 ms or more
Complex dashboards 3000–10000 ms

Zoom

Zoom controls the rendering scale.

Example:

Zoom: 100%

Zoom can be used when users need to capture a wider area, make text smaller or larger, or reproduce a specific visual layout.

Cache Limit

Cache limit controls how long a screenshot result may be reused.

Example:

Cache limit: 14 days

Special value:

0 = no cache

Example for one hour:

0.041666 = 1 hour

Caching improves speed and reduces repeated captures for the same URL and settings. When fresh visual evidence is required, cache should be disabled or reduced.

🖥️ Device Presets

The tool supports common device presets.

Desktop

1024x768
1366x768
1920x1080

Desktop mode is useful for:

Phone

480x800

Phone mode is useful for:

Tablet

800x1280

Tablet mode is useful for:

Full Page

Example:

1024xfull

Full-page capture is useful for:

For heavy pages, a delay of at least 2000 ms is recommended.

🧠 Advanced Options

The Advanced section allows more precise control over the capture.

CSS Selector

The CSS Selector field captures a specific DOM element instead of the whole viewport.

Example:

#main-content

.article-body

Use cases:

Click Selector

The click selector is used to click an element before the screenshot is taken.

Examples:

.cookie-accept

#close

Use cases:

This option is useful for pages that require one simple interaction before capture.

Hide Selectors

Hide selectors remove or visually hide unwanted elements before capture.

Example:

.ads, .cookie, #modal

Use cases:

Users should use this carefully when capturing evidence. If the screenshot is used for compliance, legal, or incident response, the report should mention that some elements were hidden.

Crop

The crop option captures a specific rectangle from the rendered page.

Format:

x,y,width,height

Example:

100,0,800,300

Use cases:

Accept-Language

The Accept-Language field controls the language preference sent with the request.

Example:

en-US

This is useful when websites show different content based on language settings.

Examples:

en-US
de-DE
uk-UA
ru-RU

User-Agent

The User-Agent field allows custom browser identification.

Example:

Mozilla/5.0 (...)

Use cases:

Custom user-agent should be used responsibly and documented when screenshots are used as evidence.

Cookies

Cookies can be passed to the page before capture.

Format:

name1=value1;name2=value2

Use cases:

Sensitive cookies must be handled carefully. Users should not paste private session tokens unless they are authorized and understand the security implications.

📊 Result Section

After a successful capture, the result panel displays screenshot output details.

Typical fields include:

Field Description
Format Output image format
File size Size of generated screenshot
Key Cache or result key
Timestamp Capture time
Preview Screenshot preview

Example:

JPG
110.6 KB
Key 40285e67
17.06.2026, 22:32:30

The preview allows users to quickly verify that the capture looks correct before saving or using it in a report.

🕓 Local History

The tool stores recent capture requests locally in the user’s browser.

Example behavior:

Stores last 100 queries in your browser.

History entries may include:

Example history item:

desktop
https://niamonx.io/en/
1024x768
JPG
17.06.2026, 22:32:30

Local history helps users repeat previous captures with the same settings.

Because history is stored locally, it may be cleared when users delete browser data, switch devices, or use a different browser profile.

On shared devices, users should clear local history when captured URLs are sensitive.

🚦 Query Limits and Plan Access

WebSite Screenshot uses plan-based query limits.

Example:

179 / 180
Queries remaining / total
Plan: Sentinel

Important points:

Users should monitor remaining queries when performing bulk captures or evidence collection.

🧠 Key Features

Universal Web Screenshot Capture

Captures public web pages and web interfaces into image format.

Device Emulation

Supports desktop, phone, and tablet modes.

Custom Viewport

Allows custom width and height values.

Full-Page Capture

Supports long-page screenshot capture using full height.

Element Capture

Captures a specific DOM element using a CSS selector.

Crop Capture

Captures a specific rectangle from the rendered page.

Delay Control

Waits before capture to allow dynamic content to load.

Zoom Control

Adjusts rendering scale.

Output Format Selection

Supports image output such as JPG and other configured formats.

Supports custom cookies, language headers, and user-agent.

Selector Interaction

Can click selectors before capture and hide selected elements.

Cache Control

Allows caching screenshot results for a configurable number of days.

Local History

Stores last 100 capture requests in the browser.

Plan-Based Limits

Access and query volume depend on the user’s plan.

🔎 Common Use Cases

WebSite Screenshot supports many practical workflows.

OSINT Evidence Capture

Capture public web pages for investigation notes.

Phishing Page Documentation

Capture suspicious login pages, clone pages, or malicious landing pages.

Brand Protection

Document impersonation pages, fake stores, fake login pages, or unauthorized brand use.

SOC and Incident Response

Attach visual evidence to security incidents and tickets.

Website QA

Test desktop, phone, and tablet rendering.

Compliance Review

Capture policy pages, consent banners, or public disclosures.

Content Monitoring

Create screenshots of public pages for review.

Support Documentation

Capture UI states for support tickets or user guides.

Archive Snapshots

Preserve visual appearance of pages at a specific time.

📸 Full-Page Capture

Full-page capture is useful when the content extends below the visible viewport.

Example:

1024xfull

Delay: 2000 ms or higher

Full-page screenshots are useful for:

Full-page captures may be larger and may take longer to process.

🧩 Element Capture

Element capture allows users to screenshot only a specific part of a page.

Example selector:

#pricing

This is useful when the user needs a clean image of one section without surrounding content.

Common selectors:

#main
.article
.login-form
.pricing-table
.hero

Element capture depends on valid CSS selectors and page structure. If the selector does not match any element, the capture may fail or return an empty result.

🧹 Cleaning the Page Before Capture

The tool can click and hide elements before capturing.

Click Selector

Use this to accept consent or close overlays.

Example:

.cookie-accept

Hide Selectors

Use this to remove visual clutter.

Example:

.ads, .cookie, #modal

Common elements to hide:

For evidence workflows, users should document any hidden or clicked elements so the screenshot remains transparent and reproducible.

🌍 Language, Region, and Session Context

Web pages may show different content depending on browser headers, cookies, region, and device.

WebSite Screenshot provides controls for:

These settings help reproduce specific page states.

Examples:

Accept-Language: en-US

Device: Phone
Dimension: 480x800

Cookies: region=de;consent=yes

This is useful when investigating region-specific phishing pages, localized landing pages, or responsive layouts.

🧾 Cache Behavior

The cache limit controls how long the screenshot result can be reused.

Examples:

0 = no cache

14 = cache for 14 days

Cache is useful for:

No-cache mode is useful when:

⚠️ Result Interpretation

Screenshots should be interpreted carefully.

Important notes:

For investigations, screenshots should be combined with timestamp, URL, DNS data, WHOIS, HTTP headers, TLS certificate data, and raw page evidence when available.

A practical screenshot workflow should follow these steps.

1. Enter the Full URL

Use https:// or http:// and include the exact path.

2. Choose Device Mode

Select desktop, phone, or tablet depending on the page version you need.

3. Set Dimensions

Use a standard viewport such as 1024x768, 480x800, or 1024xfull.

4. Choose Format

Use JPG for small files or PNG when sharper UI quality is needed.

5. Set Delay

Use at least 2000 ms for heavy or dynamic pages.

6. Handle Popups

Use click selector or hide selectors for cookie banners, ads, or modals when appropriate.

7. Use Full Page or Crop

Use full page for long content or crop for a precise section.

8. Set Language and Cookies if Needed

Use Accept-Language, User-Agent, or Cookies to reproduce a specific state.

9. Review Preview

Confirm that the screenshot captured the correct content.

10. Save Evidence Securely

Store screenshots and settings together when used for investigations or reports.

🛡️ Security, Privacy & Responsible Use

WebSite Screenshot is intended for lawful web capture, documentation, OSINT, QA, compliance, support, and cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX WebSite Screenshot is a flexible screenshot capture and device emulation tool for public web pages. It supports desktop, phone, and tablet rendering, custom viewport dimensions, full-page capture, element capture, crop regions, delay, zoom, cache control, selector-based clicking, selector hiding, custom language, user-agent, cookies, screenshot preview, local history, and plan-based query limits.

The tool is designed for OSINT evidence collection, phishing investigation, SOC workflows, brand protection, QA testing, compliance documentation, support cases, and web archive snapshots. Screenshots should be treated as point-in-time visual evidence and interpreted together with the capture settings, timestamp, URL, and supporting technical data.

Website and Host Analysis

Website to PDF | Webpage PDF Conversion Tool

image.png

The platform available at https://dash.niamonx.io/web_topdf — known as Website to PDF — is a webpage-to-PDF conversion tool within the NiamonX platform. It allows users to convert public webpages into PDF documents with configurable paper size, orientation, rendering media mode, delay, scale, background rendering, cookies, language headers, custom user-agent, click selectors, and hidden elements.

Overview of the Service

Website to PDF is designed to help users convert public web pages into structured PDF files for documentation, investigation, evidence preservation, compliance review, QA testing, reporting, archiving, and sharing.

The tool loads a target webpage in a controlled rendering environment and exports it as a PDF document based on the selected conversion settings. Users can choose paper layout, orientation, screen or print rendering mode, background rendering, delay, scale, and several advanced options that help reproduce a specific page state.

Website to PDF is useful for OSINT analysts, SOC teams, cybersecurity investigators, compliance departments, brand protection teams, support teams, legal reviewers, QA engineers, developers, researchers, and documentation teams.

The module is especially helpful when users need a portable, timestamped, shareable PDF representation of a website instead of a screenshot image.

🔍 How the Tool Works

When a user enters a website URL and selects conversion settings, Website to PDF loads the page, waits according to the configured delay, optionally performs selector-based actions, applies rendering options, and generates a PDF file.

The tool can convert:

Example conversion configuration:

Website URL: https://www.netflix.com/de-en/
Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 200 ms
Scale: 100%

Example result:

PDF
1.39 MB
Key: d7d63a63
17.06.2026, 22:38:39

🧩 What Can Be Converted

Website to PDF supports complete public website URLs.

Valid examples:

https://www.netflix.com/de-en/

https://niamonx.io/

https://help.ubuntu.ru/wiki/nginx-phpfpm

https://www.netacad.com

Unsupported or invalid examples:

netflix.com

www.netflix.com/de-en/

localhost

file:///C:/page.html

192.168.1.1

For best results, users should enter a complete URL with http:// or https://.

Private, local, internal, or restricted resources may not be accessible from the conversion backend unless they are publicly reachable and authorized for capture.

⚙️ Conversion Settings

The Conversion Settings panel contains the main PDF generation options.

Website URL

The full URL of the page to convert into PDF.

Example:

https://www.netflix.com/de-en/

The URL should include the protocol and should point to a webpage that can be loaded by the backend.

https://domain.com/path

The entered page should be publicly accessible or intentionally accessible through the provided authorized context, such as cookies.

Paper

The paper setting controls the target PDF page size.

Example:

Paper: A4

A4 is commonly used for reports, evidence exports, documentation, compliance archives, and printable records.

Common use cases for A4:

Depending on backend configuration, additional paper sizes may be supported. The current interface example uses A4.

Orientation

Orientation controls whether the PDF page is generated vertically or horizontally.

Available orientation modes include:

Example:

Orientation: Portrait

Portrait mode is usually best for articles, policy pages, documentation pages, legal pages, and standard website exports.

Landscape mode is useful for wide layouts, dashboards, tables, admin panels, pricing comparisons, or pages with horizontal UI elements.

Example:

Orientation: Landscape
Page Type Suggested Orientation
Article or blog post Portrait
Terms or privacy policy Portrait
Documentation page Portrait
Wide dashboard Landscape
Pricing table Landscape
Data table Landscape
Landing page Portrait or Landscape

Media

The media setting controls how the webpage is rendered before PDF generation.

Available media modes include:

Example:

Media: Screen

Screen mode captures the page as it would normally appear in a browser.

Print mode uses the website’s print stylesheet when available. This can produce cleaner, more document-like output for pages that support printer-friendly layouts.

Example:

Media: Print
Goal Suggested Media
Preserve visual browser appearance Screen
Create printer-friendly PDF Print
Capture marketing landing page Screen
Export documentation Print or Screen
Export policy or legal page Print
Capture phishing or scam page Screen
Remove unnecessary web UI naturally Print

Important note: Print mode may change the appearance of the page because many websites hide navigation menus, banners, sidebars, videos, ads, and interactive elements in their print stylesheet.

Include Background

The Include Background option controls whether backgrounds are rendered in the PDF.

Example:

Include background: Yes

When enabled, the PDF includes background colors, background images, section backgrounds, hero blocks, styled buttons, and other visual design elements.

When disabled, the PDF may look cleaner and more printer-friendly.

Example:

Include background: No
Goal Include Background
Visual evidence Yes
Brand impersonation documentation Yes
Phishing page capture Yes
Clean printing No
Text-focused review No
Smaller PDF size No
UI/UX documentation Yes

For evidence workflows, background rendering should usually stay enabled because it preserves the page’s visual appearance more accurately.

Delay

Delay controls how long the tool waits before generating the PDF.

Example:

Delay: 200 ms

Supported delay values may include:

0, 200, 400, ..., 10000

Delay is useful when pages need time to load dynamic content, animations, external resources, cookie banners, fonts, images, API data, or lazy-loaded sections.

Page Type Suggested Delay
Simple static page 0–400 ms
Normal website 1000–2000 ms
Dynamic landing page 2000–3000 ms
Heavy page with animations 3000–5000 ms
Complex dashboard 3000–10000 ms
Page with cookie banner 1000–3000 ms
Page with lazy-loaded content 2000–5000 ms
Evidence capture 2000 ms or more

Example for a heavier page:

Delay: 2000 ms

A longer delay can improve completeness, but it may also increase processing time and resource usage.

Scale

Scale controls the rendering size of the webpage content inside the PDF.

Example:

Scale: 100%

Scale can be used to fit more content on each page or make content larger and easier to read.

Examples:

Scale: 80%

Scale: 100%

Scale: 120%
Goal Suggested Scale
Default PDF export 100%
Fit more content per page 70–90%
Improve readability 110–125%
Capture wide layout on A4 70–90%
Preserve normal browser feel 100%

Scale affects layout, pagination, text size, and the number of PDF pages.

🧠 Advanced Options

The Advanced section allows more controlled webpage conversion.

Click Selector

The Click Selector option clicks a specific element before PDF generation.

Example:

.cookie-accept

#close

Use cases:

Example:

Click selector: .cookie-accept

This option is useful when a page blocks content with a banner or modal that can be handled with one simple click.

For evidence workflows, users should document the clicked selector because it changes the visible state of the page.

Hide Selectors

Hide Selectors allows users to hide unwanted elements before converting the page to PDF.

Example:

.ads, .cookie, #modal

Use cases:

Common selectors:

.ads
.cookie
#modal
.newsletter
.chat-widget
.sticky-header

Example:

Hide selectors: .ads, .cookie, #modal

Users should use this option carefully when creating evidence. If elements were hidden, the report should mention it so the PDF remains transparent and reproducible.

Cookies

Cookies can be passed to the webpage before conversion.

Format:

name1=value1;name2=value2

Example:

region=de;consent=yes

Use cases:

Important security note: Users should not paste sensitive session cookies unless they are authorized and fully understand the risk. Session cookies can provide access to accounts or private data.

For sensitive investigations, cookies should be handled as confidential data.

Accept-Language

Accept-Language controls the language preference sent with the webpage request.

Example:

Accept-Language: en-US

Other examples:

de-DE

uk-UA

ru-RU

This is useful when websites show different content depending on language settings.

Use cases:

Example:

Accept-Language: de-DE

User-Agent

The User-Agent field allows custom browser identification during conversion.

Example:

Mozilla/5.0 (...)

Use cases:

Custom user-agent should be used responsibly and documented when the PDF is used as evidence.

📄 Result Section

After a successful conversion, the Result panel displays PDF output details.

Typical fields include:

Field Description
File size Size of the generated PDF
Key Cache or result identifier
Timestamp Date and time of PDF generation
Output Generated PDF document

Example:

1.39 MB
Key d7d63a63
17.06.2026, 22:38:39

The result allows users to confirm that the conversion was completed and that the generated PDF is available for review, download, sharing, or reporting.

PDF file size depends on:

🕓 Local History

Website to PDF stores recent conversion requests locally in the user’s browser.

Example behavior:

Stores last 100 queries in your browser.

History entries may include:

Example history item:

https://www.netflix.com/de-en/
A4
PORTRAIT
SCREEN
17.06.2026, 22:38:39

Another example:

https://www.netacad.com
A4
PORTRAIT
PRINT
12.10.2025, 23:12:38

Local history helps users repeat previous conversions with the same or similar settings.

Because history is stored locally, it may be cleared when users delete browser data, change browsers, use a different device, or switch browser profiles.

On shared devices, users should treat conversion history as sensitive and clear it when URLs contain confidential, investigative, legal, or internal context.

🚦 Query Limits and Plan Access

Website to PDF uses plan-based query limits.

Example:

179 / 180
Queries remaining / total
Plan: Sentinel

Important points:

Users should monitor remaining queries when converting multiple pages for reports, investigations, evidence packages, compliance reviews, or bulk documentation.

🧠 Key Features

Webpage to PDF Conversion

Converts public webpages into portable PDF documents.

Paper Configuration

Supports paper-based PDF output such as A4.

Orientation Control

Allows Portrait or Landscape PDF layout.

Media Rendering

Supports Screen and Print media rendering modes.

Background Rendering

Can include or exclude webpage backgrounds.

Delay Control

Waits before conversion to allow dynamic content to load.

Scale Control

Adjusts webpage rendering size inside the PDF.

Selector Interaction

Can click a selected element before conversion.

Hide Selectors

Can hide unwanted page elements before PDF generation.

Allows cookie-based page state reproduction.

Language Header Control

Supports Accept-Language customization.

User-Agent Control

Allows custom browser identification.

Result Metadata

Displays PDF size, result key, and timestamp.

Local History

Stores the last 100 conversion requests in the browser.

Plan-Based Limits

Access and query volume depend on the user’s plan.

🔎 Common Use Cases

Website to PDF supports many practical workflows.

OSINT Evidence Export

Convert public webpages into PDF documents for investigation notes and reports.

Phishing Page Documentation

Export suspicious login pages, clone pages, scam pages, or malicious landing pages as PDF evidence.

Brand Protection

Document fake websites, impersonation pages, counterfeit stores, unauthorized brand use, or misleading public pages.

SOC and Incident Response

Attach PDF evidence to incident tickets, case management systems, internal reports, or escalation workflows.

Compliance Review

Export terms, privacy policies, cookie notices, public disclosures, regulatory pages, or public-facing statements.

Create PDF records of public webpages for legal review, audit trails, or compliance archives.

QA and Web Testing

Check how pages render in screen or print mode and preserve output for bug reports.

Documentation Archiving

Convert technical documentation, help pages, guides, or knowledge base pages into PDF files.

Support Cases

Attach converted web pages to support tickets for easier review.

Research and Reporting

Save public articles, pages, and references as stable PDF documents for later analysis.

Printer-Friendly Output

Use print media and background control to create clean, readable PDF files.

📐 Paper, Orientation, and Media Recommendations

The best settings depend on the target page and intended use.

Standard Webpage Export

Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 1000–2000 ms
Scale: 100%

Best for:

Clean Printable PDF

Paper: A4
Orientation: Portrait
Media: Print
Include background: No
Delay: 1000–2000 ms
Scale: 100%

Best for:

Wide Layout or Table Export

Paper: A4
Orientation: Landscape
Media: Screen
Include background: Yes
Delay: 2000 ms
Scale: 80–90%

Best for:

Heavy Dynamic Page

Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 3000–5000 ms
Scale: 100%

Best for:

Evidence Collection

Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 2000 ms or higher
Scale: 100%

URL
Timestamp
Paper size
Orientation
Media mode
Delay
Scale
Background setting
Click selector
Hide selectors
Cookies used
Accept-Language
User-Agent
Result key

For investigation work, PDF output should be stored together with conversion settings and supporting technical evidence.

🖨️ Screen Media vs Print Media

Website to PDF supports two major rendering modes: Screen and Print.

Screen Media

Screen media renders the webpage as it appears in a normal browser.

Best for:

Example:

Media: Screen

Screen mode is usually the best choice when visual appearance matters.

Print Media

Print media uses the website’s print stylesheet if available.

Best for:

Example:

Media: Print

Print mode may remove or change:

Print mode can produce cleaner output, but it may not reflect what a normal user saw in the browser.

🧹 Cleaning the Page Before Conversion

Some websites display banners, overlays, popups, ads, or chat widgets that interfere with PDF output.

Website to PDF provides two main cleanup options:

Click Selector

Use Click Selector when an element needs to be clicked before conversion.

Example:

.cookie-accept

Common uses:

Hide Selectors

Use Hide Selectors when elements should be visually removed before conversion.

Example:

.ads, .cookie, #modal

Common elements to hide:

For evidence and compliance workflows, users should document all cleanup actions.

Example documentation note:

Before PDF generation, the selector .cookie-accept was clicked and .ads, #modal were hidden.

🌍 Language, Region, and Session Context

Webpages may show different content depending on language, region, cookies, browser type, or session context.

Website to PDF provides controls for:

Examples:

Accept-Language: en-US

Accept-Language: de-DE

Cookies: region=de;consent=yes

User-Agent: Mozilla/5.0 (...)

These settings help reproduce a more specific page state.

Use cases:

Important note: A PDF created with custom cookies, language, or user-agent reflects that specific request context, not necessarily the default version of the website.

📊 Result Interpretation

PDF output should be interpreted carefully.

Important notes:

For investigations, PDF evidence should be combined with:

A practical Website to PDF workflow should follow these steps.

1. Enter the Full Website URL

Use a complete URL with protocol.

Example:

https://www.netflix.com/de-en/

Avoid incomplete URLs such as:

www.netflix.com/de-en/

2. Select Paper Size

Use A4 for standard reports, documentation, and printable PDF output.

Example:

Paper: A4

3. Choose Orientation

Use Portrait for normal pages and Landscape for wide layouts.

Example:

Orientation: Portrait

4. Choose Media Mode

Use Screen for visual accuracy and Print for printer-friendly output.

Example:

Media: Screen

5. Decide Whether to Include Background

Use background enabled for visual evidence.

Example:

Include background: Yes

Use background disabled for clean printing.

Example:

Include background: No

6. Set Delay

Use a short delay for simple pages and a longer delay for dynamic pages.

Example:

Delay: 2000 ms

7. Set Scale

Start with 100%. Reduce scale if content is too large or too wide.

Example:

Scale: 100%

8. Handle Popups or Cookie Banners

Use Click Selector or Hide Selectors when needed.

Example:

Click selector: .cookie-accept

Example:

Hide selectors: .ads, .cookie, #modal

9. Add Language, User-Agent, or Cookies if Needed

Use advanced settings to reproduce a specific context.

Example:

Accept-Language: de-DE
Cookies: region=de;consent=yes

10. Generate and Review the PDF

Check the result size, key, timestamp, and output.

Example:

1.39 MB
Key d7d63a63
17.06.2026, 22:38:39

11. Store the PDF With Context

For professional workflows, store the PDF together with the conversion settings.

URL: https://www.netflix.com/de-en/
Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 200 ms
Scale: 100%
Result key: d7d63a63
Timestamp: 17.06.2026, 22:38:39

🛡️ Security, Privacy & Responsible Use

Website to PDF is intended for lawful webpage conversion, documentation, OSINT, QA, compliance, support, cybersecurity, and evidence workflows.

Acceptable use cases include:

Users should follow responsible use principles:

Sensitive cookies, private URLs, authentication tokens, and internal resources must be handled carefully.

⚙️ Technical Highlights

📌 Usage Hints

🧾 Example Configurations

Basic PDF Export

Website URL: https://niamonx.io
Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 200 ms
Scale: 100%

Best for normal visual webpage export.

Printer-Friendly Export

Website URL: https://www.netacad.com
Paper: A4
Orientation: Portrait
Media: Print
Include background: No
Delay: 1000 ms
Scale: 100%

Best for clean reading and printing.

Investigation Evidence Export

Website URL: https://www.netflix.com/de-en/
Paper: A4
Orientation: Portrait
Media: Screen
Include background: Yes
Delay: 2000 ms
Scale: 100%
Click selector: .cookie-accept
Hide selectors: .ads, #modal
Accept-Language: de-DE

Best for documenting a specific visual page state.

Wide Page Export

Website URL: https://example.com/dashboard
Paper: A4
Orientation: Landscape
Media: Screen
Include background: Yes
Delay: 2000 ms
Scale: 80%

Best for dashboards, tables, and wide layouts.

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Website to PDF is a flexible webpage PDF conversion tool for public websites. It supports paper configuration, Portrait and Landscape orientation, Screen and Print rendering modes, background control, delay, scale, selector-based clicking, selector hiding, cookies, Accept-Language, custom User-Agent, result metadata, local history, and plan-based limits.

The tool is designed for OSINT evidence export, phishing investigation, SOC workflows, brand protection, QA testing, compliance documentation, support cases, legal review, research, and web archiving. Generated PDFs should be treated as point-in-time webpage records and interpreted together with the exact URL, timestamp, conversion settings, result key, and supporting technical evidence.

Website and Host Analysis

IP WHOIS | RDAP / WHOIS IP Intelligence Tool

image.png

The platform available at https://dash.niamonx.io/ip_whois — known as IP WHOIS — is an IP intelligence and registration lookup tool within the NiamonX platform. It allows users to search RDAP / WHOIS information for IPv4 and IPv6 addresses, including network ranges, CIDR blocks, IP version, country, network name, allocation type, registration status, events, notices, remarks, related entities, contacts, abuse contacts, administrative contacts, technical contacts, RDAP links, and raw JSON data.

Overview of the Service

IP WHOIS is designed to help users investigate the public registration and network ownership information associated with an IP address. The tool retrieves structured RDAP / WHOIS data and presents it in an analyst-friendly interface.

It is useful for cybersecurity investigations, OSINT research, incident response, SOC triage, abuse reporting, infrastructure mapping, network ownership checks, threat intelligence enrichment, compliance review, and technical due diligence.

Instead of manually querying multiple WHOIS or RDAP endpoints, users can enter a single IP address and receive a structured summary of the network, related objects, contacts, events, statuses, and remarks.

The tool is especially helpful when users need to answer questions such as:

🔍 How the Tool Works

When a user enters an IPv4 or IPv6 address, IP WHOIS validates the input and performs an RDAP / WHOIS lookup. The result is parsed and displayed in multiple structured sections.

Example query:

IP Address: 1.1.1.1

Example result summary:

Range: 1.1.1.0 - 1.1.1.255
CIDR: 1.1.1.0/24
Name: APNIC-LABS
Type: ASSIGNED PORTABLE
Country: AU
IP Version: v4
Objects: 3

The tool may display:

🧩 Supported Input

IP WHOIS supports direct lookup of IP addresses only.

Supported input types:

Valid examples:

1.1.1.1

8.8.8.8

2606:4700:4700::1111

2001:4860:4860::8888

Unsupported examples:

example.com

https://1.1.1.1

1.1.1.1/24

cloudflare.com

localhost

999.999.999.999

Important validation rule:

Only IPv4 or IPv6.

The tool is not intended for domain WHOIS lookups. Domain names, URLs, hostnames, and CIDR ranges should be checked with other dedicated tools.

📊 Summary Section

The Summary section provides a compact overview of the IP lookup result.

Example:

1.1.1.0 - 1.1.1.255
ASN —
CIDR 1.1.1.0/24
Entities: 0
22:42:09

Typical fields include:

Field Description
Range The IP range containing the queried address
ASN Autonomous System Number, if available
CIDR Network block in CIDR notation
Entities Number of related objects or contacts
Time Lookup or display time

The Summary section is useful for quick triage. It allows analysts to understand the basic network assignment without opening the full raw response.

🧾 Query Details

The Query section displays the main lookup data returned for the IP address and associated network.

Example:

Query: 1.1.1.0 - 1.1.1.255
ASN: —
ASN CIDR: —
ASN CC: —
ASN Registry: —
ASN Date: —
ASN Description: —
Entities Count: 0
Network CIDR: 1.1.1.0/24
Start: 1.1.1.0
End: 1.1.1.255
IP Version: v4

This section helps users separate the queried IP from the larger network block it belongs to.

🌐 Network Information

The network block describes the IP allocation or assignment returned by RDAP / WHOIS.

Example:

Name: APNIC-LABS
Type: ASSIGNED PORTABLE
Network: ASSIGNED PORTABLE
Handle: 1.1.1.0 - 1.1.1.255
Parent: -
CIDR: 1.1.1.0/24
Start: 1.1.1.0
End: 1.1.1.255
Version: v4
Country: AU

Name

The network name identifies the registered network object.

Example:

APNIC-LABS

The name may represent a registry project, organization, network allocation, ISP block, cloud provider range, hosting provider range, enterprise network, research prefix, or another registered resource.

Type

The type field describes the allocation or assignment category.

Example:

ASSIGNED PORTABLE

Common type values may include:

The exact values depend on the registry and RDAP source.

Handle

The handle is the identifier of the network object.

Example:

1.1.1.0 - 1.1.1.255

In some registries, the handle may be a textual object ID. In other cases, it may resemble the network range itself.

Parent

The parent field shows the parent network object if one is available.

Example:

Parent: -

A missing parent value does not necessarily mean that no broader allocation exists. It may simply mean that the source did not expose parent information in the returned object.

CIDR

CIDR shows the network prefix that contains the queried IP address.

Example:

1.1.1.0/24

CIDR is useful for:

Start and End

Start and End define the first and last IP addresses in the returned network range.

Example:

Start: 1.1.1.0
End: 1.1.1.255

This helps users understand whether a suspicious IP belongs to a small network, a large provider allocation, a cloud range, or a specific assigned block.

IP Version

The version field identifies whether the network is IPv4 or IPv6.

Example:

Version: v4

Possible values:

v4
v6

Country

The country field displays the country code associated with the network registration.

Example:

Country: AU

Important note: the country value in WHOIS / RDAP data does not always represent the physical location of the server. It may represent the registration country, registry region, organization address, or administrative contact location.

For accurate infrastructure geolocation, the country field should be compared with IP geolocation, routing data, ASN information, DNS records, latency, and other technical signals.

🛰️ ASN Information

ASN data describes the Autonomous System associated with an IP address, when available.

The tool may display:

Example:

ASN: AS13335
ASN CIDR: 1.1.1.0/24
ASN CC: AU
ASN Registry: APNIC
ASN Date: 2011-08-11
ASN Description: CLOUDFLARENET

In some responses, ASN fields may be unavailable.

Example:

ASN: —
ASN CIDR: —
ASN CC: —
ASN Registry: —
ASN Date: —
ASN Description: —

Missing ASN data does not always mean that the IP is not routed. It may mean that the selected RDAP / WHOIS response did not include ASN enrichment.

For complete routing analysis, ASN data should be verified with BGP, RPKI, route collectors, passive DNS, and external network intelligence sources.

Example:

https://rdap.apnic.net/entity/AIC3-AP

Interface hint:

Hover your cursor over the open link icon to open the link in a new tab.

📅 Events

Events describe registration-related actions associated with the network or contact objects.

Possible event types may include:

Example display:

Events:
action — -
action — -

Some RDAP responses contain complete event dates. Others may return incomplete or minimal event objects.

Events are useful for:

Important note: event availability depends on the source registry. Not every RDAP / WHOIS response includes complete event data.

✅ Status

The Status section shows the current state of the network object.

Example:

Status: active

Common statuses may include:

Status values depend on the registry and RDAP implementation.

A status such as active usually means the registration object is currently active in the registry database. It does not automatically mean that every IP inside the range is currently reachable, safe, or in use.

📌 Notices

Notices contain registry-provided informational messages, legal notices, terms of use, source information, or disclaimers.

Example:

Notices: No

If notices are present, they may include:

Users should review notices when using WHOIS / RDAP data in legal, compliance, or official reporting workflows.

📝 Remarks

Remarks contain additional registry-provided descriptions or notes about the network.

Example:

description:
APNIC and Cloudflare DNS Resolver project,
Routed globally by AS13335/Cloudflare,
Research prefix for APNIC Labs

remarks:
---------------
All Cloudflare abuse reporting can be done via
resolver-abuse@cloudflare.com
---------------

Remarks are often highly valuable because they may contain:

For investigations, remarks should be reviewed carefully. They may contain the correct abuse escalation channel even when the main contact object is generic.

👥 Objects and Contacts

The Objects section shows related RDAP entities such as organizations, abuse contacts, administrative contacts, technical contacts, NOC contacts, and registrants.

Example:

Objects: 3

Objects may include:

The tool supports searching and filtering objects by role.

Example:

Search...
Role: all

🧑‍💼 Example Contact Object

Example object:

AIC3-AP
APNICRANDNET Infrastructure Contact
Kind: group
Roles:
administrative
technical
E-mails:
research@apnic.net
Phones:
+61 7 3858 3100
Addresses:
6 Cordelia St South Brisbane QLD 4101
Links:
https://rdap.apnic.net/entity/AIC3-AP

A contact object may contain:

Field Description
Handle Unique entity identifier
Name Display name of the entity
Kind Entity type, such as group or org
Roles RDAP roles assigned to the entity
E-mails Contact e-mail addresses
Phones Listed phone numbers
Addresses Postal or office addresses
Links RDAP links for the entity
Status Entity status, if available
Events Entity registration or update events
Remarks Additional registry-provided notes

🏷️ RDAP Roles

Objects use standard RDAP role designations.

Common roles include:

Role Meaning
registrant Organization or entity associated with the registration
administrative Administrative contact
technical Technical contact
abuse Abuse reporting contact
noc Network Operations Center contact
billing Billing contact
registrar Registrar-related entity
reseller Reseller-related entity
sponsor Sponsoring organization

Example:

Roles:
administrative
technical

Another example:

Roles:
abuse

Roles are important for choosing the correct escalation path. For malicious activity, the abuse role is usually the most relevant contact type.

🚨 Abuse Contacts

Abuse contacts are used to report malicious, unauthorized, or harmful activity associated with an IP address or network.

Example:

IRT-APNICRANDNET-AU
Roles:
abuse
E-mails:
helpdesk@apnic.net

Abuse contacts may be used for reports related to:

Before sending an abuse report, users should collect supporting evidence such as timestamps, URLs, logs, packet captures, screenshots, HTTP headers, DNS data, and affected systems.

📤 Copy and Export Features

IP WHOIS supports data extraction features that help users move results into reports or external workflows.

Available actions may include:

These features are useful for:

📄 Export Contacts to CSV

The Export contacts to CSV function allows users to export aggregated contact information from the objects section.

The exported data may include:

This is useful when an investigation involves multiple entities and the analyst needs to preserve contact data in a structured format.

Example use cases:

🧬 Raw JSON

The Raw JSON view displays the original structured response returned by the RDAP / WHOIS source.

Raw JSON is useful for:

When accuracy matters, users should compare the visual UI fields with the raw JSON response.

🕓 Local IP History

IP WHOIS stores recent IP lookups locally in the browser.

Example interface section:

IP History
Filter...

History helps users:

Since the history is stored locally, it may be removed when browser data is cleared. It may also not sync between devices or browser profiles.

Security recommendation: clear local history on shared or untrusted devices when investigating sensitive IPs, customer incidents, or confidential infrastructure.

🔎 Common Use Cases

IP WHOIS supports many practical cybersecurity and OSINT workflows.

IP Ownership Investigation

Identify the registered network, organization, allocation type, and contact objects associated with an IP address.

SOC Alert Triage

Enrich suspicious IP addresses from alerts, logs, firewall events, EDR detections, IDS events, or SIEM correlations.

Abuse Reporting

Find abuse contacts and supporting registration details for reporting malicious activity.

Phishing Infrastructure Analysis

Investigate IP addresses hosting phishing pages, fake login portals, clone websites, or malicious redirects.

Malware Infrastructure Review

Check IP addresses linked to malware delivery, command-and-control servers, botnets, or payload hosting.

Brand Protection

Identify infrastructure behind impersonation websites, fake stores, unauthorized brand pages, or fraudulent campaigns.

Network Troubleshooting

Check which network block an IP belongs to and review registration details.

Threat Intelligence Enrichment

Add WHOIS / RDAP context to indicators of compromise.

Compliance and Audit

Preserve registration data for investigation files, audit trails, incident documentation, or legal review.

OSINT Research

Map public infrastructure, investigate hosting providers, and identify related contact entities.

🧠 Practical Investigation Workflow

1. Enter a Valid IP Address

Use only IPv4 or IPv6.

Example:

1.1.1.1

Avoid domains, URLs, hostnames, and CIDR input.

2. Review the Summary

Check the returned range, CIDR, ASN, entity count, and lookup time.

Example:

Range: 1.1.1.0 - 1.1.1.255
CIDR: 1.1.1.0/24
Entities: 3

3. Review Network Details

Check the network name, allocation type, country, start IP, end IP, version, and handle.

Example:

Name: APNIC-LABS
Type: ASSIGNED PORTABLE
Country: AU
Version: v4

4. Check ASN Information

Example:

ASN Description: description of the autonomous system.

If ASN data is missing, verify routing information using additional BGP or ASN lookup tools.

5. Review Status and Events

Check whether the network is active and whether registration or update events are available.

Example:

Network Status: active

Events can support timeline analysis and help identify recent changes.

6. Inspect Remarks

Read remarks carefully because they may contain special instructions, abuse reporting information, routing notes, or project descriptions.

Example:

All Cloudflare abuse reporting can be done via resolver-abuse@cloudflare.com

7. Inspect Objects and Roles

Important roles:

abuse
administrative
technical
registrant
noc

For reporting malicious activity, prioritize abuse contacts.

8. Copy or Export Data

Use copy and export features to preserve results.

IP address
Network range
CIDR
Network name
Country
ASN data
Status
Events
Remarks
Contact objects
Abuse e-mails
Raw JSON
Lookup timestamp

9. Validate With Additional Evidence

For professional investigations, combine IP WHOIS data with:

WHOIS / RDAP data is only one part of the investigation.

📌 Field Interpretation Guide

ASN Description

The ASN Description field describes the autonomous system, when available.

Example meaning:

Description of the autonomous system.

This may identify an ISP, cloud provider, hosting provider, enterprise network, CDN, or other routing organization.

Network Status

Network Status shows the current status values associated with the network object.

Example:

active

Status values can indicate whether the object is active, allocated, assigned, reserved, or otherwise marked by the registry.

Events

Events show registration and change-related dates when the source provides them.

Possible examples:

registration
last changed
last updated

Events are useful for understanding when the object was created or modified.

Objects

Objects represent entities connected to the network.

Examples:

org
abuse
admin
technical
noc
registrant

Objects follow standard RDAP role designations and may contain names, e-mails, phones, addresses, links, statuses, events, and remarks.

⚠️ Limitations and Important Notes

WHOIS / RDAP data should be interpreted carefully.

Important limitations:

In case of a server-side 500 error, repeat the request.

Example note:

In case of a 500 error on the server side, please repeat your request.

🛡️ Security, Privacy & Responsible Use

IP WHOIS is intended for lawful cybersecurity, OSINT, compliance, reporting, infrastructure analysis, and network investigation workflows.

Acceptable use cases include:

Users should follow responsible use principles:

WHOIS / RDAP data can support investigations, but it should not be used alone to accuse an organization or individual of malicious activity.

🧾 Recommended Abuse Report Context

When using IP WHOIS to prepare an abuse report, include enough evidence for the receiving team to understand and verify the issue.

Source IP: 1.1.1.1
Observed activity: phishing / malware / scanning / spam / abuse
Timestamp with timezone: 17.06.2026, 22:42:09
Affected system or URL: relevant target
Evidence: logs, screenshots, headers, URLs, samples
WHOIS range: 1.1.1.0 - 1.1.1.255
CIDR: 1.1.1.0/24
Network name: APNIC-LABS
Abuse contact: listed abuse e-mail
Additional notes: analyst summary

A high-quality abuse report should be factual, concise, and evidence-based.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX IP WHOIS is an RDAP / WHOIS lookup tool for IPv4 and IPv6 addresses. It provides structured IP registration intelligence, including network range, CIDR, start and end IP, IP version, network name, allocation type, country, ASN fields, status, events, notices, remarks, RDAP links, related objects, contacts, e-mails, phone numbers, addresses, raw JSON, local history, copy options, and CSV export.

The tool is designed for OSINT research, SOC workflows, incident response, abuse reporting, phishing investigations, malware infrastructure analysis, brand protection, compliance documentation, network troubleshooting, and threat intelligence enrichment. Results should be interpreted as public registration context and combined with additional technical evidence before making conclusions about ownership, infrastructure usage, or attribution.

Website and Host Analysis

Subdomains Extended | Subdomain Discovery & DNS Inventory Tool

image.png

The platform available at https://dash.niamonx.io/subdomains_extended — known as Subdomains Extended — is a domain intelligence and DNS inventory tool within the NiamonX platform. It discovers subdomains for a target domain, resolves DNS records, and presents a clear technical inventory for each discovered hostname.

The tool helps users identify exposed subdomains, review DNS configuration, map public infrastructure, detect forgotten assets, verify mail and security-related records, and support OSINT, SOC, incident response, compliance, and attack surface management workflows.

Overview of the Service

Subdomains Extended is designed to perform a more detailed subdomain audit than a basic subdomain list. Instead of only returning discovered hostnames, it enriches each subdomain with DNS resolution data.

For every discovered subdomain, the tool may show:

This makes the module useful not only for discovery, but also for understanding how each subdomain is connected to infrastructure, cloud services, mail systems, verification records, third-party services, CDN providers, and DNS delegation.

The tool is useful for:

🔍 How the Tool Works

When a user enters a domain and starts an audit, Subdomains Extended searches for known or discoverable subdomains and resolves DNS records for each result.

Example audit input:

Domain: niamonx.io

Example summary result:

Domain: niamonx.io
Total: 2
17.06.2026, 22:45:18

Example discovered subdomains:

_dmarc.niamonx.io
poreva.niamonx.io

Example resolved DNS data:

poreva.niamonx.io
IPv4:
172.67.153.184
104.21.12.231

IPv6:
2606:4700:3030::ac43:99b8
2606:4700:3033::6815:ce7

The system performs a thorough audit and may require time to collect, resolve, and organize results.

Example interface note:

The system performs a thorough audit; please wait while results are collected and resolved.

🧩 What Can Be Audited

Subdomains Extended accepts a root domain as input.

Valid examples:

niamonx.io

example.com

company.org

security.example.net

Unsupported or invalid examples:

https://niamonx.io

http://example.com/page

192.168.1.1

user@example.com

localhost

*.example.com

domain.tld

Users should enter only the domain name, without protocol, path, wildcard prefix, query parameters, or URL fragments.

⚙️ Main Audit Function

Run Subdomain Audit

The main action starts the subdomain discovery and DNS resolution process.

Example:

Run Subdomain Audit
Domain: niamonx.io

After running the audit, the tool returns a summary and a structured table of discovered subdomains with DNS records.

The audit may include:

🚦 Plan Limits and Usage

Subdomains Extended uses plan-based query limits.

Example:

Plan: Sentinel
Used: 1 / 60
Remaining: 59

Important points:

Users should monitor remaining queries when auditing multiple domains, customer assets, investigation targets, or large infrastructure footprints.

📊 Summary Section

The Summary section provides a compact overview of the audit result.

Example:

Domain: niamonx.io
Total: 2
17.06.2026, 22:45:18

Typical fields include:

Field Description
Domain The audited root domain
Total Number of discovered subdomains
Timestamp Date and time when the audit was completed

The Summary section is useful for quick reporting and audit comparison. It allows users to see how many subdomains were discovered at a specific point in time.

📋 Subdomain Results Table

The Subdomain Results table displays discovered hostnames and their resolved DNS records.

Example table columns:

Column Description
Subdomain Discovered hostname
IPv4 A records resolved for the hostname
IPv6 AAAA records resolved for the hostname
CNAME Canonical name target
MX Mail exchanger records
TXT Text records
NS Name server records

Example result:

Subdomain: _dmarc.niamonx.io
IPv4: —
IPv6: —
CNAME: —
MX: —
TXT: v=DMARC1; p=none;
NS: —

Another example:

Subdomain: poreva.niamonx.io
IPv4:
172.67.153.184
104.21.12.231

IPv6:
2606:4700:3030::ac43:99b8
2606:4700:3033::6815:ce7

CNAME: —
MX: —
TXT: —
NS: —

If a record type is not available, the interface displays:

—

This means that no value was returned for that specific DNS record type during the audit.

🔎 Result Pagination

For domains with many discovered subdomains, results may be paginated.

Example:

Page 1 of 1
Showing 1–2 of 2

Pagination helps keep the interface readable when auditing larger domains.

Possible pagination information includes:

For large domains, users should review all pages to avoid missing important records.

🧾 Details Panel

The Details panel shows a focused view of one selected subdomain.

Example:

Details
Subdomain: poreva.niamonx.io
IPv4:
172.67.153.184
104.21.12.231
IPv6:
2606:4700:3030::ac43:99b8
2606:4700:3033::6815:ce7
CNAME: —
MX: —
TXT: —
NS: —

The Details panel is useful when a subdomain has many records or when the user needs to copy, inspect, or document a specific hostname.

🌐 Hostname

The Hostname field shows the discovered subdomain.

Example:

poreva.niamonx.io

Hostnames may represent:

Subdomain discovery is useful because organizations often expose services across many hostnames that are not visible from the main website.

🌍 IPv4 Records

IPv4 records show A records resolved for the subdomain.

Example:

172.67.153.184
104.21.12.231

IPv4 results help identify:

A subdomain can resolve to one IPv4 address or multiple IPv4 addresses. Multiple addresses may indicate load balancing, CDN usage, high availability, or provider-managed routing.

🌐 IPv6 Records

IPv6 records show AAAA records resolved for the subdomain.

Example:

2606:4700:3030::ac43:99b8
2606:4700:3033::6815:ce7

IPv6 results help users identify modern dual-stack infrastructure.

IPv6 records are important because:

Security teams should review both IPv4 and IPv6 records when assessing exposure.

🔁 CNAME Records

CNAME records show canonical name targets for a subdomain.

Example:

CNAME: app.example.hosting-provider.com

CNAME records are useful for identifying:

A missing CNAME is displayed as:

CNAME: —

Important security note: abandoned or misconfigured CNAME records may sometimes indicate potential subdomain takeover risk, especially when pointing to a third-party service that is no longer configured. Such findings should be validated carefully and responsibly.

📬 MX Records

MX records show mail exchangers associated with a subdomain.

Example:

MX: mail.example.com

MX records are useful for:

A missing MX record is displayed as:

MX: —

For most normal application subdomains, MX records may be absent. This is expected.

🧾 TXT Records

TXT records show text-based DNS records associated with a subdomain.

Example:

v=DMARC1; p=none;

TXT records may contain:

Example discovered record:

Subdomain: _dmarc.niamonx.io
TXT: v=DMARC1; p=none;

TXT records are especially important for e-mail security and domain ownership verification.

Security teams should review TXT records for:

🛡️ DMARC Records

Subdomains Extended may discover DMARC-related records such as _dmarc.domain.tld.

Example:

_dmarc.niamonx.io
TXT: v=DMARC1; p=none;

DMARC records are used to define domain-level e-mail authentication policy.

A DMARC value such as:

v=DMARC1; p=none;

means that DMARC is present, but the policy is monitoring-only. It does not instruct receivers to quarantine or reject failing messages.

Common DMARC policies include:

Policy Meaning
p=none Monitor only
p=quarantine Treat failing mail as suspicious
p=reject Reject failing mail

For stronger protection against spoofing, organizations often move from p=none to p=quarantine or p=reject after monitoring and validation.

🧭 NS Records

NS records show name servers associated with a subdomain or delegated zone.

Example:

NS: ns1.example.net

NS records are useful for:

A missing NS record is displayed as:

NS: —

Delegated subdomains are important during security reviews because they may be managed separately from the main domain and may have different access controls, owners, or providers.

📚 Examples Section

The tool includes examples that can prefill the audit form.

Example interface note:

Examples
Click to prefill the form, then run the audit.

Examples help users quickly understand the correct input format and run a test audit without manually typing a domain.

🕓 Local History

Subdomains Extended stores recent audits locally in the user’s browser.

Example:

History (local)
Filter
Stored only in your browser (last 50 audits).

Example history item:

niamonx.io
Total: 2
17.06.2026, 22:45:18

Local history helps users:

Because history is stored only in the browser, it may be removed when browser data is cleared, a different browser profile is used, or the user switches devices.

On shared or untrusted devices, users should treat local history as sensitive and clear it after investigating confidential domains, client assets, or incident-related infrastructure.

🔐 Why Subdomain Discovery Matters

Subdomains are often part of an organization’s public attack surface. Even when the main website is secure, exposed subdomains may reveal additional systems, legacy applications, development environments, staging panels, APIs, authentication portals, cloud services, or forgotten infrastructure.

Subdomain discovery helps identify:

A complete subdomain inventory is an important foundation for attack surface management and defensive security.

🔎 Common Use Cases

Attack Surface Inventory

Create a list of public-facing subdomains and their DNS records to understand the visible infrastructure of a domain.

OSINT Research

Map publicly discoverable domain infrastructure during open-source intelligence investigations.

SOC Triage

Enrich alerts involving suspicious hostnames, unknown subdomains, or unusual DNS activity.

Incident Response

Check whether a suspicious subdomain is part of an organization’s known infrastructure.

Brand Protection

Identify suspicious, forgotten, or unexpected subdomains that may be used in impersonation, phishing, or brand abuse investigations.

Subdomain Takeover Review

Review CNAME records that point to third-party services and verify whether they are still properly configured.

DNS Security Audit

Inspect DNS records, including TXT, MX, NS, IPv4, and IPv6 records, for misconfigurations or unexpected exposure.

E-mail Security Review

Find DMARC, SPF, DKIM, MX, and TXT-related records that affect e-mail authentication and spoofing protection.

Cloud and CDN Mapping

Identify subdomains resolving to cloud providers, CDN endpoints, managed platforms, or external infrastructure.

Compliance Documentation

Create a record of public DNS exposure for compliance reviews, asset inventories, and audit documentation.

DevOps and Infrastructure Review

Help engineering teams identify public DNS entries and validate whether they match the intended infrastructure state.

🧠 Recommended Audit Workflow

A practical Subdomains Extended workflow should follow these steps.

1. Enter the Domain

Use only the domain name.

Example:

niamonx.io

Do not include:

https://
http://
/path
?query=value
#fragment
*

2. Run the Audit

Start the audit using the main action button.

Example:

Run Subdomain Audit

The tool will collect discovered subdomains and resolve their DNS records.

3. Review the Summary

Check the audited domain, total number of discovered subdomains, and timestamp.

Example:

Domain: niamonx.io
Total: 2
17.06.2026, 22:45:18

This gives a quick overview of the result set.

4. Review the Subdomain Table

Inspect each discovered hostname and its DNS records.

Important columns:

Subdomain
IPv4
IPv6
CNAME
MX
TXT
NS

Look for unexpected records, unknown hostnames, third-party dependencies, mail records, and delegated zones.

5. Open Details for Important Subdomains

Use the Details panel to inspect a selected subdomain more closely.

Example:

Subdomain: poreva.niamonx.io
IPv4:
172.67.153.184
104.21.12.231
IPv6:
2606:4700:3030::ac43:99b8
2606:4700:3033::6815:ce7

6. Review CNAME Records

CNAME records are especially important for third-party service mapping and takeover-risk review.

Questions to ask:

7. Review TXT Records

TXT records can reveal mail policies, verification records, and security configuration.

Important records to review:

DMARC
SPF
DKIM
domain verification
service ownership tokens

Example:

v=DMARC1; p=none;

8. Review MX Records

MX records should be checked to understand mail routing and possible subdomain-specific mail handling.

Questions to ask:

9. Review NS Records

NS records may indicate delegated subdomains.

Questions to ask:

10. Compare With Asset Inventory

Compare discovered results against the organization’s official asset list.

Focus on:

11. Save or Document Findings

For professional workflows, document important results with timestamp and context.

Domain: niamonx.io
Audit time: 17.06.2026, 22:45:18
Total subdomains: 2
Subdomain: poreva.niamonx.io
IPv4: 172.67.153.184, 104.21.12.231
IPv6: 2606:4700:3030::ac43:99b8, 2606:4700:3033::6815:ce7
CNAME: —
MX: —
TXT: —
NS: —

🚨 Security Review Checklist

When using Subdomains Extended for security auditing, review the following areas.

Unknown Subdomains

Check whether every discovered subdomain is known and authorized.

Questions:

Staging and Development Systems

Look for names such as:

dev
test
stage
staging
qa
uat
demo
internal
admin
panel
backup
old
legacy

Such systems are often less protected than production environments and may expose sensitive data or outdated software.

CNAME Takeover Indicators

Review CNAME targets pointing to third-party services.

Potential risk indicators:

Any suspected takeover risk should be validated safely and responsibly without exploiting the domain.

Mail Security Records

Review mail-related records:

MX
SPF
DKIM
DMARC

Potential issues:

IPv6 Exposure

Check whether services are exposed through IPv6.

Important questions:

IPv6 exposure is sometimes overlooked during security reviews.

Delegated DNS Zones

Review NS records for delegated subdomains.

Potential issues:

📊 Interpreting Results Correctly

Subdomain audit results should be interpreted carefully.

Important notes:

Subdomains Extended provides strong DNS inventory context, but conclusions should be validated with additional tools and evidence.

When documenting a subdomain audit, use a consistent format.

Example:

Domain: niamonx.io
Audit timestamp: 17.06.2026, 22:45:18
Total discovered subdomains: 2

Subdomain: _dmarc.niamonx.io
IPv4: —
IPv6: —
CNAME: —
MX: —
TXT: v=DMARC1; p=none;
NS: —

Subdomain: poreva.niamonx.io
IPv4: 172.67.153.184, 104.21.12.231
IPv6: 2606:4700:3030::ac43:99b8, 2606:4700:3033::6815:ce7
CNAME: —
MX: —
TXT: —
NS: —

For security reports, add analyst notes:

Finding: DMARC policy is set to p=none.
Impact: Monitoring-only policy does not instruct receivers to reject or quarantine failing messages.
Recommendation: Review DMARC reports and consider phased migration to p=quarantine or p=reject when ready.

🛡️ Security, Privacy & Responsible Use

Subdomains Extended is intended for lawful domain analysis, OSINT, cybersecurity, compliance, infrastructure review, and defensive security workflows.

Acceptable use cases include:

Users should follow responsible use principles:

Subdomain discovery is a legitimate defensive and OSINT technique, but it must be used responsibly.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Subdomains Extended is an extended subdomain discovery and DNS inventory tool for public domains. It discovers subdomains, resolves DNS records, and presents a structured view of hostnames, IPv4 addresses, IPv6 addresses, CNAME targets, MX records, TXT records, and NS records.

The tool is designed for OSINT research, attack surface management, SOC workflows, incident response, DNS security reviews, brand protection, compliance documentation, cloud and CDN mapping, e-mail security analysis, and infrastructure inventory. Results should be interpreted as point-in-time DNS intelligence and combined with additional technical evidence such as HTTP responses, TLS certificates, WHOIS data, ASN information, screenshots, passive DNS, and asset inventory records.

Website and Host Analysis

Subdomains Check | Subdomain Enumeration Tool

image.png

The platform available at https://dash.niamonx.io/subdomains_check — known as Subdomains Check — is a subdomain enumeration tool within the NiamonX platform. It helps users discover subdomains associated with a target domain by using internal services, archives, and available discovery sources. The tool returns a structured list of discovered hostnames and calculates useful metadata such as the main zone, subdomain depth, total number of subdomains, unique areas, and maximum depth.

Overview of the Service

Subdomains Check is designed to help users quickly enumerate known or discoverable subdomains for a domain. It provides a clean and focused inventory of hostnames without requiring the user to manually search archives, public datasets, or internal discovery sources.

The tool is useful for OSINT research, attack surface mapping, security audits, SOC workflows, incident response, brand protection, bug bounty reconnaissance, DNS inventory review, compliance checks, and infrastructure documentation.

Unlike tools that focus primarily on DNS resolution, Subdomains Check focuses on the discovery and organization of subdomain names. It helps users understand what hostnames exist or have been observed for a target domain and provides export options for further analysis.

The module is especially useful when users need to answer questions such as:

🔍 How the Tool Works

When a user enters a domain, Subdomains Check validates the input and performs enumeration through internal services and archives. The result is returned as a structured table of discovered subdomains.

Example input:

Domain: niamonx.io

Example result:

Domain: niamonx.io
Subdomains: 4
Unique Areas: 1
Maximum Depth: 3
22:49:02

Example discovered subdomains:

dash.niamonx.io
data-wells.niamonx.io
poreva.niamonx.io
support.niamonx.io

The tool calculates and displays:

🧩 Supported Input

Subdomains Check accepts domain names only.

Correct input examples:

niamonx.io

example.com

sub.example.com

company.org

Incorrect input examples:

https://niamonx.io

http://example.com

https://example.com/path

*.example.com

user@example.com

192.168.1.1

localhost

The interface guidance is:

Enter only the domain (example.com, sub.example.com) without the protocol.

Users should not include:

https://
http://
/path
?query=value
#fragment
*

domain.tld

⚙️ Main Function: Search and Check Subdomains

The main action performs subdomain enumeration for the entered domain.

Example:

Search and Check Subdomains
Domain: niamonx.io

After the query is processed, the tool returns a result summary and a searchable table of discovered hostnames.

The enumeration process may use:

This makes the tool useful for quickly building an initial subdomain inventory.

📊 Result Summary

The Result section provides a compact overview of the enumeration result.

Example:

Result
niamonx.io
Subdomains: 4
22:49:02

Detailed summary:

Domain: niamonx.io
Subdomains: 4
Unique Areas: 1
Maximum Depth: 3

Typical fields include:

Field Description
Domain The domain that was checked
Subdomains Total number of discovered subdomains
Unique Areas Number of unique main zones or grouped areas found in the result
Maximum Depth Highest hostname depth found among discovered subdomains
Time Time when the result was generated or displayed

The summary is useful for quick reporting and comparing enumeration results across multiple domains or repeated audits.

📋 Subdomain Results Table

The Subdomain Results table displays discovered hostnames and calculated metadata.

Example table:

# Subdomain Zone Depth
1 dash.niamonx.io niamonx.io 3
2 data-wells.niamonx.io niamonx.io 3
3 poreva.niamonx.io niamonx.io 3
4 support.niamonx.io niamonx.io 3

The table helps users quickly review discovered assets and understand their relationship to the main domain.

🌐 Subdomain Field

The Subdomain column shows the discovered hostname.

Example:

dash.niamonx.io

A subdomain may represent:

Subdomains are important because they often reveal additional public infrastructure that is not visible from the main website.

🧭 Zone Field

The Zone column shows the main domain or area associated with the discovered subdomain.

Example:

dash.niamonx.io → zone: niamonx.io

Another example:

api.dev.example.com → zone: example.com

The zone helps group discovered hostnames under their main domain.

This is useful when:

📏 Depth Field

The Depth column shows the number of levels in the hostname.

Example:

dash.niamonx.io → depth: 3

Explanation:

dash.niamonx.io
1: dash
2: niamonx
3: io
Depth: 3

Another example:

api.dev.example.com → zone: example.com, depth: 4

Explanation:

api.dev.example.com
1: api
2: dev
3: example
4: com
Depth: 4

Depth is useful for identifying deeply nested assets such as:

api.dev.example.com
login.internal.stage.example.com
cdn.assets.app.example.com

Deep hostnames may indicate development structures, environment separation, internal naming conventions, or complex infrastructure.

🔢 Unique Areas

The Unique Areas value shows how many unique zones or grouped domain areas are present in the result.

Example:

Unique Areas: 1

For a simple domain audit, this value is often 1, because all discovered subdomains belong to the same main domain.

This field becomes more useful when results include hostnames that may be grouped into different areas or zones.

Use cases:

📈 Maximum Depth

The Maximum Depth value shows the deepest hostname level found in the result set.

Example:

Maximum Depth: 3

If the tool discovers a deeply nested hostname such as:

api.dev.example.com

the maximum depth would be:

4

Maximum Depth helps users identify whether the domain has only simple subdomains or more complex nested infrastructure.

Higher depth may indicate:

🔎 Search and Filtering

The results table includes a search field for filtering discovered subdomains.

Example:

Search...

Search is useful when working with large result sets.

Users can search for terms such as:

api

dev

support

admin

stage

Search can help analysts quickly locate interesting or risky hostnames.

📄 Pagination

The table supports pagination for easier review of large result sets.

Example:

25 / page

Pagination helps users:

For complete analysis, users should review all result pages.

🕓 History of Domains

Subdomains Check stores entered domains locally in the browser history.

Example interface section:

History of Domains
Filter...

History helps users:

Because the history is local, it may be removed when browser data is cleared or when the user changes devices, browsers, or profiles.

On shared or untrusted devices, users should treat domain history as sensitive and clear it after investigating confidential, customer-related, or incident-related domains.

📤 Copy and Export Features

Subdomains Check supports several output actions for using results in reports or external tools.

Available actions may include:

These features are useful for:

📋 Copy List

The Copy list option allows users to copy discovered subdomains as a plain list.

Example output:

dash.niamonx.io
data-wells.niamonx.io
poreva.niamonx.io
support.niamonx.io

This is useful for:

🧬 Copy JSON and Raw JSON

The Copy JSON and Raw JSON options provide structured machine-readable data.

Raw JSON is useful for:

JSON output may include:

domain
subdomains
zone
depth
total
unique_areas
maximum_depth
timestamp

When accuracy matters, users should preserve the Raw JSON together with the visible table result.

📄 Export to CSV

The Export to CSV option allows users to download the subdomain table in a spreadsheet-friendly format.

The CSV may include:

Example CSV-style structure:

#,Subdomain,Zone,Depth
1,dash.niamonx.io,niamonx.io,3
2,data-wells.niamonx.io,niamonx.io,3
3,poreva.niamonx.io,niamonx.io,3
4,support.niamonx.io,niamonx.io,3

CSV export is useful for:

🔐 Why Subdomain Enumeration Matters

Subdomains are a critical part of an organization’s public attack surface. A company may secure its main website while leaving older, forgotten, or poorly maintained subdomains exposed.

Subdomain enumeration helps identify:

A complete subdomain inventory is often the first step in attack surface management and external security review.

🔎 Common Use Cases

Attack Surface Mapping

Build a list of known public subdomains for a domain and use it as the foundation for further DNS, HTTP, TLS, and security analysis.

OSINT Research

Discover publicly known hostnames connected to an organization, product, brand, or domain.

SOC Triage

Check whether a suspicious hostname belongs to a known domain and determine whether it should be investigated further.

Incident Response

Brand Protection

Find suspicious or unexpected subdomains that may be relevant to impersonation, phishing, fraud, or unauthorized use of brand infrastructure.

Bug Bounty Reconnaissance

Collect in-scope hostnames for authorized security testing and further technical validation.

Asset Inventory

Create or update an inventory of public-facing hostnames associated with an organization.

Compliance Review

Document known public subdomains as part of security audits, risk reviews, or infrastructure governance.

Shadow IT Detection

Identify hostnames that may belong to undocumented systems, old projects, unmanaged services, or unknown teams.

Follow-Up DNS Analysis

Use the discovered list as input for tools that resolve IPv4, IPv6, CNAME, MX, TXT, NS, HTTP, TLS, or screenshot data.

A practical Subdomains Check workflow should follow these steps.

1. Enter the Domain

Use only the domain name without protocol.

Example:

niamonx.io

Do not enter:

https://niamonx.io

2. Run the Enumeration

Start the search and wait for the result.

Example:

Search and Check Subdomains

The system will enumerate subdomains through internal services and archives.

3. Review the Result Summary

Check the domain, total number of subdomains, unique areas, maximum depth, and timestamp.

Example:

Domain: niamonx.io
Subdomains: 4
Unique Areas: 1
Maximum Depth: 3

4. Review the Subdomain Table

Inspect every discovered hostname.

Example:

dash.niamonx.io
data-wells.niamonx.io
poreva.niamonx.io
support.niamonx.io

Look for unusual names, old systems, staging environments, administrative portals, and unexpected assets.

5. Use Search for Interesting Keywords

Search for common high-risk terms.

Examples:

admin

dev

test

stage

backup

internal

These terms may indicate systems that require closer review.

6. Review Zone and Depth

Use the Zone and Depth fields to understand hostname structure.

Example:

api.dev.example.com → zone: example.com, depth: 4

Deep subdomains may reveal application structure, environment naming, or internal service organization.

7. Export the Results

Use copy or export actions to preserve the data.

Copy list
Copy JSON
Export to CSV
Raw JSON

8. Enrich the Subdomain List

After enumeration, enrich the discovered list with additional tools.

9. Compare With Official Asset Inventory

Compare discovered subdomains with the organization’s known asset list.

Questions to ask:

🚨 Security Review Checklist

When reviewing subdomain enumeration results, pay special attention to suspicious or high-risk patterns.

Administrative Interfaces

Look for hostnames such as:

admin.example.com
dashboard.example.com
panel.example.com
portal.example.com
login.example.com

These may expose authentication portals or administrative systems.

Development and Testing Environments

Look for names such as:

dev.example.com
test.example.com
stage.example.com
staging.example.com
qa.example.com
uat.example.com
demo.example.com

These systems may have weaker security controls than production environments.

Legacy or Forgotten Assets

Look for names such as:

old.example.com
legacy.example.com
backup.example.com
archive.example.com
temp.example.com

Legacy assets may contain outdated software, expired certificates, weak authentication, or forgotten services.

Internal-Looking Names

Look for hostnames such as:

internal.example.com
intranet.example.com
vpn.example.com
private.example.com
corp.example.com

Even if the name suggests internal use, the hostname may still be publicly discoverable and should be reviewed.

API and Data Services

Look for names such as:

api.example.com
data.example.com
graphql.example.com
db.example.com
storage.example.com
files.example.com

These may expose backend services, APIs, file storage, or data-related endpoints.

Customer or Tenant Subdomains

Look for patterns such as:

customer1.example.com
client.example.com
tenant.example.com
org.example.com

Tenant-based subdomains may require special handling, access controls, and monitoring.

📊 Interpreting Results Correctly

Subdomain enumeration results should be interpreted carefully.

Important notes:

Subdomains Check provides a discovery layer. For deeper investigation, combine results with DNS resolution, HTTP checks, TLS inspection, screenshots, IP WHOIS, ASN data, and authorized security testing.

When documenting results, use a consistent structure.

Example:

Domain: niamonx.io
Enumeration time: 22:49:02
Total subdomains: 4
Unique areas: 1
Maximum depth: 3

Discovered subdomains:
1. dash.niamonx.io | Zone: niamonx.io | Depth: 3
2. data-wells.niamonx.io | Zone: niamonx.io | Depth: 3
3. poreva.niamonx.io | Zone: niamonx.io | Depth: 3
4. support.niamonx.io | Zone: niamonx.io | Depth: 3

For security reports, add analyst notes:

Observation:
The domain has 4 discovered subdomains. All discovered hostnames belong to the zone niamonx.io and have depth 3.

Recommended next step:
Resolve DNS records, check HTTP availability, review TLS certificates, capture screenshots, and compare the results against the official asset inventory.

🛡️ Security, Privacy & Responsible Use

Subdomains Check is intended for lawful domain analysis, OSINT research, security review, asset inventory, compliance, and defensive cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

Subdomain enumeration is a normal defensive and OSINT technique, but it should be used responsibly and legally.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Subdomains Check is a focused subdomain enumeration tool for discovering and organizing subdomains of a target domain. It validates domain input, searches internal services and archives, displays discovered subdomains, calculates zone and depth, shows total count, unique areas, maximum depth, and provides search, pagination, local history, copy options, CSV export, and Raw JSON view.

The tool is designed for OSINT research, attack surface mapping, SOC triage, incident response, brand protection, compliance documentation, asset inventory, and authorized security workflows. Results should be treated as point-in-time discovery intelligence and enriched with DNS resolution, HTTP checks, TLS data, screenshots, IP WHOIS, ASN information, and official asset inventory validation before drawing security conclusions.

Website and Host Analysis

Subdomains Check V2 | Experimental Subdomain & DNS Records Discovery Tool

image.png

The platform available at https://dash.niamonx.io/subdomains_v2 — known as Subdomains Check V2 — is an experimental domain intelligence tool within the NiamonX platform. It searches for subdomains and related DNS records for a specified domain name, including A records, CNAME records, MX records, NS records, TXT records, resolved IP addresses, and basic network/provider information.

This tool is designed for fast domain reconnaissance, DNS inventory, infrastructure mapping, attack surface review, OSINT analysis, SOC workflows, incident response, and technical asset discovery.

Because the module is experimental, the speed, coverage, and completeness of results may depend on crawler performance, available sources, DNS response behavior, and tariff limits.

Overview of the Service

Subdomains Check V2 helps users discover subdomains and associated DNS records for a target domain. The tool accepts a domain name, performs discovery and DNS resolution, then organizes the results into clear sections.

The module can return:

Subdomains Check V2 is useful when users need to quickly understand which public DNS records and subdomains are associated with a domain.

The tool is especially helpful for:

🔍 How the Tool Works

When a user enters a domain name, Subdomains Check V2 searches for subdomains and related DNS records. The tool then resolves available records and presents the results in grouped sections.

Example input:

Domain: niamonx.io

Example result summary:

niamonx.io
A: 1
Subdomains: 1
IPs: 2
MX: 3
NS: 2
TXT: 2
22:51:28

Example resolved A / subdomain result:

niamonx.io
104.21.12.231
CLOUDFLARENET
Cloudflare

172.67.153.184
CLOUDFLARENET
Cloudflare

Example DNS records:

MX:
20 mx2.zoho.eu
50 mx3.zoho.eu
10 mx.zoho.eu

NS:
abdullah.ns.cloudflare.com
ashley.ns.cloudflare.com

TXT:
"google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4"
"v=spf1 include:zohomail.eu -all"

The tool provides a practical overview of both discovered subdomains and domain-level DNS configuration.

🧩 Supported Input

Subdomains Check V2 accepts only a domain name.

Correct input examples:

niamonx.io

example.com

sub.example.com

company.org

Incorrect input examples:

https://niamonx.io

http://example.com

https://example.com/page

example.com/path

*.example.com

user@example.com

192.168.1.1

localhost

The interface guidance is:

Only the domain, without http(s):// and without the path.

Users should enter the domain only, without protocol, path, query parameters, fragments, wildcard prefixes, or URL formatting.

domain.tld

⚙️ Main Function: Search by Domain

The main search field starts the domain discovery and DNS record collection process.

Example:

Search by Domain
Domain: niamonx.io

After the query is processed, the tool displays a result summary and grouped DNS sections.

The tool may collect and display:

Because this version is experimental, results may vary depending on crawler performance and available data sources.

🧪 Experimental Status

Subdomains Check V2 is marked as experimental.

Interface note:

This tool is experimental: speed and completeness depend on the crawler's performance.

This means:

The tool should be treated as a fast discovery and enrichment layer, not as a guaranteed complete DNS inventory.

For critical security work, results should be validated with additional tools and repeated over time.

📊 Results Summary

The Results section provides a compact overview of the discovered records.

Example:

niamonx.io
A: 1
Subdomains: 1
IPs: 2
MX: 3
NS: 2
TXT: 2
22:51:28

Typical fields include:

Field Description
Domain The domain that was searched
A Number of A-record hostnames or A-record groups found
Subdomains Number of discovered subdomain entries
IPs Number of resolved IP addresses
MX Number of mail exchanger records
NS Number of name server records
TXT Number of text records
Time Query time or result timestamp

The summary is useful for quick triage and comparison between multiple domain checks.

🌐 A Records and Subdomains Section

The A / Subdomains section shows hostnames and their resolved IPv4 addresses.

Example:

A / Subdomains

niamonx.io
104.21.12.231
CLOUDFLARENET
Cloudflare

172.67.153.184
CLOUDFLARENET
Cloudflare

A records are used to map hostnames to IPv4 addresses.

This section helps users identify:

A single hostname may resolve to multiple IP addresses because of:

🏢 Network and Provider Information

Subdomains Check V2 may show basic provider or network hints next to resolved IP addresses.

Example:

CLOUDFLARENET - Cl
Cloudflare

This helps users quickly identify whether a hostname appears to be associated with:

Provider information is useful for triage, but it should not be treated as final attribution. For accurate infrastructure ownership analysis, users should also check IP WHOIS, ASN data, BGP routes, passive DNS, HTTP headers, and TLS certificates.

🔎 Filtering by Subdomains

The tool provides filtering by subdomain substring.

Example:

Filter by subdomains (substring)

Filtering is useful when working with large result sets.

Users can search for terms such as:

api

admin

dev

stage

support

mail

This helps analysts quickly locate interesting, risky, or business-relevant hostnames.

🔁 CNAME Records

The CNAME section displays canonical name records.

Example:

CNAME
No Records

A CNAME record points one hostname to another canonical hostname.

Example:

app.example.com → example.hosting-provider.com

CNAME records are useful for identifying:

If the tool shows:

No Records

it means no CNAME records were returned for the current result set.

Important security note: CNAME records pointing to third-party services should be reviewed carefully. Abandoned or misconfigured CNAME records may indicate potential subdomain takeover risk, but this must be validated responsibly.

📬 MX Records

The MX section shows mail exchanger records for the domain.

Example:

MX
20 mx2.zoho.eu
50 mx3.zoho.eu
10 mx.zoho.eu

MX records define where e-mail for the domain should be delivered.

The number before the mail server is the MX priority.

Example:

10 mx.zoho.eu

Lower priority numbers are preferred first.

In the example above:

10 mx.zoho.eu
20 mx2.zoho.eu
50 mx3.zoho.eu

the mail server with priority 10 is preferred before 20 and 50.

MX records are useful for:

🌍 MX IP Resolution

Subdomains Check V2 may also resolve MX hostnames to IP addresses.

Example:

20 mx2.zoho.eu
89.36.170.166

50 mx3.zoho.eu
185.230.212.166

10 mx.zoho.eu
185.20.209.166

This helps users understand not only which mail servers are configured, but also which IP addresses they resolve to.

MX IP resolution is useful for:

🧭 NS Records

The NS section shows authoritative name servers for the domain.

Example:

NS
abdullah.ns.cloudflare.com
162.159.44.203

ashley.ns.cloudflare.com
172.64.32.71

NS records indicate which name servers are responsible for the domain’s DNS zone.

Name server data helps identify:

The tool may also resolve name server hostnames to IP addresses.

Example:

abdullah.ns.cloudflare.com → 162.159.44.203
ashley.ns.cloudflare.com → 172.64.32.71

NS records are important during security audits because DNS provider compromise or misconfiguration can affect the entire domain.

🧾 TXT Records

The TXT section displays text records associated with the domain.

Example:

TXT
"google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4"
"v=spf1 include:zohomail.eu -all"

TXT records may contain:

TXT records are useful for identifying how a domain is connected to external services and how e-mail authentication is configured.

📧 SPF Records

TXT records may include SPF configuration.

Example:

v=spf1 include:zohomail.eu -all

SPF defines which mail servers are allowed to send e-mail on behalf of the domain.

In this example:

include:zohomail.eu

allows Zoho Mail infrastructure to send mail for the domain.

The ending:

-all

means mail from unauthorized senders should fail SPF validation.

SPF records are important for:

🔐 Domain Verification Records

TXT records may also include verification tokens.

Example:

google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4

Verification records are commonly used by services such as:

These records prove domain ownership to third-party services.

Security teams should review TXT records to identify outdated, unused, or unexpected third-party integrations.

🕓 Local Request History

Subdomains Check V2 stores a local request history in the browser.

Example interface note:

Request history (local)
Filter...
We keep the domain and a brief summary (up to 200 entries).

Example history item:

niamonx.io
A:1
Subs:1
IPs:2
17.06.2026, 22:51:28

Other examples:

itstep.org
A:50
Subs:50
IPs:2
16.05.2026, 22:37:48

haveibeenpwned.com
A:13
Subs:13
IPs:3
10.12.2025, 00:46:07

The local history helps users:

Because history is stored locally in the browser, it may be removed when browser data is cleared or when the user changes browser profiles, devices, or private browsing sessions.

On shared or untrusted devices, users should clear local history after checking sensitive domains, client assets, or incident-related infrastructure.

🚦 Tariff Limits

Subdomains Check V2 respects user tariff limits.

Interface note:

Tariff limits are taken into account. If exceeded, we will display a message and will not clear the previous results.

Important points:

This behavior helps prevent users from losing their last successful result when a new query cannot be completed.

📤 Copying and Exporting Results

Subdomains Check V2 supports copying and exporting data.

Available actions may include:

Export features are useful for:

📄 CSV Export

CSV export allows users to work with results in spreadsheet tools or reporting systems.

CSV data may include:

Example CSV-style structure:

Domain,Record Type,Hostname,Value,IP,Provider
niamonx.io,A,niamonx.io,104.21.12.231,104.21.12.231,Cloudflare
niamonx.io,A,niamonx.io,172.67.153.184,172.67.153.184,Cloudflare
niamonx.io,MX,niamonx.io,10 mx.zoho.eu,185.20.209.166,Zoho
niamonx.io,NS,niamonx.io,abdullah.ns.cloudflare.com,162.159.44.203,Cloudflare
niamonx.io,TXT,niamonx.io,"v=spf1 include:zohomail.eu -all",,

CSV export is useful when results need to be shared with technical teams, compliance departments, management, or auditors.

🧬 JSON Export

JSON export provides structured machine-readable output.

JSON data may include:

JSON is useful for:

🔐 Why This Tool Matters

Subdomains and DNS records are a major part of an organization’s public attack surface. A domain may appear simple from the outside, but DNS records can reveal mail providers, name servers, cloud services, CDN usage, verification tokens, third-party dependencies, and public application endpoints.

Subdomains Check V2 helps users identify:

This information supports both defensive security and operational infrastructure management.

🔎 Common Use Cases

DNS Inventory

Create a structured overview of DNS records associated with a domain.

Subdomain Discovery

Find discovered subdomains and review how they resolve.

Attack Surface Mapping

Identify public hostnames, IP addresses, DNS providers, and mail systems.

SOC Triage

Enrich alerts involving domains, hostnames, or suspicious DNS records.

Incident Response

Check whether a suspicious domain or subdomain is related to known infrastructure.

Phishing Investigation

Review DNS records, mail configuration, and provider information for suspicious domains.

Brand Protection

Inspect domains and subdomains related to impersonation, fraud, or unauthorized brand usage.

Mail Security Review

Review MX and TXT records, including SPF-related configuration.

DNS Provider Review

Check NS records and identify authoritative DNS providers.

Cloud and CDN Mapping

Identify whether hostnames resolve to CDN or cloud provider infrastructure.

Compliance Documentation

Document DNS records and public exposure for audits, reports, and risk reviews.

Asset Inventory

Add discovered hostnames, IPs, and records to an asset management workflow.

A practical Subdomains Check V2 workflow should follow these steps.

1. Enter the Domain

Use only the domain name.

Example:

niamonx.io

Do not include:

https://
http://
/path
?query=value
#fragment
*

Start the query and wait for the result.

Example:

Search by Domain

3. Review the Summary

Check the high-level result counts.

Example:

A: 1
Subdomains: 1
IPs: 2
MX: 3
NS: 2
TXT: 2

This gives a quick overview of how much data was found.

4. Review A / Subdomains

Inspect discovered hostnames and IP addresses.

Example:

niamonx.io
104.21.12.231
172.67.153.184

Follow up with IP WHOIS, ASN lookup, HTTP checks, TLS inspection, or screenshot capture when needed.

5. Check CNAME Records

Review whether the domain or subdomains point to external services.

Example:

CNAME: No Records

If CNAME records exist, validate whether the targets are expected and still active.

6. Review MX Records

Check mail routing and provider configuration.

Example:

10 mx.zoho.eu
20 mx2.zoho.eu
50 mx3.zoho.eu

Confirm that the mail provider is expected and that MX priorities are correct.

7. Review NS Records

Check authoritative name servers.

Example:

abdullah.ns.cloudflare.com
ashley.ns.cloudflare.com

Verify that the DNS provider is expected and properly managed.

8. Review TXT Records

Inspect TXT records for SPF, verification tokens, and third-party integrations.

Example:

v=spf1 include:zohomail.eu -all

Check for outdated, unexpected, or overly permissive records.

9. Filter Subdomains

Use substring filtering to locate interesting names.

Examples:

api
admin
dev
stage
mail
support

Filtering is useful for large domains with many discovered subdomains.

10. Export Results

Use CSV or JSON export for reporting and follow-up analysis.

CSV
JSON

11. Validate With Additional Tools

Because the tool is experimental, validate important findings with additional sources.

🚨 Security Review Checklist

When reviewing results, pay special attention to the following areas.

Unexpected IP Addresses

Check whether resolved IPs belong to expected providers.

Questions:

Third-Party Dependencies

Review CNAME, NS, MX, and TXT records for third-party services.

Potential dependencies:

Mail Security

Review MX and TXT records.

Important checks:

Name Server Control

Review NS records.

Questions:

Subdomain Exposure

Review discovered subdomains and search for sensitive patterns.

Examples:

admin
dev
test
stage
staging
internal
portal
dashboard
api
backup
old
legacy

These names may indicate systems that need closer review.

TXT Record Hygiene

TXT records can expose operational information.

Review for:

⚠️ Limitations and Important Notes

Subdomains Check V2 should be interpreted carefully.

Important limitations:

Interface note:

The tool is experimental; not all sources provide a complete list of subdomains.

For high-confidence analysis, combine results with multiple discovery and DNS validation methods.

📊 Interpreting Results Correctly

Subdomains Check V2 provides point-in-time DNS and subdomain intelligence.

Important interpretation notes:

The tool should be used as part of a broader investigation workflow.

When documenting results, use a consistent format.

Example:

Domain: niamonx.io
Query time: 17.06.2026, 22:51:28

Summary:
A records: 1
Subdomains: 1
Resolved IPs: 2
MX records: 3
NS records: 2
TXT records: 2

A / Subdomains:
niamonx.io
- 104.21.12.231
- 172.67.153.184

MX:
- 10 mx.zoho.eu → 185.20.209.166
- 20 mx2.zoho.eu → 89.36.170.166
- 50 mx3.zoho.eu → 185.230.212.166

NS:
- abdullah.ns.cloudflare.com → 162.159.44.203
- ashley.ns.cloudflare.com → 172.64.32.71

TXT:
- "google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4"
- "v=spf1 include:zohomail.eu -all"

For security reports, add analyst notes:

Observation:
The domain resolves through Cloudflare infrastructure and uses Zoho mail exchangers. TXT records include Google site verification and SPF authorization for Zoho Mail.

Recommended next step:
Validate DMARC and DKIM configuration, confirm that the listed providers are expected, review DNS provider account security, and enrich resolved IPs with WHOIS / ASN data.

🛡️ Security, Privacy & Responsible Use

Subdomains Check V2 is intended for lawful DNS analysis, OSINT research, security review, compliance, infrastructure mapping, and defensive cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

Subdomain and DNS discovery is a legitimate defensive and OSINT technique, but it should be used responsibly and legally.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX Subdomains Check V2 is an experimental subdomain and DNS records discovery tool for domain-based reconnaissance. It searches for subdomains and related DNS records, including A, CNAME, MX, NS, and TXT records, resolves IP addresses, shows basic provider information, supports substring filtering, provides CSV and JSON export, and stores local request history with brief summaries.

The tool is designed for OSINT research, DNS inventory, SOC workflows, incident response, attack surface mapping, mail security review, provider dependency analysis, brand protection, compliance documentation, and authorized security assessments. Because it is experimental, results should be treated as point-in-time discovery intelligence and validated with additional DNS, WHOIS, ASN, HTTP, TLS, screenshot, passive DNS, and asset inventory sources before drawing final conclusions.

Website and Host Analysis

URL Shortener | Custom Short Link Creation Tool

image.png

The platform available at https://dash.niamonx.io/url_shortener — known as URL Shortener — is a short link creation tool within the NiamonX platform. It allows users to create branded short URLs using available custom domains, optional custom slugs, optional expiration settings, and an optional expired redirect URL.

The tool is designed for fast and controlled link shortening, link branding, sharing, campaign routing, documentation links, support links, internal workflows, and security-aware URL management.

Overview of the Service

URL Shortener helps users convert long URLs into shorter, cleaner, and easier-to-share links. Instead of sending long dashboard URLs, documentation URLs, campaign links, or support links, users can generate compact short URLs using available NiamonX-connected domains.

The tool supports:

Example generated link:

https://clc.is/adsas345253

Example target URL:

https://dash.niamonx.io/url_shortener

This makes the module useful for support teams, analysts, developers, marketing teams, internal documentation, OSINT workflows, SOC teams, customer communication, and controlled temporary link sharing.

🔍 How the Tool Works

The user selects a short link domain, enters the target URL, optionally defines a custom slug, optionally sets an expired URL, and optionally configures expiration hours.

The tool then creates a short URL that redirects users to the specified target destination.

Example configuration:

Domain: clc.is
Target URL: https://dash.niamonx.io/url_shortener
Slug: adsas345253
Expired URL: https://example.com/expired
Expired hours: 0

Example result:

https://clc.is/adsas345253
Target: https://dash.niamonx.io/url_shortener
Domain: clc.is
Slug: adsas345253
Expires: Never
17.06.2026, 22:56:05

If expiration is set to 0, the short link does not expire.

Example:

Expired hours: 0
0 = never

🧩 Main Use Cases

URL Shortener can be used for many link management workflows.

Common use cases include:

Example:

Long URL:
https://dash.niamonx.io/url_shortener

Short URL:
https://clc.is/adsas345253

The main panel is used to create a new short URL.

Main fields include:

Example interface section:

After submission, the tool displays the generated short link and its configuration.

🌐 Domain

The Domain field controls which short domain will be used.

Example:

Domain: clc.is

The available domains are populated from the API.

Interface note:

Populates from API

Possible examples:

clc.is

clc.cx

The selected domain becomes the base of the short link.

Example:

https://clc.is/adsas345253

Domain selection is useful for:

🔗 Target URL

The Target URL is the destination where users will be redirected when they open the short link.

Example:

https://dash.niamonx.io/url_shortener

The target should be a complete URL with protocol.

https://example.com/page

Valid examples:

https://dash.niamonx.io/url_shortener

https://dash.niamonx.io/webscreen

https://support.niamonx.io/

Invalid or incomplete examples:

dash.niamonx.io/url_shortener

www.example.com/page

example.com

localhost

For reliable redirection, users should always include:

https://

or:

http://

🏷️ Slug

The Slug field defines the custom path part of the short link.

Example:

Slug: adsas345253

Generated short URL:

https://clc.is/adsas345253

The slug is optional.

If the user leaves the slug empty, the system may generate or assign a slug automatically, depending on backend behavior.

Example with a custom slug:

https://clc.is/url_shortener

Example with another custom slug:

https://clc.cx/petux

A slug can be useful for:

Good slug examples:

webscreen

url_shortener

support-guide

case-2026-001

444444444444444444444444444444

-

adsas345253

Although technical slugs may work, descriptive slugs are easier to manage, trust, and remember.

⏳ Expired URL

The Expired URL field defines where users should be redirected after the short link expires.

Example:

Expired URL: https://example.com/expired

This is optional.

Use cases for an expired URL:

Example behavior:

Before expiration:
https://clc.is/adsas345253 → https://dash.niamonx.io/url_shortener

After expiration:
https://clc.is/adsas345253 → https://example.com/expired

If no expired URL is provided, backend behavior may depend on platform configuration.

For best user experience, users should provide a clear expired destination when creating temporary links.

🕓 Expired Hours

The Expired hours field controls how long the short link remains active.

Example:

Expired hours: 0

Special value:

0 = never

This means the link does not expire.

Example:

Expires: Never

A non-zero value creates a temporary short link.

Example:

Expired hours: 1

This means the link expires after one hour.

Temporary links are useful for:

Use Case Suggested Expiry
Permanent documentation shortcut 0
Temporary support link 1–24 hours
Campaign link Based on campaign duration
Incident response link 1–72 hours
Internal test link 1–24 hours
Demo or training link 24–168 hours
Long-term branded shortcut 0

✅ Results Section

After successful creation, the Results section displays the generated short link and metadata.

Example:

17.06.2026, 22:56:05
https://clc.is/adsas345253
Target: https://dash.niamonx.io/url_shortener
Domain: clc.is
Slug: adsas345253
Expires: Never

Typical result fields include:

Field Description
Timestamp Date and time when the short link was created
Short URL The generated short link
Target Destination URL
Domain Selected short domain
Slug Custom or generated slug
Expires Expiration status

The Results section is useful for quickly copying the generated link and verifying that it points to the correct destination.

📋 Request History

URL Shortener stores recent actions locally in the user’s browser.

Example interface note:

Request History
Filter...
Stores last 100 actions in your browser.

Example history item:

https://clc.is/adsas345253
Domain: clc.is
Slug: adsas345253
Expires: Never
17.06.2026, 22:56:05
Target: https://dash.niamonx.io/url_shortener

The request history helps users:

Because the history is stored locally in the browser, it may be removed when users clear browser data, switch devices, use a different browser profile, or use private browsing mode.

On shared or untrusted devices, users should treat link history as sensitive and clear it when links point to private dashboards, customer pages, internal tools, incident reports, or confidential resources.

🚦 Query Limits and Plan Access

URL Shortener uses plan-based query limits.

Example:

1249 / 1250
Queries remaining / total
Plan: Sentinel

Important points:

Example interface note:

Server-side plan limits apply.

Plan limits help control resource usage and prevent abuse.

🧠 Key Features

Custom Domain Selection

Users can choose from available short link domains provided by the API.

Custom Slug Support

Users can define their own slug for branded, readable, or workflow-specific links.

Target URL Validation

The tool validates the destination URL to reduce invalid or malformed link creation.

Optional Expiration

Users can configure links to expire after a specified number of hours.

Never-Expire Mode

Setting expiration hours to 0 creates a non-expiring link.

Expired Redirect URL

Users can define a fallback destination for expired links.

Copy-Friendly Results

Generated short URLs are displayed clearly for easy copying and sharing.

Local Request History

The tool stores the last 100 actions locally in the browser.

Filtering History

Users can filter request history to find previous links.

Plan-Based Limits

Short link creation is controlled by the user’s active plan.

Client-Side Controls

The interface provides validation, copy, and export-oriented controls on the client side.

🔎 Common Use Cases

Example:

https://clc.is/webscreen

Dashboard Shortcuts

Example:

Target: https://dash.niamonx.io/webscreen
Slug: webscreen

Create readable shortcuts for long documentation URLs.

Temporary Access Links

Use expiration hours to create time-limited links.

Example:

Expires: 1 h

Campaign or Announcement Links

Use custom slugs to create memorable campaign or announcement URLs.

Incident Response Sharing

Create controlled short links for reports, evidence packages, or internal incident documentation.

Training and Demo Links

Create short, easy-to-type links for presentations, workshops, and training sessions.

Use expired URLs to send users to a fallback page after a campaign or temporary workflow ends.

🧾 Example Configurations

Domain: clc.is
Target URL: https://dash.niamonx.io/url_shortener
Slug: url_shortener
Expired URL: —
Expired hours: 0

Result:

https://clc.is/url_shortener
Expires: Never

Best for:

Domain: clc.cx
Target URL: https://dash.niamonx.io/url_shortener
Slug: demo-link
Expired URL: https://example.com/expired
Expired hours: 1

Result behavior:

Active for: 1 hour
After expiry: redirects to https://example.com/expired

Best for:

Domain: clc.is
Target URL: https://dash.niamonx.io/webscreen
Slug: webscreen
Expired hours: 0

Result:

https://clc.is/webscreen

Best for:

Automatically Assigned Slug

Domain: clc.is
Target URL: https://dash.niamonx.io/url_shortener
Slug: —
Expired hours: 0

Possible result:

(created)
Domain: clc.is
Slug: —
Expires: Never

Backend behavior may assign a slug automatically depending on platform configuration.

A practical URL Shortener workflow should follow these steps.

1. Select a Domain

Choose the short link domain that should be used.

Example:

clc.is

Use a domain that matches the purpose of the link, brand, or workflow.

2. Enter the Target URL

Paste the full destination URL.

Example:

https://dash.niamonx.io/url_shortener

Make sure the URL includes https:// or http://.

3. Choose a Slug

Enter a custom slug if a readable or branded link is needed.

Example:

url_shortener

Leave it empty if automatic slug generation is preferred.

4. Configure Expiry

Set expiration hours.

Example for no expiration:

Expired hours: 0

Example for a temporary link:

Expired hours: 24

5. Add an Expired URL if Needed

For temporary links, add a fallback URL.

Example:

https://example.com/expired

This improves user experience after the link expires.

6. Create the Short Link

Submit the form and wait for the result.

Example result:

https://clc.is/adsas345253

7. Verify the Result

Check:

Target URL
Domain
Slug
Expiration
Timestamp

8. Copy and Share the Link

Copy the generated short URL and share it through the intended channel.

Examples:

9. Review Local History if Needed

Use request history to find recently created links.

Example:

Filter...

This is useful when the short link was created earlier in the same browser.

🔐 Security Considerations

Important security points:

Do not place sensitive information directly inside slugs.

Bad examples:

customer-password-reset-token

case-secret-token-123

private-client-incident-admin

Better examples:

case-2026-001

support-guide

webscreen

🛡️ Responsible Use

URL Shortener is intended for legitimate link management, support, documentation, internal workflow, campaign routing, and controlled sharing.

Acceptable use cases include:

Users should follow responsible use principles:

📊 Interpreting Results Correctly

A generated short link should be interpreted as a redirect object.

Important notes:

Good slugs should be:

Good examples:

webscreen

url-shortener

support

docs

incident-guide

Avoid slugs that are:

When documenting created short links, use a consistent format.

Example:

Created: 17.06.2026, 22:56:05
Short URL: https://clc.is/adsas345253
Target URL: https://dash.niamonx.io/url_shortener
Domain: clc.is
Slug: adsas345253
Expires: Never
Expired URL: https://example.com/expired
Plan: Sentinel

For temporary links, document the expiration:

Short URL: https://clc.cx/demo-link
Target URL: https://dash.niamonx.io/url_shortener
Expires: 1 hour
Expired URL: https://example.com/expired
Purpose: temporary demo link

For internal security workflows, also document:

Owner
Purpose
Creation time
Expected audience
Expiration policy
Review date

🧹 Managing Local History

The local request history stores the last 100 actions in the browser.

Example:

Stores last 100 actions in your browser.

Local history is a convenience feature, not a full link management database.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX URL Shortener is a custom short link creation tool for generating compact redirect URLs. It supports API-provided short domains, custom slugs, target URL validation, optional expired URLs, expiration in hours, never-expire mode, copy-friendly results, local request history, filtering, and plan-based query limits.

The tool is designed for branded short links, support workflows, documentation shortcuts, dashboard links, temporary sharing, campaign routing, internal communication, reports, and presentations. Users should choose clear slugs, verify target URLs before sharing, use expiration for temporary or sensitive workflows, and avoid placing secrets or private information in short links.

Website and Host Analysis

DNSSEC Configuration | DNSSEC Validation, Keys & Signature Analysis Tool

image.png

The platform available at https://dash.niamonx.io/dnssec_check — known as DNSSEC Configuration — is a DNSSEC validation and diagnostic tool within the NiamonX platform. It analyzes whether a domain is correctly protected with DNSSEC by checking DS records at the parent zone, DNSKEY records at the authoritative zone, RRSIG signatures, validation flags, DNS response status, authoritative name servers, IP nodes, and detected configuration issues.

The tool helps users understand whether a domain has a valid DNSSEC trust chain or whether DNSSEC is missing, incomplete, misconfigured, or failing validation.

Overview of the Service

DNSSEC Configuration is designed to analyze the DNSSEC state of a domain in a structured and readable way. DNSSEC helps protect DNS responses against tampering by using cryptographic signatures and a chain of trust from the parent zone to the domain’s authoritative DNS zone.

The tool checks several important parts of DNSSEC configuration:

The module is useful for DNS administrators, DevOps engineers, security teams, SOC teams, compliance teams, incident responders, domain owners, infrastructure engineers, and OSINT analysts.

It is especially helpful when users need to answer questions such as:

🔍 How the Tool Works

When a user enters a domain, DNSSEC Configuration performs DNSSEC-related DNS queries and analyzes the results.

Example input:

Domain: niamonx.io

Example summary result:

niamonx.io
DNSSEC is NOT correctly configured
Issues: 3
DNSKEY: 0
DS: 0
22:58:27

The tool may perform checks for:

The result is organized into multiple sections:

🧩 Supported Input

DNSSEC Configuration accepts domain names only.

Correct input examples:

niamonx.io

example.com

cloudflare.com

sub.example.com

Incorrect input examples:

https://niamonx.io

http://example.com

https://example.com/path

example.com/path

user@example.com

192.168.1.1

localhost

Interface guidance:

Enter the domain without the protocol (example.com).

Users should enter only the domain name, without http://, https://, path, query string, fragment, wildcard, or e-mail formatting.

📊 Summary Section

The Summary section provides a compact DNSSEC status overview.

Example:

niamonx.io
DNSSEC is NOT correctly configured
Issues: 3
DNSKEY: 0
DS: 0
22:58:27

Typical fields include:

Field Description
Domain The checked domain
Status DNSSEC validation result
Issues Number of detected configuration problems
DNSKEY Number of DNSKEY records found
DS Number of DS records found
Time Query or result timestamp

The Summary section is useful for quick triage. It immediately shows whether the domain appears to have a valid DNSSEC configuration or whether further investigation is needed.

✅ Status Validator

The tool provides a clear status result.

Example:

DNSSEC is NOT correctly configured

Possible high-level outcomes may include:

A valid DNSSEC configuration normally requires:

DS record in the parent zone
DNSKEY record in the authoritative zone
Valid RRSIG signatures
Successful validation
AD=true

If one or more of these components are missing or invalid, the domain may fail DNSSEC validation.

🧾 Domain Details

The detailed result section shows the checked domain and DNSSEC-related values.

Example:

Domain: niamonx.io
Status: DNSSEC is NOT correctly configured
Issues: 3
DNSKEY count: 0
DS count: 0
AD DNSKEY: false
AD DS: false
AD RRSIG: false
Authoritative NS: abdullah.ns.cloudflare.com, ashley.ns.cloudflare.com
IP nodes: 104.21.12.231, 172.67.153.184, 2606:4700:3033::6815:ce7, 2606:4700:3030::ac43:99b8

This section helps users understand both the DNSSEC state and the DNS infrastructure involved in the result.

🔐 DNSSEC Trust Chain

DNSSEC depends on a chain of trust.

A simplified trust chain looks like this:

Root zone
→ TLD parent zone
→ Domain DS record
→ Domain DNSKEY record
→ Signed DNS records
→ Validated response

For DNSSEC to validate correctly:

  1. The parent zone must publish a DS record for the domain.

  2. The domain’s authoritative zone must publish matching DNSKEY records.

  3. DNS records must be signed with valid RRSIG signatures.

  4. A validating resolver must be able to verify the signatures.

  5. The response should set AD=true when validation succeeds.

If the DS record is missing, the chain of trust cannot be established from the parent zone.

If DNSKEY records are missing, the domain zone cannot provide the public keys needed to validate signatures.

If RRSIG records are missing or invalid, DNSSEC-signed data cannot be validated.

🚨 Issues Section

The Issues section lists detected DNSSEC problems.

Example:

Issues
Total: 3

#1 Missing DNSKEY record
#2 Missing DS record
#3 No Authenticated Data (AD flag not set)

Issues help users quickly identify what needs to be fixed.

Common issues may include:

Each issue should be reviewed in the context of the domain’s DNS provider, registrar configuration, and authoritative zone settings.

🔑 DNSKEY Section

The DNSKEY section shows DNSKEY query details and DNSKEY records when available.

Example:

DNSKEY
AD: false
Status: 0
AD: false
CD: false
RD: true
RA: true
TC: false
Status 0
No DNSKEY records

DNSKEY records contain public keys used to validate DNSSEC signatures.

A DNSKEY record may include:

Field Description
Data DNSKEY record data
Flags Key role indicator
Proto DNSSEC protocol field
Algo Cryptographic algorithm
TTL Time to live

Example table when no records exist:

# Data Flags Proto Algo TTL
No DNSKEY records

If no DNSKEY records are found, the domain zone does not provide the public keys required for DNSSEC validation.

🧬 DNSKEY Flags

DNSKEY flags help identify the type of key.

Common values include:

Flag Meaning
256 Zone Signing Key, often called ZSK
257 Key Signing Key, often called KSK

The exact DNSSEC key structure depends on the DNS provider and deployment model.

In a typical DNSSEC configuration:

If DNSKEY records are missing, DNSSEC cannot be validated at the domain zone level.

🧾 DS Section

The DS section shows DS query results from the parent zone or authority response.

Example:

DS
AD: false
Status: 0
AD: false
CD: false
RD: true
RA: true
TC: false
Status 0

A DS record connects the parent zone to the child domain’s DNSKEY.

A valid DS record is required for a complete DNSSEC trust chain.

If the DS record is missing, the parent zone does not delegate DNSSEC trust to the domain.

Example issue:

Missing DS record

The DS section may also show authority records such as SOA, DS, RRSIG, or NSEC/NSEC3-related data.

Example authority output:

a0.nic.io. hostmaster.donuts.email. 1781729005 7200 900 1209600 3600

This information can help diagnose whether the parent zone returned a negative answer, an authority response, or related DNSSEC denial-of-existence data.

🧷 RRSIG Section

The RRSIG section shows signature query information.

Example:

RRSIG Query
AD: false
Status: 0
AD: false
CD: false
RD: true
RA: true
TC: false
Status 0
Response from 172.64.35.203.

RRSIG records contain cryptographic signatures for DNS records.

RRSIG is important because it proves that DNS records were signed by the domain’s DNSSEC keys.

A valid DNSSEC response generally requires:

If RRSIG validation fails or no authenticated data is returned, the tool may show an issue such as:

No Authenticated Data (AD flag not set)

🏁 AD Flag

AD means Authenticated Data.

Interface hint:

AD: Authenticated Data (server verified signatures).

Example:

AD DNSKEY: false
AD DS: false
AD RRSIG: false

When AD=true, the validating resolver indicates that DNSSEC validation succeeded for the response.

When AD=false, it may mean:

For a correctly validated DNSSEC response, AD=true is an important positive signal.

🚫 CD Flag

CD means Checking Disabled.

Interface hint:

CD: Checking Disabled (client requested to skip verification).

Example:

CD: false

When CD=true, the client asks the resolver not to perform DNSSEC validation.

When CD=false, DNSSEC validation is not intentionally disabled by the query.

The CD flag is useful for diagnosing whether DNSSEC failures are caused by validation behavior or by the underlying DNSSEC configuration.

🔁 RD and RA Flags

RD means Recursion Desired.

RA means Recursion Available.

Interface hint:

RD / RA: Recursion Desired / Available.

Example:

RD: true
RA: true

Meaning:

Flag Description
RD The client requested recursive resolution
RA The resolver supports recursive resolution

These flags help users understand how the DNS query was processed.

🧯 TC Flag

TC means Truncated.

Example:

TC: false

If TC=true, the DNS response was truncated. This can happen when the response is too large for the transport method and may require retrying over TCP.

A truncated DNSSEC response can affect diagnostics because DNSSEC records may be large.

📟 DNS Status Code

The Status field shows the DNS response code.

Interface hint:

Status: Response code (0=NOERROR).

Example:

Status: 0

Common DNS response codes include:

Code Meaning
0 NOERROR
1 FORMERR
2 SERVFAIL
3 NXDOMAIN
4 NOTIMP
5 REFUSED

A status of 0 means the DNS response itself returned NOERROR, but it does not automatically mean DNSSEC is correctly configured. DNSSEC may still be missing or unauthenticated.

🧭 Authoritative Name Servers

The DNS Chain section displays authoritative name servers for the domain.

Example:

Authoritative NS:
abdullah.ns.cloudflare.com
ashley.ns.cloudflare.com

Authoritative name servers are responsible for serving the domain’s DNS zone.

This information is useful for:

If DNSSEC is missing or broken, the authoritative DNS provider configuration should be reviewed.

🌐 IP Nodes

The DNS Chain section may also show IP nodes associated with the domain or authoritative resolution path.

Example:

IP nodes:
104.21.12.231
172.67.153.184
2606:4700:3033::6815:ce7
2606:4700:3030::ac43:99b8

IP nodes are useful for understanding the infrastructure returned by DNS resolution.

They may represent:

IP nodes should not be confused with DNSSEC keys. They are infrastructure addresses, not DNSSEC trust records.

💬 Query Comments

The tool may display comments showing where a response came from.

Examples:

DNSKEY Comment: Response from 173.245.58.71.

DS Comment: Response from 2a01:8840:a1::17.

RRSIG Comment: Response from 172.64.35.203.

These comments are useful for diagnostics because they show which resolver or server returned the response.

Response comments can help analysts identify:

🧠 Extended DNS Errors

Extended DNS Errors provide additional diagnostic information for DNS failures.

Interface hint:

Extended DNS Errors: Additional codes (RFC 8914) for failure diagnostics.

Extended DNS Errors may help explain:

If extended errors are present, they should be reviewed together with DNSKEY, DS, RRSIG, and response flags.

🕓 History of Domains

DNSSEC Configuration stores recently checked domains locally in the browser.

Example interface section:

History of domains
Filter...

History helps users:

Because history is stored locally, it may be removed when browser data is cleared, a private browsing session is used, or the user switches devices or browser profiles.

On shared or untrusted devices, users should clear local history after checking sensitive customer domains, investigation targets, or internal infrastructure.

📤 Copying and Exporting

DNSSEC Configuration supports copying and exporting results.

Available actions may include:

Copying and exporting are useful for:

🔎 Common Use Cases

DNSSEC Configuration Check

Verify whether a domain has DNSSEC enabled and correctly configured.

Domain Security Audit

Review DNSSEC status as part of a broader domain security assessment.

Registrar Configuration Review

Check whether DS records are published correctly at the parent zone.

DNS Provider Troubleshooting

Check whether DNSKEY and RRSIG records exist in the authoritative DNS zone.

Incident Response

Investigate whether DNS tampering protection is enabled for a domain involved in an incident.

Compliance Documentation

Document DNSSEC posture for compliance, audit, or risk management.

Migration Validation

Verify DNSSEC after changing DNS providers, registrars, nameservers, or signing configuration.

Broken DNSSEC Diagnosis

Identify whether validation failures are caused by missing DS, missing DNSKEY, invalid signatures, or resolver behavior.

Infrastructure Review

Map authoritative name servers and IP nodes involved in DNS resolution.

OSINT and Defensive Research

Check DNSSEC posture of domains during domain intelligence or external attack surface review.

A practical DNSSEC Configuration workflow should follow these steps.

1. Enter the Domain

Use only the domain name.

Example:

niamonx.io

Do not enter:

https://niamonx.io

2. Review the Summary

Start with the high-level status.

Example:

DNSSEC is NOT correctly configured
Issues: 3
DNSKEY: 0
DS: 0

This quickly shows whether DNSSEC is working or requires troubleshooting.

3. Review the Issues List

Check every issue reported by the tool.

Example:

Missing DNSKEY record
Missing DS record
No Authenticated Data (AD flag not set)

The issue list provides the most direct explanation of the DNSSEC problem.

4. Check DS Records

Review whether the parent zone publishes a DS record.

Example issue:

Missing DS record

If DS is missing, DNSSEC trust cannot be established from the parent zone.

This is often configured at the domain registrar.

5. Check DNSKEY Records

Review whether DNSKEY records exist in the authoritative zone.

Example issue:

Missing DNSKEY record

If DNSKEY is missing, the domain zone is not providing public keys for DNSSEC validation.

This is usually configured at the DNS provider.

6. Check RRSIG and AD Flag

Review whether signatures are present and whether authenticated data is returned.

Example:

AD RRSIG: false

If AD=false, the response was not authenticated by the validating resolver.

7. Review Authoritative Name Servers

Confirm that the expected name servers are authoritative.

Example:

abdullah.ns.cloudflare.com
ashley.ns.cloudflare.com

If the domain recently changed DNS providers, make sure the registrar and authoritative DNS provider are aligned.

8. Review IP Nodes

Check which IP nodes were returned.

Example:

104.21.12.231
172.67.153.184
2606:4700:3033::6815:ce7
2606:4700:3030::ac43:99b8

This helps understand the visible DNS infrastructure, although these IPs are not DNSSEC records.

9. Review Extended Errors

If extended DNS errors are present, use them to diagnose the failure.

Possible reasons may include:

10. Export or Copy Results

Save the DNSSEC diagnostic output for troubleshooting.

Domain: niamonx.io
Status: DNSSEC is NOT correctly configured
Issues: 3
DNSKEY count: 0
DS count: 0
AD DNSKEY: false
AD DS: false
AD RRSIG: false
Authoritative NS: abdullah.ns.cloudflare.com, ashley.ns.cloudflare.com
Checked at: 22:58:27

🧰 DNSSEC Troubleshooting Guide

Missing DS Record

Issue:

Missing DS record

Meaning:

The parent zone does not publish a DS record for the domain.

Possible causes:

Missing DNSKEY Record

Issue:

Missing DNSKEY record

Meaning:

The authoritative DNS zone does not publish DNSKEY records.

Possible causes:

AD Flag Not Set

Issue:

No Authenticated Data (AD flag not set)

Meaning:

The resolver did not return authenticated DNSSEC-validated data.

Possible causes:

Status 0 but DNSSEC Not Valid

A DNS status code of 0 means NOERROR, but this only means the DNS query succeeded.

Example:

Status: 0

This does not mean DNSSEC is correctly configured.

A domain can return NOERROR while still having:

Always review DNSSEC-specific fields, not only the DNS response status.

🚦 Server Errors and Retry Behavior

In some cases, the processing server may return an error.

Interface note:

In case of a processing server error and receiving a 500 error, please repeat your request several times.

A temporary server-side error may be caused by:

If this happens, repeat the request. If the issue continues, compare results with another DNSSEC validation method and contact support if needed.

📊 Interpreting Results Correctly

DNSSEC Configuration results should be interpreted carefully.

Important notes:

DNSSEC is one layer of domain security. It should be used together with HTTPS, HSTS, secure registrar accounts, MFA, DNS change monitoring, SPF, DKIM, DMARC, and proper access control.

When documenting DNSSEC status, use a consistent structure.

Example:

Domain: niamonx.io
Check time: 22:58:27

Status:
DNSSEC is NOT correctly configured

Issues:
1. Missing DNSKEY record
2. Missing DS record
3. No Authenticated Data (AD flag not set)

Counts:
DNSKEY: 0
DS: 0

Flags:
AD DNSKEY: false
AD DS: false
AD RRSIG: false

Authoritative name servers:
- abdullah.ns.cloudflare.com
- ashley.ns.cloudflare.com

IP nodes:
- 104.21.12.231
- 172.67.153.184
- 2606:4700:3033::6815:ce7
- 2606:4700:3030::ac43:99b8

For a remediation report, add:

🛡️ Security, Privacy & Responsible Use

DNSSEC Configuration is intended for lawful DNS security analysis, infrastructure review, compliance, troubleshooting, and defensive cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

DNSSEC misconfiguration can affect domain availability. Changes should be planned and tested carefully.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX DNSSEC Configuration is a DNSSEC validation and diagnostics tool for checking whether a domain has a valid DNSSEC configuration. It analyzes DS records, DNSKEY records, RRSIG signatures, AD/CD flags, RD/RA flags, DNS response status, authoritative name servers, IP nodes, issues, comments, and extended DNS error information.

The tool is designed for DNS security audits, domain hardening, compliance checks, DNS provider troubleshooting, registrar validation, incident response, OSINT, and infrastructure review. A correct DNSSEC trust chain requires a valid DS record in the parent zone, DNSKEY records in the authoritative zone, valid signatures, and authenticated DNS responses. Results should be interpreted as DNSSEC diagnostics and combined with broader domain security checks such as HTTPS, TLS, HSTS, registrar security, SPF, DKIM, DMARC, DNS monitoring, and access control.

Website and Host Analysis

DMARC Policy & Configuration | DMARC Record Analysis Tool

image.png

The platform available at https://dash.niamonx.io/dmarc_check — known as DMARC Policy & Configuration — is an e-mail domain security analysis tool within the NiamonX platform. It checks whether a domain has a valid DMARC record, extracts and parses DMARC tags, identifies the active policy, analyzes reporting configuration, evaluates alignment settings, highlights security gaps, and provides a practical risk score.

The tool helps domain owners, security teams, SOC analysts, administrators, compliance teams, and investigators understand how a domain handles unauthenticated e-mail and whether its DMARC configuration is strong enough to protect against spoofing and phishing.

Overview of the Service

DMARC Policy & Configuration analyzes the DMARC record published at:

_dmarc.domain

DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is an e-mail authentication policy framework. It works together with SPF and DKIM to help receiving mail servers determine whether messages claiming to come from a domain are legitimate.

The tool checks the DMARC TXT record, parses its tags, displays the active policy, and evaluates whether the domain is using a monitoring-only policy or an enforcement policy.

The module can analyze:

This makes the tool useful for e-mail security audits, anti-phishing hardening, domain protection, compliance reviews, brand protection, SOC workflows, and infrastructure security assessments.

🔍 How the Tool Works

When a user enters a domain, the tool queries the DMARC TXT record for that domain and analyzes the returned policy.

Example input:

Domain: niamonx.com

The tool checks the DNS location:

_dmarc.niamonx.com

Example result:

Domain: niamonx.com
Policy: none
Tags: 3
23:04:59

Example parsed DMARC record:

v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com

Example analysis result:

record_exists: OK
valid_version: OK
policy_enabled: FAIL
reporting_enabled: OK
strict_alignment: FAIL
Risk Score: 40 / 100

The result helps users understand whether DMARC is present, whether it is only monitoring mail, whether reports are enabled, and whether stricter protection should be considered.

🧩 Supported Input

DMARC Policy & Configuration accepts second-level domains and subdomains.

Correct examples:

niamonx.com

example.com

sub.example.com

company.org

Incorrect examples:

https://niamonx.com

http://example.com

https://example.com/path

user@example.com

192.168.1.1

_dmarc.example.com

Interface guidance:

Only a second-level domain or subdomain (without https://).

Users should enter only the domain or subdomain. The tool automatically checks the correct DMARC DNS location by querying _dmarc. in front of the submitted domain.

📊 Result Section

The Result section provides a quick summary of the DMARC configuration.

Example:

niamonx.com
Policy: none
Tags: 3
23:04:59

Typical fields include:

Field Description
Domain The checked domain
Policy Active DMARC domain policy
Tags Number of parsed DMARC tags
Time Query or result timestamp

The Result section is useful for quick triage. It immediately shows whether the domain has a DMARC policy and whether that policy is monitoring-only or enforcement-based.

🧾 Domain Details

The detailed result view shows the parsed DMARC configuration.

Example:

Domain: niamonx.com
Policy (p): none
Subdomain (sp): (inherits p)
Reports (rua): mailto:rua@dmarc.brevo.com
Percentage (pct): 100 (implicit)
fo: 0 (default)
adkim: r (default)
aspf: r (default)

This view helps users understand both explicit and implicit DMARC values.

Some values may be shown as default because they were not explicitly present in the DNS record but are defined by DMARC behavior.

🛡️ Policy Field

The Policy (p) field defines what receiving mail servers should do when a message fails DMARC validation.

Example:

Policy (p): none

DMARC supports three main policy levels:

Policy Meaning
none Monitor only; do not request enforcement
quarantine Treat failing messages as suspicious
reject Reject failing messages

p=none

Example:

p=none

p=none means that the domain is collecting DMARC information but is not asking receivers to quarantine or reject failing messages.

This is useful during initial deployment and monitoring, but it does not provide strong spoofing protection by itself.

p=quarantine

Example:

p=quarantine

p=quarantine requests that receiving mail servers treat DMARC-failing messages as suspicious. These messages may be placed in spam or quarantine.

p=reject

Example:

p=reject

p=reject is the strongest policy. It requests that receiving mail servers reject messages that fail DMARC validation.

For mature configurations, p=reject is usually the strongest anti-spoofing posture.

🧭 Subdomain Policy

The Subdomain Policy (sp) field controls how DMARC should apply to subdomains.

Example:

Subdomain (sp): (inherits p)

If sp is not defined, subdomains inherit the main domain policy.

Example:

p=none
sp not defined
Result: subdomains inherit p=none

Possible sp values include:

sp=none
sp=quarantine
sp=reject

The subdomain policy is important because attackers may try to spoof or abuse subdomains if the root domain has incomplete enforcement.

📬 Aggregate Reports: RUA

The rua tag defines where aggregate DMARC reports should be sent.

Example:

rua=mailto:rua@dmarc.brevo.com

Aggregate reports provide summarized information about mail claiming to come from the domain.

They may include:

In the tool result, RUA may be shown as:

Reports (rua): mailto:rua@dmarc.brevo.com

Reporting is important because it allows domain owners to monitor legitimate and unauthorized e-mail sources before moving to stricter policies.

🧪 Forensic Reports: RUF

The ruf tag defines where forensic or failure reports may be sent.

Example:

ruf=mailto:forensic@example.com

If no forensic report address is configured, the tool may show:

RUF: —

Forensic reports can contain more detailed failure information, but support varies between receivers and privacy restrictions may limit their availability.

RUF should be configured carefully because failure reports may contain sensitive message details or metadata.

📈 Percentage: PCT

The pct tag defines the percentage of messages to which the DMARC policy should be applied.

Example:

pct=100

If pct is not explicitly defined, the tool may show:

Percentage (pct): 100 (implicit)

This means the policy applies to 100% of relevant messages by default.

Use cases for pct:

Example phased rollout:

p=quarantine; pct=25
p=quarantine; pct=50
p=quarantine; pct=100
p=reject; pct=25
p=reject; pct=50
p=reject; pct=100

⚙️ Failure Options: FO

The fo tag controls failure reporting options.

Example default:

fo: 0 (default)

Common values include:

Value Meaning
0 Generate reports if both SPF and DKIM fail to produce an aligned pass
1 Generate reports if either SPF or DKIM fails
d Generate reports if DKIM fails
s Generate reports if SPF fails

The default value is:

fo=0

Failure options are mainly relevant when forensic reporting is configured and supported.

🔐 DKIM Alignment: ADKIM

The adkim tag defines DKIM alignment strictness.

Example default:

adkim: r (default)

Possible values:

Value Meaning
r Relaxed alignment
s Strict alignment

Relaxed DKIM alignment allows organizational-domain alignment.

Strict DKIM alignment requires a closer match between the DKIM signing domain and the visible From domain.

Example:

adkim=s

Strict alignment provides stronger control but may break legitimate mail if third-party senders are not configured properly.

🔐 SPF Alignment: ASPF

The aspf tag defines SPF alignment strictness.

Example default:

aspf: r (default)

Possible values:

Value Meaning
r Relaxed alignment
s Strict alignment

Relaxed SPF alignment allows organizational-domain alignment between the SPF-authenticated domain and the visible From domain.

Strict SPF alignment requires a closer match.

Example:

aspf=s

Strict SPF alignment can improve security but should be enabled only after confirming all legitimate mail sources are correctly aligned.

🧾 Parsed Tags Table

The tool displays parsed DMARC tags in a structured table.

Example:

Tag Value Description
v DMARC1 Protocol version
p none Policy for domain
rua mailto:rua@dmarc.brevo.com Aggregate report URIs

Example record:

v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com

The tag table helps users understand exactly which DMARC values are present in the DNS record.

🧠 Analysis Section

The Analysis section translates raw DMARC tags into practical configuration meaning.

Example:

Policy: none
Subdomain Policy: inherit
RUA: mailto:rua@dmarc.brevo.com
RUF: —
DKIM Alignment: r
SPF Alignment: r
Failure Options: 0
Coverage %: 100

This section is useful for both technical and non-technical review because it explains the active DMARC posture in a structured format.

✅ Configuration Checks

The tool performs several checks to evaluate DMARC health.

Example:

Check: record_exists
OK

Check: valid_version
OK

Check: policy_enabled
FAIL

Check: reporting_enabled
OK

Check: strict_alignment
FAIL

record_exists

Checks whether a DMARC record exists.

Example:

record_exists: OK

If this check fails, the domain does not have a detectable DMARC record.

valid_version

Checks whether the record uses a valid DMARC version tag.

Example:

valid_version: OK

A valid DMARC record should include:

v=DMARC1

policy_enabled

Checks whether the domain uses an enforcement policy.

Example:

policy_enabled: FAIL

This may fail when the policy is:

p=none

p=none is valid for monitoring, but it does not request quarantine or rejection of failing messages.

reporting_enabled

Checks whether DMARC reporting is configured.

Example:

reporting_enabled: OK

This usually means that rua is present.

Example:

rua=mailto:rua@dmarc.brevo.com

strict_alignment

Checks whether strict alignment is configured.

Example:

strict_alignment: FAIL

This may fail when both alignment tags use relaxed mode or default relaxed behavior:

adkim=r
aspf=r

Strict alignment is not always required, but it can improve protection for mature domains after legitimate senders are validated.

📊 Risk Score

The tool provides a risk score to help prioritize remediation.

Example:

Risk Score: 40 / 100

A lower score may indicate a weaker DMARC posture, while a higher score may indicate stronger protection.

The score may be influenced by:

Example interpretation:

Score Range General Meaning
0–30 Weak or missing DMARC protection
31–60 Basic monitoring or partial configuration
61–80 Good configuration with some improvement areas
81–100 Strong DMARC enforcement posture

The score should be treated as a practical guidance indicator, not as the only measure of e-mail security.

📚 Reference by Tags

v — Version

Defines the DMARC protocol version.

Example:

v=DMARC1

This tag is required.

p — Domain Policy

Defines the policy for the main domain.

Example:

p=none

Possible values:

none
quarantine
reject

sp — Subdomain Policy

Defines the policy for subdomains.

Example:

sp=reject

If sp is not present, subdomains inherit the main p policy.

rua — Aggregate Reports

Defines addresses for aggregate DMARC reports.

Example:

rua=mailto:rua@example.com

Multiple report destinations may be separated by commas.

ruf — Forensic Reports

Defines addresses for forensic or failure reports.

Example:

ruf=mailto:forensic@example.com

Support for RUF varies across mail receivers.

pct — Policy Percentage

Defines what percentage of messages the policy applies to.

Example:

pct=100

If omitted, the default is 100.

fo — Failure Options

Defines reporting behavior for SPF and DKIM failures.

Example:

fo=0

Common values:

0
1
d
s

adkim — DKIM Alignment

Defines DKIM alignment strictness.

Example:

adkim=s

Possible values:

r
s

r means relaxed.
s means strict.

aspf — SPF Alignment

Defines SPF alignment strictness.

Example:

aspf=s

Possible values:

r
s

r means relaxed.
s means strict.

🧪 Example DMARC Configurations

Monitoring-Only DMARC

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Meaning:

Best for:

Quarantine Policy

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

Meaning:

Best for:

Reject Policy

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

Meaning:

Best for:

Strict Alignment Policy

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100

Meaning:

Best for:

🧠 Recommended DMARC Deployment Workflow

A practical DMARC deployment workflow should be gradual.

1. Publish a Monitoring Policy

Start with:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This allows the organization to collect reports without affecting mail delivery.

2. Analyze Reports

Review aggregate reports to identify all legitimate senders.

Check:

3. Fix SPF and DKIM Alignment

Make sure legitimate senders pass SPF or DKIM alignment.

Review:

SPF pass and aligned
DKIM pass and aligned
Visible From domain
Return-Path domain
DKIM d= domain

4. Move to Quarantine

After monitoring, move to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

Optionally start with a lower percentage:

pct=25

Then increase gradually.

5. Move to Reject

After confirming legitimate mail is aligned, move to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

This gives stronger protection against spoofing.

6. Define Subdomain Policy

Add an explicit subdomain policy.

Example:

sp=reject

This helps protect unused or unmanaged subdomains.

7. Consider Strict Alignment

After confirming all senders are properly configured, consider:

adkim=s; aspf=s

Strict alignment should be tested carefully before production deployment.

🚨 Common DMARC Issues

Missing DMARC Record

The domain has no detectable DMARC TXT record.

Risk:

Publish a DMARC record at _dmarc.domain with at least p=none and a valid rua address.

Policy Is Set to None

Example:

p=none

Risk:

After monitoring legitimate mail sources, move to p=quarantine or p=reject.

Reporting Is Not Enabled

Missing rua.

Risk:

Add rua=mailto:dmarc-reports@example.com or use a trusted DMARC reporting provider.

Subdomain Policy Not Defined

Missing sp.

Risk:

Define sp=quarantine or sp=reject after reviewing legitimate subdomain mail usage.

Relaxed Alignment

Example:

adkim=r
aspf=r

Risk:

Consider strict alignment only after all legitimate senders are validated.

Low Policy Coverage

Example:

pct=25

Risk:

Gradually increase pct to 100 after validating mail delivery.

🔎 Common Use Cases

Domain Anti-Spoofing Review

Check whether a domain is protected against spoofed e-mail.

Phishing Defense

Evaluate whether attackers can easily send unauthenticated mail using the domain in the visible From address.

Brand Protection

Review DMARC enforcement for high-value brand domains and customer-facing domains.

SOC Triage

Quickly check DMARC posture during phishing investigations.

Mail Security Audit

Review policy, reporting, SPF alignment, DKIM alignment, and subdomain behavior.

Compliance Documentation

Document whether e-mail authentication controls are deployed.

Vendor Mail Review

Confirm whether third-party senders are included in SPF and DKIM alignment before enforcement.

Migration Monitoring

Monitor DMARC reports when moving mail providers or adding new sending services.

Subdomain Protection Review

Check whether subdomain policy is inherited or explicitly enforced.

Risk Prioritization

Use the risk score and checks to prioritize remediation.

When documenting a DMARC check, use a consistent format.

Example:

Domain: niamonx.com
Check time: 23:04:59

DMARC Status:
Record exists: OK
Valid version: OK
Policy enabled: FAIL
Reporting enabled: OK
Strict alignment: FAIL

Policy:
p=none
sp=inherits p
pct=100 implicit
fo=0 default
adkim=r default
aspf=r default

Reports:
RUA: mailto:rua@dmarc.brevo.com
RUF: —

Risk Score:
40 / 100

Parsed tags:
v=DMARC1
p=none
rua=mailto:rua@dmarc.brevo.com

The domain has a valid DMARC record with aggregate reporting enabled, but the policy is set to p=none. This is suitable for monitoring, but it does not enforce protection against spoofed messages. After reviewing reports and confirming legitimate senders, move gradually to p=quarantine and then p=reject.

🛡️ Security, Privacy & Responsible Use

DMARC Policy & Configuration is intended for lawful e-mail security analysis, domain protection, compliance, anti-phishing review, and defensive cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

DMARC is a powerful control, but incorrect enforcement can disrupt legitimate mail delivery.

🚦 Server Errors and Retry Behavior

In some cases, the system may return a server-side error.

Interface note:

If you receive a 500 error from the database, repeat your request several times.

Temporary errors may be caused by:

If the error persists, repeat the query later and compare results with raw DNS tools or another validation method.

📊 Interpreting Results Correctly

DMARC results should be interpreted carefully.

Important notes:

A strong e-mail security posture normally includes SPF, DKIM, DMARC, secure DNS, monitored reports, vendor governance, and domain abuse monitoring.

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX DMARC Policy & Configuration is a DMARC analysis tool for checking e-mail domain protection. It extracts the DMARC record from _dmarc.domain, parses tags such as v, p, sp, rua, ruf, pct, fo, adkim, and aspf, displays policy level, reporting configuration, alignment settings, analysis checks, and risk score.

The tool is designed for anti-phishing defense, brand protection, SOC triage, compliance review, domain security auditing, mail provider migration, and DMARC deployment planning. A domain with p=none can collect reports, but stronger protection normally requires a phased move to p=quarantine or p=reject after monitoring legitimate mail sources and confirming SPF / DKIM alignment.

Website and Host Analysis

PageRank | Open PageRank Domain Ranking Tool

image.png

The platform available at https://dash.niamonx.io/pagerank — known as PageRank — is a domain ranking and Open PageRank lookup tool within the NiamonX platform. It allows users to check international ranking metrics, PageRank score, ranking position, availability status, and comparative authority signals for one or multiple domains.

The tool supports bulk domain input, automatic URL cleanup, quick input presets, sortable result tables, export options, request history, and plan-based query limits.

Overview of the Service

PageRank is designed to help users evaluate the relative authority and ranking position of domains using Open PageRank-style metrics. It provides a fast way to compare multiple domains and understand which domain has stronger ranking signals.

The tool is useful for:

Users can paste a list of domains, run a lookup, and receive a sortable overview containing rank, PageRank score, position, and response status for each domain.

Example input:

cloudflare.com, itstep.org, mirohost.net

Example summary:

Results for 3 domain(s)
Last updated: 28th Mar 2026 · 17.06.2026, 23:07:47
Requested: 3
Resolved: 3
Not found: 0
Max PR: 5.11
Avg PR: 3.77
Top domain: cloudflare.com

🔍 How the Tool Works

The user enters one or more domains into the input field. The tool normalizes the submitted values, removes URL formatting when needed, sends the cleaned domain list for ranking lookup, and displays the results in a table.

The tool can process:

Example input:

cloudflare.com, itstep.org, mirohost.net

Example normalized domains:

cloudflare.com
itstep.org
mirohost.net

Example result table:

cloudflare.com    5    5.11    3196       200
itstep.org        3    2.82    6758275    200
mirohost.net      3    3.38    2587325    200

The result allows users to compare ranking strength and authority signals across domains.

🧩 Supported Input

PageRank supports domain-based input.

Valid examples:

cloudflare.com

itstep.org

mirohost.net

github.com, google.com

Line-separated input is also supported:

cloudflare.com
itstep.org
mirohost.net

URLs may be automatically cleaned to domains.

Example submitted URL:

https://www.cloudflare.com/products/

Possible normalized domain:

cloudflare.com

Unsupported or poor input examples:

not a domain

user@example.com

localhost

192.168.1.1

https://

domain.com

or:

domain1.com, domain2.org, domain3.net

⚙️ Main Function: Check Domains

The main panel allows users to submit domains for PageRank lookup.

Example:

Check domains
Domains:
cloudflare.com, itstep.org, mirohost.net

The tool supports up to 50 domains per request.

Interface note:

Up to 50 domains per request. URLs will be auto-cleaned to domains.

This makes the tool suitable for quick comparisons, bulk checks, and domain list analysis.

⚡ Quick Input

The Quick Input field allows users to quickly append domains to the main input.

Example:

github.com, google.com

Interface note:

Optional: quickly append domains

Quick input is useful when users already have a main list but want to add commonly checked domains or comparison benchmarks without rewriting the entire input.

Example workflow:

Main input:
cloudflare.com, itstep.org, mirohost.net

Quick input:
github.com, google.com

Final checked set:
cloudflare.com, itstep.org, mirohost.net, github.com, google.com

🚦 Plan Limits and Usage

PageRank uses plan-based query limits.

Example:

1249 / 1250
Queries remaining / total
Plan: Sentinel

Important points:

Interface note:

Plan limits are enforced server-side.

📊 Results Summary

After a successful lookup, PageRank displays a result summary.

Example:

Results for 3 domain(s)
Last updated: 28th Mar 2026 · 17.06.2026, 23:07:47
Requested: 3
Resolved: 3
Not found: 0
Max PR: 5.11
Avg PR: 3.77
Top domain: cloudflare.com

Typical summary fields include:

Field Description
Results for Number of domains included in the displayed result
Last updated Date of the ranking dataset or source update
Requested Number of submitted domains
Resolved Number of domains successfully found or processed
Not found Number of domains without available ranking data
Max PR Highest PageRank score in the result set
Avg PR Average PageRank score across resolved domains
Top domain Domain with the highest PageRank score in the submitted set

The summary helps users quickly understand the overall strength of the checked domain group.

🧾 Results Table

The results table displays ranking data for each domain.

Example:

cloudflare.com    5    5.11    3196       200
itstep.org        3    2.82    6758275    200
mirohost.net      3    3.38    2587325    200

A typical table may include:

Column Description
Domain Checked domain
Rank Rounded or categorized PageRank value
PageRank Score More precise PageRank score
Position International ranking position
Status HTTP or API response status

Example interpretation:

cloudflare.com
Rank: 5
PageRank Score: 5.11
Position: 3196
Status: 200

This means the domain was found, returned successfully, and has the strongest PageRank score among the checked examples.

🏷️ Domain Column

The Domain column shows the normalized domain checked by the tool.

Example:

cloudflare.com

The tool may clean URLs and reduce them to domains before lookup.

Example:

Input: https://www.cloudflare.com/products/
Normalized: cloudflare.com

This helps users paste mixed URL lists without manually cleaning each entry.

📈 Rank Column

The Rank column shows a simplified PageRank value.

Example:

Rank: 5

This value provides a quick category-like view of domain authority.

A higher value generally indicates stronger ranking authority or broader visibility in the ranking dataset.

Example comparison:

cloudflare.com → Rank 5
itstep.org → Rank 3
mirohost.net → Rank 3

In this example, cloudflare.com has a stronger rank than the other two domains.

📊 PageRank Score

The PageRank Score column shows a more precise score.

Example:

PageRank Score: 5.11

This score allows more detailed comparison than the rounded rank.

Example:

itstep.org: 2.82
mirohost.net: 3.38

Although both domains may have Rank 3, the PageRank score shows that mirohost.net has a higher score than itstep.org in this result set.

🌍 Position Ranking

The Position column shows the domain’s international ranking position.

Example:

Position: 3196

A lower position number generally indicates a stronger or more prominent domain in the ranking dataset.

Example comparison:

cloudflare.com → 3196
mirohost.net → 2587325
itstep.org → 6758275

In this example, cloudflare.com has a significantly stronger international position.

Position rankings are useful for:

✅ Status Column

The Status column shows the response status for each checked domain.

Example:

Status: 200

A status of 200 usually indicates that the ranking lookup completed successfully for that domain.

Possible status meanings may include:

Status General Meaning
200 Successfully resolved or returned
404 Domain not found in the ranking dataset
400 Invalid or malformed request
429 Rate limit or quota issue
500 Server-side processing error

Exact status behavior depends on backend implementation and upstream source responses.

🔃 Sorting Results

The table supports sorting by column headers.

Interface note:

Click column headers to sort

Sorting helps users quickly identify:

Recommended sorting workflows:

Goal Sort By
Find strongest domain PageRank Score descending
Find weakest domain PageRank Score ascending
Find best international rank Position ascending
Find missing domains Status or Not Found
Compare bulk list PageRank Score descending
Identify outliers Position or PR score

📤 Export Options

PageRank supports exporting normalized results.

Interface note:

Export normalized results to CSV/TXT

Export options are useful for:

📄 CSV Export

CSV export is useful when users want to analyze results in spreadsheet tools.

Example CSV-style output:

Domain,Rank,PageRank Score,Position,Status
cloudflare.com,5,5.11,3196,200
itstep.org,3,2.82,6758275,200
mirohost.net,3,3.38,2587325,200

📄 TXT Export

TXT export is useful for simple lists or plain-text reports.

Example TXT-style output:

cloudflare.com | Rank: 5 | PR: 5.11 | Position: 3196 | Status: 200
itstep.org | Rank: 3 | PR: 2.82 | Position: 6758275 | Status: 200
mirohost.net | Rank: 3 | PR: 3.38 | Position: 2587325 | Status: 200

TXT export is useful for:

🕓 Request History

PageRank stores recent requests locally in the browser.

Example interface note:

Request History
Filter...
Stores last 100 requests in your browser.

Example history entry:

cloudflare.com, itstep.org, mirohost.net
Count: 3
17.06.2026, 23:07:47

The history helps users:

Because request history is stored in the browser, it may be deleted when browser data is cleared or when the user changes devices, profiles, or private browsing sessions.

On shared or untrusted devices, users should clear history after checking sensitive domain lists, client portfolios, investigation targets, or confidential research sets.

🧠 Understanding PageRank Metrics

PageRank-style metrics are designed to estimate the relative importance, authority, or ranking strength of a domain.

A higher PageRank score may indicate that the domain has stronger web visibility, authority signals, or link-based importance in the ranking dataset.

However, PageRank should be interpreted carefully.

Important notes:

PageRank is best used as one signal among many.

🔎 Common Use Cases

SEO Research

Compare domain authority signals across competitors, partners, publishers, or content targets.

Competitive Analysis

Check which domains in a group have stronger ranking positions and higher PageRank scores.

OSINT Research

Enrich domain investigations with authority and ranking context.

Domain Reputation Review

Evaluate whether a domain appears to have established web presence or limited visibility.

Brand Protection

Compare suspicious domains, impersonation domains, or lookalike domains against legitimate brand domains.

Threat Intelligence Enrichment

Add ranking context to domains found in phishing kits, malware infrastructure, spam campaigns, or suspicious web activity.

Partner and Vendor Review

Check public ranking strength of vendor, partner, or customer-facing domains.

Domain Portfolio Analysis

Compare multiple owned domains to identify stronger and weaker assets.

Content Outreach

Evaluate domains before outreach, publication, partnership, or backlink analysis.

Investigation Prioritization

Use PageRank and position data to prioritize domains that may have broader reach or visibility.

🧪 Example Analysis

Example checked domains:

cloudflare.com, itstep.org, mirohost.net

Example results:

cloudflare.com
Rank: 5
PR: 5.11
Position: 3196
Status: 200

itstep.org
Rank: 3
PR: 2.82
Position: 6758275
Status: 200

mirohost.net
Rank: 3
PR: 3.38
Position: 2587325
Status: 200

Example interpretation:

cloudflare.com has the strongest PageRank score and best international position in this set. mirohost.net has a higher PageRank score and better position than itstep.org, even though both have the same rounded rank value. All three domains were resolved successfully with status 200.

A practical PageRank workflow should follow these steps.

1. Prepare a Domain List

Collect domains that need to be compared.

Example:

cloudflare.com
itstep.org
mirohost.net

The list may be comma-separated or line-separated.

2. Paste Domains Into the Tool

Use the Domains field.

Example:

cloudflare.com, itstep.org, mirohost.net

Do not worry if some values are full URLs. The tool can auto-clean URLs to domains.

3. Add Quick Input if Needed

Use Quick Input for optional additional domains.

Example:

github.com, google.com

4. Run Open PageRank

Start the lookup.

Example:

Open PageRank

The tool will process the normalized domains and return ranking data.

5. Review the Summary

Check the overall result metrics.

Example:

Requested: 3
Resolved: 3
Not found: 0
Max PR: 5.11
Avg PR: 3.77
Top domain: cloudflare.com

6. Sort the Table

Click column headers to sort by PageRank score, position, status, or domain.

PageRank Score descending

This quickly shows the strongest domains in the list.

7. Review Not Found Results

If any domains are not found, validate that the input is correct.

Possible reasons:

8. Export Results

Export normalized data to CSV or TXT for reporting.

CSV for spreadsheet analysis
TXT for quick documentation

9. Compare With Other Signals

Use PageRank as one signal and enrich with additional checks.

📊 Interpreting Results Correctly

PageRank results should be interpreted as comparative ranking intelligence, not as a final verdict.

Important interpretation notes:

Example:

A high PageRank score can indicate domain authority, but it does not prove that the current website content is safe or trustworthy.

🚨 Security Review Checklist

When using PageRank in security or OSINT workflows, review the following areas.

High-Ranking Suspicious Domains

A suspicious domain with a high PageRank may deserve priority review because it may have broader visibility or inherited authority.

Check:

Low-Ranking Lookalike Domains

A low-ranking domain that resembles a brand may still be dangerous.

Check for:

Not Found Domains

Domains not found in ranking data may be:

Not found does not mean safe.

Large Domain Lists

For bulk lists, sort by PageRank score and position to prioritize review.

1. High PageRank + suspicious context
2. Low PageRank + brand similarity
3. Not found + recent registration
4. Unexpected domains in known infrastructure

When documenting PageRank checks, use a consistent format.

Example:

Checked domains:
cloudflare.com, itstep.org, mirohost.net

Check time:
17.06.2026, 23:07:47

Dataset last updated:
28th Mar 2026

Summary:
Requested: 3
Resolved: 3
Not found: 0
Max PR: 5.11
Avg PR: 3.77
Top domain: cloudflare.com

Results:
1. cloudflare.com | Rank: 5 | PR: 5.11 | Position: 3196 | Status: 200
2. mirohost.net | Rank: 3 | PR: 3.38 | Position: 2587325 | Status: 200
3. itstep.org | Rank: 3 | PR: 2.82 | Position: 6758275 | Status: 200

Example analyst note:

Observation:
cloudflare.com has the highest PageRank score and strongest international ranking position in the checked set. mirohost.net ranks higher than itstep.org based on both PageRank score and position. All submitted domains were successfully resolved.

🛡️ Security, Privacy & Responsible Use

PageRank is intended for lawful domain analysis, SEO research, OSINT, reputation review, brand protection, compliance, and defensive cybersecurity workflows.

Acceptable use cases include:

Users should follow responsible use principles:

⚙️ Technical Highlights

📌 Usage Hints

📬 Contact Information

support@niamonx.io — Technical Support
other@niamonx.io — General Inquiries
takedown@niamonx.io — Privacy or Data Removal Requests
legal@niamonx.io — Legal and Compliance Matters

Alternative contact channel:

🔗 Helpdesk: https://support.niamonx.io/

Summary

NiamonX PageRank is an Open PageRank domain ranking tool for checking PageRank score, domain rank, international position, response status, and comparative authority metrics. It supports bulk input, automatic URL cleanup, quick input, sortable results, CSV/TXT export, local request history, and server-side plan limits.

The tool is designed for SEO research, OSINT analysis, competitive comparison, domain reputation review, brand protection, threat intelligence enrichment, domain portfolio analysis, and reporting workflows. PageRank results should be treated as ranking and authority signals, not as final security or trust decisions, and should be combined with DNS, WHOIS, TLS, HTTP, screenshot, backlink, traffic, and threat intelligence data for deeper analysis.