Question about Web Protection

[0xDEADBEEF 43]

Does ESET web protection/realtime scan malware inside an archive (e.g. zip)? The reason I am asking this is because in most cases the zip containing malware (no password) I downloaded doesn't trigger any detection from ESET until I unzip it. These archives are small (<512KB). However, for the eicar test zip file ESET will detect it immediately. This is a bit confusing.

I tried both on Edge and Chrome, and the results are the same.

[Marcos 5,071]

Web protection scans archives utilizing more sensitive detections while real-time protection doesn't scan archives at all with the exception of certain sfx archives or installers. If you come across an undetected archive, send it to me via a personal message please.

[zamar27 5]

For extra precaution, always check questionable origin archives with VirusTotal, but make sure beforehand they're not encrypted, including archive parts, thus making virus detection impossible. Though not all detected files by any A/V are in fact malicious.

Edited May 10, 2019 by zamar27

[itman 1,659]

2 hours ago, 0xDEADBEEF said:

Does ESET web protection/realtime scan malware inside an archive (e.g. zip)?

Yes, it indeed does. You can use this web site to verify Eset's downloaded archive scanning: https://www.amtso.org/feature-settings-check-download-of-compressed-malware/ . It will/should detect every download prior to hitting your disk. However, the AMTSO archived payload is the EICAR file.

FortiGuard likewise has a similar test here: http://metal.fortiguard.com/ . Eset scores 17/18 on this test only failing the password protected archive test. Again and unfortunately, the test payload is EICAR.

By any chance are the malware files in the archive packed, compressed, or obfuscated? Eset's web scanner might not be able to detect those until they fully "decloak" which might only occur after disk file creation and extraction from same.

[itman 1,659]

2 hours ago, Marcos said:

while real-time protection doesn't scan archives at all with the exception of certain sfx archives or installers.

I assume this is because SmartScan default Is not set to scan archives? Setting SmartScan to do so I assume would then scan all archive types?

[Marcos 5,071]

3 minutes ago, itman said:

I assume this is because SmartScan default Is not set to scan archives? Setting SmartScan to do so I assume would then scan all archive types?

"Smart scan" is an on-demand scan profile. Real-time protection has nothing to do with it. Looking at profile settings, Smart scan has scanning of archives and SFX archives enabled by default.

[itman 1,659]

1 minute ago, Marcos said:

"Smart scan" is an on-demand scan profile. Real-time protection has nothing to do with it.

True. But being the default scan profile, it would be deployed in Eset's startup and module update event scans. The question is if the User Download directory is scanned by those?

[Marcos 5,071]

Smart scan scans all local disks completely, not just specific folders.

[itman 1,659]

9 minutes ago, Marcos said:

Smart scan scans all local disks completely, not just specific folders.

Doublechecked startup and module update scan parameters. They only scan select files and areas. Looks like I have to ponder this disk archive scanning after file creation a bit.

[Marcos 5,071]

I was talking about Smart scan which is an on-demand scan profile:

[itman 1,659]

Thinking a bit more about this if packed, encrypted, or obfuscated malware exists in an archive, Eset or any other AV scanner is not going to be able to detect it until the archive is extracted. And if its a script, not until it is executed via AMSI examination. Which brings up the issue of those nasty bundled Python engine and script .exe's.

[zamar27 5]

Giving more examples, not a single modded Android apk was detectable regardless how malicious, they all have encrypted content, hopefully catched at run time. 😉

Broader speaking, the definition of "malicious action" is also at review. Yesterday's Windows MS Office updates led to constant OneNote crashes. Was it by design to push folks documents to MS cloud by forcing to upgrade to new OneNote app? Or unintended consequence of previous Reg changes not expected by the update?  One can say, the update IS a virus. 😋

Edited May 11, 2019 by zamar27

[0xDEADBEEF 43]

12 hours ago, Marcos said:

If you come across an undetected archive, send it to me via a personal message please.

After some more tests, I feel like this is website dependent. For the same archive that contains malware, downloading from dropbox is fine (ESET detects it), but downloading from firefox send doesn't work. 

My test results (On windows 10 1903 Edge + EES 7.1.2045)

                    Dropbox                Firefox Send

Eicar zip:     detected                 detected (after some delay)

malware zip:  detected             not detected

 

I've sent u the zip I used to test this through private msg

BTW, VPN plugin also affect this. For example my main browser is Chrome + surfshark VPN plugin. When the VPN plugin is enabled, the zip won't be detected. Disabling the plugin will have ESET detect it. I don't know if this is considered a bug...

The test I had on Edge is orthogonal to this though, it is a barebone Edge browser with no plugin

 

Edited May 11, 2019 by 0xDEADBEEF

[0xDEADBEEF 43]

12 hours ago, Marcos said:

scans archives utilizing more sensitive detections

does this mean web protection may detect something that on-demand scan cannot detect?

[Marcos 5,071]

7 minutes ago, 0xDEADBEEF said:

does this mean web protection may detect something that on-demand scan cannot detect?

Correct. Also web protection blocks known sites that distribute malware so even if there's a new unrecognized variant, the download would be blocked.

[0xDEADBEEF 43]

4 minutes ago, Marcos said:

Also web protection blocks known sites that distribute malware so even if there's a new unrecognized variant, the download would be blocked

For this kind of detection, will it be shown as some specific malware name? or it will just redirect the browser to the ESET warning page?

 

BTW, I am not a web dev pro, but I suspect the reason why ESET cannot detect firefox send is due to its HTML5-based download system (similar to mega.co.nz). I did the same test on mega.co.nz and ESET cannot detect it as expected.

Edited May 11, 2019 by 0xDEADBEEF

[Marcos 5,071]

It depends. When you click a link in a browser to download a malicious file, it looks like as follows:

[itman 1,659]

6 hours ago, 0xDEADBEEF said:

BTW, I am not a web dev pro, but I suspect the reason why ESET cannot detect firefox send is due to its HTML5-based download system (similar to mega.co.nz).

FireFox Send is new. My take on it is, it's basically an encrypted cloud file sharing service. Conceptually similar to how client e-mail file transfer works.

It may very well be that Eset SSL/TLS protocol scanning doesn't work with FireFox Send downloads from Chrome; I assume that was the browser you were using.

Personally, I wish Eset kept the network adapter mini-port filter driver approach for SSL/TLS scanning which would ensure everything downloaded is scanned.

Ref.: https://blog.mozilla.org/blog/2019/03/12/introducing-firefox-send-providing-free-file-transfers-while-keeping-your-personal-information-private/

Edited May 11, 2019 by itman

[itman 1,659]

Some more info on FireFox send:

Quote

Firefox Send allows for files up to 1GB to be sent to others via any web browser (2.5GB if you sign in with a Firefox account). The files are encrypted after a key is generated, at which point a URL is created containing said key. You send this URL to the recipient, who is able to then download and access the file securely. Mozilla can’t access the key, as the JavaScript code powering things only runs locally.

https://blog.malwarebytes.com/cybercrime/privacy/2019/03/mozilla-launches-firefox-send-for-private-file-sharing/

In other words, this is the same as sending/receiving encrypted e-mail via e-mail client. Eset SSL/TLS protocol scanning can't scan the encrypted FireFox send files because it has no access to the public key used to unencrypt the files.

Edited May 11, 2019 by itman

[0xDEADBEEF 43]

8 hours ago, itman said:

Eset SSL/TLS protocol scanning can't scan the encrypted FireFox send files because it has no access to the public key used to unencrypt the files.

if this is the case, it seems to be a security vulnerability that can bypass the web protection heuristics.

[0xDEADBEEF 43]

13 hours ago, Marcos said:

It depends. When you click a link in a browser to download a malicious file, it looks like as follows

Wondering if you have confirmed my observation. If so, is there a plan to fix it? (along with VPN plugin issue)

[itman 1,659]

13 hours ago, 0xDEADBEEF said:

if this is the case, it seems to be a security vulnerability that can bypass the web protection heuristics.

The situation with encrypted archive downloads is identical to that for password protected archives. With a strong algorithm used for encryption, it could take weeks to crack it.

What I want to know is how Fortiguard can inspect password protected archives which it indicates it can. They must have figured out a way to bypass that feature.

Finally, packed, encrypted, and obfuscated non-archive code downloads really aren't scanned until they are executed via heuristics. There is no known way to do the same with an encrypted archive file. It first has to be decrypted before the archive can be accessed. Also, determining a file's encryption status is far from straight forward: https://www.quora.com/How-can-one-tell-if-a-file-is-encrypted .

Edited May 12, 2019 by itman

[zamar27 5]

15 hours ago, 0xDEADBEEF said:

If so, is there a plan to fix it? (along with VPN plugin issue)

As to VPN plugin, it allows to encrypt browser traffic including file "downloads", so it all comes to the sequence, whether the traffic is decrypted by the plugin before Eset checks it.

Edited May 12, 2019 by zamar27

[0xDEADBEEF 43]

56 minutes ago, zamar27 said:

As to VPN plugin, it allows to encrypt browser traffic including file "downloads", so it all comes to the sequence, whether the traffic is decrypted by the plugin before Eset checks it.

It depends on where ESET intercepts the traffic. Essentially when the file is landed on the disk, it is not encrypted, so ESET will have a chance to inspect it using more aggressive heuristic. However I guess so far because this is handled by realtime monitoring and it doesn't scan archives by default, such more sensitive detection won't be activated.

The way ESET scans SSL traffic seems to be different from some other vendors (e.g. bitdefender). ESET will install its own CA to intercept the traffic (thus the https website in the browser shows ESET CA). I am not sure at this level will ESET be able to inspect the traffic. I guess it should because the data received is likely to be decrypted by VPN first and then decrypted by HTTPS, so inspecting at HTTPS will not be affected. Also I've heard other people saying ESET won't inspect archives downloaded by IDM or other download software.

Edited May 12, 2019 by 0xDEADBEEF

[zamar27 5]

Some VPN plugins do not encrypt https traffic at all, in contrast with VPN desktop apps, or encryption level is degraded. Generally, VPN purpose is not only encryption, but obfuscating traffic origin using other techniques.

Also, what is the purpose to inspect regular archives? They can be inspected at extract time to save resources. How would Eset differ an encrypted archive from not?