How do you detect suspicious network communication with IPFS?

What makes IPFS traffic stand out in network telemetry?

IPFS is a content-addressed, peer-to-peer protocol, so suspicious activity usually looks less like ordinary client-server web traffic and more like distributed node communication. The strongest signal is not the protocol name alone, but whether a host that should have no decentralised-content role is suddenly reaching out to peers, maintaining persistent connections, or using infrastructure patterns that do not match its business function.

That makes context essential. A developer workstation, build host, lab system, or content distribution workload may legitimately contact IPFS infrastructure, while a finance, HR, or back-office endpoint usually should not. You are looking for an inconsistency between the host’s role and the communication pattern, especially when the traffic persists over time or appears across multiple unusual destinations.

Which logs and behaviours are most useful for detection?

Start with DNS, proxy, and flow telemetry, then connect the dots across them. IPFS-related use often shows up as repeated lookups or contacts to decentralised gateway infrastructure, followed by long-lived or recurring peer-style sessions that do not resemble normal application browsing. The value is in the pattern, not a single indicator.

Look for outbound connections that are hard to explain by the host’s approved software, especially when the destination set is broad, changes frequently, or includes systems outside your usual service relationships. If a host is making these connections while its normal application traffic remains quiet, that contrast is often more informative than any one packet capture artefact.

When possible, baseline normal decentralised or content-distribution use by asset class, because one team’s expected behaviour is another team’s anomaly. A security team should distinguish approved gateways, sanctioned developer tooling, and known test environments from systems that have no reason to participate in decentralised content exchange.

How should analysts triage and validate a suspected case?

First, confirm whether the endpoint has any approved IPFS use case, browser extension, development tooling, or local software that intentionally uses the protocol. If not, treat the activity as suspicious and check whether the connections align with user intent, installed software, and the asset’s normal role.

Next, determine whether the pattern is merely noisy experimentation or part of a broader command, staging, or exfiltration path. IPFS can be used as an alternate communication channel because it distributes content across peers and can make traffic analysis harder than a simple single-server connection model. That does not prove maliciousness, but it does raise the bar for explanation.

When correlation suggests abuse, preserve the surrounding host evidence: process lineage, browser history where relevant, installed packages, recent downloads, and any companion outbound traffic that may indicate staging or follow-on activity. Analysts should also check whether the behaviour is paired with unusual encryption, uncommon ports, or other infrastructure that suggests the endpoint is acting as a relay rather than a consumer.

Risk and Threat Considerations

IPFS is attractive to adversaries because its distributed design can hide infrastructure changes and blur the line between legitimate distribution and malicious staging. The main risk is that an endpoint may be using decentralised communication as a covert or hard-to-block channel while appearing to participate in normal peer-to-peer activity.

Failure mechanism: Security teams miss the mismatch between the host’s expected role and its persistent peer-style communication, so malicious content delivery or command traffic blends into permitted decentralised patterns.

Impact: That can delay detection of staging, payload retrieval, or covert communication, and it can also widen the blast radius if multiple internal hosts begin using the same unapproved protocol path.

Practitioner Guidance

What to verify: Treat IPFS as suspicious only when you can show that the endpoint has no approved decentralised-content use and the traffic pattern is persistent, peer-like, or otherwise inconsistent with its job function. Role mismatch is the deciding factor.

Common mistake: Investigating only the destination name or protocol label misses the real signal. A better test is whether DNS, proxy, and flow logs together show communications that the business can explain, repeat, and justify.

What good looks like: Your detections should baseline where decentralised protocols are allowed, alert on their appearance elsewhere, and preserve enough surrounding telemetry to tell normal experimentation from suspicious staging or relay behaviour.

Practitioner takeaway: The strongest IPFS detections come from asset context plus communication pattern, not from the protocol in isolation.

Related resources from NHI Mgmt Group

• Guide: Command and Control (C2) Guide
• What are the signs that network device monitoring is failing to detect suspicious activity?
• What should you monitor to detect suspicious device activity in Microsoft Entra ID?
• How do you detect Okta network zones being deactivated or deleted?
• How do you detect suspicious SAML activity in AWS?