The July 2020 Twitter hack began with phone calls to employees, not malware or exploits. Use this ten point checklist, drawn from the New York Department of Financial Services report, to test whether your own help desk, MFA, access to internal tools and monitoring would have stopped or caught the same sequence.
What happened, briefly?
The DFS report says the hack unfolded over roughly 24 hours on 14 and 15 July 2020 in three phases: social engineering to gain network access, takeover of accounts with desirable usernames, and takeover of dozens of high profile accounts for a bitcoin scam. Callers claimed to be the IT help desk, responding to a VPN problem. Since the move to remote work, VPN problems had been common at the company. They directed employees to a lookalike VPN login page, and entered the stolen details into the real site as the employee typed them, which triggered a genuine MFA prompt that some employees approved.
The report found no evidence employees knowingly aided the attackers. The callers used personal information about employees to seem legitimate, and some employees reported the calls. In total 130 accounts were compromised, 45 of them used to send tweets, and about $118,000 in bitcoin was stolen. The report also states the attack involved no malware, no exploits and no backdoors.
This is a story about a well constructed deception that worked on busy people, not about careless people. The checklist below is about system design.
The ten point checklist
- Would a call from a fake help desk be recognized? Do staff know the help desk never asks for credentials by phone, and have a way to verify a caller through a separate channel? Test with a simulated call, since the report recommends regular phishing and vishing exercises.
- Is MFA resistant to approval fatigue and relay? The report notes that app based MFA was bypassed when employees approved the login prompt, and says a physical security key would have stopped this attack. Where can you use hardware keys for your riskiest access?
- Do high risk tools need stronger authentication than email? The report says authentication should be calibrated to risk, with stricter requirements for tools like internal admin consoles.
- How many people can use your most powerful internal tool? The report says over 1,000 employees had access to the internal tools, and that access was cut immediately after the incident. Count yours.
- Does a dangerous action need a second person? The report suggests approval by a second employee as a way to limit damage if one person's access is compromised.
- Do you recertify access regularly? The report says access should be recertified to account for changes in roles.
- Would you see unusual use in near real time? The report says a strong monitoring program, such as a SIEM, could have detected the anomalous activity quickly and allowed sessions to be ended based on risk. Check whether your admin tool usage is logged and alerted on.
- Did you adjust after a big change? The report says the company did not implement significant compensating controls after the March 2020 move to remote work, despite regulator guidance on pandemic risks. After any large change, such as a new office model or a merger, review which controls assumed the old setup.
- Who owns security at the executive level? The report notes the company had no chief information security officer for seven months before the attack, and says an executive level leader should be responsible.
- Can you handle a fast moving incident publicly and privately? The report describes the response and the limited public updates during the first day. Rehearse who decides, who speaks and how staff are reached.
How do you score yourself?
For each point write Yes, Partly or No, with the evidence. A Yes needs a record: a test result, a log, a policy and its date. Anything Partly or No becomes a ticket with an owner.
Where does software supply chain fit?
Mostly it does not, and that is the lesson. The attack used no software flaw. Supply chain tools such as SBOM and dependency scanning, which Safeguard provides, address a different path into an organization. A good program covers both people and software, and this checklist covers the people and access side.
What to do
- Run a simulated help desk call this month, and record who followed procedure.
- List accounts that can reach your most powerful internal tools, and remove unneeded access.
- Move admin access to hardware backed MFA where you can.
- Add a second person approval for the three most damaging actions in that tool.
- Alert on unusual use of those tools, and test the alert.
- Review compensating controls after your last big change.
- Name the executive who owns security, and write down who declares an incident.
Quick check
Was this a technical hack?
The DFS report describes social engineering by phone and says no malware, exploits or backdoors were involved. The weakness was in processes and access design.
Would stronger MFA alone have prevented it?
The report says a physical security key would have stopped this attack. It also lists access limits, monitoring and training, because several layers reduce the chance and the damage.
Sources
- New York DFS: Twitter Investigation Report, fetched 18 October 2026
Last reviewed: 18 October 2026.
