Andy Ful

Level 49
Verified
Trusted
Content Creator
SUMMARY of WD offline non-signature detection/blocking on Windows Home and Pro.
  1. WD offline non-signature detection uses Machine Learning models, behavior-based algorithms, generics (based on similarities to known malware), and heuristics.
  2. AMSI is used to log/detect unobfuscated script actions.
  3. Most of these features apply to images in memory and are optimized to detect suspicious behavior and trigger the cloud backend.
  4. WD can be configured to use also ASR rules and Controlled Folder Access to block locally, malicious behaviors.
It seems that WD main offline protection is based on malware signatures, and can be extended by using ASR rules and Controlled Folder Access. Other features are mostly the interlude to the cloud backend.
Of course, in the home environment, offline protection is supported by cloud protection even when the user is offline! The main malware delivery is due to the Internet, so if the user is well protected online (web protection, BAFS, etc.), then there is usually no malware on disk when being offline. This may work well for many users, but there are some exceptions, for example when downloading/unpacking files without MOTW (like from USB drives, via 7-ZIP unpacker, etc.).
The WD offline/online detection (without BAFS and without proactive features, default settings applied) was tested in AV-Comparatives Malware Protection tests. The test-set used contained 10970 recent/prevalent samples from the last few weeks. So, this test was very different from Zero-Day Protection tests on Malware Hub (not comparable). The results here, are from the latest test:
WD Offline detection rate: 68.5%
WD Online detection rate: 88.3%

The results of detection based on signatures are significantly lower as compared to other AVs. The above results are related to on-access (on-demand) scans without executing the samples. Samples were scanned from USB and network drives (no BAFS).

The comparison with other AVs:
MalwareTesst2019.png


When the samples were executed while online (no BAFS but triggered proactive features), then the result was:
WD Online Protection rate: 99.98% which was similar to other AVs.

Edit.
I would not take seriously the small differences among AVs in Online Protection Rate column. One could probably get the opposite scoring when choosing another pule containing 10970 samples from millions of in-the-wild samples.
 

Attachments

Last edited:

matrixlord

Level 1
Finally i found way to fully clear protection history (detected malwares&risky action&protected folder)

Start CMD from Troubleshoot and type;

Code:
del "C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\*"
del "C:\ProgramData\Microsoft\Windows Defender\Scans\mpenginedb.db"
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
Finally i found way to fully clear protection history (detected malwares&risky action&protected folder)

Start CMD from Troubleshoot and type;

Code:
del "C:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\*"
del "C:\ProgramData\Microsoft\Windows Defender\Scans\mpenginedb.db"
This can be also done manually by using Defender Control tool to disable WD temporarily, delete entries, and enabling WD again.
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
Your method has to be commented on because it will not work in many cases. The problem is that the disk C: which normally includes the Windows folder, usually will not be the disk C: when you will start the computer from CMD shell. That can depend on how the partitions were made on the drive. So, the user has to find the proper disk first (for me it was E: ), and next apply the commands (I assume that the right disk was E: ):
Code:
del "E:\ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\*"
del "E:\ProgramData\Microsoft\Windows Defender\Scans\mpenginedb.db"
That is why I proposed to use the Defender Control tool, because then deleting the above entries can be done from Windows without starting the computer from CMD shell.:giggle:(y)
 
Last edited:

Rijndael

Level 1
So, the user has to find the proper disk first (for me it was E: ), and next apply the commands (I assume that the right disk was E: )
You don't have to, you can use %PROGRAMDATA% environment variable:
Code:
del "%PROGRAMDATA%\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\*"
del "%PROGRAMDATA%\Microsoft\Windows Defender\Scans\mpenginedb.db"
 

Andy Ful

Level 49
Verified
Trusted
Content Creator
You don't have to, you can use %PROGRAMDATA% environment variable:
Code:
del "%PROGRAMDATA%\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory\*"
del "%PROGRAMDATA%\Microsoft\Windows Defender\Scans\mpenginedb.db"
No, you cannot. CMD shell uses a different system. In my case, this system is run from the X: volume. When I run the command:
echo %ProgramData%
then the result is:
X:\ProgramData
The correct result should be in my case:
E:\ProgramData

Post edited.
The X: is usually not a partition, but is loaded & mounted in the memory.
 
Last edited:

Rijndael

Level 1
No, you cannot. CMD shell uses a different system. In my case, this system is run from the X: partition. When I run the command:
echo %ProgramData%
then the result is:
X:\ProgramData
The correct result should be in my case:
E:\ProgramData
jeje My fault I didn't notice you were talking about "troubleshoot". %PROGRAMDATA% not work beause OS is not running so CMD cant access to this variable.
 
Last edited:

Andy Ful

Level 49
Verified
Trusted
Content Creator
jeje My fault I didn't notice you were talking about "troubleshoot". I think that %PROGRAMDATA% not work beause OS is not running so CMD cant access to this variable.
I understand what you mean, but some things require clarification.
The OS is running and can recognize the variable %ProgramData% (in my case the value is X:\ProgramData). But, this is a different OS from the OS which is started normally. That is why it is so useful, because if the normal OS is infected, then one can use Troubleshoot option and run the second (uninfected) OS from CMD shell.
 
Last edited:

Rijndael

Level 1
I understand what you mean, but some things have to be clarified. The OS is running and can recognize the variable %ProgramData% (in my case the value is X:\ProgramData). But, this is a different OS from the OS which is started normally. That is why it is so useful, because if the normal OS is infected, then one can use Troubleshoot option and run the second (uninfected) OS.
Yes you're right:
 
Last edited:

Pat MacKnife

Level 8
Verified
The WD offline/online detection (without BAFS and without proactive features, default settings applied) was tested in AV-Comparatives Malware Protection tests. The test-set used contained 10970 recent/prevalent samples from the last few weeks. So, this test was very different from Zero-Day Protection tests on Malware Hub (not comparable). The results here, are from the latest test:
WD Offline detection rate: 68.5%
WD Online detection rate: 88.3%

The results of detection based on signatures are significantly lower as compared to other AVs. The above results are related to on-access (on-demand) scans without executing the samples. Samples were scanned from USB and network drives (no BAFS).

The comparison with other AVs:
View attachment 226733

When the samples were executed while online (no BAFS but triggered proactive features), then the result was:
WD Online Protection rate: 99.98% which was similar to other AVs.

Edit.
I would not take seriously the small differences among AVs in Online Protection Rate column. One could probably get the opposite scoring when choosing another pule containing 10970 samples from millions of in-the-wild samples.
A new malware-protection-test is online :

Microsoft29.7%76.3%99.96%