1. Introduction

This document explains what actions to take when SecureDNS has triggered a Botnet or APT alert on your network.

Important: Every domain or FQDN listed in the alert email has been blocked by SecureDNS.
No connection was established to the flagged destination.
Your endpoint is protected at DNS level SecureDNS prevented the query from resolving, which means no data was exchanged with the malicious infrastructure.

2. Understanding the Alert Categories

SecureDNS uses two high-priority categories that trigger immediate alerting: Botnet and APT. They differ in nature, origin, and the level of urgency they require.

2.1 Botnet

A botnet is a network of compromised devices (bots) that are remotely controlled by a threat actor, typically through a Command & Control (C2) server. Infected devices communicate back to this infrastructure to receive instructions, exfiltrate data, or participate in coordinated attacks such as DDoS campaigns.

A Botnet trigger means a device on your network attempted to resolve a domain associated with known botnet infrastructure provided by one of our vendors.

This could indicate:

• A device infected with malware that is attempting to check in with its C2 server
• A Potentially Unwanted Program (PUP) or adware making background requests
• A browser extension with malicious behavior
• A visited website with an embedded reference to a blocklisted domain (e.g. via ad networks, tracking scripts, or iframes) this is a common cause and does not always indicate an active infection
• A mobile device connected to your internal network running a compromised application

Urgency: Medium to High investigate the origin. If this has a website-based explanation such as embedded references, the risk is lower. If there is evidence of malware or it originates from a malicious process, service, or application, treat it as a potential active infection.

2.2 APT (Advanced Persistent Threat)

An APT refers to a sophisticated, targeted attack typically carried out by a well-resourced threat actor (nation-state group, cybercriminal organization) with the intent to establish long-term, stealthy access to a network. APT infrastructure is used for reconnaissance, lateral movement, data exfiltration, and persistence.

An APT trigger means a device on your network attempted to resolve a domain associated with known APT infrastructure or tooling provided by one of our vendors. This is a more serious indicator than a Botnet trigger because:

• APT actors could specifically target organizations, rather than broadly infecting random devices
• APT malware is designed to be stealthy and persistent it may not be visible to standard antivirus
• The presence of an APT-related DNS query suggests a device may already be compromised and communicating with attacker-controlled infrastructure

Urgency: High do not dismiss this as a false positive without thorough investigation.

2.3 Key Differences at a Glance

3. Before You Start

3.1 Check the Internal IP, Hostname, and Site fields

In the alert email, each detection includes several fields that help you narrow down the origin of the query before you start investigating.

• If an Internal IP is listed: A device on your network made the query. Use this to target your investigation directly.
• If a Hostname is listed: Your DHCP logs are being shared with SecureDNS, which allows us to match the IP to a device name at the time of the query. Use the hostname to immediately identify the device without needing to cross-reference your DHCP leases manually.
• If a Public IP is listed: Your organisation has multiple sites or internet breakout points. The public IP indicates which site or location the query originated from, allowing you to scope your investigation to the correct network segment.
• If Internal IP shows as N/A: Your local DNS queries are not being shared with SecureDNS. You will need to consult your local DNS server logs to find the originating client IP. Match the timestamp from the alert against your DNS log entries for the flagged domain.

To enable client IP enrichment or hostname resolution via DHCP logs please check the following links: DNS Enrichment or DHCP Enrichment. This can also be done via the Self Onboarding PowerShell Script. Each of these significantly reduces the time needed to identify the source device.

3.2 Establish a timeline and available tooling

Note the timeframe from the alert. You will need this to correlate events across your DNS logs, EDR telemetry, and browser history.

If you have SentinelOne, check the URL events on the identified device around the timeframe of the alert. This allows you to:

• See which URLs and domains the device contacted or attempted to contact
• Perform a URL inspection in an isolated virtual environment to safely load the suspected page and verify whether the blocked domain or FQDN appears in the page source, HTML, or loaded scripts, without exposing your environment to any risk
• Confirm whether the trigger was caused by an embedded reference on a visited website before escalating further

This is particularly useful for ruling out website-embedded causes early and is faster than manually checking browser history.

4. Investigation Steps

Work through these steps in order. Stop when you have identified the source, not every step will be necessary.

Step 1 Search your EDR / XDR platform

Search for the blocked domain or FQDN in your EDR/XDR tool. This is typically the fastest way to identify the originating device and process.

Look for:

• The device that generated the query
• The process or application responsible for the DNS request
• Any associated parent processes, scheduled tasks, or persistence mechanisms
• Related alerts or detections in the same timeframe

If you have SentinelOne: Open Deep Visibility and search for events on the identified device within a window of 1 minute before and 1 minute after the alert timestamp. Filter on URL events and check whether the source process of the blocked query was a web browser. Only proceed with the steps below if a browser process is confirmed as the origin if the source is a non-browser process, skip to the malicious process path.

If a browser is confirmed as the source, review the URLs visited in that same Deep Visibility window. For any URL that could be the cause, open it in SentinelOne's isolated virtual environment. Once the page loads, open the browser inspector (F12), go to the Network tab, and make sure Preserve Log is enabled before navigating to the URL. After the page has fully loaded, use Ctrl+F to search within the network requests for the blocked domain or FQDN. If it appears in the network log, the trigger was caused by an embedded reference on that page — an ad, analytics script, or other third-party resource and is not indicative of an active infection on the device.

• If your EDR identifies a known malicious process: proceed to Step 5 (Remediation).
• If your EDR shows a browser process as the origin: continue to Step 3.
• If your EDR has no results: continue to Step 2.

Step 2 Consult your DNS server logs

If the Internal IP in your alert shows as N/A and no hostname is available, check your internal DNS server logs to identify the originating device.

Should you already be sending your internal DNS logs to us through Filebeat, please let us know so we can investigate the root cause of why no internal IP address is showing up.

If your organisation has multiple sites, use the Public IP field to confirm which location to focus on before digging into DNS logs.

Filter your DNS logs on:

• The flagged domain or FQDN
• The timeframe from the alert

This will give you the client IP of the device that made the request. Once identified, focus your EDR investigation on that specific device.

Step 3 Verify website-embedded cause

If your EDR points to a browser process as the origin, the trigger may have been caused by a website the user visited that contained an embedded reference to the blocked domain or FQDN for example via an advertising network, analytics script, social widget, or iframe. This is a common cause and does not necessarily indicate an active infection.

If you have SentinelOne: Use the URL inspection feature to load the suspected page in an isolated environment and check whether the blocked domain appears in the page source or loaded resources. This is the most reliable and safest way to confirm an embedded reference.

Without SentinelOne: Review the browser history on the identified device around the timeframe of the alert and look for sites visited shortly before the detection timestamp. You can manually inspect the page source of suspected sites, but do so carefully and preferably from an isolated or non-production device.

In both cases, also check installed browser extensions and disable any that are unfamiliar or recently installed a malicious extension can generate background DNS queries that appear identical to browser-origin traffic.

If a visited website is confirmed as the cause and no malicious process or extension is found, the risk is significantly lower. Document your findings and monitor for recurrence.

Step 4 Check for mobile devices

If no desktop or server source has been identified, consider whether a mobile device connected to your internal network could be responsible.

Mobile devices that use your internal DNS resolvers (directly or via Wi-Fi) will route their DNS queries through SecureDNS. A compromised mobile app can trigger the same alerts.

Check which mobile devices were connected to your network during the alert timeframe and whether any recently installed applications could be the source.

Step 5 Remediation

If a malicious process, extension, or application has been identified:

1. Isolate the device from the network to prevent further communication or lateral movement
2. Run a full scan with your EDR/AV tool in an elevated or offline mode if possible. If you have SentinelOne, trigger a full disk scan and review the threat timeline on the isolated device
3. Remove identified threats malware, PUPs, malicious extensions, or compromised applications
4. Review persistence mechanisms scheduled tasks, startup entries, browser extensions, and registry run keys
5. Reset credentials for any accounts that were active on the compromised device, particularly if an APT trigger was involved
6. Monitor the device after remediation for recurring SecureDNS triggers

5. Determining Next Steps

Use the following as a guide after completing your investigation:

6. Contact & Escalation

If after following this guide you are unable to identify or remove the source of the malicious queries, or if you are dealing with an APT trigger that requires further assistance, contact Secutec Support:

• Email: support@secutec.com
• Phone: 03/877.82.92

Please have the following ready when contacting support:

• The alert email or CSV with the flagged domains and timeframe
• The identified (or suspected) device
• A summary of the investigation steps already performed