4 ms·

Vs code functions as a remote access trojan (RAT) in this scenario. But while your AV will hopefully detect and flag most common RATs, it won't flag vs code. Th

Vs code functions as a remote access trojan (RAT) in this scenario. But while your AV will hopefully detect and flag most common RATs, it won't flag vs code. This method is often used in real world attacks (especially targetted ones). I'm not saying that's a huge concern, but something one has to consider when protecting their organisation.

skinner927 3y ago
But how did you put the binary on the box and run it without an already working RCE/RAT?
- _cenw 3y ago
  I think it's a point about persistence. It's easy to obfuscate an existing piece of malware to not be found for a day or two, harder to keep it undetected forever. If you instead task schedule code.exe to expose some internal network port, you can keep it for as long as the machine lives. But that's already assuming you get compromised anyway, and that your compromised workstations have things worth reaching on their internal network/VPN. All things that are true on real corporate networks, but "fixing" this vulnerability is still pretty low impact in the grand scheme of things one could do to to improve the situation. But in my experience, most CISOs aren't that great at setting priorities and threat modeling anyway: One just recently told me they doesn't want XSS vulnerabilities reported, because the scanner would find them anyway - but sends out daily all-caps emails about specific emails being phishing.
- rfoo 3y ago
  The industry is pretty bad at blocking RCEs (0-day is just inevitable, but preventing 1-day or just stolen credentials is IMO equally hard). The industry is better at detecting compromise by spotting post-exploitation behaviors such as reverse shells or exfiltrating large amount of data. Your developer uses VSCode and sends a lot of data to vscode.dev or another Microsoft domain? Sounds totally normal, nothing suspicious here, move on!

skinner927 3y ago

But how did you put the binary on the box and run it without an already working RCE/RAT?

_cenw 3y ago
I think it's a point about persistence. It's easy to obfuscate an existing piece of malware to not be found for a day or two, harder to keep it undetected forever. If you instead task schedule code.exe to expose some internal network port, you can keep it for as long as the machine lives. But that's already assuming you get compromised anyway, and that your compromised workstations have things worth reaching on their internal network/VPN. All things that are true on real corporate networks, but "fixing" this vulnerability is still pretty low impact in the grand scheme of things one could do to to improve the situation. But in my experience, most CISOs aren't that great at setting priorities and threat modeling anyway: One just recently told me they doesn't want XSS vulnerabilities reported, because the scanner would find them anyway - but sends out daily all-caps emails about specific emails being phishing.
rfoo 3y ago
The industry is pretty bad at blocking RCEs (0-day is just inevitable, but preventing 1-day or just stolen credentials is IMO equally hard). The industry is better at detecting compromise by spotting post-exploitation behaviors such as reverse shells or exfiltrating large amount of data. Your developer uses VSCode and sends a lot of data to vscode.dev or another Microsoft domain? Sounds totally normal, nothing suspicious here, move on!