Jump to content

Problem with program quarantine


Recommended Posts

File not properly quarantined.


Steps to reproduce:

1. Turn off file guard protection. Fileguard detects the program as Trojan.Generic.KDV.715285 (B)

2. Download autosandboxme2 from -> hxxp://public.avast.com/dev/autosandboxme2.exe. If allowed to run, this program copies a text file to the root drive and adds a run key to the registry.

3. Run autosandboxme2

4. Program is verified as dangerous by the Emsisoft Anti-Malware Network. (see attached)

5. Emsisoft has detected suspicious behavior and the Anti-Malware Network has confirmed that suspicion. (see attached)

6. The file has been quarantined. No further action is required. (see attached)


The problem? The file has not been quarantined. It is still sitting on my desktop and nothing is in quarantine.






Link to comment
Share on other sites

  • 2 weeks later...

There is nothing to fix to be honest. AutoSandboxMe2.exe (parent process) creates a copy of itself as AutoSandboxMe2.exa (child process) and runs it. The parent process then waits for the child process to end to delete the copy. The dialog box you see as well as the malicious actions are simulated by the child process. So once you click the button our behavior blocker steps in. The child process is then terminated and the child process' image file (AutoSandboxMe2.exa) is queued for quarantine. Since the child process is gone however the parent process wakes up and deletes the file. So once the quarantine thread in EAM is ready to quarantine the file, it is already gone so there is nothing to quarantine.

Link to comment
Share on other sites

Not really. Who deleted it doesn't really matter to most users. Similar things may happen when Windows Defender or some other AV deletes the file before us. Technically we do know whether we deleted a file or not, but only after the quarantine thread finished. The quarantine thread however has an inherent delay to essentially wait for a few seconds to see if other infections will show up to clean them all up in one swoop. That is done because EAM's quarantine process involves scanning thousands of places on your system where a file could have registered itself to remove those references properly as well. That process of enumerating all possible load points does take a while and costs quite a bit of resources. So instead of doing it for every file we want to quarantine we try to do it in batches so we only have that overhead once per batch. In your case it wouldn't matter, but it matters greatly if you take an archive that contains 1000 malware files and just unpack it with the File Guard being on. You used to be able to DoS a system running EAM that way if your malware archive was large enough.


So waiting for the quarantine thread to finish to display a message will always cause the message to be delayed. This delay is really bad for usability. When we block a file, Windows will almost always throw a more or less cryptic error message. Currently our message and Windows' error message show up at the same time, so the user can make the connection. Having our message show up delayed by 5 or so seconds though keeps the user wondering for that time. Of course we could display multiple messages. However, that will result in a lot of spam that most users don't care about. That is why we display only one message when we queue the file to be quarantined, because in almost all cases it will really be quarantined. We could maybe change the alert text to specifically state that the file is only queued to be quarantined but not actually quarantined yet, but to be completely honest I don't think users will care.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...