Reading Time: 4 minutes

MSF (Metasploit) version 6. Network possible detection ?

OJ ( @TheColonial ) is a clever guy and a main contributor to the open source project of Metasploit. One of MSF6’s goal is to get rid of Strings in order to fly even lower … so close to the ground…to avoid any detection or …not close enough ? Remember the strings in MSF5 ? (see previous article here)

fig.1 MSF5 decoded packet to negotiate key phase

In my lab I upgraded my install to the latest and dumped the traffic (see other article to see which packet), I applied the XOR decryption I doesn’t get much strings anymore. Wouah ! well done. Congratz !

fig.2 MSF6 decoded packet to negotiate key phase

But it makes me curious to know how he/they achieved it.

So let’s dig into it. Let’s recheck the XOR function

The Original XOR of the packets is still the same

fig.3 packet.rb source code

So let’s search about that String “core_negotiate_tlv_encryption

fig.4 packet.rb source code

Ok, this is changed, there is no more strings for that command, but an ID.

fig.5 packet.rb source code

So end value = 16. So that original string can no longer be found ! but we can find the 16

fig.6 MSF6 decoded packet to negotiate key phase (like fig.2)

So now, what about the public key string ?

Digging into the code we see a difference and this commit is quite explanatory

fig.7 Pull request where we see the changes from old and new method

The public key is no longer sent in PEM (base64 ) format but the most compressed format the DER (ASN.1) ! And that format does not contain any strings ! ( clever  thinking ! )

But can we do detect anything about this DER format ?

Yes ! ASN.1 is a strict format and PKCS #1 has to have the OID 1.2.840.113549.1.1.1

fig.8 Decryption of the key (online tool)

That OID is “06 09 2A 86 48 86 F7 0D 01 01 01” in HEX format

There seem to be another object behind it but it’s null. It translates it to “05 00” . This could be added to the detection to lower down even more the rate of False Positives.

So at the end of today yes it should still be possible to detect MSF6 initial public key exchange communication be searching the followings

fig.9 fig.6 MSF6 final recognized negotiate key phase (like fig.2 & 6)

Now, if Security Product vendors would spend more time into R&D analyzing the most common and probably the most used C2 framworks like MSF is, and doing some labs, attackers wouldn’t get away so easily.


P.S: Don’t take me wrong, I have huge respect for Metasploit, and how it is achieving security by demonstration as other ways, people wouldn’t patch their machine, but also it is used with bad intent, proper redteam, would know also by reading this article how easily it would be to customize any part of this, to be not detected, but then anyway at the moment, I’m not aware of any security products who detects this on the wire. They all push back to the vision that is should be up to the end point to detect it with EDR … 🙁 (and depending on your payload we all know it’s possible to bypass any EDR on the market at the moment)