The takeover of high profile Twitter profiles last month on July 15 made headlines when public figures like former President Barack Obama, Jeff Bezos, and Elon Musk began announcing that they wanted to “give back” to the community. But instead of making a donation to a COVID-related charity or something similar, they were promising that if people would send them Bitcoin, then they would return twice as much as they were given. This type of social engineering scam is a common one. Bad actors will pretend to be someone famous and use a fake account to trick people into sending them money. In most cases, a closer inspection of the account will show that the account is fraudulent, usually by seeing that the user name isn’t the account that belongs to the person being impersonated. Avoiding these confusions over authenticity of an account is the reason why Twitter introduced their verified account status with the checkmarks next to the name. But this attack was different because the accounts really did belong to these high profile characters. If it had just been Elon Musk tweeting out something wacky, then the case might have been believable just like any other Wednesday. But the idea of Jeff Bezos giving back to the community? That sent most people’s radars blaring that something big might be afoot. (Image Source: Twitter) As it soon emerged that these were the real accounts tweeting out the scammy message, confusion and a lockdown quickly followed as Twitter went into crisis mode. Within hours, Twitter responded, shutting down tweeting services for all verified accounts, thus ending the scammers’ operation. Coinbase, the cryptocurrency exchange that was being used for running the ill-gotten gains halted payments to the illicit wallet, blocking digital currency from reaching the thieves’ hands. For a full rundown of the story, please see coverage by that even managed to get comments for their story. The New York Times from the scammers However, once control of the impacted accounts was regained, the questions over how the hackers had taken over these important profiles began. In from the company on July 30, Twitter claimed that the breach had been the result of a “phone spear phishing attack” that led to the hackers accessing their internal tools: a statement The social engineering that occurred on July 15, 2020, targeted a small number of employees through a phone spear phishing attack. A successful attack required the attackers to obtain access to both our internal network as well as specific employee credentials that granted them access to our internal support tools. Not all of the employees that were initially targeted had permissions to use account management tools, but the attackers used their credentials to access our internal systems and gain information about our processes. This knowledge then enabled them to target additional employees who did have access to our account support tools. Using the credentials of employees with access to these tools, the attackers targeted 130 Twitter accounts, ultimately Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7. (Source: Twitter) How did this Happen? In his of the incident, cybersecurity expert Graham Cluley notes that Twitter has not been particularly forthcoming regarding the details of the attack. He believes that the “phone spear phishing” — which is sometimes referred to as vishing, short for voice phishing — was likely the attacker pretending to be from the company’s Help Desk. He surmises that the hacker probably spoofed Twitter’s phone number and might have directed the victim to a fake login page where the credentials were captured. recent analysis While this is admittedly conjecture, his theory sounds solid given that the victim gave over their credentials to someone who was not on their team, which is most likely to happen with a Help Desk interaction. It is probable that the victim was directed to a fake login page where the capture occurred. Cluley goes on to note that these types of spear phishing attempts can “be even more successful when your staff are forced to work remotely because there’s a global pandemic.” But why is this so? Well, for starters, being on our own at home can make it much more difficult to confirm that the person on the other end of the line is who they say that they are. At the office, verifying that someone reaching out to you can be as easy as walking down the hallway or a flight of stairs. We can also turn to our co-workers and get a sanity check about whether something is or is not a good idea to do. Working from home is a different story. Lacking our regular support network, we need to increase our vigilance significantly. Don’t trust, and certainly verify multiple times. Mitigate Your Risk If we want to think about how organizations can help to prevent these types of attacks from being successful in the future, Cluley offers a useful bit of advice when he says that employees should be provided with the real Twitter support team long before they receive a scam call like this. He touches on two important points here. When you are approached to provide sensitive information in a way that might set off alarm bells, whether it be your boss asking you to pick up gift cards or change the payment details for a vendor, always confirm on a separate channel from the one that you were contacted on. By this we mean that if you received a sketchy email, then do not respond there but pick up the phone and speak to them yourself. The second is not to use the number or link that is sent to you. For example, do not use the support number that someone sends you supposedly from your service provider. Use the one from their official site that you are already familiar with. Also, do not click on links sent to you by mail to access your accounts. If your bank supposedly sends you an email that you have to urgently address an issue, then ignore their link and just log in on your own through their site. Zooming out a tick from the individual level, as organizations, we should ask ourselves if we are doing enough to reduce our risk. Are we providing the technical oversight to enforce security policies that an employee might unwittingly violate that can put the organization at risk? If a security event does occur, do we have the capability to quickly understand what happened and move to block additional damage? The question is not how to stop all human errors (errare humanum est), but how to reduce them and mitigate the damage when they do occur. As organizations, what are we doing to train our people how to spot threats with a healthy dose of paranoia but without going overboard? Versus Being Quick to Judge, Use This as a Lesson to Prevent Something Similar from Happening to You In reading about the details of the story and writing this post, the thought occurred that we often read the same advice about how to work securely. Tips like always making sure that your software is up to date, not reusing passwords, and of course confirming the identities of people contacting you for sensitive information all seem to be basic best practices at this point. It is hard to imagine that an attack as “basic” and cliche as impersonating the Help Desk could work. But the truth is that these types of social engineering tactics continue to provide fantastic results for hackers, and those numbers are hard to argue against. That’s why they continue to use them. Their victims aren’t dumb, but they are busy and stressed. To address these problems at their core and empower a new era of working from home and/or outside the regular traditional office setting - as - be sure to have education and protocols in place that are shared on a regular basis; best practices enacted to ensure the and effectively transparent to help mitigate the risk of insider threats that could result in customer data breaches, intellectual property theft, misuse of company assets or information through negligence or malfeasance. Twitter employees may be able to do indefinitely safety and security of remote workers employee monitoring of remote workers This article was originally published on IT Security Central and reprinted with permission.
