Malware Detection

When a user requests to run a file with administrative privileges, the file can be scanned in real-time to block malware using 20+ anti-virus engines. This happens without any performance or waiting penalty and it doesn’t conflict with any security software you may have on your endpoints, because it happens in the cloud. If the file is flagged as malicious, it is blocked before it can do any damage. If you think your endpoint anti-virus product is sufficient … watch the video further down.

Real-time detection

Admin By Request takes away users’ admin rights, but allows users to run some applications with administrative privileges. When a user requests to run a file, malware checks are performed using 20+ anti-virus engines before it is executed. The engines we currently use are:

 CrowdStrike Falcon ML

 BitDefender

 McAfee

 Kaspersky

 Windows Defender

 AegisLab

 Ahnlab

 Avira

 ClamAV

 Comodo

 Cyren

 Emsisoft

 Ikarus

 K7

 NANOAV

 Quick Heal

 TACHYON

 Vir.IT eXplorer

 Vir.IT ML

 Webroot SMD

 Xvirus Anti-Malware

 Xvirus Personal Guard

 Zillya!

If a file is flagged as malicious, execution is blocked in real-time on the endpoint before it runs with administrative privileges and does the damage. In many cases, malicious files will be caught by your endpoint anti-virus product, but as everyone knows – no single anti-virus product is perfect and if it doesn’t catch it, the result is disastrous. If a program passes through all engines without any flags raised, you can reasonably assume that the file is not malicious and is safe to run.

Background

The ability to scan and detect malware is technically a transparent integration between the Admin By Request cloud service and our partner OPSWAT’s MetaDefender cloud service. You can read about the strategic partnership between Admin By Request and OPSWAT here.

OPSWAT is a front-runner in the cloud threat protection space and is used by 98% of U.S. nuclear power facilities and this technology is also integrated into Cisco products. The list of engines will increase over time as OPSWAT signs more vendors. This blog OPSWAT explains the integration in greater detail:

 

OPSWAT Blog: Admin by Request and MetaDefender Cloud

This external blog from www.opswat.com talks about the integration between Admin By Request and OPSWAT’s MetaDefender

Real-world case

Malware is often hidden in “too good to be true” freebies, such as free PDF generators, ISO tools or cleaner tools. Let’s take a realworld example shown in the video. Your user forgot the password for an Outlook PST file and Googles a free tool for this one-time problem. Your user tries to install a PST password recovery tool and luckily this is caught by Admin By Request. The file passed Windows Defender on the endpoint, but was luckily caught by MetaDefender. Have a look at the video to see how shockingly fast (1 minute) it is to get malware.

Knowing that you are running the file against so many engines means that you can reasonably be assured that files your users run with administrative privileges are not malicious. With this insurance in mind, it is not necessary to enable approval for every request from end users, unless you have other reasons to do so. You can also set up an email notification to yourself in your portal settings, when malware is blocked.

Malware blocking in Admin Sessions

If you allow Admin Sessions for expert users, the malware checks are also performed, when users use Run As Administrator in the session. This is transparent to the end user (no splash screen), simply because it so fast that the splash screen would just be a quick flicker.

If we run the same scenario in an Admin Session running the same PST password recovery setup file, not only is it still blocked, but it also kills off the entire session right away, as shown in the video, and your email notification will notify you.

How it works

How is it possible that this can magically be done without any performance or time penalty for the end user? When a user attempts to run a file with administrative privileges using Run As Administrator, an API call is made from the endpoint to our backend servers. This call includes the SHA256 checksum of the file the user intends to run. At this time, the file is not executed yet. A checksum is an industry-standard way to uniquely identify a file by making a hash of the binary content of the file. This means you cannot rebuild the original file, but you get a world-unique identification of the file. If the checksum of the file is known by MetaDefender and is flagged as malicious, the endpoint gets the message back to block the file and stop the process. You will see an entry in the auditlog that the file was blocked, and which engine(s) flagged it. This checksum lookup takes less than 0.1 second, because the file itself is not scanned – the checksum is simply looked up in a MetaDefender central database of current scan results across all their customers in the world. This means there is no time penalty for your end user at all, no matter how many engines there may be in the future.

Cloud file scanning

MetaDefender has about 10 billion records of scan results from checksums of files. Statistically, about 75% of checksum of files are known. But the more common a file is, the more likely it is to be known. If a checksum falls into the unknown 25%, you can opt to run a real-time cloud scan of the files. If you use this setting, the splash screen on the endpoint will change to look like this after a few seconds and the user has to wait for a MetaDefender cloud file scan:

What happens is that the actual file is sent to the MetaDefender cloud service for real-time scanning using all the engines listed above. The upload time depends on the file size and bandwidth on the endpoint, but the scanning itself typically takes less than 10 seconds. If the file is flagged, the execution is blocked. Please note that:

• The file never resides or passes the Admin By Request cloud service in any form; the file goes directly to MetaDefender.
• MetaDefender does not store your file. It exists only as long as the file is scanned. Please refer to MetaDefender Cloud Privacy Policy for more information.
• Once the file has been uploaded once, the checksum is known and it will not be scanned again until if falls under aging of 7 days.
• If anyone else in the world uploads the same file before aging, the result is updated and aging is reset.

The option to upload unknown files to MetaDefender is the “Cloud scan unknown files” option in your settings:

If you uncheck “Cloud scan unknown files” but leave “Real-time detection” on, only checksum lookup for the known 75% is performed and the rest must be handled by your local endpoint anti-virus product. It is not recommended to ever disable the “Real-time detection” option, simply because there is no drawback of having it. The extra wait time for the end user is a tenth of a second. We can sum of the flow like this:

Auditlog

If a file is flagged as malicious, what happens depends on your “Action” setting. If you set Action to “Quarantine”, the file will be blocked and put into the “Quarantined” tab under “Requests” in the top menu. This allows IT staff to look at the reported data and make the judgment, if this file should be allowed or not. If you set “Action” to “Permanently block”, the file cannot be approved to run at all. In the Auditlog, you will see the request with status being “Quarantine” or “Blocked”:

If you click the MefaDefender link in the details, you will see a page like the one below. In the “Settings” menu you can also select “Detected Malware” to get an overview of all files ever detected across the entire Auditlog.

Handling false positives

It is commonly known that anti-virus engines sometimes report false positives. When the file is scanned with so many engines, the likelihood of this happening increases, especially when using AI based engines like CrowdStrike. The way we handle this is by applying this simple ruleset:

• The file is flagged if one of the major engines using classic pattern recognition flags it (for example BitDefender or McAfee)
• The file is flagged if more than one engine flag it

Testing without using malicious files

To test how the flow works and to verify your settings work as you expect, you need to be able to simulate a malware situation without using a malicious file. An industry standard file called Eicar exists, but it will most likely be blocked by your local anti-virus program. Therefore, you can create an Admin By Request simulation file. A simulation file is an XML file with the extension .abrsim. You can double-click an .abrsim file on an endpoint with the version 6.3 or newer client and it will process the file as if it was the file with this checksum, but will not execute anything. The backend will behave exactly the same as if it was real file, which allows you to test the entire flow.

You can download some simulation files that we have created by clicking the button below. What is interesting about these simulation files is that these files are checksums that are collected from real customers. These files have all passed the local endpoint anti-virus solution (!!), but was blocked in real-time by one or more of the other engines. These files appeared to be common files like WinRAR, PowerISO, Messenger, Media Player, PDF Creater, Cleaner tools and so forth.

DOWNLOAD ABRSIM FILES
You can also create an .abrsim file yourself based on a checksum you wish to try:

Questions?

If you have questions not answered on this page, please contact us using the chat or the contact menu at the top.