A signed “touch controller” that only talks to servers with the right ID badge

About this post: Thanks to MalwareHunterTeam for flagging this sample. 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, FLOSS, pefile/capstone, OpenSSL, tshark, Wine (sandboxed) and ANY.RUN.

TL;DR

QuaTouchCtrl.exe calls itself the "Quartz Touch Controller" from "Quartz Devices", a driver helper that "processes touch controller interrupts". It is actually a small first-stage loader. It checks in with an attacker’s server, waits for orders, and runs whatever program the server sends it, straight from memory. What makes it unusual is that it carries its own client certificate, a kind of ID badge, and the attacker’s server asks for that badge before it will talk.

• Signed: valid EV signature from AirTiki ApS (GlobalSign), applied 18 September 2026.
• Hidden config: all 88 of its text strings are encrypted with ChaCha20 and only unscrambled at run time.
• Mutual TLS: a client certificate and private key from the attacker’s own private certificate authority ("ca-arch") are built into the file.
• C2: gitihubusercomtent[.]com (a misspelled "githubusercontent") on 178[.]105[.]122[.]30.
• Sandbox verdict: ANY.RUN rated it "No threats detected". We decrypted that run’s traffic: the server was alive and answered "no jobs right now".

What it pretends to be

The file has the full set of version details a real driver utility would have: a product name, company name, version 4.13.5504.26 and a plausible description. It is also signed with an Extended Validation (EV) code-signing certificate. Code signing is a digital seal that tells Windows which company published a program and that nobody has changed it since. EV certificates are meant to be the most carefully vetted kind.

The certificate belongs to a Danish company, AirTiki ApS, which has nothing to do with touch controllers or "Quartz Devices". The contact email inside the certificate is ole@airtioki.com, a misspelling of the company’s own name. A real company’s certificate being used to sign someone else’s "product" is a pattern we see again and again with signed malware.

Unscrambling the strings

Open the file in a disassembler and there is almost no readable text: no web addresses, no API names. Every string is stored encrypted and decrypted at start-up with ChaCha20, a modern stream cipher. The key is simply the SHA-256 hash of a phrase hardcoded in the file, 09239werijp34905erfklw3p049.

Once you know that, all 88 strings fall out at once. Among them are the server name, the web paths it uses, the JSON message templates, the Windows functions it loads by name (so they don’t show up in its import list), and two full PEM blocks: a certificate and its private key. The author also sprinkled in a dozen do-nothing functions full of random arithmetic, just to make the code look different to signature scanners.

The ID badge: mutual TLS

Normally, when your computer connects to a website over HTTPS, only the website shows a certificate to prove who it is. With mutual TLS, the client has to show a certificate too, like a staff member swiping a badge to get through a door.

QuaTouchCtrl.exe imports its built-in certificate and key into a Windows key container named stg_<process id> and presents it on every connection. The attacker’s server asks for that certificate during the handshake. Meanwhile the malware itself switches off every check on the server’s certificate, so it will happily talk to whatever answers.

The certificates tell a neat story. The server certificate seen in the sandbox traffic and the client certificate hidden in the file were both issued by the same private authority, ca-arch, one second apart, with consecutive serial numbers. About two hours and forty minutes later the program was signed with the AirTiki EV certificate. The infrastructure and the binary were put together on the same afternoon.

For defenders this badge is a gift. Any server presenting CN=srv-arch.internal signed by CN=ca-arch belongs to the same setup, and any other implant carrying a cli-arch certificate is a sibling.

Checking in

Every check-in is a POST to /api/sync with a small JSON report:

• a random ID that changes every run;
• a short machine fingerprint (a hash of the Windows machine GUID, computer name and C: drive serial number);
• whether it is running as an administrator, as SYSTEM, or as a member of the Administrators group;
• a string of 64 to 511 random letters as padding, so the message size is never the same twice.

The hostname and username fields are literally sent as "pending". This stage doesn’t bother collecting them; it just wants to know whether the machine is worth the next step.

The first check-in happens as soon as the program starts. After that, the server sets the pace: every reply says how long to wait and how much randomness to add. This server said 60 seconds ±20%, so in practice the malware checks in roughly every minute. The built-in default of 10 minutes ±30% only matters when the server can’t be reached. Even then it backs off, doubling the wait after each failure, up to once a day.

What the server can order

The server replies with a list of "jobs". This build understands five:

Downloaded programs are never written to disk. The loader maps them into memory itself (the way Windows would load a DLL, but without Windows knowing), then calls functions named SetModuleID, StartModule and so on. Every job’s result goes back to the server at /api/update/<id>. Ask for something it doesn’t know and it replies, somewhat grumpily, "Send ‘load’ first".

We confirmed all of this by running the program in an isolated sandbox against a fake server we controlled, and feeding it each job in turn. We served junk instead of real programs, so nothing actually loaded.

What the real server said

ANY.RUN’s run scored the file zero, "No threats detected". That is understandable, because the program does almost nothing on its own. Inside ANY.RUN’s capture, though, there was a TLS key log, and with it we could decrypt the one real conversation with the attacker’s server:

• the malware sent its check-in;
• the server (a Python gunicorn web server) answered {"interval":60,"jobs":[],"variance":20}.

In plain words: "I see you, check back in about a minute, nothing for you yet." The server was alive and accepted the badge. It just didn’t hand a sandbox anything worth having.

What we couldn’t reach

The interesting part of this operation is the module and checker programs the server hands out, and we don’t have them. With the certificate from inside the malware, it would be technically possible to ask the server for them directly. That means actively contacting the attacker’s infrastructure, so we have not done it. The server may also only serve them to machines it has chosen.

We also can’t say how this file reaches victims. The "touch controller" disguise suggests it is meant to sit quietly among driver tools rather than be opened by someone on purpose.

Advice

For everyone:

• A valid signature tells you who signed a program, not that it is safe. A "Quartz Touch Controller" from a Danish company you have never heard of should be a red flag.
• Get drivers and device utilities from your PC maker’s or the device maker’s own site.

For defenders:

• Block and hunt for gitihubusercomtent[.]com and 178[.]105[.]122[.]30.
• Look for TLS servers presenting CN=srv-arch.internal / issuer CN=ca-arch. That is a much stronger signal than any single domain.
• WinHTTP traffic with the cut-off user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (no browser name after it) is unusual.
• On a suspect host, an orphaned crypto key container under %APPDATA%\Microsoft\Crypto\RSA\<SID>\ created by an unfamiliar "driver" process is worth a look.

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

IOCs

Wrapping up

QuaTouchCtrl.exe is a small, tidy stager: it is signed, it encrypts its strings, it runs payloads only in memory, and it insists on a private-CA handshake before it will talk. That last design choice is also its weak spot, because those certificates are unique fingerprints of the operation. If you come across another ca-arch certificate or a srv-arch.internal server, we’d love to hear about it.