Archive for author: makoadmin

Emulators have played a part in many tech-savvy users’ lives. They introduce a level of flexibility that not only allows another system to run on top of a user’s operating system—a Windows OS running on a MacBook laptop, for example—but also allows video gamers to play games designed to work on a different platform than the one they own.

Recently, ESET revealed a campaign that targeted users of NoxPlayer, a popular Android emulator for PCs and Macs. Affected users didn’t have to visit a potentially dubious website to get malware. All they did was download the update for NoxPlayer.

What we see here is the latest example of a supply-chain attack, wherein threat actors were able to manipulate a legitimate executable file to make it behave in a way it’s not supposed to. In this case, attackers manipulated two files: Nox.exe, the main NoxPlayer file, and NoxPack.exe, the downloader of the update itself. The latter is its infection vector.

How users can get infected

Everything starts and happens at the backend where users cannot see what is really going on.

In the post, ESET explains that upon opening NoxPlayer—and before a message pops up telling users that a software update is available for download—the program queries the update server via the BigNox HTTP API to check for updates and if so, retrieves update-related information. This includes the URL where the update file is housed.

The researchers believe that certain sections of the BigNox infrastructure were compromised. It’s thought that either the attackers replaced the legitimate update file with malware, or changed the file name or download URL to point to a destination they controlled. These new download URLs mimicked the legitimate download location of the NoxPlayer update.

Malware was then executed on affected systems. Reconnaissance is pinned as the main purpose of this yet unknown malware. The researchers also observed that throughout the end of 2020 and the start of 2021, certain victims were infected with other malware.

Signs of the times

The video gaming industry isn’t exempted from any cyberattack and online risks. For years, companies within the industry have been targeted by phishing, scammers, and sometimes, malware.

Early this year, employees (and sometimes clients) of big-name gaming companies like Ubisoft had their credentials leaked on the dark web. In mid-2020, PipeMon, the product of an attacker group called Winnti, who is also known to use supply-chain attacks, infected several massive multiplayer online (MMO) game developers to use game builds and game servers for their malicious purpose.

Because the current pandemic has fueled the popularity of vide gaming, including how much people spend within these games, it shouldn’t surprise anyone that cybercriminals are homing in on them now more than ever. This particular attack on a gaming emulator company may seem unusual, but it aligns with the current trend.

While video gamers are enjoying their games, they should realize that they have caught the attention of cybercriminals. Similarly, video game companies should understand they are targets too. To keep the cybercriminals at bay, both will need to do their part.

The post Android emulator abused to introduce malware onto PCs appeared first on Malwarebytes Labs.

Late last December we started getting a distress call from our forum patrons. Patrons were experiencing ads that were opening via their default browser out of nowhere. The odd part is none of them had recently installed any apps, and the apps they had installed came from the Google Play store. Then one patron, who goes by username Anon00, discovered that it was coming from a long-time installed app, Barcode Scanner. An app that has 10,000,000+ installs from Google Play! We quickly added the detection, and Google quickly removed the app from its store.

Simple scanner turns evil

Many of the patrons had the app installed on their mobile devices for long periods of time (one user had it installed for several years). Then all of sudden, after an update in December, Barcode Scanner had gone from an innocent scanner to full on malware! Although Google has already pulled this app, we predict from a cached Google Play webpage that the update occurred on December 4^th, 2020.

Malicious intent

The majority of free apps on Google Play include some kind of in-app advertizing. They do this by including an ad SDK to the code of the app. Usually at the end of the app’s development. Paid-for versions simply do not have this SDK included.

Ad SDKs can come from various third-party companies and provide a source of revenue for the app developer. It’s a win-win situation for everyone. Users get a free app, while the app developers and the ad SDK developers get paid.

But every once in a while, an ad SDK company can change something on their end and ads can start getting a bit aggressive. Sometimes even landing the apps that use it in the Adware category. When this happens, it is not the app developers’ doing, but the SDK company. I explain this method to say that in the case of Barcode Scanner, this was not the case.

No, in the case of Barcode Scanner, malicious code had been added that was not in previous versions of the app. Furthermore, the added code used heavy obfuscation to avoid detection. To verify this is from the same app developer, we confirmed it had been signed by the same digital certificate as previous clean versions. Because of its malign intent, we jumped past our original detection category of Adware straight to Trojan, with the detection of Android/Trojan.HiddenAds.AdQR.

Bad behavior

The toughest part of malware analysis can be replicating what our users are experiencing. That wasn’t a problem with Barcode Scanner, it went into action within minutes of install. Watch the short video below to see its malicious behavior:

Removed from Play, but not from mobile device

Removing an app from the Google Play store does not necessarily mean it will be removed from affected mobile devices. Unless Google Play Protect removes it after the fact, it remains on the device. This is exactly what users are experiencing with Barcode Scanner. Thus, until they install a malware scanner like Malwarebytes for Android, or manually remove the app, it will continue to display ads.

Lying dormant

It is hard to tell just how long Barcode Scanner had been in the Google Play store as a legitimate app before it became malicious. Based on the high number of installs and user feedback, we suspect it had been there for years. It is frightening that with one update an app can turn malicious while going under the radar of Google Play Protect. It is baffling to me that an app developer with a popular app would turn it into malware. Was this the scheme all along, to have an app lie dormant, waiting to strike after it reaches popularity? I guess we will never know.

App Information

App Name: Barcode Scanner

MD5: A922F91BAF324FA07B3C40846EBBFE30

Package Name: com.qrcodescanner.barcodescanner

The post Barcode Scanner app on Google Play infects 10 million users with one update appeared first on Malwarebytes Labs.

A Chrome patch has been issued with an advisory stating that the Stable channel has been updated to 88.0.4324.150 for Windows, Mac and Linux. The only noteworthy thing about this update is a patch for a zero-day vulnerability that has been actively exploited in the wild. But that one looks to be extremely important.

Which zero-day got patched?

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). This zero-day got listed as CVE-2021-21148. From the update announcement for this Chrome patch we can learn that the patch counters a heap buffer overflow in the V8 JavaScript engine, reported by Mattias Buelens on January 24, 2021.

What is a heap buffer overflow?

Heap is the name for a region of a process’ memory which is used to store dynamic variables. A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches its address boundary and writes into an adjacent memory region. In software exploit code, two common areas that are targeted for overflows are the stack and the heap.

So, by creating a specially crafted input, attackers could use this vulnerability to write code into a memory location where they normally wouldn’t have access. Having this attack vector available as a zero-day in a popular browser is a golden opportunity for a watering hole.

Watering holes are used as a targeted attack strategy. The attackers infect a website where they know their intended victim(s) will visit, or lure them to a site of their own making. Depending on the nature of the infection, the attackers can single out their intended target(s) or just infect anyone that visits the site unprotected. The watering hole strategy is a mix of social engineering, hacking, and drive-by infections that requires a high level of knowledge and a well-thought-out strategy.

How was this vulnerability used in the wild?

Based on the timing of the discovery (January 24) and this report by Google’s Threat Analysis Group (TAG) issued on January 26, the general assumption is that the attack was used against security researchers working on vulnerability research and development at different companies and organizations. To connect and gain trust among security researchers, the actors created a research blog and multiple Twitter profiles to interact with potential targets.

One of the methods the attackers used was to interact with the researchers and get them to follow a link on Twitter to a write-up hosted on a malicious website. Shortly after the visit, a malicious service was installed on the researcher’s system and an in-memory backdoor would begin to communicate with a command and control (C&C) server. This sure sounds like something that could be accomplished using a heap buffer overflow in a browser.

The update

Despite its discovery, this exploit remains useful to cybercriminals. We advise everyone to update and get the latest version of Chrome as soon as possible.

The easiest way to do it is to allow Chrome to update automatically, which basically uses the same method as outlined below but does not require your attention. But you can end up lagging behind if you never close the browser or if something goes wrong, such as an extension stopping you from updating the browser.

So, it doesn’t hurt to check now and then. And now would be a good time, given the zero-day vulnerability. My preferred method is to have Chrome open the page chrome://settings/help which you can also find by clicking Settings > About Chrome.

If there is an update available, Chrome will notify you and start downloading it. Then it will tell you all you have to do to complete the update is Relaunch the browser.

Stay safe, everyone!

The post Update now! Chrome patches zero-day that was exploited in the wild appeared first on Malwarebytes Labs.

Modern browsers include synchronization features (like Google Chrome’s Sync) so that all your browsers, on all your devices, share the same tabs, passwords, plugins, and other features. While this is certainly convenient, particularly when you’re migrating to a new device, synchronizing browsers also comes with some risks.

What is browser sync?

Browser syncing was introduced in 2012 by Chrome with the goal of letting you continue at home where you left off at work, and vice versa. Since then, other browsers have introduced similar features. There are slight differences between them when it comes what you can synchronize, but the basics are pretty much the same for most of them.

When Chrome Sync is toggled on, the synchronised information includes bookmarks, passwords, history, open tabs, settings, preferences, and, in some cases, even payment information saved in Google Pay.

Firefox lets you synchronize your data and preferences—such as your bookmarks, history, passwords, open tabs, and installed add-ons—across all your devices.

Microsoft Edge can synchronize your favorites, passwords, and other browser data—including payment information—across all your signed-in devices.

Opera lets users synchronize their bookmarks, settings, and open tabs between mobile and desktop browsers. Earlier, Opera required users to create an account and sign in on both platforms, or use the more limited “Opera Touch” app in order to do so. After users install the latest Android and desktop updates, however, they can synchronize all that data across devices within the core apps using a QR code, no need for an account.

Sharing with strangers

Synchronized data can include browser history, bookmarks, passwords, cookies, and other information that users consider private and typically have no intention of sharing with anyone else. Password, cookie and payment card secrecy is also important for security. Browser synchronization increases the risk of you inadvertently sharing that information with other users of the computers you sync between.

It’s important to consider whether you are truly the only user of a system that is set to synchronize. Imagine what can happen if your kids are playing with your home laptop and it synchronizes to your work system.

You should also consider the risk of your device being lost or stolen but continuing to sync your information to the thief (as if there wasn’t enough stress involved in losing a device.)

Another thing to consider before synchronizing is that having a universal ID for all your systems can lead a hacker from one of your systems to all of them!

Spreading danger

Security threats can also be copied from one device to another, in the form of malicious extensions (also called plugins or add-ons), and open tabs.

Malware in the form of browser extensions is relatively rare, but it does happen. We have seen infected JavaScript-based extensions with malicious code that made it possible to introduce malware to an affected system.

Google regularly has to clear out bad extensions from its Chrome Web Store. While many of those extensions would fall into the categories of Potentially Unwanted Programs (PUPs) or adware, they can still cause problems and many would be frowned upon if you introduced them into your work environment by synchronizing from your home browser.

Open tabs are potentially even more risky. While most browsers have built-in methods to get out of browlocks, copying them to another device is undesirable.

Differences in patching and security software between machines can also create opportunities for threats to thrive. While a malicious website might be harmless on your personal device, because of local protection, it might seize the opportunity if the tab it’s in is synchronized to a work device that relies on different security measures.

Cloud privacy issues

Another reason why some people dislike the idea of synchronizing browsers is because the synchronized data isn’t just shared between devices, it’s also stored in the cloud, under the control of the browser vendor.

Not all browsers are the same here. The popular Firefox browser encrypts your data locally—with a cryptographically secure, randomly generated key—before storing it in the cloud, so it can’t read your information. Chrome users who want similar protection must set a passphrase.

People who just don’t like that idea of sharing their information with browser vendors, even if it’s encrypted, can use specialized software that promises to synchronize your browser data in a more secure way.

Chrome disables sync API for third-parties

Recently a story that is sideways related hit the news. Google issued a statement saying that it will block third-party Chromium web browsers from using private Google APIs that were only intended for Chome. (Chromium is an open source project run by Google that provides most of the code for Google Chrome, and forms the basis of other popular browsers like Microsoft Edge and Brave.)

Google Chrome Engineering Director Jochen Eisinger stated:

“During a recent audit, we discovered that some third-party Chromium-based browsers were able to integrate Google features, such as Chrome sync and Click to Call, that are only intended for Google’s use.”

Google will limit 3rd party Chromium browsers from accessing private Chrome APIs starting March 15, 2021. However, Google says that users who have accessed private Google features such as Chrome Sync while using third-party browsers will still be able to access the synchronized data locally or in their Google account, depending on their settings. And if you should decide to look into the third-party alternatives we talked about earlier, you will find that some of these will provide you with options to synchronize other Chromium browsers.

An informed decision

An informed decision is all we can hope to offer you. Before you decide it’s safe to synchronize your browser data, these are the questions we would like you to ask:

• Is the owner of the two devices the same? If this is not the case, it wouldn’t hurt to ask for permission first.
• Is the main user of the two devices the same person? If not, synchronizing could leak data, or be considered spying on someone.
• Do you trust the provider of the synchronization service and its cloud facility to handle your data with care?
• What are the chances of carrying over malicious content from one device to another? Are both devices equally well protected?

Asking these questions will remind you of what could go wrong and help you decide whether it is worth it.

Stay safe, everyone!

The post Browser sync—what are the risks of turning it on? appeared first on Malwarebytes Labs.

“Use real identities to reduce abuse online” is a talking point you’ve almost certainly seen down the years. It also seems to come around like clockwork every other month, and is currently a hot topic in the UK after prominent journalists / media personalities raised the issue.

It’s an interesting idea, but the devil is in the details. “Verified identities solve the problem” won’t address the new problems such an approach creates. Is it possible to make this work, or is it all just pie in the sky?

Real users still behave badly

Think back to some of the worst arguments you’ve seen on social media. They almost certainly involve verified accounts somewhere in the mix. Often they initiate the aggression, or wade into replies and make it worse.

They may also utilise platform features to spread the argument further afield. Accounts with large followings on Twitter will do this via quote tweeting. They may simply retweet a stance they disagree with to initiate a so-called “pile on“, or retweet other people arguing, or quote tweet adding their own commentary along the way. They may even retweet their own replies.

Once this happens, it’s often game over for the other person whose notifications are essentially ruined with a flood of angry responses. I could be wrong, but I don’t believe I’ve ever seen a verified account banned for causing a pile on. I have, however, seen small accounts targeted by such things delete their profile completely. On balance, this doesn’t seem particularly fair.

Realness doesn’t equate to accuracy

Going back to Twitter, this is somewhat a problem of their own making. Whether an accurate assumption or not, the verified system was originally where you assumed all the celebrities you liked ended up. Twitter expanded it to include other people of note, for example authors, athletes, scientists, and so on. Then lots of folks were handed verification simply for working in news / media orgs. Alongside this, for a period of time you could submit a request to be verified and if you passed the bar, you got your checkmark.

Already, you can see how the system was torn between notions of “Is this a badge of notability, identity, or something else altogether?” Things became even more confusing as for a few years, the Twitter verification information page insisted verification was not currently happening…while new checkmarks continued to be given out.

The scheme is currently undergoing renovation, but it remains to be seen what happens with it.

Whether intentional or not, people seem to trust verified accounts as trustworthy voices of reason. This is not sensible, as people will tweet whatever they feel like. If we’re asking, “Does verification help reduce abuse or misinformation”, it can be argued that no, it does not. A drop of 73% in election misinformation after Twitter suspended Donald Trump is a frankly staggering statistic.

This alone should be a fatal blow to the “Use a real identity and things will magically be better somehow” idea.

Facebook’s foray into real names

Facebook already requires you to register an account with your legal name. The problem is if they think your name is not real, you’re locked out and have to try and regain access. This has had very mixed results, causing problems over everything from “fake” names to Star Wars.

Consider all the effort involved in policing this, and the hassle for site users, and then compare that with the number of accounts who are happily pushing large-scale propaganda campaigns via fake profiles on Facebook anyway.

Is it really worth all that effort? Is it helping?

Access denied

If we want everyone online with a real ID, there’s many privacy issues up for debate if identity documents are involved. There’s also the massive problem of access. The international gold-standard for ID is your passport. Many verification schemes ask for scans of your passport at some point.

Problem: lots of people don’t have passports, because it’s not a mandatory document. Depending on country, it might be very expensive. It could involve a complicated process or have its own barriers to entry. Live in a different country to the one you were born in? You may only have a residence permit. It’s possible your passport has expired. Will they even accept an expired passport?

In 2018, around 76% of people had a passport in the UK. That compares with 42% of Americans and 66% of Canadians. That leaves an awful lot of people out of the loop across just 3 locations. This is before you factor the rest of the world in.

Unless passports are somehow made free worldwide, or a universal form of ID is created, people will lose out. When crucial services like banking, tax, municipal services, gas and electricity are all moved online, this seems irresponsible. We typically don’t need to show our energy company a scan of our passport to use their service online. Does it make sense that the bar to entry is so much higher to post on a social network?

There are limited circumstances where a social network currently may ask to see a form of identification. That’s mostly tied to issues of death and memorialisation. Similarly, some verification processes involve passport scans.

Scanning everybody, though? That’s going to cause additional problems…

All the eggs, in the biggest basket

Any social media app containing something approaching the whole world’s passports is instantly a massive target for hacks and scams. It’s debatable if they could keep it all secure and locked down—they only have to fail once. For comparison, the UK’s Home Office deals with a frankly unimaginable volume of personal data. Passports, birth certificates, wedding certificates, photographs, personal emails, biometrics, the works. Some of this is outsourced to third parties.

It is incredibly important this data is kept under lock and key. This is now the point where we mention a 120% rise in data loss incidents. With 4,204 incidents “in the last financial year” alone, that’s an awful lot of problems related to paper documents and electronic devices. If this is the scale of the issue for UKGOV despite their best efforts, imagine the problem for a much less wealthy social media site. It just seems too much of a leap of faith to think this would end in anything but disaster.

This leads us neatly on to…

Data theft fallout

When people say that losing their anonymity online “isn’t a problem”, or “wouldn’t bug me”, that’s great for them. But just because something isn’t in their threat model, doesn’t mean it can’t hurt someone else, as the EFF’s Eva Galperin pointed out on Twitter only recently:

Some people are at risk from domestic violence or racial abuse. For some, anonymity is built into aspects of their job. For others, their stay in a country might be. conditional but they’d like to speak up on the issues affecting them without feeling they’re jeopardising their status.

“You’re not living in a repressive regime” should not be the barrier to entry for privacy. Treating your right to keep yourself safe from data abuse isn’t a special exemption, kept out of reach except in the direst of emergencies. This normalises the idea of privacy and safety as an exception. You know who loves it when privacy and safety are treated as abnormal?

People who’d rather you have as little of it as possible, that’s who.

Same again next time?

I’ve seen this discussion come around many, many times now. No matter the circumstance, it tends to fizzle out and be resurrected a few months later. In the UK, at least, “everyone should supply ID” will collapse under weight of sheer impossibility. The task there is made harder by virtue of the fact there is no nationally issued, mandatory identity card system in operation.

Things are a little more complicated in the US, where anonymous online speech is concerned. The legal provision that protects free speech online—Section 230—is under increasing scrutiny. It remains to be seen how things will play out there.

Having said that, this talking point will return. When it does, you’ll be armed with the knowledge that data privacy is incredibly important. Due to a variety of social, legal, and practical problems in this particular realm, social media sites won’t be asking you for verification any time soon.

The post Would real identities make social media safer? appeared first on Malwarebytes Labs.

Back in the fall of 2020 threat actors started to massively exploit a vulnerability in the no-longer maintained Magento 1 software branch. As a result, thousands of e-commerce shops were compromised and many of them injected with credit card skimming code.

While monitoring activities tied to this Magento 1 campaign, we identified an e-commerce shop that had been targeted twice by skimmers. This in itself is not unusual, multiple infections on the same site are common.

However this case was different. The threat actors devised a version of their script that is aware of sites already injected with a Magento 1 skimmer. That second skimmer will simply harvest credit card details from the already existing fake form injected by the previous attackers.

In the incident we describe in this post, the threat actors also took into account that an e-commerce site may get cleaned up from a Magento 1 hack. When that happens, an alternate version of their skimmer injects its own fields that mimic a legitimate payments platform.

Mass Magento 1 infections

The Magento 1 end-of-life coupled with a popular exploit turned out to be a huge boon for threat actors. A large number of sites have been hacked indiscriminately just because they were vulnerable.

RiskIQ attributed these incidents to Magecart Group 12, which has a long history of web skimming using various techniques including supply-chain attacks.

This skimmer is rather lengthy and contains various levels of obfuscation that make debugging it more challenging. Although there are variations, the format and decoy payment form are very much the same.

No honor among thieves

Costway is a retailer that started to sell its own name-brand products via platforms such as Amazon and later rolled out costway.com and subsequent localized online stores. Their French portal (costway[.]fr) attracted about 180K visitors last December.

Our crawlers identified that the websites for Costway France, UK, Germany and Spain, which run the Magento 1 software, had been compromised around the same time frame.

We can see the credit card skimmer injection directly on the checkout page for costway[.]fr as it stands out in English while the rest of the site is in French. This is not surprising considering that the Magento 1 hacking campaign is automated and fairly indiscriminate.

But what’s more interesting is that another skimmer is also present on the site (loaded externally from securityxx[.]top) and targeting the Magento 1 skimmer.

It’s possible that the threat actors’ level of access to e-commerce sites differs. The former exploit a core vulnerability that grants them root access while perhaps the latter can only perform specific types of injections. If that is the case, this would explain why they simply leave the fake form alone and grab credentials from it.

There’s an additional twist here where the criminals also planned for the scenario where the e-commerce site gets cleaned up from the Magento 1 injection.

The skimmer creates its own form fields which closely ressemble the legitimate ones from the Adyen payments platform that Costway uses. Visually, only a very small style change (font size) gives it away, but there are more significant implications under the hood.

Adyen encrypts the form fields using their proprietary technology. The threat actors wanted to recreate the same look and feel from Adyen but be able to harvest the credit card information in their own way.

To summarize, from a victim’s perspective, there are 3 different skimmers that get loaded when they proceed to the checkout page.

1. Magento 1 hack skimmer injected directly in checkout page
2. Custom skimmer (securityxx[.]top/security.js) that steals from Magento 1 skimmer
3. Custom skimmer (securityxx[.]top/costway.js) that alters legitimate payment iframe

Previous skimmer

The same threat actors were already busy working on Costway’s compomise at least in late December 2020 as recorded in this urlscanio crawl. They used the custom domain costway[.]top to host their code.

The domain costway[.]top is related to a family we have come across before. There is overlap with the skimmer code they use, naming conventions and even infrastructure.

At the moment, this group is quite active and continues with the same techniques we have seen several months ago.

Competing for resources

A large number of Magento 1 sites have been hacked but yet are not necessarily being monetized. Other threat actors that want access will undoubtedly attempt to inject their own malicious code. When that happens, we see criminals trying to access the same resources and sometimes fighting with one another.

We informed Costway during our investigation but also witnessed their site getting reinfected. The costway[.]top domain was discarded in favor of securityxx[.]top where threat actors customized the skimmer specifically for them.

At the time of writing, costway[.]fr is still compromised but Malwarebytes users are protected thanks to our Browser Guard extension and general web protection available in our software.

We would like to thank Jordan Herman over at RiskIQ for sharing additional indicators with us.

Indicators of Compromise (IOCs)

securityxx[.]top
costway[.]top
hdpopulation[.]com
cdnanalyze[.]com
hdenvironement[.]com
crazyvaps[.]info
cdnchecker[.]org
cdnoptimize[.]com
hdanalyse[.]com
cdnapis[.]org
cookiepro[.]cloud
cdndoubleclick[.]net

149[.]248[.]7[.]219
95[.]179[.]142[.]28
45[.]76[.]75[.]35
136[.]244[.]110[.]105
149[.]248[.]0[.]74
149[.]28[.]64[.]156
95[.]179[.]139[.]29
209[.]250[.]246[.]214

The post Credit card skimmer piggybacks on Magento 1 hacking spree appeared first on Malwarebytes Labs.

January 28 was Data Privacy Day, but for Malwarebytes Labs, it was Data Privacy Week. As such, we’re packed with more privacy coverage than you can shake a stick at, starting with some practical steps on how to make your online life private and secure, and why privacy is core to a safer internet. We also covered news on Grindr facing a huge GDPR fine due to privacy concerns and Google’s new privacy-friendly technology called FLoC (Federated Learning of Cohorts) that could replace cookies in cross-site ad trackers.

To cap the week off, we invited a panel of experts from Mozilla, DuckDuckGo, and EFF to talk about Internet users’ experiences with the internet and online privacy, in a special episode of the Lock & Code podcast.

Lastly, we touched on DDoS attacks spawned by the abuse of RDP, the mighty take down of the Emotet botnet, and the Emotet update written by law enforcement that’s meant to remove it from infected computers.

Other cybersecurity news

• Serco, the company behind the UK’s Test and Trace app, was hit by the Babuk ransomware. (Source: Sky News)
• In another win for the good guys, a Canadian national was charged in relation to the NetWalker ransomware. (Source: Threatpost)
• The state of Utah has introduced legislation to make “catfishing” a criminal offense. (Source: Threatpost)
• After being disrupted by cybersecurity companies before 2020 ended, Trickbot is back with fresh phishing campaigns. (Source: ZDNet)
• A new Microsoft Office 365 phishing campaign homed in on executives. (Source: Help Net Security)
• An “NHS Coronavirus vaccination program” scam was found making rounds. (Source: Belfast Live)
• Instagram scams—yikes! (Source: The Daily Express)
• According to a report, phishing links targeted at Steam players rose by 250 percent, between November and December 2020. (Source: TechRadar)

Stay safe, everyone!

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

Ransomware gangs deciding to pack their bags and leave their life of crime is not new, but it is a rare thing to see indeed.

And the Fonix ransomware (also known as FonixCrypter and Xinof), one of those ransomware-as-a-service (RaaS) offerings, is the latest to join the club.

Fonix was first observed in mid-2020, but it only started turning heads around September-October of that year. Believed to be of Iranian origin, it is known to use four methods of encryption—AES, Salsa20, ChaCha, and RSA—but because it encrypts all non-critical system files, it’s slower compared to other RaaS offerings.

Encrypted files usually bear the .FONIX and .XINOF (Fonix spelled backwards) file extensions; however, the .repter extension was also used. The Desktop wallpaper of affected system is changed to the Fonix logo.

The same account that announced the end of Fonix later tweeted an apology:

And a promise to “make up for our mistakes”:

That promise came in the form of the master decryption keys needed to decrypt .FONIX and .XINOF files, and an administration tool, which can only decrypt one file at a time. Cautious readers may want to wait for more useful decryption tools, written by more legitimate organisations, before trusting code released by known cybercriminals.

This isn’t the first time a ransomware group has displayed a conscience—that is assuming we take their word they will continue to “use our abilities in positive ways”. In 2018, developers of the GandCrab ransomware, another RaaS that also made a public announcement of shutting down its operations in mid-2019, made a U-turn and released decryption keys for all its victims in Syria after a Syrian father took to Twitter to plead with them. GandCrab had infected his system and encrypted photos of his two sons who had been taken by the war.

In 2016, when TeslaCrypt made an exit from the RaaS scene, a security researcher reached out to its developers and asked if they would release the encryption keys. They did release the master key that helps decrypt affected systems for free.

It remains to be seen if the Fonix gang will keep their word. If some or all of them change their minds and go back to a life of crime, they wouldn’t be the first ransomware gang to do so. Any ransomware group packing up and leaving is good news. However, while Fonix appears to have left the building, it was only one small player in a vast criminal ecosystem. The threat of ransomware remains.

The post Fonix ransomware gives up life of crime, apologizes appeared first on Malwarebytes Labs.

We have talked about RDP many times before. It has been a popular target for brute force attacks for a long time, but attackers have now found a new way to abuse it.

Remote access has become more important during the pandemic, with as many people as possible try to work from home. Which makes it all the more important to configure RDP services in a secure way.

Quick recap of RDP

RDP is short for Remote Desktop Protocol. Remote desktop is exactly what the name implies, an option to control a computer system remotely. It almost feels as if you are actually sitting behind that computer. Because of the current pandemic, many people are working from home and may be doing so for a while to come.

All this working from home has the side effect of more RDP ports being opened. Not only to enable the workforce to access company resources from home, but also to enable IT staff to troubleshoot problems on the workers’ devices. A lot of enterprises rely on tech support teams using RDP to troubleshoot problems on employee’s systems.

We warned about one of the consequences of exposing RDP in our post Brute force attacks increase due to more open RDP ports. And we provided some security measures in our post How to protect your RDP access from ransomware attacks. But this time we are going to talk about a different kind of attack that makes use of open RDP ports.

RDP as a DDoS attack vector

The RDP service can be configured by Windows systems administrators to run on TCP (usually port 3389) and/or on the UDP port (3389). When enabled on a UDP port, the Microsoft Windows RDP service can be abused to launch UDP reflection attacks with an amplification ratio of 85.9:1.

The traffic that is set off by this amplification attack is made up of non-fragmented UDP packets sourced from the UDP port and directed towards UDP ports on the victim’s IP address(es). From logs, these attack-induced packets are readily discernible from legitimate RDP session traffic because the amplified attack packets are consistently 1,260 bytes in length and are padded with long strings of zeroes.

Open RDP ports

At the time of writing, the Shodan search engine, which indexes online devices and their services, lists over 3.6 million results in a search for “remote desktop” and NetScout identified 33,000 Windows RDP servers that could potentially be abused in this type of DDoS attack.

The consequences of such an attack

The owner of the destination IP address(es) will experience a DDoS attack. DDoS stands for Distributed Denial of Service. It is a network attack that involves hackers forcing numerous systems to send network communication requests to one specific server. If the attack is successful, the receiving server will become overloaded by nonsense requests. It will either crash or become so busy that normal users are unable to use it.

A DDoS attack can cause:

• Disappointed users
• Loss of data
• Loss of revenue
• Lost work hours/productivity
• Damage to the businesses’ reputation
• Breach of contract between a victim and its users

We have discussed preventive measures for DDoS targets in our post DDoS attacks are growing: What can businesses do?

But there are consequences for the abused service owners as well. These may include an interruption or slow-down of remote-access services, as well as additional service disruption due to an overload of additional network hardware and services.

How to avoid helping a DDoS attack

There are a few things you can do to avoid being roped into an RDP DDoS attack. They are also useful against other RDP related attacks.

• Put RDP access behind a VPN so it’s not directly accessible.
• Use a Remote Desktop Gateway Server, which provides some additional security and operational benefits like 2FA, for example. Also, the logs of the RDP sessions can prove especially useful.
• If RDP servers offering remote access via UDP cannot immediately be moved behind VPN concentrators, it is recommended to disable RDP via UDP.

Logging of the traffic will not be effective as a preventive measure, but it will enable you to figure out what might have happened and assist you in closing any gaps in your defenses.

Stay safe, everyone!

The post RDP abused for DDoS attacks appeared first on Malwarebytes Labs.

This blog post was authored by Hasherezade and Jérôme Segura

Emotet has been the most wanted malware for several years. The large botnet is responsible for sending millions of spam emails laced with malicious attachments. The once banking Trojan turned into loader was responsible for costly compromises due to its relationship with ransomware gangs.

On January 27, Europol announced a global operation to take down the botnet behind what it called the most dangerous malware by gaining control of its infrastructure and taking it down from the inside.

Shortly thereafter, Emotet controllers started to deliver a special payload that had code to remove the malware from infected computers. This had not been formally clarified just yet and some details around it were not quite clear. In this blog we will review this update and how it is meant to work.

Discovery

Shortly after the Emotet takedown, a researcher observed a new payload pushed onto infected machines with a code to remove the malware at a specific date.

That updated bot contained a cleanup routine responsible for uninstalling Emotet after the April 25 2021 deadline. The original report mentioned March 25 but since the months are counted from 0 and not from 1, the third month is in reality April.

This special update was later confirmed in a press release by the U.S. Department of Justice in their affidavit.

On or about Janury 26, 2021, leveraging their access to Tier 2 and Tier 3 servers, agents from a trusted foreign law enforcement partner, with whom the FBI is collaborating, replaced Emotet malware on servers physically located in their jurisdiction with a file created by law enforcement

BleepingComputer mentions that the foreign law enforcement partner is Germany’s Federal Criminal Police (Bundeskriminalamt or BKA).

In addition to the cleanup routine, which we describe in the next section, this “law enforcement file” contains an alternative execution path that is followed if the same sample runs before the given date.

The uninstaller

The payload is a 32 bit DLL. It has a self-explanatory name (EmotetLoader.dll) and 3 exports which all lead to the same function.

If we look inside this exported function, we can see 3 subroutines:

The first one is responsible for the aforementioned cleanup. Inside, we can find the date check:

If the deadline already passed, the uninstall routine is called immediately. Otherwise the thread is run repeatedly doing the same time check, and eventually calling the deletion code if the date has passed.

The current time is compared with the deadline in a loop. The loop exits only if the deadline is passed, and then proceeds to the uninstallation routine.

The uninstall routine itself is very simple. It deletes the service associated with Emotet, deletes the run key, and then exits the process.

As we know by observing the regular Emotet, it achieves persistence in two alternative ways.

Run key

This type of installation does not require elevation. In such a case, the Emotet DLL is copied into %APPDATA%

.

System Service

If the sample was run with Administrator privileges, it installs itself as a system service.. The original DLL is copied into C:WindowsSysWow64

.

For this reason, the cleanup function has to take both scenarios into account.

We noticed the developers made a mistake in the code that’s supposed to move the law enforcement file into the %temp% directory:

GetTempFileNameW(Buffer, L"UPD", 0, TempFileName) 

The “0” should have been a “1” because according to the documentation, if uUnique is not zero, you must create the file yourself. Only a file name is created, because GetTempFileName is not able to guarantee that the file name is unique.

The intention was to generate a temporary path, but because of using the wrong value in the parameter uUnique, not only was the path generated, but the file was also created. That lead to the further name collision and as a result, the file was not moved.

However, this does not change the fact that the malware has been neutered and is harmless since it won’t run as its persistence mechanisms have been removed.

If the aforementioned deletion routine was called immediately, the other two functions from the initial export are not getting run (the process terminates at the end of the routine, calling ExitProcess). But this happens only if the sample has been run after April 25.

The alternative execution path

Now let’s take a look at what happens in the alternative scenario when the uninstall routine isn’t immediately called.

After the waiting thread is run, the execution reaches two other functions. The first one enumerates running processes, and searches for the parent process of the current one.

Then it checks the process name if it is “explorer.exe” or “services.exe”, followed by reading parameters given to the parent.

Running the next stage

The next routine decrypts and loads a second stage payload from the hardcoded buffer.

Redirection of the flow to the decrypted buffer (via “call edi“):

The next PE is revealed: X.dll:

After decrypting the payload, the execution is redirected to the beginning of the revealed buffer that starts with a jump:

This jump leads to a reflective loader routine. After mapping the DLL to a virtual format, in the freshly allocated area in the memory, the loader redirects the execution there.

First, the DllMain of X.dll is called (it is used for the initialization only). Then, the execution is redirected to one of the exported functions – in the currently analyzed case it is Control_RunDll.

The execution is continued by the second dll (X.dll). The functions inside this module are obfuscated.

The payload that is called now looks very similar to the regular Emotet payload. Analogical DLL, and also named X.dll such as: this one could be found in earlier Emotet samples (without the cleanup routine), for example in this sample.

The second stage payload: X.dll

The second stage payload X.dll is a typical Emotet DLL, loaded in case the hardcoded deadline didn’t pass yet.

This DLL is heavily obfuscated and all the used APIs are loaded dynamically. Also their parameters are not readable – they are dynamically calculated before use, sometimes with the help of a long chain of operations involving many variables:

This type of obfuscation is typical for Emotet’s payloads, and it is designed to confuse researchers. Yet, thanks to tracing we were able to reconstruct what APIs are being called at what offsets.

The payload has two alternative paths of execution. First it checks if it was already installed. If not, it follows the first execution path, and proceeds to install itself. It generates a random installation name, and moves itself under this name into a specific directory, at the same time adding persistence. Then it re-runs itself from the new location.

If the payload detects that it was run from the destination path, it takes an alternative execution path instead. It connects to the C2 and communicates with it.

The current sample sends a request to one of the sinkholed servers. Content:

L"DNT: 0rnReferer: 80.158.3.161/i8funy5rv04bwu1a/rnContent-Type: multipart/form-data; boundary=--------------------GgmgQLhRJIOZRUuEhSKorn"

The following image shows web traffic from a system infected via a malicious document downloading the special update file and reaching back to the command and control server owned by law enforcement:

Motives behind the uninstaller

The version with the uninstaller is now pushed via channels that were meant to distribute the original Emotet. Although currently the deletion routine won’t be called yet, the infrastructure behind Emotet is already controlled by law enforcement, so the bots are not able to perform their malicious action.

For victims with an existing Emotet infection, the new version will come as an update, replacing the former one. This is how it will be aware of its installation paths and able to clean itself once the deadline has passed.

Pushing code via a botnet, even with good intentions, has always been a thorny topic mainly because of the legal ramifications such actions imply. The DOJ affidavit makes a note of how the “Foreign law enforcement agents, not FBI agents, replaced the Emotet malware, which is stored on a server located overseas, with the file created by law enforcement”.

The lengthy delay for the cleanup routine to activate may be explained by the need to give system administrators time for forensics analysis and checking for other infections.

The post Cleaning up after Emotet: the law enforcement file appeared first on Malwarebytes Labs.