IT NEWS

Four Attorneys General (AG) from the District of Columbia and the states of Indiana, Texas, and Washington have filed separate lawsuits agains Google for allegedly misleading its users into believing that they are no longer tracking their location when they deliberately pause the “Location History” setting on mobile devices.

All four AG’s allege that users are still being tracked by Google without them knowing unless they also turn off the settings in the Web & App Activity section, too. The deception, they say, happened between 2014 and 2019.

What moved AGs to go after Google

These allegations were based on an exclusive Associate Press report back in 2018 where it was revealed that many Google services on both Android and iPhone devices can store location data even when users set their devices not to. The AP proved this by conducting its own investigation and had its findings confirmed by Princeton computer science researchers.

Google has been upfront, for the most part, about asking permission to use one’s location information, according to the report. However, it’s seen as deceptive that Google explicitly mentions in its own support page that places that the user has been are no longer stored once they turn off Location History, but still somehow tracks users via other apps (e.g. weather apps) without their consent.

The article also mentions that using Google Search on a phone’s browser, something that shouldn’t really rely on a user’s location data, can accurately pinpoint one’s precise latitude and longitude and save it to their Google account.

“If you’re going to allow users to turn off something called ‘Location History,’ then all the places where you maintain location history should be turned off,” Jonathan Mayer, a computer scientist from Princeton, had been quoted saying. “This seems like a pretty straightforward position to have.”

A Yale Privacy Lab researcher, Sean O’Brien, was also referenced saying it is “disingenuous” for the seach giant to continue to record locations even when users disable Location History.

According to the suit, Google employees expressed surprise upon learning that their company is still collecting data via the Web & App Activity setting.

Homing in on dark patterns

The four lawsuits focused on how Google relies on dark patterns, which is defined as subtle cues or tactics that urges one to make choices that might be to their detriment.

You can listen more about dark patterns in our S02E09 Lock & Code podcast episode entitled
“Shining a light on dark patterns with Carey Parker”

One example, with regard to this case, is the repeated prompting to enable location in certain apps while simultaneously claiming that the app won’t function the way it’s intended to if location is not enabled.

“Google also uses dark patterns in ‘in-product’ prompts to enable Google Account settings—i.e., prompts to enable these settings when a user begins to use Google apps and services on a device,” the report reads, “However, these products could properly function without users agreeing to constant tracking. For example, Maps and Google Now did not “need” Location History in order to perform its basic functions and, in fact, both products would continue to function if the user later took a series of actions to disable Location History.”

“Because Google’s statements falsely implied that users were not free to decline Google Account settings if they wished to use certain (often preinstalled) Google products as they were intended, users were left with effectively no choice but to enable these settings.”

The AG also criticized the way the search giant designed the set-up process of its products, which limits or takes away the user’s ability to decide on whether they consent to Google tracking them or not as they use these products.

“Google falsely led consumers to believe that changing their account and device settings would allow customers to protect their privacy and control what personal data the company could access,” said Attorney General Karl Racine of the District of Columbia in a statement. “The truth is that contrary to Google’s representations it continues to systematically surveil customers and profit from customer data.”

Speaking on behalf of Google, José Castañeda said in an email statement: “The Attorneys General are bringing a case based on inaccurate claims and outdated assertions about our settings.”

“We have always built privacy features into our products and provided robust controls for location data. We will vigorously defend ourselves and set the record straight.”

A similar past lawsuit won the day

This isn’t the first time Google received a lawsuit regarding location tracking. In 2020, Attorney General Mark Brnovich of Arizona filed a similar lawsuit to stop Google from continuously tracking its consumers in the state, in spite of them disabling location tracking, so they can be targeted with ads.

A state judge has recently given the suit the green light to move towards trial.

“Great win for Arizona consumers today,” Brnovich said in a statement, “For too long, the company has used deceptive and unfair practices to allegedly obtain users’ location data to help fund its lucrative advertising business. We will not stand by as Big Tech continues to invade Arizonans’ personal privacy.”

The post Google sued over deceptive location tracking appeared first on Malwarebytes Labs.

The American Innovation and Choice Online Act (AICOA), a bill that forbids Big Tech platforms like Apple, Alphabet (Google’s parent company), and Amazon from generally behaving in an anti-competitive manner, was approved by the Senate Judiciary Committee late last week with a 16-6 vote.

US Senator Amy Klobuchar of Minnesota, a primary sponsor of the bill, called this “the first time that a major tech bill on competition has advanced to the Senate floor since the dawn of the internet.”

What is antitrust law?

Antitrust law is a set of statutes aimed at protecting consumers by ensuring that no single company or group of companies gain so much power that they can tip market prices in their favor, or warp the competitive market. In the United States, the Federal Trade Commission (FTC)—in tandem with the Bureau of Economics—is the governing agency that enforces antitrust laws.

Antitrust laws protect against tactics that don’t promote innovation and competition. Countries all over the world have their own version of these laws, such as the Competition and Consumer Act 2010 (CCA) (Australia), the Brazilian Antitrust Law [PDF] (Brazil), the Anti-Monopoly Law of the People’s Republic of China (China), and the Antimonopoly Act (Japan).

Countries with antitrust laws enforce it their own way. The US Department of Justice (DOJ), for example, can file a civil or criminal charge against the companies or the executives heading them.

About AICOA and its possible effects

The American Innovation and Choice Act is a bill aimed at breaking up Big Tech firms and curbing their allegedly monopolistic behavior. It was first introduced by Rep. David Cicilline of Rhode Island and Rep. Ken Buck of Colorado in June 2021 along with four other bills, namely: the Platform Competition and Opportunity Act, the Ending Platform Monopolies Act, the Augmenting Compatibility and Competition by Enabling Service Switching (ACCESS) Act, (which we wrote about previously) and the Merger Filing Fee Modernization Act.

“Right now, unregulated tech monopolies have too much power over our economy,” Cicilline said in a press release last year. “They are in a unique position to pick winners and losers, destroy small businesses, raise prices on consumers, and put folks out of work. Our agenda will level the playing field and ensure the wealthiest, most powerful tech monopolies play by the same rules as the rest of us.”

Unfortunately, AICOA was voted out of the House Judiciary Committee.

In October 2021, three months later, Senators Klobuchar and Chuck Grassley—of Iowa—introduced a similar bill that shares the same name and broad features of Cicilline’s bill. This, eventually, resurrected AICOA from the grave.

This bill prohibits companies—which fit in a criteria that would be set out by the FTC pertaining (but perhaps not limited) to active userbase and market cap—from discriminating against other businesses that rely on their platform by favoring their own products and services.

If the Senate passes the bill, it would make it illegal for companies with their own marketplace, such as Amazon, Apple, and Google, from favouring their own products and services over other competitors. Amazon, for example, would be barred from ranking its AmazonBasics brand higher than other brands in search results on the Amazon market.

But AICOA’s implications could go beyond this, as many have pointed out on Twitter:

With the American Innovation and Choice Act passing a Senate committee vote and making its way to the full Senate, in spite of its many, many criticisms, you can expect the fiery debate to go on from both sides. Note, however, that the current administration has yet to take a stance on this matter.

The post Senate Committee passes new antitrust bill aimed at Big Tech companies appeared first on Malwarebytes Labs.

This blog post was authored by Roberto Santos

KONNI is a Remote Administration Tool that has being used for at least 8 years. The North Korean threat actor that is using this piece of malware has being identified under the Kimsuky umbrella. This group has been very busy, attacking political institutions located in Russia and South Korea. The last known attack where KONNI Rat was used was described here.

We found that KONNI Rat is being actively developed, and new samples are now including significant updates. In this blog post, we will cover some of the major changes and explain why the security community should keep a close eye on it.

Simplified Attack Chain

The attack usually starts leveraging a malicious Office document. When this document is opened by the victim, a multistage attack is started, involving various steps. But these steps are just the way that the attackers manage to accomplish tasks to elevate privileges, evade detection and deploy required files. As we described in a previous blog post, the attack chain could be summarized in the following diagram:

The attack usually starts leveraging a malicious Office document. When this document is opened by the victim, a multistage attack is started, involving various steps. But these steps are just the way that the attackers manage to accomplish tasks to elevate privileges, evade detection and deploy required files.

The final goal of the attack is installing what is called KONNI Rat, which is a .dll file supported by an .ini file. In a nutshell, the .dll file contains the functionality of the RAT, and the .ini file contains the address of the first C&C server. KONNI Rat’s general behavior remains almost the same as previous versions, but there are changes we will cover below.

Rundll no longer supported

In previous KONNI Rat samples there were two branches. One handles if the malware was launched using a Windows service, and the other handles the execution through rundll. The next image shows these two old branches, with the strings svchost.exe and rundll32.exe visible:

However, new samples will not show these strings. In fact, rundll is no longer a valid way to execute the sample. Instead, when an execution attempt occurs using rundll, an exception is thrown in the early stages.

In early stages of our analysis, we thought that they were using the classic process name check, or any other usual technique. The reality is far simpler and brilliant; the actual export just implements the SvcMain prototype so the program will break at some point when accessing one of the arguments.

In the previous image we see the state of the machine at the moment that this exception is thrown. RDI at that point should contain a pointer to the service name. The exception happens because the Service Main function meets one prototype and rundll32 will expect another different prototype:

VOID WINAPI SvcMain( DWORD dwArgc, LPTSTR *lpszArgv )

VOID WINAPI runnableExport(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow)

Basically, at some point of the execution, hinst will be treated as lspzArgv, causing the exception. But why did the attackers delete that functionality? There are multiple benefits.

First of all, we have not seen any recent attack that used rundll. In fact, the only way that the attackers launched KONNI Rat in recent campaigns involves registering a Windows service. So the rundll32 branch wasn’t being used in real world attacks.

But there is another big reason in how sandboxes will fail in collecting the real behavior of the sample, as it just cannot execute that way.

Strings are now protected using AES

Multiple malware families protect their strings in order to defeat most basic string analysis. KONNI wasn’t an exception, and also used this technique. Old samples were using base64 for obfuscation means. Also, they were using a custom alphabet. This custom alphabet was changed from time to time in order to make the decoding task more difficult:

Now, the attackers made a major change in that regard by protecting the strings using AES encryption. The algorithm followed by new Konni RAT samples could be represented as follows:

The reason behind that change is clear. As the key used for decryption is the service name, samples run by different service names will not work properly. Moreover, having only the sample without knowing the service name becomes useless, as these strings contain core information about the sample behavior.

Files are also protected using AES

KONNI Rat makes use of various support files when it is executed. One of these files is the .ini file, which contains the primary C&C server, but there are others like the .dat file that is supposed to be dropped eventually, and temporal files that are used to send some basic information about the computer.

Our tests reveal that all of these files are dropped and protected using AES. Cleverly, they reused the algorithm used for string protection, making the file layout identical to the protected strings layout, as they appear in raw memory:

As can be seen from the diagram, the file itself contains the IV and the encrypted data. The key used is extracted from its original filename. In some cases, the names match with the service name, so the keys used in the .ini and the .dat files are the result of applying a SHA256 to the service name as well.

Also, files sent to the C&C server are protected using AES. The IV is generated using a QueryPerformanceCounter API CALL. Filenames are generated concatenating 2 letters that represent the data with the current timestamp, followed by the extension. Furthermore, they will use this newly generated name as AES key, so they send this name through the request to the C&C server.

In that regard, as the filename is generated automatically using the timestamp, identical files will produce different request contents, as they were encrypted using that filename. Network signatures could also fail to detect the malicious activity, due to that.

Other obfuscation techniques

As we found some samples that were protected just by the means that we described before, we also have found others that were making use of an unidentified packer. We would like to share some of our notes regarding that packer, as others could find it useful in identification and attribution tasks.

Contiguous instruction obfuscation

The flow of the obfuscated program will make use of series of push-call pairs of instructions, where the pushed values will indicate the actions that the program will take. An image can better explain that:

In particular, we find it interesting that the attackers have placed random bytes between these pairs. This silly trick causes wrong code interpretation for decompilers that will assume that bytes after the push instruction are part of the next instruction. The image below shows how IDA fails in analyzing the code:

Obfuscated program flow

The used packer will obfuscate the original program flow. This is accomplished in various steps. The first required step is to find the Image Base value, placed in a fixed location and the RIP (Instruction Pointer) value.

Once the packer knows these two values, it will start jumping from one place to another, making analysis harder. For that, it will store in some register value of the next address to jump in registers. The value of these registers is calculated right after the jmp instruction, using structures like POP [reg] – JMP [reg] or ADD [reg1, reg2] – JMP [reg1]. Note that decompilers will fail in displaying the real flow, as the jumping address is determined by a somehow undefined register.

The combination of these simple techniques ends in the packer being now in control of the flow, but statically the decompiler cannot represent the path that the code will follow. Finally, the packer will execute a big amount of junk instructions and eventually will execute the real interesting code. For instance, the original code will take no more than 20 instructions between GetProcAddress calls in IAT building tasks. but the packed code executes more than 30,000 instructions.

According to our threat intel data, most recent attacks are not making use of that packer anymore.

Conclusion

As we have seen, KONNI Rat is far from being abandoned. The authors are constantly making code improvements. In our point of view, their efforts are aimed at breaking the typical flow recorded by sandboxes and making detection harder, especially via regular signatures as critical parts of the executable are now encrypted.

Malwarebytes users are protected against this attack.

IOCs

A3CD08AFD7317D1619FBA83C109F268B4B60429B4EB7C97FC274F92FF4FE17A2
F702DFDDBC5B4F1D5A5A9DB0A2C013900D30515E69A09420A7C3F6EAAC901B12

The post KONNI evolves into stealthier RAT appeared first on Malwarebytes Labs.

Microsoft has published a list of 25 group policies that administrators should not use in Windows 10 and Windows 11 as they do not provide optimal behavior or cause unexpected results.

Since November 2015 when Windows 10 was first introduced, there have been many changes and some of them have caused Windows Update policies to interfere with performance, while others have been replaced with different versions.

Microsoft has identified which older policies have become irrelevant or replaced with a better option. The policies in this article are all more or less tied to Windows updates. Notifications, the ability to dictate the behavior of update downloads, installation, and restarts, and the settings experience have all shifted dramatically from what was originally released in the early Windows 10 versions.

This posting from Microsoft helps bring clarity to many years of frustration experienced by IT admins and Windows enthusiasts that wanted or needed to control the Windows Update experience.

As Alex Smith, Technical Product Manager at Malwarebytes, puts it:

“I am happy to see Microsoft finally clear the air on Group Policies for Windows Update. IT admins and Windows enthusiasts like myself have been frustrated trying to control the Windows Update experience on managed devices for years. At times, we questioned our technical sanity since the results wouldn’t align with the group policies being used. Now, that will be a thing of the past.”

Group policies

Administrators can work with Group Policy Objects (GPO) to customize a computer’s functions and the user experience. Designed to be used mostly by network administrators, group policies define what specific users or a group of users can do on machines in their network, restricting or allowing features as necessary.

Where can I find the policies?

To change the Group Policies’ settings you will typically use the Group Policy Editor. The Group Policy Editor is a utility that allows you to configure Group Policy settings for a Windows PC or a group of PCs. Note that this is only available for Windows Pro versions.

Probably the easiest way to open the Group Policy Editor is by using search in the Start menu. First, click the Start button, and when it pops up, type gpedit and hit Enter when you see an entry called Edit Group Policy in the list of results.

Windows 11

To make life easier for Windows 11 users, Microsoft created a sub-folder under Windows Update to specify Legacy Policies. Please note that these sub-folders are only available in the Windows 11 ADMX templates. ADMX files are XML‑based administrative template files, that are language‑neutral and support multilingual display of policy settings. Microsoft Windows manages ADMX files from the central store that is a central location in the domain.

While admins need to select an OS-specific set of ADMX files for the central store, Microsoft has provided a method that admins can use to manage the policies for the other operating systems in their environment.

Deprecated policies

You can find the complete list of deprecated policies and suggested replacements in Microsoft‘s article. This list shows which policies are not recommended, why they are not recommended, and how to get the same or similar behavior with either default settings or recommended policies. This list can really help Windows administrators to review their existing group policy configurations and replace outdated policies with newer variants that provide more control and expected behavior.

A quick overview was provided in a tweet by Aria Carley (@ariaupdated) who wrote the article.

The post Windows Update has changed over the years. Here are 25 group policies to avoid appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs:

• CISA calls for urgent action against critical threats
• Red Cross begs attackers to “Do the right thing” after family reunion service compromised
• Update now! Chrome patches critical RCE vulnerability in Safe Browsing
• Combatting SMS and phone fraud: UK government issues guidance
• Open Subtitles breach: The dangers of password reuse
• Steer clear of gift card balance scams
• Browsers on iOS, iPadOS and Mac leak your browsing activity and personal identifiers
• Mac users, update now! “Powerdir” flaw could allow attackers to spy on you
• Campaign launched to delay social media end-to-end encryption
• Cybercriminals’ friend VPNLab.net shut down by law enforcement
• Why we don’t patch, with Jess Dodson: Lock and Code S03E02
• Nintendo warns of imitation websites and suspicious hardware
• Infamous dark net carding site UniCC to close
• REvil ransomware gang busted by Russian Federal Security Service

Stay safe!

The post A week in security (January 17 – 23) appeared first on Malwarebytes Labs.

Back in October 2021, Microsoft announced in an email to customers that it planned to disable Excel 4.0 macros by default to protect customers from malicious documents.

Last week—after three decades of macro viruses, and three decades of trying to convince every single Excel user individually to disable macros—Microsoft made the change.

Good news

Excel 4.0 macros, aka XLM macros, were first added to Excel in 1992. They allowed users to add commands into spreadsheet cells that were then executed to perform a task. Unfortunately, we soon learned that (like any code) macros could be made to perform malicious tasks. Office documents have been a favorite hiding place of malicious code ever since.

In July 2021, Microsoft released a new Excel Trust Center setting option to restrict the usage of Excel 4.0 (XLM) macros. As planned, this setting is now the default when opening Excel 4.0 (XLM) macros.

Administrators also have the option to completely block all XLM macro usage (including in new user-created files) by enabling the Group Policy, “Prevent Excel from running XLM macros”, which is configurable via Group Policy Editor or registry key.

Backward compatibility

For backward compatibility reasons the feature was never removed, despite being superseded by Visual Basic for Applications (VBA) just one year after XLM macros were introduced.

I understand the argument in favor of keeping it back then, but why keep it enabled by default for so long after, when so few people use it? Microsoft could have made it so that those that needed Excel 4.0 macros had to turn the feature on, and the rest of us (the overwhelming majority of Excel users) could have been more secure without having to remember to turn it off.

Will you miss it?

It is very, very unlikely you will miss Excel 4.0 macros. XLM was the default macro language for Excel through Excel 4.0, but beginning with version 5.0, Excel recorded macros in VBA by default, although XLM recording was still allowed as an option. After version 5.0 that option was discontinued. All versions of Excel are capable of running XLM macros, though Microsoft discourages their use.

Now—almost 30 years after they were made obsolete—it’s fair to stay that the biggest users of Excel 4.0 macros are probably malicious threat actors.

Abuse cases

Attackers have always liked Office macros because they provide a simple and reliable method to spread malware using legitimate features, and without relying on any vulnerability or exploit. XLM macros have been used to drop many well-known malware families, including ZLoader, TrickBot, BitRat, QBot, Dridex, FormBook and StrRat, among others.

But this does not mean that now all documents are safe to open now. Malware authors are moving on to use other vulnerabilities like CVE-2017-11882.

Security over backward compatibility

Despite the shared joy about this security enhancing rollout, it raises the question of when security should overrule backward compatibility? Microsoft must have better things to do than fix obsolete features from the past century.

Wouldn’t it have been preferable if the step up to VBA in 1993 had been less steep, so we could all forget about 4.0 and move on to the latest version without having to look over our shoulder? Or perhaps Microsoft could have disabled this potentially dangerous feature decades ago and left it to those who actually wanted it to turn it back on?

If history has taught us anything, it’s that the incentive to enable something you need is a lot stronger than the incentive to disable something that might be potentially dangerous.

Stay safe, everyone!

The post Microsoft is now disabling Excel 4.0 macros by default appeared first on Malwarebytes Labs.

Avid readers of the Malwarebytes Labs blog will be well aware of QR code scams.

Take, for example, that QR code scam in the Netherlands that victimized at least a dozen (and definitely more) car owners. It went like this: Someone approaches you and says they want to pay for their parking but can’t find payment terminals that accept cash. They then ask you to kindly pay on their behalf—say, $5 USD—by scanning a QR code with their bank’s app after they hand you the money. Sadly, that ends up with you parting with a lot more than $5.

And then last week, the Austin Police Department in Texas released a scam alert on Twitter about “pay-to-park” scams involving a QR code that directs users to a phish.

Now, the FBI has released a public service announcement (PSA) about criminals using malicious QR codes.

Be extra vigilant when faced with a QR code

QR codes provide contactless access to a product or service, and they’ve proven useful and very convenient especially with the pandemic still ongoing. The problem is that there’s no way of distinguishing between a genuine code and a malicious one. Cybercriminals know this too and have capitalized on it.

“Cybercriminals tamper with both digital and physical QR codes to replace legitimate codes with malicious codes,” notes the FBI alert. “A victim scans what they think to be a legitimate code but the tampered code directs victims to a malicious site, which prompts them to enter login and financial information. Access to this victim information gives the cybercriminal the ability to potentially steal funds through victim accounts.”

QR codes can also be embedded with malware. Once scanned, the malware can be dropped onto the device and executed. Depending on the malware, criminals could steal personal and financial information (if you bank using your smartphone) from you, make your device part of a botnet, or spy on you.

Criminals can also replace legitimate QR codes in establishments to mislead users and direct them to a potentially malicious site. In certain cases where a contactless way of paying is available but does not use QR codes, it would be easy for criminals to just add their QR code sticker and make users believe that they should scan it.

This is exactly what happened in the fraudulent “pay-to-park” scheme.

How to protect yourself from QR code scams

The FBI has recommended the following steps that users should keep in mind:

• Check the URL to ensure you’re being directed to a site where you’re supposed to be directed once you scan a QR code. Watch out for misspellings in the URL.
• When you see a QR code in a shop and want to scan it, make sure you check for signs of tampering, such as a sticker over the QR code itself.
• Download an app from your go-to app store, not from a QR code.
• Use the built-in scanner through your smartphone’s camera to scan for QR codes. There is no need to download another one from the app store as there are fake QR code scanners, too.
• If you receive a QR code either in the mail or sent to you by a friend, get in touch with them first and verify if they have indeed sent you the code.
• If you can, avoid making payments via a QR code. There are better and more secure ways of paying.

Stay safe!

The post Warning issued over tampered QR codes appeared first on Malwarebytes Labs.

It’s not been a great couple of weeks for people looking to get in on NFTs. Missing apes, rug-pulls, it’s all go in non-fungible token land. The latest mishap has come to light, in the shape of bad planning and the slowly shifting impermanence of link ownership.

Rockstar Ozzy Osbourne announced “CryptoBatz” just a week or so ago. Whoever put the marketing campaign together deserves some sliver of credit for self-consciously poking fun at aspects of NFT culture in the promo video.

“He started thinking, started working…locked away in his library for weeks working on something big. He teamed up with a company called Sutter Systems. Their mission was to create an NFT project that wasn’t another celebrity rug pull.”

Well, they didn’t end up with a rug pull but they did end up with an accidental phish-ball rolling unstoppably downhill. But how?

Minting some Batz

Close to 10,000 digital NFT bats were supposed to be put up for grabs on an NFT marketplace. The bats reference a rather infamous moment in Osbourne’s career, and allow the owner to “breed” them with NFT images from other collections. A bit like Pokemon on the blockchain, perhaps.

As with any NFT project looking to gain leeway with the general public, it has a Discord server. There’s a good chance pretty much any digital project has a similar setup, and this is nothing unusual. However, things started to go wrong in a hurry – and it’s all down to the CryptoBatz Discord.

Discord in Discord Land

Not long after the bats went on sale, people started to complain about phishing links from official sources. Could it be true? Had this somehow turned into an incredibly bizarre rug-pull? The answer is no. It was something much more mundane.

The CryptoBatz project had, at some point, changed at least one of the URLs it was working with. They switched out the old Discord vanity URL for a new one, but didn’t delete old tweets containing the now outdated URL. Can you guess what the scammers did?

As per the above tweet, the scammers set up a new Discord server using the old CryptoBatz vanity URL. As potential victims naturally came across tweets with the old link in it, they were then directed to the (bogus) Discord server.

From there, it’s a short step to having their cryptocurrency wallets connected to things they shouldn’t be. End result: drained wallets, lost funds, CryptoBatz everywhere.

The financial impact of a cryptocurrency phish

According to this Verge article, the scammers made off with quite a bit of bank. Transactions to the tune of around $40,000 were sent to a digital wallet containing “more than $150,000”. The team behind the project claim they’re not responsible for “scammers exploiting Discord”, though it’s hard to argue against them having simply deleted outdated links in the first place. No links, no scam able to take place.

All the same: the back and forth doesn’t really help the victims. Even a project fronted by known entities can easily wander into a bad NFT situation, an area of digital business where it’s all a bit Wild West by default.

I suppose we must now add “Always check the most up-to-date link on any social feed related to NFT sales” to the growing list of tips to avoid gracing your digital wallet with an Electric Funeral.

The post Discord scammers go CryptoBatz phishing appeared first on Malwarebytes Labs.

There’s been trouble brewing over the weekend for players of the smash-hit Dark Souls series. PvP (player vs player) servers were temporarily shut down by the developers after a hack.

Dark Souls says that PvP servers for console versions (PlayStation, Xbox) were not affected, and that it is a PC-centric issue.

What happened?

It all begins with a popular streamer playing a Souls game in PvP mode. You can view a recording of the stream here (warning: the language is not safe for work). The stream changes very unexpectedly. It switches from regular gameplay to a meme image which includes character Thanos and the words “oof my game crashed”.

On top of that, Text to Speech voice kicks in and begins a long ramble aimed at the streamer. You’ll also hear the incredibly confused streamer in the background, talking about seeing “powershell.exe” on their screen. Someone had gained control of his PC, mid-stream, to crash his game and autoplay the synthesised speech.

Dark Souls players have run into hacking related problems before, and, as a result, player-created tools like anti-cheat system Blue Sentinel are incredibly popular. Even so, it couldn’t help with this particular “attack” when it came to attention.

Spreading the word

The majority of information bouncing around the player base came from notices in relevant gaming Discord servers, like so:

Hey everyone, it’s come to our attention that a Remote Code Execution (also known as RCE) exploit has emerged for Dark Souls III on PC. This means that potentially malicious players connected to your game may be able to execute code by sending information to your game that directly affects aspects of your operating system. This can lead to sensitive information leaks, including but not limited to: installation of malicious programs such as keyloggers or viruses, theft of account information or login tokens, and access to other sensitive information such as banking info or other things that may be stored on your computer.

We’ve referenced the program Blue Sentinel, a community-made program that serves as a third-party anti-cheat in the past for issues like this; however, it has apparently been made known that RCE can bypass Blue Sentinel. For this reason, it is recommended that if you play Dark Souls III on PC, you may want to stay offline until a further development is made against this exploit. If you still really want to play online, know that there is still a risk of the aforementioned effects, and it would still be recommended to do some research into the Blue Sentinel mod to see if it can help with anti-cheat effects.

This rapid-response spread of information, along with the developers/publisher being made aware of it in public led to Sentinel being updated to ward off the RCE.

Do you need to worry about this?

Talk of remote execution is always scary. You don’t want someone potentially having the ability to do whatever they want to your system. However, the impact from this code-related shenanigan seems to have had an incredibly limited impact. That is to say, the one single streamer from the above video.

It’s claimed whoever first discovered the ability to do this tried to get the developer’s attention and disclose responsibly. It’s also claimed that they didn’t get very far. From a Reddit thread:

I’ll try and clear things up: A person who isn’t malicious discovered a new RCE method, and tried to contact From about it through multiple channels. They ignored him. In an attempt to raise awareness to it so that it would be fixed (as this is a SEVERE security flaw), he did a live benign showcase on stream. It didn’t “leak”. Nobody has it beside him.

If this is accurate, then it’s reassuring with regards to potential spread. At this point, there doesn’t appear to be any reports of it happening outside the gaming stream. Even so, someone could’ve conceivably discovered it separately. There’s also concerns upcoming title Elden Ring could be affected as it apparently shares a lot of code with the older games.

Either way, developer From Software is on the case and the issue is being addressed. More information will probably be revealed over the next few days. If you’re worried, playing offline and running Blue Sentinel is likely your best bet until the fixes are confirmed to solve the problem.

The post Dark Souls servers taken offline over hacking fears appeared first on Malwarebytes Labs.

In the early 2000’s, the Segway company released a personal transporter that would become iconic. The Segway Human Transporter was quickly sold on Amazon and featured in a number of movies.

Since 2015, Segway has been a subsidiary of Chinese-based company Ninebot and sells electric scooters under the Ninebot brand. By 2020, a number of changes in personal transportation forced the company to halt the production of its famous Segway PT.

Our web protection team recently identified a web skimmer on Segway’s online store. In this blog, we will review the attack and tie it back to a previous campaign that is attributed to Magecart Group 12. We already have informed Segway so that they can fix their site, but are publishing this blog now in order to raise awareness.

Magecart-style attack

Stefan Dasic, from our web protection team, identified a connection to a known skimmer domain (booctstrap[.]com) loaded by the Segway store. This domain has been active since November and is connected to a previously documented campaign sometimes referred to as “ant and cockroach”.

The hostname at store.segway[.]com is running Magento, the popular Content Management System (CMS) used by many e-commerce sites and also a favorite among Magecart threat actors. While we do not know how Segway’s site was compromised, an attacker will usually target a vulnerability in the CMS itself or one of its plugins.

Based on urlscanio data, the website was compromised at least since January 6th. Malwarebytes was already blocking the booctstrap[.]com domain and its hosting server at 185.130.104[.]143 since November. Looking at our telemetry, we can see that the number of blocks (attacks prevented on our customers’ machines) also goes up around the January 6th mark.

The top 5 countries exposed to this skimmer, based on our telemetry data, are:

Favicon campaign

A fairly long but innocuous piece of JavaScript disguised as ‘Copyright’ is responsible for dynamically loading the skimmer such that it will not be visible by looking at the HTML source code.

Instead, if we check the code via the browser’s debugger we can see how the URL is constructed:

The threat actors are embedding the skimmer inside a favicon.ico file. If you were to look at it, you’d not notice anything because the image is meant to be preserved. However, when you analyze the file with a hex editor, you will notice that it contains JavaScript starting with an eval function.

There is a lot that has been written about this skimmer and the threat group behind it. Sucuri’s Denis Sinegubko covered it and Jordan Herman from RiskIQ also wrote about the numerous ties it shares with a number of incidents that can attributed to Magecart Group 12.

The compromise of the Segway store is a reminder that even well-known and trusted brands can be affected by Magecart attacks. While it usually is more difficult for threat actors to breach a large website, the payoff is well worth it.

Malwarebytes customers were already protected thanks to our website shield available in Malwarebytes for Desktop as well as our Browser Guard extension.

The post Segway store compromised with Magecart skimmer appeared first on Malwarebytes Labs.