A signed “Abe Office” helper that opens your browser behind your back

About this post: Thank you to MalwareHunterTeam for identifying and sharing the file. This analysis and write-up were produced by Claude (Opus 5.5), working as an agent in Claude Code on a REMnux analysis VM. Tools used: Malcat, capa, Python, Wireshark, a sandboxed Wine run, ANY.RUN and a multi-day Deception Pro run.

TL;DR

AbeAgent.exe calls itself the "Abe Office workstation helper". It is signed with a certificate in the name of an individual, Kimberley Hankinson, and there is no "Abe Office" product behind it. It is a modular remote-access trojan (RAT): a small starter program that carries three encrypted add-ons, asks its server for the key to unlock them, and then gives the operator a hidden desktop with the victim’s own logged-in browsers, plus a browser stealer built to defeat Chrome’s newest cookie protection, App-Bound Encryption. "Abe" is very likely short for App-Bound Encryption.

The "unlock" step is meant to keep the add-ons secret unless the server agrees. It doesn’t: the key can be derived from a default password left in the file, so we decrypted all three add-ons and every message the program exchanged with its server.

• Signed: SSL.com certificate "Kimberley Hankinson", serial 5CA1AA263B09E43D349B735343EB2FDC, signed 4 November 2026.
• Hidden desktop (hVNC): the victim’s Chrome and Edge profiles are copied to C:\ProgramData\AbeOffice\SystemCache\ and opened on an invisible desktop, so the operator can use the victim’s logged-in sessions without them seeing anything.
• Browser stealer ("DC Styler"): passwords, cookies and extensions from Chrome, Edge, Brave, Opera and Firefox, including a tool that gets the browser to decrypt its own App-Bound key.
• Persistence: a Run key "Abe Office Sync" and a scheduled task, both starting AbeAgent.exe --autostart.
• Command and control (C2): 2.26.230[.]54:9090, which answered and unlocked the add-ons during our sandbox runs.
• Seen in action: in a multi-day sandbox run, the operator opened the hidden Chrome and Edge and went straight to their saved-password pages.
• Part of a bigger campaign: the operator’s control panel runs on the C2 server itself. A second server with the same download page is linked to 132 more files on VirusTotal going back to mid-September, mostly loaders and packages we have not analysed yet.

But it’s signed!

Code signing is like a tamper seal with a name on it, vouched for by a certificate authority (CA) such as SSL.com. It tells you who sealed the package and that nobody changed it afterwards; it does not tell you the contents are safe. Here the seal names a private person in Cherry Tree, Pennsylvania, while the file presents itself as an office product from "Abe Office". A brand-new certificate in an individual’s name, used straight away to sign a "company" product, is a pattern we see again and again with signed malware. The certificate became valid on 26 October 2026, and the file was signed on 4 November.

The certificate was used twice in this kit: the small browser helper inside it (AbeBrowserShim.dll) carries the same signature, dated 31 October.

The certificate has been reported to the CA and added to the CertGraveyard.

Step one: move in and make itself at home

When it first runs, AbeAgent.exe copies itself to %USERPROFILE%\AbeOffice\ and restarts from there. On the way it:

• removes the "downloaded from the internet" mark (the Mark of the Web, a hidden tag Windows uses to warn you about downloaded files);
• adds a Run registry value Abe Office Sync, which starts it at every logon with the switch --autostart;
• registers a scheduled task that does the same;
• tries to add a Windows Firewall rule called "Abe Office Agent" that would let it receive connections. In our short sandbox run this command failed; in the longer run it went through.

It also writes three files ending in .abe1. These are its add-ons, still encrypted.

A lock with the key taped to it

The three add-ons are:

Before loading them, the starter program contacts its server, sends a build ID plus an encrypted "wrapped key", and waits for the server to reply with the real key. Its own log message says it plainly: "server key required". The idea is that a researcher holding only the file cannot see the add-ons.

In practice the lock doesn’t hold. Everything needed to unwrap that key is in the file, including a password that looks like an unchanged default: AbeOffice-ChangeMe. Hashing that password gives a "product key", the product key unwraps the per-build key, and the per-build key decrypts all three add-ons. The key the live server sent back during the sandbox run was exactly the one we had computed offline, and the decrypted add-ons matched the files the sandbox saw on disk byte for byte.

The same password also protects the network traffic. Each message is encrypted with AES (a standard, strong cipher), but the AES key is just a hash of AbeOffice-ChangeMe, so we could decrypt the whole captured conversation.

What the server said

In the first, short sandbox run the decrypted traffic tells a clear story:

1. The starter program logs in with its build ID and wrapped key, and gets back the add-on key plus an expiry date.
2. The main module logs in separately, with the computer name and user name, and is accepted.
3. After that it sends a "still here" heartbeat every couple of seconds.

No commands arrived during that short run. To give the operator time to show up, we then ran the file in a sandbox for several days. That paid off, as described below.

A second browser you can’t see

AbeHvcn.dll creates a separate, invisible Windows desktop and starts Explorer, Chrome, Edge or Firefox on it. Think of it as a second monitor the attacker plugged into your PC, which you never see. The operator gets screenshots of that desktop and can move the mouse and type on it.

To make this useful, the add-on first copies the victim’s Chrome and Edge profiles to C:\ProgramData\AbeOffice\SystemCache\. In the sandbox it copied 287 profile files this way, including saved logins, cookies and settings. A browser opened from those copies is already logged in to the victim’s webmail, banking or shopping sites, so the operator can act as the victim without needing passwords, and from the victim’s own computer, which helps get past "new device" checks.

The hidden browsers are started with remote debugging switched on, but only reachable from the same computer. The add-on uses that local debugging connection to control them, for example to open tabs, run scripts or set cookies.

Watching the operator at work

In the multi-day run, the operator connected three times over about a day and a half. Because the traffic can be decrypted, we could replay what the hidden desktop showed them, frame by frame, along with every mouse movement and key they sent.

The first visit only pulled a few screenshots of the real desktop. On the next two the operator:

1. asked which browsers and profiles were on the machine (Chrome and Edge, each with a "Default" profile);
2. opened both browsers on the hidden desktop, using the copied profiles;
3. typed chrome://settings and edge://settings and clicked straight through to "Autofill and passwords" in Chrome and "Passwords and autofill / Microsoft Password Manager" in Edge.

The sandbox browsers held no saved passwords, so there was nothing to take, and the operator closed the browsers again. We did not see the browser stealer, remote commands or new add-ons being used. The run is still going, though, and this post will be updated if more turns up.

Following the servers

One more detail leaked: every command from the operator’s control panel includes the name of the computer it was sent from. Two names appeared, DESKTOP-7VBH2AA and VM-2C4B10FE-33D, and the second one did all of the hands-on work. Looking those names and the C2 address up in public internet-scan data (Shodan) and VirusTotal turned up more than we expected:

• The operator works from the C2 server itself. When Shodan checked the remote-desktop port on 2.26.230[.]54, the server gave its name as VM-2C4B10FE-33D, a Windows Server 2022 machine. That is the same name that drove the hidden browsers, so the control panel runs on the C2 server itself, most likely with the operator logged in to it over Remote Desktop. The server’s remote-desktop certificate was created in late October, which roughly dates when the server was set up. A couple of days later its port 80 began serving a small "Abe Update" page that lists the kit’s files for download: AbeCapability.dll, AbeHvcn.dll, AbeBrowserShim.dll and AbeAgent.exe.
• The other name is a dead end. DESKTOP-7VBH2AA shows up on at least 79 rented Windows servers at more than 20 budget hosting companies. It is the default name of a widely copied server image. In our traffic that panel only ever sent keep-alive pings, sometimes alongside the main one.
• A second server. A search for the same page title found one other server, 87.199.195[.]141 (hosted at VDSINA, server name WIN-R84DEUE96RB). In early November it served the same page listing the same add-ons, and VirusTotal has files that connected to its port 9090, the same port our sample uses.
• Our sample is one of many. VirusTotal ties 133 files to these two servers, first seen between mid-September and early November. They include 10 other files named AbeAgent.exe, 61 files named launcher-bootstrap-stub.exe signed with a homemade "Code Signing (self-signed local)" certificate, and 49 app.zip packages, 31 of them seen in folders named %TEMP%\launch-<number>-<hex>\. Ours is the only build with a certificate from a real certificate authority, and the only file linked to 2.26.230[.]54. It looks like the newest step of a campaign that has been running since at least mid-September: a fresh server and a bought certificate.

We have not analysed those other files yet. The stub and app.zip look like a likely delivery route, but that is still to be confirmed.

Getting past App-Bound Encryption

Since mid-2024 Chrome protects its cookie key with App-Bound Encryption: the key can only be decrypted by a Windows service that checks that the request really comes from Chrome itself. That was designed to stop exactly this kind of stealer, which reads the cookie database from outside the browser.

This kit’s answer is to ask from inside. It starts a browser off-screen (at position -32000, -32000), injects AbeBrowserShim.dll into it, and the helper asks the browser’s own elevation service to decrypt the key. Because the request comes from the real browser process, the service agrees. The helper writes the result to C:\ProgramData\AbeOffice\abe_job\key.dat. The code also contains other routes to the same key: injecting into a browser the user already has open, a browser extension called "Abe Crypto Bridge", and Chrome’s own helper programs.

With the key, the stealer (named "DC Styler" in its own messages) packs passwords, cookies and extensions per browser and profile and uploads them in parts. The code also looks for payment-card numbers.

Other things it can do

From the code (not all seen live):

• run commands through cmd.exe or PowerShell, and transfer files;
• take screenshots of the real desktop;
• list folders, collect basic system information;
• receive new or updated add-ons from the operator, wipe itself, or reboot the PC with the message "Office administrator requested a restart.";
• listen for a short "wake-up" network message (ABE_RECALL) that tells it to reconnect. This only works with the firewall rule in place, which was created in our longer run.

What we still don’t know

• How it is delivered. We only have the file itself. The launcher-bootstrap-stub.exe and app.zip files linked to the same servers may be the delivery route, but we have not analysed them yet, and the lure or download page is still unknown.
• What the operator does after browsing. We watched hidden-browser sessions live, but not the stealer, remote commands or any further downloads.
• Some command numbers. We matched most server commands to features, but not the ones that start the stealer or the remote shell.
• Who is behind it. We found no public reporting on this kit and no technical overlap with other samples we have analysed.

What should you do?

If you’re a regular user: a signature only tells you who signed a file, not that it is safe. A "company" product signed by a private person’s name is a red flag. If you ran this file, assume your browser sessions are compromised: from a clean device, sign out of all sessions and change passwords for important accounts (email first), and turn on two-factor authentication. Then have the PC cleaned or reinstalled.

If you’re a defender:

• Look for %USERPROFILE%\AbeOffice\ and C:\ProgramData\AbeOffice\, the Run value Abe Office Sync, and any process started with --autostart from that folder.
• Block or alert on outbound TCP to 2.26.230[.]54:9090 and 87.199.195[.]141:9090, and on HTTP to either address.
• Watch for browsers started with --window-position=-32000,-32000 or with remote debugging bound to 127.0.0.1, and for non-browser processes reading browser Login Data, Cookies and Local State files.
• Treat a sign-in from the victim’s own PC as untrusted too: hidden-desktop RATs act from the victim’s machine and IP address.

Indicators of compromise

All addresses are defanged.

Wrapping up

This kit puts real effort into the hard parts: a hidden desktop fed with cloned browser profiles, and several ways to get past Chrome’s App-Bound Encryption. Then it protects all of it with a password that was never changed from ChangeMe. That is good news for defenders: anyone with the file can decrypt its add-ons and its traffic. If you have a sample from the same kit, or know how it is being spread, we would like to hear from you.