Malware Sample By-Passes Autosandbox + Disables HIPS [M1554]

Malware Sample Bypasses Auto-Sandbox + Disables HIPS

SHA256: 277c5d85c9b002be4b541a4c518ee3ef83877e77d113b3ea82f4c3be31b36d2e

File name: PO859585958595.exe (executes .bat file)

SHA256: eab54269e37992b78173956fe8c67dab7bbcb935852875b95b9bbc80d399b508

File name: ivepa.exe (dropped file - Users\xyz\AppData\Roaming - random_name.exe - different name every install)

NOTE: Installer is detected by signature at this time, but dropped files is not.

NOTE: Malware sample was tested with AV turned off to observe auto-sandbox, HIPS and configuration’s ability to protect system.

Can you reproduce the problem & if so how reliably?:

Every time - at will

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

** Disable AV Module **

1: Run sample.
2: Sample will not be auto-sandboxed.
3: Sample will disable HIPS.
4: Sample will disable anti-executable\default-deny configuration; any installer\application can be run and cannot be blocked.
5: User cannot block dropped file by changing file rating to “Malicious” after it is executed.
6: Dropped file can extract license keys.

Once malware is run it permanently disables the user’s ability to enforce CIS antiexecutable\default-deny configuration.

NOTE: This sample disables Windows firewall, UAC - as well as causes other brands of security software to malfunction.

One or two sentences explaining what actually happened:

Executed Bladabindi\ZBot variant. Sample was not auto-sandboxed. HIPS was disabled. Sample could run despite user changing file rating to “Malicious” in local database. Anti-executable\default-deny configuration was disabled; any installer\app could run instead of being blocked by CIS.

One or two sentences explaining what you expected to happen:

I expected CIS modules to be immune to attack, disabling and\or other tampering by malware sample. In short, I expected CIS to protect the system.

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

Not Applicable.

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

Yes. Malware sample attached.

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

Well-crafted piece of malware.

Exact CIS version & configuration: - Proactive Security with Enhanced Protection Mode enabed.

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


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

Yes. Configuration file attached.

Have you updated (without uninstall) from CIS 5, 6 or 7?:


 [b]if so, have you tried a clean reinstall - if not please do?[/b]:

 Current installation is clean.

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


 [b]if so, have you tried a standard config - if not please do[/b]:

 Malware's ability to impair CIS is configuration independent; various configurations\settings tested against sample.

 Malware's ability to impair CIS is system independent; tested on Intel\AMD, i3, i5, A8, A10, desktop, laptop.

OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:

Windows 8.1 x86-64 OEM (Toshiba), “Always Notify,” Administrator, No VM used.

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

a=None. b=None.


  1. Configuration file
  2. Anti-Virus Log
  3. Defense+ Log
  4. Malware Sample (zipped\password “infected”)
  5. Configuration Changes Log (changed file rating to “Malicious” - CIS did\could not block)

[attachment deleted by admin]

I made a mistake in original report and have made corrections.

I tested, re-tested and re-tested again to ensure all bug report details are correct.

If the malware is executed with antiexecutable\default-deny configuration enabled - the malware is blocked.

If the malware is executed before antiexecutable\default-deny configuration is enabled - the malware will permanently disable the user’s ability to activate the AE\DD configuration.

1: To activate\configure CIS for anti-executable\default-deny using the following settings - after executing malware:

A. Security Settings > File Rating > File Rating Settings > De-select “Trust applications signed by Trusted Vendors.”
B. Security Settings > File Rating > File Rating Settings > De-select “Trust files installed by Trusted installers.”
C. Security Settings > Defense+ > Auto-sandbox > Create rule as follows: Block - All Applications - Unrecognized

Best Regards,


This is another serious one

I’m not seeing any bypass or disabling the ability to activate the AE\DD configuration when I ran the sample. CIS functions normally and nothing touched the real system all files where ran fully virtualized and dropped files where contained within VTRoot folder and upon resetting the sandbox were removed. Also to enforce anti-executable/default-deny you must disable online lookup and the option to detect programs witch require elevated privileges.

According to Comodo support the settings for AE configuration are as described in original post; Cloud Lookup and Detect Installers has nothing to do with AE configuration.

I guess it depends on how you define AE as in to prevent any new executable introduced to the system from being executed or only preventing unknown executables. In either case with the sample you have provided I could configure CIS as an anti-executable after running the malware. The dropper, the .bat file, and the dropped file where all sandboxed and did not modify the system or corrupt CIS.

Could be system specific… it is reliably repeatable on my system. And the malware causes problems for Comodo as well as Kaspersky, Emsisoft, ESET, etc.


Thank you for the important feedback. We are checking.

Kind Regards

Hi hjlbx, please ping me on skype ( to discuss about this issue.


You have granted installer privileges to Explorer!!!
And what behaviour do you expect?..

Not sure what you mean… I haven’t granted anything to Explorer.

On my W8.1 system the sample executes, disappears from the desktop, and it causes both HIPS and sandbox to malfunction.

I have imported your config and seen HIPS ruleset “Installer or updater” assigned to Explorer.
It explains all your causes.

Like I said… I never granted anything to Explorer. I do not change settings for Explorer… it is always an Allowed Application. I would notice if it changed as I pay attention to that sort of thing.

I know what the log says, but I have never changed Explorer to a Trusted Installer - never… and it has always been only an Allowed Application per Proactive Security config rules under HIPS in my CIS installation.

The sample is being analyzed by Comodo. Ultimately, it is up to CIS engineering to decide…

You have done it, like on the attached video

[attachment deleted by admin]

08/16/15 - Comodo Engineering has sample. They are investigating. No other infos\feedback provided at this time.

During remote session with CE I asked the engineer if he needed to execute sample on my specific system.

CE reply: “Not necessary…”

Engineering needs time to investigate…

Best Regards,


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.

Thanks again

From configuration it seems that installer/updater ruleset was utilized on ‘explorer.exe’. This action is dangerous as it can disable security.
Thus, it’s invalid.

I will move this one to “Resolved” section.
Thank you.