What happened
The New York State Department of Financial Services found that, starting the afternoon of 14 July 2020, attackers called Twitter employees claiming to be from the company's IT help desk and directed them to a fake VPN login page. Some employees entered credentials there and approved the resulting multi-factor prompt, believing it was their own login. That first compromised account did not have access to Twitter's internal account-management tools; the attackers used it only to study Twitter's internal systems until, on 15 July, they reached employees whose accounts did have that access. Through the morning and into the afternoon the attackers used the tools to take over accounts, and from mid-afternoon hijacked verified accounts belonging to public figures and cryptocurrency companies to post a bitcoin scam that took in roughly 118,000 dollars. A screenshot of one of the internal tools, showing simple account-status toggles, circulated publicly during the attack. Twitter's own shareholder letter, filed with the SEC eight days later, acknowledged the security issue and described steps to improve resilience against social engineering. The regulator's report also records that Twitter had not had a chief information security officer since December 2019 and that more than 1,000 employees held access to the tools the attackers reached.
Confidence and limits
The regulator's report is based on subpoenas, interviews and document review, and its account of the timeline, the vishing method and the access-control gaps is treated here as authoritative. Twitter's own SEC filing corroborates that a security incident occurred that week but does not itself detail the mechanism. A contemporaneous technical write-up is cited only for its description of the posted screenshot; it supports no figure or date used here, which come from the regulator's report.
Why it mattered
The intrusion used no malware or software exploit, only a phone call and a convincing fake login page, yet it reached tools with the power to alter any account on the platform. It foreshadowed a pattern that recurred later against other companies: attackers targeting IT help-desk trust rather than technical vulnerabilities, with broad internal access turning one compromised employee into a platform-wide incident.
Defensive takeaway
Restrict which employees can reach account-takeover-capable admin tools to the smallest group that needs them, require hardware security keys rather than phone-approved prompts for that access, and give help-desk staff a documented way to verify a caller's identity that cannot be satisfied with personal details an attacker could have gathered.
- How many of our employees can reach a tool capable of resetting another user's credentials or multi-factor authentication?
- Would our multi-factor authentication resist an attacker who tricks an employee into approving a login they did not start?
- Do our help-desk procedures verify a caller's identity in a way that cannot be satisfied with publicly available information?
The case is now closed as a matter of regulatory record, but its lesson is not about Twitter specifically: any organisation that concentrates powerful account or data access behind a phone-verifiable help-desk process carries the same exposure, regardless of its size or technical sophistication.