How can security teams detect web protocols?

What security teams should look for in web traffic

Detection starts with distinguishing ordinary browsing from activity that should not exist on a given host. HTTP and HTTPS on endpoints, servers, and infrastructure nodes become more suspicious when the process is unusual, the destination is unexpected, or the traffic pattern does not fit the role of the asset. User agents, methods, certificate details, and request cadence are often enough to separate routine application use from scripted abuse.

For defenders, the most useful lens is not “is this web traffic?” but “is this system supposed to generate it, and does the pattern match its function?” Web protocol visibility is strongest when proxy logs, DNS telemetry, and endpoint data are read together. That combination helps expose covert web-based command-and-control, exfiltration, and fallback channels that look benign if each source is reviewed in isolation. NHIMG’s Command and Control (C2) Guide is the most direct companion for this detection problem because it covers beaconing, JA4 fingerprints, DNS analytics, and egress filtering in the same workflow.

Another practical clue is role mismatch. A file server, batch job host, database node, or management system making routine outbound web requests often merits review, especially when the traffic is to consumer cloud endpoints, newly seen infrastructure, or destinations with no business justification. Normal web use usually has context, such as a browser process, a known SaaS domain, or a documented application dependency; malicious use often borrows those same protocols to hide in plain sight.

Which telemetry patterns are most useful for protocol detection?

Protocol detection works best when teams build patterns rather than rely on single indicators. HTTP methods that do not fit the application, scripts embedded in responses, odd headers, repeated low-volume polling, and certificate anomalies can all point to hidden automation or abuse. HTTPS in particular can conceal activity unless teams inspect the metadata that still remains visible, including SNI, certificate chains, timing, size, and destination reputation.

DNS is a valuable companion signal because web-beaconing and browser-like tunnelling often depend on domain lookups, dynamically generated hostnames, or unusual resolution behaviour. Endpoint telemetry adds the missing context by identifying which process opened the connection, whether the destination was launched from a browser or service binary, and whether the request aligns with the host’s normal role. When those layers are correlated, defenders can distinguish a legitimate web application from covert use of web protocols as transport.

That same correlation also helps separate common administration tools, update services, and sanctioned automation from suspicious external web activity. A host can use HTTP and HTTPS legitimately, but the burden of proof rises when the asset is not a user workstation, when the traffic volume is sparse and regular, or when the connection pattern appears designed to blend into everyday browsing. NHIMG’s Secure Web Gateway and Web Filtering Guide is useful here because it covers proxy logging, protective DNS, and bypass risks that directly affect how well web protocols can be observed.

For teams doing discovery and triage, the Attack Surface Management Guide is also relevant because unexpected web services, exposed interfaces, and shadow infrastructure often create the very traffic paths defenders later need to detect and explain.

How to turn web protocol visibility into operational detection

Detection becomes practical when teams define what “normal web use” looks like by asset class, then alert on deviations. End-user systems, servers, and appliances should not all be judged against the same baseline. A workstation browsing to many destinations is normal; a service account host opening outbound HTTPS to a small set of unrelated domains may warrant immediate review. The goal is to identify protocol use that is technically valid but operationally implausible.

Teams should also look for evidence of staging and follow-on activity. Web protocols are frequently used to retrieve payloads, host scripts, move data out, or proxy command traffic through common services. If a host suddenly makes web requests after being quiet, or if requests coincide with archive creation, credential use, or unusual parent-child process chains, treat that as more than a networking anomaly. The Web Application Attacks Guide helps frame the request patterns and payload abuse that defenders may encounter when web traffic is being used offensively.

Web protocol detection also improves when defenders maintain a clean inventory of approved web-facing services and expected egress paths. That makes it easier to spot rogue browser processes, covert update channels, and hostnames that were never meant to appear in production traffic. If the organisation already has strong egress controls, the remaining challenge is usually not volume, it is fidelity: making sure the telemetry shows enough of the request to explain why it is normal or suspicious.

Risk and Threat Considerations

Web protocols are attractive to attackers because they are ubiquitous, allowed through many networks, and easy to disguise as ordinary business activity. That makes HTTP and HTTPS useful for covert command-and-control, payload retrieval, and exfiltration, especially when defenders focus on ports alone and miss the surrounding behaviour.

Failure mechanism: Visibility fails when teams inspect only firewall allowlists or raw destination counts, without tying the traffic to process, role, certificate, and DNS context. Adversaries can then hide behind common web channels, use legitimate-looking user agents, or blend malicious requests into normal proxy and browser traffic.

Impact: The result is delayed detection of compromise, missed exfiltration, and weaker containment because the malicious traffic looks like routine web use until the environment is already mapped and data has already moved.

Practitioner Guidance

What to prioritise: Start with assets that should not be web clients at all, then move to endpoints that should use web protocols only through approved proxies or gateways. Those two groups produce the highest-value alerts because any HTTP or HTTPS activity is more likely to be meaningful.

What to verify: For each suspicious connection, verify the source process, destination reputation, certificate pattern, DNS resolution path, and whether the activity fits the asset’s business role. If those five elements do not line up, treat the traffic as a detection event, not a benign browsing exception.

What good looks like: You can explain each major web connection by host role, process, and destination purpose. When a service or server uses web protocols, the team can say why it is expected, what proxy or gateway path it should take, and what evidence proves the request is normal.

Practitioner takeaway: Web protocol detection is strongest when traffic metadata, process context, and asset role are correlated, because the protocol itself is common while the legitimacy of the behaviour is highly contextual.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?