Category Archives: News

US court gets UK Twitter hack suspect arrested in Spain

You can probably guess what we mean by “Twitter hack“.

Some data breaches involve millions or even billions of accounts, perhaps compromised by a leaky cloud storage server or a poorly-secured customer database.

In contrast, the Twitter hack we’re referring to ultimately led to the takeover of just 45 accounts.

But what accounts they were!

As federal investigator Tigran Gambaryan reported at the time, when charges were filed against three suspects:

[M]ultiple high-profile verified accounts were compromised, including accounts belonging to Bill Gates, Elon Musk, Kanye West, Joe Biden, Barack Obama, Jeff Bezos, Mike Bloomberg, Warren Buffett, Benjamin Netanyahu, and Kim Kardashian.

Trading in Twitter accounts

The suspects were alleged to have previous form in hacking and trading in so-called OG accounts, where OG is short for original gangster.

OG accounts have the sort of short and funky account names that get snapped up by early adopters when a new social media platform starts becoming popular, making them easy on the eyes and simple to remember, such as @jack (which belongs to Twitter’s founder, Jack Dorsey) instead of @another_jack_63 (which is, unsurprisingly, still available).

In this hack, however, they didn’t plan to sell on the high-profile accounts that they hijacked; they used them to promote a cryptocoin scam that they hoped people would fall for because of the reach and influence of the accounts involved.

You might think it’s unlikely that anyone would fall for messages saying, essentially, “Pay me $1000 in BTC now and I’ll pay you back $2000 later”, but the prestige of the accounts involved did, apparently, convince hundreds of people to take a chance on it…

…altough investigator Gambaryan wryly noted in his affidavit to the court that “No bitcoin was ever returned, much less doubled.”

The hack, Twitter ultimately figured out, was human-led rather than technology-driven, with the scammers using social engineering tricks – sweet-talking secrets out of support staff on the phone, to you and me – to wrangle access credentials out of Twitter staff.

The crooks then used those details later on to get into Twitter’s internal support tools and to provide direct “support” of their own for their criminal enterprise.


Listen to our special-episode podcast with Rachel Tobac, a renowned social engineering expert, and give yourself the confidence and understanding not to get sucked into saying or doing the wrong thing online:

Three suspects were identified quickly.

One suspect was soon arrested in Florida, US, and hit the news when his bail hearing, held via Zoom in the early days of the coronavirus pandemic, was zoom-bombed with political rants and, perhaps inevitably, porn.

Though only 17 at the time, the accused, Graham Clark, had apparently already been probed for a cryptocoin heist running into a million dollars or more , but voluntarily paid back close to $1m in bitcoins to Secret Service investigators.

(Clark has since received a three-year prison sentence for his part in the Twitter hack.)

One more suspect

One year on, and a fourth person, Joseph O’Connor, 22, is now not only under investigation for his alleged involvement in this hack, but under arrest in Spain.

O’Connor, described in a press release from the US Department of Justice (DOJ) merely as “a citizen of the United Kingdom”, was arrested at the Spanish holiday resort of Estepona on the Costa del Sol, and will now presumably face extradition to the United States.

The press release doesn’t link to an affidavit or a charge sheet in this case; reporters at IT news site The Register say they’ve seen the relevant court document but didn’t publish it because of the private nature of some of the data that it contained.

You can imagine what some of that data might reveal, and why El Reg decided to keep it private, from the DOJ’s press release:

[I]n addition to the July 15, 2020, hack of Twitter, O’Connor is charged with computer intrusions related to takeovers of TikTok and Snapchat user accounts. O’Connor is also charged with cyberstalking a juvenile victim.

O, what a tangled web we weave/When first we practise to deceive!

S3 Ep42: Viruses, Nightmares, patches, rewards and scammers [Podcast]

[00’38”] Learning from computer virus history.  [02’26”] The PrintNightmare saga continues.  [05’27”] Apple puts out a patch, but doesn’t say why.  [08’12”] Snitch on a crook and earn $10 million.  [17’50”] Scammars do grammer and speeling correctly.  [25’12”] And the Business Email Compromise that wasn’t.

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.


Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.


You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at, or simply leave us a comment below.

Windows “HiveNightmare” bug could leak passwords – here’s what to do!

As if one Windows Nightmare dogging all our printers were not enough…

…here’s another bug, disclosed by Microsoft on 2021-07-20, that could expose critical secrets from the Windows registry.

Denoted CVE-2021-36934, this one has variously been nicknamed HiveNightmare and SeriousSAM.

The moniker HiveNightmare comes from the fact that Windows stores its registry data in a small number of proprietary database files, known in Microsoft jargon as hives or hive files.

These hive files include a trio called SAM, SECURITY and SYSTEM, which between them include secret data including passwords and security tokens that regular users aren’t supposed to be able to access.

They’re kept in a special, and supposedly secure, folder under the Windows directory called C:\Windows\System32\config, as you see here:

C:\Windows\System32\config> dir
[. . .]
Directory of C:\Windows\System32\config
[. . .]
21/07/2021 12:57 524,288 BBI
25/06/2021 06:21 28,672 BCD-Template
21/07/2021 14:45 32,768,000 COMPONENTS
21/07/2021 12:57 786,432 DEFAULT
21/07/2021 12:32 4,194,304 DRIVERS
[. . .]
21/07/2021 12:57 65,536 SAM <--some system secrets included
21/07/2021 12:57 32,768 SECURITY <--some system secrets included
21/07/2021 12:57 87,556,096 SOFTWARE
21/07/2021 12:57 11,272,192 SYSTEM <--some system secrets included
[. . .]

The moniker SeriousSAM comes from the filename SAM, which is short for Security Account Manager, a name that sounds as serious as the file’s content’s are.

If you have ever used password cracking or hacking tools (or found evidence of them on your network after detecting an active attack), you’ll know that the SAM database is where many cybercriminals start digging in order to try to get hold of administrator credentials to move around your network.

Fortunately, you need to have Administrator access already in order to get at the SAM data in memory, and you can’t get at the SAM registry hive on disk while Windows is running even if you are an Administrator, because the SAM file shown above is locked for the exclusive use of the operating system.

So far, so good.

Who can see what?

We wrote a tiny C program that you can use to get an “accessibility indicator” for any file on the system – it simply tries to open the filename or filenames you put on the command line, and reports the Windows error code if the file couldn’t be opened up for read access.

(The code below is in the public domain so you can do what you like with it, but you use it at your own risk.)

You don’t even need the Windows header files to compile it; you just need to tell your compiler or linker that it needs kernel32.dll and msvcrt.dll:

/* --- CHKIT.C --- */ void *CreateFileA(char *name,unsigned mode,unsigned share,void *sec,unsigned disp,unsigned attr,void *tmpl);
int CloseHandle(void *hnd);
unsigned GetLastError(void);
int printf(char *fmt, ...); int main(int argc, char **argv) { for (int i = 1; i < argc; i++) { printf("Opening file [%s]\n",argv[i]); void *hnd = CreateFileA(argv[i],0x80000000L,0,0,3,0x80,0); if ((long int)hnd == -1) { printf("Failed (GetLastError=0x%08X)\n",GetLastError()); } else { printf("Worked (handle=%ld)\n",(long int)hnd); CloseHandle(hnd); } } return 0;

From an elevated command prompt (one that is running with Administrator privilege), we get the following result:

C:\Users\duck> chkit C:\Windows\System32\config\SAM C:\Windows\System32\config\SYSTEM C:\Windows\System32\config\SECURITY
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000020)
Opening file [C:\Windows\System32\config\SYSTEM]
Failed (GetLastError=0x00000020)
Opening file [C:\Windows\System32\config\SECURITY]
Failed (GetLastError=0x00000020)

Error 0x20 stands for ERROR_SHARING_VIOLATION, described officially by Microsoft as “The process cannot access the file because it is being used by another process.

So far, still good.

Let’s try again from a non-elevated command prompt, where we’re running as a regular user:

C:\Users\duck> chkit C:\Windows\System32\config\SAM
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000020)

Ooooer! That can’t be right!

We should have received Error 0x05, short for the self-explanatory ERROR_ACCESS_DENIED, right away.

Seeing Error 0x20 means that the program was allowed to have a go at opening the file, and failed at that point, instead of being blocked from even trying to access the file in the first place.

And if we look at the ACL (access control list) for the SAM hive file, for instance, using the ICACLS utility, we see that this behaviour is down to a security blunder:

C:\Windows\System32> icacls config\SAM
config\SAM BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) <-- this is wrong - regular users should not have read access! APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX) Successfully processed 1 files; Failed processing 0 files

In other words, the SAM registry data (and the SECURITY and SYSTEM hive files, too) are protected at runtime against access by regular users because the files are in use elsewhere, not because the files are off-limits to regular users from the outset.

We need to fix that vulnerability, and Microsoft’s official workaround is to restrict the access control lists (ACLs) on everything in and below the CONFIG directory.

You need to be Administrator, and to make the following security change:

C:\Users\duck> icacls %windir%\system32\config\*.* /inheritance:e
processed file: C:\Windows\system32\config\BBI
[. . .]
processed file: C:\Windows\system32\config\SAM
[. . .]
processed file: C:\Windows\system32\config\SECURITY
[. . .]
processed file: C:\Windows\system32\config\SYSTEM
[. . .]
Successfully processed 45 files; Failed processing 0 files

Now, the ACL for the SAM file that we checked above looks much healthier:

C:\Windows\System32> icacls config\SAM
config\SAM NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) Successfully processed 1 files; Failed processing 0 files

Also, if we try to open the live SAM registry hive file again from a non-Administrator command promtp, we no longer get Error 0x20.

We now get the more security-conscious Error 0x05, telling us ACCESS_DENIED:

C:\Users\duck> chkit C:\Windows\System32\config\SAM
Opening file [C:\Windows\System32\config\SAM]
Failed (GetLastError=0x00000005)

Still not done!

But that alone is not enough.

If you have any system restore points (also known as Volume Shadow Copies) on your computer, those restore points include copies of your original SAM, SECURITY and SYSTEM registry hive file with the old and insecure access control settings.

In other words, any unprivileged user could just read out data such as your Windows access control secrets or password hashes from the shadow copies instead.

By the way, you may have one or more shadow copies on your computer even if you didn’t go to the System Protection menu yourself and click the [Create] button to generate one.

(A restore point is like an online snapshot or temporary backup that you can use to “rewind” your hard disk’s contents and recover an older version of your system if something breaks, for example after an update that didn’t work out.)

Restore points may have been made by IT at various times; also, system upgrades and even some security software may create restore points automatically for their own use.

You can check for the presence of shadow copies on your computer using the Volume Shadow Copy Service administrative command-line tool, vssadmin.

We’ve got one shadow copy (we created it on purpose for this article), as you can see here:

C:\Users\duck> vssadmin list shadows vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp. Contents of shadow copy set ID: {. . .} Contained 1 shadow copies at creation time: 21/07/2021 14:58:05 Shadow Copy ID: {. . .} Original Volume: (C:)\\?\Volume{. . .}\ Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2 <--this is the directory tree where the shadow file copies can be found Originating Machine: W10 Service Machine: W10 Provider: 'Microsoft Software Shadow Copy provider 1.0' Type: ClientAccessibleWriters Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

What this output tells us is that copies of the registry hive files, at the moment we created the restore point/shadow copy, can be found in this shadow directory:


You simply take the root directory name of the shadow copy volume and add the original Windows filename to it, minus the drive letter, of course.

(In case you were wondering, the weird-looking prefix \\?\ above tells Windows to treat this as a “wide” filename, by using two bytes for each character, even though it’s written as a regular ASCII text string with one byte per character. This allows filenames up to 32KB long instead of the usual ASCII filename limit of 260 characters.)

So, let’s try the chkit program on the shadow copies of the registry hive files, instead of on the live copies that gave us SHARING_VIOLATION and then ACCESS_DENIED errors above.

Using a non-Administrator command prompt, we get:

C:\Users\duck> chkit \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\config\SAM
Opening file [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\System32\config\SAM]
Worked (handle=136)

Simply put, we were able to get access to the SAM file (and likewise to other registry hive backups in the shadow copy directory) even though [a] the system was running and [b] we didn’t have Administrator powers.

What to do?

Microsoft’s official workaround is fairly easy:

  • Reset the ACLs on the live registry hive files using the ICACLS command, as shown above. This protects your system from now on.
  • Remove all existing restore points or shadow copies. This ensures no wrongly-secured files are left behind in a shadow copy directory.
  • Recreate a new restore point, if needed.

Of course, as Microsoft wryly notes, “Deleting shadow copies could impact restore operations, including the ability to restore data with third-party backup applications.

That’s one reason why ransomware crooks almost always delete all your restore points just before they trash your network, to make recovery slower and harder.

In case you’re wondering, the quick way to zap all your restore points is to use the following command as an Administrator:

C:\Users\duck> vssadmin delete shadows /all
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2013 Microsoft Corp. Do you really want to delete 1 shadow copies (Y/N): [N]? y Successfully deleted 1 shadow copies.

In theory, we suspect that you could write a script or program to locate any insecure registry hive backups inside any of your shadow copy directories, and then set the ACLs on those individual files, thus leaving the rest of the restore point intact.

But we’ve not tried doing that, and we’re not sure if a restore point would still work properly if you modified its contents “unofficially” in this way, so we’re not going to recommend it.

Apple iPhone patches are out – no news if recent Wi-Fi bug is fixed

It’s already nearly two months since Apple’s last security update to iOS 14, which was back on 2021-05-24 when iOS 14.6 appeared.

So we weren’t surprised to see that another patch is out, officially listed [2021-07-19] as covering iOS (now on 14.7), tvOS (now also 14.7) and watchOS (now on 7.6).

Annoyingly, there’s no mention of iPadOS, which has typically been listed on the same line as its related iOS update in recent Apple security reports.

Until iOS 13 and iPadOS 13, released as separate products for phones and tablets respectively in September 2019, both types of device ran iOS and therefore inevitably received their updates at the same time. Older, officially supported iPhones and iPads that can’t run version 14 both still run iOS 12 (there is no longer an official build of iOS 13), which is a common product for both phones and tablets. However, iOS 12 updates have typically been appearing out of step with iOS/iPadOS 14 updates recently, so if you have an iOS 12 device, there isn’t an update for you at the moment.

Another annoyance, as we write this, is that Apple still hasn’t given official details of what’s been fixed.

Usually, releases that bump the version number up by 0.1 rather than by 0.0.1 (e.g. 14.6 to 14.7 rather than 13.5 to 13.5.1) include all the security holes that Apple has been working on since the last major update came out.

This means there are ofen several dozen patches, typically with several of them rated as critical importance because they could allow attackers to compromise your phone via a rogue web page or other booby-trapped content.

Sometimes, as we’ve described a few times recently on Naked Security, one or more of the updates consitutes a zero-day, meaning that Apple found out that it needed to patch the hole after it started being exploited in the wild.

Details “soon”

This time, the updates are listed on Apple’s main security update page, but tagged with the disappointing note: Details available soon [2021-07-20T13:00Z]

In particular, this means we can’t yet tell you whether the iOS 14.7 update fixes the recenly publicised “crashtastic Wi-Fi” flaw.

That bug, disclosed in something akin to a comedy of errors by its finder, means that accidentally attempting to connect to a weird network name with a percent sign (%) in it could leave your iDevice blocked from connecting to any network at all, even your own trusted Wi-Fi at home.

Amusingly, at least with hindsight, the bug’s original reporter apparently investigated thoroughly and deeply enough that he locked himself out of his own network completely – even using the Reset Network Settings system option didn’t fix the problem – and had to turn to Twitter for help.

Ultimately, it seems that with some mildly complex scripting shenanigans and a local backup of the phone to his computer’s hard disk, he was able to convince the phone that it should stop trying to connect to any of the poisoned network names that were tripping it up…

…so he was able to recover his device without doing a full firmware wipe-and-restore.

Interestingly, cybersecurity researchers at a company called ZecOps recently claimed that they had researched this “crashtastic Wi-Fi” bug to the point that they felt certain that the bug could be exploited for remote code execution (RCE).

They therefore decided to pitch a new moniker for it, namely Wi-Fi-Demon, arguing that it may pose a bigger threat that merely being a so-called denial of service (DoS) attack.

Their claim is that by using the special text %@ in a network name rather than just %s, a local attacker could “build a partial sandbox escape to help achieve jailbreaking”, or even to infiltrate unauthorised software remotely.

What to do?

Given that this iOS 14.7 update is officially listed as fixing security holes, we’re going to recommend that you check you have it anyway, even before Apple releases an official list of patched flaws.

Use Settings > General > Software Update to check that you have the latest version, and to jump the queue in installing it if you don’t have it yet.

We’ll let you know in due course if this update does, indeed, patch the “crashtastic Wi-Fi” bug (or WiFi-Demon, if you prefer).

By the way, whether it does or it doesn’t fix the wireless problem, we recommend that you regularly revisit and thin out the list of known Wi-Fi networks on your phone anyway.

If you can, consider using Settings > General > Reset > Reset Network Settings on a regular basis to empty out your known networks list, given that iPhones will connect to known networks automatically.

That includes networks on train and bus services you only use occasionally, or at airports or in hotels you haven’t visited lately.

You might be surprised how many known networks your phone or laptop has in its list, even ones that you last connected to months or years ago and that might be under new ownership or have adopted new terms and conditions of use since you last used them.

S3 Ep41: Crashing iPhones, PrintNightmares, and Code Red memories [Podcast]

[01’32”] We explain how a format string bug could lock your iPhone out of your own network.  [08’53”] We revisit the PrintNightmare saga, which is sort-of fixed but not really.  [12’50”] We look back at the 20-year-old Code Red virus.  [18’30”] We look at what cybercriminals spend money on (hint: more cybercrime).  [29’10”] And in this week’s “Oh! No!”, we learn how farm animals can disrupt your network. (Seriously!)

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.


Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.


You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.

Or just drop the URL of our RSS feed into your favourite podcatcher software.

If you have any questions that you’d like us to answer on the podcast, you can contact us at, or simply leave us a comment below.

go top