You owe a supplier money. An email arrives with payment instructions. The purchase is real, the supplier is familiar, and paying them is part of your job.
An attacker impersonating that supplier has an existing transaction to work with. The request comes with a reason to take it seriously.
Government-service impersonation uses a different kind of familiarity. A message names a service you recognise and asks you to complete a step. Before you examine the sender, you may already be thinking about the task.
Two cases in Excera’s scam directory show how these approaches unfold.
Behind the fake Absher page
CloudSEK documented a campaign that directed recipients to an imitation of Saudi Arabia’s Absher portal. Visitors were led through a supposed verification step and then to bank login pages.
The counterfeit portal accepted any four-digit code. A person could enter a meaningless number and still move forward through something that looked like verification.
Read the case and its sources.
The sequence is useful to study. The attacker used the identity of a government service to introduce a request for information. The recipient had to judge whether those steps belonged to the service they thought they were using.
The payment was real. The destination was wrong.
In a case involving a cement buyer in Dubai, Bernama reporting carried by Malay Mail described police allegations that a lookalike supplier email diverted a payment to a Malaysian account.
Read the case and its sources.
The alleged fraud concerned an existing purchase. The attacker sought to redirect money the buyer already intended to pay.
That gives us a specific decision to examine: what would make someone accept those payment instructions as the supplier’s own?
Could the Same Attack Work at Your Company?
At Excera, we start with what an attacker could know. A publicly disclosed supplier relationship, a procurement manager’s name or information about payment authority could help someone construct a credible approach. Regional institutions, language and communication habits help determine how that approach should be assessed.
We connect those details with documented attacker methods to form a hypothesis about a particular organisation or role. Knowing who approves payments gives an attacker something to work with. It tells us nothing conclusive about whether that person would approve a fraudulent request.
The current product already matches documented attack patterns to a person’s role, sector, region and authority. It presents a tailored scenario, records how the person chooses to respond, and shows the possible consequences alongside the method behind the attack. Someone whose identity is being impersonated can also consider how their team should handle requests made in their name.
The next layer we are building brings together public information about an organisation and its people, emerging attacker methods and relevant events. We want to identify which attack deserves attention, who could face it and when the circumstances might make it especially plausible.
We would then test that hypothesis through an authorised, safe simulation and compare what happened with what we expected. An apparently strong attack opportunity might meet a person who questions it immediately. That result should change the assessment.
The existing research can be inspected now: explore the cases and their sources in the Excera scam directory.
Sources
Excera analysis, based on the reporting linked below.