Hello all, Over the last eleven days, EP_X0FF/DiabloNova, the author of Rootkit Unhooker, has been publicly disclosing potential ways of bypassing Prevx's self protection without notifying us or taking any standard measures to ensure users remain fully protected. What began as a bit of sport for someone to leverage our brand to increase their popularity and raise some interesting, albeit unlikely, vectors of attack, has however been useful. It has enabled us to test and prove our responsiveness and our ability to react to specifically targeted and persistent attacks. Our feelings on this, as echoed by many of our customers, are that we performed well. We are as committed as ever to improving our product but should these exploits appear in the wild we have demonstrated more than enough ability, agility, and promptness to deal with them professionally. While to this date, despite thousands of threats attempting to do so every day, zero actual in-the-wild threats have ever penetrated the Prevx self protection, we nevertheless take any attempt seriously and always try to stay several steps ahead of malware authors, or even committed hackers whatever their motivation. On a technical level, all of these exploits require full debug-level administrative rights to function within the system. At this level, while it may be possible to terminate any and all security applications, including Prevx, it is also possible to steal user files and data, install rootkits, load drivers, overwrite the Master Boot Record, erase the entire operating system, or do any variety of nefarious actions. Prevx has always advocated a layered approach including a steadfast commitment to interoperability that allows our products to be used alongside most other security solutions. An approach which most other security companies do well to emulate sooner than forcing users to use their products as a lone and many times inadequate security set up. Inevitably, if a user, hacker or process is given full administrative rights, the self protection components of any antivirus product are totally vulnerable. Any determined hacker with heavily elevated rights could easily remove any AV with little work at all. At an even more basic level, there have been some recent tests where automated scripts were developed that simply ran the MSI uninstall routines of the top 10 major AVs - uninstalling them completely without warning. Additionally, many infections today do not bother terminating the antivirus product as it is the one telltale sign of an infection and today's threats try to survive covertly. Self protection, in the context of an antivirus solution, is primarily focused on preventing users from terminating the product (i.e. in a corporation which requires an antivirus product to be installed) and from preventing threats from terminating it under limited user accounts. Outside of these cases, self protection becomes a cat and mouse game with no winner. The first step is always prevention and Prevx's centralized database was able to automatically add protection for all 20+ variants of "UnPrevx" within minutes of each of their releases - many before they were actually released, resulting in the need for EP_X0FF to manually modify the builds several times until they got through, a case that was only successful because of the limited behavioral profile of the exploit. If UnPrevx were a real world threat, it would try to perform additional actions like stealing user data, an action that would not only be logged against the threat itself, condemning it as malicious, but one that would be blocked by SafeOnline automatically even if Prevx's processes were not loaded. Throughout this exercise, we have released a few updates to improve self protection but across all of the exploits, none were able to remove the underlying kernel-level components of Prevx. Therefore, if this was an actual piece of malware, Prevx would still have the upper hand on the system. There were several core versions of UnPrevx released - the Prevx database learned of the first instance before it was released, against .179, which resulted in us updating the protection of Prevx in release .185, still before UnPrevx was actually released. EP_X0FF then changed techniques and we released .186 with a minor improvement in self protection on XP, completing the additional protection changes and distributing them to our public alpha testers less than one hour after the release of the exploit. EP_X0FF then changed techniques again, and we released .187, again less than one hour after the exploit. After changing techniques yet again, we released .188 which blocked his new, XP-based attack generically. Each of these rounds has required a mere tweak and very little actual new technology and it is worth saying that all of these exploits are only relevant on XP as Vista/7/2008 all use an entirely different hooking structure. With .189, we have now fully blocked all of his techniques and while Prevx automatically restarts if it is killed, now it is unable to be killed by any known techniques. Ironically, his Rootkit Unhooker and nearly every other AV on XP has been vulnerable to these techniques, hence the escalating arms race. We surmise that EP_X0FF has targeted Prevx because of our fast responses. He has targeted other vendors in the past but they took several weeks to patch their holes while we patched each publicly within the same hour. He has also publicly complained multiple times now about Prevx adding protection/detection for the exploits themselves. The centralized Prevx database automatically analyzes software installations as a whole and is therefore made aware of aberrations such as the ones introduced by UnPrevx. EP_X0FF has considered us to be "cheating" with this, but the UnPrevx samples have each been blocked automatically - sometimes not on the first user, but each within the first couple users, despite the samples themselves not doing anything besides targeting Prevx. If UnPrevx had been a real malicious threat and our database did not automatically add detection for it, we would have of course added detection manually and tuned our rules accordingly, then released the necessary product updates as quickly as possible. Not doing so would be like building a force field and then saying that if someone with a gun was accidentally allowed in and we later saw the gun, we would still let him attack. The sum of the parts of Prevx is where the protection really shines, and we feel that this exercise has clearly demonstrated that the layered approach of Prevx protection as a whole is strong - even when someone is adamantly attacking it. We'd like to thank EP_X0FF for his work and would always welcome his ethical approaches on things we can do to improve our product. In the event that we cannot deal with exploits in a timely fashion then we have no issue with him or anyone else posting these after a period of notice as is acknowledged ethical industry practice. However, many of the techniques he is now suggesting essentially bypass any and all security products and to provide a public forum in this way is merely improving state of the art in malware authorship and now borders on recklessness. We will continue to react to properly and ethically reported exploits with the same speed as ever produced by anyone who feels our protection is in need of strengthening against a probable vector of attack. Of course, should a large number of our customers feel there is a benefit of a rapid threat disclosure reaction thread which outweighs the obvious risks this poses to all security products we would of course consider re-opening the point. We would, however, need to hear the other viewpoints of other vendors on this type of disclosure as it does indeed open the door for attacks against their products as well. For now we have closed the original thread but please feel free to respond to this post if wanted as we're always open to discuss our protection and the threats we see emerging on a daily basis. Thank you all for your continued support!