-
-
I agree. It’s not a big issue but Microsoft could certainly be a bit more clear about why leaving an empty folder on the disk is supposed to be a form of “protection”. I suspect why – although I’m not entirely sure – but BleepingComputer’s article pointed out by @techtango ( #2763070 ) might be an important clue.
The article provides help for people like me and others who’ve deleted the ‘C:\inetpub‘ folder – confirming Redmond’s recommended workaround to recreate it (by temporarily enabling the IIS features, disabling them back and rebooting). Interestingly, the recreated folder ACL permissions seem to be slightly different than the default ones ( also shown by @pkcano in #2762966 ):
More importantly, though, the article also mentions Will Dormann‘s explanation of what those “changes that increase protection” might actually be – and why Microsoft is recommending people not to delete the folder but, instead, keep it (even if empty, even if no IIS features are used):
https://infosec.exchange/@wdormann/114315544895955943
Perhaps keeping the ‘C:\inetpub‘ folder, with the proper ACL attributes applied, could just be a quick emergency fix (a preventive first step, a necessary workaround to gain some time until a more thoroughly and complete patch is developed, tested and deployed in a future update) to something else, eventually a new attack surface exploiting WSL (Windows Subsystem for Linux) that takes advantage of something that shouldn’t be possible (allowing to create junctions to files and treating those junctions not as files but as directories ).
I guess we’ll just have to wait and see.
-
-
-
-
-
AFAIK, the ‘C:\inetpub‘ folder may be safely deleted, if no Internet Information Services (IIS) features are being used.
It was probably created as part of the monthly update process, when updating the IIS packages that Windows relies upon to enable (turn on) or disable (turn off) the related, optional features: those packages must be kept up-to-date, too, in order to ensure that an updated version of any given feature is used instead of an old, previous version of that feature containing security vulnerabilities that have been fixed since.
The above image shows the ‘%WINDIR%\servicing\Packages‘ folder contents of a Windows 10 v22H2 test system (with no IIS features enabled), updated with KB5055518, which had its IIS baseline packages (build 19041.1) cumulatively updated with at least a couple of major updates: one back in September, 2024 (build 19041.4957, along with the KB5043131 monthly preview) and, again, this month (build 19041.5737).
In the ‘%WINDIR%\Logs\CBS\CBS.log‘ file contents of that system we see several entries related to the IIS packages and their updated components and learn exactly what IIS optional features have been patched:
That doesn’t tell us why the ‘C:\inetpub‘ folder is being created in the first place. It may be happening either by the KB5055518 update itself (when updating the IIS packages that support these features) or be triggered by, and have a direct correlation with, the .NET Framework cumulative updates (KB5055683): an old comment suggests a possible relationship with the Windows Communication Foundation (WCF) HTTP Activation feature, that is part of the .NET Framework 3.5 core services and is deep buried into Windows 10/11 (not to be confused with the HTTP Activation feature, used to activate applications using HTTP protocols, that is part of the WCF Services that, in turn, are a component of the .NET Framework 4.8 Advanced Services).
The folder presence is a bit odd, though. It should have been removed after updating the IIS packages (as part of the final cleanup process) but, for all I can tell, it might be just a bug (an unintended leftover) and is, quite likely, safe to remove.
1 user thanked author for this post.
-
Just a quick update, as it seems there’s indeed what it seems to be a logic explanation and a confirmation that the observed random artifacts do not mean corrupted contents but are, instead, rather normal since they’re related with compression.
https://forums.virtualbox.org/viewtopic.php?p=554048#p554048
Quoting:
“The reason [why the Windows installer has nearly doubled in size from 106MB for 7.0.22 to 216MB for 7.0.24] is that the compression settings were in a way ‘lost’ during a larger installer rework. Purely affects the download size, doesn’t mean that there’s much more code or some such. As soon as we have a new test build next week it’ll be back to the usual size.”
This seems to confirm that v7.0.24 is OK (good to know) and the upcoming 7.0.x setup version (probably v7.0.26) is expected to be released, again, with the usual, “normal” size.
-
There doesn’t seem to be a new dependency all of a sudden: that Python Core package dependency your screenshot refers to exists in previous versions, too, if you select the ‘VirtualBox Python support’ item (which I normally DON’T).
The extraneous contents I wrote about are unrelated to that.
It seems like someone might have mistakenly chosen the wrong flags when triggering the usual build process, causing the final setup to embed more than what it should: some parts of the build environment itself (of which we usually have no visibility at all).
In previous versions, these were not part of the product itself, neither were part of the setup installer. Under normal conditions, the final setup would not have to “inherit” and embed (or use) those extra contents, at all. That assumption is reinforced by the fact that the main contents of the new setup (those 191 files I mentioned in the post) appear to be (only) the exact same, updated equivalents of the previous version.
Whatever happened, the final setup ended up being (unnecessarily?) larger than it should because it also embedded those extra (useless and unused?) contents “inherited” from the build environment. My point was more about noticing that many of these contents seemed to be partially CORRUPTED.
On the other hand, that might not be true or a big deal at all, IF those contents are NOT exact copies of the original contents. The compiler might have simply decided to use and embed into the final setup whatever was in memory at compile time (to put it simply, memory is constantly reused and overwritten: that’s why many programming languages require variables to be declared and initialized – rather than assuming they will always have a predefined well-known value – so they won’t get “garbage” values from the stack or unexpected, random memory addresses).
It MAY be a problem, though, if those extra contents are, indeed, exact copies of the original resources (in that build environment). It MAY be a problem if those extra contents do reflect some sort of file CORRUPTION that might have been going on, unnoticed, in the build environment that might be the root cause of weird “bugs” and issues that affect normal features and prevent them from working correctly, as expected.
We simply don’t know. And that’s why I wrote it might be a red flag. If that is the case – and some parts of Oracle’s build environment are not pristine as they should but, instead, they do include partially corrupted files – then IMHO the VB team engineers should take a look at what’s going on and fix those issues before they escalate into deeper, more complex problems.
Again, being optimistic here, eventually they’ll notice something’s not right and will fix things up in the next release. Let’s hope so. In the meantime, VB users using v7.0.22 might be better off skipping v7.0.24 at all and just waiting a little bit more for the next, upcoming v7.0.26 version to be released.
Just my 2 cents,
1 user thanked author for this post.
-
This latest release has a few oddities that shed a light on Oracle’s QA, providing clues to people that have been complaining that it seems like each new version is getting worse than the previous one and scratching their heads on why some “persistent” bugs and “weird” issues never seem to be properly fixed.
Puzzled on why the new 7.0.24 Windows setup doubled (!) its size, compared to the previous 7.0.22 version – especially since both setups seem to unpack similar contents (191 files with approximately 212Mb)
I took a closer look and pinpointed that the main size difference between the two binaries boils down to the ‘BIN_00’ RC Data resource at the .rsrc section (Initialized Data):
It turns out that the new 7.0.24 version has some “Easter eggs”: a lot of additional, unexpected contents were added and embedded into the final setup – probably by mistake, likely due to some “AI/automation bs involved in the building process“…
We’re talking here about pieces of information that are not present in previous versions of the setup (they’re probably not needed or ever used by the setup, at all) but do appear to be part of a Continuous Integration/Continuous Delivery/Deployment (CI/CD) pipe lined environment used by Oracle teams to compile and build the final setup – including, but not limited to, shell scripts (debian_postinstall.sh – A post installation script template for debian-like distros), Python scripts (vboxapi.py – VirtualBox Python API Glue), C language headers, .rtf license files (COPYING), WSDL definitions (src/VBox/Main/webservice/websrv-wsdl.xsl Generator, Generated from: src/VBox/Main/idl/VirtualBox.xidl (VirtualBox’s interface definitions in XML)) and other binary contents.
What bugs me most is not the reason why these contents ended up being part of the setup in the first place (someone messed up, period – it sucks, but it happens). What worries me, as a user is that some of these contents appear to be partially <span style=”text-decoration: underline;”>CORRUPTED</span> by seemingly random pieces of “garbage” (extraneous UNICODE characters):
Being optimistic here, perhaps the original resources are not corrupted (only these “useless” copies that were embedded by mistake into the setup). However, from a user’s perspective, this doesn’t look good and (sadly and a bit unfairly, given the product’s past history) it’s a red flag that might serve as an eye-opener to how software is being “built” these days and, unfortunately, casts a shadow over the quality of the product and the confidence users should have about using it.
Just my 2 cents,
-
-
Bumped into this recently: while running Windows Defender scans, a legacy Windows 8.1 system (running flawlessly with zero security incidents, no significant issues over the years and still up for the job and tasks and goals it was set up and meant for – which is quite remarkable comparing to the effort put in dealing with, and fixing, a rather long list of issues while managing “modern” Windows 10/11 WaaS systems) suddenly began showing up the yellow warning symbol and the alarming message
“Preliminary scan results show that there might be malicious or potentially unwanted software on your system”
but the scan always ended with a “green” status reporting a “safe” machine, with 0 results (no malware findings at all). In every single scan, roughly at the very same point of the scanning progress, the warning message came up but, in the end, there were no quarantined contents, history was clear (no detections), there were no defined exclusions involved and – what’s more annoying – there were no useful log contents to help.
If that wasn’t odd enough, disk cleanups and system restarts made no difference: it was a sticky, “persistent” situation of a “false positive” that refused to go away, no matter what (and yes, that was confirmed to be the case after spending a couple of hours extensively applying advanced malware scanning techniques that ensured, with a high degree of confidence, that the system in question was, indeed, “clean” and that there were no active infections whatsoever).
It turns out there’s a reasonable explanation for this odd behavior:
https://learn.microsoft.com/en-us/answers/questions/326108/mar-17-21-msert-detects-items-during-scan-but-at-eRob Koch’s post (here quoted by Andy David, replying to a similar scenario when running the MSERT standalone tool – one of the many Microsoft security products that, like Windows Defender, share the same common antimalware platform) is enlightening but doesn’t tell you the whole picture, neither does it pinpoint exactly WHY or HOW this scenario might happen. It also doesn’t tell you how to FIX it, so here’s the deal (based merely upon my observations and assumptions and how I was able to workaround the issue and fix it)…
1. Consider a legacy Windows 7 system running Microsoft Security Essentials (or, in my case, a legacy Windows 8.x system running the same rebranded and upgraded Windows Defender product that, incidentally, never had any malware detection before) with the Settings > MAPS option configured to be either ‘Basic membership’ or (as it was the case) ‘Advanced membership’.
2. While executing an OFFLINE scan, the yellow warning symbol is shown and the “Preliminary scan results” message appears. In the end, a PuP (Potentially Unwanted Program) is found.
- At this point, Defender has a copy of the “suspicious fragment” that triggered the warning and lead to the PuP detection. Because the MAPS option was set accordingly, if there had been internet connectivity when the detection occurred, or roughly at 95% of the progress accordingly to Rob Koch’s post, the fragment should have been sent directly to Microsoft, so that the MAPS servers would analyze it and return further information about its nature (confirming if it was, indeed, a known piece of malware or a possible unknown strain of malware that should be further analyzed and included in upcoming antimalware signature definitions). This “cloud protection” feature implementation is not uncommon, it’s just how modern security products work.
. - Defender’s MAPS option is roughly equivalent to the “heartbeat” feature of both the Malicious Software Removal Tool (MRT) and Microsoft Safety Scanner (MSERT) standalone removal utility. All the three products set their own Registry REG_DWORD value that determines if any detection findings shall be sent, or not, to Redmond:
; Microsoft Security Essentials [Windows 7] / Windows Defender [Windows 8.x] ; ; If the 'SpyNetReporting' REG_DWORD is set to 0, ; Defender should not submit any findings to Microsoft MAPS servers ; [HKLM\SOFTWARE\Microsoft\Microsoft Antimalware\SpyNet\] [HKLM\SOFTWARE\Microsoft\Windows Defender\SpyNet\] ; ; 0 = I don't want to join MAPS <- Privacy-minded preferred option ; 1 = Basic membership ; 2 = Advanced membership ; "SpyNetReporting"=dword:00000000 ; ; Microsoft Malicious Software Removal Tool (MRT) / Microsoft Safety Scanner (MSERT) ; ; The Registry key and the 'DontReportInfectionInformation' REG_DWORD might not exist, ; which is the default and equivalent to having the REG_DWORD set to 0 ; ; 0 = Send the detection findings to Microsoft ("heartbeat" report) ; 1 = Do *NOT* send the detection findings to Microsoft <- Privacy-minded preferred option ; [HKLM\SOFTWARE\Policies\Microsoft\MRT\] [HKLM\SOFTWARE\Policies\Microsoft\MSERT\] "DontReportInfectionInformation"=dword:00000001 - The system’s MAPS option is set to submit the “suspicious fragment” (SpynetReporting REG_DWORD > 0). However, because the user is OFFLINE, Defender was unable to do so: instead, it keeps the “suspicious fragment” in a local “cached” folder. Presumably, once the internet connectivity is (re)established, the fragment may be queued and sent to the MAPS servers – either automatically or, eventually, when the next scan happens.
3. Realizing the detected PuP is NOT a malware infection, but rather a false positive scenario triggered by a specific tool that the user had been temporarily using for troubleshooting purposes (case in point: NirSofer’s WirelessNetView), the user not only dismisses the question and accepts Defender’s automatic action (the tool was put into quarantine) but he also uses the ‘Remove all’ button in the ‘History’ tabsheet to clear the scanning history and remove the item from quarantine (effectively confirming the tool’s deletion).
- At this point, the machine is still OFFLINE but Defender is smart enough to honor its MAPS settings: therefore, despite being instructed to clear its scanning history and quarantined contents, the “suspicious fragment” that triggered the PuP detection still exists, and will be kept. The “cached copy” of it (which is now an orphan reference to something that doesn’t exist anymore, because the tool was deleted) will supposedly be submitted to the MAPS servers once the internet connectivity is (re)established, or the next scan happens. But here’s the catch:
4. The user also realizes the MAPS option in the ‘Settings’ tabsheet is set to ‘Advanced membership’ but, because he recently had middle management “security training” and had received, and read, internal company emails alerting to “privacy issues” that could arise from inadvertently having software misconfigured to “disclose corporate privileged information” he promptly changes the MAPS setting to ‘I don’t want to join MAPS’.
I won’t digress about the user’s decision. The important thing here is, what should Defender do? Honor the MAPS option that had been previously set (and keep the cached “suspicious fragment”, now an orphan reference, for later submission) or adapt and adjust to the new MAPS option (and remove the “suspicious fragment”, since the now chosen MAPS option clearly states that “No information will [shall] be sent to Microsoft” anymore)? I’d say BOTH:
- If the system restarts now it is acceptable that, after a reboot, the new MAPS option should be honored and the orphan, “suspicious fragment” leftover shall be removed (similarly to what happens in the legacy software installation process, requiring a reboot to replace drivers, reapply settings and so on);
- If the system doesn’t restart yet and internet connectivity is (re)established in the meantime, it is also acceptable to assume that the old MAPS option should still be honored and the “suspicious fragment” should still be sent anyway because, at the time of its detection, the MAPS option was set to send it to Microsoft (and, it might be worth noting, that an additional ‘SubmitSamplesConsent’ REG_DWORD was also set to 1). Therefore, it is acceptable that the user’s decision otherwise shall only be taken into account from the time it was changed onwards and that the user’s decision doesn’t apply to the previously detected items. If the submission doesn’t happen automatically, it is also acceptable that it may happen at the next scan. Either way, internet connectivity must exist, so that the item can be submitted to the MAPS server, and only then – after submitting that “fragment” – the ‘SubmitSamplesConsent’ REG_DWORD can also be set to 0, honoring the user’s current decision (MAPS option set to ‘I don’t want to join MAPS’ [anymore]).
But, wait: what if the system DOESN’T restart yet, internet connectivity is (re)established and Defender is updated with new antimalware signature definitions before it has a chance to submit the “suspicious fragment”?
In that scenario, it is fair to assume that a “bug” MIGHT exist in the legacy Win7/8.x Defender’s interface that, when applying the new antimalware signature definitions corrupts somehow the orphanized “suspicious fragment” state and that cached, orphanized “suspicious fragment” becomes a “zombie” that might be repeatedly read and re-interpreted as a “preliminary scan result”, consistently and incorrectly triggering a warning message that refers to something that doesn’t even exist anymore!
In my case, that assumption was enforced by the fact that doing the obvious (changing back the MAPS option to ‘Basic membership’ or ‘Advanced membership’, connecting to the Internet and executing a scan so that the fragment could be submitted and subsequently removed from the local cache) didn’t seem to work, either. Not even after multiple system restarts and MAPS option changes in between. Whatever the reason was (probably related with the order in which the user actions occurred, the internet connectivity was (re)established, the new signature updates were applied or even the very nature of those specific signature definitions – eventually an intermmediate beta, buggy “delta” version), something went wrong in Defender’s interface: a glitch in the expected workflow that prevented the product from ever submitting the orphanized “fragment” to the MAPS server or removing it from the local cache – leaving that “fragment” indefinitely lying as a “zombie” leftover that kept triggering a misguiding warning to a non-existent “preliminary sign” of a non-existent malware infection!
Thus, I ended up fixing the situation by rebuilding Windows Defender’s internal “cached” history (a word of caution applies here: be advised not to do that unless you’re absolutely sure that the machine isn’t infected by malware – otherwise, you might be doing more harm than good. When in doubt, always seek experienced help). Here’s how:
- Boot from a rescue disk (or a Linux live system that gives you root access to the filesystem) – “Safe Mode” won’t do here.
. - From an elevated prompt, rename the history folder (as a convenient and temporary backup to rollback things up, if necessary) and create a new one, with nothing but the minimum, required subfolder structure and the main .bin control file(s):
cd /d "C:\ProgramData\Microsoft\Windows Defender\Scans" ren History History.BAK mkdir History\CacheManager copy History.BAK\CacheManager\Mp*.bin History\CacheManager /v /y mkdir History\Results\Quick mkdir History\Results\Resource mkdir History\Service mkdir History\Store
- Reboot and perform a Quick scan. Wait for it to finish: if the system is indeed “clean”, the yellow warning symbol and the “Preliminary scan results” message shouldn’t appear anymore. For completeness (if you want to double check and make sure all’s clean and well) you may wish to run a Full scan, too.
. - From an elevated prompt, the old folder can now be safely removed:
cd /d "C:\ProgramData\Microsoft\Windows Defender\Scans" rd /s History.BAK
That’s it. Hope it helps.
1 user thanked author for this post.
- At this point, Defender has a copy of the “suspicious fragment” that triggered the warning and lead to the PuP detection. Because the MAPS option was set accordingly, if there had been internet connectivity when the detection occurred, or roughly at 95% of the progress accordingly to Rob Koch’s post, the fragment should have been sent directly to Microsoft, so that the MAPS servers would analyze it and return further information about its nature (confirming if it was, indeed, a known piece of malware or a possible unknown strain of malware that should be further analyzed and included in upcoming antimalware signature definitions). This “cloud protection” feature implementation is not uncommon, it’s just how modern security products work.
Author
