The help desk caller who wasn't: *how vishing works* when attackers know your name

The attack that needs almost nothing

Vishing, short for voice phishing, is a confidence trick carried out over the phone. The attacker pretends to be someone the target ought to trust—a colleague, a manager or, in this case, someone from IT support.

In the incidents Cisco Talos described, the attackers found names and email addresses on company websites, LinkedIn profiles and similar public sources ^[1]. They then called employees, introduced themselves as IT help desk staff and asked the employee to open a remote access session to fix an urgent problem. In one case, the employee did, and the attackers used that access to deploy ransomware ^[1].

It's like someone calling your mobile, saying they're from your bank and asking you to confirm a transaction by reading out a code. The difference is that corporate help desks often do call employees, so the request doesn't sound odd.

Why it keeps working

The attacker's opening move is cheap and simple: a name, an email address and a plausible story. Most organisations have processes for verifying inbound calls from customers, but fewer have equally strict processes for calls that staff receive, especially when the caller claims to be from the same organisation.

The second reason is that remote access tools are ubiquitous. IT teams use them every day to help employees, so the request to open a session sounds reasonable. By the time the employee realises something is wrong, the attacker is already inside the network.

The third reason is that logs of phone calls, remote access sessions and user actions are often kept in separate systems, none of which is designed to answer the question that comes up afterwards: did this person really call that employee, did the employee open a session during that call, and if so, what did the attacker do?

The evidence question

When an incident like this happens, the organisation needs to reconstruct what took place. That means checking call logs, remote access logs, authentication logs and possibly chat or email records, and then trying to line them all up.

The harder question is whether those logs can be trusted. If they're kept in systems that administrators can edit, an attacker with enough access could change them. Even if no attacker touches them, an organisation whose logs can be quietly altered may struggle to convince a supervisor, an insurer or a court that the logs are complete and unchanged.

Under Sweden's Cybersecurity Act, which came into force on 15 January 2026, essential and important entities in 18 sectors must report significant incidents in stages: an early warning within 24 hours, an incident notification within 72 hours and a final report within a month ^[2]. That 24-hour clock starts when the organisation becomes aware of the incident, not when it's convenient.

If the logs themselves are questioned, meeting those deadlines becomes harder.

How a digital witness fits here

A digital witness seals records as they are created, so that any later change shows up. In a vishing case, the things to seal are call logs, remote access session records and authentication events.

Here's how it would work. Each time a remote access session starts, the system writes a record with the employee's username, the session ID, the start time and the caller's claimed identity. That record is sealed immediately by taking a fingerprint of it—a short string of characters calculated from the content—and sending that fingerprint to WitniumChain. The content itself never leaves your systems. You get a witness ID back, which you store alongside the record.

Months later, if someone asks whether that record has been tampered with, anyone you share it with can calculate the fingerprint again and compare it with the sealed one. If they match, nothing has changed. Change a single character and the fingerprint won't match.

A digital witness doesn't prevent vishing, and it doesn't tell you whether the caller was genuine. What it does is give you a checkable record of what your systems logged at the time, so that when you're asked to show what happened, you can.

You can seal records through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. Full documentation is at witniumchain.com/docs.

How it would work

1. Your remote access system writes a session record and seals it with WitniumChain as the session starts.
2. You store the witness ID with the record.
3. When the record is questioned, you or anyone you share it with can check that it hasn't changed.

What this means for you

If your organisation uses remote access tools and has staff whose names and email addresses are public, these questions are worth asking:

• Do you have a process for verifying inbound calls to staff, not just from staff?
• Can your IT team show, months later, exactly who opened a remote session, when and on whose instruction?
• Are your call logs, remote access logs and authentication logs kept in a way that makes it clear whether they've been edited?
• If you had to report a significant incident within 24 hours, would your logs hold up to scrutiny?

Vishing works because it exploits trust and moves quickly. The defence is partly training—teaching staff to verify unusual requests—and partly logging, so that when something goes wrong, you know what happened and can show it.

What to watch

The Cybersecurity Act's reporting deadlines are already in force. The AI Act's logging requirements for high-risk systems in Annex III apply from 2 December 2027, though they don't directly cover vishing ^[3]. The broader point is that logs are moving from a technical afterthought to a compliance and evidential necessity, and that means they need to be protected as carefully as the data they describe.