Information Technology

Ransomware has been around for more than three decades, so it’s hardly an unexpected threat. And yet, organisations large and small are still being taken completely by surprise by the file-encrypting malware, leaving them to decide between rebuilding many of their computer systems from scratch to rid themselves of the ransomware or paying up to the crooks in the hope that they will hand over the encryption keys. So why aren’t we learning the lessons from all the companies that have already been hit by ransomware over the years? Here are a few reasons.
Nobody thinks that they will be the next victim
This is one of the root problems; while many organisations are aware of the ransomware threat, they don’t think they’re going to be the next victim. Some firms think they are too small or obscure to be noticed by ransomware gangs. Others think they are too well protected to be at risk. Both can be wrong; some ransomware attacks start with a spray of malware-filled emails that could end up in pretty much anyone’s inbox; others start with randomly scanning for internet-facing ports. Either of these could put any organisation of any size at risk. And as for those big companies that think they are invulnerable? Well, there are plenty of examples of huge organisations being hit hard by ransomware gangs who have the money and the time to play a long game.
Security basics are be ignored
Ransomware crooks are sometimes portrayed as master criminals and while they are undoubtedly sophisticated, most ransomware attacks are preventable by relatively straightforward steps. Keeping software patched and updated is one of the basics. Some of the ransomware that is causing the most problems relies on some pretty old software flaws in order to spread. Fixes for these flaws are readily available and yet too many companies aren’t applying them. Of course, software patching is boring, time consuming and costly work that brings little obvious benefit. But rebuilding all your customer databases after a ransomware attack is probably going to be a lot worse.
Staff aren’t taking security seriously
Because some ransomware attacks still start with a bogus email, a wrong decision by an individual worker can put your whole organisation at risk. That means educating staff as to what phishing and ransomware looks like is extremely important. Also, it’s still too easy for a single mistake to cause chaos because once crooks have access to the network, too many times companies stick with default passwords across the network, or give too many staff too wide ranging access to systems which means that once their account it hacked the threat to the broader organisation is much greater. Remote working is not making this any better, of course.
Catching ransomware gangs is far too hard
Most police forces struggle with such limited resources that investigating major crime is hard enough. Trying to investigate cyber  crime – never a top priority – is even harder because few officers have the expertise to understand what crime is being committed, let alone understand how to chase the crooks involved. Even if the police do have the resources and the skills to pursue these gangs, there is also reality that many will be hard to trace. And even if police can identify the crooks, they often live in jurisdictions far away that are in little hurry to hand them over to stand trial, in some cases because the line between the ransomware gangs and the state itself are blurred.
Too many businesses will pay the ransom
It’s hard to tell how many ransomware victims actually pay up, but some estimates put it as high as between a third and a half. And while police will urge victims not to pay up, it’s understandable that when faced with either paying or losing their entire business, some execs will grit their teeth and reach for the bitcoin. The bigger problem here is that not only does this reward the criminals, it also encourage more crooks to give ransomware scams a go. One ransomware group alone managed to generate around $60 million in an 18 month period.
More ransom payments means more ability to hire developers to make their ransomware more effective. More ransom payments means the crooks can spend the time and effort on bigger targets that might take longer and more resources to crack. More ransom payments means the whole cycle starts again – with the gangs stronger than ever. 
ZDNET’S MONDAY MORNING OPENER
The Monday Morning Opener is our opening salvo for the week in tech. Since we run a global site, this editorial publishes on Monday at 8:00am AEST in Sydney, Australia, which is 6:00pm Eastern Time on Sunday in the US. It is written by a member of ZDNet’s global editorial board, which is comprised of our lead editors across Asia, Australia, Europe, and North America.
PREVIOUSLY ON MONDAY MORNING OPENER: More

Image: ZDNet

According to data collected by Google’s Project Zero security team, there have been 11 zero-day vulnerabilities exploited in the wild in the first half of the year.
The current number puts 2020 on track to have just as many zero-days as 2019 when Google security researchers said they tracked 20 zero-days all of last year.
Details about these zero-days have been obtained from a spreadsheet managed by Google security researchers, which the company made public available earlier this year. The spreadsheet contains Google’s internal statistics about in-the-wild zero-day usage going as far back as 2014, when the company began tracking said stats.
Below we will list this year’s current zero-day vulnerabilities.
Below that, we will also summarize the most important conclusions of the Google’s first Zero-Day Year in Review report, which the company published last week, detailing 2019 zero-days and their causes.
2020 H1 zero-days

1. Firefox (CVE-2019-17026)
This zero-day was used as part of a combo with another zero-day. See below.
Patched here, in Firefox 72.0.1.
2. Internet Explorer (CVE-2020-0674)
Both of Firefox zero-day listed above and this one have been used by a nation-state hacking group known as DarkHotel, believed to be operating out of the Korean peninsula (unclear if from North Korea or South Korea). Both zero-days have been used to spy on targets located in China and Japan, hence why they were both discovered by Qihoo 360 (Chinese antivirus maker) and JPCERT (Japan’s Computer Emergency Response Team).
Victims of this campaign were redirected to a website where they’d be served either the Firefox or IE zero-day, and then they were infected with the Gh0st remote access trojan.
Patched here, in the Microsoft February 2020 Patch Tuesday.
3. Chrome (CVE-2020-6418)
This zero-day was detected exploited in the wild by Google’s Threat Analysis Group, and details about the attacks where it was used were never released.
Patched here, in Chrome version 80.0.3987.122.
4. & 5. Trend Micro OfficeScan (CVE-2020-8467 and CVE-2020-8468)
Both zero-days were discovered internally by Trend Micro staff. It is believed the zero-days were discovered while Trend Micro investigated a 2019 zero-day in the same product that was used to hack Mitsubishi Electric.
Patched here.
6. & 7. Firefox (CVE-2020-6819 and CVE-2020-6820)
Details about the attacks where these two Firefox zero-days have been used have not yet been released, although, security researchers suggested these might be part of a larger exploit chain.
Patched here, in Firefox 74.0.1.
8. & 9. & 10. (CVE-2020-0938, CVE-2020-1020, and CVE-2020-1027)
All three bugs have been discovered and reported to Microsoft by Google TAG, and just like most Google TAG discoveries, no details about the attacks have been released — yet.
Patched here, here, and here, in the Microsoft April 2020 Patch Tuesday.
11. Sophos XG Firewall (CVE 2020-12271)
A group of hackers discovered earlier this year a zero-day in XG, a top-shelf firewall product developed by UK security firm Sophos. The zero-day, an SQL injection in the firewall’s management panel, allowed hackers to plant the Asnarok backdoor on infected systems. In an investigation, Sophos said hackers tried to deploy the Ragnarok ransomware on infected hosts once its zero-day made the news, but the company says it blocked most attempts.
Patched here.
Analysis of 2019’s zero-days
Putting aside this year’s zero-days, let’s take a look over Google’s analysis of last year’s zero-days.
The bullet list below contains Google’s primary conclusions from its 2019 Zero-Day Year in Review report, which took a thorough look at how security firms are discovering zero-days, which software products are impacted the most, why, and what are the primary causes for most zero-days.
In 2019, Google says it detected 20 zero-days.
Eleven of the 20 zero-days impacted Microsoft products.
Two companies discovered half of all of 2019’s zero-days (Google discovered 7 and Kaspersky found 4).

Image: Google Project Zero
No actively exploited zero-days have been found in Linux, Safari, or macOS since 2014, when Google began tracking this stat.
2019 was the first year when an Android zero-day was discovered.
Not all zero-days impacted the latest version of the OS/software.
Google suspects some software vendors are hiding actively exploited zero-days as mundane bugfixes.
Google says there’s a detection bias towards Microsoft, as there are more security tools specialized in detecting Windows bugs.
Google says it’s hard to find zero-days on mobile platforms due to walled garden and app sandbox approaches.
63% of 2019’s 0-day vulnerabilities were memory corruption bugs (Same 63% figure also applies to 2020 H1’s zero-days. This is also in tune with stats released by Microsoft and Google in 2019, both claiming that 70% of all Microsoft security bugs and 70% of all Chrome vulnerabilities are memory safety issues) (In 2020, 63% of all).
Google said that it plans to publish an annual Zero-Day Year in Review report each year, going forward. More

Image: Asha Barbaschow/ZDNet
Customers with Telstra’s default DNS settings found themselves seemingly unable to access the internet on Sunday morning, as the telco was facing a denial of service attack.
The attack kicked off some time before 10:30am on the Australian east coast.
“Some of our Domain Name Servers (DNS) used to route your traffic online are experiencing a cyber attack, known as a Denial of Service (DoS),” Telstra said on Twitter just before noon.
“Your info isn’t at risk. We’re doing all we can to get you back online.”
Customers that switched their DNS settings away from Telstra were able to mitigate the outage. At the same time, Telstra’s own outage site was misbehaving and returning 502 errors on occasion, and at other times, returning 404 errors.

At 12:05pm, Telstra said it had a handle on the attack.
“We’re blocking the malicious traffic attacking some of our services. We are confident we have blocked all of this malicious traffic and are working to get you back up and running again. Thanks for sticking with us,” it said.
By 2:27pm, Telstra said the issue was fixed.
“The massive messaging storm that presented as a Denial of Service cyber-attack has been investigated by our security teams and we now believe that it was not malicious, but a Domain Name Server issue,” the telco said.
“We’re really sorry for getting in the way of your weekend plans.”
Telstra has been vocal in recent times about its DNS filtering capabilities, dubbed Cleaner Pipes, that are used to fight malware passing through its network.
The initiative focuses on blocking command and control communications of botnets, the downloading of remote access trojans, as well as other forms of malware. The telco said in May it is already blocking “millions of malware communications” when the traffic hits its infrastructure.
This action reduces the impact of cyber threats on millions of Telstra’s customers including stopping the theft of personal data, financial losses, fraudulent activity, and users’ computers being infected with malware. 
“We know many consumers and small businesses do not have the resources to adequately protect themselves,” Telstra CEO Andy Penn said.
“Cleaner Pipes means we are able to more actively block cyber threats on our network that would compromise the safety of our customers’ personal information. While it will not completely eliminate the risk, or substitute appropriate threat protection, it will contribute to significantly reducing the volumes and impact.”
The initiative was recommended as a example that could be replicated by other telcos in the industry advisory panel report that is set to feed into Australia’s upcoming 2020 Cyber Security Strategy. The report added there should be legislation to both back up the process and provide safe harbour provisions to give telcos certainty about the information they share with each other in responding to cyber threats.
Fellow Australian ISP iiNet suffered from a DNS outage at the start of the year. In that instance, the telco recommended users set their DNS to use a publicly available service such as Cloudflare’s 1.1.1.1 service.
Once the outage was over, iiNet said users could revert to default DNS configuration.
Updated at 4:35pm AEST, 2 August 2020: Added further Telstra comment.
Related Coverage More

Getty Images/iStockphoto

A mixed team of security researchers from Google, PayPal, Samsung, and Arizona State University has spent an entire year analyzing the phishing landscape and how users interact with phishing pages.
In a mammoth project that involved analyzing 22,553,707 user visits to 404,628 phishing pages, the research team has been able to gather some of the deepest insights into how phishing campaigns work.
“We find that the average phishing attack spans 21 hours between the first and last victim visit, and that the detection of each attack by anti-phishing entities occurs on average nine hours after the first victim visit,” the research team wrote in a report they are scheduled to present at the USENIX security conference this month.
“Once detected, a further seven hours elapse prior to peak mitigation by browser-based warnings.”
The research team calls this interval between the start of the campaign and the deployment of phishing warnings inside browsers the “golden hours” of a phishing attack — when attackers make most of their victims.

But the research team says that once the golden hours end, the attacks continue to make victims, even after browser warnings are deployed via systems like Google’s Safe Browsing API.
“Alarmingly, 37.73% of all victim traffic within our dataset took place after attack detection,” researchers said.

Image: Oest et al.
Further, researchers also analyzed user interactions on the phishing pages. They said that 7.42% of the victims entered credentials in the phishing forms, and eventually suffered a breach or fraudulent transaction on their account.
On average, crooks would attempt to breach user accounts and perform fraudulent transactions 5.19 days after the user visited the phishing site, on average, and victim credentials would end up in public dumps or criminal portals after 6.92 days after the user visited the phishing page.
Most phishing campaigns come from a few major players
But while researchers analyzed more than 400,000 phishing sites, they said that the vast majority of phishing campaigns weren’t really that effective, and that just a handful of phishing operators/campaigns accounted for most of the victims.
“We found that the top 10% largest attacks in our dataset accounted for 89.13% of targeted victims and that these attacks proved capable of effectively defeating the ecosystem’s mitigations in the long term,” they wrote in the report.
Researchers said that some campaign remained active as long as nine months, while making tens of thousands of victims, using nothing more than “off-the-shelf phishing kits on a single compromised domain name [phishing site].”
The study’s findings are conclusive with what Sherrod DeGrippo, Sr. Director, Threat Research and Detection at Proofpoint, told ZDNet in an interview this week. DeGrippo said that Proofpoint usually tracks around 12 million credential phishing attacks per month and that the best threat actors focus on evasion tactics to avoid getting detected, knowing this would keep their campaigns running for longer, and prolong the “golden hours.”
“In terms of evasion, this is something the credential phish threat actors absolutely work hard on,” DeGrippo said.
More collaboration needed
The academic team blamed the current state of affairs on the reactive nature of anti-phishing defenses, which are usually slow in detecting phishing attacks. However, researchers also blamed the lack of collaboration between industry partners, urging the different anti-phishing entities to work together more.
“Cross-industry and cross-vendor collaboration certainly makes all entities stronger against phishing and other attacks,” DeGrippo also added, echoing the study’s conclusion.
However, the Proofpoint exec also says that entities outside the anti-phishing and cyber-security world also need to pitch in, as well.
“Additional effectiveness also involves domain registrars, encryption cert providers, and hosting companies to complete abuse takedowns, which can be a challenge as providers can be resource-restrained.
“Stopping phishing attacks is vital to help protect organizations worldwide and industry collaboration, insight sharing, and action, such as blocking cred phish from reaching victims, is essential,” DeGrippo said.
The full academic study, entitled “Sunrise to Sunset: Analyzing the End-to-end Life Cycle and Effectiveness of Phishing Attacks at Scale,” is available for download as a PDF. More

A 30-year-old Moldovan man pleaded guilty on Friday for creating FastPOS, a strain of malware designed to infect computers processing payment card data from Point-of-Sale (POS) systems.
Valerian Chiochiu, known in the hacking world as “Onassis” (after the Greek shipping magnate who married Jacqueline Kennedy), was part of the Infraud criminal organization.
Infraud was a hacking forum that was founded in 2010 and operated as a place for hackers to meet and exchange services. The forum first operated at infraud.cc and infraud.ws, and was primarily known as a place where hackers could sell or buy stolen payment card numbers, stolen identities, and buy, sell, or rent malware and DDOS attacks.
The forum operated under the slogan of “In Fraud We Trust” and had more than 11,000 registered members.
According to the US Department of Justice, Chiochiu sold the FastPOS malware on the forum, and then provided support for paying customers.

His “business” stopped when US authorities seized and took down the forum in February 2018. US authorities charged 36 members and arrested 13, but Chiochiu was not among the members in the first wave of arrests — having been arrested at a later undisclosed date.
Image: DOJ
Last month, Sergey Medvedev (Infraud username “Stells”), one of the two Infraud administrators, pleaded guilty for his involvement in the forum.
Chiochiu now becomes the second Infraud member to plead guilty for his crimes and is scheduled to be sentenced on December 11, later this year.
The FastPOS malware
As for Chiochiu’s creation, the FastPOS malware was first discovered by Trend Micro in 2016. In a PDF report released at the time, Trend Micro said the malware had three main components: (1) a memory scrapper that collected payment card data from the computer’s RAM; (2) a keylogger for recording user key strokes; and (3) a self-updating mechanism.
At the time, Trend Micro said it believed it identified the FastPOS author on an online forum asking for help with their (keylogger component) code.

The FastPOS malware author seeking help on a coding forum.
Image: Trend Micro
Trend Micro also said it tracked down ads on hacking forums that were promoting the FastPOS malware, which at the time was being sold on the SwipeIt.pw portal. Trend Micro said the portal was hosted on the same server as the FastPOS command-and-control server, effectively linking the ads and Chiochiu’s online persona to the FastPOS malware.

Ad for FsatPOS’ SwipeIt.pw portal on hacking forums
Image: Trend Micro

FastPOS backend panel
Image: Trend Micro
According to Trend Micro, the FastPOS malware was distributed via multiple methods (hacked websites, VNC transfers), suggesting multiple clients had rented the tool, and made victims all over the world, not just the US.

Image: Trend Micro More

Image: Volodymyr Hryshchenko, ZDNet, Twitter
After earlier today US law enforcement charged three individuals for the recent Twitter hack, with the help of court documents released by the DOJ, ZDNet was able to piece together a timeline of the hack, and how US investigators tracked down the three suspected hackers.
The article below uses data from three indictments published today by the DOJ against:
Mason Sheppard, aka “Chaewon,” 19, of Bognor Regis, in the United Kingdom [indictment].
Nima Fazeli, aka “Rolex,” 22, of Orlando, Florida [indictment].
Graham Ivan Clark, believed to be “Kirk,” 17 of Tampa, Florida [indictment, courtesy of Motherboard].
According to court documents, the entire hack appears to have begun on May 3, when Clark, a teen from Tampa, but living in California, gained access to a portion of Twitter’s network.

Image: ZDNet
Here, the timeline gets murky and it is unclear what happened between May 3 and July 15, the day of the actual hack, but it appears that Clark wasn’t immediately able to pivot from his initial entry point to the Twitter admin tool that he later used to take over accounts.
However, reporting from the New York Times days after the Twitter hack suggests Clarke initially gained access to one of Twitter’s internal Slack workspaces, and not to Twitter itself.

NYT reporters, citing sources from the hacking community, said the hacker found credentials for one of Twitter’s tech support tools pinned to one of the company’s Slack channels.
Images of this tool, which allowed Twitter employees to control all facets of a Twitter account, later leaked online on the day of the hack.

Image: Reddit
However, the credentials for this tool weren’t enough to access the Twitter backend. In a Twitter blog post detailing the company’s investigation into the hack, Twitter said accounts for this administrative backend were protected by two-factor authentication (2FA).
It is unclear how much time it took Clark to do it, but the same Twitter investigation says the hacker used “a phone spear phishing attack” to trick some of its employees and gain access to their accounts, and “getting through [Twitter’s] two-factor protections.”
According to Twitter, this happened on July 15, the same day of the hack.
Clark, who went on Discord by Kirk#5270, didn’t wait around to be detected, and according to Discord chats obtained by the FBI, the hacker contacted two other individuals to help him monetize this access.
Chat logs included in court documents showed Clark (Discord user “Kirk#5270”) approaching two other users from the Discord channel of OGUsers, a forum dedicated to hackers selling and buying social media accounts.
In chat logs, Clark approached two other hackers (Fazeli as Discord user “Rolex#037” and Sheppard as Discord user “ever so anxious#0001”) and claimed to work at Twitter.
He proved his claims by modifying the settings of an account owned by Fazeli (Rolex#037) and also sold Fazeli access to the @foreign Twitter account.

Image: ZDNet
Clarke also sold Sheppard access to multiple short-form Twitter accounts, such as @xx, @dark, @vampire, @obinna, and @drug.

Image: ZDNet
As Clark convinced the other two of his level of access, the three struck a deal to post ads on the OGUsers forum to promote Clark’s ability to hijack Twitter accounts.

Image: ZDNet

Image: KrebsOnSecurity
Following the posting of these ads, it is believed that multiple people bought access to Twitter accounts. In a recorded message posted on YouTube by the Executive Office for United States Attorneys, investigators said they are still looking into multiple users who participated in the hack.
It is believed that one of these parties is responsible for buying access to celebrity verified Twitter accounts on July 15, and posting a cryptocurrency scam message.
The message, spotted on accounts belonging to Barrack Obama, Joe Biden, Bill Gates, Elon Musk, Jeff Bezos, Apple, Uber, Kanye West, Kim Kardashian, Floyd Mayweather, Michael Bloomberg, and others, asked users to send Bitcoin to several addresses.

Court documents say hackers operating wallets used in this scam received 12.83 bitcoin, or around $117,000. A subsequent investigation also revealed that cryptocurrency exchange Coinbase took matters in its own hands on the day of the hack to block transactions to the scam addresses, eventually preventing another $280,000 from being sent to the scammers.
It’s at this point that the hack became visible to everyone, including Twitter’s staff, who intervened to block verified Twitter accounts from tweeting while they kicked Clark out of their network.
Twitter’s subsequent investigation discovered that Clark interacted with 130 accounts while he had access to the Twitter admin tool, initiated a password reset for 45, and accessed private messages for 36.
The day following the hack was also when Twitter filed a formal criminal complaint with authorities, and the FBI and Secret Service started an investigation.
Per court documents, the FBI used data shared on social media and by news outlets to get chat logs and user details from Discord.
Since some of the hacker ads were posted on OGUsers, the FBI also used a copy of the OGUsers forum database that leaked online in April this year after the forum got hacked. This database contained details on registered forum users, such as emails and IP addresses, but also private messages.
Authorities, with the help of the IRS, also obtained data from Coinbase about the Bitcoin addresses involved in the hacks, and addresses used and mentioned by the three hackers in the past in Discord chats and OGUsers forum posts.
Correlating data from the three sources, the FBI was able to track hacker identities on the three sites, and link them to email and IP addresses.
For example, authorities tracked Fazili down after he linked his Discord username from his OGUsers page, an obvious operational security (OpSec) mistake.

Image: ZDNet
Fazili also made multiple other mistakes in hiding his identity. For starters, he used the damniamevil20@gmail.com address to register an account on the OGUsers forum and the chancelittle10@gmail.com email address to hijack the @foreign Twitter account.
He also used the same two email addresses to register Coinbase accounts, which he later verified with a photo of his driver’s license.
Furthermore, Fazili also used his home connection to access accounts on the three sites, leaving his home IP address in connection logs on all three services — Discord, Coinbase, and OGUsers.
The same goes for Sheppard (ever so anxious#0001), who went on OGUsers as Chaewon. Investigators said they were able to connect Sheppard’s Discord user with his OGUsers persona thanks to the ad he posted on the site on the day of the hack, but they also got confirmation going through the OGUsers leaked database, where they found Chaewon buying a video game username with a Bitcoin address that was connected to addresses used on the day of the Twitter hack.

Image: ZDNet
Just like in Fazili’s case, Sheppard managed accounts at Coinbase, where he, too, used his real-world driver’s license to verify multiple accounts.
Authorities didn’t link Clark directly to the Kirk#5270 Discord user, but details shared today by different US government sources suggest he’s the same individual.
First, Hillsborough State Attorney Andrew Warren claimed the 17-year-old Tampa teen (Clark) they arrested today was the “mastermind” of the entire hack — the role that Kirk#5270 played in the entire scheme.
Second, in a press release from the Northern District of California, authorities said they referred the third hacker, the juvenile, to the State Attorney for the 13th Judicial District (Hillsborough County) in Tampa, Florida.
The same Florida office announced today the hacker’s arrest and revealed his real name as Graham Ivan Clark. More

In a press conference on Friday, US authorities announced they arrested the main suspect behind this month’s major Twitter hack, and charged two other accomplices.
The suspected main hacker was identified as Graham Ivan Clark, a 17-year-old teen from Tampa, Hillsborough County, Florida.
According to Florida news outlet WFLA-TV, which first reported on the arrest, Clark was arrested earlier this morning in Tampa, following a nationwide collaboration between the FBI, the IRS, the DOJ, and the Secret Service.
Hillsborough State Attorney Andrew Warren filed charges against Clark for being the “mastermind” behind the July 15 Twitter incident, when the teen is believed to have gained access to Twitter’s backend, took over several high-profile accounts, and tweeted on their behalf to promote a cryptocurrency scam. The list of hacked accounts includes big names like Barrack Obama, Joe Biden, Bill Gates, Elon Musk, Jeff Bezos, Apple, Uber, Kanye West, Kim Kardashian, Michael Bloomberg, and others.

Officials said the hack resulted in more than $100,000 being sent to Bitcoin “accounts associated with Clark” in one single day.

According to a press release from Warren’s office, the teen now faces 30 felony charges, including:
ORGANIZED FRAUD (OVER $50,000) – 1 count
COMMUNICATIONS FRAUD (OVER $300) – 17 counts
FRAUDULENT USE OF PERSONAL INFORMATION (OVER $100,000 OR 30 OR MORE VICTIMS) – 1 count
FRAUDULENT USE OF PERSONAL INFORMATION – 10 counts
ACCESS COMPUTER OR ELECTRONIC DEVICE WITHOUT AUTHORITY (SCHEME TO DEFRAUD) – 1 count
The charges were announced in a live stream today by the Hillsborough State Attorney.

While initially Warren didn’t specify if Clark had partners, hours after the press conference, in a separate announcement after this article went live, the US Department of Justice announced additional charges against two other suspects believed to have helped Clark in the hack.
The second suspect was identified as Mason Sheppard, aka “Chaewon,” 19, of Bognor Regis, in the UK, while the third was identified as Nima Fazeli, aka “Rolex,” 22, of Orlando, Florida. The DOJ didn’t specify if the two have been apprehended.
Clark’s arrest comes just hours after Twitter published its latest update on its investigation into the July 15 hack. Below is Twitter’s entire investigation, summarized, for easier reading:
The incident took place on Wednesday, July 15, 2020.
Twitter said hackers used phone-based social-engineering to gain access to Twitter employee accounts.
A New York Times report that has yet to be confirmed by Twitter said that hackers breached employee Slack accounts and found credentials for the Twitter backend pinned inside a Slack channel.
Twitter said hackers got “through” their two-factor protections but did not specify if it referred to the backend accounts or the Slack accounts.
Once hackers accessed the Twitter backend, they Twitter’s own internal tech support tools to interact with accounts.
Hackers interacted with 130 accounts, according to Twitter.
For 45 accounts, hackers initiated a password reset, logged into the account, and sent new tweets to promote their cryptocurrency scam.
Twitter said it believes hackers also tried to sell access to some hijacked Twitter accounts, due to highly-coveted usernames.
For eight accounts, hackers downloaded account data through the “Your Twitter Data” feature.
Twitter said hackers accessed direct messages (DMs) for 36 accounts, including 1 elected official in the Netherlands.
None of these eight accounts were verified.
Twitter is now reaching out to the eight account owners.
Once the hack came to light on Wednesday, Twitter said it blocked all verified accounts from tweeting as it investigated.
It then also blocked some users from resetting their password to hackers from taking over new accounts.
These limitations lasted for a few hours, and functionality was eventually returned.
Twitter said it had no reason to believe the hackers had access to cleartext passwords and will not be resetting user passwords going forward.
However, attackers did view information such as email addresses and phone numbers for the targeted accounts.
A law enforcement investigation is already underway.
Twitter said it restricted the number of employees who can access to its internal tools following the attacks.
Article updated 20 minutes after publication with the DOJ’s announcement of additional charges against two other suspects. More

As many experts anticipated, patches for the BootHole vulnerability in the GRUB2 bootloader that is used by all major Linux distributions are causing problems and preventing some users from booting their systems.
While the list of affected distros only included Red Hat yesterday, it has now expanded to include users of Ubuntu [1, 2, 3], Debian, CentOS [1, 2], and Fedora.
Microsoft security researcher Kevin Beaumont, also reports issues in cloud environments, namely where “a bug in cloud-init is causing problems across major cloud providers with Grub, such as Digital Ocean and Azure, having the same impact: patched systems then fail to boot.”
What is BootHole
Details about the BootHole vulnerability were published earlier this week, on Wednesday. Discovered by security firm Eclypsium, the vulnerability impacts GRUB2, a bootloader component used to help launch operating systems on servers and desktops.
GRUB2 is currently the default bootloader on all major Linux systems but is also used for Windows, in some scenarios, such as a custom bootloader or for dual-boot purposes.

The BootHole vulnerability allows attackers or malware to modify the GRUB2’s config file and insert malicious code in the bootloader, and inherently the operating system that it launches.
Systems using GRUB2 in a Secure Boot mode were also deemed vulnerable, as the GRUB2 config file is not protected by the Secure Boot process checks.
The vulnerability was deemed serious enough that all major Linux distros had patches ready when Eclypsium went public with its research earlier this week.
Most experts anticipated problems
The issues were to be expected, Kelly Shortridge, VP of cybersecurity firm Capsule8, said in a blog post this week, where she analyzed the impact of the BootHole vulnerability on system administrators.
The issues primarily arise because patching BootHole involves dancing around advanced cryptography, the safety checks of the Secure Boot process, and working with an allowlist-denylist managed by Microsoft, everyone expected issues to arise.
And so they did. As ZDNet reported yesterday, the first issues were reported with Red Hat, but more bug reports are now coming in from other distros.
Because a bug in GRUB2 usually stops the entire OS from booting, the issues result in downtime for those affected. In all cases, users reported that downgrading systems to a previous release to reverse the BootHole patches usually fixed their problems.
Regardless of the reported problems, users are still advised to apply the BootHole patches, as security researchers expect this bug to be weaponized by malware operators at some point in the future — primarily because it allows malware to implant a bootkit component on infected systems that operates below the antivirus level and survive OS reinstalls. More