Silicon Valley Bank (SVB) Failure Could Signal a Rise in Business E-mail Compromise (BEC)

On 10 March, Silicon Valley Bank (SVB) – a popular institution for the venture capital community in the Bay area – failed when venture capitalists (VCs) quickly started to pull money out of the 40-year-old bank, causing federal regulators to step in and shut its doors before more damage could be done. As investors and CEOs scramble to make sense of the situation, many are looking for alternative locations to store and manage their personal and company’s money ASAP. We understand that in this pressure-filled moment, many will likely take shortcuts and quickly share sensitive information on unsecured platforms, leaving malicious threat actors to take advantage through techniques like business e-mail compromise (BEC).

Currently, vendors are rushing to set up new accounts to switch payments to and scrambling to update ALL payment details for their customers so that new receivables are being sent to their new bank account versus their now defunct SVB account. These account details are being sent unsecurely over e-mail and as attached PDF’s, and the recipients are operating with urgency to get money transferred ASAP. Due to this emergency, customers are transferring substantial amounts of money into these new accounts, leaving both company and customer vulnerable to malicious activity during the process. These are the perfect conditions for threat actors to steal several million dollars (and perhaps much more!).

What is Business E-mail Compromise (BEC)?

Threat actors commonly leverage e-mail access to conduct business accounting fraud, conduct highly targeted phishing attacks, gain access to sensitive information, and elicit trusting coworkers to perform actions on their behalf. BEC is a scam targeting both businesses and individuals performing transfers of funds, according to the US Federal Bureau of Investigation (FBI). It is commonly carried out when a threat actor compromises legitimate business e-mail accounts through social engineering or computer intrusion tactics, techniques, and procedures (TTPs) to conduct unauthorized transfers of funds. In 2021 alone, BEC scams resulted in nearly 20,000 complaints and a loss of $2.4 billion. For example, threat actors have targeted the mortgage industry, specifically targeting the home buying/refinancing workflows whose employees use e-mail for nearly all transactions, usually overworked, and under trained in cybersecurity issues such as BEC.

In addition to social engineering TTPs, threat actors can also use legitimate credentials to access business e-mail within an organization to impersonate targets and garner sensitive information over unsecure/unencrypted e-mail correspondence.

We know that threat actors exploit credential requirements in many ways; they can:

• Take advantage of weak password strength requirements or weak account lockout thresholds
• Capture and then crack hashes
• Take advantage of accounts that reuse compromised credentials
• Use the default credentials that remain unchanged in a variety of web applications and systems processes

Threat actors do not often use sophisticated hacking tools and techniques to gain access to business e-mail and networks; along with social engineering techniques, threat actors don’t “hack” in, they log in with legitimate user credentials.

How does BEC work?

BEC allows threat actors to read, send, and receive e-mails under the guise of that user or many users at once. Threat actors frequently seek out their targets through open-source research like a company website or professional social media platforms such as LinkedIn to figure out whose identity they can use in the scam. Once the threat actor gains initial access, they will seek to determine their target based on who is able to send and/or receive money (Threat actors generally seek and target a junior employee who’s responsible for inputting the numbers into a bank’s portal). In a subsequent e-mail conversation, the threat actor will impersonate one of the parties by spoofing the e-mail domain and then try to solicit their target’s trust and ask them to send money, gift cards, or information. These e-mails usually contain an attached PDF with wire instructions and are often proceeded by a follow-up e-mail that says, “Sorry, use these account and routing numbers instead.”

Why does this matter?

For all intents and purposes, a threat actor using credentials looks like a legitimate user. Coupled with the absence of malware, this type of attack is extremely difficult to detect.

Over the past 6 months, only 2.5% of Horizon3.ai customers experienced BEC in their environment with proof of exploitation. However, NodeZero successfully executed credential-based attacks over 6,000 times (out of the 34,000 times in which NodeZero successfully executed an attack compromising at least one host), and to significant effect. For more detail and recommendations regarding credential-based attacks, please see our Year in Review 2022 report.

For example, NodeZero was also able to execute a BEC on a large US based security systems provider by successfully chaining the following weaknesses together (See NodeZero’s attack path below):

• Credential Dumping of Security Account Manager (SAM) Database and Local Security Authority (LSA) Secrets
• Azure Multi-Factor Authentication Disabled
• Credential Reuse and cracked Weak or Default Credentials

In this case, NodeZero found that this privileged user had the same credentials for local admin and domain user on the company’s Azure account, and from the domain user account was able to pivot laterally for further access. MFA was not enabled, so NodeZero proceeded to gain access into their Azure cloud environment and then get into Outlook. With this valid domain account, NodeZero accessed 25 business e-mails, and as proof, NodeZero showed the customer the subject lines of the e-mails it was able to access.

From here, an attacker could login legitimately as a company employee, create an email, and send it to the customer base, and in the case of a banking collapse or change of accounting, could direct the customer to change their invoicing and remit payments for vendor services to the attacker’s personal account. Both the company and the customer lose money and trust.

What can we do about it?

Horizon3.ai recommends:

• Require the use of multifactor authentication for logging into external environments and segmented networks when possible.
  • If you’re using Azure AD, you can enable Azure AD Password Protection to automatically ban well-known bad passwords.
• Assess and analyze your employee’s passwords to ensure they meet your minimum requirements
  • Institute password policies that include sophistication and length requirements as described in the latest recommendations from NIST Special Publication 800-63B. NOTE: Horizon3 recommends a 12-character (min) for users and more for privileged users, just as several other companies do.
  • When creating a temporary password for a new user or a user that requires an account unlock, require the password to be used within a specific timeframe before the account becomes disabled.
  • Do NOT allow passwords that have been in previous breaches, are contextually based on the company name, their personal name or login, or their role
  • Implement a configuration management process that directs default credentials (including and especially empty, null, or “guest” defaults) are changed before systems are deployed in a production environment.
• Implement good access controls to include the principle of “least privilege.”
• Disable the accounts of current or former employees who no longer require access.
• Always, verify that each of the above guidelines are implemented, enforced, and effective by attacking your teams, tools, and rules using NodeZero.
• And lastly, increase training for employees on basic cyber security, including the dangers of credential reuse and weak or easily guessed passwords and social engineering TTPs to look out for and avoid.