Perpetual IT

Johnathan Swift is probably most famous for his novel Gulliver’s Travels, during which the narrator, Lemuel Gulliver, encounters a socio-political schism in Liiliputian society caused by unending arguments over whether you should open a boiled egg at the big end or the little end.

This satirical observation has flowed diretly into modern computer science, with CPUs that represent integers with the least significant bytes at the lowest memory addresses called little-endian (that’s like writing the year AD 1984 as 4 8 9 1, in the sequenceunits-tens-hundreds-thousands), and those that put the most significant bytes first in memory (as numbers are conventionally written: 1 9 8 4) known as big-endian.

Swift, of course, gave us another satirical note that applies rather neatly to open-source supply chain attacks, where programmers decide to use project X, only to find that X depends on Y, which itself depends on Z, which depends on A, B and C, which in turn…

…you get the picture.

That observation came in a series of remarks about poets that appeared, appropriately enough, in a poem:

 So, Nat'ralists observe, a Flea Hath smaller Fleas that on him prey, And these have smaller yet to bite 'em, And so proceed ad infinitum

We’re not sure, but we’re guessing that the Great Vowel Shift was still not complete in the late 1600s and early 1700s, and that the -EA in Swift’s word Flea was pronounced then as we still, rather peculiarly, pronounce the -EY in prey today. Thus the poem would be read aloud with the sound flay to rhyme with pray. (This E-used-to-be-A business is why British people still say DARBY when they read the placename Derby, or BARKSHIRE when they visit Royal Berkshire.)

Flea stacks considered hamrful

We’ve therefore got used to the idea that rogue content uploaded to open source package repositories generally aims to inject itself unnoticed into the “flea stacks” of code dependencies that some products inadvertently download when updating automatically.

But researchers at supply-chain security testing outfit Checkmarx recently warned about a much less sophisticated, yet potentially much more intrusive, abuse of popular repositories: as phishing link “redirectors”.

Researchers noticed hundreds of online properties such as WordPress blogging sites that had been littered with scammy-looking posts…

…that linked off to thousands of URLs hosted in the NPM package repository.

But those “packages” didn’t exist to publish source code.

They existed simply as placeholders for README files that included the final links that the crooks wanted people to click on.

These links typically including referral codes that would net the scammers a modest reward, even if the person clicking through was doing so simply to see what on earth was going on.

The NPM package names weren’t exactly subtle, so you ought to spot them.

Fortunately, the crooks (inadvertently, we assume) managed to include their list of poisonous packages in one of their uploads.

Checkmarx has therefore published a list containing more than 17,000 unique bogus names, of which just a small sample (one each for the first few letters of the alphabet) shows you what sort of “goods and services” these crooks claim to offer:

active-amazon-promo-codes-list-that-work-updates-daily-106
bingo-bash-free-bingo-chips-and-daily-bonus-222
call-of-duty-warzone-2400-points-for-free-gamerhash-com778
dice-dream-free-rolls
evony-kings-return-upgrade-keep-level-35-without-spending-money779
fifa-mobile-23--new-toty-23-make-millions546
get-free-tiktok-followers505
how-can-i-get-my-snap-score-higher796
instagram_followers_bot_free_apk991
jackpot_world_free_coins_and_jewels307
king-of-avalon--tips-and-tricks-to-get-free-gold429
lakers-shirt-nba-jersey023
. . .

Checkmarx also published a list of close to 200 web pages on which posts had been published that promoted and linked to these bogus NPM packages.

It sounds as though the scammers already had usernames and passwords for some of these sites, which allowed them to post as named or otherwise “trusted” users and reviewers.

But any site with unmoderated or poorly-moderated comments could be peppered anonymously with this sort of rogue link, so just forcing all your community members to create an account on your site is not itself enough to control this sort of abuse.

Creating clickable links in many, if not most, online source code repositories is surprisingly easy, and automatically follows the look-and-feel of the site as a whole.

You don’t even need to create full-blown HTML layouts or CSS page styles – usually, you just create a file in the root directory of your project called README.md.

The extension .md is short for Markdown, a super-easy-to-use text markkup language (see what they did there?) that replaces the complex angle-bracket tags and attributes of HTML with simple text annotations.

To make text bold in Mardown, just put stars round it, so that **this bit** would be bold. For paragraphs, you just leave blank lines. To create a link, just put some text in square brackets and follow it with a URL in round brackets. To display an image from a URL instead of creating clickable text to it, put an exclamation point in front of the link, and so on.

What to do?

• Don’t click “freebie” links, even if you find you are interested or intrigued. You don’t know where you’ll end up, but it will probably be in harm’s way. You may well also be creating bogus pay-per-click traffic for the crooks, and even though the amount for each click might be minuscule, why gift cybercriminals anything if you can help it?
• Don’t fill in online surveys, no matter how harmless they seem. Checkmarx reported that many of these links end up with surveys and other “tests” to qualify you for “gifts” of some sort. The scale and breadth of this scamming exercise is a good reminder that fake “surveys” that each ask for small and apparently inconsequential gobbets of information about you aren’t collecting that data independently. It all ends up collated into one huge bucket of PII (personally identifiable information) that ultimately gives away much more you than you might expect. Filling in surveys gives free assistance to the next wave of scammers, so why why gift cybercriminals anything if you can help it?
• Don’t run blogs or community sites that allow unmoderated posts or comments. You don’t have to force everyone to create a password if you don’t want to, but you should require a trusted human to approve every comment. If you can’t handle the volume of comment spam (which can be huge – though most blogging services have filtering tools that can help you get rid of most of it automatically), turn comments off. A bogus link in a comment is essentially a free service to scammers, so why gift cybercriminals anything if you can help it?

Remember…

…think before you click, and if in doubt, don’t give it out!

Popular cryptocurrency exchange Coinbase is the latest well-known online brand name that’s admitted to getting breached.

The company decided to turn its breach report into an interesting mix of partial mea culpa and handy advice for others.

As in the recent case of Reddit, the company couldn’t resist throwing in the S-word (sophisticated), which once again seems to follow the definition offered by Naked Secuity reader Richard Pennington in a recent comment, where he noted that ‘Sophisticated’ usually translates as ‘better than our defences’.

We’re inclined to agree that in many, if not most, breach reports where threats and attackers are described as sophisticated or advanced, those words are indeed used relatively (i.e. too good for us) rather than absolutely (e.g. too good for everyone).

Coinbase confidently stated, in the executive summary at the start of its article:

Fortunately, Coinbase’s cyber controls prevented the attacker from gaining direct system access and prevented any loss of funds or compromise of customer information.

But that apparent certainty was undermined by the admission, in the very next sentence, that:

Only a limited amount of data from our corporate directory was exposed.

Unfortunately, one of the favourite TTPs (tools, techniques and procedures) used by cybercriminals is known in the jargon as lateral movement, which refers to the trick of parlaying information and access acquired in one part of a breach into ever-wider system access.

In other words, if a cybercriminal can abuse computer X belonging to user Y to retrieve confidential corporate data from database Z (in this case, fortunately, limited to employee names, e-mail addresses, and phone numbers)…

…then saying that the attacker didn’t “gain direct system access” sounds like a rather academic distinction, even if the sysadmins amongst us probably understand those words to imply that the criminals didn’t end up with a terminal prompt at which they could run any system command they wanted.

Tips for threat defenders

Nevertheless, Coinbase did list some of the cybercriminal tools, techniques and procedures that it experienced in this attack, and the list provides some useful tips for threat defenders and XDR teams.

XDR is a bit of a buzzword these days (it’s short for extended detection and response), but we think that the simplest way of describing it is:

Extended detection and response means regularly and actively looking for hints that someone is up to no good in your network, instead of waiting for traditional cybersecurity detections in your threat response dashboard to trigger a response.

Obviously, XDR doesn’t mean turning off your existing cybersecurity alerting and blocking tools, but it does mean extending the range and nature of your threat hunting, so that you’re not only searching for cybercriminals once you’re fairly certain they’ve already arrived, but also watching out for them while they’re still getting ready to attempt an attack.

The Coinbase attack, reconstructed from the company’s somewhat staccato account, seems to have involved the following stages:

• TELLTALE 1: An SMS-based phishing attempt.

Staff were urged via SMS to login to read an important corporate notification.

For convenience, the message included a login link, but that link went to a bogus site that captured usernames and passwords.

Apparently, the attackers didn’t know, or didn’t think, to get hold of the 2FA (two-factor authentication code) they’d need to go along with the username and password, so this part of the attack came to nothing.

We don’t know how 2FA protected the account. Perhaps Coinbase uses hardware tokens, such as Yubikeys, that don’t work simply by providing a six-digit code that you transcribe from your phone to your browser or login app? Perhaps the crooks failed to ask for the code at all? Perhaps the employee spotted the phish after giving away their password but before revealing the final one-time secret needed to complete the process? From the wording in the Coinbase report, we suspect that the crooks either forgot or couldn’t find a believable way to capture the needed 2FA data in their fake login screens. Don’t overestimate the strength of app-based or SMS-based 2FA. Any 2FA process that relies merely on typing a code displayed on your phone into a field on your laptop provides very little protection against attackers who are ready and willing to try out your phished credentials immediately. Those SMS or app-generated codes are typically limited only by time, remaining valid for anywhere between 30 seconds and a few minutes, which generally gives attackers long enough to harvest them and use them before they expire.

• TELLTALE 2: A phone call from someone who said they were from IT.

Remember that this attack ultimately resulted in the criminals acquiring a list of employee contact details, which we assume will end up sold or given away in the cybercrime underground for other crooks to abuse in future attacks.

Even if you have tried to keep your work contact details confidential, they may already be out there and widely-known anyway, thanks to an earlier breach you might not have detected, or to a historical attack against a secondary source, such as an outsourcing company to which you once entrusted your staff data.

• TELLTALE 3: A request to install a remote-access program.

In the Coinbase breach, the social engineers who’d called up in the second phase of the attack apparently asked the victim to install AnyDesk, followed by ISL Online.

Never install any software, let alone remote access tools (which allow an outsider to view your screen and to control your mouse and keyboard remotely as if they were sitting in front of your computer) on the say-so of someone who just called you, even if you think they are from your own IT department.

If you didn’t call them, you’ll almost certainly never be sure who they are.

• TELLTALE 4: A request to install a browser plugin.

In the Coinbase case, the tool that the crooks wanted the victim to use was called EditThisCookie (an ultra-simple way of retrieving secrets such as access tokens from a user’s browser), but you should refuse to install any browser plugin on the say-so of someone you don’t know and have never met.

Browser plugins get almost unfettered access to everything you type into your browser, including passwords, before they get encrypted, and to everything your browser displays, after it’s been decrypted.

Plugins can not only spy on your browsing, but also invisibly modify what you type in before it’s transmitted, and the content you get back before it appears on the screen.

What to do?

To repeat and develop the advice we’ve given so far:

• Never login by clicking on links in messages. You should know where to go yourself, without needing “help” from a message that could have come from anywhere.
• Never take IT advice from people who call you. You should know where to call up yourself, to reduce the risk of being contacted by a scammer who knows exactly the right time to jump in and appear to be “helping” you.
• Never install software on the say-so of an IT staffer you haven’t verified. Don’t even install software that you yourself consider safe, because the caller will probably direct you to a booby-trapped download into which malware has already been added.
• Never reply to a message or call by asking if it’s genuine. The sender or caller will simply tell you what you want to hear. Report suspicious contacts to your own security team as soon as you can.

In this case, Coinbase says its own security team was able to use XDR techniques, spotting unusual patterns of activity (for example, attempted logons via an unexpected VPN service), and to intervene within about 10 minutes.

This meant that the individual under attack not only broke off all contact with the criminals right away, before too much harm was done, but knew to be extra-careful in case the attackers came back with yet more ruses, cons and so-called active adversary trickery.

Make sure you’re a human part of your company’s XDR “sensor network”, too, along with any technological tools your security team has in place.

Giving your active defenders more to go on that just “VPN source address showed up in access logs” means they’ll be much better equipped to detect and respond to an active attack.

LEARN MORE ABOUT ACTIVE ADVERSARIES

In real life, what really works for the cybercrooks when they initiate an attack? How do you find and treat the underlying cause of an attack, instead of just dealing with the obvious symptoms?

LEARN MORE ABOUT XDR AND MDR

Short of time or expertise to take care of cybersecurity threat response? Worried that cybersecurity will end up distracting you from all the other things you need to do?

Take a look at Sophos Managed Detection and Response:
24/7 threat hunting, detection, and response  ▶

LEARN MORE ABOUT SOCIAL ENGINEERING

Join us for a fascinating interview with Rachel Tobac, DEFCON Social Engineering Capture the Flag champ, about how to detect and rebuff scammers, social engineers and other sleazy cybercrimimals.

No podcast player showing below? Listen directly on Soundcloud.

Twitter has announced an intriguing change to its 2FA (two-factor authentication) system.

The change will take effect in about a month’s time, and can be summarised very simply in the following short piece of doggerel:

 Using texts is insecure for doing 2FA, So if you want to keep it up you're going to have to pay.

We said “about a month’s time” above because Twitter’s announcement is somewhat ambiguous with its dates-and-days calculations.

The product announcement bulletin, dated 2023-02-15, says that users with text-message (SMS) based 2FA “have 30 days to disable this method and enroll in another”.

If you include the day of the announcement in that 30-day period, this implies that SMS-based 2FA will be discontinued on Thursday 2023-03-16.

If you assume that the 30-day window starts at the beginning of the next full day, you’d expect SMS 2FA to stop on Friday 2023-03-17.

However, the bulletin says that “after 20 March 2023, we will no longer permit non-Twitter Blue subscribers to use text messages as a 2FA method. At that time, accounts with text message 2FA still enabled will have it disabled.”

If that’s strictly correct, then SMS-based 2FA ends at the start of Tuesday 21 March 2022 (in an undisclosed timezone), though our advice is to take the shortest possible interpretation so you don’t get caught out.

SMS considered insecure

Simply put, Twitter has decided, as Reddit did a few years ago, that one-time security codes sent via SMS are no longer safe, because “unfortunately we have seen phone-number based 2FA be used – and abused – by bad actors.”

The primary objection to SMS-based 2FA codes is that determined cybercriminals have learned how to trick, cajole or simply to bribe employees in mobile phone companies to give them replacement SIM cards programmed with someone else’s phone number.

Legitimately replacing a lost, broken or stolen SIM card is obviously a desirable feature of the mobile phone network, otherwise you’d have to get a new phone number every time you changed SIM.

But the apparent ease with which some crooks have learned the social engineering skills to “take over” other people’s numbers, usually with the very specific aim of getting at their 2FA login codes, has led to bad publicity for text messages as a source of 2FA secrets.

This sort of criminality is known in the jargon as SIM-swapping, but it’s not strictly any sort of swap, given that a phone number can only be programmed into one SIM card at a time.

So, when the mobile phone company “swaps” a SIM, it’s actually an outright replacement, because the old SIM goes dead and won’t work any more.

Of course, if you’re replacing your own SIM because your phone got stolen, that’s a great security feature, because it restores your number to you, and ensures that the thief can’t make calls on your dime, or listen in to your messages and calls.

But if the tables are turned, and the crooks are taking over your SIM card illegally, this “feature” turns into a double liability, because the criminals start receiving your messages, including your login codes, and you can’t use your own phone to report the problem!

Is this really about security?

Is this change really about security, or is it simply Twitter aiming to simplify its IT operations and save money by cutting down on the number of text messages it needs to send?

We suspect that if the company really were serious about retiring SMS-based login authentication, it would impel all its users to switch to what it considers more secure forms of 2FA.

Ironically, however, users who pay for the Twitter Blue service, a group that seems to include high-profile or popular users whose accounts we suspect are much more attractive targets for cybercriminals…

…will be allowed to keep using the very 2FA process that’s not considered secure enough for everyone else.

SIM-swapping attacks are difficult for criminals to pull off in bulk, because a SIM swap often involves sending a “mule” (a cybergang member or “affiliate” who is willing or desperate enough to risk showing up in person to conduct a cybercrime) into a mobile phone shop, perhaps with fake ID, to try to get hold of a specific number.

In other words, SIM-swapping attacks often seem to be premeditated, planned and targeted, based on an account for which the criminals already know the username and password, and where they think that the value of the account they’re going to take over is worth the time, effort and risk of getting caught in the act.

So, if you do decide to go for Twitter Blue, we suggest that you don’t carry on using SMS-based 2FA, even though you’ll be allowed to, because you’ll just be joining a smaller pool of tastier targets for SIM-swapping cybergangs to attack.

Another important aspect of Twitter’s announcement is that although the company is no longer willing to send you 2FA codes via SMS for free, and cites security concerns as a reason, it won’t be deleting your phone number once it stops texting you.

Even though Twitter will no longer need your number, and even though you may have originally provided it on the understanding that it would be used specificially for the purpose of improving login security, you’ll need to remember to go in and delete it yourself.

What to do?

• If you already are, or plan to become, a Twitter Blue member, consider switching away from SMS-based 2FA anyway. As mentioned above, SIM-swapping attacks tend to be targeted, because they’re tricky to do in bulk. So, if SMS-based login codes aren’t safe enough for the rest of Twitter, they’ll be even less safe for you once you’re part of a smaller, more select group of users.
• If you are a non-Blue Twitter user with SMS 2FA turned on, consider switching to app-based 2FA instead. Please don’t simply let your 2FA lapse and go back to plain old password authentication if you’re one of the security-conscious minority who has already decided to accept the modest inconvenience of 2FA into your digital life. Stay out in front as a cybersecurity trend-setter!
• If you gave Twitter your phone number specifically for 2FA messages, don’t forget to go and remove it. Twitter won’t be deleting any stored phone numbers automatically.
• If you’re already using app-based authentication, remember that your 2FA codes are no more secure than SMS messages against phishing. App-based 2FA codes are generally protected by your phone’s lock code (because the code sequence is based on a “seed” number stored securely on your phone), and can’t be calculated on someone else’s phone, even if they put your SIM into their device. But if you accidentally reveal your latest login code by typing it into a fake website along with your password, you’ve given the crooks all they need anyway, whether that code came from an app or via a text message.
• If your phone loses mobile service unexpectedly, investigate promptly in case you’ve been SIM-swapped. Even if you aren’t using your phone for 2FA codes, a crook who’s got control over your number can neverthless send and receive messages in your name, and can make and answer calls while pretending to be you. Be prepared to show up at a mobile phone store in person, and take your ID and account receipts with you if you can.
• If haven’t set a PIN code on your phone SIM, consider doing so now. A thief who steals your phone probably won’t be able to unlock it, assuming you’ve set a decent lock code. Don’t make it easy for them simply to eject your SIM and insert it into another device to take over your calls and messages. You’ll only need to enter the PIN when you reboot your phone or power it up after turning it off, so the effort involved is minimal.

By the way, if you’re comfortable with SMS-based 2FA, and are worried that app-based 2FA is sufficiently “different” that it will be hard to master, remember that app-based 2FA codes generally require a phone too, so your login workflow doesn’t change much at all.

Instead of unlocking your phone, waiting for a code to arrive in a text message, and then typing that code into your browser…

…you unlock your phone, open your authenticator app, read off the code from there, and type that into your browser instead. (The numbers typically change every 30 seconds so they can’t be re-used.)

PS. The free Sophos Intercept X for Mobile security app (available for iOS and Android) includes an authenticator component that works with almost all online services that support app-based 2FA. (The system generally used is called TOTP, short for time-based one-time password.)

Late last week [2023-02-16], popular web hosting company GoDaddy filed its compulsory annual 10-K report with the US Securities and Exchange Commission (SEC).

Under the sub-heading Operational Risks, GoDaddy revealed that:

In December 2022, an unauthorized third party gained access to and installed malware on our cPanel hosting servers. The malware intermittently redirected random customer websites to malicious sites. We continue to investigate the root cause of the incident.

URL redirection, also known as URL forwarding, is an unexceptionable feature of HTTP (the hypertext transfer protocol), and is commonly used for a wide variety of reasons.

For example, you might decide to change your company’s main domain name, but want to keep all your old links alive; your company might get acquired and need to shift its web content to the new owner’s servers; or you might simply want to take your current website offline for maintenance, and redirect visitors to a temporary site in the meantime.

Another important use of URL redirection is to tell visitors who arrive at your website via plain old unencrypted HTTP that they should visit using HTTPS (secure HTTP) instead.

Then, once they have reconnected over an encrypted connection, you can include a special header to tell their browser to start with HTTPS in future, even if they click on an old http://... link, or mistakenly type in http://... by hand.

In fact, redirects are so common that if you hang around web developers at all, you’ll hear them referring to them by their numeric HTTP codes, in much the same way that the rest of us talk about “getting a 404” when we try to visit a page that no longer exists, simply because 404 is HTTP’s Not Found error code.

There are actually several different redirect codes, but the one you’ll probably hear most frequently referred to by number is a 301 redirect, also known as Moved Permanently. That’s when you know that the old URL has been retired and is unlikely ever to reappear as a directly reachable link. Others include 303 and 307 redirects, commonly known as See Other and Temporary Redirect, used when you expect that the old URL will ultimately come back into active service.

Here are two typical examples of 301-style redirects, as used at Sophos.

The first tells visitors using HTTP to reconnect right away using HTTPS instead, and the second exists so that we can accept URLs that start with just sophos.com by redirecting them to our more conventional web server name www.sophos.com.

In each case, the header entry labelled Location: tells the web client where to go next, which browsers generally do automatically:

$ curl -D - --http1.1 http://sophos.com
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://sophos.com/ <--reconnect here (same place, but using TLS)
. . . $ curl -D - --http1.1 https://sophos.com
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Location: https://www.sophos.com/ <--redirect to our web server for actual content
Strict-Transport-Security: . . . <--next time, please use HTTPS to start with
. . .

The command line option -D - above tells the curl program to print out the HTTP headers in the replies, which are what matters here. Both these replies are simple redirects, meaning that they don’t have any content of their own to send back, which they denote with the header entry Content-Length: 0. Note that browsers generally have built-in limits on how many redirects they will follow from any starting URL, as a simple precaution against getting caught up in an never-ending redirect cycle.

Redirect control considered harmful

As you can imagine, having insider access to a company’s web redirection settings effectively means that you can hack their web servers without modifying the contents of those servers directly.

Instead, you can sneakily redirect those server requests to content you’ve set up elsewhere, leaving the server data itself unchanged.

Anyone checking their access and upload logs for evidence of unauthorised logins or unexpected changes to the HTML, CS , PHP and JavaScript files that make up the official content of their site…

…will see nothing untoward, because their own data won’t actually have been touched.

Worse still, if attackers trigger malicious redirects only every now and then, the subterfuge can be hard to spot.

That seems to have been what happened to GoDaddy, given that the company wrote in a statement on its own site that:

In early December 2022, we started receiving a small number of customer complaints about their websites being intermittently redirected. Upon receiving these complaints, we investigated and found that the intermittent redirects were happening on seemingly random websites hosted on our cPanel shared hosting servers and were not easily reproducible by GoDaddy, even on the same website.

Tracking down transient takeovers

This is the same sort of problem that cybsersecurity researchers encounter when dealing with poisoned internet ads served up by third-party ad servers – what’s known ih the jargon as malvertising.

Obviously, malicious content that appears only intermittently doesn’t show up every time you visit an affected site, so that even just refreshing a page that you aren’t sure about is likely to destroy the evidence.

You might even perfectly reasonably accept that what you just saw wasn’t an attempted attack, but merely a transient error.

This uncertainty and unreproducibility typically delays the first report of the problem, which plays into the hands of the crooks.

Likewise, researchers who follow up on reports of “intermittent malevolence” can’t be sure they’re going to be able to grab a copy of the bad stuff either, even if they know where to look.

Indeed, when criminals use server-side malware to alter the behaviour of web services dynamically (making changes at run-time, to use the jargon term), they can use a wide range of external factors to confuse researchers even further.

For example, they can change their redirects, or even suppress them entirely, based on the time of day, the country you’re visiting from, whether your’re on a laptop or a phone, which browser you’re using…

…and whether they think you’re a cybersecurity researcher or not.

What to do?

Unfortunately, GoDaddy took nearly three months to tell the world about this breach, and even now there’s not a lot to go on.

Whether you’re a web user who’s visited a GoDaddy-hosted site since December 2022 (which probably includes most of us, whether we realise it or not), or a website operator who uses GoDaddy as a hosting company…

…we aren’t aware of any indicators of compromise (IoCs), or “signs of attack”, that you might have noticed at the time or that we can advise you to search for now.

Worse still, even though GoDaddy describes the breach on its website under the headline Statement on recent website redirect issues, it states in its 10-K filing that this may be a much longer-running onslaught than the word “recent” seems to imply:

Based on our investigation, we believe [that this and other incidents dating back to at least March 2000] are part of a multi-year campaign by a sophisticated threat actor group that, among other things, installed malware on our systems and obtained pieces of code related to some services within GoDaddy.

As mentioned above, GoDaddy has assured the SEC that “we continue to investigate the root cause of the incident”.

Let’s hope that it doesn’t take another three months for the company to tell us what it uncovers in the course of this investigation, which appears to stretch back three years or more…

CAN WE STOP WITH THE “SOPHISTICATED” ALREADY?

The birth of ENIAC. A “sophisticated attack” (someone got phished). A cryptographic hack enabled by a security warning. Valentine’s Day Patch Tuesday. Apple closes spyware-sized 0-day hole.

With Doug Aamoth and Paul Ducklin

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

Featured image of ENIAC licensed under CC BY-SA 3.0.