Viruscope - how it works

Here’s a Google cache of Draft help text to get you started. I’ll check what more we can give you guys :slight_smile:

http://webcache.googleusercontent.com/search?q=cache:ixxjhpgsOHQJ:help.comodo.com/topic-72-1-522-6307-.html+&cd=2&hl=en&ct=clnk&gl=uk

MIKE’S SUMMARY OF HOW VC WORKS (DRAFT - Based on Builds 4058-4073)

Please note that this is just my personal assessment, based on some info from Comodo, much testing, and some extrapolation. The things I am most uncertain about are expressed in qualified language. It is supplied on a best endeavors basis.

I will update/correct as we find out more

I hope it will be of some help to testers.

Purposes

  1. Locally-based automated detection of malware by monitoring process actions
  2. Assist expert users to manually determine whether a process is malware
  3. Reversal of malware actions

Relationship to BB
When appropriate recognisers are introduced, it is intended that VC should work alongside BB to allow reversal of actions that cannot be blocked without instability.

Components

  1. Process activity logging
  2. Malware recognition
  3. Malware action reversal
  4. GUI reflections of above

Behavior
Logging

[ol]- The actions of all non-virtualised portable executable (.exe) processes, including trusted processes, are logged and this log appears to be retained for the process run session. Logging extends across sub-processes. Interpreted (eg Batch) executables are not logged. The log is accessible from

[li]Process in Killswitch ~ Properties ~ Process activity tab

  • Active Process List ~ Show all processes ~ Right click ~ Process Activities
  • HIPS, Firewall, AV alerts ~ Process activities link
    [/li]
  • These actions currently appear to be logged whether they actually happen or not. That is actions blocked by the BB are logged even though they do not happen. This is probably intended (see purpose 2)
  • The logged actions are probably those listed for reversal below plus

[li]Modify file

  • Delete file
  • Change file time to past
  • Enumerate files
  • Terminate process
  • Load image file
  • Close connection
    [/li]
  • Non-virtualised actions of virtualised processes are logged. Virtualised actions are not logged.[/ol]

Recognition

  • The following action sets when carried out by unknown (but not trusted) .exe processes , or their children (including batch files), lead to a non-virtualised, non-restricted .exe process being recognised (detected) as malware and an AV-like alert being issued:

[li]Move (not copy) self to autorun path

  • Move (not copy) self to other folder and copy link (shortcut) to self to autorun path

  • Move (not copy) self to other folder and set registry value in autorun key to self

  • Move (not copy) self to other folder and create autorun.inf autorun file in root volume directory. (e.g. X:\autorun.inf where X=volume drive letter.)
    [/li]

  • Detection of two stage moves (copy then delete) appears to be detected. Moves using cut and paste methods appear to be detected, though it is not clear if this is intended.

  • Sometimes these actions sets are alerted for BB’d (restricted) processes even though they are blocked. This is probably unintended. [Bug fixed] It is probably intended that non-blocked recognized action sets should be alerted - but there are none of these at present.

  • Batch or other interpreted files invoked directly from explorer.exe or cmd.com are not detected.

  • When batch files move themselves to an autorun path, that is not a detected action, but if they move other unknown portable executable processes from which they are run to autorun paths that is a detected action, though it will be detected as an action of the portable executable file.

  • Neither static heuristic nor signature based detection is currently employed to assist recognition

  • Recognition logging occurs under AV logs, but currently events are logged only when reversal is requested [Bug fixed]. A recogniser instance id is given in the Malware name column in the format Generic.Infector.n where n is an integer. Generic infector 1 appears to be ‘move self to other folder and create autorun.inf in root drive path’, Generic infector 3 appears to be ‘move self to other folder and copy link (shortcut) to self to autorun path’, Generic infector 4 appears to be ‘move self to autorun path’, Generic infector 5 appears to be ‘Move self to other folder and set registry value in autorun to self’ for path

Reversal

  • The following process actions when carried out by unknown or trusted unvirtualised .exe files, and their children (including batch files), can be reversed. At present trusted files can only be reversed from Killswitch and HIPS or FW alerts (block and terminate option), not from a detection alert… Also batch or other interpreted files invoked directly from explorer.exe or cmd.com cannot be reversed. Note that actions that would involve file caching to reverse are missing, and although batch file actions can be reversed alerting is limited (see above).

[li]Create file

  • Rename file
  • Change file attributes
  • Create process
  • Create key
  • Delete key
  • Rename Key
  • Set value
  • Delete value
  • Create connection
    [/li]
  • Reversal is initiated by selecting ‘clean’ from the VC alert, or by selecting ‘Terminate and Reverse’ from the process right click menu in Killswitch, and it appears not to be logged in detail yet, though an entry is made in CIS AV logs. There are the normal AV alert alternatives. Ignore once ignores for process run session. Report false positive must upload sig to Cloud?
  • Cleaning and thus reversal is the default action after receiving an AV alert and occurs after 2 minutes if no other action is selected
  • Reversal appears to be limited to actions carried out in the current process run session
  • When a process is reversed it is also quarantined using the normal AV quarantine feature
  • Restoring a recognised file from quarantine does not reverse the reversal, so if files were incorrectly deleted they would remain so.


Updating

  • The malware recognition component is updatable without updating the main CIS executable files. Possibly this extends to reversal facilities too - we don’t know yet

[b]

I don’t understand how Viruscope actually works, I mean it’s supposed to be able to undo changes by the malware, so if a malware called malware.exe deletes a file called movie.mkv which is 10GB then Viruscope detects malware.exe as a malware and you clean it then that movie.mkv should be recreated right? What I’m wondering is where this data is stored? I mean, it can’t be recreated out of nothing so Viruscope must have stored that whole movie.mkv somewhere and that must have taken 10GB off either from the hard-drive or the Memory… so how does it actually deal with this? Where is the data stored?

Also is it supposed to be Virus Scope or Virus Cope, if the later then I believe VirusCope looks better… just Sanyain.

It is Viruscope.

First, VC is VirusCope.
Here are what it can deal with (reversable things) but IDK if I can share it…gonna ask mods anyway

I am trying to get authorisation to disclose a more detail about Viruscope. I have asked, but have not got an answer - [Edite: this sort of authorisation understandably takes some time to sort out.]

What I can say is that the activities it can detect and revert are very limited so far. So that’s the answer to your very reasonable question. (One I asked too!)

They will be enhanced gradually by AV-like updates.

Mike

I see, I remember reading somewhere else something about Viruscope currently only monitoring something about autorun, so then it would only monitor that and if a malware is caught Viruscope would only revert the autorun changes even if the malware did other damage as well?

I realize Viruscope is in its infancy and things like these might still be under development so perhaps it’s impossible to answer for now.

Basically my thought was ransomwares that encrypt your data, if Viruscope would monitor file changes that would be a whole lot of data to keep track on, perhaps even terabytes for some people… Where would all that be stored in a hypothetical situation where Viruscope would monitor that?

Thanks for the info mouse. It will help users understand the feature better. Kaspersky has the same kind of feature.

I’ll try to get you a bit more info tomorrow or the day after Sanya. Best wishes. Mike

All such technologies revert the changes to some extent only, they do not recover deleted files. Or in theory, they can through data recovery method which may or may not be successful. You know, delete files aren’t actually deleted until it’s overwritten…

Kaspersky can roll back malware action(s), but only 30MB of data is stored in their cache. However, in the 2013 version you could increase the cache size to 3000MB etc., maybe that’s how Comodo will work…

I tried again today (for the VC notes) and yesterday (for the forma help file), but QA was not available

Sorry I will try again on Monday

Mike

Basically it’s necessary just for some initial files before the behavior blocker recognizes the malware. So you don’t really need 3GB to rollback, for example cryptor tries to encrypt 10 files at which point Viruscope would recgnize it and stop it. Files that need to rollback count to 10 files total and lets say 60MB in size. It’s not like it would allow the malware to try encrypting all your data and then stop it at which point you’d need a massive cache. But you need just lets say 500MB which sounds reasonable. Though that wonders me how it affects SSD drives because it would mean a lot of extra writes in the cache, unless if it’s dynamic in-memory cache (dynamic as it occupies RAM as needed and not permanently eating that amount of memory) at which point it wouldn’t matter.

Those are very good points! However what if the cryptor would start with files that are lets say 10GB? (I have quite a few media files that big) Then I assume those would be irreversible if you only had 500MB cache size?

A solution that stores the cache in RAM is also an interesting idea but I wonder have reliable it is, I mean, what if the malware would crash/shut down the computer after making some changes? The cache would be lost then if I’m not mistaken, since the memory is volatile… Perhaps it could be an optional feature?

True. But then again, crashing a computer before HDD/SSD has flushed its buffers results in a similar scenario. Maybe data will be written due to smaller buffers, but still, it would most likely be corrupted.

I have another theory, but since i’m not a programmer i’m not sure of they can be carried out at all.

What of Comodo intercepts the actions, holds them in it’s internal buffer as simulated actions and once found clean after enough actions performed through the behavior analysis, it actually performs them to the physical system and files. Until that happens, Comodo drivers would sort of hold them on probation in memory.

This way, program is executed, Comodo starts monitoring it what it does based on raw actions and follows the chain. Once it sees the file actually does nothing malicious, it would physically carry out the actions automatically. Now that i think off, avast! sort of does that already, but they do it as a physically separate step instead of being seemlesly transparent without app stopping and analysis and then app restart outside the virtualized environment. Run two apps in parallel, hold the one on live system on a starting point and run the same one within virtualized environment for analysis. Once carried out and found clean in virtualized space, let the pne on live system start and apply the changes within virtualized system to the live one.

It’s sort of like asking someone what he plans to do with something and once you see he has the things planned out right, you allow him to carry out the job opposed to let him carry out the job wrong and then you have to make the “rollback” and fix the badly done job.

Like i said, purely theoretical stuff, but maybe smeone from Comodo will get an idea about it that cpould be actually used.

And one more question about Viruscope…
Where in the scan pipeline does Viruscope stand? For example, i try to execute an unknown app that requires unlimited rights. I pick “Run unlimited” instead of Run isolated. Does Viruscope kicks in now and checks the behavior of the file even though i have picked run as unlimited or does it skip that file inteirely because i picked Run unlimited myself?

It would be smart to let Viruscope still analyze the behavior regardless of other selections. If the app is inside auto-sandbox or outside of it, Viruscope should be monitoring them. Or is doing that already?

As described in the help file it monitors all processes (hint: try right click, process activities tab in Killswitch, or right click on sandboxed processes display, or on any other alert)

But it only alerts and offers to revert unknown processes currently, so if you same something is trusted it won’t alert it. I think it’s long term CIS integration is still evolving.

If Viruscope is skipped if you allow some file past the auto-sandbox, then what’s the point of it then? It should be as an additional layer that prevents malware from doing much once user releases it from auto-sandbox (noobs would do that quickly).

It operates for unknown processes even if BB is off.

Currently if BB is on you will probably not see VC alerts, but that’s because current recognisers detect mainly, probably exclusively, (a small subset of) actions which are blocked by BB.

For what its worth I too think it’s [current GUI integration/immediate purpose] is somewhat confusing and have said so explicitly.

But its very clever technology with huge long term potential, IMHO

This alone makes new version very promising indeed :slight_smile:

Somewhat like Shadow Defender works? Well except it doesn’t monitor, only virtualize but you can make it save the data in RAM and then you have the option to merge it with the real system… But I think it requiers a reboot… (sorry for bad English, on a phone)