BEC Fraud (Business E-mail Compromise) has reached epidemic levels in recent years. In 2019, the FBI’s Internet Crime Compliant Center, reported that it received complaints with adjusted losses of over $1.7 billion from this type of scam. The reported cases to the IC3 is just a drop in the bucket compared to the overall amount of incidents online. Considering nothing dramatic has changed in the cybercriminal world, it can be assumed that in 2020 and 2021, the numbers are the same, if not worse.
The scam has a few variants in how it is executed and in its technical sophistication. The majority of the cases involve invoice scams, in which the fraudster masquerades as a vendor, sending the victim’s CFO or account payable team a request for payment with an updated bank account information. In term of sophistication, the scam ranges from involving an actual compromised E-mail account of the vendor, the use of a similar domain that impersonates the vendor’s, to a simple well-crafted E-mail message. In all variants, the attacker hopes for the victim to fall for the bait and issue a wire transfer.
The reason why BEC fraud has become immensely popular is due to its high success rate despite the low bar of entry, at least for the less sophisticated variants of the scam. The reason why the success rate is so high is because CFOs and account payable teams don’t have a quick and easy way of validating that the account information they currently have for a vendor is indeed legitimate.
As the anti-fraud industry is beginning to catch up with the threat and BEC fraud detection solutions enter the market, these are premium services that are limited by the specific anti-fraud vendor’s data and visibility. As the scam targets many smaller organizations as well, and as we live in a globalized world in which vendors can be from any country where a vendor’s data may be incomplete, a different type of solution is needed.
In this column I am suggesting a free and open source solution for BEC fraud. The solution provides companies the choice of privacy and control levels by enabling them to either use it as a SaaS service offered by third parties for ease of use or to set up their own infrastructure. The suggested solution is a standard which enables organizations to quickly and securely validate the bank account information of companies before they send payments, while also enabling anti-fraud vendors to collect much needed threat intelligence on on-going scam campaigns.
This can be achieved through a Distributed Account Information Certification, or DAIC for short.
With DAIC, every company can place its account number, in which it receives payments from customers, into a “certification server” of its choosing.
When an entity wants to send money to that company, it can then query the server using a DAIC client to check whether the account information they have on file is the same as the “certified” account information stored on the server.
By validating the account number prior to sending payment, if the payment was done due to a fraudulent invoice that has been received from a scammer, one which contains a different account number, it will be identified and the payment could be stopped.
As DAIC is open source and works with a standard protocol, this validation process could be done using a dedicated open source software or be embedded into any payment solution.
How it works
DAIC uses tried-and-tested methods used in other security standards, such as DMARC (Domain-based Message Authentication, Reporting & Conformance).
Each company adds to their DNS records a record indicating the DAIC server of their choice. When a client is used to validate an account number, the user enters the payment recipient’s account number and domain name. It then looks for a DAIC DNS record of the provided domain in order to extract the location of the DAIC server. The server is then queried to validate if the account number is accurate.
Benefits of DAIC
This concept provides several benefits.
• It’s free. As BEC fraud targets smaller organizations as well as large ones, it can be used to improve everyone’s ability to protect themselves from the scam without impacting their bottom line. It also means that adopting this standard should be easier.
• It’s a standard. As the solution does not rely on a specific vendor’s visibility into account information, it can work well across geographies and industries if adopted. Furthermore, as noted, it can be embedded into existing payment management solutions.
• As it is open source, companies can decide whether to set up their own DAIC server, which would exclusively hold their account information, or use a SaaS service. There is an incentive for anti-fraud vendors to provide such services as theoretically it can help them capture any queries with wrong account numbers, generating threat intelligence.
• DAIC doesn’t need to be adopted by everyone to work. Companies can demand that their vendors implement DAIC in order to receive payments from them. Even without mass adoption, they would be protected.
• Any attempt to disrupt the validation process, by performing DDoS attacks on DAIC servers, for example, would be counterproductive to attackers, as their payment requests would not be validated.
Limitations of DAIC
DAIC isn’t an infallible system. It is exposed to some forms of attacks, such as gaining a company’s DNS management rights (for example, by obtaining registrar credentials using malware), enabling attackers to redirect DAIC queries to servers they control. Alternatively, attackers can take over the server currently used by a company and poison its data.
Despite some limitations, implementing DAIC still raises the bar of the technical level necessary to pull off a successful BEC fraud, taking many of the unsophisticated fraudsters who are currently performing these scams out of the game, dramatically reducing the overall losses experienced by BEC fraud worldwide.
At what stage is DAIC right now?
DAIC is still in its infancy, the product of a thought experiment in how to prevent BEC fraud. For it to become a tangible solution, the concept should be expanded and its details defined.
A proof-of-concept has been developed, an initial prototype of a server and a client, both are available on Github.