A new phishing campaign is impersonating Bank of America in an attempt to trick Windows users into installing a legitimate remote access tool that has been repurposed for malicious activity. The campaign uses an email designed to create a sense of urgency, warning recipients that they must take action to avoid account restrictions. If the recipient follows the embedded link, they are taken to a page that closely resembles the bank's login portal. Depending on the operating system in use, the fake page either attempts to harvest credentials or pushes a malicious installer disguised as a security tool.
Security researchers who analyzed the campaign found that the attack chain is unusually elaborate for a typical phishing operation. The final payload is a customized ScreenConnect remote monitoring and management client, a tool that is widely used by IT teams for legitimate remote support. Once installed, the client allows the attacker to connect to the victim's computer and perform almost any action, including stealing files, capturing keystrokes, and moving laterally across a network. What sets this campaign apart is the effort the attackers put into hiding the software and preventing the victim from removing it.
Phishing lure and device-specific paths
The phishing email is made to look like a legitimate Bank of America notification. It spoofs the bank's alert system and tells recipients that they must verify or update their account information to avoid restrictions. The message urges immediate action, a common tactic used to bypass rational decision-making. Victims who click the link are sent through a device detection process that determines whether they are using a Mac or a Windows computer.
For Mac users, the redirection leads to a convincing lookalike bank login page. The page asks for a username and password and then requests additional personal and financial information. This data is likely collected and sold or used in follow-up fraud schemes. The Mac path does not appear to involve a software download, suggesting the attackers are interested mainly in credential harvesting from that group.
Windows users encounter a different page. The fake page informs them that their information needs to be updated and presents a button labeled “Update My Information.” Clicking the button triggers the download of a ZIP archive. Inside the archive is a Visual Basic Script file named AccountGuardSetup.vbs. If the user extracts the archive and runs the script, the infection chain begins. The software masquerades as “Account Guard,” a name that sounds like a banking security product, which may lower the user's suspicion.
A closer look at the malicious installation chain
The Visual Basic script is heavily obfuscated. It contains an unusual amount of base64-encoded data blobs, and every stage of the attack relies on a script that contains more of these encoded blobs. The obfuscation makes static analysis difficult, but researchers were able to decode the blobs and map out the complete infection sequence.
The attack begins with a delay, which may be intended to evade sandbox detection and automated analysis. After the delay, multiple PowerShell scripts run in succession, with each script calling the next one. The final PowerShell script downloads an encoded MSI file from a file-sharing service. It decodes the MSI file and writes it to the local application data folder under a Microsoft subfolder, a location that is commonly used by legitimate software and therefore less likely to arouse suspicion.
Once the MSI file is in place, the script decodes two additional data blobs embedded within itself. The first blob contains a public user account control bypass exploit. This exploit allows the attacker to install the ScreenConnect MSI file with administrator privileges without triggering a user prompt. The attack does not require the user to approve a UAC elevation dialog, which normally provides a warning that a program is trying to make changes to the system.
After the MSI installation is complete, ScreenConnect registers itself as a Windows service. The service is given a misleading name: “Windows Security.” This name is designed to blend in with legitimate Windows services and to trick users who may open the Services console into thinking the service is part of the operating system.
Making the foothold persistent and untouchable
Most remote access malware is removed by simply uninstalling the application or deleting its files. The attackers behind this campaign anticipated that response and went to great lengths to make removal difficult. The second AES-encrypted blob decodes into a VBScript that performs several destructive actions.
First, the script deletes the Registry key that points to the ScreenConnect installer. This means the software will not appear in the standard “Programs and Features” list, and it cannot be uninstalled through normal Windows settings. Second, the script modifies the Windows Service Descriptor Definition Language, or SDDL, for the service. SDDL is used to define access control lists for Windows objects, including services. The modified SDDL prevents the current user and even local administrators from changing the service configuration or terminating the process.
The script also uses access control lists to block the user from making changes to the computer and to hide the ScreenConnect process from standard process viewers. Even if a savvy user knows that the malicious software is present, they may find it impossible to stop or delete the service using conventional tools. The parent PowerShell script then deletes itself and the script blobs, removing most forensic traces of the infection chain from disk. This leaves the victim with a hidden, protected remote access client that can be used by the attacker at will.
Why cleanup is difficult
Security analysts who investigated the campaign found that common tools such as services.msc, Get-Service, and sc.exe query will not list the hidden “Windows Security” service. This is a significant obstacle for average users and even for IT help desk teams who are not familiar with advanced Windows internals. The ScreenConnect process is concealed, the service is protected by ACLs, and the uninstaller is gone. Without specialized tools that can repair service DACLs or remove the service manually, the infected machine may remain compromised indefinitely.
The command-and-control infrastructure behind the campaign adds another layer of concern. The IP address used by the attacker geolocates to the United Arab Emirates and has a poor reputation because several other malware families appear to use the same address for command and control. This suggests that the threat actor may be reusing infrastructure or that a single hosting provider is serving multiple criminal operations.
The phishing email was received by a honeytrap account, which is an account set up specifically to attract malicious emails. This indicates that the attackers are spraying the campaign broadly rather than targeting specific individuals or organizations. The use of multiple device-specific paths also suggests a mass-audience strategy. While the main payload targets Windows users, Mac users are still funneled into a credential harvesting page, allowing the attackers to monetize a wider range of victims.
How users and organizations can defend against this campaign
Users can protect themselves by carefully inspecting the sender's email address before clicking any links. Bank notifications that contain urgent language about account restrictions should be treated with suspicion, especially when they ask the recipient to download software or enter sensitive information. A legitimate bank will never ask a customer to download an attachment or a program to resolve an account issue.
It is also important to verify the URL in the browser's address bar before logging in to any online banking portal. Phishing pages often use domains that are visually similar to the real institution but contain extra characters, misspellings, or unusual top-level domains. In this campaign, the fake Bank of America pages were hosted on domains that had no obvious relation to the real bank. Hovering over a link before clicking it, or copying and pasting the URL into a notepad for inspection, can help users spot these clues.
For organizations, the presence of ScreenConnect or similar remote access tools should be monitored carefully. Security teams should maintain a list of approved remote support tools and alert on the installation of unapproved RMM clients. Endpoint detection and response products can be configured to flag suspicious Visual Basic Scripts, PowerShell execution chains, and MSI installations launched from temporary or local application data folders.
Another layer of defense is to restrict PowerShell execution policy on user endpoints and to require signed scripts for any administrative tasks. Limiting the ability of standard users to install MSI packages or to modify Windows services can also reduce the impact of this type of attack. The UAC bypass used in this campaign highlights the importance of keeping systems patched, though public exploits of this kind can sometimes bypass patched systems. Therefore, application control and behavioral monitoring are essential.
If a user suspects they have been infected, they should disconnect the computer from the network immediately and contact their organization's security team or a trusted IT professional. Because the ScreenConnect service is hidden and protected by access control lists, standard removal is not likely to work. In severe cases, the operating system may need to be restored from a known-good backup or completely reinstalled to ensure the attacker no longer has access. Changing banking credentials and other sensitive passwords should be done from a separate, trusted device.
As remote support tools become more common in both legitimate IT operations and criminal campaigns, users must recognize that a request to install software from an email is a red flag. The combination of social engineering, legal remote access software, and malicious access control manipulation makes this campaign particularly dangerous. By staying alert and verifying every unexpected request, users can prevent the initial compromise and avoid the painful cleanup that follows.
Source: Help Net Security News