I've struggled to find much information on this topic. What I'm interested in is the following:

A user is logged into a Windows (7, 8.1, etc) workstation as a standard non-administrative account. They then use the Shift-Right Click method to start another process as an elevated account (e.g. domain admin, local admin, etc.)

If that workstation were to be infected with Malware, what level of permissions would that malware have the realistic potential to exploit? Would it be limited to the non-administrative account that is logged in, or would it have the possibility to also take advantage of any elevated processes that may be available? Also how different would this be from standard UAC operations?

The purpose of the question is to determine how effective running as a non-administrator while still elevating several processes be against malware?

  • 1
    It is not the workstation that is infected, but a specific app (in which case the malware has the privileges of the app) or a file / system resource (in which case privileges are acquired and sometimes lost over time as apps interact with said resource). Commented Jan 28, 2016 at 11:57
  • Fair enough, and that makes sense. I'm really trying to gauge how effective running as a non-admin account is while elevating several processes.
    – TokinRing
    Commented Jan 28, 2016 at 15:14
  • I interpret your question as asking the following: " Assume that a Windows workstation has already been compromised by malware running with user-mode privileges. If the user of the affected account then uses "run as" to elevate or start a process with administrator privileges can the user-mode malware take advantage of that?" But if so, you might want to edit the question again to clarify that you're assuming (1) compromise has already occurred and (2) the malware that invaded is still limited to user-context privileges. Because the answerers so far are reading the question differently. Commented Jan 29, 2016 at 18:53

2 Answers 2


There is so many variables to this question with that been said but I'll provide an few scenarios.

Scenario 1: User machine has been infected by an "virus.exe" which is executing under the user context "TokinRing" which is not an administrator account. You've decided to run an application "cool.exe" as an administrator account. Default windows security for "virus.exe" will not prevent to use any APIs such as OpenProcess, SendMessage and so on against "cool.exe" since it's executing under higher permissions.

However, if "cool.exe" is using is vunerable to buffer overflow which can be influenced by non-administrative account. So, let's say "cool.exe" reads an file which any user can write to. If "virus.exe" creates an file to cause buffer overflow and execute shellcode to do whatever under an higher permission process.

Scenario 2: User machine has been infected by an "virus.exe" which is executing under the administrator/system context this virus can execute in any any process in the system and could impersonate any local user.

If you could make your question more specific I'd gladly give you much more indepth answer.

  • This actually helps quite a bit, my question partially boiled down to if running as a non-admin account offered significant protection. It sounds like the answer is "Some".
    – TokinRing
    Commented Jan 28, 2016 at 15:14
  • 1
    Yeah, it offers a good amount of security since it's more down to fact of your user unpatched windows or user installed vulnerable software. Just keep in mind that it’s not bullet proof and in my opinion any amount of additional security is better than none at all.
    – Paul
    Commented Jan 29, 2016 at 0:32

That depends a lot on the process who is used to conduct the exploit. If the elevated privilege process is the one being used, then any shellcode injected into the logical address space will have administrator privileges.

So if a normal user starts, for example, Firefox as administrator and catches a malware using drive-by-download, the exploit will have ring 0 access. That's also the reason why it's almost always a bad idea to run anything unnecessary as administrator.

You must log in to answer this question.

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