I read this question: Is it common to allow local admin access for developers in organizations?

This question makes me wonder. I can see how local admin access is a danger to the machine. But can a computer with a user account with local admin access actually be a bigger danger to a properly set-up network than a computer that does not have local admin access? If yes, how?

  • 1
    @schroeder assume no different than a non-admin user, since we are comparing those.
    – Belle
    Jul 23, 2018 at 13:51
  • 1
    If you haven't seen developers run rogue DHCP servers (as often as not, just by mistake -- for example, meaning to do so only for a VM, but bridging it to the main network in error), you're either lucky, or haven't worked somewhere developers were running subnets with test hardware or otherwise doing adequately interesting things. :) Jul 23, 2018 at 19:48
  • 1
    Your question is a bit mixed up. What do you mean by be a danger to the a properly set-up network over a computer that does not have local admin access?. Did you mean: Is there a risk for another computer that the user has no admin access to over a well-setup network?
    – Tom K.
    Jul 23, 2018 at 19:51
  • 2
    @TomK. Yes, basically to anyone or anything on the network that is not the computer in question.
    – Belle
    Jul 23, 2018 at 20:11
  • 1
    @Falco, this was some years ago, so probably not. Good point though, nowadays more and more software is designed to install in user space, so denying admin access to the end user is only a start, not all you need to do by any means. Jul 26, 2018 at 8:19

8 Answers 8


Local Admin access means that it is easier for the attacker to establish persistent control of the host, to install software and modify system settings, and to take actions like sniffing the network that may allow it to move laterally onto other systems.

So, yes, it is a danger to the network, in that it provides the attacker with more stable access to a more capable platform for lateral movement.

  • 2
    I have local admin access, as well as persistent control and the ability to install software and modify system settings on my own machine, and yet I do not pose a particular threat to the internet (at least, not the hosts that are properly set up). Could you elaborate on why a LAN would be different in this respect?
    – Ray
    Jul 23, 2018 at 20:27
  • 6
    @Ray on the Internet, you've got non-local (non-broadcast) connections to a lot of machines with some level of their shields up. On a LAN, the shields are down, peers are trusted, and depending on the network config there may be very juicy bits of data in the broadcast traffic. A 'wolf' in the LAN full of sheep is far more dangerous than on the Internet.
    – gowenfawr
    Jul 23, 2018 at 20:29
  • 9
    Note that not every LAN is trusted; it is entirely possible to have a trustless network. That doesn't mean you can just stop worrying about local admin escalations, of course, but it does make them moderately less scary.
    – Kevin
    Jul 24, 2018 at 0:46
  • 1
    The attacker can already install a lot of software without admin access, modify many user-scoped system settings. Add itself as a background startup programm for the user. Of course local admin gives more local access - but on the other hand a user with local admin has an easier time to wipe his machine.
    – Falco
    Jul 26, 2018 at 7:14
  • I would not be sure to agree to "more capable" from a network perspective. The attacker can "dig in" on local admin, after he successfully mounted an attack.
    – Falco
    Jul 26, 2018 at 7:16

Danger is a bit of a strong word. I would say that local admin access presents additional network risks over non-admin access.

Admin access allows the user to run a packet sniffer in promiscuous mode. That can present additional risks if the network in question is vulnerable to MiTM attacks, or other unencrypted, sensitive information goes across the network.

You have to understand this risk in the context of users normally having physical access to the network. A malicious insider with physical access to the network cable could just simply plug their own device into the network which they have root/admin access too, and sniff packets on and perform the same attacks without root access on their own machine.

  • You are assuming local intrusion/attack. Non insider attacks with non-admin level would have to work (scalate privileges) to be able to get promiscous mode network, so imho it is a danger. BTW, I like the carefull with the network cable advice.
    – bradbury9
    Jul 23, 2018 at 19:14

It is far more danger than most people guess. When we debated how much someone could do from Local Admin (local account, not domain account) on one domain-joined machine, I said "Would you like to find out?" Nobody did. Turned out they wanted to debate the theory but not put it to the test.

I argued on the other question what are you defending against. Well here's the thing. The next time anybody else connectslogs on to the machine in question, the local admin can impersonate that user. If it was a network share access, the impersonation can be only used for a few minutes. But a few seconds of domain admin is plenty to create a service on a network share on the domain controller. Microsoft finally fixed it so that network share access isn't transitive anymore and in doing so fixed this too.

In the old days it was stupid worse. The machine can MITM-attack anybody on the network not specifically defended against arp-spoofing. Until recently, this was the end game, but MS finally got their act together and closed SMB against MITM by fixing the auth package and actually making a backwards-incompatible change so that it stays fixed.

But not permitting the developer's VLAN access to the internet is dumb. Perhaps the best thing to do is let them have admin on their machines or VMs but simply not join them to the domain.

Yet this almost never comes up. The threat of being fired and prosecuted keeps the developers from going all-out like this, and for some reason internet-bourne malware doesn't use this stuff. So again, what are you really defending against? The developers probably can take over anyway. You've got to install version updates on production sooner or later.

  • 1
    Basically, "if the machine is shared it suddenly gets a whole lot worse".
    – Riking
    Jul 24, 2018 at 18:22
  • Can it be at least partially mitigated by isolating the clients on the switches? So that every PC can exchange traffic only with an uplink port? Of course it still exposes whatever is available (like local servers) to the malicious machine, but at least limits broadcast, ARP and direct (PC-PC) traffic.
    – filo
    Jul 25, 2018 at 8:57
  • @filo: only if you key your Mac addresses into your switches. But that still doesn't block token stealing.
    – Joshua
    Jul 25, 2018 at 13:17
  • I think you are mixing up domain admin and local admin. I can impersonate a user with local access to his account already? Local admin does not change anything from an outside perspective
    – Falco
    Jul 26, 2018 at 7:10
  • 1
    @Falco: I am not. Never underestimate the power of a kernel debugger. Once the domain admin connects at all the thread running as him can be changed to do something else.
    – Joshua
    Jul 26, 2018 at 13:28

Admin access means you can run certain privilege-requiring tools. Packet sniffers are one mentioned by other. Another example is an ARP-spoofer/poisoner for MitM attacks, or an mDNS/NBT-NS impersonator(e.g. Responder). Generally any tool which requires low-level network access, or the ability to open certain protected ports is more likely to require admin access.

Also, being a local admin vs a non-admin means you are going to be able to access certain things on that machine which could allow you to pivot to others, e.g. using mimikatz to dump stored AD passwords, access the full registry on Windows, install keyloggers cross-account(i.e. as a daemon/service), etc.

It's honestly night-and-day having admin access to not; it's the reason things like OSCP focus so heavily on learning privilege escalation, and not just gaining an initial foothold.


Yes, it's dangerous.

In 2014 I had a case which went like this:

  1. Developer with local admin rights takes ownership of utilman.exe, which is an ease-of-access application
  2. Replace utilman.exe by cmd.exe (which is also signed by Microsoft, so a signature check does not reveal it)
  3. Restart the PC and click the accessibility icon

Voilà, you have a console with NT Authority/System rights. You can now spy credentials from critical processes such as LSASS (e.g. using Mimikatz). If you can trick your admin (social engineering) to remotely logon at your PC, you have his credentials.

If you can't, just install a service that runs with System rights as well. You can then undo the hack and simply let the service wait for a longer time to collect credentials for you.

It seems this has not ben fixed in Windows 10.

  • 4
    Note, however, that unless you were using full disk encryption, the attacker didn't need admin rights. They could simply have booted to removable media and replaced utilman.exe with cmd.exe that way. (Although what really puzzles me about that story is why someone who already had admin took such a round-about route to get to SYSTEM in the first place. There are easier ways!) Jul 24, 2018 at 23:37
  • @HarryJohnston: ok, which easier ways? Jul 25, 2018 at 6:59
  • 7
    You can download psexec from the Microsoft web site, it has an option for running an arbitrary command in system context. If you want to do it yourself you can install a service. Another option is the Task Scheduler. None of these are security vulnerabilities, if you have administrator privilege you're entitled to run code as local system. Jul 25, 2018 at 7:52
  • Developers are less likely to be familiar with administration and/or security tools like psexec, so it makes sense they'd resort to something like replacing executables. Dec 27, 2018 at 0:25
  • @AngeloSchilling: Actually no. That was for a while the preferred method of unwedging a machine with all administrative passwords lost. And yes, it was done from a boot disk.
    – Joshua
    Jan 26 at 22:49

It depends what you mean by "properly set up network".

If you configure your network to treat every host on it as potentially evil, most likely compromised, and a possible source of attack, then local admin access is not a danger (that you are not already expecting).

In the real world, any internal network and most data center networks are set up with an assumption of some level of trust, meaning that they are at least more trustworthy than the outside / the Internet.

Local admin challenges that assumption. Note that I said "challenges", not "breaks".

You need to ask yourself how trustworthy your local admins are, both on the scale of intentional action and on the scale of errors and mistakes. That is now your level of trust on the network.


Well just an example. Suppose you have a reasonably secure network with a firewall that allow full outgoing http/https access from user desktops, and no other incoming or outgoing access from those machines, and some other protocols for internal servers (DNS, mail, etc.)

A local admin can set up an https proxy from his/her desktop to an external relay and use it to completely bypass the firewall rules. It can even be done for good reasons because it allows to continue to work or test from home. But it just defeats the goal of the corporate firewall...


The answer to your question is "yes." The attacker can very easily convert the machine into a zombie and perform malicious tasks (with full admin rights) on your network.

One of the most difficult attacks to mitigate is the "Insider Attack." In your case, you are allowing an attacker to perform attacks from your internal network with full rights on a zombie (compromised machine).

  • 1
    Local admin does not mean network level admin rights. Did you mean to say that?
    – schroeder
    Jul 23, 2018 at 19:03
  • 2
    This is not the traditional use of "insider attack." That normally refers to someone who has legitimate access trying to do something nasty. Jul 23, 2018 at 19:42
  • @Schroeder, Not the network admin.
    – Sayan
    Jul 23, 2018 at 23:56
  • @TempoaralWolf, scenario is similar if the attacker converts machine to a Bot.
    – Sayan
    Jul 23, 2018 at 23:57

You must log in to answer this question.

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