On 15 July 2020, attackers took over 130 Twitter accounts after phoning employees, posing as IT support, and getting them to enter credentials on a fake VPN page. The New York Department of Financial Services found no malware and no exploits. The lesson is about access to internal tools, phishing-resistant authentication and remote work.
Almost everything here comes from one source: the October 2020 report of the New York State Department of Financial Services (DFS) on its investigation. Where the report relies on allegations, we say so.
What happened and when?
The DFS report describes three phases over roughly 24 hours.
- Social engineering. On the afternoon of 14 July 2020, one or more attackers called several Twitter employees claiming to be from the IT help desk, responding to a reported VPN problem. Since the move to remote work, VPN problems were common. The callers directed employees to a phishing site that looked like the real VPN page and sat on a similarly named domain. As an employee typed credentials into it, the attackers entered them into the real site at the same time, which triggered a multi-factor request that some employees approved.
- Exploring. The first compromised employee did not have access to the internal account tools. The attackers used that access to browse internal sites and learn how systems worked. On 15 July they targeted employees who did have access to the tools.
- Account takeover and the scam. Between about 3 a.m. and 10 a.m. on 15 July, the report says the attackers allegedly discussed taking over and selling short account names. Just before 2 p.m., they hijacked accounts and tweeted screenshots of an internal tool. Then came a bitcoin giveaway scam from high-profile accounts. The report says Twitter's public acknowledgement came at about 5:45 p.m.
The report's counts: 130 accounts were compromised, 45 were used to send tweets, data was downloaded from seven through the "Your Twitter Data" tool, and Twitter believed that for up to 36 of the 130, the attackers also accessed direct message inboxes. The report says the attackers stole approximately $118,000 worth of bitcoin.
What were the root causes, according to DFS?
- No CISO. Twitter had not had a chief information security officer since December 2019, seven months before the incident. DFS called leadership a common source of cybersecurity weakness.
- Remote work without compensating controls. Twitter moved to remote work in March 2020, and DFS says it did not implement significant compensating controls afterward.
- Broad access to powerful tools. Internal tools could change the email address, reset passwords and disable multi-factor authentication on any user's account. After the incident, Twitter further limited the number of employees with access.
- Phishable multi-factor authentication. Twitter used app-based approval prompts. The report says the attackers got past them by convincing employees to approve. It states that a physical hardware security key would have stopped the attackers, and that Twitter was moving to hardware keys.
- Weak response to the human factor. Some employees reported the calls to internal fraud monitoring, and at least one employee believed the attackers. The report found no evidence the employees knowingly helped.
What is the framing of the attackers?
The report calls the technique "vishing," social engineering by phone, and says the attackers used basic techniques "akin to those of a traditional scam artist." It notes they researched employee functions and titles to make their calls convincing. The report also says between January and July 2020, about one third of significant cybersecurity incident notices filed with DFS involved phishing or vishing. The report describes a 17 year old hacker and accomplices, and it uses the word allegedly for parts of what they did.
What should defenders take from it?
These are our reading of the report.
- Treat any internal tool that can reset another user's credentials as crown jewels. Restrict who can use it, require stricter authentication, and consider a second person's approval for high-risk actions. DFS recommends that last control.
- Use phishing-resistant authentication for those people. A push approval can be socially engineered. A hardware key bound to the real site cannot be tricked the same way.
- Teach a rule, not a story. Publish how IT will contact staff, for example "we never ask for your password by phone," and test it with vishing exercises, as DFS recommends.
- When your working model changes, update controls too. A sudden move to remote work was an opening here.
- Plan the public response. DFS recounts hours of limited public communication. Know who speaks, and where.
What to do
- List every internal tool that can change account recovery, email, passwords or MFA. Count how many people can use each.
- Cut that list to the smallest group and review it quarterly.
- Move that group to hardware security keys, and add a second approver for the most dangerous actions.
- Add a vishing exercise to your next awareness cycle, and measure the report rate.
- Write and publish the "how IT contacts you" standard.
- Run a tabletop for the case where the attacker is inside a support tool and the news is breaking publicly.
Quick check
Did the Twitter attackers use malware or a software vulnerability?
According to the DFS report, no. It says the hack involved no malware, no exploits and no backdoors, only social engineering.
Would app-based MFA have prevented the attack?
The report says it did not. Attackers convinced employees to approve the prompts. DFS says hardware security keys would have stopped them.
Sources
Last reviewed: 18 October 2026.
