LNK-file can execute any program with trusted installer's privileges [M1410]

A. THE BUG/ISSUE (Varies from issue to issue)

Can you reproduce the problem & if so how reliably?:
Yes, every time.

If you can, exact steps to reproduce. If not, exactly what you did & what happened:

  1. Create any executable file, e.g. “test.exe”

  2. Create LNK-file containing a command like this:

%comspec% /c &

E.g.: %comspec% /c %windir%\system32\tcmsetup.exe /Q & test.exe

  1. Execute LNK-file

  2. Take notice: the program “test.exe” is started without alerts and without restrictions.

  3. Open the “Active Process List” and notice that the program “test.exe” is taken for a child process of “tcmsetup.exe” and therefore it has installer’s privileges

One or two sentences explaining what actually happened:
This is a critical fail of “Heur Cmd-Line Analysis”. Through this fail any virus can become trusted and be executed without restrictions.

E.g.: This command adds the file “test.exe” to trusted and executes it:
%comspec% /c %windir%\system32\tcmsetup.exe /Q & copy test.exe test2.exe /y & test2.exe

This command executes the file “arc.exe” several times:
%comspec% /c %windir%\system32\tcmsetup.exe /Q & for /L %n in (1,1,10) do arc.exe -ppassword
When the file “arc.exe” extracts and executes even a known virus, the virus becomes trusted and runs without restrictions

It is the simplest way to bypass Comodo HIPS, Auto-Sandbox and Antivirus together!!!

One or two sentences explaining what you expected to happen:

If a software compatibility problem have you tried the advice to make programs work with CIS?:

Any software except CIS/OS involved? If so - name, & exact version:

Any other information, eg your guess at the cause, how you tried to fix it etc:

I had tried to block LNK-files on removable devices, but Comodo can’t do it.

Exact CIS version & configuration:
Configuration: Proactive Security

Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:

“Do not show antivirus alerts”: disabled

Safe Mode
“Create rules for safe applications”: disabled

Auto-Sandbox: Enabled, default rule set
Firewall: Safe Mode

Have you made any other changes to the default config? (egs here.):
No changes

Have you updated (without uninstall) from CIS 5 or CIS6?:

Have you imported a config from a previous version of CIS:

OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Win7x64SP1 (VMware), Admin, UAC is enabled

Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=None b=None

[attachment deleted by admin]

Thanks for another great bug report. Can you please attach your KillSwitch Process List (instructions on how to do that provided here) then i will forward this.


[attachment deleted by admin]

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.


The devs have not marked this as Fixed in the tracker. However, sometimes bugs are fixed by the release of new versions, but not marked as Fixed in the tracker.

If you are able please check with the newest version (CIS version and let me know if this is fixed on your computer with that version.

Thank you.


This is not fixed.

Configuration: Proactive Security
Win7x64SP1 (VMware), Admin, UAC is enabled

[attachment deleted by admin]

Thanks i have updated the tracker.

This bug is partially fixed by the version CIS Beta
It doesn’t appear with this version when an *.exe file is used as “trusted installer”.

But what about other types of trusted installers? They are also able to used in the command:

%comspec% /c <any trusted installer> & <any untrusted file>


%comspec% /c %PROGRAMDATA%\Comodo\Installer\cis_setup_x64.msi /q & malware.exe


%comspec% /c installer.msi /q & malware.exe

(The file “installer.msi” is any trusted msi-file placed in the same folder as the file “malware.exe”)

This bug is not fixed for such installers as MSI.
I have attached an example.

[attachment deleted by admin]

Thank you very much for letting me know. i have added this extra info to the tracker. As least some progress is being made.

Keep on testing things.

Is this bug fully fixed in the latest V8?

Only partially.
CIS still can be bypassed by this method. See attachment.

[attachment deleted by admin]

This is not a bug as this is working as designed. Any executable that is executed by a “Trusted/Installer” will inherit the same rights as its parent process in this case become Trusted/Installer as well. Just like if an unknown executable is sandboxed as Partially Limited,Limited,Restricted,Untrusted, or Fully Virtualized and executes a trusted application, that trusted application will also be sandboxed with the same restrictions as the aforementioned executable. You are intentionally running a trusted/installer and passing to it an unknown executable to be executed by the trusted installer, no user would normally do this. However, to prevent sub-processes being treated as Trusted/Installer as the result of being launched from a trusted installer, you can disable the option to automatically detect installers under sandbox settings “Detect programs which require elevated privileges e.g. installers or updaters”

No, this is a bug.
Moreover, this is a vulnerability, that can be used by trespassers to bypass Comodo’s Defense+ and Antivirus. I have shown it on the video.

E.g. the victim opens an infected flash and opens an LNK-file, taking it for a folder, and the malicious programs executes bypassing CIS. LNK-files are popular as starters for the viruses.

In fact, the unrecognized program in my example is not a child of the trusted installer. The real parent application is the interpreter cmd.exe. But the child application inherits privileges of the installer by mistake.

In addition, it is absurd, that CIS takes for an installer any trusted program bigger than 40 MB. I have used this “feature” to bypass CIS in my recent example.

It isn’t enough. To avoid this vulnerability you have to:

  1. enable Auto-Sandbox with the rule set as for the configuration “Proactive Security”;
  2. disable the option “Detect programs which require elevated privileges” (you are right);
  3. disable the option “Trust files installed by trusted installers”.
    And you must remember that HIPS still will not control programs running by trusted installers. Only Auto-Sandbox will block or virtualize those programs.

In your most recent example malware.exe is a child process of the trusted/installer, which is digitally signed by Microsoft, any_big_trusted_unexecutable_file.bat as you can see in the attached screenshot. When using a normal executable installer which I have provided an example here causes malware.exe to be sandbox after the installer is closed.

[attachment deleted by admin]

“malware.exe” is NOT the child process of any trusted installer. Its real parent process is cmd.exe
But CIS takes “any_big_trusted_unexecutable_file.bat” for the parent process. That is the essence of this bug.
And your screenshot illustrates this mistake.

I fact the program “any_big_trusted_unexecutable_file.bat” doesn’t execute any file.

Yes, the problem is partially solved, in comparison with the version CIS 8.1 and below. In the version CIS this bug doesn’t appears with exe- and msi-installers.
But unfortunately trespassers aren’t obliged to use only “normal executable installer”, when they want to bypass CIS : )

In addition, the attached program “any_big_trusted_unexecutable_file.bat” is not a real installer. It is only a big signed file. But Comodo takes it for an installer. It isn’t reasonably.

Should be fixed with version <>.

Thank you.