I recently updated my D-link wifi dongle driver. However, I had to do this through the command line because Microsoft revoked the D-link certificates after a leak. The executable would simply not start, with an red UAC prompt blocking the executable. However, the executable ran just fine when I started it from an elevated command prompt.

This got me thinking: a hostile agent could use a revoked cert from a trusted source to disguise malware as a driver update and upload it to the source's website secretly. The user would download the driver, try to run it, fail, google why it fails and find the alternative method and an explanation about how Microsoft revoked the certificate. In turn, he would conclude that, since he downloaded the driver from a trusted source, it's a false positive and he woul use the alternative method, installing the malware willingly. Hell, I installed the driver without considering that this might be an issue, only afterwards internally justifying it after discussion with the Super User chatroom and a Virustotal scan.

This might sound a bit conspiratorial, but I don't see this as an impossibility. Or am I mistaken in that?

  • How can you be sure that didn't happen to your dlink driver and you infected your computer when you installed it? Mar 17, 2016 at 5:41
  • @NeilSmithline I'm not 100% sure, but according to the website, the driver was made available before the day the leaked certificate was signed. I.e. the driver was released early february, and the particular leaked certificate was signed late february. So the driver was created with an older certificate that wasn't leaked, but still revoked.
    – Nzall
    Mar 17, 2016 at 7:23

1 Answer 1


I highly doubt the terminal is looking for revoked certificates. Which I imagine isn't a job of the terminal itself but UAC. But I can say this is expected behavior. You elevated the permissions of the terminal as admin. And it will run everything as admin by design. This includes elevating the child processes.

As far as bad it is no different then tricking someone into running an executable. For example someone could need help in a support form. And a malicious user could post a file with instructions to run it via an administrative terminal. The only things stopping the attack is if the prospective victim is smart enough not to do it. Or don't want to deal with the terminal. Chances are, if they are going to fall for it, the attacker is better off talking them into bypassing this through the UI anyways.

Changing this default behavior just isn't going to happen. Otherwise this would interrupt silent batch/shell jobs that rely on child/external processes. So if such a thing was to be patched you would need to give them a way to bypass the UAC. And a hacker would have the exact same access to that bypass method just adding another step of complication for a moot cause. Not only that, but what if the file wasn't malicious at all and you absolutely needed some way to run it.

Ultimately you had to elevate the the privileges to admin to make this work. You willingly did this with no automation and a prompt explaining what this elevation was going to do. Doing so you made your choice to waive any protection beyond this point.

You must log in to answer this question.

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