How to recognize Phishing when the story looks (too) real

A job interview.
A request from a government agency.
A message about keeping your money safe.

None of these needs to look suspicious at first glance, and that is precisely the problem. To recognize phishing, today, people need to look beyond spelling mistakes and unfamiliar logos, they need to recognize when a credible story is being used to justify a dangerous action.

The recent Binance and Revolut cases bring that distinction into focus. The circumstances differ right, but both raise a question organizations should rehearse before a real incident: what happens when the request looks like part of someone’s job?

Binance: when a job interview becomes an entry point

On 30 October 2026, Binance reported a compromise of its hot wallets involving approximately $6.3 billion in token assets. Its initial statement described “an ongoing investigation and multiple points of compromise“.

In a 3 November briefing, the company described a recruitment approach involving a software engineer. According to CoinDesk’s reporting of the briefing, attackers used a legitimate job platform, staged interviews and persuaded the engineer to download a coding assignment onto a work computer. Binance said the assignment contained malware.

This is the company’s account of part of a wider attack chain: it does not establish that one employee’s decision, by itself, explains the incident.

So, for awareness training, the relevant moment is the coding assignment, where a developer may reasonably expect one during recruitment. The attacker’s task is to make running untrusted software feel like the ordinary next step.

Revolut: a real domain does not authorize a request

A separate incident reported in September 2026 involved fraudulent requests for Revolut customer information sent from an email account on a legitimate government agency domain.

In a statement reported by The Block, Revolut described external impersonation affecting a limited number of customers. Potentially disclosed information included identity documents, contact details, account statements and transaction histories – the company said its systems and customer funds were unaffected and that it had blocked the email address and notified the relevant authorities.

This distinction matters: this was a disclosure of customer information following fraudulent requests, rather than a reported theft of customer funds.

A genuine domain can support a sender check, actually it cannot, on its own, prove that the person making a request has authority to receive sensitive information.

Why familiar phishing advice can leave a gap?

Checking the sender and inspecting links remain useful habits: you can see the gap appears when those checks become the whole decision.

A recruitment conversation can take place on a genuine platform and a fraudulent request can arrive through a legitimate domain; also, a familiar name can be attached to instructions that would never survive an independent check.

Phishing uses deceptive communications to induce actions such as disclosing credentials or opening malicious content. Social engineering is the broader manipulation behind these and other attacks, including attempts to obtain information or authorize payments. Recognizing the mechanism helps people respond when the channel or pretext changes.

The useful question is stunning concrete: what am I being asked to do, and what independent evidence makes that action safe? That question travels better than a mental picture of a badly written email..

So, how to recognize phishing before taking the next step?

Pay attention to the moment a conversation asks you to cross a boundary: from discussing a role to executing code, from receiving a request to releasing records, or from checking an account to authorizing a transfer.

These actions deserve a verification step proportionate to the risk:

• running unfamiliar software: a coding exercise or troubleshooting tool should not gain automatic permission to run on a work device because the conversation around it feels professional. Use your organization’s approved process for assessing and isolating untrusted code, and if you’re unsure, stop it all and ask your IT;
• releasing sensitive information: verify the requester’s identity, authority and scope through an established process. A credible signature or genuine domain does not answer all three, and if you’re unsure, push back;
• sharing authentication material: never ever give an unsolicited contact your password, recovery phrase or one-time code. Read authentication prompts carefully and reject actions you did not initiate, and if you’re unsure, stop it all and ask your IT;
• moving money to “protect” it: stop and contact the institution through a route you already trust. Do not use contact details supplied in the suspicious conversation, and if you’re unsure, push back and ask your HR.

For Binance users, Binance Verify offers a way to check claimed official sources, its own notice makes a useful distinction: verifying a source does not authorize an action. Independent verification needs a separate route: calling a number in the same message simply continues the conversation on the attacker’s terms; we’ve already shown this in out first “Superfici Invisibili” live event in Turin.

Phishing readiness needs practice inside *real* workflows

For a CISO or HR leader “our employees completed the course” leaves a practical question unanswered: could they interrupt a convincing request while trying to finish their work?

A useful phishing simulation gives people a recognizable situation and a safe way to challenge it. Finance should practice changes to payment instructions, developers should encounter recruitment and software-installation pretexts, and teams handling sensitive records should rehearse requests that appear to carry institutional authority.

Include legitimate requests in the learning process too because people need to learn how to verify and continue working, rather than treating every unexpected message as an incident.

Then look beyond clicks.
Measure whether people reported the request, used an independent verification route and avoided the consequential action.
Check whether the security team responded in time to help, a reporting button is only useful when someone owns what happens next.

Training also needs technical support: controls on software execution, access restrictions, stronger authentication and independent approval for sensitive actions. People should have permission to pause, and systems should limit the damage when someone gets through.

What this means for Baited

At Baited, we build phishing simulations around the context an attacker could use to make a request believable. Public information about an organization, its people and its suppliers can provide the raw material for a convincing approach.

The training opportunity sits at the point where that context turns into an instruction, so rehearsing that decision lets teams examine both the person’s response and the process available to support them. We do believe a simulation should leave someone better prepared for the next conversation, with a verification habit they can actually use.

Next: the Fideuram case, in our Italian-language webinar

We will continue this conversation in our upcoming Italian-language webinar with Giorgio Scura of Decripto and Indago and Riccardo Masutti (our CEO), joined by guest Raffaele Angius of IrpiMedia, who will examine the Fideuram case.

Join us to look at how a convincing request becomes a consequential decision, and where there is room to interrupt it. Being ready starts before the message arrives: https://dixdecripto.github.io/seems-legit/