Archive for author: makoadmin

A set of vulnerabilities has been found in the way a number of popular TCP/IP stacks handle DNS requests. Potentially this could impact hundreds of millions of servers, smart devices, and industrial equipment. The researchers that discovered the vulnerabilities have named them NAME:WRECK.

Plural vulnerabilities?

Yes, the researchers found 9 DNS-related vulnerabilities that have the potential to allow attackers to take targeted devices offline or to gain control over them. These vulnerabilities affect 4 popular TCP/IP stacks: FreeBSD, IPnet, Nucleus NET, and NetX. Together they are used by over 100 Million devices. Since the vulnerable DNS clients are usually exposed to the internet this creates a huge attack surface.

Some background

Domain Name System (DNS) is an internet protocol that translates user-friendly, readable URLs, like malwarebytes.com, to their numeric IP addresses, like 52.85.104.30, allowing the computer to identify a server without the user having to remember and input its actual IP address. Basically, you could say DNS is the phonebook of the internet. DNS name resolution is a complex process that can be interfered with at many levels.

Although never visible to end-users, TCP/IP stacks are libraries that vendors add to their firmware to support internet connectivity and other networking functions like DNS queries for their devices. These libraries are very small but, in most cases, underpin the most basic functions of a device, and any vulnerability here exposes users to remote attacks.

Devices and organizations affected by NAME:WRECK

FreeBSD is widely used in firewalls and several commercial network appliances. It is also the basis for other well-known open-source projects. The most common device types running FreeBSD include computers, printers and networking equipment.

IPNet tends to be used by internet-facing enterprise devices located at the perimeter of an organization’s network, such as modems, routers, firewalls, and printers, as well as some industrial and medical devices.

The Nucleus RTOS website mentions that more than 3 billion devices use this real-time operating system, such as ultrasound machines, storage systems, critical systems for avionics and others, although presumably many of them are not internet connected.

NetX is usually run by the ThreadX Real Time Operating System (RTOS). Typical applications include medical devices, systems-on-a-chip and several printer models. The most common device types running ThreadX include printers, smart clocks and energy and power equipment in Industrial Control Systems (ICS).

Did you notice how it may turn out that the vertical that has most to fear from these vulnerabilities is a sector that is already under heavy stress, and has been actively targeted by cyberattacks? The healthcare sector is indeed in the top 3 of most affected by these vulnerabilities, together with the government.

Exploitation

For an attacker to use these vulnerabilities they have to find a way to send a malicious packet in reply to a legitimate DNS request. So the attacker will have to run a person-in-the-middle attack or be able to use an existing vulnerability like DNSpooq between the target device and the DNS server to pull this off.

Mitigation

Complete protection against NAME:WRECK requires patching devices running the vulnerable versions of these IP stacks. FreeBSD, Nucleus NET and NetX have been patched recently, and device vendors using this software should provide their own updates to customers.

It is not always easy though for users to find out whether they have the most up to date patches for any devices running across these affected IP Stacks. And patching devices is not always easy, or even possible.

There are a few things you can do however:

• Make an inventory of the devices running the vulnerable stacks. Forescout Research Labs has released an open-source script that uses active fingerprinting to detect devices running the affected stacks.
• Keep unpatched devices contained or disconnected from the internet, until they can be patched or replaced.
• Configure devices to rely on internal DNS servers where possible.
• Monitor network traffic for malicious packets that try to exploit the vulnerabilities.
• Apply patches as soon as possible after they have been made available.

For those interested in the full technical details the full report is available here and will be presented at Black Hat Asia 2021.

Stay safe, everyone!

The post NAME:WRECK, a potential IoT trainwreck appeared first on Malwarebytes Labs.

An Italian citizen’s apparent attempt to hire a hitman on the Dark Web has been undone by clever analysis of his Bitcoin transactions. The man, who is reported to be an IT worker employed by a major corporation, is alleged to have paid the hitman to assassinate his former girlfriend.

What happened?

According to a news article published by European policing entity Europol on April 7, they assisted Italian communications crime law enforcement Polizia Postale e Delle Comunicazioni in arresting a local citizen suspected of paying about $12,000 USD worth of bitcoin (at the moment of writing) to a Dark Web hitman to kill his ex-girlfriend. The Europol report states that the timely investigation had prevented any harm against the potential victim. The spiteful ex was detained before he paid the entire sum on the verge of the attack.

The agencies

The Polizia Postale e Delle Comunicazioni is a federal department of the Italian police force that is, among others, responsible for solving cybercrimes.

Europol is the European Union Agency for Law Enforcement Cooperation. Headquartered in The Hague, the Netherlands, they assist the EU member states in their fight against serious international crime and terrorism.

The investigation

After being asked for assistance, Europol reportedly carried out an urgent analysis of the Bitcoin transactions to trace the origin. They were able to identify the crypto-asset service provider from which the suspect had acquired the funds. The company that sold the assets confirmed the information provided by the investigators and offered more information about the suspected man.

Unmasking Bitcoin transactions

Europol managed to track down the local cryptocurrency service provider that facilitated the suspect’s Bitcoin purchases to uncover more information about him.

In their press release Europol states:

Europol carried out an urgent, complex crypto-analysis to enable the tracing and identification of the provider from which the suspect purchased the cryptocurrencies.

It was able to do this because Bitcoin transactions are all recorded in a public ledger called a blockchain. The Bitcoin blockchain records every transaction ever made using the currency in its blockchain, making it a perfect source for big data investigations. With the proper tools investigators can follow and back-track payments. Although Bitcoin transactions don’t record the names of the people involved, they do record the wallet addresses that sent or received money. If police can link a wallet address to a real individual, they can trace that individual’s credits and debits.

Exchanges where non-digital money and crypto-currencies get exchanged are an established weak spot in the chain for criminals, since users often have to hand over personally identifiable information before they can use one. If the police can trace bitcoin payments back to a bitcoin purchase at a legitimate exchange they can subpoena the exchange for the bitcoin owner’s personal details.

Unmasking Dark Web activity

The story is a useful reminder that the Dark Web is not as hidden and unconnected as many people think. Connections to the regular web, and the real world, can reveal the things its users are trying to keep hidden. In this case, the arrested man seems to have been unmasked by his connections to currency transactions on the regular web, but there are numerous other pathways from one to the other.

For example, Dark Web sites can reveal their links to hosting companies or regular websites through misconfigured SSL certificates or leaky server-status pages, among other things. And real people can accidentally unmask themselves through any number of mistakes, from EXIF data in photos to reusing their Reddit account username on a Dark Web market.

Investigation tools

There are existing tools and new ones under development that enable investigators to find the type of information that can connect Dark Web operators to a real world identity. Interpol is working with great interest on a Dark Web Monitor to help in criminal investigations that involve Crypto-currencies, PGP, the Dark Web, and other related fields, and the US Defense Advanced Research Projects Agency (DARPA) revealed the existence of its Deep Web search project, Memex, several years ago.

Anonymity and privacy researcher Sarah Jamie Lewis has written a tool called OnionScan to help Dark Web site operators identify the kind of operational security leaks or software misconfigurations, like shared SSH keys, which can connect Dark Web sites to each other, or to clear web sites. You can find information about her work on onionscan.org.

The hitman

It is unknown whether the hitman that offered to carry out the crime has been identified and will be prosecuted. As we have seen in the past, not every hitman on the Dark web does what they were paid for. Obviously we do not condone what this suspect was doing, but there is another lesson to be learned here. It is not safe to assume that you are private on the Dark Web, nor that you will get what you paid for.

The post How bitcoin payments unmasked a man who hired a Dark Web contract killer appeared first on Malwarebytes Labs.

Many of us who read the news daily encounter a regular drum beat of ransomware stories that are both worrying and heartbreaking. And what many of us don’t realize is that they are often interconnected. Some of the gangs behind the ransomware campaigns that we read about have established a relationship among each other that can be described as “being in league with each other”, yet they lack certain elements that might cement their status as a true cartel in the digital underground world.

This is the overall finding of Jon DiMaggio, known cybersecurity luminary and Chief Security Strategist for Analyst1, a threat intelligence company.

In a whitepaper entitled “Ransom Mafia – Analysis of the World’s First Ransomware Cartel”,  DiMaggio and his team aimed to provide an analytical assessment on whether there is indeed a ransomware cartel, or if indications there might be was just something the ransomware gangs fabricated to distract researchers and law enforcement.

The ties that bind

Analyst1 has identified two strong connections among the affiliated groups mentioned in its report that establishes how they work together as something like a cartel. They are:

Shared data leak sites

The gangs within the cartel share information about the companies they have attacked, as well as all the data they have exfiltrated. In one example, the researchers saw Twisted Spider posting victim data gathered by the Lockbit gang and Viking Spider. This is on top of these gangs posting company data onto their respective leak sites.

Shared infrastructure

SunCrypt was found using IP addresses and Command and Control infrastructure tied to Twisted Spider to deliver the ransomware payload in its campaigns. This was observed 10 months after Twisted Spider used them in its operations. This kind of resource sharing can only occur if a relationship of trust has already been established.

Analyst1 has also identified other circumstantial and technical ties among the groups that, on their own, aren’t sufficient measures for precise attribution.

Other noteworthy findings

The research includes several other noteworthy findings:

• Victim data is not the only thing these affiliate gangs pass between each other. They were also observed sharing tactics, such as the increasing proliferation and persistence of their malware in the wild by making a Ransomware-as-a-Service (RaaS) package available to other criminals, and command and control (C&C) infrastructure.
• Affiliated gangs appear to be on the move to automate their attacks, in evidence of added automated capabilities found in ransomware payloads. Manually infecting compromised companies is a known hallmark of big game hunting (BGH) ransomware threat actors.
• Some of the groups involved have opened themselves to media interviews in the past. They also issue their own press releases from their own websites and use multiple means to harass victims into paying up.
• Affiliated gangs have claimed to be part of a cartel at some point in the past. Although some of them have already denied their connections, evidence contradicts this.

Who is in the cartel?

Analyst1 grouped affiliated ransomware gangs under the “Ransom Cartel” tag. Note, however, that this collective had named themselves the “Maze Cartel” the same year their cooperative relationship had been established.

The Ransom Cartel arose in May 2020. Twisted Spider, the gang behind Maze ransomware and others, is said to be the group that initiated its creation. Their primary motivation was financial gain.

Most of these groups are based in Eastern Europe and they primarily speak Russian, an attribute they don’t hide at all. Some of these groups have developed malware other than ransomware; however, all groups made sure that none of them would affect users in Russia and in the Commonwealth of Independent States (CIS).

Below is a brief overview of the individual groups said to make up the Ransom Cartel (Note that not all of them go for an official name. As such, they are named based on the ransomware variant they use):

Twisted Spider

Other alias(es): Maze Team, FIN6

Malware: Maze ransomware (previously known as ChaCha), Egregor ransomware, Qakbot worm, other commodity exploit kits

Malwarebytes detections: Ransom.Maze, Ransom.Sekhmet, Worm.Qakbot, respectively

LockBit gang

Other alias(es): none

Malware: LockBit ransomware, Hakops keylogger

Malwarebytes detection: Ransom.LockBit, Trojan.Keylogger, respectively

Wizard Spider

Other alias(es): Grim Spider (hailed as a subset of Wizard Spider), UNC1878, TEMP.MixMaster

Malware: TrickBot Trojan, Ryuk ransomware, Conti ransomware, MegaCortex ransomware, BazarLoader backdoor

Malwarebytes detection: Trojan.TrickBot, Ransom.Ryuk, Ransom.Conti, Ransom.MegaCortex, Trojan.Bazar, respectively

Viking Spider

Other alias(es): Ragnar group

Malware: Ragnar locker ransomware

Malwarebytes detection: Ransom.Ragnar

SunCrypt Gang

Other alias(es): none

Malware: SunCrypt ransomware

Malwarebytes detection: Ransom.SunCrypt

“What cartel?”

Although there is indeed trust, and sharing of resources and tactics, among these ransomware gangs, Analyst1 has assessed that the Ransomware Cartel is not a true cartel. Its report concludes that the cooperation it witnessed lacked some of the elements needed to reach the level of a cartel, most notably profit-sharing.

You can read more about the report here.

The post How ransomware gangs are connected, sharing resources and tactics appeared first on Malwarebytes Labs.

This week on Lock and Code, we discuss the top security headlines generated right here on Labs. In addition, we speak to Point3 Security chief strategist Chloé Messdaghi, HaveIBeenPwned founder Troy Hunt, and We Hack Purple founder and CEO Tanya Janca about security fatigue.

Security fatigue is exactly what it sounds like. It’s the limit we all reach when security best practices become overbearing. It’s what prevents us from making a strong password for a new online account. It’s why we may not update our software despite repeated notifications.

And, importantly, it probably isn’t your fault.

Tune in to learn about security fatigue from the experts—how does it manifest in their professions, what have they seen, and what are the unforeseen outcomes to it—on the latest episode of Lock and Code, with host David Ruiz.

https://feed.podbean.com/lockandcode/feed.xml

You can also find us on the Apple iTunes store, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.

We cover our own research on:

• Research claims Pixel phones share 20 times more data than iPhones
• Has Facebook leaked your phone number?
• Aurora campaign: Attacking Azerbaijan using multiple RATs
• Pre installed auto installer threat found on Android devices in Germany
• Fake Trezor app steals more than $1 million worth of crypto coins
• SAP warns of malicious activity targeting unpatched systems
• Zoom zero day discovery makes calls safer, hackers $200,000 richer

Other cybersecurity news:

• Vulnerabilities cause headaches for QNAP (Source: The Register)
• Preventing cyberattacks during tax season (Source: Help Net Security)
• Call of Duty cheats expose gamers to malware (Source: Threat Post)
• Avoiding Instagram scams (Source: Business 2 Community)
• Hackers steal security camera footage, sell it on as “home videos” (Source: SCMP)

Stay safe!

The post Beating security fatigue with Troy Hunt, Chloé Messdaghi, and Tanya Janca: Lock and Code S02E06 appeared first on Malwarebytes Labs.

Last month, Google began a test pilot of its Federated Learning of Cohorts—or FLoC—program, which the company has advertised as the newest, privacy-preserving alternative in Google Chrome to the infamous third-party cookie.

Sounds promising, right? Well, about that.

Despite Google’s rhetoric about maintaining user privacy, its FLoC trial leaves much to be desired. Google Chrome users had no choice in whether they were included in the FLoC trial, they received no individualized notification, and, currently, they have no option to specifically opt-out, instead having to block all third-party cookies on their Google Chrome browsers to leave the trial.

Electronic Frontier Foundation (EFF), which analyzed Google’s published materials and Chromium’s source code to better understand FLoC, lambasted the pilot program and the technology behind it.

“EFF has already written that FLoC is a terrible idea,” the digital rights organization said. “Google’s launch of this trial—without notice to the individuals who will be part of the test, much less their consent—is a concrete breach of user trust in service of a technology that should not exist.”

What is FLoC?

Labored acronyms aside, FLoC is part of Google’s broader plan to develop its idea of a more private web, as the search giant struggles with the death of the most important digital advertising tool in the history of the Internet—the third-party cookie.

We should be clear at the outset here. First-party cookies help the Internet function. Cookies help websites knit web page visits together. First-party cookies are used to knit together different visits to pages on the same website and help them remember useful information such as your settings, what’s in your shopping cart, and—most importantly—whether you are logged in or not.

Third-party cookies can also benefit Internet users, but for years, this technology primarily served as a sort of “tree of life” for the digital advertising economy, allowing advertisers to knit together web page visits from many different websites.

Implanted on millions of popular websites, tracking code that relies on third-party cookies has enabled the profiling of nearly every single Internet user by their age, gender, location, shopping interests, political affiliations, and religious beliefs. Third-party cookies also ushered in the era of “Real-Time Bidding,” in which businesses compete for the opportunity to deliver you ads based on those user profiles. And as online publishers like newspapers struggled to maintain in-print advertising revenue in their decade-long transition to digital, third-party cookies provided a sometimes necessary bargain for those publishers: Sell ad placements not to individual companies, but scale ad revenue rapidly by harnessing the results of mass user profiling.

Without the third-party cookie, much of this activity would either have been delayed or limited. So, too, would the money being made by the developers of those third-party cookies, which include many digital advertising companies and, as it just so happens, one notable Silicon Valley giant—Google.

The obvious question about FLoC technology then is: Why would Google create an alternative to the technology that helps them generate billions of dollars in ad revenue every year?

Because the third-party cookie is dying. As users increasingly protect their online privacy, they continue to install browser plug-ins that block the type of online tracking enabled by third-party cookies. Further, several browsers—including Safari and Mozilla—began blocking third-party cookies by default years ago.

If anything, FLoC is Google’s answer to a future that we all know is coming, in which the third-party cookie has lost its power.

Alright but what actually is FLoC?

How FLoC technology differs from third-party cookies is that, primarily, FLoC will create profiles on groups of users and not profiles on individual users. If FLoC becomes the norm, then Google Chrome users will have their activity tracked by Google Chrome itself. Based on that browsing activity—including what sites are visited and what searches are made—Google Chrome will then group users into “cohorts.” When you visit a website it will be able to ask your browser what cohorts you belong to and deliver ads that advertisers have targeted towards those “cohorts.”

This means that the broader digital advertising ecosystem will remain, but the wheels that churn to move it forward will undergo some changes.

In its FLoC announcement, Google explained that it is trying to find a balance between what it believes is the usefulness and the harm of third-party cookies.

“Keeping in mind the importance of ‘and,’ FLoC is a new approach to interest-based advertising that both improves privacy and gives publishers a tool they need for viable advertising business models,” the company said.

According to Google, FLoC technology will not share your individual browsing history with anyone or any company, including Google. Instead, that activity will be grouped into the activity of thousands of users in a cohort. Further, Google said that its Chrome browser will not create cohorts based on “sensitive topics.” So, that hopefully means that there will not be cohorts for people searching for aid in suicide prevention, domestic abuse, drug addiction, or private medical diagnoses, for example.

According to EFF, though, Google’s FLoC technology includes multiple privacy problems, such as the ability to use FLoC findings in conjunction with browser fingerprinting to reveal information about users, and the potentially never-ending quest to gather user data as a first-stage requirement only to then “unlearn” that user data if it could lead to the creation of a sensitive cohort.

The technical concerns with FLoC are many, but they’re difficult for the average user to grasp. What is easy to understand, however, is how those average users are left behind in Google’s FLoC trial.

A quiet trial

For such a seismic shift in the Internet’s infrastructure, many might assume that Google would announce the FLoC trial with more safeguards.

That’s not what happened.

In Google’s FLoC trial announcement, it gave Google Chrome users no option to opt out before the trial began. Instead, Google silently pushed FLoC technology to Chrome users in the US, Canada, Mexico, Australia, New Zealand, Brazil, India, Japan, Indonesia, and the Philippines. While Google described the trial as affecting a “small percentage of users,” according to EFF, that percentage could be as high as 5 percent.

That sounds small at first, but take into account that nearly-ancient estimates (circa 2016) put active Google Chrome users around 2 billion, meaning that the FLoC trial could affect up to 100 million people. That is an enormous number of people to subject to a data analysis experiment without their prior consent.

Google also said that users can opt-out of the FLoC trial by disabling third-party cookies through Google Chrome. It’s good that such an option exists, but it’s unfortunate that users will have to have some basic understanding of FLoC and third-party cookies to remove themselves from a trial that they might have no knowledge about.

Compounding the issue is that turning off all third-party cookies could remove a good deal of functionality from a user’s web experience. That seems both imprecise and unfair.

Finally, the FLoC trial affects more than browser users—it affects websites, too. Remember those publishers that Google said it would like to help? According to Google, “websites that don’t opt out will be included in the FLoC calculation if Chrome detects that they load ads-related resources”. Some of them have already opposed being automatically included into a technology trial that will result in the profiling of their readers—even if that profiling is supposedly less privacy-invasive.

Julia Angwin, editor-in-chief of the investigative news outlet The Markup, said that her organization chose to opt out of FLoC.

“We @themarkup opted out of Google’s newfangled cookie-less tracking system (FLoC) so our readers will not be targeted with ads based on visiting our site,” Angwin wrote on Twitter. “Others who care about reader privacy might want to do the same.”

Angwin is just one of many journalists who have reported on FLoC technology, most of whom have authored FAQs, explainers, and detailed guides on just what it is Google is trying to do with its recent experiment.

All of those explainers, in fact, point to the biggest problem here: Users are being included in something that they did not know about that will affect how they are treated on the Internet, and they had no say in the matter beforehand.

A private web can incorporate many things. At the very least, it should include user respect.

The post Millions of Chrome users quietly added to Google’s FLoC pilot appeared first on Malwarebytes Labs.

In traditional software development, programmers code an application in one computing environment before deploying it to a similar, but often slightly different environment. This leads to bugs or errors that only show up when the software is deployed—exactly when you need them least. To solve for this, modern developers often bundle their applications together with all of the configuration files, libraries, and other pieces of software required to run in it in “containers” hosted in the cloud. This method, called containerization, allows them to create and deploy the entire computing environment, so there are no unexpected surprises.

Because a lot of projects rely on many of the same dependencies, developers can get their projects off to a flying start by building on top of pre-configured container images, which can be downloaded from online image repositories like Docker Hub. Those images may in turn be built on top of other images, and so on. So, for example, developer building a plugin for the WordPress content management system might base their project on a container image containing WordPress, and that container might be built on top of another image that includes a web server and database, which may be built on a container image for a popular operating system, like Ubuntu.

Container images provide a simple way to distribute software at the expense of transparency.

Now imagine if a malicious actor could hide a crypto-jacker in a popular source image, one that might get used and reused thousands of times. They could end up with a huge number of systems mining cryptocurrency for them for free.

Docker images

Docker Hub is the world’s largest library and community for container images and therefore a very attractive target for attackers. Luckily, tampering with containers is not easy and Docker has a strong focus on “Trusted Delivery” which is supposed to guarantee an untampered app. But there is a lot more to be found in container images than just the app.

Uncovered by researchers

In the last several years, Unit 42 researchers have uncovered cloud-based crypto-jacking attacks in which miners are deployed using an image in Docker Hub. Containerization is almost always conducted in a cloud environment, because that contributes to its scalability—behind the scenes popular web applications or services often rely on huge numbers of identical containers. This has some advantages for the crypto-jackers:

• There are many instances for each target.
• It is hard to monitor, so miners can run undetected for a long time.

The researchers uncovered 30 images from 10 different Docker Hub accounts that accounted for over 20 million “pulls” (downloads).

The favorite cryptocurrency

The most popular cryptocurrency for attackers to mine is Monero. Monero is a cryptocurrency designed for privacy, promising:

“all the benefits of a decentralized cryptocurrency, without any of the typical privacy concessions”.

No cryptocurrency is anonymous, as many people think, but there are other reasons why the crypto-jackers favor Monero:

• Many crypto-mining algorithms run significantly better on ASICs or GPUs, but Monero mining algorithms run better on CPUs, which matches what the crypto-jacker can expect to find in a containerized environment.
• Besides Bitcoin, Monero is one of the better known cryptocurrencies and therefore is expected to hold its value.

Cryptocurrencies are pseudonymous at best, which means that users hide behind a pseudonym, like one or more wallet IDs. Their activities can be tracked—forever—so keeping their identity secret depends on how well they can separate their real identity from their wallet IDs.

XMRig

In most of the recorded attacks that mined Monero, the attackers used XMRig. XMRig is a popular Monero miner and is preferred by attackers because it is easy to use, efficient, and, most importantly, open source, which allows attackers to modify its code. In some images, the researchers found different types of cryptominers. Possibly to enable the attacker to choose the best crypto-miner for the victim’s hardware.

The consequences

Not only will having a crypto-miner in your container lead to either a higher bill or lower performance, there could be other consequences too, because many cloud service providers explicitly forbid mining for cryptocurrencies.

Mitigation

Stopping crypto-jackers from taking advantage of popular images can be done at a few levels:

Image providers needs to perform regular checks against tampering, container repositories should monitor for irregularities, and cloud service providers can check outgoing connections for mining-related activity

Container users should avoid downloading containers from untrusted sources, scan images for malware at the build stage, check the integrity of images before and after copying them, and monitor runtime activity and network communication.

Since containers are just another way of arrange software stacks—including operating systems, applications and libraries—all the usual precautions apply too, such as patching vulnerabilities promptly.

Stay safe, everyone!

The post Cryptomining containers caught coining cryptocurrency covertly appeared first on Malwarebytes Labs.

Two Dutch white-hat security specialists entered the annual computer hacking contest Pwn2Own, managed to find a Remote Code Execution (RCE) flaw in Zoom and are $200,000 USD better off than they were before.

Pwn2Own

Pwn2Own is a high profile event organized by the Zero Day Initiative that challenges hackers to find serious new vulnerabilities in commonly used software and mobile devices. The event is held to demonstrate that popular software and devices come with flaws and vulnerabilities, and offers a counterweight to the underground trade in vulnerabilities.

The “targets” volunteer their software and devices and offer a reward for successful attacks. Fans are treated to a hacking spectacle, successful hackers get kudos and no small amount of cash (in this case the reward was a whopping $200,000 USD), and vendors find nasty bugs that might otherwise be sold to criminals.

Pwn2Own 2021 runs from 6 April to 8 April. The full schedule for this year can be found on their site. This year the event has focused on software and devices used when working from home (WFH), including Microsoft Teams and Zoom, for obvious reasons.

The white hats

Keuper and Alkemade, who are employed by cybersecurity company Computest, combined three vulnerabilities to take over a remote system on the second day of the Pwn2wn event. The vulnerabilities require no interaction of the victim. They just need to be on a Zoom call.

The vulnerability

In the light of responsible disclosure, the full details of the method have been kept under wraps. What we do know is that it was Remote Code Execution (RCE) flaw: As a class of software security flaws that allow a malicious actor to execute code of their choosing on a remote machine over a LAN, WAN, or the Internet.

We also know that the method works on the Windows and Mac version of the Zoom software, but does not affect the browser version. It is unclear whether the iOS- and Android-apps are vulnerable since Keuper and Alkemade did not look into those.

The Pwn2Own organization have tweeted a gif demonstrating the vulnerability in action. You can see the attacker open the calculator on the system running Zoom. Calc.exe is often used as the program that hackers open on a remote system to show that they can run code on the affected machine.

Not patched yet

Understandably, Zoom has not yet had the time to issue a patch for the vulnerability. They have 90 days to do so before details of the flaw are released, but they are expected to do it way before that period is over. The fact that the researchers came out on the second day of the Pwn2Own event with this vulnerability does not mean they figured it out in those two days. They will have put in months of research to find the different flaws and combine them into an RCE attack.

Security done right

This event, and the procedures and protocols that surround it, demonstrate very nicely how white-hat hackers work, and what responsible disclosure means. Keep the details to yourself until protection in the form of a patch is readily available for everyone involved (with the understanding that vendors will do their part and produce a patch quickly).

Mitigation

For now, the two hackers and Zoom are the only ones that know how the vulnerability works. As long as it stays that way there is not much that Zoom users have to worry about. For those that worry anyway, the browser version is said to be safe from this vulnerability. For anyone else, keep your eyses peeled for the patch and update at earliest convenience after it comes out.

Stay safe, everyone!

The post Zoom zero-day discovery makes calls safer, hackers $200,000 richer appeared first on Malwarebytes Labs.

Several users of Trezor, a small hardware device that acts as a cryptocurrency wallet, have been duped by a fake app with the same name. The app was available on Google Play and Apple’s App Store and also claimed to be from SatoshiLabs, the creators of Trezor.

According to the Washington Post, the fake Trezor app, which was on the App Store for at least two weeks (from 22 January to 3 February), was downloaded 1,000 times before it was taken down. A fake Trezor app on the Play Store was downloaded by a similar number of users, but it’s not clear how long it was available on the platform.

Those victimized by the fake app couldn’t tell that they were downloading a dodgy app. Apart from the mimicked name and visual style of the Trezor brand, victims have also reported seeing high rating reviews—155 reviews giving it close to a 5 star rating—a common tactic of criminal app developers looking to gain the trust of users.

Phillipe Christodoulou, owner of a dry-cleaning service was one of the many Trezor users who downloaded the fake Trezor app from the App Store. He wanted to check his cryptocurrency balance on his phone and decided to search for and download an app instead of plugging the device into his computer via a USB connection. He lost 17.1 Bitcoins, which was worth $600,000 USD at that time. At the time of writing it is worth more than $1 million USD.

A similar incident happened with James Fajcz, a reliability engineer, in December 2020. He bought both Ethereum and Bitcoin worth $14,000 USD with his savings after seeing the price of digital tokens rising that same month. To ensure his investment was secure, be bought a Trezor, and then downloaded its purported app on his iPhone. When the app didn’t connect to his hardware wallet, he assumed that the app didn’t work. After buying a second round of cryptocurrencies weeks later, he checked the balance on his Trezor device using his computer, but it was empty. He realized he had been conned out of his digital currencies when he reached out to the Trezor community on Reddit.

Both men didn’t know that an official Trezor app doesn’t exist, and both also blamed Apple for letting a fake app into the App Store, a space touted by Apple as “the most trusted marketplace for apps.”

Both Google and Apple provide screening of apps before they’re added to their app stores, but these incidents remind us that no form of screening is perfect. Successful criminals are good at finding and exploiting loopholes, or using malicious techniques that are hard to screen for. We don’t know how this malicious app worked, but we can guess that it might simply transfer victims’ cryptocurrency to a wallet (that happens to be owned by the app’s creator), which is very similar to what a legitimate app would be doing.

With cryptocurrencies continuing to gain popularity, expect more scammers to bank on this wave. In May last year, Harry Denley, a cybersecurity researcher specializing in cryptocurrencies, revealed that he discovered almost 75 malicious Google Chrome extensions designed to steal money from cryptocurrency wallets.

Last month, CoinDesk went on a crypto scam hunt and found that both popular app stores have found fake crypto wallet apps.

Cryptocurrency owners are advised to be more vigilant than ever about phishing campaigns in the form of apps and extensions. Trezor users, in particular, should be aware that while there is no app for their hardware wallet now, there will be an official one in the future. Watch the company’s official website and Twitter account for news on that and, until then, avoid downloading Trezor apps and heed the company’s advice: never share your seed until your device asks you to do so.

The post Fake Trezor app steals more than $1 million worth of crypto coins appeared first on Malwarebytes Labs.

A timely warning to keep systems patched has appeared, via a jointly-released report from Onapsis and SAP. The report details how threat actors are “targeting and potentially exploiting unprotected mission-critical SAP applications”. Some of the vulnerabilities used were weaponised fewer than 72 hours after patches are released. In some cases, a newly deployed SAP instance could be compromised in just under a week if people aren’t patching.

Old threats cause new problems

The vulnerabilities being exploited were patched months or even years ago. Sadly, when organisations don’t patch and update, compromise is only a step away. This isn’t a new phenomenon, by any means. It doesn’t matter if we’re talking software or hardware fixes, or replacing an insecure Windows XP box on the network, or running updates you’ve been putting off for that old mobile phone in your drawer. Erratic update routines, or worse still, abandoning them altogether can lead to serious consequences.

In its own press release on the subject, SAP warns that a failure to patch could give cybercriminals “full control of the unsecured SAP applications”, while pointing out that its cloud-based solutions are not at risk:

The scope of impact from these specific vulnerabilities is localized to customer deployments of SAP products within their own data centers, managed colocation environments or customer-maintained cloud infrastructures. None of the vulnerabilities are present in cloud solutions maintained by SAP.

The US Department of Homeland Security’s CISA lists some of the serious end-results of failing to make use of the available SAP patches, in an announcement that followed the release of the report:

• Financial fraud
• Disruption to business
• Sensitive data theft
• Ransomware
• Halt of operations

Patch early, patch often

From the above list, ransomware alone could lead to any of those security issues. The data in the threat intelligence report is incredibly useful for anybody who thinks they could be affected. Thanks to SAP and Onapsis, we know how brief the window can be for those tasked with defending systems to do something about it. It also highlights how both security and compliance are at risk, along with some of the techniques attackers will try to use out in the wild.

Regular readers will know we’re big on patching and updating. Some of the most undesirable threats around thrive on a lack of regular updates. Manual, as opposed automatic updates, can also bring headaches for organisations struggling to get up to speed with best practices. It’s certainly not easy, with some organisations simply choosing to never patch at all.

A lack of patching may lead to disaster

That risky strategy of little-to-no-patching stands a good chance of going horribly wrong. A study of 340 security professionals in 2019 found 27% of organisations worldwide, and 34% in Europe, said they’d experienced breaches due to unpatched vulnerabilities. If an inability to patch promptly is compounded by delays in detecting new systems added to networks and a lack of regular vulnerability scanning, attackers are left with a lot of room to work with.

If your organisation is a touch lax on patching, or making it up as you go along – fear not! There’s still time to get a grip on this difficult subject. Whether you use any of the systems mentioned in the threat report up above or not, timely patching is the way to go. The threats to your business may not come knocking at the door today, or even tomorrow, but that won’t be the case forever.

The post SAP warns of malicious activity targeting unpatched systems appeared first on Malwarebytes Labs.

This post was authored by Hossein Jazi

As tensions between Azerbaijan and Armenia continue, we are still seeing a number of cyber attacks taking advantage of this situation. On March 5th 2021, we reported an actor that used steganography to drop a new .Net Remote Administration Trojan. Since that time, we have been monitoring this actor and were able to identify new activity where the threat actor switched their RAT from .Net to Python.

Document Analysis

The document targets the government of Azerbaijan using a SOCAR letter template as lure. SOCAR is the name of Azerbaijan’s Republic Oil and Gas Company. The document’s date is 25th March 2021 and the letter, related to export of catalyst for analysis, is written to the Ministry of Ecology and Natural Resources. The document’s creation time is 28th March 2021 and is aligned with the date mentioned on the letter. Based on the dates we believe that this attack happened between 28th and 30th of March 2021.

The embedded macro in this document is almost similar to what we have reported before with some small differences. We will talk about the similarities between these two documents in the next section.

The macro has two main functions “Document_Open” and “Document_Close”. In “Document_Open” after defining the required variables it creates a directory (%APPDATA%Roamingnettools48) for its Python Rat.

It then copies itself in a new format to the file path defined before in order to be able to extract the required data from an embedded PNG file (image1.png).

To extract the embedded data, it calls the “ExtractFromPng” function to identify the chunk that has the embedded data. After finding the chunk, it extracts the files from the PNG file and writes them into “tmp.zip”.

The “tmp.zip” is then extracted into “%APPDATA%Roamingnettools48” directory. It contains the Python 3.6 interpreter, NetTools Python library, Python Rat, the RAT C2 config, as well runner.bat.

The Python Rat will be executed when the document is closed. The “Document_Close” first delays execution to bypass security detection mechanisms by creating a junk loop for 100 times and then executes the runner.bat by calling Shell function.

The runner.bat is also delaying execution for 64 seconds and then it calls Python to execute the Python RAT (vabsheche.py)

SET /A num=%RANDOM% * (80 - 60 + 1) / 32768 + 60
timeout /t %num%
set DIR=%~dp0
"%DIR%python" "%DIR%vabsheche.py"

Python RAT Analysis

The Python RAT used by the attacker is not obfuscated and is pretty simple. It is using the platform library to identify the victim’s OS type.

The C2 domain and port are hardcoded within a file in the RAT directory. The RAT opens this file and extracts the host and port from this file.

In the next step if the victim is running Windows, it makes itself persistent through creating a scheduled task. It first checks if a scheduled task with the name “paurora*” exists or not. If it does not exist, it reads the content of bg.txt file and creates a bg.vbs file. Then adds the created VBS file to the list of scheduled tasks.

The created VBS file calls the runner.bat to execute the Python RAT.

The main functionality of the RAT is through a loop that starts by creating a secure SSL connection to the server using a certificate file (cert.pem) that was extracted from the PNG file and dropped into the RAT directory.

After building the secure connection to the server it goes to a loop that receives a message from the server and executes different commands based on the message type.

Here is the list of commands that can be executed by the RAT:

• OPEN_NEW_CONNECTION: Sends a message to the server with False as content
• HEART_BEAT: Sends a message to the server that the victim is alive
• USER_INFO: Collects victim info including OS Name, OS Version and User Name
• SHELL: Executes shell commands received from the server
• PREPARE_UPLOAD: Checks if it can open a file to write the received data from server into it and if that is the case it sends a “Ready” message to the server
• UPLOAD: Receives a buffer from the server and writes them into file
• DOWNLOAD: Archives files and sends them to the server

Similarity Analysis

In this sections we provide the similarities between two documents and TTPs used by them. This will help hunters to identify the future campaigns associated with this actor.

TTPs similarities

• Used steganography to embed RATs within the embedded images.
• Used scheduled tasks for persistence. In both cases It created a VBS file to execute the batch runner.
• Used a batch file with the same name (runner.bat) to execute the final RAT.
• Used the same technique to exfiltrate data. (Archive them and send them to the server)

Documents similarities

• Both have been obfuscated using same obfuscation techniques: Inserting random characters within the meaningful names to obfuscate the functions and variables names. After deobfuscation, the function graph of these two documents are almost similar.

• Both have used the similar method to obfuscate strings: using “MyFunc23” function that receives an array of numbers and decodes them into a string.

Other similarities

• both C2 domains have resolved to the same IP address.
• There are overlaps between the commands used by both .Net and Python RATs.

Conclusion

Due to tensions between Azerbaijan and Armenia, cyber attacks against these countries have been increasing in the past year. The Malwarebytes Threat Intelligence Team is constantly monitoring actors that are targeting these countries and was able to identify an actor that has targeted Azerbaijan using different RATs. This actor has used .Net and Python RATs to infect victims and steal data from them. The actor used spear phishing as initial vector that has used steganography to drop a variant of its RATs.

IOCs

The post Aurora campaign: Attacking Azerbaijan using multiple RATs appeared first on Malwarebytes Labs.