3 ms·

Well, firstly, it wouldn't be port 80 in that case.

• zamadatix 5y ago
  Could be an artifact of however the proxying or decryption is done, particularly if the goal was to have the traffic be decrypted as it went across the NIC not just to get a copy of the data being proxied locally. Or it could be an artifact of bad editpcap-ing. Same with the all 0s Ethernet source/destinations. Either way I don't think it was the run box that triggered it. Either they didn't know the original run box is still a thing and the field in the taskbar is a search box or they have clipboard history enabled and didn't realize that's a cloud function while they were ctrl+c and ctrl+v-ing into the box.
  • jfrunyon 5y ago
    Frankly, I can't think of any way to proxy or decrypt it that would result in the packets still being destined for the same Microsoft IP, but with port 80 instead of 443. The only explanation I could think of was that it falls back to HTTP if HTTPS is unavailable and they blocked port 443, which not only would be bat**** insane, but I tested and that does not occur.
    • zamadatix 5y ago
      "Many also interpreted the screen shot as if the traffic was sent in clear text. That is not the case, whatever you type on the Win start menu is sent using HTTPS over TCP 443. We used a TLS proxy to decrypt the TLS traffic in order to show what is being sent to Microsoft." https://twitter.com/netresec/status/1440298939509399553 https://twitter.com/netresec/status/1440298939509399553
      • jfrunyon 5y ago
        Yeah, turns out their capturing proxy just creates inaccurate pcaps. Who woulda thunk.