Metasploit Deep Dive Part 10: Network-Level Detection Engineering

This part is narrower than the original scope for a specific reason: a separate HIDS/Detection series is being built with a real Wazuh deployment and a live Active Directory domain, and once that lab exists, host-based visibility into everything this Metasploit series covers gets its own dedicated coverage, tested against real captured alerts rather than documented behavior. This post stays on the wire, where Part 5’s transports and Part 4’s TLV protocol already did the groundwork.

The staged handshake is a shape, not just a byte pattern

Part 5 drew the line between staged and stageless payloads. From a network monitor’s position, staged transports have a distinctive two-phase shape: a small initial connection, followed shortly after by a second, larger transfer of comparatively fixed size, the meterpreter stage itself. That two-phase pattern, connect small, then immediately pull something bigger, is a structural signature independent of the specific bytes involved, and it’s the kind of thing a flow-based detection tool (NetFlow analysis, a Zeek script watching connection sequences) can catch without doing any deep packet inspection at all. A stageless payload avoids this specific two-phase pattern by design, at the cost of its own single larger transfer standing out instead.

Defaults that get caught, and how easily they change

Metasploit’s out-of-the-box defaults are well known, precisely because the framework is open source and every default is sitting in the repository this series has been reading from all along. LPORT 4444 is the most famous of these; it’s been the framework’s default listener port since early versions, and it shows up in default IPS/IDS rulesets for exactly that reason. The self-signed TLS certificate a reverse_https handler generates unless the operator configures otherwise carries recognizable default characteristics as well, an unusually short validity window and framework-typical subject fields being the two most commonly cited.

The honest caveat, and it applies to every default listed here: all of it is a set command away from changing. LPORT is a datastore option like any other covered in Part 2. A competent operator changes the listener port, supplies a real or convincingly forged certificate for reverse_https, and every signature keyed to the unmodified default stops matching immediately. Default-based detection catches the unprepared, not the deliberate. It’s still worth having, because a meaningful share of real-world Metasploit usage genuinely is unmodified defaults, but it should never be represented as more than that.

Where Malleable C2 changes the picture

Part 9 covered Malleable C2 profiles as a network-evasion feature rather than an endpoint one, and this is where that distinction pays off directly. A profile-shaped reverse_https session doesn’t just avoid the framework’s own defaults, it actively mimics a named, plausible traffic pattern (browsing a specific real site, per Rapid7’s own demonstration). Signature-based network detection built against Metasploit’s unmodified traffic shape has nothing to match against a well-built profile. This is a genuine capability gap opened up by a 2026 feature, not a hypothetical one, and it’s the clearest argument in this whole series for why static, signature-only network detection was never going to be a durable answer against a maintained, actively developed framework.

What still works despite profile shaping

Traffic shape isn’t the only network-visible signal. TLS fingerprinting techniques like JA3/JA3S look at the client’s negotiation behavior, cipher suite ordering, extension list, and similar, rather than the application-layer content a Malleable C2 profile reshapes. A profile changes what the HTTP request looks like; it says nothing about what TLS library and configuration generated the underlying handshake, unless the operator has separately addressed that layer too. This is a genuinely useful distinction for anyone building detection against this framework: application-layer signature matching is the layer 6.5’s own features are explicitly built to defeat, while transport-layer fingerprinting sits one level below that and isn’t automatically addressed by the same feature.

Connection cadence and reconnect behavior are visible independent of what a single connection’s payload looks like. Part 4 covered TLV_TYPE_C2_RETRY_TOTAL and TLV_TYPE_C2_RETRY_WAIT, real fields in the protocol governing how a session reconnects after a drop. A host repeatedly reconnecting to the same external endpoint on a fixed or near-fixed interval is a beaconing pattern, and beaconing detection doesn’t care what the connection’s application-layer content looks like, only its timing.

Cross-linking the site’s existing Fortinet detection material

This site’s Fortinet content covers IPS signature tuning and FortiGuard threat intelligence cadence in depth in Threat Intelligence and FortiGuard Tuning. The general discipline that post argues for, don’t trust inherited default severity classifications, tune specific signature IDs rather than whole bands, applies directly to Metasploit detection: a signature written against the framework’s unmodified defaults needs the same kind of ongoing maintenance as any other IPS signature, because the framework’s own defaults and feature set keep moving.

The honest close

Everything in this post is a network-layer signal, not a guarantee. Structural signals (two-phase staged handshakes, beaconing cadence) survive traffic reshaping because they’re not about content. Content-level signals (default ports, default certificates, unmodified traffic shape) are exactly what a deliberate operator using a current framework will change first, and 6.5’s Malleable C2 support makes that specific evasion easier than it’s ever been. Detection built entirely on the second category is detection built to catch defaults, not attackers. The HIDS/Detection series, once its lab lands, will show what changes when host-based visibility gets added on top of everything covered here.