In a PowerShell script in Windows 10 Pro 64, I'm getting access-denied errors on several folders, such as:

  • C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache\Content.IE5
  • C:\Windows\System32\LogFiles\WMI\RtBackup

I went to look at those folders in File Explorer. I never did get into them, but along the way, on three folders:

  • C:\Windows\System32\config
  • C:\Windows\System32\config\systemprofile
  • C:\Windows\System32\LogFiles\WMI

I got a message saying that I didn’t have permission to access them, but inviting me to click to get permission permanently. I clicked that. I’m now able to access those three folders like any other. In order to test what "permanently" meant, I rebooted. I'm still able to access those folders.

Three questions:

  • Is it a security risk (or a bad idea for any other reason) to have those folders accessible? If so, how do I revert that permission?
  • On the "RtBackup" folder, I got the same offer to give me permanent access, but when I clicked for that, the permission was denied and I was told that to get it I should go to the "Security" tab. Presumably that means of the folder properties. I'm thinking it might be a bad idea to mess around with security settings for a system folder. Is that right? What are the risks from doing that?
  • In researching this, I came across the DOS command TakeOwn. I wonder if that might allow me to access all these elusive folders and maybe eliminate the access-denied errors in my PowerShell script. Would it? And would doing that be dangerous? What are the risks from running TakeOwn on an inaccessible folder?

1 Answer 1


File permissions are really designed for a multi-user system. If that's the case -- multiple people use this machine, or it's part of a corporate environment -- then giving yourself write permissions inside C:\Windows\System32\ means that you (or malware you download that's running as you) can muck things up for other users.

If this is a single-user system then the distinction between you and Admin is a bit less meaningful. As usual, there's a perfect XKCD for this:

XKCD comic "Authorization"

XKCD comic "Authorization"

It's also worth noting that by giving yourself (and therefore any malware running as you) write permission to C:\Windows\System32\, you increase the chance that malware can escalate itself to being Admin, at which point it's easier for it to hide from any anti-virus software you might be running because now the malware is equally powerful as the AV.

  • Thank you. I take this to answer all three questions with "Yes, that is dangerous," and you've explained the risk. Could you therefore edit the answer to add instructions (preferably with a link to documentation) on how to revert the permission that I now regret granting? (And thanks for the introduction to xkcd!)
    – NewSites
    Commented Oct 26, 2019 at 13:59
  • 1
    @NewSites, unlike most online forum type communities it is preferable when you have a follow up question like that for a user to post a new question with that question rather than ask in a comment. Part of the purpose of SE is to provide a source of questions others may ask and be able to find their answer as well. This tends to work best when questions/answers stay limited to their original scope.
    – YLearn
    Commented Oct 26, 2019 at 15:04
  • @NewSites This forum tends to prefer answers about general security concepts. A question looking for step-by-step instructions on doing something in a specific operating system would be a better fit on superuser.com. Commented Oct 26, 2019 at 18:02
  • @YLearn - The request for instructions was not a follow-up. It was part of the original question. I asked, if granting the permissions was a security risk, how to revert it. But in response to your comment, I went ahead and posted that part of the question separately, and it has now been migrated to SuperUser: superuser.com/questions/1496261/… . I hope someone knows the answer because it's pretty lame that Windows offered to let me grant the permission without warning me of the risks.
    – NewSites
    Commented Oct 28, 2019 at 10:01
  • 1
    "you increase the chance that malware can escalate itself to being Admin" -- this is a bit of a quibble for me but this isn't increasing the risk, it's guaranteeing it'll happen. Being involved with PenTests/RedTeams, the first thing that's done is to analyze privilege escalation capabilities. The minute I have figured out I have WRITE access to System32, at least local administrator is a foregone conclusion and given admin habits, probably the domain. I can now create System running Scheduled Tasks, overwrite Service targets, change Run keys, etc. etc., ad nauseum.
    – thepip3r
    Commented Oct 28, 2019 at 16:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .