MOVEit mayhem 3: “Disable HTTP and HTTPS traffic immediately”

Yet more MOVEit mayhem!

“Disable HTTP and HTTPS traffic to MOVEit Transfer,” says Progress Software, and the timeframe for doing so is “immediately”, no ifs, no buts.

Progress Software is the maker of file-sharing software MOVEit Transfer, and the hosted MOVEit Cloud alternative that’s based on it, and this is its third warning in three weeks about hackable vulnerabilities in its product.

At the end of May 2023, cyberextortion criminals associated with the Clop ransomware gang were found to be using a zero-day exploit to break into servers running the MOVEit product’s web front-end.

By sending deliberately malformed SQL database commands to a MOVEit Transfer server via its web portal, the criminals could access database tables without needing a password, and implant malware that allowed them to return to compromised servers later on, even if they’d been patched in the meantime.

The attackers have apparently been stealing trophy company data, such as employee payroll details, and demanding blackmail payments in reurn for “deleting” the stolen data.

We explained how to patch, and what you could look for in case the crooks had already paid you a visit, back at the start of June 2023:

Second warning

That warning was followed, last week, by an update from Progress Software.

While investigating the zero-day hole that they’d just patched, Progress developers uncovered similar programming flaws elsewhere in the code.

The company therefore published a further patch, urging customers to apply this new update proactively, assuming that the crooks (whose zero-day had just been rendered useless by the first patch) would also be keenly looking for other ways to get back in.

Unsurprisingly, bugs of a feather often flock together, as we explained in this week’s Naked Security podcast:

[On 2023-06-09, Progress put] another patch out to deal with similar bugs that, as far as they know, the crooks haven’t found yet (but if they look hard enough, they might).

And, as weird as that sounds, when you find that a particular part of your software has a bug of a particular sort, you shouldn’t be surprised if, when you dig deeper…

…you find that the programmer (or the programming team who worked on it at the time that the bug you already know about got introduced) committed similar errors around the same time.

Third time unlucky

Well, lightning has apparently just struck the same place for the third time in quick succession.

This time, it seems as though someone performed what’s known in the jargon as a “full disclosure” (where bugs are revealed to the world at the same time as to the vendor, thus giving the vendor no breathing room to publish a patch proactively), or “dropping an 0-day”.

Progress has just reported:

Today [2023-06-15], a third-party publicly posted a new [SQL injection] vulnerability. We have taken HTTPS traffic down for MOVEit Cloud in light of the newly published vulnerability and are asking all MOVEit Transfer customers to immediately take down their HTTP and HTTPS traffic to safeguard their environments while the patch is finalized. We are currently testing the patch and we will update customers shortly.

Simply put, there’s a brief zero-day period during which a working exploit is circulating, but the patch isn’t ready yet.

As Progress has mentioned before, this group of so-called command injection bugs (where you send in what ought to be harmless data that later gets invoked as a server command) can only be triggered via MOVEit’s web-based portal, using HTTP or HTTPS requests.

Fortunately, that means you don’t need to shut down your entire MOVEit system, only web-based access.

What to do?

Quoting from Progress Software’s advice document dated 2023-06-15:


Disable all HTTP and HTTPs traffic to your MOVEit Transfer environment. More specifically:

  • Modify firewall rules to deny HTTP and HTTPs traffic to MOVEit Transfer on ports 80 and 443.
  • It is important to note that until HTTP and HTTPS traffic is enabled again:
    • Users will not be able to log on to the MOVEit Transfer web UI.
    • MOVEit Automation tasks that use the native MOVEit Transfer host will not work.
    • REST, Java and .NET APIs will not work.
    • MOVEit Transfer add-in for Outlook will not work.
  • SFTP and FTP/s protocols will continue to work as normal

Keep your eyes out for the third patch in this saga, at which point we assume that Progress will give the all-clear to turn web access back on…

…though we’d sympathise if you decided to keep it turned of for a while longer, just to be sure, to be sure.


THREAT HUNTING TIPS FOR SOPHOS CUSTOMERS


S3 Ep139: Are password rules like running through rain?

DON’T GET INTO THE HABIT OF A BAD HABIT

Magnetic core memory. Patch Tuesday and SketchUp shenanigans. More MOVEit mitigations. Mt. Gox back in the news. Gozi malware criminal imprisoned at last. Are password rules like running through rain?

No audio player below? Listen directly on Soundcloud.

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

DOUG.  Patch Tuesday, cybercrime comeuppance, and fun with passwords.

All that, and more, on the Naked Security podcast.

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug Aamoth; he is Paul Ducklin.

Paul, how do you do today?


DUCK.  Doug, I shouldn’t say this… but because I know what’s coming in This Week in Tech History, because you gave me a preview, I’m very excited!


DOUG.  Alright, well, let’s get right to it!

This week, on 15 June, way back in 1949, Jay Forrester, who was a Professor at the Massachusetts Institute of Technology, or MIT, wrote down…


DUCK.  [MOCK DRAMA] Don’t say that like you’re from Boston and you’re all smug about it, Doug? [LAUGHTER]


DOUG.  Hey, it’s a beautiful campus; I’ve been there many times.


DUCK.  It is a kind of famous engineering school as well, isn’t it? [LAUGHS]


DOUG.  It sure is!

Jay Forrester wrote down a proposal for “core memory” in his notebook, and would later install magnetic core memory on MIT’s Whirlwind computer.

This invention made computers more reliable and faster.

Core memory remained the popular choice for computer storage until the development of semiconductors in the 1970s.


DUCK.  It’s a fantastically simple idea once you know how it works.

Tiny little ferrite magnetic cores, like you’d get at the centre of a transformer… like super-miniature washers.

They were magnetised, either clockwise or anticlockwise, to mean zero or one.

It literally was magnetic storage.

And it had the funky feature, Douglas, that because ferrite essentially forms a permanent magnet…

…you can remagnetise it, but when you turn off the power, it stays magnetised.

So it was non-volatile!

If you had a power failure, you could basically restart the computer and carry on where you left off.

Amazing!


DOUG.  Outstanding, yes… that’s really cool.


DUCK.  Apparently, MIT’s original plan was to charge a royalty of US$0.02 per bit on the idea.

Can you imagine how expensive that would make, say, a 64 gigabyte iPhone memory?

It would be in the billions of dollars! [LAUGHS]


DOUG.  Unreal.

Well, some interesting history, but let’s bring it up to the modern day.

Not too long ago… Microsoft Patch Tuesday.

No zero-days, but still plenty of fixes, Paul:

Patch Tuesday fixes 4 critical RCE bugs, and a bunch of Office holes


DUCK.  Well, no zero-days this month if you ignore that Edge remote code execution hole that we talked about last week.


DOUG.  Hmmmmmm.


DUCK.  Technically, that’s not part of Patch Tuesday…

…but there were 26 remote code execution [RCE] bugs in total, and 17 elevation-of-privilege [EoP] bugs.

That’s where crooks are already in, but they can’t do much yet, so they then use the EoP bug to get superpowers on your network, and do much more dastardly things.

Four of those remote code execution bugs were dubbed “Critical” by Microsoft, meaning that if you’re one of those people who still likes to do your patches in a specific order, those are the ones we suggest you start with.

The good news about the four critical patches is that three of them relate to the same Windows component.

As far as I can make out, it was a bunch of related bugs, presumably found during some kind of code review of that component.

Which relates to the Windows Messaging Service, if you happen to use that in your network.


DOUG.  And we’ve been all collectively thanked for our patience with the SketchUp debacle, which I didn’t know existed until now.


DUCK.  Like you, Doug, I have never used this program called SketchUp, which I believe is a third-party 3D graphics program.

Who knew that it would be really great to be able to drop SketchUp 3D images into your Word, Excel, PowerPoint documents?

As you can imagine, with a brand new file format to parse, to interpret, to process, to render inside Office…

…Microsoft introduced a bug that was fixed as CVE-2023-33146.

But the hidden story-behind-the-story, if you like, is that on 01 June 2023, Microsoft announced that:

The ability to insert SketchUp graphics has been temporarily disabled in Word, Excel, PowerPoint and Outlook for Windows and Mac.

We appreciate your patience as we work to ensure the security and functionality of this feature.

I am glad that Microsoft appreciates my patience, but I do perhaps wish that Microsoft itself had been a bit more patient before introducing this feature into Office in the first place.

I wish they had put it in there *after* it was secure, rather than putting it in to see whether it was secure and finding out, as you say (surprise! surprise!), that it wasn’t.


DOUG.  Great.

Let’s stick on the subject of patience.

I said that we would “keep an eye on this”, and I hoped that we wouldn’t need to keep an eye on this.

But we’ve got to alliterate a bit, as you did in the headline.

More MOVEit mitigations: new patches published for further protection, Paul.

More MOVEit mitigations: new patches published for further protection


DUCK.  It’s that good old MOVEit problem again: the SQL injection bug.

That means that if you’re using the MOVEit Transfer program, and you haven’t patched it, then crooks who can access the web-based front end can trick your server into doing bad things…

…up to and including embedding a webshell that will let them wander in later and do whatever they want.

As you know, there was a CVE issued, and Progress Software, the makers of MOVEit, put out a patch to deal with the known exploit in the wild.

They now have another patch out to deal with similar bugs that, as far as they know, the crooks haven’t found yet (but if they looked hard enough, they might).

And, as weird as that sounds, when you find that a particular part of your software has a bug of a particular sort, you shouldn’t be surprised if, when you dig deeper…

…you find that the programmer (or the programming team who worked on it at the time that the bug you already know about got introduced) committed similar errors around the same time.

So well done in this case, I would say, to Progress Software for trying to deal with this proactively.

Progress Software just said, “All Move It customers must apply the new patch released on 09 June 2023.


DOUG.  OK, I guess we’ll… keep an eye on that!

Paul, help me out here.

I’m in the year 2023, reading in a Naked Security headline something about “Mt. Gox.”

What is happening to me?

History revisited: US DOJ unseals Mt. Gox cybercrime charges


DUCK.  Mt. Gox!

“Magic The Gathering Online Exchange”, Doug, as it was…


DOUG.  [LAUGHS] Of course!


DUCK.  …where you could trade Magic The Gathering cards.

That domain got sold, and those with long memories will know that it turned into the most popular, and by far the biggest, Bitcoin exchange on the planet.

It was run by a French expatriate, Mark Karpelès, out of Japan.

It was all going swimmingly, apparently, until it imploded in a puff of cryptocurrency dust in 2014, when they realised that, loosely speaking, all their Bitcoins had disappeared.


DOUG.  [LAUGHS] I shouldn’t laugh!


DUCK.  647,000 of them, or something.

And even back then, they were already worth about $800 a pop, so that was half-a-billion US dollars’ worth of “puff”.

Intriguingly, at the time, a lot of fingers pointed at the Mt. Gox team itself, saying, “Oh, this must be an inside job.”

And in fact, on New Year’s Day, I think it was, in 2015, a Japanese newspaper called Yomiuri Shimbun actually published an article saying, “We’ve looked into this, and 1% of the losses can be explained by the excuse they’ve come up with; for the rest, we’re going on the record saying that it was an inside job.”

Now, that article that they published, which caused a lot of drama because it’s quite a dramatic accusation, now gives a 404 error [HTTP page not found] when you visit it today.


DOUG.  Very interesting!


DUCK.  So I don’t think they stand by it anymore.

And, indeed, the Department of Justice [DOJ] in the United States has finally, at last, all these years later, actually charged two Russian nationals with basically stealing all the Bitcoins.

So it does sound like Mark Karpelès has got at least a partial exoneration, courtesy of the US Department of Justice, because they have very definitely put these two Russian chaps in the frame for this crime all those years ago.


DOUG.  It’s a fascinating read.

So check it out on Naked Security.

All you have to do is search for, you guessed it, “Mt. Gox”.

Let’s stay on the subject of cybercrime, as one of the main offenders behind the Gozi banking malware has landed in jail after ten long years, Paul:

Gozi banking malware “IT chief” finally jailed after more than 10 years


DUCK.  Yes… it was a little bit like waiting for the bus.

Two astonishing “wow, this happened ten years ago, but we’ll get him in the end” stories arrived at once. [LAUGHTER]

And this one, I thought, was important to write up again, just to say, “This is the Department of Justice; they didn’t forget about him.”

Actually. He was arrested in Colombia.

I believe he paid a visit, and he was in Bogotá Airport, and I guess the border officials thought, “Oh, that name’s on a watch list”!

And so apparently the Colombian officials thought, “Let’s contact the US Diplomatic Service.”

They said, “Hey, we’re holding a chap here by the name of (I won’t mention his name – t’s in the article).. you used to be interested in him, relating to very serious multimillion-dollar malware crimes. Are you still interested, by any chance?”

And, what a surprise, Doug, the US was very interested indeed.

So, he got extradited, faced court, pleaded guilty, and he has now been sentenced.

He’ll only get three years in prison, which may seem like a light sentence, and he has to hand back more than $3,000,000.

I don’t know what happens if he doesn’t, but I guess it’s just a reminder that by running and hiding from malware related criminality…

…well, if there are charges against you and the US are looking for you, they don’t just go, “Ah, it’s ten years, we might as well leave it.”

And this guy’s criminality was running what are known as in the jargon as “bulletproof hosts”, Doug.

That’s basically where you’re kind-of an ISP, but unlike a regular ISP, you go out of your way to be a moving target to law enforcement, to blocklists, and to takedown notices from regular ISPs.

So, you provide services, but you keep them, if you like, shifting around and on the move on the internet, so that crooks pay you a fee, and they know that the domains that you’re hosting for them will just carry on working, even if law enforcement are after you.


DOUG.  All right, great news again.

Paul, you have, as we round out our stories for the day, grappled with a very difficult, nuanced, yet important question about passwords.

Namely, should we be changing them constantly on a rotation, maybe once a month?

Or lock in really complex ones to start with, and then leave well enough alone?

Thoughts on scheduled password changes (don’t call them rotations!)


DUCK.  Although it sounds like a sort-of old story, and indeed it’s one that we have visited many times before, the reason I wrote it up is that a reader contacted me to ask about this very thing.

He said, “I don’t want to go into bat for 2FA; I don’t want to go into bat for password managers. Those are separate issues. I just want to know how to settle, if you like, the turf war between two factions inside my company, where some people are saying we need to do passwords properly, and others are just saying, ‘That boat sailed, it’s too hard, we’ll just force people to change them and that will be good enough’.”

So I thought it was actually worth writing about it.

Judging by the number of comments on Naked Security, and on social media, lots of IT teams are still wrestling with this.

If you just force people to change their passwords every 30 days or 60 days, does it really matter if they choose one that’s eminently crackable if their hash gets stolen?

As long as they don’t choose password or secret or one of the Top Ten Cats’ Names in the world, maybe it’s OK if we force them to change it to another not-very-good password before the crooks would be able to crack it?

Maybe that’s just good enough?

But I have three reasons why you can’t fix a bad habit by just following another bad habit.


DOUG.  The first one out of the gate: Changing passwords regularly isn’t an alternative to choosing and using strong ones, Paul.


DUCK.  No!

You might choose to do both (and I’ll give you two reasons in a minute why I think forcing people to change them regularly has another set of problems).

But the simple observation is that changing a bad password regularly doesn’t make it a better password.

If you want a better password, choose a better password to start with!


DOUG.  And you say: Forcing people to change their passwords routinely may lull them into bad habits.


DUCK.  Judging by the comments, this is exactly the problem that lots of IT teams have.

If you tell people, “Hey, you’ve got to change your password every 30 days, and you better pick a good one,” all they’ll do is…

…they’ll pick a good one.

They’ll spend a week committing it to memory for the rest of their life.

And then every month they’ll add -01, -02, and so on.

So if the crooks do crack or compromise one of the passwords, and they see a pattern like that, they can pretty much work out what your password is today if they know your password from six months ago.

So that’s where forcing change when it’s not necessary can lead people to take cybersecurity shortcuts that you don’t want them to do.


DOUG.  And this is an interesting one.

We’ve spoken about this before, but it’s something that some people may not have thought of: Scheduling password changes may delay emergency responses.

What do you mean by that?


DUCK.  The point is that if you have a formalised, fixed schedule for password changes so that everyone knows that when the last day of this month comes round, they’re going to be forced to change their password anyway…

…and then they think, “You know what? It’s the 12th of the month, and I went to a website I’m not sure about that could have been a phishing site. Well, I’m going to change my password in two weeks anyway, so I won’t go and change it now.”

So, by changing your passwords *regularly*, you may end up in the habit where sometimes, when it’s really, really important, you don’t change your password *frequently* enough.

If and when you think there is a good reason to change your password, DO IT NOW!


DOUG.  I love it!

Alright, let’s hear from one of our readers on the password piece.

Naked Security reader Philip writes, in part:

Changing your passwords often so as not to get compromised is like thinking that if you run fast enough, you can dodge all the raindrops.

OK, you’ll dodge the raindrops falling behind you, but there’ll be just as many where you’re going.

And, forced to regularly change their passwords, a very large number of people will simply append a number they can increment as required.

Like you said, Paul!


DUCK.  Your friend and mine, Chester [Wisniewski] said, a few years ago when we were talking about password myths, “All they need to do [LAUGHS], to work out what the number is at the end, is to go to your LinkedIn page. ‘Started at this company in August 2017’… count the number of months since then.”

That’s the number you need at the end.

Sophos Techknow – Busting Password Myths


DOUG.  Exactly! [LAUGHTER]


DUCK.  And the problem comes that when you try and schedule, or algorithmise… is that a word?

(It probably shouldn’t be, but I’ll use it anyway.)

When you try and take the idea of randomness, and entropy, and unpredictability, and corral it into some super-strict algorithm, like the algorithm that describes how the characters and numbers are laid out on vehicle tags, for example…

…then you end up with *less* randomness, not *more*, and you need to be aware of that.

So, forcing people to do anything that causes them to fall into a pattern is, as Chester said at the time, simply getting them into the habit of a bad habit.

And I love that way of putting it.


DOUG.  Alright, thank you very much for sending that in, Philip.

And if you have an interesting story, comment, or question you’d like to submit, we’d love to read it on the podcast.

You can email tips@sophos.com, comment on any one of our articles, or hit us up on social: @nakedsecurity.

That’s our show for today.

Thanks very much for listening.

For Paul Ducklin, I’m Doug Aamoth, reminding you, until next time, to…


BOTH.  Stay secure!

[MUSICAL MODEM]


Patch Tuesday fixes 4 critical RCE bugs, and a bunch of Office holes

No zero-days this month, if you ignore the Edge RCE hole patched last week (make sure you’ve got that update, by the way):

For a full list of this month’s Microsoft Patch Tuesday fixes, take a look at our sister site Sophos News, where SophosLabs analysts have collated complete lists of the the numerous Microsoft CVEs that were fixed this month:

Just the way you like it

Helpfully, our researchers have created multiple lists, handily sorted by bug type and severity (so you can tell your remote code executions from your elevations-of-privilege); by Microsoft’s guesses at the likelihood of crooks figuring out working exploits for each bug (in case you like to prioritise your efforts that way), and by product type (if you like to divide up your patching efforts between your server team, your Office experts and your laptop support crew).

In case you were wondering, there were 26 Remote Code Execution (RCE) patches, including four dubbed “Critical”, although three of those seem to be related bugs that were found and fixed together in a single Windows component.

RCE patches generally cause the most concern, because they deal with bugs that can, in theory at least, be exploited by attackers who don’t yet have a foothold on your network, which means they represent possible ways of criminals breaking-and-entering in the first place.

There were 17 Elevation-of-Privilege (EoP) fixes, just one of which is deemed “Critical” by Microsoft, ironically in the SharePoint Server, which is the very tool many companies rely on for exchanging large amounts data securely inside their networks.

In other words, unauthorised access to SharePoint could hand attackers a free pass to get straight into your own, or even your customers’, trophy data, as happened recently to numerous companies using the competing file sharing service MOVEit.

As you probably know, the problem with EoP bugs is that they are often exploited as the second step in an attack from outside, used by cybercriminals to boost their access privileges as soon as they can after they break in.

This can turn a security breach that started out with comparatively limited initial exposure (for example, rogue access only to the local files on one user’s laptop)…

…into a much more dangerous incident (for example, rogue access to everyone else’s laptop across the network, and perhaps to all your corporate servers as well, such as customer databases, payment systems, backups, and more).

Notable holes

SophosLabs experts have identified six of the CVEs as “notable”.

Head to our long-form report for more information on those six bugs.

For now, we’ll just list five of them here:

  • CVE-2023-29357. Microsoft SharePoint Server Elevation of Privilege Vulnerability. This bug could give a crook who has access to your network, but who doesn’t have a logon to your SharePoint system, a way to steal a legitimate user’s access credentials and thus to sidestep the need to come up with a username, password or 2FA code of their own.
  • CVE-2023-29363, -32014 and -32015. Windows Pragmatic General Multicast (PGM) Remote Code Execution Vulnerability. If you use the Windows message queuing service in your network, these bugs could allow attackers to trick a device on your network into running code of their choice.
  • CVE-2023-33146. Microsoft Office Remote Code Execution Vulnerability. Apparently, thus bug can be triggered by booby-trapped SketchUp files (we’ve never even heard of, let alone used, the SketchUp app, but apparently it’s a popular 3D graphics program) embedded in a wide range of Office files, including Word, Excel, PowerPoint and Outlook.

Intriguingly, the patch for CVE-2023-33146 seems to be symptomatic of broader unresolved security problems in Office’s support for handling SketchUp objects, presumably because of the difficulty of safely parsing, processing and embedding yet another complex file format into Office documents.

Indeed, on 2023-06-01, Microsoft officially announced that it was turning off the SketchUp embedding system until further notice (our emphasis):

The ability to insert SketchUp graphics (.skp files) has been temporarily disabled in Word, Excel, PowerPoint and Outlook for Windows and Mac. Versions of Office that had this feature enabled will no longer have access it. […] We appreciate your patience as we work to ensure the security and functionality of this feature.

Feature creep whereby embedded objects in Office files introduce new security risks… who knew?


Gozi banking malware “IT chief” finally jailed after more than 10 years

Yesterday, we wrote about cybercrime charges that were finally unsealed for a massive cryptocurrency heist that was allegedly conducted over a three-year period starting back in 2011.

Today’s long-term cybercrime justice story concerns the last member of the so-called Gozi Troika, three men who were originally charged in January 2013 for malware-related crimes that apparently kicked off way back in the late 2000s:

Those charges were publicised at that time under a dramatic US Department of Justice (DOJ) headline:

Three Alleged International Cyber Criminals Responsible For Creating And Distributing Virus That Infected Over One Million Computers And Caused Tens Of Millions Of Dollars In Losses Charged In Manhattan Federal Court

The three criminals on the charge sheet (back then, they were only suspects, but all three have subsequently been convicted in court) were:

  • Mihai Ionut Paunescu of Romania, then 28. He ran what are known as “bulletproof hosts” for the enterprise, providing servers for the gang that were supposed to keep ahead of any disruption efforts by law enforcement or mainstream ISPs. So-called bulletproofers shift their services around online to sidestep takedown attempts, blocklisting, and other crime-fighting measures.
  • Deniss Čalovskis of Latvia, then 27. He was the Gozi group’s web expert, coding up bogus HTML content that the malware could inject into legitimate web pages in order to trick victims and steal their account information.
  • Nikita Kuzmin of Russia, then 25. He was effectively the COO, hiring coders to work on the Gozi malware, and running what is now known as a Crimeware-as-a-Service (CaaS) business based around it.

A long and winding road

The arrests and convictions of this trio make a fascinating and twisty tale.

Kuzmin was the first to get busted, back in 2013.

He spent 37 months in custody in the US as his court case progressed, before pleading guilty in 2016, receiving a three-year prison sentence, and paying a “fine” of close to $7,000,000, presumably clawed back from his illegal earnings.

At the time, the DOJ used his case as an explainer for the whole CaaS “franchise model” that cybercriminals started adopting from the late 2000s onwards:

In addition to creating Gozi, Kuzmin developed an innovative means of distributing and profiting from it. Unlike many cybercriminals at the time, who profited from malware solely by using it to steal money, Kuzmin rented out Gozi to other criminals, pioneering the model of cybercriminals as service providers for other criminals. For a fee of $500 a week paid in WebMoney, a digital currency widely used by cybercriminals, Kuzmin rented the Gozi “executable”, the file that could be used to infect victims with Gozi malware, to other criminals.

Kuzmin designed Gozi to work with customized “web injects” created by other criminals that could be used to enable the malware to target information from specific banks; for example, criminals who sought to target customers of particular American banks could purchase web injects that caused the malware to search for and steal information associated with those banks. Once Kuzmin’s customers succeeded in infecting victims’ computers with Gozi, the malware caused victims’ bank account information to be sent to a server that Kuzmin controlled where, as long as the criminals had paid their weekly rental fee, Kuzmin gave them access to it.

Next to face a US court was the “web inject” expert Čalovskis, who was arrested in his native Latvia but successfully resisted extradition for two years, arguing that the maximum sentence he faced in the US, openly listed by the DOJ as a whopping 67 years, was unreasonable by Latvian standards:

But the US and Latvian authorities seem to have reached a middle ground whereby Čalovskis would face a mutually acceptable sentence, supposedly of no more than two years, after which he was sent to face trial:

Čalovskis then pleaded guilty, admitted on the record that “I knew what I was doing was against the law”, and received a 21-month sentence, equivalent to the time he’d already been incarcerated in Latvia and the US.

Unfree at last

The longest holdout from justice was Paunescu, who remained free for eight years until he was picked up in June 2021 at Bogotá International Airport in Colombia:

The Colombians, it seems, then contacted the US diplomatic corps, assuming that the US still considered Paunescu a “person of interest”, and asking whether the US wanted to apply to extradite him from Colombia to stand trial in America.

As you can imagine, the answer from the US was, “Most definitely yes,” and Paunescu ultimately arrived in the US to face the music in July 2022:

Paunescu pleaded guilty in February 2023, and was finally sentenced in a Manhattan federal courtroom yesterday [2023-06-12], well over a decade after his criminal activity and his original indictment:

[Paunescu, also known by the handle] “Virus”, was sentenced to three years in prison today […] for conspiracy to commit computer intrusion in connection with running a “bulletproof hosting” service that enabled cybercriminals to distribute the Gozi Virus, the Zeus Trojan, the SpyEye Trojan, and the BlackEnergy malware, all of which were designed to steal confidential financial information.

Paunescu also enabled other cybercrimes, such as initiating and executing distributed denial of service (DDoS) attacks and transmitting spam.

He’ll be given credit for the 14 months he’s already spent in custody awaiting extradition and trial, so he’s got just under two years still to serve.

He also has to hand over $3,510,000, and pay restitution to the tune of almost $20,000.

It took a long time, but the FBI and the DOJ got all three suspects in the end…


LEARN MORE: BANKING TROJANS AND OTHER MALWARE TYPES


History revisited: US DOJ unseals Mt. Gox cybercrime charges

Remember Mt. Gox?

Originally, it was a card-trading site called MTGOX, short for Magic The Gathering Online Exchange (there was no sense of “Mountain” in the name at all), but the domain changed hands and purpose in the early days of cryptocurrency.

Operated out of Japan by French expatriate Mark Karpelès, Mt. Gox rapidly became the biggest online Bitcoin exchange, but imploded in 2014 when the company was forced to admit that it had lost Bitcoins worth more than $0.5 billion at the time (they’d be worth more than 25 times as much today).

As we wrote back then:

In 2014, the Big Daddy of Bitcoin exchanges, Japan-based Mt. Gox, made a “So sorry, they seem to have vanished” announcement about a whopping 650,000 Bitcoins, worth approximately $800 each at the time.

The mystery of the missing BTCs was at first blamed on a cryptographic flaw in the Bitcoin protocol that Mt. Gox’s coders hadn’t defended against properly – something they really ought to have done, considering that they were sitting on half-a-billion dollars worth of other people’s assets.

But that story didn’t wash with everyone, not least those who thought that any abuse of the flaw concerned (it’s euphemistically known as transaction malleability if you would like to look it up) ought to have been visible, albeit too late, in the transaction record.

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

Ironically, the very sort of incautious attitude to coding that would make a transaction malleability exploit possible would probably also make it possible for rogue insiders to get away unnoticed with large-scale Bitcoin larceny.

That’s where the story sat throughout the second half of 2014: something bad happened, but no-one quite knew whom to blame.

But on New Year’s Day 2015, as we noted in that report, Japanese newspaper Yomiuri Shimbun published a dramatic article in which it openly stated that there was “strong suspicion” that most of the missing Bitcoins were ripped off from inside.

The paper suggested that although the loss of BTC 7000 could be explained by cyberattack (in other words, that crooks outside the company’s network were the perpetrators), there was no evidence of cyberattack in repsect of the remaining BTC 643,000.

In short, the reporters at Yomiuri Shimbun were as good as saying, 99% of the crime was an inside job.

Karpelès, for his part, ultimately received a suspended prison sentence in Japan, but that was because he was found guilty of misrepresenting his financial position to potential investors, not because of the missing Bitcoins.

Not Karpelès

Ironically, perhaps, Karpeles now has what amounts to a partial exoneration on the matter of the many missing Bitcoins, with the US Department of Justice unsealing Mt. Gox-related charges against two named individuals:

Alexey Bilyuchenko, 43, and Aleksandr Verner, 29, both Russian nationals, are charged with conspiring to launder approximately 647,000 bitcoins from their hack of Mt. Gox.

[…]

Bilyuchenko, Verner, and their co-conspirators allegedly used their unauthorized access to Mt. Gox’s server to fraudulently cause bitcoin to be transferred from Mt. Gox’s wallets to bitcoin addresses controlled by Bilyuchenko, Verner, and their co-conspirators.

From September 2011 through at least May 2014, Bilyuchenko, Verner, and their co-conspirators allegedly caused the theft of at least approximately 647,000 bitcoins from Mt. Gox, representing the vast majority of the bitcoins belonging to Mt. Gox’s customers.

Bilyuchenko, Verner, and their co-conspirators allegedly laundered the bulk of the bitcoins stolen through Mt. Gox principally through bitcoin addresses associated with accounts Bilyuchenko, Verner, and their co-conspirators controlled at two other online bitcoin exchanges.

In an intriguing twist, Bilyuchenko is also charged with operating one of those “two other online Bitcoin exchanges”, the notorious exchange known as BTC-e, along with a third individual named Alexander Vinnik.

BTC-e ran from 2011 until July 2017, when it was busted and shut down by US law enforcment.

Vinnik was indicted back then by a US court on money-laundering charges, after being arrested in Greece.

(Since then, Vinnik has variously been in custody in Greece; extradited to France, where he was sent to prison for money laundering; returned to Greece after his release; and then extradited to the US to face charges there.)

The DOJ’s press release about these new charges, relating to a hack that now dates back more than 10 years, says simply that Bilyuchenko and Verner are “Russian nationals”, but not which country the two men are in right now.

But US Attorney Ismail J. Ramsey did go on the record to say:

For years, Bilyuchenko and his co-conspirators allegedly operated a digital currency exchange that enabled criminals around the world – including computer hackers, ransomware actors, narcotics rings, and corrupt public officials – to launder billions of dollars.

The Department of Justice will work tirelessly to identify cyber criminals, no matter where they are.

And Bilyuchenko and his co-conspirators will learn that the Department of Justice has long arms and an even longer memory for crimes that harm our communities.

As for Mt. Gox, its winding-up process is at last drawing to a close, with the final deadline for recognised corporate creditors to file verification documents recently extended until 2023-06-15, just three days from now.

Though the mills of the Law grind slowly/Yet they grind exceeding small/Though with patience they stand waiting/With exactness grind they all…

…or, at least, we can but hope they do and will.


LEARN MORE ABOUT BTC-E (AND HOW DARK WEB CROOKS GET CAUGHT)

We talk to renowned cybersecurity author Andy Greenberg about his excellent book, Tracers in the Dark: The Global Hunt for the Crime Lords of Cryptocurrency.

No audio player below? Listen directly on Soundcloud.
Prefer reading to listening? Full transcript available.


go top