26.08.2026 11:00
Increased fraud attempts through BEC
In recent weeks, we have been receiving an increasing number of reports about criminals targeting Austrian organizations through Business Email Compromise (BEC).
In this type of fraud, criminals impersonate a trusted person (such as management, a known supplier, a colleague from the HR department, ...) in order to get employees to carry out bank transfers, change payment or bank details, or hand over sensitive information.
BEC is not a single, uniform type of attack, but rather a "family" of scenarios that all rely on identity deception. Some examples:
- Impersonation of management: Attackers pose as a senior executive and write to the finance or accounting department with a supposedly urgent, confidential request for a transfer. This is to be carried out as quickly as possible and, above all, without the knowledge of other members of the organization.
- Invoice fraud: Attackers pose as a supplier or service provider of an organization (sometimes even using the original mail accounts of a legitimate company that was previously compromised by the criminals) and send an "updated" invoice or a notice that the supplier's bank details have changed, in order to redirect a legitimate, expected payment to an account controlled by the criminals.
- Hijacking of an email thread: Attackers gain access to an email mailbox (for example, via credentials compromised by an infostealer or through a vulnerability in a web interface), covertly observe a conversation surrounding a real invoice or an actual business transaction, and subsequently inject false payment instructions into that conversation, which makes the request appear authentic.
- Data theft: Instead of (or in addition to) a monetary transaction, the attackers pose as an executive and ask the HR department for sensitive information such as payroll tax statements or employees' personal data. This data is then subsequently misused for identity theft and / or further fraudulent acts.
What distinguishes this type of attack from others is the low technical effort involved. In most cases, the attackers' main tool is a credible story and at least a rudimentary understanding of how communication normally works within companies and how the approval of financial transactions typically proceeds.
By exploiting organizational trust and internal processes in this way, this form of fraud bypasses many of the common technical protective measures that companies and organizations rely on for defense against other forms of cybercrime.
Detection
Although perpetrators act rather skillfully by now, there are certain characteristics within messages that indicate a fraud attempt is underway.
- Feigned urgency, often combined with a request for secrecy: Perpetrators try to induce stress in order to weaken the victims' vigilance - for example, by demanding that a transfer be carried out immediately and that no one be told about it, often under threat of consequences for the victim.
- Circumvention of normal approval processes: The perpetrators push to skip normal approval processes or at least to speed them up. Sometimes criminals have an intimate understanding of the targeted organization and demand amounts that fall below an internal approval threshold.
- Unavailability of the "responsible person": In their messages, the criminals claim that the person they are impersonating cannot be reached by phone, citing various reasons, so that communication takes place exclusively via digital mail.
- Sudden changes: An unexpected, unsolicited change to the bank or payment details of a known supplier, service provider, or employee is a very clear warning sign. The same applies to a sudden change in writing style within an existing email conversation.
There are also indicators on a technical level that represent grounds for suspecting a fraud attempt:
- Domain changes: A sender domain or reply-to domain that is almost, but not quite, correct (e.g. a swapped letter, an additional hyphen, a different TLD, ..)
- Irregularities in the email address: The display name in the email client is correct, but when checking the full headers, the actual email address does not match.
- Fake forwarding: An apparently forwarded email conversation that, upon inspection of the headers, actually originates from an external domain rather than from the organization's own mail system.
- Unusual logins: Logins from a new device, a new country, or from an unknown IP-address, or an unexpected password reset on an account (especially shortly before a payment instruction), are strong indicators of illegitimate activity.
Countermeasures
Unlike many other types of attacks, protective measures against BEC are primarily situated at the policy level:
- Well-documented, fixed, non-negotiable procedures should exist for financial transactions and changes to data of service providers and suppliers. It's particularly important that employees are aware that these procedures must not be overridden by supposed urgency, hierarchy, and / or demands for confidentiality.
- Every request to change payment / bank details or every urgent transfer request should be verified by phone using an already known, stored number - and never using a number provided within an "instructing" email itself.
- The four-eyes principle should apply to financial transactions, whereby one person may never both approve and execute a transfer.
- Awareness training should explicitly address the topic of BEC, since the approach here is entirely different from "classic" phishing emails.
Nevertheless, there are also measures at the technical level that, while generally advisable and valid on their own, make this type of fraud particularly difficult:
- Wherever technically and organizationally feasible, enforce modern multi-factor authentication (MFA) for all email and remote access accounts. Exceptions to these authentication measures should be viewed as highly critical within the organization's own risk management and should be avoided as much as possible.
- Apply conditional access policies (blocking access in the case of unusual geographic origin / unusual device) and set up corresponding alerting.
- Implement SPF, SKIM, and DMARC and enforce them accordingly, with DMARC set to "reject" for your own organization's domains.
- Restrict and log the creation of automatic forwarding rules, and block forwarding to external domains via policy.