HSBC Breach Apparently Caused by Credential Stuffing, or Not

Elections may have obscured reports that HSBC Bank, one of the largest financial services organizations in the world, confirmed a data breach occurred between October 4-14 affecting its U.S. customers’ information.

HSBC believed fewer than 1% of its American clients were affected. The Telegraph reported HSBC manages about 1.4 million U.S. accounts. But attackers accessed a glut of personal information including account numbers and balances, statement and transaction histories, payee details, names, addresses and birth dates.

Most cybersecurity experts said the incidents look like credential stuffing where attackers use stolen account credentials harvested elsewhere.

The bank said it immediately suspended online access to affected accounts and was not aware of any customers who had suffered financial loss.  A spokesman for the bank said: “HSBC regrets this incident, and we take our responsibility for protecting our customers very seriously.” This is just the latest security incident reported by HSBC, which experienced DDoS attacks in January and July 2016.

Some breach victims live in California; HSBC filed a notice of a data breach with California’s state attorney general office, dated Nov. 2, that it’s been sending to state residents, as it’s legally required to do.

Even community institutions such as credit unions can learn from this type of cyberattack.

Jacob Serpa, product marketing manager, at Campbell, Calif.-based Bitglass, said, “As one of the world’s largest banking and financial services organizations, consumers trust HSBC with the well-being of their information. The attackers are believed to have gained unauthorized access to the compromised accounts from credential-stuffing attacks.” Serpa suggested the attack could have been prevented if HSBC used dynamic identity management solutions that can detect potential intrusions, require multi-factor authentication, and integrate with existing systems for managing user access.

“The most seasoned and well-resourced security teams can be easily overwhelmed by the volume of organizational alerts they receive in a day,” Stephen Moore, chief security strategist, San Mateo, Calif.-based Exabeam, held. “That complexity, when combined with the inherent difficulties of detecting credential-based attacks, because the attackers are impersonating legitimate users, creates an environment that lacks control and trust,”

Moore stated, “To remediate incidents involving user credentials and respond to adversaries, the key is to move fast and consider an approach that is closely aligned with monitoring user behavior — to provide the necessary visibility needed to restore trust, and react in real time, to protect user accounts.” This should include the ability to detect, using behavioral characteristics.

Bryan Becker, application security researcher, San Jose, Calif.-based WhiteHat Security is not sold on the attack cause. “From the organization’s point of view: credential stuffing seems like a suspicious explanation for a bank-account breach. Generally speaking, banks require some sort of two-factor authentication, and that should stop any credential stuffing attack in its tracks. This begs the question of either: Why wasn’t HSBC using two-factor authentication, OR (if they were) what was the real cause of the breach?”

Becker also suggested the best solution is to use a password manager and have a different login for every site.” He also said organizations can also enforce two-factor authentication and check users’ passwords against a database of previously leaked passwords in order to prevent reuse as recommended by NIST.

Oscar Tovar, vulnerability verification specialist, WhiteHat Security, maintained “An attacker can brute force passwords by first gathering a list of potential victims, which happens when attempting to use a register account function or reset password function.” Tovar also held an attacker may then compile a list of valid usernames to proceed to the next step, an attempt to brute force their login. “If a web application does not have any form of anti-automation put in place, then this leaves them exposed to this kind of attack.”

Some possible remediations, Tovar suggested, never expose any customer information in any shape or form without proper validation such as through a password reset functionality such as by asking for the username of the account requesting the password reset. Organizations can also use anti-automation methods such as blacklisting IP addresses with a large number of requests sent in a small timeframe, locking an account with multiple failed login attempts, or the use of a CAPTCHA.”