New malicious infrastructure has surfaced. Quietly.
A pulse on AlienVault OTX has flagged a single IPv4 address, 80.200.28.28, alongside two hostnames operating under the .lhr.life tunnelling domain. The cluster looks consistent with active command-and-control or data exfiltration activity in the wild. No corroborating sources were available at the time of writing, so the analysis below draws directly from the OTX pulse data and should be weighed accordingly.
The .lhr.life domain pattern is associated with localhost.run, a legitimate SSH tunnelling service that lets users expose local servers to the internet through a public URL. Attackers abuse this kind of service deliberately. It's cheap, quick to spin up, and the traffic blends in with legitimate developer activity on many networks. If you're not specifically monitoring for tunnelling services in outbound traffic, connections to these hostnames will likely pass through your perimeter unnoticed. Building habits around spotting suspicious outbound activity is what turns this kind of traffic from invisible into actionable.
The IPv4 address 80.200.28.28 appearing alongside these tunnelled hostnames is significant. It suggests the threat actor is operating a dual-track infrastructure: a static IP for direct communication and ephemeral tunnel endpoints to obscure the backend. This kind of layering makes attribution harder and means blocking one indicator without the others leaves you partially exposed. Your detection logic needs to account for the full cluster, not just the most obvious indicator.
Tunnelled infrastructure is particularly difficult to handle because the hostnames rotate. The two hostnames identified here, 87e0bbc636999b.lhr.life and edcf8b03c84634.lhr.life, are specific subdomains, but the underlying tunnelling service can generate new ones trivially. That means your indicators of compromise need to feed into broader wildcard detection for *.lhr.life traffic, not just these two hostnames specifically.
Any organisation whose endpoints or servers can make outbound connections to arbitrary hostnames over SSH or HTTPS is potentially at risk. That's most enterprise environments unless you're running a strict egress filtering policy. Sectors with high volumes of developer workstations, including technology firms, financial services, and government departments running mixed-use environments, are particularly exposed because tunnelling service traffic can look like normal developer tooling.
Organisations that rely primarily on perimeter-based detection without endpoint-level visibility into outbound connection attempts are at a heightened disadvantage here. If your SOC is only looking at firewall logs and not endpoint telemetry, these connections may never surface as alerts. Environments where SSH outbound on port 22 or HTTPS on port 443 is broadly permitted will give this infrastructure the path it needs to operate.
There are no specific CVEs or named software products tied to this pulse, which is itself a useful prompt for thinking about prioritising live threats over theoretical ones. The risk is infrastructure-level: any compromised host within your environment that establishes a connection to these indicators should be treated as a high-priority incident regardless of how that host was initially compromised.
IPv4: 80.200.28.28
Hostname: 87e0bbc636999b.lhr.life
Hostname: edcf8b03c84634.lhr.life
Block the known indicators immediately. Add 80.200.28.28, 87e0bbc636999b.lhr.life, and edcf8b03c84634.lhr.life to your firewall deny lists, DNS sinkholes, and proxy blocklists now. Don't wait for a full investigation before doing this. The cost of a false positive here is near zero, and the cost of leaving them unblocked is not.
Implement wildcard DNS blocking for *.lhr.life. The two hostnames in this pulse are specific instances of a tunnelling service that generates subdomains dynamically. Blocking only these two values leaves you open to the same actor rotating to a new subdomain within minutes. Push a wildcard block for *.lhr.life at your DNS filtering layer and log any attempted resolutions so you can identify potentially compromised hosts.
Hunt for historical connections in your telemetry. Query your SIEM, EDR, and DNS logs for any past connections to these indicators. Look back at least 90 days. If you find hits, the priority shifts from prevention to incident response. Identify the affected host, determine what data it had access to, and check for signs of lateral movement or data staging. Your attack surface extends to any system that host could have reached.
Audit egress rules for tunnelling services broadly. If your current policy permits outbound SSH or unrestricted HTTPS to arbitrary external hosts, this incident is a prompt to tighten that. Review whether localhost.run and similar services (ngrok, serveo, pagekite) are legitimate business tools in your environment. If they're not, block them at the network layer and add detection rules for the traffic patterns they generate.
Add detection logic for suspicious tunnel traffic patterns. Beyond static IOC blocking, configure your network monitoring tools to alert on connections from internal hosts to *.lhr.life, *.ngrok.io, and similar tunnelling domains. If you're running an IDS or NDR solution, write a rule that flags repeated HTTPS or SSH connections from a single endpoint to low-reputation dynamic subdomains. The traffic volume and connection duration patterns from C2 over tunnels are often distinguishable from normal developer use once you're looking for them.
It's a legitimate SSH tunnelling service that exposes local services to the public internet through subdomains under .lhr.life, which is the same pattern seen in the two hostnames flagged in this pulse. Attackers favour it because it's free, requires no account registration to operate, and produces traffic that mimics normal developer tooling. Practically, that means standard perimeter controls won't surface it unless you've deliberately written detection or egress rules to catch tunnelling activity.
Treat it as high-priority suspected compromise until you can prove otherwise. A legitimate internal tool has no reason to be reaching 80.200.28.28 or these specific .lhr.life subdomains, and the dual-track infrastructure pattern (static IP plus ephemeral tunnel endpoints) is consistent with deliberate C2 design rather than incidental misconfiguration. Isolate the host, preserve its logs, and work backwards to understand how the connection was initiated before clearing anything. Don't assume it's a false positive without evidence.
Not on the basis of the available source data. The AlienVault OTX pulse does not attribute these indicators to a specific named threat actor or malware family, and no corroborating reporting was identified at the time of writing. The infrastructure pattern is consistent with post-exploitation C2 or exfiltration activity, but attribution remains open. That means your response should focus on the behavioural indicators and the cluster itself rather than waiting for a named adversary to be confirmed.
Possibly, if developers are actively using localhost.run for testing or demos. Audit current usage before pushing a blanket block if operational disruption is a real concern, and check whether the two flagged hostnames have ever resolved internally. In most enterprise and government environments, this service has no legitimate business use, and blocking it outright with a logged exception process is the safer default position. Pair the block with logging so you can spot any host that tries to bypass it.
