Security Warning on files that I create on the desktop

sammy3417 said:

Crazy to ask you this!! are you the Administrator on this system? If not has someone changed your permissions?

I am an administrator and domain administrator. I don't think anyone was monkeying with my permissions; they looked right and I can't imagine why anyone would want to mess around with it.

We use the enterprise version of Sophos Anti-Virus at work. I've also tried disabling it and then making a new script but the warning persists.

A Guy said:

For you the question is what changed? And why only the desktop?

No idea. I used PoSH to list all files that were modified over the weekend to see if someone else did something, but I couldn't find anything that seemed particularly relevant. Sophos did some updates to itself but, yeah, it does that and it also does that to hundreds of other computers on site without apparent issue.

I use Firefox primarily at work and home, so I haven't been fussing about in IE9 much to change any settings. I was looking around in them afterward, of course, and I admit I don't understand full the extent of how IE9 is integrated in Windows Explorer and whatnot. I'll take another look around and try twisting some knobs to see if anything happens.

Thanks for the suggestions and links. Those showed up in my web searches and actually led me to this forum, but the heavy-handedness of their usage turned me off using them as a solution. I was looking for more of a scalpel than a chainsaw, and any further understanding of some under-the-hood mechanisms of Windows 7 would be a bonus.

Yeah, no can do on the system restore unfortunately.

So there are two Windows updates that were installed over the weekend that this happened: KB2744842 and KB2732059. Maybe I'll try uninstalling those to see if anything changes.

Other than those updates, the only other files that look to have been modified over the weekend are related to Sophos and Chrome updating themselves. I could try uninstalling those as well. Sophos in particular logged a ton of errors in the System event log over that weekend--looked like one of its services got caught in a perpetual loop of trying to restart itself and failing.

Another curiosity: I can make a .bat on my desktop, and it will give the warning. I can copy that elsewhere and the copy doesn't exhibit the warning. If I then move that copy to the desktop, it still doesn't give a warning. The file hashes of the original and copy are exactly the same, however, so I don't know what's happening here other than some metadata thing or external program/service keeping tabs on every file...? I'll see if I can do a ProcMon capture and see if there are any clues there.

It's pretty tenuous, but at least it's a few more things to try before throwing in the towel.

SFC gives me:

Code:

2012-10-18 15:48:31, Info                  CSI    0000028f [SR] Repairing corrupted file [ml:520{260},l:56{28}]"\??\C:\Windows\Help\mui\0409"\[l:22{11}]"diskmgt.CHM" from store
2012-10-18 15:48:31, Info                  CSI    00000292 [SR] Repairing corrupted file [ml:520{260},l:56{28}]"\??\C:\Windows\Help\mui\0409"\[l:22{11}]"diskmgt.CHM" from store

Which I'm ignoring because it reported the same thing long before this issue. Why SFC has such a fit over diskmgt.CHM would be worthy of its own meticulous investigation--if I actually cared about the diskmgt.CHM file. For anyone curious:

• I can open the diskmgt.chm file just fine, no issues.
• SFC /SCANNOW always complains about the diskmgt.chm file being corrupt, yet it has the same hashes as my coworkers' diskmgt.chm files and yet their SFC runs without any such errors.
• SFC always says it's repairing the diskmgt.chm file, yet it never fails to still show up on subsequent SFC /SCANNOW attempts.
• Despite this, pointing SFC directly to the file with SFC /SCANFILE=C:\Windows\Help\Mui\0409\diskmgt.chm reports the file is perfectly fine. Argh!

Anyway, back to the topic.


Didn't have much spare time today, but I did manage to uninstall both of the aforementioned hotfixes, Chrome, and Sophos. Still get the security warning.



On the plus side, systematically uninstalling Sophos and killing every chunk of it I could find in the registry and hard drive fixed some oddities I was having with it deploying correctly on my machine via policy. I consider that a small win, anyway.

Another update. Sorry it's been a while, but apparently I have to do real work at my job from time to time.

I tried looking over policies applied to my system/user and comparing them with another. I also even compared my registry hive against another user's to see if anything stood out. A few curiosities but nothing I looked into from there panned out. I even tried resetting all my caspol configurations to no effect (a shot in the dark).

I ended up moving the location of my desktop (right-click on your desktop folder in your profile and go to the Location tab) to a Desktop2 folder in my profile. Success! I then renamed my old, broken desktop folder and moved my desktop back from Desktop2 to the new Desktop and it still works. Yay.

Sorry to report that I still have no idea what the issue was but, hey, at least it was easily remedied. I did notice one new thing when I compared my new desktop folder's SDDL string against the old one when I included audit information (e.g. get-acl -audit). The old one has a blank SACL (apparently) hanging off at the end of the SDDL (it just stops at S:). That seems kinda odd, but I'm hardly an expert. Either way, next time I'm in office, I'll try and wipe the SACL on that folder to see if it clears up the issue (which is still very much intact with items placed in that folder) and/or clone the permissions from my new desktop to that one.

Anyway, if that fixes it then I'll post back here. If not, I suppose it will remain a mystery.

Today I tried messing with the ACLs on the folder. I tried adding an audit entry to it and then removed it. Re-checked the SDDL on the folder to see that the S: at the end was now S:AI. AI seems to be a propagation flag to child-objects. Problem with that folder persists. Hmm.

I then use PowerShell to copy the ACLs from my new desktop folder (that's working) onto the OldDesktop folder. It does that, but the folder retains the mysterious S:AI.

I try using ICACLS to reset the ACLs on the folder, but that doesn't get rid of it. I take ownership of the folder and wipe all the DACLs/SACLs off the damn thing. I make a DACL for me so I can view the lists and damn if that stupid S:AI is still there.

I downloaded SetACL (command-line) and messed with all the obvious parameters I could find for it. Can't seem to get rid of that pesky thing. Pretty sure I even protected it from inheritance and it still remains there.

So I have no idea what's going on that and even less of an idea of what caused the issue in the first place. I can't be sure if it's the cause since I haven't figured out how to remove it. If you guys have any ideas, I'll take another crack at it. In the meantime, the new desktop folder is working just fine. So that's nice. Maybe I'll add a SACL on it to log when the permissions get changed just in case this happens again.