IT News

Explore the MakoLogics IT News for valuable insights and thought leadership on industry best practices in managed IT services and enterprise security updates.

A week in security (July 5 – July 11)

Last week on Malwarebytes Labs:

Other cybersecurity news:

  • A group of privacy-first tech companies have published an open letter today asking regulators to ban surveillance-based advertising. (Source: The Record)
  • Fake cryptomining apps, some found on the Play Store, scam $350,000 from users. (Source: TechSpot)
  • Ransomwhere has been launched as the open, crowdsourced ransomware payment tracker.
  • The hard truth about ransomware: we are not prepared. (Source: DoublePulsar)
  • Hackers leak scraped data of 87,000 GETTR users. (Source: HackRead)
  • Cyber is the new weapons system of the future. (Source: The Cipher Brief)
  • NCSC: Impersonating the taxman remained phishers’ favourite pastime. (Source: The Register)
  • Hackers use new trick to disable macro security warnings in malicious Office files. (Source: The Hacker News)
  • How fake accounts and sneaker-bots took over the internet. (Source: ThreatPost)
  • Online course provider Coursera hit with API issues, with cloud driving additional exposure. (Source: SC Magazine)

Stay safe, everyone!

The post A week in security (July 5 – July 11) appeared first on Malwarebytes Labs.

DNS-over-HTTPS takes another small step towards global domination

Firefox recently announced that it will be rolling out DNS-over-HTTPS (or DoH) soon to one percent of its Canadian users as part of its partnership with CIRA (the Canadian Internet Registration Authority), the Ontario-based organization responsible for managing the .ca top-level domain for Canada and a local DoH provider. The rollout will begin on 20 July until every Firefox Canada user is reached in late September 2021.

This announcement came five months after Firefox rolled out DoH by default for its US-based users.

The overall purpose of this rollout is to increase the privacy of all Firefox users by encrypting DNS requests. DNS requests are sent in plain text—meaning, any computer they pass through is able to see what website domains you’re looking up and likely visiting. This includes websites you visit over an encrypted connection, prefixed with https://. The DNS resolver the request is sent to also sees the DNS request, too. It needs to in order to convert the domain name users want to visit to the IP address equivalent for that destination. DNS-over-HTTPS is designed to shut out everyone else.

Because a DNS request has no encryption—again, regardless of whether the website you want to visit is encrypted or not—intermediates can monitor or modify DNS requests. This means that the organization you work for, your favorite coffee shop, or your ISP, can spy on your web browsing history without you knowing or letting you know what they do with the information.

“Today, we know that unencrypted DNS is not only vulnerable to spying but is being exploited, and so we are helping the internet to make the shift to more secure alternatives,” wrote Selena Deckelmann on Mozilla’s official blog. “We do this by performing DNS lookups in an encrypted HTTPS connection. This helps hide your browsing history from attackers on the network, helps prevent data collection by third parties on the network that ties your computer to websites you visit.”

The downside of encrypting DNS

Not everyone is a fan of DNS-over-HTTPS. To many, DNS-over-TLS is a more appropriate solution to the encryption problem but its “correctness” is also its great flaw. DNS-over-TLS communication (and nothing else) happens on port 853. Your ISP, or employer, can’t spy on your DNS requests if you use DNS-over-TLS but they can block port 853 and stop you from using it, leaving you no option but to revert to the unencrypted version of DNS on port 53, which they can spy on.

DoH communication happens on port 443, the port used for https:// web browsing. Because of that, DoH requests are indistinguishable from web traffic. Your ISP or employer can’t block port 443 to stop DoH without also stopping all web browsing. And an ISP that does that will quickly find itself with no customers.

So, from a personal privacy point of view, DoH is a clear win. But from a corporate security point of view it’s a problem. Security appliances like Next-Generation firewalls want to peer inside network traffic to identify security threats, and encryption like DoH makes that harder.

Some are also concerned about the way DoH might centralize trust. Using DNS-over-HTTPs is similar to using a third-party VPN in that it keeps your traffic private inside an encrypted tunnel, but you have to trust the VPN vendor or DNS resolver at the end of the tunnel an awful lot. Because DoH is relatively new there aren’t many DoH resolvers. So instead of everyone’s DNS requests being fulfilled by their respective ISPs they are sent to one of a relatively small number of DoH resolvers, operated by organizations like Google and CloudFlare.

CIRA Canadian Shield

In the case of Canadian Firefox users, their DNS resolver is CIRA. Canadian users who use DoH by default will begin seeing “CIRA Canadian Shield” as their default DNS provider. You can read more about CIRA Canadian Shield on CIRA’s official website here.

mozilla DoH Doorhanger
Canadian users of Firefox should expect this window, letting them know that their DNS requests are encrypted and router through a DoH provider. (Source: Mozilla Blog)

“Protecting the privacy of Canadians is a key element of restoring trust on the internet,” says CIRA President and CEO Byron Holland in a statement, “Our goal is to cover as many Canadians as possible with Canadian Shield, and that means finding like-minded partners who share our values. We are proud to be the first Canadian participant in the Trusted Recursive Resolver (TRR) Program and are always seeking out new ways to extend the reach of Canadian Shield to enhance the privacy of Canadians.”

The post DNS-over-HTTPS takes another small step towards global domination appeared first on Malwarebytes Labs.

How one word can disable an iPhone’s WiFi functionality

A researcher has found a way to disable the WiFi functionality on iPhones by getting them to join a WiFi hotspot with a weird name.

This shouldn’t be happening. The first thing you learn in coding school when it comes to input (which is literally any data a device has to do something with) is to validate it. Well, maybe not the first thing, but if you want to practice secure coding it is one of the most important things: Make sure that a hacker can not abuse your application by feeding it something it can’t digest. Like a WiFi network name.

It is not the first time by the way that iPhones can be compromised by using a format string vulnerability. And I’m afraid it will not be the last.

Let’s talk iPhone

iPhones are supposedly much more secure than Android devices, but as it turns out I can disconnect your secure iPhone from any WiFi by using a simple format string vulnerability. All I would have to do is make you connect to a specific WiFi hotspot.

The magical WiFi network name (SSID) for fritzing your phone is %p%s%s%s%s%n but since the underlying issue is almost certainly the fact that  % is interpreted as a string format specifier, you can bet there are more possibilities to be found.

String format specifiers

In programming you sometimes have to build words and sentences you want to show the user using some information you know in advance, and some you don’t. In C and C-style languages, string format specifiers are used. They have a special meaning and are processed as variables or commands by the printf function.

A simple printf command might look like this:

printf("Malwarebytes %n rules", &c);

In this example %n is a string format specifier that modifies the output. When the program prints the sentence “Malwarebytes %n rules” the %n will be replaced by the number of characters preceding it, so it will output:

Malwarebytes 13 rules

There are many other format specifiers that do different things. They look like a percentage sign followed by a single character that specifies the type of data, for example %s will be replaced by a string of characters, %d by a number (a decimal integer), %p by a pointer address and so on.

So you can see why an WiFi network called %p%s%s%s%s%n might cause problems. Apple’s programmers should have ensured their code reads names like that as percent signs and letters, not as string format specifiers. It seems they didn’t.

Seriousness

I can hear you thinking, so what? I would never join a WiFi Hotspot with such a weird name. Well, maybe you wouldn’t, if you would notice that the name looks out of the ordinary. But anyone can spoof a well-known SSID and your device will happily connect to it again if it’s connected to an open SSID by that name before.

Other research has shown that the vulnerability is not only restricted to the iOS operating system, it can potentially affect the macOS operating system. The same research team found a way to construct the network name in a way that does not expose the user to the weird characters, making it look like a legitimate, existing network name.

It is not impossible that researchers will find a way to construct SSID names that can lead to remote code execution (RCE) attacks. But this will probably turn out to be too complicated since you would be limited by the maximum length of an SSID (32 characters), the limited functionality of the string  format specifier, and the memory location of the format string. The format string is located on the heap which does not provide the attacker control of the pointers on stack. Which is not to say that this method could not be used in combination with other vulnerabilities.

Recovery from testing

If you couldn’t resist testing this and now you want your WiFi options back, here is how to do it. You will have to reset their iPhone network settings (Settings > General > Reset > Reset Network Settings), which will erase all your WiFi passwords. This is not a permanent fix for the issue. Any time your device is affected by the issue, you will have to reset it again.

And don’t go overboard with your testing. As this researcher has found out the reset does not work for every possible string.

The post How one word can disable an iPhone’s WiFi functionality appeared first on Malwarebytes Labs.

Judge drops hammer, dishes 7 years slammer for BEC and romance scammer

A Texas resident has finally paid the price for a heady mix of malicious mail antics. A combination of business email compromise (BEC) scams and romance fakeouts bagged them $2.2 million across roughly 6 years.

This is quite a divergent portfolio of scamming activity. You may typically assume BEC scammers, for example, stick to that as it’s their area of expertise. Did you want the fake romance department? Sorry, they’re back down the hall.

If nothing else, this case is instructive in that people running these schemes happily mix-and-match. Shall we take a look?

Business email compromise 101

Business email compromise is a simple yet potentially devastating attack aimed at organisations the world over. These begin with a phish from a stolen or spoofed company mail address. If the address belongs to someone in finance or a CFO, so much the better. The aim of the game is convincing someone to wire funds overseas. If the company has no mechanisms in place to deal with such a threat, there’s a good chance the money is gone forever.

Romance scams 101

These have been around pretty much forever. You know the score: Fake military generals promising a new life overseas, catphishing, random emails out of the blue from people who only need the cost of the airfare to fall into your arms, and so on.

Something this has in common with BEC scams is the ridiculous amount of money to be made from it. Both of these scam areas are wildly profitable for people who know what they’re doing.

So now you can perhaps see why this particular individual was so invested in dabbling in not one, but two scam tactics. With that short explanation out of the way, let’s get back to the story at hand.

What happened in Texas?

Roughly seven years of imprisonment and an order to pay $865,210.78 back to victims, that’s what.

You know how we’re always warning people about the risk to fraud victims from money laundering? That’s where an innocent party is tricked into moving money from / to accounts, without realising the money has been stolen. The innocent party, otherwise known as a money mule, is left holding the legal responsibility as the perpetrators pull strings from behind the scenes. Prison time often beckons.

Here, we have someone caught by those same rules while actively getting up to no good. According to the a release, the perpetrator pleaded guilty to one count of conspiracy to commit money laundering.

Using a “fraudulent foreign passport” to open a number of bank accounts in different areas, they used them to:

…receive, launder and distribute wire transfers to coconspirators illegally receiving proceeds of BEC and romance schemes.  For his efforts, Onoimoimilin collected between 10% and 15% of more than $420,000 in fraudulently obtained funds.

New crimes, old laws

It’s frequently tricky to charge people with bad computer related activities, despite there being quite a lot of laws to cover them. Money laundering though, that’s a relatively straightforward one and legal folks understand it perfectly. If they can prove you’ve been ushering money in and out of your account in ways you shouldn’t be, rest assured a whole lot of trouble is heading your way.

Mileage may vary for how satisfying it is for victims to see this person put in prison. There’s almost certainly folks who won’t be getting their money back. Considering we’re talking about life savings and wage packets, there won’t be a happy ending for everyone. Whether we’re talking BEC or romance scams, we need to do our part to ensure we give scammers as few opportunities to strike as possible.

The post Judge drops hammer, dishes 7 years slammer for BEC and romance scammer appeared first on Malwarebytes Labs.

How to send an anonymous email

Sometimes readers ask us how to send an anonymous email or how criminals and scammers manage to send anonymous emails. Since this is not an easy question to answer, because, for starters, there are several ways to interpret the question, I’ll try to give you some information here.

Interpret the question

Sending an anonymous letter via snail-mail was easy. You forgot to add the sender address, filled out a false one, and if there was a chance the receiver could recognize you by your handwriting you used newspaper clippings to construct the sentences. And snail mail had the advantage that you could drop your message in a mailbox that gathered mails from various senders before starting the delivery process. So, not even the carrier had any way to identify the sender. The place of origin is hidden except maybe roughly by looking at the post stamp to see from what postal district the letter came. Unless the sender went through the trouble of driving halfway across the country to post the letter.

As you can see there are a few sides even to this low-tech version of an anonymous mail:

  • No sender address
  • False sender address
  • Masking the content > encryption
  • Carrier
  • Origin masking

What is a spoofed email?

Since sending an email without a sender address can result in errors and will certainly raise suspicion, it is easier to spoof a sender address. Spoofing is sending an email with a false sender address. Spoofing an address is relatively simple since the Simple Mail Transfer Protocol (SMTP) does not check the information in the  “From”, “Reply to”, or “Sender” fields. The only reason it is possible to track back an email with a spoofed address is because the email headers will include the sending IP address.

So, to pull off a completely untraceable spoofed email the sender will have to use a VPN to mask their IP address or use a compromised system to send the emails from. Compromised servers are popular with people running malicious email campaigns.

How can I send and receive an encrypted email?

A very different concern is to hide the content of an email from anyone except the intended receiver. This requires some type of encryption that only the receiver can decrypt. Encrypting emails like this—known as end-to-end encryption—has historically been difficult, although the tools for achieving this kind of encryption are getting better and easier to use.

Most emails are encrypted during transmission, but they are stored in clear text when they are at rest, making them readable by third parties such as email providers. But there are some providers that provide end-to-end encryption and zero access encryption to secure emails. This means even the service provider cannot decrypt and read your emails.

If you want to have full control and not depend on a provider you will need to exchange public keys with the parties that you want to start encrypted communications with. Once you have exchanged keys, most email clients will offer you the option to encrypt emails on a per-message basis.

How can I send an email anonymously?

I wrote a blog post on how to send encrypted mails a long time ago. Some things have become considerably easier since then. Some carriers offer you the option to send end-to-end encrypted email for free. Personally I have only tried Protonmail which allows you to come up with your own email address, and even the free version is free of advertisements. You only need to provide an existing email address if you want to use that as a recovery method in case you forget your credentials. If you do not need that option the sign-up procedure is completely anonymous.

Is ProtonMail really anonymous?

Protonmail is a secure email provider that does not solicit any information from you to use the free version, as long as you don’t chose to use the recovery option. For any legitimate use case Protonmail can be considered secure and private. This is considering that for any legitimate use cases it should be enough to send an encrypted email, so that the intended receiver is the only one that can read the content of the message.

Protonmail can even be used in combination with a VPN so that even your IP address remains hidden. Unfortunately this also makes the service very popular amongst ransomware peddlers who sometimes create individual Protonmail accounts for every single victim.

Can email be traced?

Even hardened criminals make mistakes, so you should always be weary of the fact that an email you sent can be tracked back to you. On the other hand it is virtually impossible for anyone to trace back an email that was sent using all the techniques we have described above. As so often, it is wise to assume the worst possible scenario. We have seen script kiddies that thought they could use a Gmail account as a means to send anonymous emails. Maybe the receiver will not be able to trace it back, but the police certainly will, with some help from Google. If you need plausible deniability don’t put it in writing. For legitimate use we hope to have handed you some useful tips.

I have received an anonymous or spoofed email. What should I do?

How you deal with any mails you receive normally depends on the content. As with any email, it is advisable to scrutinize whether the email and the sender are who and what they claim to be. If you recognize the sender but don’t trust the content, contact the sender through other means to verify they sent it. Do not send read receipts or other confirmations that you have read the mail before you are sure you can trust the sender.

You can find some tips on how to recognize and deal with unsolicited mail in this blogpost about recognizing and disposing of malicious emails and this article about phishing. If the mail has the character of an extortion email you may find our post describing what to do when you receive an extortion email helpful. Depending on where you live it may be prudent, or even mandatory, to inform the proper authorities about any extortion attempts.

The post How to send an anonymous email appeared first on Malwarebytes Labs.

Kaseya update delayed for security reasons

Software vendor Kaseya has been caught in the chaos of a supply-chain compromise by the REvil ransomware gang since Friday. Around 40 managed service providers (MSPs) that rely on Kaseya VSA software to administer customers’ IT—and up to 1,500 of their customers—have been stricken with the ransomware.

In response to the attack, Kaseya shutdown the SaaS version of VSA, and instructed users of its on-premises customers to do the same. Organizations that use Kaseya VSA, and their clients, have been without the administration tool since.

Yesterday, the company released a video detailing the attack and steps taken to mitigate it. It was hoping to be back up and running as soon as possible, but it seems an already cautious approach has taken on an additional helping of reserve.

A new, unscripted video has been released in the last few hours which details a delay to getting things back up and running. The original estimate for a recovery timeline appeared to be bringing the SaaS version of VSA back on Tuesday morning, with on-premises installations to follow. That then switched to today. This latest video now mentions Sunday as the most likely date for things to get moving. The reason? Security, apparently.

Security concerns

Friday’s attack was made possible by a zero-day vulnerability in the on-premises VSA platform. Since then, Victor Gevers of the Dutch Institute for Vulnerability Disclosure (DIVD) has revealed that the organization had been in a “coordinated vulnerability disclosure process” with Kaseya at the time of the attack. Fixing those is clearly top of Kaseya’s agenda before it can instruct customers to restart VSA servers.

Striking an apologetic and far less bullish tone than in his first video, the beleaguered Kaseya CEO, Fred Voccola, says the new release time is going to be “this Sunday, in the early afternoon, Eastern Standard time“. This decision, he says, is down to him alone in order to put additional layers of protection in place.

In his own words:

The reason for that is we had all the vulnerabilities that were exploited during the attack, we had them locked. We felt comfortable with the release. Some of the third-party engineers, engineering firms and companies that we’ve been working with, as well as some of our own IT people, made some suggestions to put additional layers of protection in there for things that we might not be able to foresee. This was probably the hardest decision that I’ve had to make in my career. And, we decided to pull it for an additional three and a half days, or whatever the approximate time is … to make sure that it is hardended as much as we feel we can do for our customers.

The slow, careful approach will no doubt cause some roadblocks for customers waiting on systems to be back online. However, this has to be a better alternative than something else happening because a weak spot wasn’t identified.

The company has released a Compromise Detection Tool, and created a runbook of changes Kaseya VSA customers will need to their on-premises environments to prepare for Sunday’s patch.

You can see a full up-to-date timeline of events in the Kasya supply-chain attack in our original article. We will update this as new facts emerge.

The post Kaseya update delayed for security reasons appeared first on Malwarebytes Labs.

Malspam banks on Kaseya ransomware attack

The Malwarebytes Threat Intelligence Team recently found a malicious spam campaign making the rounds and banking on the ransomware attack that forced Kaseya to shut down its VSA service.

This is a classic example of an opportunistic attack conducted by (potentially) another threat actor/group off the back of another threat actor/group’s attack. With Kaseya being a big name in the MSP world and the company attempting to take their VSA SaaS platform off the ground, post-attack, it’s the perfect time and opportunity to also capitalize on organizations who are eagerly waiting for the hotfix that REvil exploited in the first place so they can get back to business as quickly as possible.

E5pFs3PWUAcBCnQ
This is a sample malspam captured by Malwarebytes experts. Note that it appears to be a reply that is part of an email thread.

The email that Malwarebytes found contains both a malicious link and attachment purporting to have come from Microsoft. The link leads to the download of a file called ploader.exe while the attachment, named SecurityUpdate.exe. Both of these are Cobalt Strike payloads.

The email reads in part:

“Guys please install the update from microsoft to protect against ransomware as soon as possible. This is fixing a vulnerability in Kaseya.”

The Threat Intelligence Team at Malwarebytes also noted that the location where the payload is hosted is the same IP address used in another malspam campaign that was pushing Dridex, a known information stealer. In the past, threat actors behind Dridex campaigns were also observed using Cobalt Strike.

If you may recall, Cobalt Strike is a legitimate software that bills itself as an “adversary simulation software.” Ransomware actors, in particular, are known to abuse legitimate software and make it part of their overall malicious attack against target organizations during their big game hunting (BGH) campaigns.


If you’re a Kaseya client, you can get first-hand updates on the VSA incident here.


It goes without saying that any and all companies affected by the Kaseya ransomware attack should only get patches straight from their vendor. Links and/or attachments sent over your way, even from a trusted colleague, should be suspect until you have confirmed with your vendor of the availability of a patch and where or how to get it. Realize that this is not the first time that threat opportunists bank on attacks like what Kaseya experienced. Opportunists will show no mercy in targeting cyber attack victims multiple times as long as they get something out of it.

In this case, with the use of Cobalt Strike, these threat actors intend to also gain access to your already-compromised system possibly for further reconnaissance or to conduct a local, follow up attack.

Stay safe!

The post Malspam banks on Kaseya ransomware attack appeared first on Malwarebytes Labs.

Patch now! Emergency fix for PrintNightmare released by Microsoft

Last week we wrote about PrintNightmare, a vulnerability that was supposed to be patched but wasn’t. After June’s Patch Tuesday, researchers found that the patch did not work in every case, most notably on modern domain controllers. Yesterday, Microsoft issued a set of out-of-band patches that sets that aims to set that right by fixing the Windows Print Spooler Remote Code Execution vulnerability listed as CVE-2021-34527.

Serious problem

For Microsoft to publish an out-of-band patch a week before July’s Patch Tuesday shows just how serious the problem is.

PrintNightmare allows a standard user on a Windows network to execute arbitrary code on an affected machine, and to elevate their privileges as far as domain admin, by feeding a vulnerable machine a malicious printer driver. The problem was exacerbated by confusion around whether PrintNightmare was a known, patched problem or an entirely new problem. In the event it turned out to be a bit of both.

Last week the Cybersecurity and Infrastructure Security Agency (CISA) urged administrators to disable the Windows Print Spooler service in domain controllers and systems that don’t print.

However, the installation of the Domain Controller (DC) role adds a thread to the spooler service that is responsible for removing stale print queue objects. If the spooler service is not running on at least one domain controller in each site, then Active Directory has no means to remove old queues that no longer exist.

So, many organizations were forced to keep the Print Spooler service enabled on some domain controllers, leaving them at risk to attacks using this vulnerability.

Set of patches

Depending on the Windows version the patch will be offered as:

  • KB5004945 for Windows 10 version 2004, version 20H1, and version 21H1
  • KB5004946 for Windows 10 version 1909
  • KB5004947 for Windows 10 version 1809 and Windows Server 2019
  • KB5004949 for Windows 10 version 1803 which is not available yet
  • KB5004950 for Windows 10 version 1507
  • Older Windows versions (Windows 7 SP1, Windows 8.1 Server 2008 SP2, Windows Server 2008 R2 SP1, and Windows Server 2012 R2) will receive a security update that disallows users who are not administrators to install only signed print drivers to a print server.

Security updates have not yet been released for Windows 10 version 1607, Windows Server 2016, or Windows Server 2012, but they will also be released soon, according to Microsoft.

The updates are cumulative and contain all previous fixes as well as protections for CVE-2021-1675.

Not a complete fix

It is important to note that these patches and updates only tackle the remote code execution (RCE) part of the vulnerability. Several researchers have confirmed that the local privilege escalation (LPE) vector still works. This means that threat actors and already active malware can still locally exploit the vulnerability to gain SYSTEM privileges.

Advice

Microsoft recommends that you install this update immediately on all supported Windows client and server operating systems, starting with devices that currently host the print server role. You also have the option to configure the RestrictDriverInstallationToAdministrators registry setting to prevent non-administrators from installing signed printer drivers on a print server. See KB5005010 for more details.

“The attack vector and protections in CVE-2021-34527 reside in the code path that installs a printer driver to a Server. The workflow used to install a printer driver from a trusted print server on a client computer uses a different path. In summary, protections in CVE-2021-34527 including the RestrictDriverInstallationToAdministrators registry key do not impact this scenario.”

CISA encourages users and administrators to review the Microsoft Security Updates as well as CERT/CC Vulnerability Note VU #383432 and apply the necessary updates or workarounds.

Impact of the updates

So, the vulnerability lies in the normal procedure that allows users to install a printer driver on a server. A printer driver is in essence an executable like any other. And allowing users to install an executable of their choice is asking for problems. Especially combined with a privilege escalation vulnerability that anyone can use to act with SYSTEM privileges. The updates, patches, and some of the workarounds are all designed to limit the possible executables since they need to be signed printer drivers.

For a detailed and insightful diagram that shows GPO settings and registry keys administrators can check whether their systems are vulnerable, have a look at this flow chart diagram, courtesy of @gentilkiwi.

The post Patch now! Emergency fix for PrintNightmare released by Microsoft appeared first on Malwarebytes Labs.

Game over: Apex Legends players locked out by protest message

Messages placed directly in or around games is a common hack technique. It can be used for trolling, phishing, scams, or anything else the message-placer can think of. Messages can also be placed in games for the purposes of advertising but that’s a tale for a different day.

Recently, players of Apex Legends have found themselves blocked from playing the game, thanks to said message placement. The multiplayer title had server playlists switched out for commentary on the state of Titanfall. This is an older game made by the same developers, Respawn Entertainment.

Levelling up a pyrrhic victory

Fans have complained for a while now that Titanfall has become unplayable due to hacks and cheaters. As such, this message – “Save Titanfall, TF1 is being attacked so is Apex” gave the same treatment to Apex Legends that Titanfall has been plagued by. Can’t play one game? Sorry, then you can’t play this game over here either. A sort of mutually assured destruction played out in games over screens.

Game developers Respawn have come out all digital guns blazing, claiming the attacks “achieved nothing of value”. This is because the messages referenced a campaign to “save” Titanfall which they were already aware of. Besides the extra work for the devs and a ruined weekend, the biggest reputation hit belongs to the Save Titanfall campaign. They’ve had to place a message at the top of their site which reads

IMPORTANT MESSAGE: This website, nor the Discord servers listed below, are in no way associated with the recent Apex Legends hack.

Plugging the DDoS gap in gaming

Ouch. DDoS attacks in video game land have been around forever. As the Respawn dev points out, solving such problems in gaming environments isn’t easy. Being locked out of multiplayer only games isn’t something the players can fix, so all eyes will be on the dev team to see what they can do about the current, occasional lack of a state of play.

It’s possible more antics will take place in Apex land until such time as Titanfall is back to full health, so gamers should be on their guard.

The post Game over: Apex Legends players locked out by protest message appeared first on Malwarebytes Labs.

3 things the Kaseya attack can teach us about ransomware recovery

Only rarely do companies allow us a look inside their organization while they are recovering from a ransomware attack. Many find it more convenient to keep a low profile or to be secretive.

A positive exception to this is found in the Dutch managed service provider (MSP) VelzArt, one of the many unfortunate victims of Friday’s enormous, cascading supply-chain attack on Kaseya. The attack used a zero-day vulnerability to create a malicious Kasaya VSA update, which spread REvil ransomware to some of the MSPs that use it, and then on to the customers of those MSPs.

Instead of avoiding the limelight, VelzArt has blogged meticulously since Friday about how it and its customers were affected, and the steps it has taken to get them up and running.

VelzArt offers its customers a broad spectrum of ICT solutions, delivered using remote administration tools. One of those tools is Kaseya VSA. The company writes that it was in the process of switching to another remote administration platform at the time of the attack, but Kaseya software was still installed on some customers’ systems. Since Friday it has been working to recover those customers.

Here are five lessons we can all learn about recovering from ransomware, thanks to VelzArt’s admirable transparency.

1. Know when to communicate

Communication is key during times of crisis. VelzArt writes that after learning about the ongoing attacks in the evening of July 2, it immediately informed the customers it managed using Kaseya software by mail, phone, and newsletters. It also started the blog that became the basis for this article.

This open communication allowed it to triage more effectively. A production company that works 24/7 needs their servers more urgently in the weekend than a law firm that needs everything ready by Monday morning.

During the evening and night, VelzArt says it limited its customer contact to email, in order to prioritize actually getting the recovery procedures done. While it is understandable that anxious customers want to be kept informed, there has to be time for actually getting the work done.

2. Backups take time

Recovering from a ransomware attack normally means rebuilding everything from backups. And that makes backups a target for ransomware.

VelzArt writes that on most servers and some of the workstations, it was able to restore from backups without any major problems. However, stopping the attackers getting to the backups is only half the battle. Machines that have been attacked by ransomware may be harbouring other malware, so backups need to be loaded on to a clean machine, and that takes time: Restoring backups is not a quick fix.

VelzArt says that the servers that were taken offline to stop the attack had to be picked up from clients, checked, reinstalled, and then made ready for normal operations. The company writes that it took quite some effort to pull that off, with staff working in teams through the night. Extra power circuits had to be set up to handle the extra demand.

The company expected 70 percent of servers to be restored by the start of Tuesday. On Tuesday, they hoped to get started with gathering all the workstations that had a back-up option, and Wednesday would be the day to get the re-installed workstations back into their operational status, meaning they would get the necessary software installed, and connected to the network.

3. Help can come from unexpected places

Recovering from ransomware doesn’t just take time, it takes people, too. If you are recovering from a ransomware attack there is a good chance that you will need external help.

VelzArt writes that it worked with one customer on a trial for self-remediation. Because of a lack of information from Kaseya it was not sure how much work would be needed for every individual workstation. The company hoped that the trial would produce a method they could use with other customers.

On Sunday afternoon they asked customers to turn on their workstations, without logging in, stating that they found an automated way to restore workstations remotely. The activated workstations gave VelzArt an idea of what the impact of the attack had been. A warning was given to the customers that the reset procedure for the affected workstations would result in a total loss of local data and installed software. Basically, the system would be flattened and reinstalled.

By Monday morning the automated script it had worked out with the help of one willing company was ready to help the others.

VelzArt also noted that friendly competitors had offered to help them resolve the situation. An offer they were happy to tell their customers they had accepted, in order to speed up the recovery.

Insight from another victim

VelzArt’s unusual level of communication provides us with a rare insight in what a company has to go through when they’re recovering from a ransomware attack. Their transparency will help other victims and we wish them luck on a speedy recovery.

Although rare, there are other organizations that have gone public with the details of what it takes to recover from a ransomware attack.

In the latest episode of the Lock and Code podcast, host David Ruiz speaks to Ski Kacoroski—a system administrator with the Northshore School District in Washington state—about the immediate reaction, the planned response, and the long road to recovery from a ransomware attack. You can listen to it below, or on Apple PodcastsSpotify, and Google Podcasts.

This video cannot be displayed because your Functional Cookies are currently disabled.

To enable them, please visit our privacy policy and search for the Cookies section. Select “Click Here” to open the Privacy Preference Center and select “Functional Cookies” in the menu. You can switch the tab back to “Active” or disable by moving the tab to “Inactive.” Click “Save Settings.”

The post 3 things the Kaseya attack can teach us about ransomware recovery appeared first on Malwarebytes Labs.