BEC Attacks: How Fake Invoice Schemes Work
According to Agari’s Business Email Compromise (BEC) Attack Trends Report, 96% of companies experienced BEC attacks in the second half of 2017, mainly because the email-borne attacks didn’t include the usual attachment-based virus but comprised a radically more sophisticated form of social engineering. One version of BEC that has helped cyber criminals net over $5 billion is the bogus/fake invoice scheme.
According to the FBI, the bulk of the funds generated via BEC attacks (including the ones involving fake invoice schemes) are transferred to China and Hong Kong, from where they’re diverted to other financial firms — or in other cases, casinos. The agency also revealed the use of British banks is on the rise.
If recipients clear the invoice, their company loses funds (and the victim is at risk of losing his/her job). If they get in touch with the adversary, the scammer uses a variety of psychological techniques to add trustworthiness to their claim, ranging from citing additional email threads to having a telephone call, to try and convince the potential victim to clear the invoice.
Fortunately, it’s possible to prevent BEC-based fraudulent invoice schemes from causing harm. The counter requires having a good understanding of how bogus invoice schemes function.
The scheme usually begins with a fraudster breaching the email of an individual who has the authority to manage their company’s finances, for instance, someone working in payroll. The adversary then navigates the victim’s email, searching for vendor invoices until he/she comes across a legitimate invoice.
Once a legitimate invoice is found, the hacker modifies the detail of the beneficiary, such as altering the routing number to which the amount needs to be credited.
The criminal then spoofs the vendor’s address to submit the invoice. The email says the vendor has updated its payment terms (Read more...)
*** This is a Security Bloggers Network syndicated blog from InfoSec Resources authored by Dan Virgillito. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/Cy6rLEdqdb4/