TL;DR: 

  • What happened: A threat actor posed as a customer in DigiCert’s support chat and sent a ZIP file disguised as a screenshot of an error, but contained a malicious Windows screensaver executable (“.scr” file) that infected a support analyst’s machine.
    • The compromise ultimately led to 27 stolen code-signing certificates being used to sign malware as legitimate until the certificates could be rotated.
    • Endpoint security blocked fourth attempts, but the fifth try was what breached Digicert.
  • The social engineering angle: “Here’s a screenshot of the error I’m seeing” is the most normal request a support rep will ever get.
    • The effective attack bypassed technical controls to weaponize the exact behavior the support rep is hired to perform.
    • This attack is extremely similar to another year-long attack against HR reps and hiring managers (“Resume lure delivers ‘BlackSanta’ control killer”)
  • This attack will be effective against more than just customer service reps! Extend the lesson of “unexpected file types are risky” to anyone in your organization who consistently receives images or files from outside your environment, including:
    • Insurance claims and mortgage adjusters
    • HR and talent acquisition
    • Legal and compliance staff
    • Sales and marketing teams
    • Engineering and developer teams
  • What employees can do:
    • Treat unexpected file formats as the red flag, not the sender’s tone.
    • Stop, verify, and escalate when a “screenshot” arrives as a ZIP, .scr, .iso, .img, .lnk, .vhd, or .hta.
    • Push file-sharing back into your official intake channel — that’s where the scanning lives.
  • Check out ‘One ish, two ish: How to prevent modern phishing‘ for more on the social engineering patterns that bypass traditional phishing defenses.

RiskyBusiness: DigiCert’s tech support team got caught by a fake customer screenshot

Risky Business and DigiCert’s preliminary post-mortem on Mozilla’s CA Program Bugzilla disclosed a breach last week that any organization with a customer-facing support team should sit up for.

On April 2, 2026, a threat actor contacted DigiCert’s support team via a customer chat channel and delivered a ZIP file disguised as a customer screenshot. Inside the ZIP was a “.scr” file: the Windows file format used to install and configure screensavers, which Windows happily executes when opened. 

CrowdStrike and DigiCert’s other endpoint controls blocked four delivery attempts. The fifth one landed on a support analyst’s workstation.

The attacker maintained access to that first endpoint for less than a day before DigiCert’s Trust Operations team detected and contained it. 

But a second compromised endpoint stayed live for almost two weeks: not because the attacker was especially clever, but because that machine’s EDR agent had been misconfigured and was no longer connected to its central management server. Nothing was watching.

During that two-week window, the attacker accessed open support tickets for EV (Extended Validation) code signing certificates DigiCert was in the process of approving. They harvested initialization codes — the customer-side credential that, paired with an approved order, lets you actually obtain the certificate. 

With both pieces, the attacker walked out with EV code signing certificates issued in real customers’ names.

DigiCert revoked all 60 EV certificates processed during the attack window, but 27 of them had already been used to “sign” malware to other computers attesting that the malware was actually a benign software, tricking security tools and leading to other compromises.

DigiCert called itself lucky. A third-party researcher noticed the abuse and reported it back, which is how the company found the compromised support accounts in the first place.

The attack didn’t just beat a security control. It exploited vulnerabilities in the human attack surface that sits in front of the security control. In this case? It was the support analyst, whose entire job is to look at customer-supplied files and figure out what went wrong.

How attackers packaged DigiCert’s “screenshot” lure

The lure here is almost too clean. Walk through the attack from the support analyst’s seat:

  • A customer pings the support chat channel. This is normal. This is the job.
  • They describe an error and offer to send a screenshot. Also normal. 
    • Support reps ask for screenshots all day. They’re often the fastest way to diagnose what a customer is actually seeing.
  • The attachment arrives as a ZIP. Slightly unusual, but not alarming. 
    • Customers compress files for all kinds of reasons, like file size, multiple images, or “my IT told me to.”
  • Inside the ZIP is a .scr file. This file type is the only red flag, but it’s a quiet one. 
    • “.scr” is the Windows screensaver file format, and Windows treats it as an executable. Opening it runs code. 
    • Most support analysts have never been told to look for “.scr” executables, because it’s not on the typical malicious-attachment list (“.exe”, “.bat”, “.zip”-with-macros, etc.).

That’s the whole social engineering chain. No urgency. No spoofed executive. No fake invoice. Just a totally normal-feeling customer request, packaged in a file format the analyst was never trained to suspect.

(Worth saying out loud: the support rep who clicked didn’t fail. The rep was doing their job. The control gap is that the file format itself wasn’t being treated as the warning signal — and four prior attempts had already been blocked silently by EDR, so the rep had no reason to think anything unusual was happening.)

Employees most at-risk of similar customer-impersonation file attacks

Customer support is the obvious vulnerable cohort — but the underlying pattern (a stranger sends you a file as part of a normal workflow, and your job depends on opening it) extends much further. 

Run the lens across any role where inbound files from outside the organization are part of the daily rhythm.

Vulnerable employee cohorts to customer-impersonation file attacks

Details
Customer support, helpdesk, and call center reps Job literally is to receive and inspect customer-supplied files. Often work in chat-based channels with limited file scanning.

And remember: your employees don’t see the four blocked attempts on your security dashboard; they just see the fifth attempt that got through. For security, it’s a pattern. For the employee? It’s the first time they’ve seen it.
Claims adjusters and intake coordinators (insurance, banking ops) Receive damage photos, statements, supporting documentation from claimants every day — exactly the “customer sends you files” pattern, often through inbound portals or email rather than scanned channels.
Legal and compliance staff handling external discovery, contracts, or vendor materials Routinely accept files from outside counsel, vendors, and counterparties via email, secure file shares, or “quick” Dropbox/Drive links when the official intake is too slow.
Procurement, vendor management, and finance AP Receive invoices, statements of work, and supplier documentation from external counterparties constantly. Often willing to accept “just send it over chat or email” when a vendor says the portal isn’t working.
Sales and customer success Routinely accept prospect-supplied RFPs, requirements docs, and “quick examples” via email and chat. The implied pressure to be responsive makes “let me check whether this is normal” feel like friction.
Engineering and developer relations on external-facing teams Receive bug reports, repro files, “here’s the crash dump,” and other artifacts from external developers and customers — often in archive formats.

Toxic combination flag: When customer-touching roles also have elevated system access, a single compromised endpoint becomes an outsized blast radius. So think:

  • CA tech support
  • IT helpdesk with admin rights
  • Claims adjusters who can release payouts
  • Legal staff with M&A document access

DigiCert is the textbook example: two compromised support reps led to 60 customer accounts touched and 27 certificates abused.

How customer-touching teams can spot similar DigiCert malicious file attacks

The remediation isn’t “stop opening files.” That’s not a real instruction for someone whose job is opening files. The real remediation is teaching people to read the file format itself as a signal.

  • Treat unexpected file formats as the red flag, not the sender’s tone or urgency. A polite customer with a normal-feeling ask can still be the attacker. The file format is the more reliable signal. 
    • If a “screenshot” arrives as a ZIP, that’s already strange. 
    • If a file inside is .scr, .iso, .img, .lnk, .vhd, .hta, or .one, stop.

  • Push file-sharing back into the official intake channel whenever you can. 
    • The official channel (e.g., the careers portal, the support ticket attachment system, or the procurement upload form) is where the file scanning, format restrictions, and sandboxing actually live. 
    • Shadow channels (e.g., LinkedIn DMs, customer chat attachments, “I’ll just Dropbox you the link”) exist for convenience and speed. Convenience and speed are exactly what this attack exploits.

  • If a file has to come through a non-official channel, ask the sender to upload it to your standard intake. 
    • Yes, this adds friction. The friction is the security control. The friction is by design.

  • If you have to open it, get a second pair of eyes from your security team first. 
    • DO NOT DOUBLE-CLICK IN THE MOMENT. 
    • Particularly if it’s an archive (ZIP, RAR, 7z), because you can’t know what’s inside.

  • Report blocked attachments to security, even if you think a security tool already caught them. A blocked attempt that nobody knows about is a blocked attempt that doesn’t help the rest of the team. 
    • DigiCert’s analysts were targeted four times before the fifth one landed. A single “hey, this got blocked, FYI” message could have changed the outcome.

Curious how to build social engineering training that actually accounts for the channels and file formats your customer-touching teams really use? Check out “One ish, two ish: How to prevent modern phishing” for the full playbook on impersonation attacks and how to teach people to spot them.