How can security teams detect LunarWeb activity?

What LunarWeb activity looks like in network and endpoint telemetry

Detection starts with the pattern, not the label. The most useful signals are web-delivered command traffic, browser or script execution that is out of step with normal user behaviour, and outbound connections that appear periodic, encoded, or tied to unusual domains. Treat this as a correlation problem across endpoint, proxy, and DNS data rather than a single-alert problem.

When a browser process, scripting host, or office application is repeatedly reaching out over HTTP or HTTPS, the question is whether the traffic is doing work that should normally belong to a legitimate application. That includes long-lived beacons, parameters that look machine-generated, and downloads that arrive from infrastructure the environment rarely uses.

Malware Guide is a useful reference point for recognising loader, RAT, obfuscation, and evasion patterns that often sit behind this kind of traffic.

How to separate suspicious web activity from normal business browsing

The key is to compare behaviour against the host’s role. A workstation used for documents and line-of-business applications should not regularly execute scripts, spawn unexpected child processes, or download content from rarely seen domains as part of a steady communication pattern. The same is true for browsers or helper processes making outbound requests that do not match known SaaS, update, or collaboration services.

Proxy and DNS records help narrow the search. Look for domains with short-lived exposure, newly observed names, unusual subdomain depth, or repeated lookups that map to the same remote service. On the endpoint, validate whether the initiating process is expected to make network calls at all, and whether the timing aligns with user activity or instead suggests automated tasking.

NIST Cybersecurity Framework 2.0 fits this detection workflow because it treats telemetry correlation, anomaly identification, and response readiness as connected functions rather than separate tasks.

What to confirm before you treat it as malicious

Do not stop at “odd traffic.” Confirm whether the same host also shows credential collection, token theft, privilege escalation, or lateral movement attempts. Those behaviours move the event from suspicious web activity into an active compromise path. Periodic connections plus encoded content are especially concerning when they appear alongside failed logons, new local admin creation, or access to sensitive resources that the user normally never touches.

If the behaviour is reproducible, preserve the evidence chain before containment changes the trace. That usually means keeping relevant endpoint artefacts, proxy records, DNS resolution history, and any captured URLs or parameters that demonstrate the command channel. The objective is to prove the sequence, not just the presence, of suspicious activity.

MITRE ATT&CK Enterprise Matrix helps teams map the observed behaviour to credential access, privilege escalation, and command-and-control patterns so the response can follow the likely attack path.

Risk and Threat Considerations

Web-based command traffic is risky because it can blend into ordinary browsing, proxy logs, and allowed outbound HTTPS, which makes early-stage compromise easier to overlook. Once the channel is established, the same infrastructure can support payload delivery, tasking, credential theft, and follow-on access from the same host.

Failure mechanism: The attacker hides command-and-control in traffic that looks like normal web activity, then uses periodic callbacks, encoded parameters, or benign-looking domains to reduce detection and sustain access.

Impact: If the channel is missed, the host can continue to leak credentials, support privilege escalation, and provide a stable foothold for deeper compromise across the environment.

Practitioner Guidance

What to prioritise: Start with hosts that show both unusual web traffic and any sign of credential collection or privilege escalation, because that combination is more actionable than isolated beaconing. Correlate endpoint process trees with proxy and DNS records before declaring the traffic benign.

What to verify: Check whether the initiating process is expected to make outbound calls, whether the destination is normal for that asset class, and whether the timing is user-driven or automated. If the same pattern appears across multiple hosts, treat it as a campaign indicator rather than an isolated anomaly.

Practitioner takeaway: The decisive clue is usually not the request itself, but the mismatch between the process, the destination, and the business role of the host.

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?