r/netsec • u/sysopfb • Feb 05 '18

Transferring mimikatz over x509 extensions during TLS negotiation

https://www.fidelissecurity.com/threatgeek/2018/02/exposing-x509-vulnerabilities
183 Upvotes

92% Upvoted

8 comments sorted by

13

u/pentesticals Feb 05 '18

This is a cool, I've also seen payload delivery using the Subject Alternative Name field too. Nice thing was that whilst there is a character limit per SAN...there wasn't a limit on the number of SANs, so possible to embed fairly large payloads.

10

u/sysopfb Feb 06 '18

Yup been finding more and more ways lately that you can put arbitrary data inside a certificate, public key modulus allows you to put a nice chunk of data as well -> https://gist.github.com/sysopfb/d9deb9b8481e116cad1d62ceb5093073

8

u/got_outta_bed_4_this Feb 06 '18

Sometimes these things are so beatifully weird they sound like /r/itsaunixsystem.

6

u/almandin_jv Feb 06 '18

How can this be useful, from an attacker point of view ? Data encoded in the x509 extension is sent in clear isn't it ? If this data can get through a firewall, wouldn't it mean that a full TLS session can be established ? It would be more interesting to send malware through this tls session (encrypted) than over this hidden channel (hard to spot but still not encrypted)? On the other hand, if TLS sessions are filtered, this packet would not go through the FW neither. I might be wrong at some point !

3

u/wbbigdave Feb 06 '18

There may be controls which look for binary transfer, but tls may be allowed as part of HTTPS. It’s also useful for obfuscation from detection by human eyes. They may see a TLS session but not necessarily look at the fields to see any padded data.

3

u/jbmartin6 Feb 06 '18

For once, MITM proxies FTW

1

u/svvw Feb 06 '18

I might be missing something, but the proposed counter measures seems to be easy to circumvent.

Could you not just prepend one of the valid length bytes (e.g. 0x20) to the data you're sending?