The only option i found for self-defense in avast was “disable self defense” and it wasn’t checked so i assume its on by default.
I used APT (Kernel Kill Method #2 was successful) …basically it uses the ZwTerminateProcess kill method (ntoskrnl.exe)
from a device driver loaded onto the system.
and avast doesn’t block this…although they do block Kernel Kill Method #1 (ZwTerminateThread)
I was able to kill ALL avast processes and shut it down completely without any attempt by avast to stop this from occuring…
which is bad because I’m sure malware writers could use this to disable avast and then load viruses onto the system.
Like i said, there is no option of turning self-defense mode “on” , only “off”, which i did not mess with. Meaning its on. I assume
Avast resisted about 16 other methods of killing it, but it fell to this one.
Additionally, i just found another method of terminating avast (Crash #1 in APT) ; it tries to crash the target with the VirtualProtectX method, which attempts to fatally crash the target process by setting each page of its virtual memory to PAGE_NOACCESS (kernel32.dll)
(was able to shutdown almost every process with this, except the AshWebsv.exe and AshUpdsv.exe, so the main avast was gone…although those 2 processes remained.
With the first method (ZwTerminateProcess) I was able to kill off ALL the avast processes, thus disabling it completely.
They acknowledged that avast could be disabled by some methods. I had a Bagle (Beagle) infection that destroyed my Vista installation starting by avast one. They’ve tried a balance between a too invasive and conservative protection that messes other applications functions. Maybe they can find a solution for this method in particular.
The self-defense module is protecting against user-mode methods only. If the malware is running on ring-0, it can do basically anything it wants (overwrite memory, …). So yes, you can kill avast! with kernel kill.
The crash, however, should not work… I guess Vlk will take a look at that.
If the malware is already running in a driver, it can do anything - such as overwriting the memory of the driver that’s preventing the kernel kill - so it’s a lost fight anyway.
If the malware is already running in a driver, it can do anything - such as overwriting the memory of the driver that's preventing the kernel kill - so it's a lost fight anyway.
Umm, then don’t let the malware run a driver. Its that easy. Don’t be a defeatist. Your responsibility as part of the antivirus company is to protect such drivers from being able to create “a lost fight”, so don’t let it happen. Look at how good Kaspersky is against self-termination; this method didn’t work on them…
When I did my testing, I took that issue into consideration. I only launched my attempt at process termination (and the device driver associated with it) AFTER the antivirus was fully protecting my system. Therefore, it had FULL control and ability to block such an attack and FAILED, leaving it compromised.
Therefore, it is QUITE possible to block against this…just block that method of termination (ZwTerminateProcess), also, harden attempts against the Crash I was able to execute. that i mentioned earlier.
;D Well, if avast! detected the driver (or the malware dropping the driver), then of course it wouldn’t allow it to be loaded. We’re talking about new, undetected malware - when none of the files is detected. So no, it’s not that easy.
But yes, it’s just about blocking a driver loading (or installation) in general - as I wrote previously. Of course, it’s not possible to block all drivers (many applications use their own drivers, and you wouldn’t be happy if they were blocked). So, what is needed is a behavior blocker, announcing suspicious or unusual events - with rules, exclusions, whitelist…
I’d say it will happen in the future version of avast!, but it’s simply not possible right now.
That’s what I am saying - yes, it would probably be possible to block this one particular method - but it’s not a real protection, the driver can do anything; if it wants to kill Kaspersky, it can.
So, what is needed is a behavior blocker, announcing suspicious or unusual events - with rules, exclusions, whitelist...
Right, that is what I was trying to say, a prompt that asks the user “do you want to install this” , sort of a built in HIPS for the antivirus…would have to not conflict with other HIPS too though…I’m not sure whether the end solution is to have 1 hips program for the entire machine by itself, or each one built into firewalls and antivirus to protect…because we don’t want them fighting…what do you think about that?
Yes you’re right, Kaspersky isn’t invincible but its pretty damn hard to remove…because of the HIPS-like behavior it uses…if the user makes the right choices of what to block, they might be okay.
It’s not possible to fix now, I suppose that will have to stay vulnerable then…kind of worries me.
Why is it not possible?
Show me a video of a system where Kaspersky is installed before any malware is present on the machine and then show me the driver being able to terminate it…I highly doubt that will happen.
Because it’s not a “fix” - it means programming quite a lot of new features.
Building a reasonable HIPS is not something doable in a week (or month). So, it will take some time.
You don’t get it.
I am not going to create any videos or program any killing drivers; drivers in Windows run on ring-0 - they have all the access they want, so they can do anything the hardware supports. That’s a fact, based on Windows / Intel architecture. So, no matter how much you doubt it, it is possible to do.