AVLab.pl Advanced In-The-Wild Malware Test - September 2025

[Trident]

Calling the said executables and doing some work through them is a standard tactic that attackers have applied for many years, to fragment the attacks and fool the correlational logics, which in a behavioural blocking are the most crucial and very high amount of R&D is focused on them.

The initial vector can still be an executable file which Webroot through reputation, Infrared and so on can still detect. But it will be a different result if the same LOLBins are called through documents, scripts, exploits and other methods.

The Webroot protection against these is poor and needs to be layered with other products to fill the blind spots.

Furthermore, Webroot by default does not monitor the behaviour of these LOLBins.

 

[stonjean633]

I could not recognize the page in light mode

You really won't recognize it as it's Kaspersky. You already abandoned K and won't be using it again. You're already on default-deny. Hehe

 

[ForgottenSeer 123960]

Trident, you raise a technically sound point regarding the fragmentation of attacks and the specific challenges of correlation logic. It is widely accepted in the industry that shifting the initial vector, moving from a compiled executable to a document macro, script, or exploit, can significantly alter the detection landscape. Historically, reliance on the reputation of the parent process has indeed been a weakness for many behavioral engines when facing these types of fileless threats.

However, we must interpret the results based on the specific telemetry provided in this assessment rather than historical assumptions about the vendor's default architecture. The methodology documentation explicitly cites "zero-day web components" and "cloud-based execution vectors" alongside the usage of `node.exe` and `az.exe`. These vectors inherently function dynamically, mirroring the script-based and fileless methodologies you are concerned about. If the solution achieved a 100% interruption rate in a dataset containing these specific "Living off the Cloud" kill chains, it implies that the behavioral monitoring in this specific test environment successfully bridged the gap between static reputation and active behavior.

Regarding the assertion that the solution does not monitor LOLBin behavior by default, the empirical data from this test presents a contradiction to that theory. For the detection logic to interrupt a kill chain involving `powershell.exe` or `rundll32.exe` driven by a web component or cloud script, it must have triggered on the malicious behavior of those trusted system binaries, rather than just the reputation of a calling file. While skepticism of any vendor is necessary, the data from this September assessment suggests that the specific blind spots you described were covered in this iteration of the test.

 

[Parkinsond]

You really won't recognize it as it's Kaspersky. You already abandoned K and won't be using it again. You're already on default-deny. Hehe

I thankfully use whichever K provides for free; something is better than nothing.

 

[Trident]

Regarding the assertion that the solution does not monitor LOLBin behavior by default, the empirical data from this test presents a contradiction to that theory. For the detection logic to interrupt a kill chain involving `powershell.exe` or `rundll32.exe` driven by a web component or cloud script, it must have triggered on the malicious behavior of those trusted system binaries, rather than just the reputation of a calling file. While skepticism of any vendor is necessary, the data from this September assessment suggests that the specific blind spots you described were covered in this iteration of the test.

The test presents no information about Webroot terminating any LOLBins whatsoever, it presents information that from this malware set Webroot detected all malware.

The abused LOLBins statistics most likely come through behavioural/sandbox analysis of the malware.

Webroot not monitoring these processes can be seen under the process monitor that is provided by nobody else but Webroot themselves. By default, high reputation and prevalence executables are not monitored by Webroot and this has been the software behaviour for many years.



The users have to manually select “monitor” for Webroot to start monitoring.

The recent additions like Script Shield and Foreign Code do not perform as well as other solutions.

Rundll is used to execute modules which have the same structure like executables and can be detected by similar technologies used to detect executable files, so again. Nothing fileless there either.

From the provided hash list for the test, all the malware that I pulled through a random spot check was executables which Webroot has no problem detecting.

 

[ForgottenSeer 123960]

Trident, the evidence you introduced regarding the hash spot check significantly shifts the technical interpretation of these results. If the underlying dataset verified via your random check consists primarily of compiled executables and DLLs, then the high detection score is almost certainly attributable to the engine catching the "payload" (the dropped file), rather than a behavioral engine intercepting the "process" itself.

Your screenshot of the internal Process Monitor effectively demonstrates the visibility gap you described. If high-prevalence system binaries are treated with a default "Allow" posture without the granular journaling applied to "Unknown" files, then the solution is relying on blocking the module loaded by the binary, not monitoring the behavior of the binary itself. This supports your assertion that the "abused LOLBins" statistics in the report are likely derived from post-execution analysis or sandbox telemetry, rather than representing active termination of those system processes by the endpoint agent.

This distinction is critical, stopping a `rundll32` attack by flagging the malicious `.dll` it attempts to load is a valid stop, but as you pointed out, it is not the same as monitoring `rundll32.exe` for anomalous memory injection or command lines. It appears the test methodology terminology conflated "attacks that utilized LOLBins" with "attacks stopped via LOLBin monitoring."

Based on the hash list you verified, the "fileless" component of this specific test appears to be overstated.

 

[Trident]

Trident, the evidence you introduced regarding the hash spot check significantly shifts the technical interpretation of these results. If the underlying dataset verified via your random check consists primarily of compiled executables and DLLs, then the high detection score is almost certainly attributable to the engine catching the "payload" (the dropped file), rather than a behavioral engine intercepting the "process" itself.

Your screenshot of the internal Process Monitor effectively demonstrates the visibility gap you described. If high-prevalence system binaries are treated with a default "Allow" posture without the granular journaling applied to "Unknown" files, then the solution is relying on blocking the module loaded by the binary, not monitoring the behavior of the binary itself. This supports your assertion that the "abused LOLBins" statistics in the report are likely derived from post-execution analysis or sandbox telemetry, rather than representing active termination of those system processes by the endpoint agent.

This distinction is critical, stopping a `rundll32` attack by flagging the malicious `.dll` it attempts to load is a valid stop, but as you pointed out, it is not the same as monitoring `rundll32.exe` for anomalous memory injection or command lines. It appears the test methodology terminology conflated "attacks that utilized LOLBins" with "attacks stopped via LOLBin monitoring."

Based on the hash list you verified, the "fileless" component of this specific test appears to be overstated.

When I tested the Evasion Shield (if I remember correctly that was the one, there are many solutions with many different names so it’s difficult to always remember), the few detections it produced were based on very obvious factors like heavy obfuscation. There was no evidence of any parent-to-child or command line analysis or any blocks based on suspicious behaviour.

It managed to block 2-3 scripts based on what looks like pre-execution heuristics which for some reason are only applied in the post execution phase.

However when dropping/downloading of executables on disk is involved (which is not uncommon for scripts), Webroot effectively detects these. For fully memory based attacks, Webroot is not equipped to stop these.

The Webroot protection method by default (without a user applying a dozen of tweaks) is slightly flawed, any interpreter or runtime is allowed to work without monitoring and journallimg, whilst the underlying files (.jar, .ps1, .whatever) are not even scanned, as the scan engine only supports a few executable formats (exe, dll, com and so on).

 

[ForgottenSeer 123960]

When I tested the Evasion Shield (if I remember correctly that was the one, there are many solutions with many different names so it’s difficult to always remember), the few detections it produced were based on very obvious factors like heavy obfuscation. There was no evidence of any parent-to-child or command line analysis or any blocks based on suspicious behaviour.

It managed to block 2-3 scripts based on what looks like pre-execution heuristics which for some reason are only applied in the post execution phase.

However when dropping/downloading of executables on disk is involved (which is not uncommon for scripts), Webroot effectively detects these. For fully memory based attacks, Webroot is not equipped to stop these.

The Webroot protection method by default (without a user applying a dozen of tweaks) is slightly flawed, any interpreter or runtime is allowed to work without monitoring and journallimg, whilst the underlying files (.jar, .ps1, .whatever) are not even scanned, as the scan engine only supports a few executable formats (exe, dll, com and so on).

Your explanation of the "Evasion Shield" mechanics and the specific gap regarding memory-resident threats effectively resolves the discrepancy between the high test scores and the architectural limitations you have highlighted. If the detection logic for scripts is primarily driven by static heuristics looking for attributes like "heavy obfuscation" rather than dynamic behavioral monitoring of the parent-child relationship, then the engine is essentially treating the script as a static object to be scanned rather than an active process chain to be monitored.

This distinction deconstructs the narrative presented in the test report. If the solution's default configuration allows interpreters and runtimes to operate without journaling, and explicitly limits scanning to specific executable formats like .exe, .dll, and .com while ignoring underlying source files like .ps1 or .jar, then the "100% detection" score cited in the assessment almost certainly relied on the attack chain eventually dropping a recognizable payload to disk. You have made a compelling case that the test measured the efficacy of traditional payload detection rather than the interruption of a truly fileless, memory-based kill chain.

It appears we have reached a technical consensus, the test results are likely accurate regarding the detection of dropped artifacts, but the report's terminology regarding protection against "fileless" and "living off the cloud" threats is misleading given the default lack of behavioral monitoring for those specific runtime environments. This insight regarding the lack of journaling for interpreters is the critical piece of context that was missing from the initial analysis.

 

[Halp2001]

I want to thank the users who share their knowledge in such a detailed and respectful way. For those of us without much technical experience, reading a clear and well‑reasoned discussion like this helps us better understand how the tests work and the differences between security solutions. Even though the explanations are quite technical, they give me a clearer idea of security and help me understand how these tests actually work. Especially thanks to @Trident and @Divergent .

 

[Khushal]

Well they test with what is prevalent.

Please note that Webroot detection of >40% post-launch is not an evidence that Webroot has some super efficient behavioural blocking.

Most likely the Webroot emulation and unpacking abilities (ahead with other algorithms) are not so proactive. Once malware is launched it would unpack itself and then Webroot will use the standard mixture of age, prevalence and other reputation (very similar to Norton) to detect the executable.

The Webroot detection on executables can be tweaked. It can go full blown default deny.

It's okay; nice of you providing us with such valuable scenarios.

Another ACR Mshta Victim I talked with it. He said both windows defender and MRT failed to detect it.

 

[Parkinsond]

Another ACR Mshta Victim I talked with it. He said both windows defender and MRT failed to detect it.
View attachment 293706

View attachment 293709

Uploaded to VT?

 

[Khushal]

Uploaded to VT?

dodi site is serving many downloads. Not sure which one is malicious and files are of very large size.

 

[Khushal]

Uploaded to VT?

He is himself not 100% sure from where he got the malware. So it is bit of a rabbit hole.

 

[Parkinsond]

dodi site is serving many downloads. Not sure which one is malicious and files are of very large size.

Just curious to know which AV engines were able to detect after failure of MD.

 

[Parkinsond]

View attachment 293710
He is himself not 100% sure from where he got the malware. So it is bit of a rabbit hole.

Wouldn't WHHL stop its malicious process?

 

[SeriousHoax]

dodi site is serving many downloads. Not sure which one is malicious and files are of very large size.

Dodi repack's games doesn't have any malware per se. But when a user clicks one of the download links which then opens another site where there are often multiple download button and redirects which could lead to downloading malware instead of downloading the actual game. It happens mainly to users who doesn't use an adblocker or using some other adblockers excluding using uBO and AdGuard. It's possible even uBO or AdGuard may not detect some of those fake download button or redirects from time to time.

 

[ForgottenSeer 114717]

Thanks for sharing your highly intelligent and elusive thoughts in this thread worth at least 3750 dollars considering the number of posts you committed in educating us.

I am not a teacher nor do I do anything for free. That is not even the primary purpose of MT.

 

[ForgottenSeer 114717]

And why is this by design? TIA

To accommodate "Users that want to use stuff."

F-SECURE has never prioritized malicious scripts, LNK, and other types of files for detection.

 

[stonjean633]

I am not a teacher nor do I do anything for free. That is not even the primary purpose of MT.

I hear you.
I remember Heath Ledger saying: If you're good at something, never do it for free.

 

[Trident]

To accommodate "Users that want to use stuff."

F-SECURE has never prioritized malicious scripts, LNK, and other types of files for detection.

F-Secure will hardly prioritise anything because they've got near zero control over the SDKs. There is the option for Avira to tailor it to the F-Secure needs and specifications but this is gonna come with fees, from consultation to building to ongoing support.

Avira in terms of scripts detection is not a disaster, it can certainly compete with the rest of the industry, however it is not known what set-up F-Secure has chosen for the Avira engines.

There is certainly some detection of fileless malware and more advanced attacks.