Oct 28 2026

Uncover Hidden Subdomains and Expand Your View of the Attack Surface with Subdomains Lookup

Uncover Hidden Subdomains and Expand Your View of the Attack Surface with Subdomains Lookup

Oct 28, 2026 · @disc

The subdomain you forgot is the one attacker find first

Your security program protects the assets you know about. Attackers start with the ones you don’t.

Every organization has a version of the same story: a dev. host spun up for a sprint and never torn down, a staging-api. endpoint left open “just for testing,” a marketing landing page on a SaaS platform that was cancelled two years ago, a chat. or assistant. subdomain someone pointed at an AI pilot. None of them are in the asset register. None of them are in the pentest scope. All of them resolve on the public internet.

That gap between the attack surface you manage and the attack surface that exists is where breaches begin. A subdomains lookup closes it. It is the fastest, lowest-friction way to see your organization the way an adversary does — before they do.

At DISC InfoSec, we’ll run that lookup for you, free. Share your domain and the email address where you want the report, and we’ll send you a subdomain exposure assessment. Details at the end of this post.

Why subdomains become your biggest blind spot

Subdomains are cheap to create and easy to forget. Anyone with DNS access can add one in seconds, and almost nobody is accountable for removing one. Over time, your DNS zone becomes an archaeological record of every project, vendor, and experiment your company has ever run.

The usual sources of hidden subdomains:

  • Development and staging environments. dev, test, uat, qa, stage, beta. These often run older code, weaker authentication, verbose error messages, and real data copied from production.
  • Shadow IT and SaaS sprawl. Teams point help., status., events. or go. at third-party platforms without security review. When the subscription lapses, the DNS record stays behind.
  • Admin and internal tooling exposed by accident. jenkins., grafana., kibana., vpn., mail., sso. — panels that were meant for the internal network but are reachable from anywhere.
  • Mergers, acquisitions, and rebrands. Acquired domains and legacy brands carry their own subdomain sprawl, rarely inventoried during integration.
  • Forgotten cloud resources. CNAMEs pointing at storage buckets, app services, and CDN endpoints that were deprovisioned while the DNS record lived on.

Each one is a door. Some are locked. Some are propped open. You can’t tell which until you know they exist.

We made a related point in our earlier post on corporate visibility as an attack surface: the information you publish — job postings, leadership bios, tech-stack hints — is reconnaissance material. Subdomains are the infrastructure version of the same problem. Your DNS footprint quietly tells attackers what you run, who you buy from, and where you cut corners.

AI has changed the math on both sides

Subdomain discovery used to take an attacker some patience. It no longer does. AI-orchestrated recon pipelines now chain certificate-transparency queries, passive DNS, live-host probing, crawling and vulnerability templates into one automated run. What a human operator once did in an afternoon, an agent does in minutes — continuously, across thousands of targets.

At the same time, AI adoption is creating new subdomains faster than governance can track them:

  • AI application endpoints. chat., ai., copilot., assistant., agent. — customer-facing LLM features stood up by product teams racing to ship.
  • Model and inference APIs. inference., llm-api., embeddings. — often protected by a single static API key, sometimes not protected at all.
  • MCP servers and agent tool gateways. mcp. and similar hosts expose tools that let a model read data and take actions. An unauthenticated or over-permissioned MCP endpoint is not an information leak; it is a remote control.
  • RAG and vector-store front ends. Search and retrieval services that can leak sensitive documents to anyone who asks the right question.
  • Shadow AI pilots. Proofs of concept on a vendor platform, wired to production data, and never registered in your AI inventory.

This is where traditional attack surface management and AI governance collide. An exposed AI endpoint inherits every classic web risk — broken authentication, IDOR, SSRF — and adds the AI-specific ones: prompt injection, excessive agency, sensitive-information disclosure, and model abuse that runs up your inference bill. When an agent combines access to private data, exposure to untrusted content, and a way to send data out, a single injected instruction can turn it into an exfiltration channel.

You cannot govern an AI system you don’t know is running. Subdomain discovery is how you find it.

What a subdomains lookup actually reveals

A well-run lookup is passive: it reads public records rather than touching your systems. That makes it safe, fast, and legal to run on your own domain without a change window. The core sources are the same ones attackers use.

SourceWhat it showsWhy it matters
Certificate transparency logsEvery hostname that has ever received a public TLS certificateCaptures hosts that were never linked from your website — including dev, staging and internal names
Passive DNS historyHostnames observed resolving over time, and where they pointedExposes legacy and decommissioned hosts that still resolve
DNS record analysis (A, CNAME, MX, TXT)Current targets, third-party providers, mail and verification recordsReveals your SaaS supply chain and dangling CNAMEs
Search engine and archive dataIndexed pages and historical snapshots per subdomainSurfaces old endpoints, exposed documents and admin pages
Live-host and technology fingerprintingWhich hosts respond, on what software and versionTurns a list of names into a prioritized risk view

The output is more than a list. Correlated properly, it answers the questions that matter to a CISO or a board:

  • How big is our real external footprint compared with what’s in our asset inventory?
  • Which subdomains are takeover candidates — CNAMEs pointing at cloud or SaaS resources that no longer exist?
  • Which non-production environments are internet-facing?
  • Where are admin panels, login pages, and APIs exposed?
  • Which AI endpoints, model APIs or agent gateways exist — and are they in our AI inventory?
  • Which third parties sit inside our trust boundary through DNS delegation?

The risk patterns we see again and again

Subdomain takeover. A CNAME still points at a cloud service, storage bucket or SaaS tenant that was deleted. An attacker claims the abandoned resource and now serves content from your domain — phishing pages, malware, credential harvesters — with your brand and often a valid certificate. In 2024, researchers at Guardio Labs exposed a campaign they named “SubdoMailing” that hijacked thousands of abandoned subdomains belonging to well-known brands and used them to send spam and phishing that passed email authentication checks. The victims’ only mistake was a stale DNS record.

Forgotten environments with real data. Staging and test hosts frequently run with debug modes on, default credentials, or outdated frameworks, while holding copies of production data. They are the easiest pivot point into the main environment.

Exposed admin and CI/CD surfaces. Build servers, dashboards and log viewers reachable from the internet leak secrets, source code and infrastructure details — and some allow code execution outright.

Unregistered AI endpoints. A chatbot or agent on its own subdomain, wired to internal data and tools, outside the AI inventory and outside the risk assessment. No owner, no logging, no prompt-injection testing.

A lesson from our own recon work

In a recent authorized engagement, a quick passive pass against a single client domain surfaced development, WordPress, support, email-routing and ERP subdomains within seconds — the real external footprint.

The instructive part came next. An AI-orchestrated pentest tool processing that same recon data failed while parsing its own output, silently discarded every subdomain, and produced a polished report stating “0 findings — Risk: low.” The raw data proved otherwise.

That is an AI governance failure in miniature: an automated system produced a confident, wrong, board-ready conclusion, and nothing in the pipeline flagged it. Automated recon is essential. Automated recon that no human validates against the raw evidence is a liability. This is exactly the kind of oversight evidence ISO 42001 and the NIST AI RMF expect you to be able to show.

From inventory to governance

Subdomain discovery is not just a technical hygiene task. It is evidence for the controls your auditors, customers and regulators already ask about. Every major framework starts with the same premise: you can only protect, assess and govern what you know you have.

FrameworkWhere subdomain discovery fits
ISO/IEC 27001:2022Annex A 5.9 (inventory of information and other associated assets), 8.8 (management of technical vulnerabilities), 5.23 (information security for use of cloud services)
ISO/IEC 42001:2023Clause 4.3 scope of the AI management system, AI system inventory, Clause 6.1 AI risk assessment, and Annex A controls on AI system resources and third-party relationships
NIST CSF 2.0ID.AM (asset management) and ID.RA (risk assessment) under Identify; continuous monitoring under Detect
NIST AI RMF 1.0MAP (establish context and inventory AI systems) and GOVERN (accountability for every AI system in production)
OWASP Top 10 for LLM ApplicationsExposed AI endpoints are where prompt injection, sensitive-information disclosure, excessive agency and unbounded consumption are exploited
EU AI ActProviders and deployers must know which AI systems they operate before they can classify risk and meet obligations

For B2B SaaS and financial services firms, this is increasingly a sales issue, not just a security one. Enterprise buyers send security questionnaires asking how you inventory external assets and AI systems. A documented, recurring subdomain discovery process — with owners, decisions and remediation tracked — is a strong answer. “We don’t know” is not.

A practical subdomain hygiene playbook

  1. Discover. Run passive enumeration across every domain you own, including acquired and legacy brands. Certificate transparency and passive DNS are the minimum.
  2. Reconcile. Compare what you found with your asset inventory and CMDB. Every unknown subdomain is a finding until someone claims it.
  3. Assign ownership. Each live subdomain gets a named business owner and a purpose. No owner, no record.
  4. Kill dangling records. Remove CNAMEs and A records that point at deprovisioned cloud or SaaS resources. Make DNS cleanup a mandatory step in every decommissioning checklist.
  5. Restrict non-production. Put dev, test and staging behind SSO, VPN or IP allow-lists. Never put production data in them.
  6. Register every AI endpoint. Any subdomain serving an LLM feature, model API, agent or MCP server goes into your AI system inventory, gets a risk assessment, and is tested for prompt injection and authorization flaws.
  7. Validate the automation. If AI tools drive your recon or scanning, check their conclusions against the raw evidence. Log those reviews as oversight evidence.
  8. Monitor continuously. Your footprint changes weekly. Alert on new certificates and new DNS records for your domains, and repeat full discovery at least quarterly.

The first step is the one most organization have never done properly. That’s where we can help.

Get your free subdomains assessment

Find out what attackers can already see. DISC InfoSec will run a passive subdomains lookup on your domain and send you a report covering:

  • Every discoverable subdomain, reconciled into a clean list
  • Potential subdomain takeover candidates and dangling DNS records
  • Exposed non-production, admin and login surfaces
  • AI endpoints, model APIs and agent gateways that should be in your AI inventory
  • Third-party providers inside your DNS trust boundary
  • Prioritized next steps mapped to ISO 27001, ISO 42001 and NIST CSF 2.0

The assessment is passive: we read public records only and never scan or touch your systems without written authorization.

To request it, share two things:

  1. Your domain (for example, yourcompany.com)
  2. The email address where you want DISC InfoSec to send the report

Email info@deurainfosec.com with the subject line “Free Subdomains Assessment,” or call (707) 998-5164. Prefer to talk it through? Book a call.

About DISC InfoSec

DISC InfoSec (Deura Information Security Consulting) is a boutique AI governance and cybersecurity consultancy serving B2B SaaS and financial services firms. Our principal holds CISSP, CISM, ISO/IEC 42001 Lead Implementer and ISO/IEC 27001 Lead Implementer credentials, with a background spanning KPMG, IBM and Intel/McAfee Foundstone. We led a SaaS virtual data room provider to ISO 42001 certification on its first Stage 2 audit attempt. We help organizations see their real attack surface — and govern the AI running on it.

Tags: Free subdomains assessment, Subdomains assessment, Subdomains lookup


Jul 31 2024

How Millions of Phishing Emails were Sent from Trusted Domains: EchoSpoofing Explained

Category: DNS Attacks,Information Security,Phishing — disc7 @ 11:44 am

Injecting spoofed headers with email relaying involves manipulating the email headers to disguise the true origin of an email, making it appear as if it was sent from a legitimate source. Here’s a detailed explanation of how this process works:

1. Understanding Email Headers

Email headers contain vital information about the sender, recipient, and the path an email takes from the source to the destination. Key headers include:

  • From: The email address of the sender.
  • To: The recipient’s email address.
  • Subject: The subject line of the email.
  • Received: Information about the mail servers that handled the email as it traveled from sender to recipient.
  • Return-Path: The email address where bounces and error messages should be sent.

2. Email Relaying

Email relaying is the process of sending an email from one server to another. This is typically done by SMTP (Simple Mail Transfer Protocol) servers. Normally, email servers are configured to relay emails only from authenticated users to prevent abuse by spammers.

3. Spoofing Headers

Spoofing email headers involves altering the email headers to misrepresent the email’s source. This can be done for various malicious purposes, such as phishing, spreading malware, or bypassing spam filters. Here’s how it can be done:

a. Crafting the Spoofed Email

An attacker can use various tools and scripts to create an email with forged headers. They might use a command-line tool like sendmail, mailx, or a programming language with email-sending capabilities (e.g., Python’s smtplib).

b. Setting Up an Open Relay

An open relay is an SMTP server configured to accept and forward email from any sender to any recipient. Attackers look for misconfigured servers on the internet to use as open relays.

c. Injecting Spoofed Headers

The attacker crafts an email with forged headers, such as a fake “From” address, and sends it through an open relay. The open relay server processes the email and forwards it to the recipient’s server without verifying the authenticity of the headers.

d. Delivery to Recipient

The recipient’s email server receives the email and, based on the spoofed headers, believes it to be from a legitimate source. This can trick the recipient into trusting the email’s content.

4. Example of Spoofing Email Headers

Here’s an example using Python’s smtplib to send an email with spoofed headers:

import smtplib
from email.mime.text import MIMEText

# Crafting the email
msg = MIMEText("This is the body of the email")
msg['Subject'] = 'Spoofed Email'
msg['From'] = 'spoofed.sender@example.com'
msg['To'] = 'recipient@example.com'

# Sending the email via an open relay
smtp_server = 'open.relay.server.com'
smtp_port = 25

with smtplib.SMTP(smtp_server, smtp_port) as server:
    server.sendmail(msg['From'], [msg['To']], msg.as_string())

via Frontend Transport

The statement about the term “via Frontend Transport” in header values refers to a specific configuration in Microsoft Exchange Server that could suggest a misconfiguration allowing email relaying without proper verification. Let’s break down the key elements of this explanation:

1. Frontend Transport in Exchange

In Microsoft Exchange Server, the Frontend Transport service is responsible for handling client connections and email traffic from the internet. It acts as a gateway, receiving emails from external sources and forwarding them to the internal network.

2. Email Relaying

Email relaying is the process of forwarding an email from one server to another, eventually delivering it to the final recipient. While this is a standard part of the SMTP protocol, it becomes problematic if a server is configured to relay emails without proper authentication or validation.

3. The Term “via Frontend Transport”

When email headers include the term “via Frontend Transport”, it indicates that the email passed through the Frontend Transport service of an Exchange server. This can be seen in the Received headers of the email, showing the path it took through various servers.

4. Suggestion of Blind Email Relaying

The concern arises when these headers suggest that Exchange is configured to relay emails without altering them or without proper checks. This could imply that:

  • The Exchange server is not adequately verifying the sender’s authenticity.
  • The server might be forwarding emails without checking if they come from trusted sources.
  • Such a configuration can be indicative of an open relay, where the server forwards any email it receives, which is highly vulnerable to abuse.

5. Abuses of Open Relays

Open relays are notorious for being exploited by spammers and malicious actors because they can be used to send large volumes of unsolicited emails while obscuring the true origin of the message. This makes it difficult to trace back to the actual sender and can cause the relay server’s IP address to be blacklisted.

https://www.securitynewspaper.com/2023/12/20/how-to-send-spoof-emails-from-domains-that-have-spf-and-dkim-protections/embed/#?secret=pu82rHzNqA#?secret=1UMPUIgHIO

Here’s a detailed breakdown of the key points:

Scenario Breakdown

  1. Attackers Use a Genuine Microsoft Office 365 Account
    • The attackers have managed to send an email from a genuine Microsoft Office 365 account. This could be through compromising an account or using a trial account.
  2. Email Branded as Disney
    • The email is branded as coming from Disney (disney.com). This branding could involve setting the “From” address to appear as if it’s from a Disney domain, which can trick recipients into believing the email is legitimate.
  3. Gmail’s Handling of Outlook’s Servers
    • Gmail has robust mechanisms to handle high volumes of emails from trusted servers like Outlook’s (Microsoft’s email service). These servers are built to send millions of emails per hour, so Gmail will not block them due to rate limits.
  4. SPF (Sender Policy Framework)
    • SPF is a protocol that helps prevent email spoofing by allowing domain owners to specify which mail servers are authorized to send emails on their behalf. The attackers benefit from this because:
      • The email is sent through Microsoft’s official relay server, protection.outlook.com.Disney’s SPF record includes spf.protection.outlook.com, which means emails sent through this relay server are authorized by Disney’s domain.
      .
  5. Spoofed Headers
    • Spoofed headers involve altering the email headers to make the email appear as if it originated from a different source. In this scenario, the attackers have spoofed headers to make the email look like it’s from Disney.
  6. SPF Check Passed
    • Since the email is sent via a server included in Disney’s SPF record (protection.outlook.com), it will pass the SPF check, making it seem legitimate to the recipient’s email server.

DKIM (DomainKeys Identified Mail)

DKIM is another email authentication method that allows the receiver to check if an email claiming to come from a specific domain was indeed authorized by the owner of that domain. This is done by verifying a digital signature added to the email.

Points of Concern

  • SPF Check Passed
    • The email passed the SPF check because it was sent through an authorized server (protection.outlook.com) included in Disney’s SPF record.
  • Spoofed Headers
    • The headers were manipulated to make the email appear as if it came from Disney, which can deceive recipients.
  • Gmail Handling
    • Gmail will trust and not rate-limit emails from Outlook’s servers, ensuring the email is delivered without being flagged as suspicious due to high sending volumes.

Potential for DKIM

To fully understand if the email can pass DKIM checks, we would need to know if the attackers can sign the email with a valid DKIM key. If they manage to:

  • DKIM Alignment
    • Ensure the DKIM signature aligns with the domain in the “From” header (disney.com).
  • Valid DKIM Signature
    • Use a valid DKIM signature from an authorized domain (which would be difficult unless they have compromised Disney’s signing keys or a legitimate sending infrastructure).

Proofpoint and similar services are email security solutions that offer various features to protect organizations from email-based threats, such as phishing, malware, and spam. They act as intermediaries between the sender and recipient, filtering and relaying emails. However, misconfigurations or overly permissive settings in these services can be exploited by attackers. Here’s an explanation of how these services work, their roles, and how they can be exploited:

Roles and Features of Proofpoint-like Services

  1. Email Filtering and Protection
    • Spam and Phishing Detection: Filters out spam and phishing emails.
    • Malware Protection: Scans and blocks emails containing malware or malicious attachments.
    • Content Filtering: Enforces policies on email content, attachments, and links.
  2. Email Relay and Delivery
    • Inbound and Outbound Filtering: Manages and filters both incoming and outgoing emails to ensure compliance and security.
    • Email Routing: Directs emails to the appropriate recipients within an organization.
    • DKIM Signing: Adds DKIM signatures to outgoing emails to authenticate them.
  3. Authentication and Authorization
    • IP-Based Authentication: Uses IP addresses to authenticate incoming email servers.
    • SPF, DKIM, and DMARC Support: Implements these email authentication protocols to prevent spoofing.

How Misconfigurations Allow Exploitation

  1. Permissive IP-Based Authentication
    • Generic Configuration: Proofpoint is often configured to accept emails from entire IP ranges associated with services like Office365 or Google Workspace without specifying particular accounts.
    • IP Range Acceptance: Once a service like Office365 is enabled, Proofpoint accepts emails from any IP within the Office365 range, regardless of the specific account.
  2. Exploitation StepsStep 1: Setting Up the Attack
    • Attacker’s Office365 Account: The attacker sets up or compromises an Office365 account.
    • Spoofing Email Headers: The attacker crafts an email with headers that mimic a legitimate sender, such as Disney.
    Step 2: Leveraging Proofpoint Configuration
    • Sending Spoofed Emails: The attacker sends the spoofed email from their Office365 account.
    • Proofpoint Relay Acceptance: Proofpoint’s permissive configuration accepts the email based on the IP range, without verifying the specific account.
    Step 3: Proofpoint Processing
    • DKIM Signing: Proofpoint processes the email, applying DKIM signatures and ensuring it passes SPF checks because it comes from an authorized IP range.
    • Email Delivery: The email is then delivered to the target’s inbox, appearing legitimate due to the DKIM signature and SPF alignment.

Example of a Permissive Configuration in Proofpoint

  1. Admin Setup
    • Adding Hosted Services: Proofpoint allows administrators to add hosted email services (e.g., Office365) with a single-click configuration that relies on IP-based authentication.
  2. No Specific Account Configuration
    • Generic Acceptance: The setup does not specify which particular accounts are authorized, leading to a scenario where any account within the IP range is accepted.
  3. Exploitation of Misconfiguration
    • Blind Relay: Due to this broad acceptance, attackers can send emails through Proofpoint’s relay, which then processes and delivers them as if they were legitimate.

A recent attack exploited a misconfiguration in Proofpoint’s email routing, allowing millions of spoofed phishing emails to be sent from legitimate domains like Disney and IBM. The attackers used Microsoft 365 tenants to relay emails through Proofpoint, bypassing SPF and DKIM checks, which authenticate emails. This “EchoSpoofing” method capitalized on Proofpoint’s broad IP-based acceptance of Office365 emails. Proofpoint has since implemented stricter configurations to prevent such abuses, emphasizing the need for vigilant security practices.

For more details, visit https://labs.guard.io/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch-3dd6b5417db6

The Domain Name System: Understand Why Domain Name Is Still Relevant

How to Catch a Phish: A Practical Guide to Detecting Phishing Emails 

Step-by-step instructions on what to do if you fall prey to this type of cyber crime.  (Phishing in 2024)

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot

Tags: EchoSpoofing, trusted domains


Sep 25 2023

BIND DNS System Flaws Let Attackers Launch DoS Attacks

Category: DDoS,DNS Attacks — disc7 @ 9:28 am

In a recent disclosure, BIND 9, a widely-used DNS (Domain Name System) server software, has been found vulnerable to two critical security flaws, labeled CVE-2023-4236 and CVE-2023-3341. 

These vulnerabilities, if exploited, could have serious consequences, making it imperative for users to take swift action.

CVE-2023-4236: DNS-over-TLS Query Load Vulnerability

This vulnerability arises from a flaw in the networking code responsible for handling DNS-over-TLS queries in BIND 9. 

Under high DNS-over-TLS query load, an internal data structure is incorrectly reused, leading to an assertion failure. Consequently, a vulnerable named instance may terminate unexpectedly.

Thankfully, this flaw does not affect DNS-over-HTTPS code, as it employs a distinct TLS implementation. However, for those relying on DNS-over-TLS, the impact can be severe.

CVE-2023-3341: Control Channel Stack Exhaustion

The second critical vulnerability, CVE-2023-3341, relates to the control channel code within BIND 9. 

This flaw allows attackers to exploit a stack exhaustion issue by sending specially crafted messages over the control channel. 

This can lead to names unexpectedly terminating, causing potential disruption.

Notably, the attack is effective in environments with limited stack memory available to each process or thread, making it difficult to predict its impact.

For users of BIND 9, immediate action is necessary to address these vulnerabilities. ISC (Internet Systems Consortium), the organization behind BIND, has provided solutions to mitigate these risks.

For CVE-2023-4236:

– Upgrade to BIND 9.18.19 or BIND Supported Preview Edition 9.18.19-S1.

– Consider disabling DNS-over-TLS connections if not required.

For CVE-2023-3341:

– Upgrade to BIND 9.16.44, 9.18.19, or 9.19.17, depending on your current version.

– Ensure that control-channel connections are limited to trusted IP ranges when enabling remote access.

No active exploits have been reported for these vulnerabilities. However, proactive measures are crucial to safeguard your systems against potential threats.

ISC extends its gratitude to the individuals who responsibly reported these vulnerabilities. 

Robert Story from the USC/ISI DNS root server operations team brought CVE-2023-4236 to ISC’s attention, while Eric Sesterhenn from X41 D-Sec GmbH identified CVE-2023-3341.

The Hidden Potential of DNS In Security: Combating Malware, Data Exfiltration, and more – The Guide for Security Professionals

InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: BIND DNS System Flaws, DNS In Security


Aug 20 2023

Microsoft DNS boo-boo breaks Hotmail for users around the globe

Category: DNS Attacks,Information Security — disc7 @ 11:05 pm

https://www.theregister.com/2023/08/21/microsoft_dns_booboo_breaks_hotmail

Someone at Microsoft has some explaining to do after a messed up DNS record caused emails sent from Hotmail accounts using Microsoft’s Outlook service to be rejected and directed to spam folders starting on Thursday.

Late on Thursday evening, Hotmail users began reporting that some emails were being returned with errors related to Sender Policy Framework (SPF), and thus recipient email services were unable “to confirm that [a] message came from a trusted location.” 

SPF, for those unfamiliar with it, is a method of outbound email authentication that helps avoid email spoofing, impersonation and phishing. If, for example, a service like Hotmail were to have one of its subdomains removed from the DNS TXT record that stores its SPF list, then recipient services may assume it’s junk. 

And that appears to be just what happened. 

Reddit users posting to the Sysadmin subreddit verified they were experiencing SPF issues with Hotmail. One user pulled up Hotmail’s SPF record and found that Redmond had made two changes: removing spf.protection.outlook.com from the record, and changing the SPF failure condition from soft to hard. That meant any suspicious messages from Hotmail should be rejected rather than just sent to spam. 

Microsoft support forum advisors confirmed that the issue was known, which was further confirmed by a look at the Office service status page. Per Microsoft: “Some users may receive non-delivery reports when attempting to send emails from hotmail.com.” 

At time of writing, the status page indicated that “a recent change to email authentication” was the potential root cause of the outage. Microsoft said it made a configuration change to remediate impact, but shortly after said the problem may have been worse than it appeared at first glance. 

“We’ve identified that additional configuration entries are impacted, and we’re implementing further configuration changes to resolve the issue,” Microsoft said. Not long after that was posted, Microsoft indicated configuration changes were complete and the problem was fixed. 

Microsoft didn’t respond to our questions about the incident, only saying the issue had been resolved.

Tags: Microsoft DNS


Jan 24 2023

Serious Security: How dEliBeRaTe tYpOs might imProVe DNS security

Category: DNS Attacks — DISC @ 10:41 am

Over the years, we’ve written and spoken on Naked Security many times about the thorny problem of DNS hijacking.

DNS, as you probably know, is short for domain name system, and you’ll often hear it described as the internet’s “telephone directory” or “gazetteer”.

If you’re not familiar with the word gazeteer, it refers to the index at the back of an atlas where you look up, say, Monrovia, Liberia in a convenient alphabetic list, and it says something like 184 - C4. This tells you to turn straight to page 184, and to follow the grid lines down from the letter C at the top of the map, and across from the number 4 on the left. Where the lines meet, you’ll find Monrovia.

For most users, most DNS lookups go out containing a server name, asking for a reply to come back that includes what’s known as its A-record or its AAAA-record.

(A-records are used for 32-bit IPv4 internet numbers, such as 203.0.113.42; AAAA-records are the equivalent answers for a 128-bit IPv6 addresses, such as 2001:db8:15a:d0c::42 – in this article, we’ll just use A-records and IPv4 numbers, but the same security issues apply to the lookup process in both cases.)

Here’s an example, where we’re looking up the imaginary domain name naksec.test via a DNS server that was specially created to track and teach you about DNS traffic.

We’ve used the old-school Linux tool dig, short for domain internet groper, to generate a simple DNS request (dig defaults to looking up A-records) for the server we want:

$ dig +noedns @127.42.42.254 naksec.test

;; QUESTION SECTION:
;naksec.test.			IN	A

;; ANSWER SECTION:
NAKSEC.TEST.		5	IN	A	203.0.113.42

;; Query time: 1 msec
;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP)
;; WHEN: Mon Jan 23 14:38:42 GMT 2023
;; MSG SIZE  rcvd: 56

Here’s how our DNS server dealt with the request, showing a hex dump of the incoming request, and the successful reply that went back:

---> Request from 127.0.0.1:57708 to 127.42.42.254:53
---> 00000000  62 4e 01 20 00 01 00 00  00 00 00 00 06 6e 61 6b  |bN. .........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01           |sec.test.....   |

DNS lookup: A-record for naksec.test ==> A=203.0.113.42

<--- Reply from 127.42.42.254:53 to 127.0.0.1:57708
<--- 00000000  62 4e 84 b0 00 01 00 01  00 00 00 00 06 6e 61 6b  |bN...........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01 06 4e 41  |sec.test......NA|
     00000020  4b 53 45 43 04 54 45 53  54 00 00 01 00 01 00 00  |KSEC.TEST.......|
     00000030  00 05 00 04 cb 00 71 2a                           |......q*        |

Note that, for performance reasons, most DNS requests use UDP, the user datagram protocol, which works on a send-and-hope basis: you fire off a UDP packet at the server you want to talk to, and then wait to see if a reply comes back.

This makes UDP much simpler and faster than its big cousin TCP, the transmission control protocol, which, as its name suggests, automatically takes care of lots of details that UDP doesn’t.

Notably, TCP deals with detecting data gets lost and asking foir it again; ensuring that any chunks of data arrive in the right order; and providing a single network connection that, once set up, can be used for sending and receiving at the same time.

UDP doesn’t have the concept of a “connection”, so that requests and replies essentially travel independently:

  • A DNS request arrives at the DNS server in a UDP packet of its own.
  • The DNS server keeps a record of which computer sent that particular packet.
  • The server sets about finding an answer to send back, or deciding that there isn’t one.
  • The server sends a reply to the original sender, using a second UDP packet.

From the level of the operating system or the network, those two UDP packets above are independent, standalone transmissions – they aren’t tied together as part of the same digital connection.

It’s up to the server to remember which client to send each reply to; and it’s up to the client to figure out which replies relate to which requests it originally sent out.

How can you be sure?

Learning CoreDNS: Configuring DNS for Cloud Native Environments

InfoSec books | InfoSec tools | InfoSec services

Tags: DNS flaw, DNS Security


Jul 11 2022

The impact of DNS attacks on global organizations

Category: DNS Attacks,Information Security — DISC @ 9:32 am

Often we see stories about cyber attacks that breached an organisations’ security parameters, and advice on how we can protect against future threats. However, what is often missed, is just how these threat actors managed to breach a system, and as such, the fact that the Domain Name System (DNS) probably played a very large role in the attacker’s entry point.

In this Help Net Security video, Chris Buijs, Chief Evangelist at EfficientIP, talks about the importance of making the DNS as part of an organisation’s security strategy.

Internet

DNSSEC Mastery

Tags: DNS attacks, DNSSEC


May 03 2022

A DNS flaw impacts a library used by millions of IoT devices

Category: DNS Attacks — DISC @ 8:29 am

A vulnerability in the domain name system (DNS) component of the uClibc library impacts millions of IoT products.

Nozomi Networks warns of a vulnerability, tracked as CVE-2022-05-02, in the domain name system (DNS) component of the uClibc library which is used by a large number of IoT products. The flaw also affects DNS implementation of all versions of the uClibc-ng library, which is a fork specifically designed for OpenWRT, a common OS for routers used in various critical infrastructure sectors.

An attacker can exploit the vulnerability for DNS poisoning or DNS spoofing and redirect the victim to a malicious website instead of the legitimate one.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.” reads the advisory published by Nozomi Networks.

The uClibc library is used by major vendors, including Linksys, Netgear, and Axis, or Linux distributions such as Embedded Gentoo.

Security experts did not disclose the details of the flaw because the vendor has yet to address it.

The researchers from Nozomi discovered the issue by reviewing the trace of DNS requests performed by an IoT device in their test environment. They were able to determine the pattern of DNS requests performed from the output of Wireshark, the transaction ID is first incremental, then resets to the value 0x2, then is incremental again. The transaction ID of the requests was predictable, a circumstance that could allow an attacker to perform DNS poisoning under certain circumstances.

DNS

“A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.” continues the advisory. “Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”

If the OS uses randomization of the source port, the only way to exploit the issue is to bruteforce the 16-bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate response.

“As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.” concludes Nozomi.

Managing Mission – Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

DNSSEC Mastery

Tags: DNS flaw, IoT devices


Mar 17 2022

B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Category: DNS Attacks,Linux Security,Log4j — DISC @ 8:50 am

Researchers uncovered a new Linux botnet, tracked as B1txor20, that exploits the Log4J vulnerability and DNS tunnel.

Researchers from Qihoo 360’s Netlab have discovered a new backdoor used to infect Linux systems and include them in a botnet tracked as B1txor20.

The malware was first spotted on February 9, 2022, when 360Netlab’s honeypot system captured an unknown ELF file that was spreading by exploiting the Log4J vulnerability.

The name B1txor20 is based on the file name “b1t” used for the propagation and the XOR encryption algorithm, and the RC4 algorithm key length of 20 bytes.

The B1txor20 Linux backdoor uses DNS Tunnel technology for C2 communications, below is the list of the main features implemented by the threat:

  • SHELL
  • Proxy
  • Execute arbitrary commands
  • Install Rootkit
  • Upload sensitive information
B1txor20

The researchers also noticed the presence of many developed features that have yet to be used, and some of them are affected by bugs. Experts believe the B1txor20 botnet is under development.

“In short, B1txor20 is a Backdoor for the Linux platform, which uses DNS Tunnel technology to build C2 communication channels. In addition to the traditional backdoor functions, B1txor20 also has functions such as opening Socket5 proxy and remotely downloading and installing Rootkit.” reads the analysis published by the experts.

Once the system has been compromised, the threat connects the C2 using the DNS tunnel and retrieves and executes commands sent by the server. The researchers noticed that the bot supports a total of 14 commands that allows it to execute arbitrary commands, upload system information, manipulate files, starting and stopping proxy services, and creating reverse shells.

“Generally speaking, the scenario of malware using DNS Tunnel is as follows: Bot sends the stolen sensitive information, command execution results, and any other information that needs to be delivered, after hiding it using specific encoding techniques, to C2 as a DNS request; After receiving the request, C2 sends the payload to the Bot side as a response to the DNS request. In this way, Bot and C2 achieve communication with the help of DNS protocol.” continues the analysis.

The post includes additional technical details along with Indicators of Compromise (IoCs) for this threat.

Indicators of Compromise Associated with BlackByte Ransomware: Joint Cybersecurity Advisory

Tags: B1txor20 Linux botnet, Indicators of Compromise, IoC


Apr 09 2021

How do I select an attack detection solution for my business?

Category: Attack Matrix,Cyber Attack,DNS Attacks,MitM Attack — DISC @ 8:33 am

When selecting an attack detection solution, no single product will provide the adequate detection needed that is required to detect and defend against the current advanced threat landscape. The holistic aspect of defending against threat actors requires technology, expertise, and intelligence.

The technology should be a platform of integrated technologies providing detection at each point of entry that a threat actor may use such as email, endpoint, network, and public cloud. These should not be disparate technologies that don’t work together to holistically defend the organization.

We must use technologies that can scale against threat actors that have a very large number of resources. The technology should also be driven by intelligence cultivated from the frontlines where incident responders have an unmatched advantage. It is also important to remember that post-exploitation, threat actors masquerade as your own employee’s making it difficult to know legitimate from non-legitimate activity occurring on the network or your endpoints.

This is where intelligence and expertise is extremely valuable to determine when a threat actor is operating within the organization. Being able to identify the threat actors “calling card” and potential next moves, is paramount. While many solutions will claim they defend against advanced threats, it is important to understand the experience that a vendor has and how that is included into their product offering.

How do I select an attack detection solution for my business?

Tags: attack detection solution


Jan 20 2021

List of DNSpooq vulnerability advisories, patches, and updates

Category: DNS Attacks,Information Security — DISC @ 11:37 am
DNSpooq

Yesterday, seven Dnsmasq vulnerabilities were disclosed, collectively known as DNSPooq, that attackers can use to launch DNS Cache Poisoning, denial of service, and possibly remote code execution attacks, on affected devices.

Dnsmasq is a widely used open-source Domain Name System (DNS) forwarding application commonly installed on routers, operating systems, access points, and other networking equipment. 

Vendors have started to release information on how customers can protect themselves from DNSPooq. To make it easier to find this information, BleepingComputer will be listing security advisories as they are released. 

The related CVEs from JSOF’s DNSpooq advisory are listed below, along with their descriptions.

NameCVSSDescription
CVE-2020-256818.1Dnsmasq versions before 2.83are susceptible to a heap-based buffer overflow in sort_rrset() when DNSSEC is used. This can allow a remote attacker to write arbitrary data into target device’s memory that can lead to memory corruption and other unexpected behaviors on the target device.
CVE-2020-256828.1Dnsmasq versions before 2.83 are susceptible to buffer overflow in extract_name() function due to missing length check, when DNSSEC is enabled. This can allow a remote attacker to cause memory corruption on the target device.
CVE-2020-256835.9Dnsmasq versions before 2.83 are susceptible to a heap-based buffer overflow when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256875.9Dnsmasq versions before 2.83are vulnerable to a heap-based buffer overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256844A lack of proper address/port check implemented in dnsmasq versions
CVE-2020-256854A lack of query resource name (RRNAME) checks implemented in dnsmasq’s versions before 2.83 reply_query function allows remote attackers to spoof DNS traffic that can lead to DNS cache poisoning.
CVE-2020-256864Multiple DNS query requests for the same resource name (RRNAME) by dnsmasq versions before 2.83 allows for remote attackers to spoof DNS traffic, using a birthday attack (RFC 5452), that can lead to DNS cache poisoning.

BleepingComputer suggests checking this page throughout the coming days to see if new information is available for devices you may be using.

Source: List of DNSpooq vulnerability advisories, patches, and updates


Aug 06 2020

Hackers abuse lookalike domains and favicons for credit card theft

Category: DNS Attacks,Hacking — DISC @ 10:58 pm

Hackers are abusing a new technique: combining homoglyph domains with favicons to conduct credit card skimming attacks.

Source: Hackers abuse lookalike domains and favicons for credit card theft



Credit Card Scammers on the Dark Web
httpv://www.youtube.com/watch?v=jT-jmq8KBw0



Preventing Credit Card Fraud: A Complete Guide for Everyone from Merchants to Consumers




PCI Compliance

Download a Security Risk Assessment Steps paper!

Subscribe to DISC InfoSec blog by Email

Take an awareness quiz to test your basic cybersecurity knowledge

DISC InfoSec 🔒 securing the business 🔒 via latest InfoSec titles




Tags: abuse lookalike domains, credit card theft


Feb 20 2019

A Deep Dive on the Recent Widespread DNS Hijacking Attacks

Category: DNS Attacks — DISC @ 5:24 pm

The U.S. government — along with a number of leading security companies — recently warned about a series of highly complex and widespread attacks that allowed suspected Iranian hackers to siphon huge volumes of email passwords and other sensitive data from multiple governments and private companies. But to date, the specifics of exactly how that attack went down and who was hit have remained shrouded in secrecy.

  • Source: A Deep Dive on the Recent Widespread DNS Hijacking Attacks