The PDF Viewer That Makes Sandboxes Wait It Out

About this post: this analysis and write-up were produced by Claude (Anthropic’s Opus 5.5 model), working as an AI agent in Claude Code on a REMnux workstation. For the analysis it used Malcat (static analysis, decompilation, YARA and KesaKode similarity lookups), objdump and pefile (disassembly and file parsing), a small C program and Python scripts (to solve the loader’s puzzle and decrypt its payloads), capa (capability detection), and the ANY.RUN sandbox (detonation). The diagrams were made with Graphviz. A second, independent Claude agent then reviewed the findings against the raw evidence. Its corrections, such as the logon bomb described below, have been checked and folded in. The file was provided to us by MalwareHunterTeam. A big thanks goes to MalwareHunterTeam for their regular hunting for malware.

A brand-new certificate that is immediately used to sign a product nobody has heard of is a pattern we see again and again with signed malware. expltprt.exe is another example. It calls itself a “PDF Document Viewer”, and its signing certificate was valid for just three days.

When it runs, nothing visible happens. Run it in a public sandbox and you get a mostly clean result: 24 out of 100, “No threats detected.” Underneath, though, is a loader that keeps a sandbox busy until the sandbox gives up. After that comes a full backdoor with a keylogger, browser injection, a remote shell and a self-destruct routine that tries to wipe evidence and leaves the PC shutting itself down at every logon.

TL;DR

  • expltprt.exe is signed through Microsoft Trusted Signing by “Essie Sound” (Netherlands). The certificate was valid from 29 September to 2 October 2026.
  • Before doing anything harmful, it plays a number-guessing game with itself: about 3.7 billion guesses to find its own decryption key. That takes longer than a typical sandbox run, so sandboxes see almost nothing.
  • Once the right number is found, it decrypts four hidden DLLs and installs a backdoor that hides inside Windows Explorer.
  • The backdoor finds its server in three ways: a saved address, the BitTorrent DHT network, or a list of generated domain names ending in .click and .cymru.
  • It can log keystrokes, watch the clipboard, inject code into web browsers, run commands and, on the operator’s command, wipe its files and plant a “logon bomb” that shuts the PC down every time the user signs in.
  • We couldn’t match it to any known malware family.
The whole chain, from a signed "PDF viewer" to a backdoor running inside Explorer.
The whole chain, from a signed “PDF viewer” to a backdoor running inside Explorer.

“But it’s signed!”

Code signing lets Windows show you who published a program and confirm the file hasn’t changed since it was signed. That’s why signed files get fewer warnings. What a signature can’t tell you is whether the publisher is someone you should trust.

This file has an identity crisis. Its embedded details say the company is “Vantage Point Systems”, the product is “App Compatibility Engine”, the description is “PDF Document Viewer” and the copyright belongs to “Pinnacle Systems Group”. The certificate belongs to none of them: it was issued to “Essie Sound” in Heerenveen, Netherlands.

The certificate came from Microsoft Trusted Signing, a service that issues short-lived certificates after verifying an identity. Short lifetimes are normal for that service. A three-day certificate used right away on a program carrying three different company names is not normal.

Takeaway: a valid signature means “this file came from whoever owns this certificate.” Check whether the signer matches the product you think you’re installing.

This certificate has been reported to Microsoft and added to the CertGraveyard.

The waiting room

Sandboxes are automated analysis machines: they run a suspicious file for a few minutes and record what it does. Their weak point is time. If a program does nothing interesting for long enough, the sandbox reports what little it saw and shuts down.

expltprt.exe exploits that weak point. First it copies itself into the Temp folder under a random name, such as cb3633bc.exe, and restarts from there with a /u switch. Then the restarted copy starts guessing numbers. Each guess is scrambled through a small random-number generator and compared against a fixed target. Most of the time it’s wrong, so it tries the next number, taking a short nap every million or so attempts.

The right answer is guess number 3,726,750,310. The program never stores this number; it has to find it again every time it runs. On a real PC we estimate that takes a few minutes; we didn’t time it, but the naps alone add up to about a minute. Think of a safe whose combination isn’t written down anywhere, so the owner has to count up from zero every time. The owner doesn’t mind waiting. An automated inspector on a timer does.

That is exactly what happened in ANY.RUN, where the run lasted 60 seconds. The sandbox recorded the copy to the Temp folder and the restart with /u, and then the run ended while the program was still guessing. The result was “No threats detected.”

Opening the safe without waiting

Because the guessing loop is just arithmetic, it can be copied out of the program and run much faster elsewhere. The malware even wastes time on purpose, redoing the same setup step 11 times for every guess. We rewrote the loop as a short C program without that padding, and it found the right number in about 30 seconds.

That number produces a 16-byte key for RC4, an older and simple encryption method. Inside the file are four long strings of hexadecimal text (letters and numbers representing bytes). Decoding them and decrypting with that key produced four complete DLLs, which are Windows code libraries that other programs can load:

NameWhat it is
core32.dll / core64.dllThe backdoor itself, in 32-bit and 64-bit versions
ext32.dll / ext64.dllA small “launcher” whose only job is to start core from inside Explorer

The stub then runs core32 directly in memory, without ever saving it as a file. It always starts with the 32-bit version; core32 then checks whether Windows is 64-bit and installs the matching pair. This is called reflective loading: the program acts as its own Windows loader, so there’s no DLL on disk for antivirus to scan.

Moving into Explorer

The first thing core does is make sure it survives a reboot, and it does that without touching the usual autostart locations.

  • It saves the small ext DLL as %LOCALAPPDATA%\Microsoft\HealthMonitor\dcom_launch_cache.dat. The folder and file names are chosen to look like Windows housekeeping.
  • It saves itself encrypted inside the registry instead of as a file. The registry is Windows’ big settings database, and HKCU is the part that belongs to the current user. The value sits under HKCU\Software\Microsoft\Windows and has a two-letter name calculated from the computer’s name, so it differs from PC to PC. (The 64-bit version, when it reinstalls itself, uses a different folder: %LOCALAPPDATA%\Microsoft\BrowserCore\app_compat_cache.dat.)
  • After waiting 60 seconds, it uses a technique called COM hijacking.

COM is a Windows system that lets programs ask for a component by an ID number instead of a file name; Windows then looks up which file to load. The ID the malware targets appears to belong to stobject.dll, a system-tray component that Explorer (the program that draws your desktop and taskbar) loads. That conclusion comes from the malware’s own behaviour: it forwards to that DLL and restarts Explorer. We couldn’t confirm it against a clean Windows registry. Windows checks the current user’s part of the registry before the system-wide part. So core adds an entry there that points the same ID at its own .dat file, then restarts Explorer.

Think of a personal address book that gets checked before the public phone directory: add a fake entry and every call to that name reaches you instead. To avoid breaking anything, the ext DLL passes Explorer’s request for the component on to the real stobject.dll, so the tray icons keep working. Ten seconds after Explorer loads it, ext reads the encrypted core from the registry, decrypts it and runs it in memory. From then on, the backdoor runs inside a process that is always on and always trusted.

Three ways to find home

Malware has to reach its operator somehow, and a single hard-coded address is easy to block. This backdoor has three fallbacks.

The backdoor tries a saved address first, then the BitTorrent DHT, then a list of generated domains. Whatever it finds must pass a basic handshake check.
The backdoor tries a saved address first, then the BitTorrent DHT, then a list of generated domains. Whatever it finds must pass a basic handshake check.
  1. A saved address. Once the operator has given it a server, it remembers it in its settings.
  2. BitTorrent DHT. The DHT (Distributed Hash Table) is the decentralised “phone book” that torrent clients use to find each other without a central server. Instead of a domain, the backdoor looks up a few entries in this phone book that change every hour. There’s no single domain to seize. The trick behind it is explained in the next section.
  3. Generated domains. As a last resort it generates domain names from a fixed starting number, the seed (0x445EE67C): 8ab46cb4[.]click, e37f0b85[.]click, 43fafac2[.]click and so on, each also tried with .cymru. The list never changes, so the operator only needs to register one of them when it’s needed. This technique is called a DGA (domain generation algorithm).

Whatever it finds, it runs a basic check. It contacts hxxp(s)[://]<IP>/index[.]php and expects the server to send back the bot’s own ID. If the answer is wrong, it moves on to the next candidate. Because the bot sends that ID itself, the check alone wouldn’t stop a researcher’s server from echoing it back. Whether the encrypted message layer adds real protection is something we haven’t worked out yet.

Hiding an address in port numbers

The DHT step is the cleverest part of this backdoor, so it’s worth a closer look.

In the DHT, every torrent is identified by a 40-character fingerprint called an info-hash, and the network keeps a list of the computers (peers) sharing each torrent, as an IP address plus a port number. Torrent clients add themselves to those lists all the time. So the operator doesn’t need a real torrent: they just need lookup keys that their bots can calculate too.

Here’s what the backdoor does:

  1. Calculates this hour’s keys. It takes the text SrvDiscovery-TES, the number of hours since 1 January 1970, and a counter (0, 1 or 2), and runs them through SHA-1, a standard fingerprint function. That gives three info-hashes that are the same on every infected PC and change every hour. It also checks the previous hour’s three, in case the operator is slightly behind.
  2. Asks who is “sharing” them. It only asks. It never adds itself to the lists.
  3. Ignores the peers’ IP addresses. What it reads are their port numbers. A port is a number from 0 to 65,535, which is exactly enough to hold half of an IPv4 address. The ports listed under key 1 give the first half of the server’s address and the ports under key 0 give the second half. For example, 203.0.113.7 would be listed as port 51968 (203.0) and port 28935 (113.7).
  4. Checks the result. Key 2 carries a check number: a port that must match a SHA-1 fingerprint of the hour and the rebuilt address. This weeds out random peers, which are common in a public network. If it matches, the backdoor contacts hxxp[://]<that IP>/index[.]php.

So the operator publishes three fake “peers” an hour and never exposes a domain name, and the peers’ own addresses can be anything.

This cuts both ways. Defenders can calculate the same keys for any hour, look them up in the public DHT and read off the operator’s current server, without touching the server at all. And the check uses only the fixed text that’s in every copy of the malware, not a secret key, so anyone who knows the scheme could publish a different address and the bots would accept it. Whether the bots would then obey that server depends on the encrypted message layer, which we haven’t decoded.

What the backdoor can do

From its code and text, core is a full remote-access tool:

  • Keylogger and clipboard monitor. It records keystrokes and anything copied to the clipboard.
  • Browser injection. It restarts Chrome, Edge, Brave or Yandex Browser in debugging mode and uses that remote-control channel (the Chrome DevTools Protocol) to inject the operator’s JavaScript into chosen websites. This is the same approach banking trojans use to change web pages or capture what you type into them. It also modifies the browser’s Secure Preferences file.
  • Remote control. It can run commands through Command Prompt, PowerShell and Windows Script Host (the built-in engine that runs .js and .vbs scripts), and load extra modules in memory. It can also open a reverse shell: a command prompt on your PC that connects out to the attacker, so firewalls that only block incoming connections don’t stop it.
  • Security product check. It looks in the registry for nearly twenty security products, including Defender, ESET, Kaspersky, CrowdStrike and SentinelOne.
  • Self-update and process blocking. It can replace itself with a new version and block programs by name.
  • A destructive “uninstall”. On command from the operator, it drops a small JScript file that overwrites its own files with zeros and forces an immediate shutdown. The script also tries to delete Windows’ backup snapshots (volume shadow copies) and clear every Windows event log. Those two steps need administrator rights, which this malware doesn’t normally have, so on a standard account they will probably fail.
  • A logon bomb. The same uninstall routine changes the user’s “Shell” setting, which tells Windows what to start when you sign in. Instead of the desktop, it now says shutdown.exe /s /f /t 0. From then on, every sign-in immediately shuts the PC down. This one needs no admin rights.

Who made it?

We don’t know. Malcat’s KesaKode similarity service compares code and strings against known families. Every score here was below 2%. The few matches were generic: memory-copying helpers, a security-vendor registry path, and the address of a public BitTorrent server that other DHT-using malware also lists. None of the indicators match anything else we’ve analysed. The internal names (core, ext, SrvDiscovery-TES) and the placeholder address test[.]test/t12 left in its templates hint at a builder, a kit that generates malware for customers, but that is weak evidence.

What the analysis couldn’t reach

We didn’t resolve the generated domains or query the DHT, so we didn’t contact any infrastructure that might belong to the operator. That means we don’t know whether a server is currently live. The encrypted message format the backdoor uses with its server was mapped but not fully decoded. Without that, we can’t say whether a defender could take over the bots through the DHT or by sinkholing one of the domains, i.e. registering it and pointing it at a harmless server to see who connects.

The installation steps and features above come from reading the decrypted code, not from watching them run, because the sandbox never got past the guessing loop.

What can you do about it?

If you’re a regular user:

  • Download software only from the developer’s official website. A “PDF viewer” from an ad or a random link is a classic lure.
  • If a program “does nothing” when you open it, treat that as a red flag, not a glitch.
  • Check the signature: right-click the file, choose Properties, then Digital Signatures. If the signer’s name has nothing to do with the product, don’t run it.

If you’re a defender:

  • Look for executables in %TEMP% named with 8 hex characters and launched with /u.
  • Check HKCU\Software\Classes\CLSID\{68ddbb56-9d1d-4fd9-89c5-c0da2a625392}\InprocServer32. On a clean system that key shouldn’t exist under HKCU. Any value pointing into %LOCALAPPDATA% is a strong signal.
  • Look for dcom_launch_cache*.dat under %LOCALAPPDATA%\Microsoft\HealthMonitor\ and app_compat_cache*.dat under %LOCALAPPDATA%\Microsoft\BrowserCore\.
  • Look for a two-letter REG_BINARY value (letters a to p) under HKCU\Software\Microsoft\Windows.
  • Alert on HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell being set to anything, especially shutdown.exe.
  • explorer.exe contacting BitTorrent DHT bootstrap servers (router[.]bittorrent[.]com, dht[.]transmissionbt[.]com and similar) is a strong signal.
  • Alert on cmd.exe running reg add … InprocServer32 … & taskkill /f /im explorer.exe.
  • Alert on browsers started with --remote-debugging-port by anything other than a developer tool.
  • Block or sinkhole the generated .click and .cymru domains.
  • Don’t rely only on sandbox verdicts. A low score can just mean the sample waited the sandbox out.

Indicators of compromise

TypeValue
SHA256 (expltprt.exe)b25c9e7e793a86965779a71a8e8f81a2d43f40db54b7c252768faff306071fd6
MD5 (expltprt.exe)a2cda3a5d03e5d1fdbb3ccd2f73b831d
SHA256 (core32.dll)c35d284ce7d0f93bee17016c5cd3451663636ed0cf3a5ab0a04630cb41fddb96
SHA256 (ext32.dll)e70225a23e8b9550960e729a396540ccd659af194cde8011d9c42003c3b81578
SHA256 (core64.dll)fd2b4e30d795858d0c771775aeeb41433ea6bf9cfe71fad28397633100b1ceaf
SHA256 (ext64.dll)43326f368f425d4071be67ae74768fcf12c0e03f81d7d2af192ed6ea0c7cca21
SignerEssie Sound (Heerenveen, NL)
Cert serial3300075fb851691fe5365badb3000000075fb8
Dropped file%LOCALAPPDATA%\Microsoft\HealthMonitor\dcom_launch_cache.dat (or …1.dat to …9.dat)
Dropped file (x64 reinstall)%LOCALAPPDATA%\Microsoft\BrowserCore\app_compat_cache.dat (or …1.dat to …9.dat)
Temp copy%TEMP%\<8 hex chars>.exe /u
RegistryHKCU\Software\Classes\CLSID\{68ddbb56-9d1d-4fd9-89c5-c0da2a625392}\InprocServer32
RegistryREG_BINARY value named [a-p]{2} under HKCU\Software\Microsoft\Windows (encrypted core)
Registry (logon bomb)HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell = shutdown.exe /s /f /t 0
MutexLocal\714A8790-6FA3-43AA-A2BC-BAF9DAC079FD
DHT key textSrvDiscovery-TES (hourly info-hash = SHA-1 of this text + hours since 1970 + counter 0/1/2)
DHT bootstrap (benign hosts)router[.]bittorrent[.]com, router[.]utorrent[.]com, router[.]bitcomet[.]com, dht[.]transmissionbt[.]com, dht[.]aelitis[.]com, dht[.]libtorrent[.]org
DGA seed0x445EE67C; TLDs .click, .cymru
DGA (first 10)8ab46cb4, e37f0b85, 43fafac2, 88f426f3, 89625c26, 9e3957f5, 2c321f56, 94c5fffa, 4c6fe687, a75485d8 (each [.]click and [.]cymru)
C2 URL patternhxxp(s)[://]<IP>/index[.]php

Wrapping up

From the outside, this sample is a “PDF viewer” with a valid signature and a nearly clean sandbox report. Patience is its main defence: it waits until the sandbox stops watching. Underneath is a carefully built backdoor that hides in Explorer, finds its server through a torrent network, and can try to wipe its tracks and leave the PC unusable on command.

As with most signed malware we see, the first warning sign was there before anything ran: a three-day-old certificate from a company with no connection to the product.

If you want to dig further:

As always: check who signed it.