EKZ Stealer Removal Guide: Browser Data Theft and FortiClient EMS Response

A file named like an endpoint patch appears around a VPN connection. On a managed work computer, that can look like another background update.

The filename alone doesn’t tell you who supplied it. When a security alert mentions EKZ, both the computer and the management route deserve attention.

Overview

EKZ is a browser-data stealer, not a legitimate patch

EKZ Stealer is Windows malware designed to collect browser credentials and other stored information. Its cleanup must be paired with protection of potentially exposed accounts.

Arctic Wolf documented a campaign involving compromised FortiClient EMS management and a payload called FortiEndpoint_Patch.exe. The legitimate Fortinet product was being abused as a delivery route.

Having FortiClient installed does not mean you have EKZ. A deployment history, security detection, and the actual management environment are needed to assess an individual device.

The campaign and the stealer perform different jobs

The primary analysis describes EKZ exporting collected browser data to a local file. Surrounding script activity then handles sending that output away.

That distinction matters during investigation. Looking only for a network connection from the stealer executable could miss activity performed by another component.

It also explains why deleting one suspicious file is not a complete response. The source of deployment and any associated scripts require review.

Contain the exposure without dismantling legitimate management

• Notify the organization responsible for the affected endpoint.
• Preserve detection details and the relevant VPN timeline.
• Have administrators inspect the management configuration and affected devices.
• Recover exposed browser accounts from a trustworthy device.

The image is a fictional file-details illustration, not an actual Windows property sheet or scan result. It highlights the reported filename without authenticating a particular file.

Why a Managed Update Can Be the Wrong Place to Put Your Trust

People are often told to avoid unfamiliar downloads. This campaign is a reminder that the delivery system can matter as much as the download’s appearance.

On an employer’s computer, software may arrive through tools controlled by administrators. The employee may not see the same installation choices as a home user.

If that management route is abused, the absence of a suspicious email does not rule out an incident. Investigators need to trace the actual deployment.

Nor should the employee assume a legitimate client application has become inherently malicious. A real tool can carry instructions that an unauthorized party inserted elsewhere.

The practical response is coordinated. The endpoint owner and management administrator each hold information the other may not see.

A user can report the moment a warning appeared. An administrator can examine policy changes, deployment records, and whether other managed computers encountered related activity.

Neither should decide the scope from the filename alone. A malicious file can use a reassuring name, and an unrelated file can share a similar label.

Preserve exact detection names, file locations, and timestamps privately. Those details help a technician compare an alert with the documented campaign.

Don’t repeatedly reconnect to the VPN to see whether the behavior happens again. Repeating an unknown trigger is not a safe diagnostic method.

How the Documented EKZ Infection Chain Unfolds

Step 1: Attackers abuse the management environment

The reported campaign involved CVE-2026-35616 in FortiClient EMS. Attackers used unauthorized management access to alter settings involved in endpoint VPN workflows.

For the reader, the important consequence is that the apparent instruction source could be a managed configuration rather than an obvious unsolicited attachment.

Administrators should assess their own deployment against the vendor’s current advisory. Do not apply a historical version list without checking the product and release actually installed.

End users should not attempt to repair a shared management server. Report the endpoint evidence to the team authorized to investigate it.

Step 2: A VPN-related workflow launches a misleadingly named payload

Arctic Wolf observed script execution associated with VPN activity and delivery of the patch-named executable. The name supplies an appearance of routine endpoint maintenance.

A file calling itself a patch is not the same as a verified vendor update. Its provenance and execution history need examination.

If your security software blocked an item, record whether the result was blocked, quarantined, or merely detected. Those outcomes can imply different exposure.

Don’t restore a quarantined file just because its name resembles approved software. Ask the responsible security team to evaluate the alert.

Step 3: Browser information is collected

The analyzed tool targets Chromium-family and Firefox-family browser information, including saved logins and cookies. Collected information is written locally for later handling.

A saved session can represent access even when you did not type a password during the incident. Include already signed-in services in the assessment.

The possible scope depends on the data available on that device. A campaign’s capabilities do not prove that every account on every computer was accessed.

Still, an absence of visible disruption is not reassuring enough. Information theft can matter while the browser continues to work normally.

Step 4: Other script activity transfers the collected output

The documented script handles exfiltration around the stealer’s local output. Investigating the executable without its surrounding process activity leaves an incomplete picture.

Security staff should preserve relevant endpoint and network records before routine cleanup destroys useful context. That decision is especially important on shared or managed infrastructure.

Device remediation cannot recall a password that has already been copied. Account protection must proceed according to the exposure identified by the investigation.

Restoring a computer to service also requires confidence that the management route will not deliver the same problem again.

Which Browser Information Deserves Immediate Attention?

Saved passwords and active sessions need separate checks

Start with services used in the affected browser. Identify which were signed in and which credentials were stored there during the suspected period.

Replace exposed passwords through the genuine services. Also inspect the session controls each service provides, rather than assuming a replacement automatically closes every connection.

Check unfamiliar devices, recovery options, and authorized applications. A compromised login may be used to establish another access method that deserves its own removal.

Email may provide a route into other accounts

A mailbox often receives password-reset links and security notifications. If it was accessible, protect it early and review changes to forwarding or filtering.

Then examine important services that use that mailbox for recovery. Look for actual reset requests and suspicious activity rather than guessing that every service was taken over.

Work accounts can require administrator assistance. The organization may need to revoke sessions or investigate records that the ordinary account holder cannot access.

Payment details call for accurate reporting

If payment information was stored or a suspicious charge appears, contact the issuer through a known number. Explain the incident without declaring an unobserved transaction fraudulent.

Keep transaction references and the period of potential exposure. The issuer can explain available controls and what additional evidence it needs.

A bank conversation should be independent of anyone who contacts you claiming to investigate EKZ. Don’t transfer funds because a stranger describes them as unsafe.

What Administrators Need Before They Call an Endpoint Clean

A workstation scan answers questions about the workstation. It does not, by itself, establish that the management server and deployment policies are trustworthy.

Separate those workstreams in the incident record. Otherwise, an endpoint may return to an environment where the original source of instructions remains unresolved.

Review unexpected management changes and identify which devices received the affected configuration. Preserve relevant logs with consistent time references.

Compare alerts across the managed group without assuming identical outcomes. One endpoint may have blocked execution while another encountered a different stage.

If business access was available, involve the owners of those systems. A technically successful cleanup does not settle whether a copied account was used elsewhere.

Document the difference between confirmed compromise and precautionary containment. That distinction makes escalation, customer communication, and recovery planning more accurate.

Use current vendor guidance for patching and support. A security advisory can change as additional fixed releases and affected configurations become clear.

A patch closes a vulnerability; it does not automatically remove previously deployed malware or invalidate secrets stolen before the patch.

Before broad credential changes, coordinate the sequence with service owners. Replacing shared access without a plan can interrupt recovery while leaving the actual compromised route active.

Likewise, do not export sensitive logs into an unapproved public tool for convenience. Browser data and deployment records may contain private information requiring controlled handling.

What to Do If EKZ Stealer Is Detected or Suspected

1. Stop sensitive work on the affected computer. Don’t log in to financial, administrative, or personal accounts while the endpoint is under assessment.

   Contact your genuine security team from another device. Follow its containment instructions, including network isolation when appropriate, without attempting an uncoordinated wipe.

2. Preserve the detection and timeline. Record the alert’s full wording, status, time, and the file involved. Note relevant VPN connections or update activity.

   Don’t execute the suspect file for confirmation. A technician can investigate safely without asking you to reproduce a potentially harmful launch.

3. Inspect Windows with trusted tools. Malwarebytes can help identify malicious and unwanted components. Use the Windows section of the reusable guide below.

   On a managed endpoint, coordinate scanning with the incident team. Its evidence-preservation and response tools may require a particular order of work.

4. Investigate management-side delivery. Authorized administrators should review the relevant EMS deployment, VPN profiles, and current vendor remediation guidance.

   Do not uninstall legitimate corporate software indiscriminately. The aim is to establish what changed, who received it, and whether the original delivery route is secure.

5. Recover exposed online access from a clean device. Prioritize valuable services and email, then change passwords and revoke suspicious sessions as the providers allow.

   Review recovery contacts and authentication methods. If an attacker altered those controls, follow the provider’s formal recovery process or your organization’s administrator-led procedure.

6. Handle financial findings through the relevant institution. Report suspicious card activity or unauthorized access with dates, references, and a clear description of what happened.

   Ask about appropriate protective steps. No security application can guarantee reimbursement, erase a remote copy of data, or reverse a transaction.

7. Choose a safe restoration plan. If the device needs rebuilding, preserve required evidence first and restore only material assessed as appropriate.

   A full old environment can restore unwanted components or settings. Agree on the source of software, the condition of backups, and who approves normal use.

8. Keep prevention tied to the actual entry route. Update systems and strengthen management access under the responsible team’s control.

   AdGuard may reduce exposure to malicious advertising during ordinary browsing. It does not repair an exploited management server or remove a compromised VPN-profile instruction.

Is Your Device Infected? Run a Free Malware Scan

Slow performance, constant pop-ups, or strange behavior? These are classic signs of a malware infection. The fastest way to find out is to scan your device with Malwarebytes Free — one of the most trusted malware removal tools available.

The free version detects and removes the most common threats, including:

• Adware — the cause of those annoying pop-ups
• Browser hijackers — unwanted redirects and changed homepages
• Trojans and spyware — hidden programs stealing your data
• Potentially unwanted programs (PUPs) — software you never asked for

👉 Select your device below — Windows, Mac, or Android — then follow the simple steps to download Malwarebytes, scan your system, and remove any threats it finds. The scan usually takes 5 to 20 minutes.

Stay Protected: Block Ads and Malicious Sites

Now that your device is clean, keep it that way. Most infections start with a malicious ad or a fake download button — so blocking them at the source is your best defense.

We recommend AdGuard, which blocks malicious ads, phishing pages, and dangerous redirects before they can reach you.

👉 Download AdGuard and browse safely

What a Successful Recovery Should Leave You With

You need more than a disappearing alert. Keep a record of endpoint remediation, management-side findings, and account-protection actions as separate completed tasks.

If no suspicious transaction appears, continue monitoring according to the investigation’s findings. Don’t turn an uncertain exposure into a claim of proven financial loss.

If a detection returns, preserve the new result and escalate. Repeating one cleanup step without investigating recurrence can miss the mechanism restoring the problem.

Microsoft’s malware troubleshooting guidance provides an official starting point when Windows security tools encounter removal problems.

For an organization, define who will confirm the management environment is safe before endpoints reconnect. Users should not have to infer that from a reassuring filename.

Include devices that were offline during the initial response. A computer reconnecting later should not receive an outdated configuration simply because the active fleet was already checked.

Agree how those devices will be assessed before normal VPN use resumes. This is a management decision for authorized administrators, not a workaround for individual employees.

Keep the final configuration reference with the recovery record. It gives the team something concrete to compare against if another endpoint reports related activity.

Finally, retain useful incident notes. A later account alert may need comparison with the original period, and memory becomes less reliable as normal work resumes.

Frequently Asked Questions

What is EKZ Stealer?

It is Windows information-stealing malware associated with browser data collection. The documented campaign used compromised management workflows and a misleading patch filename.

Does using FortiClient mean I am infected?

No. Product use alone is not a diagnosis. Your administrators must assess the actual configuration, exposure, deployment history, and device evidence.

Does EKZ send stolen data by itself?

The primary analysis describes local output from the stealer, with surrounding script activity transferring that data. Investigate the whole chain, not one process alone.

Will patching the management server remove EKZ?

Not automatically. Closing the vulnerability, remediating endpoints, and recovering exposed access are separate tasks that need coordinated verification.

Can changing passwords on the affected PC be unsafe?

Yes, if the computer remains compromised. Use a separate trustworthy device for account recovery while the endpoint is being assessed.

Is a clean scan proof that no data was taken?

No. A scan reports its findings at that point. Historical data exposure and remote account activity require their own investigation.

The Bottom Line

Treat EKZ Stealer removal as both an endpoint incident and an access-recovery task. Don’t trust the patch filename or stop after deleting one executable.

Involve the responsible security team, address the delivery route, and protect exposed accounts from a clean device before returning the computer to ordinary work.