Perpetual IT

Remember Mt. Gox? Sure you do!

Although it’s usually said aloud as “Mount Gox”, as if it were a topographic feature, it actually started life as MTGOX, short for Magic: The Gathering Online Exchange, where MTG fans could trade cards via the internet.

The web domain was eventually repurposed for what was, back in 2014, the world’s biggest Bitcoin cryptocurrency exchange.

Mt. Gox was headquartered in Japan, holding what was then a mind-blowing $500,000,000 in other people’s bitcoins (BTC).

And then a strange thing happened: the money, or at least the bitcoins, vanished, just like that.

We’ve never really found out what happened.

Early suggestions blamed a cryptographic flaw known as transaction malleability, but sceptics argued that this sort of treachery, even if if were possible on such an epic scale, would be visible in the Bitcoin transaction record, also known as the blockchain.

Simply put, transaction malleability means that two different transactions can be rigged to have the same supposedly unique identifier. Crooked transactors could, in theory, fraudulently concoct duplicate-yet-different transaction pairs, and use these transactions to trick a naive exchange into thinking that something had gone wrong. Them the crooks could dishonestly repudiate one of the transactions in each pair and demand a refund.

Some people suspected Mt. Gox insiders of simply taking the missing bitcoins (or some of them, anyway) for themselves.

Indeed, on New Year’s Day 2015, Japanese newspaper Yomiuri Shimbun publicly stated that there was “strong suspicion” that most of the missing Bitcoins were ripped off from inside.

Yomiuri Shimbun’s considered opinion was that no more than 1% of the loss could be explained by external hacking or cyberscamming – for example due to transaction malleability tricks – and therefore that 99% of the loot had simply been plundered from within.

Intriguingly, Mt. Gox founder Mark Karpelès was arrested, and ultimately given a suspended prison sentence in Japan, but not because of the missing bitcoins – he was found guilty of mispreresenting the value of his company to make it look like a better investment.

Even more weirdly, lawyers for Ross Ulbricht, currently serving two life sentences in the US for running the infamous Silk Road site on the dark web, argued – without success, given that their client was convicted – that it was Karpelès, not Ulbricht, who was behind the notorious website.

And in what may be the weirdest cryptocurrency twist of all in this part of our story, a federal agent from the US Secret Service, Shaun Bridges, who investigated the Silk Road case, was himself convicted of stealing several hundreds of thousands of dollars of bitcoins from the Silk Road site.

Bridges (and you have probably guessed this by now) stashed his ill-gotten gains on the Mt. Gox exchange.

You couldn’t make this stuff up… and, at the end of it all, we still can’t answer the question, “What really happened when Mt. Gox got hacked?”

Plus ça change

Well, we’re now in the middle of In other episode of the “Cryptocurrency Truth is Stranger than Fiction” saga.

Online blockchain company Poly Networks, which describes itself as a company that was “built to implement interoperability between multiple [block]chains in order to build the next generation internet infrastructure”, has been hacked.

A blockchain, simply put, is a public ledger that lists details such as financial payments or contractual agreements.

A contract might be some sort of algorithm such as “when Pete sends me the $50 he owes me, I’ll automatically pay $20 of that to Jane, send $15 to Naledi, and keep the rest in my cryptocoin wallet.”

A transaction might record that “wallet B457F has transferred $30 to wallet 7EE19, with $4.50 of transaction fees claimed from B457F by wallet 1445A”.

As you can imagine, a hacker who could inject fraudulent contracts and transfers into a system of this sort could wreak havoc, for example by triggering a series of automated payments into cryptocoin wallets of their own, and then running off with the proceeds.

And that it exactly what seems to have happened to Poly Networks, apparently to the tune of $600,000,000, dizzyingly breaking the Mt. Gox “megahack” record by some $100 million.

What happened?

How the hack happened is not yet certain.

Some reports are blaming the attack on “stolen private keys”, which basically implies that the hacker got hold of the authentication codes needed to approve a whole raft of fraudulent activities.

Twitter user @kelvinfichter, however, who tweets under the self-assured name of God-like Natural Number Creator Person (TM, R), claims to have identified various cryptographic blunders in Poly Network’s transaction protoocol.

For anyone still confused, here’s the hack depicted as a beautiful gif pic.twitter.com/Shg5Tdf21Z

— God-like Natural Number Creator Person (TM, R) (@kelvinfichter) August 10, 2021

Fichter says that this blunder would have allowed the hacker to set the fraudulent transactions in train using cryptographic keypairs they had created themselves.

This means that, instead of being forced to use public keys that could only be verified by private keys held by other principals in the transaction, the hacker was able to use public keys for which they themselves had the matching private keys.

That’s a bit like appearing on a criminal charge where your defence attorney not only gets to present your case to the court, but then also gets to act as judge and jury in deciding whether to acquit you.

Would you like your money back?

Astonishingly, the hacker decided to send a note to Poly Networks.

And what better way than to generate a public transaction with no value, but with some added data, like this:

The Input Data field above, 52454144 5920544f 20524554 55524e20 54484520 46554e44 21, is the ASCII encoding of the message:

 READY TO RETURN THE FUND!

That was followed a minute later by another hidden message:

This time, the hexadecimal data above decodes as:

 FAILED TO CONTACT THE POLY. I NEED A SECURED MULTISIG WALLET FROM YOU

Since then, Poly Networks has asked as follows:

As far as we can see [2021-08-11T15:00Z], the ETH account above has only received about $3000 so far.

But the Polygon wallet has picked up $1,010,100.

That “binary-like” number is apparently the result of three transactions in quick succession this morning, first of $100, then $10,000 and then a full $1,000,000:

According to other reports, Poly Networks has also received a repayment of $622,000 in a cryptocoin known as Fei, and a whopping 260 billions’ worth of SHIBA INU cryptocoins.

As dramatic as the last “refund” might sound, the current exchange rate for SHIBA INU is about 125,000 SHIBs to the US dollar, assuming you could find anyone to cash them out into hard currency, so the nominal value there is about $2,000,000.

Unfortunately, that leaves Poly Networks short by more than 99% of the funds that originally went missing, given than the total theoretical value of the cryptocoins returned is about $4,000,000.

What next?

As in the Mt. Gox case, we may never discover the full truth of what happened.

Poly Networks may never get the funds back, and as for how much the company’s customers stand to lose, we can only guess.

Perhaps the hacker or hackers are now fearful of being caught, and will aim to make amends?

Perhaps they will eventually return all, or at least most, of the vanishing cryptocoins?

Perhaps the hackers are just playing with Poly Networks and have no intention of paying back more than they have already?

Only time will tell.

What to do?

In the meantime, we will leave you with two suggestions:

• If you’re thinking of getting into the cryptocurrency scene, never invest more than you can afford to lose. There are more than 10,000 different cryptocoins currently in existence, many of which were kicked off by cash injections from early investors. Not all cryptocoins can or will follow the Bitcoin pattern of going from a few cents in value in 2010 to $40,000 each in 2021. Even worse, some are outright scams in which the “creators” of the cryptocoinage collect startup funds from early investors in what’s known as an ICO (initial coin offering), only to run off without ever establishing the new cryptocurrency at all.
• If you plan to buy and hold cryptocurrency, keep as much of you can offline in what’s known as a cold wallet. A cold wallet is an encrypted file that you keep where you won’t lose track of it, and where other people can’t use it unless they know your password.

---

Evan Grant, a researcher at network security scanning company Tenable, recently decided to have a go at hacking a home router.

The idea, it seems, was more to learn about the general techniques, tools and procedures available to router hackers than to conduct a security assessment of any particular product.

Understandably, therefore, Grant picked a router model using two non-technical criteria: was it popular, and was it available in Canada (Grant’s home country)?

After opening up the router casing to get access to the circuit board, Grant made good progress, by quickly:

• Finding likely pins on the circuit board where a debugging device could be connected.
• Identifying the correct wiring for the debugging circuity to permit a serial connection.
• Getting a root shell via a serial line and accessing the files on the device.

Grant’s first stop was to download a binary file (executable program) called httpd, which is the name under which you typically find a home or small business router’s web server, used for managing the device from a browser.

The name httpd stands for HTTP daemon, where HTTP means that the program handles web traffic, and daemon is the Unix/Linux name for what Windows users know as a service: software that runs in the background whether anyone is logged in or not. (The word daemon is properly pronounced “die-moan” or “day-moan”, but many sysadmins just call them “demons”, and you may need to follow suit to avoid causing confusion.)

Bugs found

Disassembling the web server binary revealed critical bugs, caused by programming errors, that Grant was able to chain together to take over the router via its web interface without needing a password.

Firstly, the router had a list of built-in web server subdirectories where authentication was not required, so that “harmless” files such as as http://[router]/images/logo.png would work for everyone.

(A company logo isn’t a secret, so why not let anyone access it, whether they’ve logged in already or are still stuck on the login page?)

But once the router had matched the name of the “harmless” subdirectory, it didn’t bother applying any other security checks such as looking for risky characters in the filename.

This means that Grant could use a filename such as /images/../login.htm in the URL as an unauthenticated equivalent to web pages that would otherwise prompt for a password or block access entirely, such as http://[router]/login.htm.

This sort of bug dates back decades, and is known as a directory traversal vulnerability, because the special directory name .. (two dots) is shorthand for “go up one directory”.

Thanks to the “go up one” component, the file named /images/../login.htm actually refers to a file that sits above the /images subdirectory, not in the directory tree underneath it.

Directory traversal bugs that rely on the “go up one” trick often show up in logs with filenames such as ../../../../../etc/passwd or ../../../../Windows/System32. The trick here is that if you “go up” by more subdirectories than your current depth in the directory tree, you don’t get an error. Once you get to the root directory, every subsequent ../ simply gets ignored, because “one up” from the root directory is just the root directory again. So, a filename preceded by sufficiently many apparently innocent relative pathnames of ../ is equivalent to a dangerous and suspicious absolute filename such as /etc/password (the list of Unix usernames) or C:\Windows\System32 (the all-important Windows directory where system software lives).

Secondly, the router set an authentication cookie, valid for any other password-protected page, as soon as a page was accessed for which authentication was supposed to have taken place.

In other words, the authentication token wasn’t generated as a side-effect of a correct password being entered, but merely as a side-effect of a protected page being accessed, even if that page itself was reached via an authentication bypass.

Simply put, a bypass in one place, using the abovementioned directory traversal bug, led reliably to bypasses elsewhere.

(Curiously, the authentication token used by the router wasn’t supplied as a web cookie, but embedded in an inline image object called spacer, where JavaScript from the router could decode it and use it to access other password-protected pages.)

Reporting the bug

This directory traveral bug was duly reported to the relevant router vendor, Buffalo, and received the vulnerability identifier CVE-2021–20090.

However, the story didn’t end there, because Grant (who did his original research with a Buffalo WSR-2533DHPL2 router) eventually realised that this wasn’t so much a router vendor’s bug as a firmware vendor’s bug.

In other words, it wasn’t just Buffalo routers that were at risk.

Tenable ultimately identified and listed 37 widely-used products that all shared code from router and firmware vendor Arcadyan, including several products from Arcadyan itself.

The bug itself, it seems, has been present in Arcadyan’s code, unnoticed until now, since 2008.

Affected products include routers shipped by well-known ISPs around the world, including BT, Deutsche Telecom, KPN, O2, Orange, Telecom Argentina, TelMex, Telstra, Telus, Verizon and Vodafone.

All of these products ought to have updates available by now, but we don’t know how many products currently in use have actually downloaded and installed those updates yet.

Unfortunately, according to follow-up reports from researcher at Juniper, cybercriminals are already probing the internet for vulnerable devices.

So, if you’re affected by this bug, or think you might be, we urge you to check for updates as soon as you can.

What to do?

• Check Tenable’s list to see if your router is affected. Some routers reveal details such as model and serial numbers in their management console, so try logging in and consulting the relevant router information pages. Unfortunately, many ISP-supplied routers don’t list the original manufacturer’s name or model number on the outside of the router itself. If in doubt, consult your ISP. (Our home internet provider is on the list, but were able to infer, simply from the format of our router’s firmware version number in the console, that it was almost certainly not one of the affected models.)
• Make sure you have your router’s latest firmware. Even if you aren’t on the danger list this time, use this as a good reason to check that you are up-to-date anyway. Some ISPs, such as ours, set up their routers to update automatically, but it’s still worth making regular checks to ensure that those updates are being installed and applied as expected.
• Avoid turning on remote access to your router’s management console. Most modern routers restrict access to the web console to the internal network only by default, but include an option to enable remove access if you want. Make sure this option is turned off unless you are absolutely certain you need it. There is no point in exposing your router’s web server directly to the internet unnecessarily.
• Never enable remote access to your router on the say-so of someone you don’t know. Crooks often contact you via email or phone claiming that they are “there to help”, and then demand remote access to your router or your computer to “fix” an imaginary “problem”. These technical support scammers often brashly claim to be from Microsoft, Google, your ISP or even from the police. They may become threatening and aggressive when challenged. Don’t be intimidated. You didn’t ask for help, so you do not need to accept it – just hang up or ignore their emails, and consult someone you know and trust instead.
• If you are a programmer, verify all your input. Any software that accepts data supplied across the network must assume that any input that it receives might be booby-trapped to probe for vulnerabilities. System commands, directories and filenames need special care because there are many characters and character sequences that have a special meaning when used in those contexts, like the infamous “dot-dot” sequence mentioned above.

---

HOW TO PROBE FOR THE BUG ON YOUR OWN NETWORK

According to Tenable’s report, you can perform a basic test on your own router by finding the URL for a page that you know exists, such as http://[router]/home.htm, and verifying that it comes up if you visit it.

Then you try to visit the same page via the “go up one” trick described above, and verify that the page does not come up, which is evidence that the directory traversal bug CVE-2021-20090 either doesn’t exist or has already been patched on your device.

From the command line, you could use the curl program, available on Windows, Mac or Linux, as shown here.

You need to replace the text [router] with the name or IP number of your own router – if you aren’t sure what that is, try 192.168.0.1, 192.162.0.254, or 192.168.1.254.

You also need to find a web page such as home.htm, index.htm or login.html that exists on your device, and that produces some content whether you are logged in or not:

$ curl -D - http://[router]/home.htm <-- "-D -" says to dump the headers as well as the body HTTP/1.0 200 OK <-- Here comes the HTTP response
Server: httpd <-- Followed by the headers
Date: Tue, 10 Aug 2021 14:05:01 GMT
Content-Type: text/html
[. . .] <-- Followed by a blank line
<!DOCTYPE html> <-- Followed by the HTML data
<html lang="en" <head> <title>Home</title>
[. . .]

If your router is vulnerable, then trying to access the same page via the filename /images/../home.htm should give the same result as above, because that implies your router will accept the “dot-dot” directory traversal trick.

If your router is not vulnerable to CVE-2021-20090, then the directory traversal will fail and the “dot-dot” trick will not work, which should result in a “404 Not Found” error.

Note that you can’t just write /images/../home.htm in the URL, because curl, or your browser, will automatically simplify it before making the request.

You need to represent the third slash character in the URL with its hexadecimal URL “escape code” %2F (the ASCII encoding of /), like this:

$ curl -D - http://[router]/images/..%2Fhome.htm <-- Try to exploit a directory traversal "go up" trick HTTP/1.0 404 Not Found <-- A 404 error suggests that the exploit *failed*
Server: httpd
Date: Tue, 10 Aug 2021 14:13:32 GMT
Content-Type: text/html
[. . .] <HTML> <-- Followed by some kind of message to say so
<HEAD><TITLE>404 Not Found</TITLE></HEAD>
<BODY<H4>404 Not Found</H4>
[. . .]

---

[00’26”] Timezone curiosities – when modular arithmetic gets weird
[04’38”] Microsoft researcher found Apple 0-day in March, didn’t report it
[13’18”] Retro computing – the TRS-80 arrived in August 1977
[19’17”] BazarCaller – the crooks who talk you into infecting yourself
[33’02”] Oh! No! A billionaire… but only for 5 minutes

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

---

WHERE TO FIND THE PODCAST ONLINE

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 tips@sophos.com, or simply leave us a comment below.

---

If you like a touch of irony in your cybersecurity news, then this has been the week for it.

Yesterday, we wrote about an exploitable security hole…

…inside a hacking tool that helps you exploit security holes.

Today, we’re writing about a ransomware-related data breach that leaked organisational information…

…from inside a ransomware group.

And if that’s not enough to bring a wry smile to your lips, then there’s more.

Today’s data breach includes a bunch of hacking tools that ransomware crooks love to use…

…including a buggy and exploitable pirated version of the very attack tool that we wrote about yesterday!

Simply told

The story, it seems, is simply told.

As you already know, many of today’s ransomware attacks aren’t conducted by the core criminals who actually write the malware code.

The core crooks like to keep out of the limelight by recruiting “affiliates” to handle the actual network intrusions.

(These cybergangs often use regular business vocabulary, even referring to their victims as “customers” and describing their extortion attempts as “negotiations”.)

In theory, affiliates can get really rich, because they typically get paid 70% of any ransom that gets extorted – and individual ransoms can run into millions of dollars these days.

And in practice, the core criminals – the ones who write the malware, operate the “affiliate system”, and collect the Bitcoin blackmail payments – can get super-rich, because they get 30% of everything.

However, according to The Record, which published a screenshot of a post in a cybercrime forum by a user discussing the Conti ransomware crew:

Yes, of course they recruit suckers and divide the money among themselves, and the boys are fed with what they will let them know when the victim pays.

The implication, clearly, is that affiliates in the Conti ransomware crew are not being paid 70% of the actual ransom amount, but 70% of an imaginary but lower number.

The critical user followed up the post above with one linking to an 81MByte archive file named Мануали для работяг и софт.rar (Operating manuals and software).

Dishonour amongst thieves, it seems.

No vital secrets

Ultimately, the data leaked by the disaffected affiliate doesn’t really amount to much.

The criminals at the core of so-called ransomware-as-a-service groups keep the source code, the decryption keys and the blackmail payment details to themselves.

So, this leak won’t help any ransomware victims to decrypt scrambled files without paying.

In fact, if you are minded to get a copy of the leaked files for yourself to see what this is all about, in the hope that it might give you some tricks and tips for defending against ransomware that you didn’t already know…

…please be careful, because the files include numerous hacking and system exploitation tools, conveniently collected in one place, together with instructions and advice (mostly written in Russian).

Think of it as a dump of the Conti gang’s community knowledgebase, with plenty of risky software thrown in.

If you’re a Sophos customer, you can use the following detection names to search your own logs for the tools included in the breach:

ATK/PowSploit-E <-- Kerberoast, used for attacking Active Directory logons ATK/Cobalt-* <-- "Cobalt Strike", a complete botnet system for "threat emulation"
ATK/Shellcode-* <-- Exploit injectors included in Cobalt Strike
Troj/Agent-* <-- Various backdoor "zombie" modules include in Cobalt Strike GMER <-- Popular detector/remover for rootkits (and security software)
Harmony Loader <-- Toolkit for fileless execution of programs via C-Sharp
PC Hunter <-- Low-level security spelunking tool
PowerTool <-- Another low-level security spelunking tool
Stas'M Router Scan <-- Scans and looks for holes in routers, Wi-Fi access points and more

Documents leaked in the breach offer basic advice on numerous topics, including:

• Dumping password hashes.
• Turning Defender off by hand.
• Installing and using Metasploit.
• Scanning networks for backup devices.
• Opening backdoors into a compromised network.
• Using popular exploits.
• Elevating privilege.
• Listing users.

There’s also a small collection of tools for disabling or uninstalling various anti-virus programs.

There’s even a dramatically named batch file called DIEsophos.bat in the mix. (It’s hard to know whether to be proud or angry that the criminals felt strongly enough to use CAPITAL LETTERS in their filename.)

According to our Managed Threat Response (MTR) team, if Sophos customers have Tamper Protection enabled, then the anti-Sophos measures in the leaked documents won’t work, even if the attacker is already an Admin and can get into Windows Safe Mode. If you aren’t using Tamper Protection, we recommend you turn it on now.

What to do?

We’re going to repeat the advice that we gave yesterday in the wake of the Cobalt Strike bug:

If your security tools come up with a “Cobalt Strike” alert, or reports that relate to any of the techniques and tools that we mentioned above, we recommend that you investigate immediately, even if your cybersecurity software tells you that it automatically blocked and removed the rogue software that caused the alert.

That’s because intrusions of this sort mean that someone was trying to establish a beachhead inside your network, perhaps for a ransomware attack, perhaps for a data heist, perhaps for both, or perhaps for a range of other criminal activity, too…

…and if they got in once, it’s reasonable to assume that if you don’t find and close the door on them, they (or someone else) will get in again, because that’s quite literally what cybercrooks do for a living.

The good news here is that the leaked data doesn’t really tell us anything we didn’t already know, or introduce any new tools or techniques that the typical cybercrook didn’t already know about, either.

The bad news here, of course, is that the leaked data doesn’t really tell us anything we didn’t already know.

So if you were hoping that the leak was going to be juicy enough to include free decryption keys, or personally identifiable data that might help law enforcement to track down some of these criminals…

…not this time, we’re sorry to say.

---

If you’re a regular reader of Naked Security and Sophos News, you’ll almost certainly be familiar with Cobalt Strike, a network attack tool that’s popular with cybercriminals and malware creators.

For example, by implanting the Cobalt Strike “Beacon” program on a network they’ve infiltrated, ransomware crooks can not only surreptitiously monitor but also sneakily control the network remotely, without even needing to login first.

Indeed, if your threat detection software comes up with a “Cobalt Strike” alert, we recommend that you investigate immediately, even if your cybersecurity software reports that it blocked and removed the rogue software automatically.

That’s because a Cobalt Strike intrusion means that someone was trying to establish a beachhead inside your network, perhaps for a ransomware attack, perhaps for a data heist, or perhaps for both…

…and if they got in once, it’s reasonable to assume that they (or someone else) will get in again if you don’t find and close the door on them, because that’s quite literally what cybercrooks do for a living.

Unassumingly fitting in

The Cobalt Strike Beacon program unassumingly pretends to be a web client, just like a browser or an official software auto-updater, and regularly calls home to a designated server using innocent-enough web requests, just like a browser or a legitimate auto-update tool.

But those call-home requests aren’t innocent at all: the computers they’re connecting to are known in the jargon as C&C servers, or C2s for short, where the Cs in the name stand for Command and Control.

Software implants that work in this way are generally referred to as bots (short for robots) or zombies, and they work well even on networks that have strict firewall rules to block incoming connections.

That’s because zombies don’t need to listen out for incoming requests, like web servers or SSH (remote login) servers do.

Instead, they use their innocent-looking outbound requests not only to upload data stolen from inside the network, but also to download the latest command and control instructions from their aptly named C&C servers at the same time.

Hotcobalt, the botnet beheader

Well, researchers at Sentinel One have just announced a brand new BWAIN – our shorthand for Bug With An Impressive Name – entitled Hotcobalt, which is a command processing bug in the Cobalt Strike server code.

The Hotcobalt bug means that a beacon that misbehaves – whether by accident or design – can crash the C&C server it’s talking to…

…thus stranding the botnet of zombies that are currently reporting to it, leaving them at least temporarily unable to take further commands.

Botnet, short for robot network, is the collective noun for a related group of bots or zombies that are all under the control of the same botherder or botmaster.

Bug or feature?

At this point, you’re probably wondering whether this should really be called a bug, given that it could be used to crash someone else’s server, or a feature, given that it could be used to disrupt cybercriminality by temporarily “beheading” an entire botnet in a single strike.

In fact, is is a bug: it has an official designation, CVE-2021-36798, and was officially patched on 2021-08-04 in Cobalt Strike version 4.4.

That’s because Cobalt Strike, for all its popularity with cybercrooks, is actually a commercial software package that’s sold as “threat emulation software” and is widely used by legally approved penetration testers and legitimate researchers.

(Cobalt Strike is not openly available for download, and not just anyone can buy it, but that hasn’t stopped the cybercrime community from acquiring it via theft or subterfuge and using it anyway.)

Trusting other people’s data

The bug was apparently caused by an easy-to-make programming error: putting too much trust in data received from someone else.

When exfiltrating a stolen screenshot, the Beacon program would announce and transmit the image data as a 4-byte image size, followed by that many bytes’ worth of data.

The server would read in the size specification, allocate enough memory to handle the request, and then download the exfiltrated data into the memory block that it just created.

What the server didn’t do was to decide in advance whether the specified memory allocation size was reasonable or safe to use.

So, with 4 bytes (32 bits) to play with, a miscreant could create a battery of unofficial “here comes a screenshot” requests, each one asking the server to reserve up to 2³²-1 bytes (4GBytes) in advance.

Although 4GBytes isn’t considered a lot of memory these days (contemporary mobile phones typically have 6GB to 8GB each), multiple requests to allocate 4GB will quickly bog down your server-side code, even on the beefiest hardware.

In 32 bits, you can’t represent the number 2³² directly, because you can only represent 2³² distinct values, one of which is 000..000, or zero. You can therefore count only as far as one less than 2³² before your addition wraps back round to zero. To visualise this, think of the Y2K bug, where the year AD1999 was followed not by AD2000 but by AD1900 all over again. With just two decimal digits to play with, you could store 100 different values ranging from 00 to 99, representing 1900 to 1999. When you computed 99+1, you didn’t have the three digits you needed to “carry one” and represent 100, so you jumped back to 00, dramatically losing a century in the process.

What to do?

• If you’re a programmer, check untrusted inputs carefully. In networking protocols, many data fields are large enough to represent values well outside a sensible range for your program. Whether you’re checking for dates that are unrealistically long ago, iteration counts that would last unfeasibly long, or memory or file sizes that just won’t fit into reality, always remember to validate your input carefully.
• Assume that all inputs are untrusted. Apply the doctrine of zero trust, and assume that even inputs that come from what appears to be a trusted source, such as a computer on your own network (or a Beacon that’s calling home to your own server), may have been generated by software that contains bugs, or that has itself been compromised.
• Never ignore security alerts that indicate possible C&C activity. Few cyberattacks these days are caused by self-spreading, standalone computer virus attacks, where the virus itself is both the threat and the intruder. Automatic detection and remediation is no longer enough on its own. Aim to investigate any threat detection that could be the side-effect of an attacker who is already inside your network, in order to ensure that you address both the symptom and the cause.
• If you are a legitimate Cobalt Strike customer, you’d better update. The version that fixes this bug was released on 2021-08-04 and is numbered 4.4

---