Perpetual IT

How a social engineer ripped off a victim lured in by one of those “small outstanding fee to pay” home delivery scams. The ransomware crooks targeting networks that still haven’t done their Hafnium patches. And the Linux kernel security holes that lay there undiscovered for 15 years.

With Kimberly Truong, Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

Here are the links that we said we’d put in the shownotes:

---

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.

It’s three weeks since the word HAFNIUM hit the news.

The word Hafnium refers to a cybergang who are said to focus on stealing data from pretty much anyone and everyone they can infiltrate, across an eclectic range of industry sectors, and this time they hit a sort-of cybercrime jackpot.

The Hafnium crew, it turned out, not only knew about four zero-day vulnerabilities in Microsoft Exchange, but also knew how to exploit these bugs reliably in order to walk into unprotected networks almost at will.

The Exchange bugs didn’t include a remote code exeution (RCE) hole to give the crooks the direct and immediate access to a compromised server, but the bugs did allow the crooks to rig up RCE using a trick known as a webshell.

Greatly simplified, the attack goes like this:

• Exploit the Exchange bugs to write a booby-trapped web file called a webshell onto a vulnerable server.
• Trigger the booby-trapped web page hosting the webshell to run a Powershell (or similar) command to download further malware, such as a fully-featured backdoor toolkit.
• Enter at will and, very loosely speaking, commit whatever cybercrimes are on today’s “to do” list.

Unfortunately, as we explained when this news first broke, the name Hafnium caused fourfold confusion:

1. Although Hafnium is often written in ALL CAPS, it’s not an acronym, so it doesn’t stand for something specific that you can protect against and then stand down from.
2. Although Hafnium refers to a specific cybergang, the zero-day exploits they were using were already widely known to other criminals, and working examples soon became available online for anyone and everyone to download and use, both for legitimate research and for launching attacks.
3. Although Hafnium attacks were associated with Microsoft Exchange in media coverage, the attacks these crooks were carrying out once they got in were not specific to networks using Exchange. The cybercrimes they ultimately committed could be initiated in many other ways.
4. Although Hafnium was associated with data exfiltration and thus with potential industrial espionage, intrusions via these Exchange bugs could lead to many other crimes, notably including ransomware attacks.

It’s the last of these issues that concerns us here, because the Sophos Managed Threat Response team recently investigated a number of cases in which networks that hadn’t been patched against the abovementioned Exchange bugs had been infiltrated and attacked by a strain of ransomware going by the dramatic name of BlackKingdom.

In case you’re wondering, the crooks variously refer to their own ransomware using two words, weirdly written Black KingDom, as well using one word, as we’ve written it here. (We’ll stick to BlackKingdom in order to make it clear that we are talking about a specific threat, in the same way that we might write WannaCry or TeslaCrypt.)

The bugs exploited in this case are now widely referred to as ProxyLogon, which is the popular name used to refer to attacks that start off by using the Exchange bug CVE-2021-26855, typically followed by using CVE-2021-27065 and perhaps CVE-2021-26857 and CVE-2021-26858. The name ProxyLogin is a better word to use than Hafnium if you’re specifically talking about an intrusion initiated by those bugs, because the name isn’t tied to any criminal gang, and doesn’t imply any specific reason for the attack.

How it works

If you’re after the low-level details of BlackKingdom, you’ll be glad to know that SophosLabs has published a technical analysis of the malware program that does the dirty work.

Read the Labs report if you want to find out exactly how the malware works, and to get indicators of compromise you can look for on your network and in your own logs.

Although BlackKingdom is not technically sophisticated, that’s cold comfort if it’s just scrambled all your files.

As SophosLabs put it:

[O]ur early analysis reveals that it is somewhat rudimentary and amateurish in its composition, but it can still cause a great deal of damage.

What it does

Like many families of ransomware, this one:

• Skips folders needed to keep Windows running, including ‘C:\Windows’, ‘C:\Program Files (x86)’, ‘C:\Program Files’ and various folders under your ‘AppData’ directory. The crooks want to be sure you can still boot Windows, read their blackmail demand and get online to buy bitcoins to pay the extortion.
• Stops any SQL server processes running, if the malware has administrator level powers, thus unlocking up your database files so that they can be attacked along with everything else.
• Scrambles files on all drives it can find, including mounted network drives and removable disks that were plugged in at the time.
• Overwrites files in place, so there are no temporary copies of your unencrypted files left behind. This makes it hard to restore files by using disk recovery or “undelete” tools.
• Chooses a new encryption key for each computer, so that the decryption key for one PC won’t work on another.
• Never saves the decryption key to disk, so that you can’t undelete or easily recover it later. The malware uploads the key from your computer to an online file storage service, where the crooks can later download it but you can’t.
• Pops up a blackmail demand when it’s done. The malware also writes a text file with the criminals’ demands in it to a file called decrypt_file.TxT.
• Deletes the Windows Event logs, if it can, making it harder and more time consuming to try to figure out exactly what happened afterwards.

The blackmail demand starts like this:

***************************
| what happened ?
*************************** We hacked your (( Network )), and now all files, documents, images, databases and other important data are safely encrypted using the strongest algorithms ever.
You cannot access any of your files or services .
But do not worry. You can restore everthing and get back business very soon ( depends on your actions ) before I tell how you can restore your data, you have to know certain things : We have downloaded most of your data ( especially important data ) , and if you don't contact us within 2 days, your data will be released to the public.

The amount demanded is $10,000 in Bitcoin for each computer attacked:

1- Send the decrypt_file.txt file to the following email ===> [REDACTED] 2- send the following amount of US dollars ( 10,000 ) worth of bitcoin to this address : [REDACTED] 3- confirm your payment by sending the transfer url to our email address 4- After you submit the payment, the data will be removed from our servers, and the decoder will be given to you, so that you can recover all your files.

Whether or not the criminals behind this attack really are routinely stealing their victims’ files before scrambling them, we aren’t sure.

However, as you will see from the SophosLabs analysis, the ransomware program that produces this message was installed and executed using the ProxyLogon exploits, which allow remote crooks to implant and run almost any program they want.

So even if they didn’t steal all your data first, they almost certainly could have…

…and so could any other crooks who came across your unpatched servers before, during or after the BlackKingdom attack.

What to do?

• Patch early, patch often. If you’re genuinely think uou are at risk of a BlackKingdom attack unleashed via the ProxyLogon exploits, your network is as good as open for anyone to get in and do almost anything, at any time they want.
• Do your backups. That way you can recover from losing your data no matter how it happens. A simple memory aid is “3-2-1”, which means you should have at least three different copies (the one you are using now plus two or more spares), using at least two different backup systems (in case one should let you down), and with at least one copy stored offline and preferably offsite (where the crooks can’t tamper with it during an attack).
• Peruse your logs. Crooks don’t always succeed at their first attempt, so keep your eye open for signs that an attack may be under way.
• Consider an anti-virus with data scrambling protection. For example, Sophos endpoint products include CryptoGuard, which detects ransomware generically by how it behaves, not by what it looks like. If CryptoGuard spots what it thinks is a rogue file-encrypting program, it can not only step in to block the attack but also automatically reverse any encryption that’s happened so far.

By the way, there are a few peculiarities about the BlackKingdom malware that give you a small (though it may admittedly only be a very small) chance of recovering your data, even if you don’t have a backup, without paying the criminals for the decryption key.

So if you do end up as a victim of this attack, talk to someone you know and trust for advice before you rush into any ill-considered response.

If you have suffered any sort of cybercrime attack, including but not limited to ransomware, and you don’t have an IT partner of your own to turn to, the Sophos Managed Threat Response or Sophos Rapid Response team would be happy to hear from you.

---

---

Just one tiny line of script in your Xcode project – and you’ve been pwned!

Learn all about it, and what you can do to avoid supply chain problems if you’re a coder yourself:

[embedded content]

Watch directly on YouTube if the video won’t play here.
Click the on-screen Settings cog to speed up playback or show subtitles.

Why not join us live next time?

Don’t forget that these talks are streamed weekly on our Facebook page, where you can catch us live every Friday.

We’re normally on air some time between 18:00 and 19:00 in the UK (late morning/early afternoon in North America).

Just keep an eye on the @NakedSecurity Twitter feed or check our Facebook page on Fridays to find out the time we’ll be live.

Remember XcodeGhost?

It was a pirated and malware-tainted version of Apple’s XCode development app that worked in a devious way.

You may be wondering, as we did back in 2015, why anyone would download and use a pirated version of Xcode.app when the official version is available as a free download anyway.

Nevertheless, this redistributed version of Xcode seems to have been popular in China at the time – perhaps simply because it was easier to acquire the “product”, which is a multi-gigabyte download, directly from fast servers inside China.

The treachery of XcodeGhost was that the malware inside the download didn’t directly affect the computers on which the booby-trapped Xcode version was used.

In almost every respect, the malware-laden version worked identically to the real thing – because, in almost every respect, it was the real thing.

However, the hacked version of Xcode would add malware into iOS apps when they were compiled on an infected system, without infecting the source code of the app itself.

The implanted malware was buried in places that looked like Apple-supplied components, with the result that Apple let many of these booby-trapped apps into the App Store, presumably because the parts compiled from the vendor’s own source code were fine.

As we said at the time, “developers with sloppy security practices, such as using illegally-acquired software of unvetted origin for production builds, turned into iOS malware generation factories for the crooks behind XcodeGhost.”

As you probably know, this sort of security problem is now commonly known as a supply chain attack, in which a product or service that you assumed you could trust turned out to have had malware inserted along the way.

Meet “XcodeSpy”

Well, researchers at SentinelOne have just written up another supply chain attack they’ve discovered that is directly targeting incautious Xcode developers, and they’re calling this one XcodeSpy.

It’s much smaller and simpler than XcodeGhost, and this time it doesn’t infect programs that you compile, although it still does its dirty work when you compile.

The malware is delivered in the form of a booby-trapped version of a legitimate Xcode project that the crooks used as a cover name for their malware.

The “donor” project that was ripped off to act as a carrier was an open-source library called TabBarInteraction created by a GitHub user going by the name of Potato04.

We don’t know why the unfortunate Potato04 was chosen by the crooks, and we don’t know if any other projects were targeted – for all we know, this may have been some sort of test-run using a project that the attackers guessed their victims were using at the time.

Interestingly, the crooks stripped out all the useful code in the project, but inserted executable script code into the PBXShellScriptBuildPhase part:

As the name suggests, this script gets called as a side-effect of building the project, so the malicious code doesn’t end up in the files that are supposed to be created by the build – those will come out unaffected, assuming the build still works with the bogus project in place,

However, the rogue shell script runs alongside all the other tasks such as compiling and linking that happen when developers click the [Build] button, effectively giving it a chance to hide in plain sight.

That’s because most project builds involve reading, creating, writing and manipulating dozens, hundreds or even thousands of files, as anyone who has ever compiled their own Linux kernel will know, so it’s a handy time for unexpected code to run unnoticed in the melee of system activity.

Most build logs get searched for things that were supposed to work but didn’t. Commands that weren’t supposed to happen at all but worked just fine are easily overlooked, meaning that build-time malware that doesn’t draw any attention to itself could go unnoticed for ages.

The malware unravelled

The script code that the crooks added into the project was inserted as follows:

Extracting the executable script code from the project file, we can see that it first sets a series of Bash shell variables, each of which contributes a few characters to the final malware string:

Next, the malicious script stitches the above short fragments together in a different order, and runs them as a new command, using the Bash function eval, short for evaluate-and-execute:

In the code above, you need to know that the Bash code odb would mean “use the raw text odb at this point”, whereas $odb means “replace this text with the value of the variable odb instead”.

The ultimate outcome of this unscrambling process is that the eval above acts as though you typed in the following two lines at a Bash command prompt:

The second command line shown above is one of the most compact ways of getting what’s called a reverse shell on a Linux or Unix system.

Simply put, it runs a new copy of the Bash shell, but instead of connecting its input and output to the console so you can type in commands on the keyboard and see the output in your terminal window…

…it connects outwards to the server name given, using TCP port 443, and hooks up the TCP network connection to the input and output of the Bash shell.

Outbound connections to port 443 are typically secure web connections, such as when you browse to a URL starting https://, so they are often considered unexceptionable by firewalls.

The result of this outward connection attempt is that if there’s a suitable program listening on port 443 at the specified remote location, that program will accept the connection and instantly get remote access to a Bash command prompt on your computer.

In the example below, we set up a listening process using ncat on a Linux laptop, and made a reverse shell connection outwards from a Mac:

Here, we added the option -i after the command bash to get a visible prompt to appear, but that’s a detail that the crooks don’t need to worry about.

What next?

When a reverse shell connection arrives at the crook’s computer, it’s as though they just logged into your computer, except that the connection came outwards, so there was in fact no “logging in”, no inbound firewall connection rules to bypass, no username needed, and no password required.

At this point, the crooks can pretty much do to your Mac anything that you could do yourself, given that they have a remote shell running under your account. (You can see this in the animation above when we run the command whoami after the Mac’s reverse shell has called home.)

Even if the remote shell is only open briefly, that’s almost always enough time for the crooks to upload and launch yet more malware on your computer, giving them a beachhead to get back into your system at will, even after the initial remote shell has exited.

According to SentinelOne, the call-home server used in the script above isn’t actively listening for reverse shell connections any more, although we found that the domain itself is still online, currently advertising itself as a forthcoming site for “fulls”:

Fulls, also written fullz, is cybercrime argot for stolen records of personally identifiable information that are considered complete. For an individual, this might include name, address, telephone number, bank account details, SSN, DOB, employment details, and more. For a credit card, it would typically include everything needed to make an online payment, including expiry date and CVV.

Watch out for EggShell

As you saw above, the first line in the implanted shell script created a file called .tag in the Mac’s temporary folder.

That hidden file (on Unix and Linux systems, filenames that start with a dot are not visible by default) is dedicated to the single task of running a mysteriously named command mdbcmd, which we’re assuming the crooks would have uploaded automatically as soon a remote shell connection arrived.

At this point, we can only guess at what the crooks had in mind here, although SentinelOne has made an educated conjecture, based on finding two other malware files from other sources that contained the same string /private/tmp/.tag that appears in the XcodeSpy script.

Both were samples of a notorious Mac backdoor known as EggShell. (These samples, along with this malicious project file, are detected by Sophos as OSX/EggShell-A.)

The original EggShell code is an open source project that describes itself as a “post exploitation surveillance tool [that] gives you a command line session with extra functionality between you and a target machine,” so an attacker using EggShell doesn’t need to run a whole series of complex commands by hand:

EggShell gives you the power and convenience of uploading/downloading files, tab completion, taking pictures, location tracking, shell command execution, persistence, escalating privileges, password retrieval, and much more.

As the original author wrly notes, EggShell is “a proof of concept, intended for use on machines you own,” though there are plenty of cybercriminals who have not adhered to that advice.

What to do?

• Don’t blindly download new packages or package updates into your own development or build systems. Test and review everything you download before you approve it for use. Packages may include build-time scripts, as in this case, as well as update-time scripts that run only when you do the update. For these reasons, a software project can be infected (and infectious) even if the source code in the project itself is clean.
• Learn more about remote shells and how they put your ecosystem at risk. Of particular recent interest are webshells, a way for crooks to run malicious scripts via your web server, notoriously abused in the so-called HAFNIUM attacks that started in February 2021. You can read more about remote shells and how to defend against them on Naked Security, on our sister website Sophos News, or even consult the NSA, which maintains a GitHub repository of tools and information on the subject.
• Consider filtering traffic using port 443 if you have a firewall that can reliably do so. Not all organisations are comfortable intercepting and examining encrypted HTTPS traffic, but products such as the Sophos Firewall allow you to exempt low-risk sites where uninterrupted encryption is important. This means you can maintain the end-to-end sanctity of connections to sites such as online banking, webmail and messaging services, and focus your attention instead on low-reputation or unknown sites where encryption could be shielding malicious content. Sites that use port 443 as a loophole for unencrypted connections, as in this case, or that aren’t using HTTPS safely, can be blocked up front before they even complete their connection.

  ---

  Sophos products report the malicious project file described here, as well the EggShell backdoors listed in SentinelOne’s report, as OSX/EggShell-A, if you would like to check your logs. The call-home sites in this case are identified by Sophos web filtering products at connection time under the general category PROD_COMMAND­_AND_CONTROL and under the security category SEC_MALWARE­_CALLHOME.
  If you are interested in real-time malware and web filtering and how you can build it into your own products and services, you might like to look at the SophosLabs Intelix APIs.

  ---