Grzegorz Tworek

Just to make it clear, this time I will address only one “no access” scenario you probably know: the process cannot access the file because it is being used by another process. Something I have referred to in my “Locker” message couple of weeks ago. If you didn’t play

Impersonating a process identity is an essential feature that Windows users rely on daily. This capability spans from Windows Services running local or domain accounts to the use of runas.exe, as well as other “magical” solutions that allow processes to run on behalf of other users. When a child

Some time ago, I have described ShareAccess parameter present in API functions responsible for opening files. If you don’t remember it, try to find “Locker” email in your inbox, somewhere near mid-August. I have intentionally focused on mechanisms and not on dealing with them, and today I will focus

Security professionals do not trust Windows Explorer when it comes to the drive content. And for a reason. Since Windows 95, Explorer was designed to be a GUI and/or Shell, not a tool for browsing files and folders. There are many reasons why the folder content in the Explorer

When it comes to Windows Services, there are a lot of things that make hackers excited. One of the most important features is the ability to manage Services remotely. Almost everything one can do with Services locally can be performed on a remote computer as well. It’s worth noting

Each file open operation in Windows (leading at the very end to NtOpenFile/NtCreateFile syscall) requires two separate parameters to be passed: DesiredAccess and ShareAccess. The first one seems to be clear - the opening party tells the Operating System about way how to open the file: for reading, for