7

In the task manager, I saw an instance of rundll32.exe running, no big deal. Just for fun, I wanted to upload the source file to VirusTotal.

Screenshot of VirusTotal scan results.

Where I noticed, the rundll32.exe file does not have the verified signature flag like the rest of the system32 files - it is as almost like it is faked. Which gave me worry, because it is very easy to swap system32 files in Windows by any program which you gave administrator permission (e.g. many setup files).

Also I found the first submission date suspicious for such an old file. Does Windows 10 constantly upgrade this file?

Screenshot of VirusTotal submission times.

I expected it to look like it does for other verified files:

Screenshot of VirusTotal scan result for verified file.

How can I understand that the file is not corrupted?

Edit1: Here is the link to the analysis. https://www.virustotal.com/en/file/d25ff1e6c6460a7f9de39198d182058c1712726008d187e1953b83abe977e4a0/analysis/1495024378/

Improve this question
0

3 Answers 3

Reset to default
6
+50

It appears this is a pretty simple thing. Windows builtin files aren't individually signed and stored in the binary, they use catalogs to store their signatures. See here: (it's old but mostly still true: https://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/)

You can verify this yourself with a quick signature check of the relevant files: enter image description here

You should also be able to use signtool to verify the catalog, which I'm not sure which is used for rundll32.exe. 

signtoolverify /c fileIdontknow.cat rundll32.exe

That should tell you if the catalog contains it, though I'm guessing it should.

Improve this answer
2

Edit 1: See @Ori's great answer for how Microsoft has signed a bundle of these executables. I am leaving this answer here because I believe that my argument as to whey the files are not individually signed with Authenticode (what VirusTotal reports on) is still valid. End addition

I could not find an official Microsoft answer, but I have a theory as to why this program (and others like it) are not directly signed.

I have checked several of my computers and VMs and found that this file is not Authenticode signed, at least not in anyway that I recognize. I do have several different versions of this file (going back 8 years). Clean copies of Windows 10 (different builds) have different versions and time stamps so it appears that Microsoft does update this file.

Ok, so why would Microsoft not sign this file? I think that the answer is found in rundll32.exe's purpose. Rundll32.exe is used to run dlls that have functionality that is needed but do not have exes to run them. You can see some examples in this How To Geek article.

Authenticode signatures enforce identity, determine what appears in a UAC prompt and help ensure that a file is not tampered with. If a dll that is a part of a process requests elevation the signature of the exe is used for the UAC prompt as that is the process that is running, not the dll.

Now for some guess work as to why the file is not signed. Because rundll32.exe executes unknown 3rd party code as part of its purpose a signature would be bad for security. Usermode level code can request that rundll32.exe run their dll. If a dll requested elevation the popup would show rundll32.exe, that is signed and verified by Microsoft, asking for Admin permissions. This would make people far more likely to say yes then if an unknown author program asks for permission, which is its current behavior. Because Microsoft cannot reasonably guarantee the function or safety of the code that rundll32.exe runs it would be dangerous for them to sign it directly.

Edit 1: @Ori has figured out how Windows validates these files. This last paragraph is here only for history. End addition

Now this does not mean that the Windows operating system does not validate run32dll.exe. It could (more guess work) compare the file's hash to determine if something has tampered with it. And then execute it only if it is a valid file.

Improve this answer
3
  • 1
    Because Microsoft doesn't sign every binary, is the short answer. There is no real reason to not sign every binary they ship, rundll32's legacy harkens back to rundll and windows 3.X and it's likely nobody has bothered to sign it. There might be some build workflow reason, but MS has had nothing but time to fix that if it's something like that.
    – Ori
    Commented May 17, 2017 at 23:56
  • Turns out I was wrong, it's signed in the catalog like the rest of the builtins. To ammend my previous comment MS doesn't sign every binary the same way is the easiest answer.
    – Ori
    Commented May 18, 2017 at 0:12
  • 1
    @Ori Nice find, but I still think my argument about why run32 should not be signed is valid.
    – AstroDan
    Commented May 18, 2017 at 0:15
0

It might be just the case that the tool that verified digital signatures in the backend at VirusTotal does not recognize the signature due to a new or alternative format, algorithm or signature. I would just try to analyze the binary using other tools than VT only, preferably native Microsoft and Sysinternals tools for signature validation. See these articles:

Otherwise it would be indeed suspicious...

Improve this answer

You must log in to answer this question.

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