A workstation keeps contacting an unfamiliar domain every minute. The proxy allows the requests. No one recognizes the hostname. Blocking it might interrupt a business application, but leaving it alone could give a compromised device more time to communicate. Your next move needs evidence, starting with what the proxy actually recorded.
A useful investigation connects four things: the outbound request, the device behind it, the destination, and the process responsible. Follow the steps below to build that connection and choose an access-control response you can defend.
Your Investigation Priorities
- Preserve the original logs before narrowing your search.
- Match client addresses to devices at the time of each request.
- Compare domain registration details with traffic and endpoint evidence.
- Apply the narrowest access restriction that addresses the threat.
- Verify enforcement and check for continued activity.
1. Preserve the Evidence and Define the Time Window
Start by recording the suspicious hostname, alert time, proxy node, and reason for concern. An unfamiliar name alone is weak evidence. An unfamiliar name contacted by a newly installed process deserves closer attention.
Export the relevant raw logs to your approved investigation location. Keep their original timestamps and record the time zone. If your proxy, endpoint platform, and DHCP server use different time settings, normalize the working timeline to UTC. Preserve the original values alongside it.
Choose an initial window around the alert, perhaps 30 minutes before and after. Expand it once you understand the activity. Search across every proxy node that could have handled the connection, including remote-user gateways.
Capture these fields where your platform provides them:
- Timestamp, client IP address, authenticated identity, and proxy node.
- Destination hostname, destination IP address, port, and HTTP method.
- URL path, response status, policy action, and matched rule.
- Bytes sent, bytes received, session duration, and user-agent value.
- TLS inspection status, hostname source, and relevant certificate details.
Keep the investigation within your organization’s access and retention rules. Full URLs can contain session tokens or personal information. Share only the fields needed for the case.
2. Filter the Logs Without Losing Related Requests
Search the exact hostname first. Use parsed hostname fields instead of a broad text search when possible. A domain string inside a URL parameter does not mean the device connected to that domain.
Normalize hostname case and handle trailing dots consistently. Keep the original field available for review. If internationalized names appear, compare their encoded and displayed forms to avoid confusing visually similar names.
- Find the initial request. Confirm the timestamp, destination, client address, and recorded policy action.
- Expand to related hostnames. Search the parent domain and its subdomains using hostname boundaries.
- Group the activity. Count requests by device, identity, destination, and time interval.
- Review nearby events. Check requests immediately before and after the suspicious connection for redirects, downloads, or authentication activity.
- Extend the timeline. Search retained history to establish the earliest observed request and changes in frequency.
For a hostname such as sync.example.net, a parent-domain filter should match example.net and names ending in .example.net. It should not match example.net.attacker.invalid. Check your product’s matching behavior before trusting a suffix rule.
Separate attempted requests from completed connections. A denied request shows an attempt. An allowed CONNECT response shows that the proxy permitted a tunnel, but it does not establish which application data crossed it.
Check how your proxy defines byte counters. Some counters describe the client side of a session; others describe upstream traffic. Cache hits and failed connections can also change how a record should be interpreted.
3. Identify the Endpoint Behind Each Client Address
A client IP address is a starting point, not a permanent device identity. DHCP leases change. Shared workstations serve several people. A proxy may also see a firewall or gateway address instead of the original client.
Match the logged address to DHCP, VPN, wireless, or address-translation records at the event time. Use the hostname and device identifier from your endpoint platform to confirm the match. A current lease lookup can point to the wrong machine when you are investigating older traffic.
Compare that result with the proxy’s authenticated identity. Service accounts, shared credentials, and background applications can complicate attribution. Keep the observed account separate from the person you believe was using the device.
Connect the Request to a Running Process
On the affected endpoint, search network telemetry for the destination and timestamp. Look for the executable path, file hash, signer, command line, parent process, and logged-in session. These details help distinguish an approved updater from an unexpected script.
If the browser made the request, inspect nearby browser activity and extensions. The user may have opened a normal website that loaded a third-party resource. Avoid assuming they intentionally visited every domain in the proxy logs.
When historical process telemetry is unavailable, record that gap. Current process listings cannot prove which program made yesterday’s connection. Continue with the evidence you have and keep your confidence level explicit.
4. Read the Traffic Pattern Before Judging the Domain
Compare request timing, volume, and endpoint spread. Repeated connections at steady intervals deserve attention, but legitimate monitoring agents and update services also behave that way. Ask whether the timing fits the application you identified.
Review outbound and inbound volume separately. A workstation sending an unusual amount of data to a destination it has never contacted warrants investigation. Small requests can still carry sensitive data, though, and large transfers can be routine backups.
Check whether the activity started after a software deployment, browser update, or user action. Requests across many managed devices shortly after an approved rollout may have a straightforward explanation. Matching activity across unrelated devices can also reflect a shared compromise, so confirm the responsible process.
Know your visibility limits. Without TLS inspection, you may have a tunnel destination and byte counts but no URL path or request content. DNS records, proxy hostnames, and endpoint connections can also disagree because of caching, shared hosting, and different observation times.
5. Check Registration Details and Threat Intelligence
Once you have a traffic timeline, use WHOIS Lookup to check domain registration details. Record the creation date, registrar, domain status, nameservers, and lookup time when those fields are available. Keep field labels with the values, since a registration date and an update date answer different questions.
Registration research may require RDAP when traditional WHOIS data is unavailable. Missing fields or an empty response do not establish that a domain is safe, malicious, or unregistered. Privacy protection and redacted contact information also do not establish malicious intent.
Compare registration dates with your first observed request. A domain created shortly before unusual outbound activity adds context. It becomes more concerning when endpoint evidence also shows an unexpected executable or script. Domain age alone is insufficient grounds for a malware verdict.
Older domains need scrutiny too. A long-established site can be compromised or change operators. A recent record update may reflect routine maintenance. Registration findings should support the investigation rather than decide it.
Check Whether Intelligence Matches Your Observation
Search your approved threat-intelligence sources for the exact hostname, parent domain, resolved addresses, and relevant file hashes. Review the report date, confidence, and stated behavior. A stale report about a shared IP address may have little bearing on the hostname in your logs.
A domain with no reputation history remains unknown. An absence of detections is not proof of safety. Compare intelligence with your traffic pattern, process evidence, and business context before blocking or allowing access.
Keep active checks in an approved analysis environment. Opening the destination from an administrator’s everyday browser can create new exposure and contaminate the timeline. Passive records and existing telemetry often answer the initial questions.
6. Choose an Access-Control Response That Fits the Evidence
State the suspected behavior before choosing a control. Are you stopping a confirmed malicious connection, limiting an unexplained upload, or reviewing an unfamiliar software dependency? Each case calls for a different scope.
Match Evidence to an Access Decision
| Evidence | Initial Response | Follow-Up Check |
|---|---|---|
| Confirmed malicious process contacting the domain | Block the destination and contain affected endpoints through the incident process. | Search for related processes, destinations, and devices. |
| Unexplained traffic with several supporting risk signals | Apply a temporary, scoped restriction while investigating. | Confirm process ownership and review business impact. |
| Approved application with expected traffic and verified ownership | Permit access within the application’s required scope. | Document the dependency and monitor meaningful changes. |
| Unfamiliar registration details without supporting threat evidence | Gather more evidence and apply existing policy. | Review endpoint activity, request timing, and intelligence. |
Prefer an exact-hostname restriction when it addresses the behavior. Blocking a parent domain can interrupt unrelated services. Blocking a shared hosting address can affect many separate organizations. Expand the scope when evidence supports it.
Check rule order, user groups, exceptions, and hostname matching. Confirm that the proxy can enforce the rule with the information visible in that connection. A URL-path rule needs visibility that a tunnel-only session may not provide.
Give temporary restrictions an owner and review date. Record a rollback method and a business contact. Active malicious traffic may require immediate containment, but the change still needs a clear record.
7. Verify the Block and Search for Continued Activity
After applying a rule, confirm that it reached every relevant proxy node. Use an approved test method and inspect the resulting logs. Check the matched rule and policy action instead of relying on a browser error message.
Existing sessions may continue depending on the product and configuration. Determine whether they must be terminated separately. If the traffic persists, check for alternate proxies, direct internet access, remote-user paths, and destinations outside the rule’s scope.
Review endpoint telemetry again. A drop in proxy requests does not prove that the underlying process has stopped. Look for retries, new hostnames, or other connection methods. Handle confirmed compromise through your incident-response process.
Watch for application failures after enforcement. If a restriction interrupts legitimate work, validate the dependency before creating an exception. Keep any exception limited to the required devices, identities, destinations, and ports your platform can reliably control.
Leave a Clear Trail for the Next Suspicious Request
Close the investigation with a short, useful case record. Capture the affected devices, time window, responsible process, registration observations, intelligence findings, access decision, and verification result. Explain the evidence that changed your judgment.
Keep unresolved questions visible. If process attribution was unavailable, say that. If a temporary block remains, assign its review. Save useful searches so another administrator can repeat the analysis without rebuilding it from scratch.
The result should be a defensible decision and a traceable path to it. That makes the next unfamiliar domain easier to assess, whether it belongs to a routine application or a device that needs immediate attention.