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
Xvirus Personal Guard
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.
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:
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. Getting a third opinion on Virustotal shows that 41 out of 65 their engines flag it as malicious too - you can see the result
here on virustotal
. 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.
Click the image to watch the video
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.
Click the image to watch the video
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.
- 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:
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. To do this, using the
VirusTotal link is a good idea, since this is a good second opinion about the file. 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:
If you have questions not answered on this page, please contact us using the chat or the contact menu at the top.