Email Forwarding to Stop BEC Attackers (2nd December, 2020)

Ref# Block | Date: Dec 2nd 2020


Cybercriminals are exploiting an email forwarding vulnerability on webmail platforms to make BEC (Business Email Compromise) attacks more prosperous.

It is reported that auto-forwarding rules are commonly used in BEC scams once attackers have compromised an employees inbox. This means that emails with specially chosen keywords like bank and invoice are automatically sent to the attackers inbox. That attacker can then monitor the communications between the employee and other users. Eventually the attacker steps in, assumes the identity of a legitimate contact and sends a fake invoice to be paid by the employees company.

How to prevent this?

To mitigate this issue, it is recommended that:

  • IT administrators sync staff web and desktop email clients. If this is not done, then auto-forwarding rules updated by an attacker will only appear on the web-clients end. This means that security teams will have no idea that a scam is in progress.
  • Administrators ensure the web email clients and desktop clients are running the same version to enable easy syncing and updating.
  • Administrators prohibit automatic email forwarding to external addresses and to monitor for suspicious behavior such as any last-minute changes to established email account addresses.
  • Administrators flag emails where the sender and reply-to addresses are different.
  • Administrators enable multi-factor authentication for employees to prevent intruders from accessing email accounts.

The Guyana National CIRT recommends that users and administrators review these recommendations and implement where necessary.


  • BEC Scammers Using Auto-Forwarding Rules in Web-Based Email Clients to Prevent Detection. (2020, December 2). Retrieved from Netsec News:
  • FBI: Block Email Forwarding to Stop BEC Attackers. (2020, December 02). Retrieved from The Cyber Security News:
  • Muncaster, P. (2020, December 2). FBI: Block Email Forwarding to Stop BEC Attackers. Retrieved from InfoSecurity Magazine: