Executive Summary
There is a remote code execution attack vector within BGInfo. A clever attacker can embed a path to a malicious script within a BGInfo config file (.bgi). If they can convince a user to click on the config file, it will load the malicious script from a remote location and run it in memory on the victim’s machine.
In our proof of concept, none of the major mail providers we tested blocked our malicious .bgi file attachment.
What is BGInfo?
BGInfo is a tool that is part of Sysinternals. It allows you to display the machine’s configuration info on the desktop wallpaper. Hospitals, schools, and large enterprises with lots of endpoints often use BGInfo to make it easy for sysadmins to see details like IP address, OS version, and hostname when they log in:
How can you exploit BGInfo?
The OS will automatically associate the BGInfo application with the .bgi extension when it’s first executed. Any .bgi files that a user double clicks will automatically run using the BGInfo executable without prompting the user.
Researchers have already shown that BGInfo can run script files from a remote location. A great example is this article on bypassing application whitelisting with BGInfo.
What we’ll show you here is how BGInfo can be an excellent way for an attacker to avoid detection by anti-phishing and anti-virus.
Get the Free Pentesting Active
Directory Environments E-Book
The attack flow we’re going to show here is unique because infected .bgi files, to our knowledge, haven’t been demonstrated as a weapon for initial infection, bypassing email security and anti-phishing detections.
The Attack Flow
1.) The attacker creates a malicious .bgi file with a User Defined Field containing a path to a remote .vbs script. In our case, the script is stored on a remote file share, but it could be stored in the cloud as well:
2.) The attacker sends a phishing email to the victim with the attached .bgi file. Because the .bgi extension is not (yet) considered dangerous, all the mail providers we tested allowed our victim to receive and download the file without any warnings.
3.) The victim, who has already run a .bgi file in the past, clicks on the .bgi file triggering it to run.
4.) The config file connects to the SMB share controlled by the attacker and runs the malicious .vbs script in memory.
Note: if an organization stores its default .bgi file on a network share, an attacker can replace it with their infected version and quickly infect many computers on the network.
Here’s a quick video we recorded to demonstrate the proof-of-concept. Notice how the .bgi file is not flagged by Gmail and it runs the .bgi on the user’s machine without any warnings. We simply had our VBScript launch calc.exe, but an attacker could do a lot worse!
What can the VBS script do?
Once an attacker can run arbitrary code on a victim machine, the possibilities are endless. We’ve seen attackers use the initial .vbs as a dropper to download bigger payloads such as Maze ransomware, Cobalt Strike, Mimikatz, etc.
What happens from this point depends on the attacker’s intentions:
- Hunt for data on the victim machine
- Establish a covert C2 channel via DNS
- Try to move laterally to other machines on the network
- Plant persistent backdoors in the system’s registry or task scheduler
For a deeper look at how attackers behave post-intrusion, check out our live cyber attack workshops.
Mitigations
- Update your mail server’s whitelist to prevent unknown file attachment types
- Update your endpoint detection and email security tools to block or quarantine .bgi attachments
- Update your firewall to block access to remote SMB file shares
It’s also important to have a layered defense. This article describes a threat related to BGInfo, but tomorrow there will be a new method to infiltrate a network, escalate privileges and ultimately steal data (see: Zerologon).
Varonis takes a data-centric approach to cybersecurity. If you’re watching what’s happening with your data, it’s harder for attackers to hide. We combine a unique set of ingredients detect threats at all stages of the kill chain such as suspicious data access, abnormal logon attempts, and DNS exfiltration.
If you’d like to see the Varonis Data Security Platform in action, simply request a demo here.
Report timeline
- 2020-11-05: First report sent to Microsoft via MSRC
- 2020-14-05: Added POC to the report; case opened
- 2020-11-06: Asked Microsoft for a 30-day status update
- 2020-12-07: Asked Microsoft for a 60-day status update; Microsoft listed the report as “Moderate”
- 2020-11-08: 90-day vulnerability disclosure
