4 ms·

This only works for casual untrained observers. A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies

This only works for casual untrained observers. A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies at all (this sounds weird). Then comparing two requests or so would likely show a suspicious pattern of all the hex changing randomly while the rest of the payload is cookie cutter the same. Unless the outer layer is a legitimate service that's actually in use, this kind of thing only fools people who'd dismiss this traffic as "something I don't know about, but which is probably benign". Then there's the whole figuring out what IPs this is going to part, which would raise more alarm bells. Cute, but I think you could do better. Hiding from someone looking at your traffic is very hard. The more important part is how well you hide from dumb automated tools that people rely on for initial detection. Then again, a huge portion of the auditing/"infosec" market nowadays are untrained random people running automated scanners who actually have zero reverse engineering or proper security research experience, so I'm sure it'd work well against those.

nl 6y ago
> A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies at all (this sounds weird). This isn't accurate. If you look at the Snort rules used to block it[1], it is masquerading as traffic to .solarwinds.com (ie, the vendor) to URLs looking like: swip/upd/SolarWinds.CortexPlugin.Components.xml Unless you knew the software isn't supposed to do that, it isn't suspicious at all. [1] https://github.com/fireeye/sunburst_countermeasures/blob/main/all-snort.rules https://github.com/fireeye/sunburst_countermeasures/blob/mai...
- marcan_42 6y ago
  Hitting a vendor web server on plaintext HTTP? That right there is a massive red flag. If this were legitimate traffic, that'd be enough reason to drop the vendor right then and there. If this were HTTPS then it wouldn't need the obfuscation to pass by undetected. And then there isn't much you could do at that point to find it via traffic analysis, assuming the uncompromised app makes similar HTTPS connections, other than perhaps going deeper into traffic pattern analysis if you're lucky. Once the threat is identified some other way, it might be possible to develop blocking rules that work at the ciphertext layer (e.g. from packet size patterns exhibited only by the backdoor requests).
  - nl 6y ago
    I wouldn't read too much into the missing "S" in the write-up. It's unclear from that one rule but the majority of the Snort rules for this exploit stop HTTPS. Note the "port 443" in the rules.
    - marcan_42 6y ago
      And those rules are matching TLS ciphertext (record headers and SNI). The path rule is matching plaintext, so it's obviously not inspecting TLS.
  - Wheaties466 6y ago
    I wish that were the case, but unfortunately some credit card processors still send some credit card processing payloads over http in some circumstances.
    - colejohnson66 6y ago
      Is the actual payload encrypted, but just sent over HTTP? In that case, it’s bad, but not as bad as unencrypted over HTTP.
acdha 6y ago
> This only works for casual untrained observers. A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies at all (this sounds weird). Then comparing two requests or so would likely show a suspicious pattern of all the hex changing randomly while the rest of the payload is cookie cutter the same. A proper analyst working in a well-funded clean environment with carefully defined legitimate traffic patterns. That is not a majority of organizations and it would be very easy to miss something like this in the other 99% where they’re understaffed, dealing with the noise of routine malware, and what appears to be a poorly written vendor application doesn’t stand out as much when you have hundreds of them.

nl 6y ago

> A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies at all (this sounds weird). This isn't accurate. If you look at the Snort rules used to block it[1], it is masquerading as traffic to .solarwinds.com (ie, the vendor) to URLs looking like: swip/upd/SolarWinds.CortexPlugin.Components.xml Unless you knew the software isn't supposed to do that, it isn't suspicious at all. [1] https://github.com/fireeye/sunburst_countermeasures/blob/main/all-snort.rules https://github.com/fireeye/sunburst_countermeasures/blob/mai...

marcan_42 6y ago
Hitting a vendor web server on plaintext HTTP? That right there is a massive red flag. If this were legitimate traffic, that'd be enough reason to drop the vendor right then and there. If this were HTTPS then it wouldn't need the obfuscation to pass by undetected. And then there isn't much you could do at that point to find it via traffic analysis, assuming the uncompromised app makes similar HTTPS connections, other than perhaps going deeper into traffic pattern analysis if you're lucky. Once the threat is identified some other way, it might be possible to develop blocking rules that work at the ciphertext layer (e.g. from packet size patterns exhibited only by the backdoor requests).
- nl 6y ago
  I wouldn't read too much into the missing "S" in the write-up. It's unclear from that one rule but the majority of the Snort rules for this exploit stop HTTPS. Note the "port 443" in the rules.
  - marcan_42 6y ago
    And those rules are matching TLS ciphertext (record headers and SNI). The path rule is matching plaintext, so it's obviously not inspecting TLS.
- Wheaties466 6y ago
  I wish that were the case, but unfortunately some credit card processors still send some credit card processing payloads over http in some circumstances.
  - colejohnson66 6y ago
    Is the actual payload encrypted, but just sent over HTTP? In that case, it’s bad, but not as bad as unencrypted over HTTP.

acdha 6y ago

> This only works for casual untrained observers. A proper infosec analyst looking at this would first wonder why there is HTTP traffic related to .NET assemblies at all (this sounds weird). Then comparing two requests or so would likely show a suspicious pattern of all the hex changing randomly while the rest of the payload is cookie cutter the same. A proper analyst working in a well-funded clean environment with carefully defined legitimate traffic patterns. That is not a majority of organizations and it would be very easy to miss something like this in the other 99% where they’re understaffed, dealing with the noise of routine malware, and what appears to be a poorly written vendor application doesn’t stand out as much when you have hundreds of them.