A series of phishing campaigns using fake Adobe Reader, Zoom, Microsoft Teams and Google Meet updates demonstrates how attackers increasingly combine familiar workplace brands, valid digital signatures and legitimate remote-management software to compromise enterprise systems. 

The campaigns directed users to fraudulent websites that closely resembled official software-download pages. Victims were told that Adobe Reader, Zoom or another workplace application was outdated and needed to be updated before they could open a document, attend a meeting or access business information.

The downloaded files appeared to be genuine application installers and used convincing names such as `adobereader.exe`, `zoomworkspace.clientsetup.exe`, `msteams.exe` and `invite.exe`. More significantly, the files were digitally signed using an Extended Validation certificate, giving Windows and users additional reasons to consider them trustworthy.

Once executed, however, the programs installed remote monitoring and management tools that provided attackers with persistent access to the affected computer.

The incident demonstrates why organizations can no longer rely on familiar branding, professional-looking websites or a valid digital signature as sufficient evidence that downloaded software is safe.

The campaigns used ordinary business activity as bait

The attackers used phishing messages designed around routine workplace activities, including meeting invitations, PDF documents, invoices, project proposals, financial communications and organizational notifications.

In one observed campaign, the victim received an email containing what appeared to be a restricted PDF document. Opening the attachment displayed a blurred image with a button marked “Open in Adobe,” encouraging the recipient to click to view the complete file.

Instead of opening a document, the button redirected the victim to a counterfeit Adobe download page. The page claimed that Adobe Acrobat Reader was outdated and automatically offered what appeared to be a legitimate update.

Other campaigns used fake Zoom, Microsoft Teams and Google Meet invitations. The victim was told that the meeting application required an update before the call or shared content could be accessed.

These lures are effective because they reflect normal business workflows. Employees routinely receive meeting invitations, invoices, shared documents and update notifications, making it difficult to reject every unexpected message without disrupting legitimate work.

The attackers also create time pressure. A user attempting to join a meeting or review an urgent document may be more likely to install an update quickly rather than verify its source.

This is particularly effective with video-conferencing lures because the victim may believe colleagues or customers are already waiting. The technical problem appears to require an immediate solution, and the offered update conveniently appears to provide one.

Software updates should therefore never be installed merely because a webpage encountered through an email or meeting invitation says that an application is outdated.

Digitally signed malware creates dangerous confidence

The malicious executables were signed using an Extended Validation certificate issued to TrustConnect Software PTY LTD.

A digital signature allows Windows and security tools to verify that a file was signed using a particular certificate and that the signed content has not been modified afterward. However, the signature does not prove that the software is safe, useful or being distributed for an authorized purpose.

Attackers can obtain certificates through fraudulent company registrations, compromised businesses, stolen signing keys or abuse of legitimate software-development processes.

When a malicious file carries a valid signature, users may see fewer warnings and assume that the software has been approved independently. Some security controls may also give signed applications more trust than unsigned binaries.

This makes certificate abuse particularly valuable for attackers. The malware does not need to defeat every security product technically when it can borrow the appearance of legitimacy from the software-signing ecosystem.

Organizations should therefore treat a valid signature as one security signal rather than a complete safety decision. The publisher, download source, expected business purpose, application behaviour and reputation must all be considered.

Security tools should also support the ability to block certificates or publishers associated with malicious activity. Once a signing certificate is confirmed as abused, organizations should be able to prevent files signed with it from executing across managed endpoints.

Remote-management software becomes the backdoor

The attackers did not depend entirely on custom malware. They deployed legitimate or repurposed remote monitoring and management tools, including ScreenConnect, Tactical RMM and MeshAgent.

RMM platforms are designed to allow administrators and support teams to connect remotely to computers, execute commands, transfer files, manage services and troubleshoot systems.

These capabilities are useful when deployed by an authorized IT team. The same features provide attackers with extensive control when the software is installed without the organization’s knowledge.

Using commercial or open-source RMM tools gives attackers several advantages. The applications are generally reliable, support encrypted communication and are designed to remain active across system restarts.

They may also be digitally signed and recognized as legitimate administrative tools, reducing the effectiveness of conventional malware detection.

Security products cannot simply classify every instance of ScreenConnect or another RMM product as malicious because many organizations use them lawfully. Detection must determine whether the specific installation is approved and whether its behaviour matches normal administrative activity.

An authorized RMM agent installed by the IT department and connected to the company’s management server may be legitimate. The same product installed from a phishing page and connected to an unfamiliar attacker-controlled instance represents a backdoor.

The name of the software alone cannot resolve that distinction.

The first executable established its own persistence

After the fake workplace application was launched from the Downloads directory, it created another copy of itself under `C:\Program Files`, helping it appear like an ordinary installed application.

The malware then registered the copied executable as a Windows service so that it could run automatically during system startup. It also created a registry Run entry that launched the program whenever Windows started.

In the Adobe-themed version, the executable was placed within a directory resembling an Adobe Acrobat Reader installation and used the name `AdobeReader.exe`.

This naming and location strategy helps the malicious program blend with legitimate applications. An administrator inspecting the system casually may assume that the file belongs to Adobe because its path and filename appear familiar.

Attackers frequently imitate legitimate software directories and process names for this reason. A trusted-looking filename is not proof that a file was installed by the actual vendor.

The file’s digital signature, creation time, hash, parent process, network communication and installation source must also be examined.

The malicious service communicated with attacker-controlled infrastructure, allowing the operators to retain access and issue further instructions.

Encoded PowerShell downloaded additional tools

The masqueraded workplace executables launched encoded PowerShell commands that retrieved additional payloads from attacker-controlled servers.

PowerShell is a legitimate Windows administration framework used extensively by IT teams. It can download files, manage services, modify the registry and execute scripts, making it equally useful to attackers after they gain initial access.

Encoding the commands helped conceal the URLs, filenames and actions from users and basic security inspection.

The scripts downloaded ScreenConnect MSI packages into temporary directories and launched them through `msiexec.exe`, the legitimate Windows Installer service.

This technique allowed the attackers to execute the next stage using trusted Windows components rather than an obviously unfamiliar loader.

Security monitoring should therefore focus on relationships between processes and events. PowerShell downloading an MSI file, placing it into a temporary directory and launching it through `msiexec.exe` shortly after a fake software update runs is highly suspicious.

Each tool involved may be legitimate individually. The complete sequence reveals the malicious context.

Multiple remote-access tools created redundancy

The attackers installed more than one remote-management framework on compromised systems.

ScreenConnect provided one remote-access route, while Tactical RMM and MeshAgent created additional channels.

Deploying several RMM tools gives the attacker operational resilience. If defenders detect and remove one agent, another may continue providing access.

Different tools may also provide different capabilities, communication paths and opportunities for evading security controls.

This redundancy shows that the campaign was designed for persistent and durable access rather than a brief opportunistic infection.

Incident responders must therefore avoid assuming that removing the first visible remote-access tool has completely contained the compromise.

Systems should be examined for every unauthorized RMM agent, Windows service, registry autorun, scheduled task and outbound management connection.

Approved remote-access software should also be reviewed because attackers may alter an existing installation, add a new server address or create unauthorized accounts within a legitimate management platform.

ScreenConnect was deeply integrated for persistence

The ScreenConnect installation created Windows services and registry entries containing identifiers, callback tokens and connection information required to reconnect to the attacker’s infrastructure.

The client executable was stored within a ScreenConnect directory under `C:\Program Files (x86)` and configured to restart automatically.

This provided continued access after system reboots or interruptions. Even if the original phishing executable was removed, the ScreenConnect service could remain operational.

Remote-management agents are specifically designed to reconnect automatically because legitimate support teams need reliable access. Attackers simply inherit that reliability when they install the agent themselves.

Security teams should maintain an inventory of authorized RMM products, servers, client identifiers and installation paths. Any remote-management agent not associated with an approved provider or internal IT system should be investigated.

Simply seeing that a file is part of ScreenConnect does not explain who controls the corresponding server.

An otherwise legitimate agent connected to an attacker’s instance remains unauthorized remote access.

Trusted tools complicate endpoint detection

The campaign demonstrates the limitations of relying exclusively on malware signatures.

ScreenConnect, Tactical RMM and MeshAgent can all have legitimate business uses. Their binaries may be signed and contain no conventionally malicious code.

Traditional antivirus software may therefore permit them to run, particularly when the initial loader is also digitally signed.

Behavioural and contextual detection become essential. Security tools should examine how the application arrived, which user installed it, where it connects and whether the organization has approved that instance.

An RMM product appearing immediately after a user opens a phishing attachment is different from an agent deployed through the company’s endpoint-management platform.

The location from which the installer executes also matters. Business software launched from Downloads or temporary folders following an email click should receive additional scrutiny.

Application-control policies can reduce this risk by permitting only approved RMM tools and publisher certificates. Organizations should block remote-management products that have no legitimate business purpose in their environment.

Where an RMM product is required, the approved instance should be configured with strong authentication, restricted administration and detailed audit logging.

Digital signatures should not become automatic allowlists

Many application-control systems trust software based on its publisher signature. This approach is operationally convenient because legitimate vendors can update their applications without administrators approving every new file hash.

However, broadly trusting a publisher can create risk when its certificate is compromised or abused.

Organizations should avoid trusting every signed application automatically. Publisher rules should be limited to vendors and products with a genuine business requirement.

High-risk categories such as RMM tools, scripting engines and system utilities may require more granular controls based on filename, path, product identity or approved certificate.

Security teams also need a mechanism for rapidly revoking trust in a certificate associated with malicious activity.

A signature proves origin only according to the certificate chain. It does not guarantee that the origin is trustworthy forever.

The software-signing system remains valuable, but defenders must resist turning a valid signature into a universal permission slip.

Meeting invitations are becoming an attack platform

Video-conferencing applications have become essential to routine business communication, giving attackers a dependable theme for phishing.

A fake meeting invitation can contain a malicious link, counterfeit transcript, fraudulent recording or supposed application update.

The recipient may not know every external participant in advance, particularly in sales, recruitment, consulting and partnership workflows.

Attackers can therefore create convincing invitations using company names, employee identities or project information collected from public sources and previous breaches.

Organizations should encourage employees to confirm unexpected meetings through a separate communication channel, particularly when the invitation asks them to install software.

Whenever possible, users should join meetings through the application already installed on the device or navigate directly to the official service.

A meeting link should not require a separate executable downloaded from an unrelated website.

Enterprise browsers, email security and secure web gateways should inspect meeting links and identify domains that imitate Zoom, Microsoft Teams, Google Meet and other collaboration services.

Lookalike domains may differ from the legitimate address by only one word, character or subdomain.

Fake PDF documents exploit familiar expectations

The Adobe-themed campaign demonstrates how attackers can turn an ordinary document workflow into malware delivery.

The attachment displayed a blurred image resembling protected content and directed the victim to click “Open in Adobe.” This created the impression that the file itself existed but required updated software or additional authorization.

The technique is effective because users expect PDF documents to open through Adobe Reader or a browser. They may also believe that a blurred preview indicates a permissions or version problem rather than deception.

Organizations should configure email systems to inspect attachments containing embedded links and unusual external redirects.

Users should understand that a PDF attachment does not need to direct them to an external software installer. Adobe Reader updates should be delivered through the installed application, centralized endpoint management or Adobe’s verified official site.

A document that refuses to open and instead requests software installation should be treated as suspicious, especially when received unexpectedly.

Unauthorized RMM use can lead to wider compromise

Once the attackers establish remote access, they may execute commands, install additional software, steal credentials and move laterally through the network.

The compromised workstation may contain browser sessions, VPN access, cloud credentials, email accounts and connections to internal services.

Attackers can use the RMM channel to perform reconnaissance, identify security products and determine whether the victim provides a valuable route into the broader organization.

They may target administrators, finance employees, executives or developers whose systems contain privileged access.

Remote-control functionality can also allow attackers to observe user activity, access files and potentially interact with business applications through the victim’s authenticated session.

If the endpoint is joined to a corporate domain, stolen credentials may support access to additional systems.

The initial fake update should therefore be treated as the beginning of a possible enterprise intrusion, not merely an isolated unwanted-software installation.

Organizations discovering an unauthorized RMM agent must investigate what the attackers did after obtaining access.

Password changes alone may be insufficient

An attacker controlling a system through RMM software may capture credentials, steal browser cookies, obtain authentication tokens or register additional persistence.

Changing the user’s password does not automatically remove these access methods.

Incident response should include terminating active sessions, revoking tokens, reviewing registered devices and rotating credentials accessed from the compromised endpoint.

Administrators should examine email forwarding rules, cloud application permissions, remote-access accounts and multi-factor authentication changes.

If the user held administrative access, service accounts and privileged credentials used from the device may also require rotation.

The affected system should be isolated before credentials are changed. Otherwise, the attacker may observe or capture the replacement values through the still-active remote session.

Where system integrity cannot be confirmed, rebuilding from a trusted image is safer than removing selected applications and returning the endpoint to service.

The investigation should identify every device reached through the attacker’s remote-management infrastructure.

RMM tools require organization-wide inventory

Many organizations use several remote-management products without maintaining one complete inventory.

Internal IT teams, managed service providers, application vendors and support contractors may each deploy separate agents.

This creates an environment in which an unauthorized RMM tool can blend with legitimate administration.

Organizations should document every approved remote-access product, the team responsible for it, the management server it contacts and the devices on which it should be installed.

Security controls can then alert when a new product or unrecognized instance appears.

The objective should not be to block remote administration entirely. It should be to ensure that only authorized teams can establish persistent remote access.

Vendor support access should be temporary where possible and protected with strong authentication. Standing access that remains active indefinitely increases supply-chain risk.

Logs should record which administrator initiated each session, which device was accessed and what actions were performed.

Application control can prevent unauthorized tools

Windows Defender Application Control, AppLocker and similar technologies can restrict software execution according to publisher, path, hash and product identity.

Organizations can use these controls to block unapproved remote-management tools and prevent executables from running directly from Downloads and temporary directories.

Policies should be tested carefully because RMM and support tools may have legitimate operational uses.

However, allowing every signed remote-access product merely because one department might someday need it creates an unnecessarily broad attack surface.

Endpoint security platforms should also alert when programs create new Windows services, Run keys or persistent remote connections.

The combination of a newly downloaded executable, service creation, encoded PowerShell and installation of an RMM agent provides a strong behavioural signal.

Attackers benefit when security controls evaluate these events independently. Defenders gain the advantage when they correlate them as one infection chain.

Network monitoring must distinguish approved RMM traffic

Remote-management tools generally communicate over encrypted connections, which can make traffic content difficult to inspect.

Nevertheless, organizations can monitor destinations, process identities, certificates, connection timing and data-transfer patterns.

Approved RMM agents should connect only to known management servers. Connections to unfamiliar ScreenConnect, Tactical RMM or MeshAgent instances should trigger investigation.

DNS and proxy logs can help identify endpoints contacting newly observed remote-management infrastructure.

Outbound communication from a fake Adobe executable or a recently installed Windows service is suspicious even when the traffic uses HTTPS.

Network controls can also restrict which devices are allowed to communicate with remote-management services. Ordinary user workstations should not freely establish persistent tunnels to arbitrary administrative platforms.

Attackers increasingly abuse legitimate cloud and RMM infrastructure because blocking the provider globally is impractical. Context remains essential.

Security awareness must address update-themed phishing

Employees are routinely advised to keep software updated, which attackers exploit by presenting malicious installation as responsible security behaviour.

Awareness training should explain where legitimate updates come from. Applications should update through their own built-in mechanisms, official vendor sites or the organization’s endpoint-management system.

A software-update prompt appearing after an email link, meeting invitation or document attachment should be treated with suspicion.

Users should not install an update because a webpage claims that it is required to continue. They should close the page, open the application independently and check for updates through its normal interface.

Organizations should also make it easy for employees to report suspicious meeting invitations and update prompts. A security process that takes several hours to respond encourages users to solve the apparent problem themselves.

Training should focus on realistic situations rather than generic warnings. Employees are more likely to remember a fake meeting update scenario when they understand exactly how urgency and familiar branding are being manipulated.

Incident response must search for several persistence layers

Responders investigating this campaign should search for the original masqueraded executable, Windows service entries, registry Run keys, encoded PowerShell activity and every installed RMM product.

The presence of one unauthorized agent should trigger a search for others because the attackers deliberately deployed multiple access channels.

Security teams should review process and network activity beginning from the time the phishing message was opened.

Files stored in Adobe-, Zoom- or Teams-looking directories should be validated rather than trusted based on their names.

Certificate information associated with TrustConnect Software PTY LTD should be used for retrospective hunting across endpoints and software inventories.

Connections to the known attacker-controlled domain and unapproved ScreenConnect or Tactical RMM servers should also be examined.

The affected mailbox should be reviewed to identify the original phishing message and determine whether other employees received or opened similar content.

Email-security systems should remove remaining copies from inboxes and block the associated domains, hashes and certificates where appropriate.

The broader cybersecurity lesson

The fake Adobe and Zoom update campaigns show how modern attackers combine social engineering with trusted software ecosystems.

The phishing messages used familiar business situations. The websites copied recognizable brands. The executables carried valid digital signatures, and the final payloads were legitimate remote-management products.

Every stage borrowed trust from something the victim or security system already recognized.

This makes the campaign more difficult to stop through any single control. Email filtering may miss a convincing invitation, users may trust the branded page, Windows may accept the signed executable and antivirus may permit the legitimate RMM software.

Effective defence requires several layers working together. Organizations need secure email filtering, browser protection, application control, behavioural endpoint monitoring, RMM inventory, network visibility and practical user training.

Most importantly, security decisions must consider context rather than relying on labels.

A file named AdobeReader is not necessarily from Adobe. A valid signature does not guarantee safe behaviour. ScreenConnect is not automatically legitimate merely because it is a real administration product.

The question should always be whether the software arrived through an approved process, is connected to an authorized service and is behaving consistently with a genuine business requirement.

Attackers increasingly understand that writing custom malware may be unnecessary when legitimate tools already provide persistence, encrypted communication and complete remote control.

Organizations must therefore monitor the use of trusted software as carefully as they monitor clearly malicious files.

The campaign reinforces a simple but important rule: software updates should come from the software itself or an approved management platform, never from a document, meeting invitation or unexpected webpage.

When an attacker controls the update prompt, the “new version” may be nothing more than a professionally packaged route into the organization’s network.

Cybersecurity researchers have disclosed details of an active, multi-wave campaign that employs social engineering lures themed around Adobe and Zoom software updates, business document reviews, and system maintenance utilities to stealthily deploy Remote Monitoring and Management (RMM) programs like ConnectWise ScreenConnect. The campaign has been codenamed SMOKE#SCREEN by Securonix Threat

Source: Fake Adobe and Zoom Updates Install ScreenConnect for Persistent Remote Access via The Hacker News — published 04 Aug 2026.