Twitter Hacked in Bitcoin Scam
It started with one weird tweet. Then another. Quickly, some of the most prominent accounts on Twitter were all sending out the same message;
I am giving back to the community.
All Bitcoin sent to the address below will be sent back doubled! If you send $1,000, I will send back $2,000. Only doing this for 30 minutes.
[- BITCOIN WALLET ADDRESS -]
Are Apple, Elon Musk, Barrack Obama, Uber, Joe Biden, and a host of others participating in a very transparent bitcoin scheme?
No. Of course, not. The question was whether or not individual accounts were compromised or if something deeper was going on.
User Account Protections
These high profile accounts are prime targets for cybercriminals. They have a broad reach and even a brief compromise of one of these accounts would significantly increase a hacker’s reputation in the underground.
That’s why these accounts leverage the protections made available by Twitter in order to keep their accounts safe.
While it’s believe that one or two of these accounts failed to take these measures, it’s highly unlikely that dozens and dozens of them did. So what happened?
As with any public attack, the Twitter-verse (ironically) was abuzz with speculation. That speculation ramped up when Twitter took the reasonable step of preventing any Verified account from tweeting for about three hours.
This helped prevent any addition scam tweets from being published but also raised the profile of this attack further.
While some might shy away from raising the profile of an attack, this was reasonable trade off to prevent further damage to affected accounts and to help prevent the attack from taking more ground.
This move also provided a hint as to what was going on. If individual accounts were being attacked, it’s unlikely that this type of move would’ve done much to prevent the attacker from gaining access. However, if the attacker was accessing a backend system, this mitigation would be effective.
Had Twitter itself been hacked?
When imagining attack scenarios, a direct breach of the main service is a scenario that is often examined in depth. This is why it’s also one of the most planned for scenarios.
Twitter—like any company—has challenges with its systems but they center primarily around content moderation…their backend security is top notch.
An example of this an incident in 2018. Twitter engineers made a mistake that meant anyones password could have been exposed in their internal logs. Just in case, Twitter urged everyone to reset their password.
While possible, it’s unlikely that Twitter’s backend systems were directly breached. There is a much simpler potential explanation: insider access.
Quickly after the attack, some in the security community noticed a screenshot of an internal support tool from Twitter surfacing in underground discussion forums. This rare inside view, showed what appeared to be what a Twitter support team member would see.
This type of access is dangerous. Very dangerous.
Joseph Cox’s article detailing the hack has a key quote,
“We used a rep that literally done all the work for us”
What remains unclear is whether this is a case of social engineering (tricking a privileged insider into taking action) or a malicious insider (someone internal motivated to attack the system).
The difference is important for other defenders out there.
The investigation is ongoing, and Twitter continues to provide updates via @TwitterSupport;
Our investigation is still ongoing but here’s what we know so far:
— Twitter Support (@TwitterSupport) July 16, 2020
— Donie O’Sullivan (@donie) July 16, 2020
If this attack was conducted through social engineering. The security team at Twitter will need to implement additional processes and controls to ensure that it doesn’t happen again.
This is what your team also needs to look at. While password resets, account closures, data transfers, and other critical processes are at particular risk of social engineering, financial transactions are atop the cybercriminals target list.
Adding additional side channel confirmations, additional steps for verifications, firm and clear approvals, and other process steps can help organizations mitigate these types of social engineering attacks.
If the attack turns out to be from a malicious insider. Defenders need to take a different approach.
Malicious insiders are both a security problem and an human resources one.
From the security perspective, two key principles help mitigate the potential of these attacks;
Making sure that individuals only have the technical access needed to complete their assigned tasks and only that access is key to limiting this potential attack. Combined with the smart separation of duties (one person to request a change, another to approval it), this significantly reduces the possibility of these attacks causing harm.
The other—and not often spoken of—side of these attacks is the reason behind the malicious intent. Some people are just malicious and when presented with an opportunity, they will take it.
Other times, it’s an employee that feels neglected, passed over, or is disgruntled in some other way. A strong internal community, regularly communication, and a strong HR program can help address these issues before they escalate to the point where aiding a cybercriminal becomes an enticing choice.
Underlying this whole situation is a more challenging issue; the level of access that support has to any given system.
It’s easy to think of a Twitter account as “yours”. It’s not. It’s part of a system that is run by a company that needs to monitor the health of the system, response to support issues, and aid law enforcement when legally required.
All of these requirements necessitate a level of access that most don’t think about.
How often are you sharing sensitive information via direct message? Those messages are most likely accessible by support.
What’s to prevent them from accessing any given account or message at any time? We don’t know.
Hopefully Twitter—and others—have clear guardrails (technical and policy-based) in place to prevent abuse of support access and they regularly audit them.
It’s a hard balance to strike. User trust is at stake but also the viability of running a service.
Clear, transparent policies and controls are the keys to success here.
Abuse can be internal or external. Support teams typically have privileged access but are also among the lowest paid in the organization. Support—outside of the SRE community—is usually seen as entry level.
These teams have highly sensitive access and when things go south, can do a lot of harm. Again, the principles of least privilege, separation of duties, and a strong set of policies can help.
In the coming days more details of the attack will surface. In the meantime, the community is still struggling to reconcile the level of access gained and how it was used.
Getting access to some of the world most prominent accounts and then conducting a bitcoin scam? Based on the bitcoin transactions, it appears the cybercriminals made off with a little over $100,000 USD. Not insignificant but surely there were other opportunities?
Occam’s razor can help here again. Bitcoin scams and coin miners are the most direct method fo cybercriminals to capitalized on their efforts. Given the high profile nature of the attack, the time before discovery was always going to be sure. This may have been the “safest” bet for the criminal(s) to make a profit from this hack.
In the end, it’s a lesson for users of social networks and other services; even if you take all of the reasonable security precautions, you are relying on the service itself to help protect you. That might not always hold true.
For service providers and defenders, it’s a harsh reminder that the very tooling you put in place to run your service may be its biggest risk…a risk that’s often overlooked and underestimated.
In the end, Marques Brownlee sums it up succinctly;
Don’t send Bitcoin to strangers.
— Marques Brownlee (@MKBHD) July 15, 2020
What do you think of this entire episode? Let’s talk about it—un-ironically—on Twitter, where I’m @marknca.