The Borrowed Signature

A tax notice that got its own timezone wrong

The message impersonates the Income Tax Department, Government of India. It is bilingual Hindi and English, carries a memorandum number, cites two real sections of the Income Tax Act, and threatens prosecution within 72 hours. It is also, in several places, careless.

• TELL 01The body signs off as Raj Kumar Sharma, Assistant Commissioner of Income Tax, with a contact address at incometax.gov.in — while the message itself is sent from a free outlook.com account.
• TELL 02The Date header is +0800 and the mail is relayed through Microsoft’s Korea Central region. A genuine notice from Aayakar Bhawan, New Delhi would be +0530.
• TELL 03The text/plain alternative is not plain text at all — it opens with leaked CSS (-webkit-text-size-adjust, mso-table-lspace) because the builder dumped the HTML body through a careless converter.
• TELL 04The invented reference No. TAX/GST-IT/2026-204 and a flat 72-hour deadline supply the urgency. Sections 271(1)(c) and 276C are real, which is what makes them persuasive.

One detail deserves emphasis for anyone tuning a mail gateway: because the message was sent through a genuine Outlook account, SPF and DKIM pass. Authentication checks alone will not stop this. The signal is in the mismatch between who the message claims to be and the infrastructure that carried it.

The email carries no attachment. Everything hangs on a single link.

From one link to a signed process running attacker code

The link was still serving at the time of analysis. Each stage below was retrieved and hashed directly.

Eight kilobytes of program, a megabyte of cargo

The clearest structural signal in tax-documents8.exe is its shape. Executable code accounts for well under one percent of the file. Almost everything else is resource data.

Parsing the resource directory gives exact boundaries for what it carries. This matters: carving on MZ markers alone truncates each file at its last raw section and silently discards the overlay, producing hashes that match nothing on disk.

Three reasons the DLL is not VideoLAN’s

Both embedded files claim the same vendor. Both carry the string 1996-2025 VideoLAN and VLC Authors, both name themselves in their version resources, and both appear signed. Telling them apart takes more than metadata.

• 01Wrong toolchain. VLC ships as a MinGW build, and the bundled vlc.exe shows exactly that signature layout. The DLL carries .00cfg, a Control Flow Guard section emitted by MSVC. VideoLAN did not build it.
• 02Proxy shape. It re-exports all 316 libvlc_* symbols and then imports libvlc.dll itself, forwarding calls to the real library so VLC keeps working. It does this in 59,904 bytes of code — nowhere near enough to implement the API it advertises.
• 03The signature is borrowed. Both certificate tables are 23,424 bytes. Extracted and hashed, they are the same bytes.

One certificate, two files

The certificate blob was lifted out of each file at its recorded offset and hashed independently.

The certificate itself is real. It chains to DigiCert Trusted Root G4 and names VideoLAN in Paris, with Sectigo timestamping. Nothing about it is forged — it was simply moved.

What this cannot survive is verification. An Authenticode signature commits to a hash of the file it was issued for, so the copied blob will not validate against the DLL’s contents. But it is enough to defeat any check that asks only whether a file has a signature, or reads the publisher name out of it without verifying the digest. That shortcut appears in allowlists, in software inventory tooling, and in more than one EDR policy.

What to block, and what to leave alone

Three MD5 signatures cover the malicious files in this chain. A fourth hash in the sample must be deliberately excluded.

Hashes are the weakest layer here. The tax-documents7 and tax-documents8 naming implies a builder that has already produced at least eight variants, so these three values have a short useful life. More durable controls, in rough order:

• 01Block the domain. dajiangcq[.]com is the one indicator that survives a rebuild of the payload.
• 02Verify signatures, don’t just detect them. Flag any PE whose Authenticode digest fails to validate while carrying a well-known publisher’s certificate. This catches the technique rather than the sample.
• 03Watch for the sideloading shape. An archive that delivers a signed vendor executable together with a same-vendor DLL that is not that vendor’s build is a strong pattern on its own.
• 04Tune mail on mismatch, not on authentication. SPF and DKIM pass here. Government-authority impersonation from consumer mailboxes, bulk-mailer artefacts, and timezone-to-claimed-origin mismatches are the usable signals.

Indicators

URLs are defanged. Hashes are MD5 unless marked otherwise.