IT News

There’s a new ransomware gang in town—and, frankly, we’re not at all surprised.

After DarkSide disappeared—coincidentally, immediately after Colonial Pipeline gave in to the group’s ransom demand of roughly $5M USD worth in Bitcoin—a new ransomware group who calls themselves BlackMatter surfaced on the dark web, kicking off their operations sometime this week.

Analysts from Recorded Future, the cybersecurity group who initially reported on the new ransomware group, said their researchers are currently investigating BlackMatter. Though it is a fairly new cybercriminal gang, its members could be considered professionals in Ransomware-as-a-service (RaaS) as, to quote from BlackMatter themselves, “The project has incorporated in itself the best features of DarkSide, REvil, and LockBit.”

The BlackMatter group has been spotted posting on Exploit and XSS, two known cybercrime forums in the dark web. They’re not advertising their ransomware, however; they are recruiting affiliates that are called “initial access brokers,” a term that cybergangs use to refer to fellow criminals who have access to hacked enterprise networks. According to BlackMatter’s ads, the ransomware group is seeking hacked access to “corporate networks” located in Australia, Canada, the UK, and the US.

The new ransomware gang made it clear that they will not be targeting certain organizations, almost as if to say that they are keenly aware of the danger that comes from pulling off internationally-recognized attacks which can lead—and have led—to sudden shutdowns and disappearances.

In their own leak site, BlackMatter claim not to attack companies belonging to the following six industries, with the caveat that if or when any companies in these industries do get hit, such victims should simply ask for a free decryption:

“* Hospitals.
* Critical infrastructure facilities (nuclear power plants, power plants, water treatment facilities).
* Oil and gas industry (pipelines, oil refineries).
* Defense industry.
* Non-profit companies.
* Government sector.”

At the moment, BlackMatter has not made any move to attack organizations yet. Perhaps it won’t be long now.

Malwarebytes Labs will keep an eye on BlackMatter and continue to report about it in the future, not forgetting that AvosLocker, another new ransomware variant that popped up roughly in late June or early July, is also currently looking for affiliates they can work with; and, last but not the least, Haron, a potential offshoot of Avaddon and Thanos ransomware operations.

The post BlackMatter, a new ransomware group, claims link to DarkSide, REvil appeared first on Malwarebytes Labs.

Researchers at RandoriSec have found serious vulnerabilities in the firmware provided by UDP Technology to Geutebrück and many other IP camera vendors. According to the researchers the firmware supplier UDP Technology fails to respond to their reports despite numerous mails and LinkedIn messages.

Because of this unwillingness of UDP Technology to respond, RandoriSec worked with Geutebrück, one of the camera vendors, to correct the 11 authenticated RCE vulnerabilities and a complete authentication bypass that they found in the firmware.

History lessons

RandoriSec had found vulnerabilities in previous versions of the UDP technology firmware and knew from that previous experience that they could expect to be stonewalled when they reported the new vulnerabilities. UDP Technology provides firmware for several IP camera manufacturers, like:

• Geutebruck
• Ganz
• Visualint
• Cap
• THRIVE Intelligence
• Sophus
• VCA
• TripCorps
• Sprinx Technologies
• Smartec
• Riva
• and the camera’s they sell under their own brand name.

CISA

The Cybersecurity & Infrastructure Security Agency issued an advisory about the two Geutebrück IP camera types that were confirmed to be vulnerable, the G-Cam E2 and G-Code.

The CISA advisory includes the CVE identifiers for the found vulnerabilities. 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).

CVE-2021-33543 Missing authentication: allows unauthenticated remote access to sensitive files due to default user authentication settings.

CVE-2021-33544 RCE: the affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33545 RCE: The affected product is vulnerable to a stack-based buffer overflow condition in the counter parameter which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33546 RCE: The affected product is vulnerable to a stack-based buffer overflow condition in the name parameter, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33547 RCE: The affected product is vulnerable to a stack-based buffer overflow condition in the profile parameter which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33548 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33549 RCE: The affected product is vulnerable to a stack-based buffer overflow condition in the action parameter, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33550 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33551 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33552 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33553 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

CVE-2021-33554 RCE: The affected product is vulnerable to command injection, which may allow an attacker to remotely execute arbitrary code.

Impact of the vulnerabilities

As you can imagine, the combination of unauthorized access to sensitive files combined with that many RCE vulnerabilities creates a treasure trove for attackers, and finding an attack method that works for you is trivial. And it should not come as a surprise that public exploits are available.

Even an attacker having access to your live-stream can be bad enough, but an attacker that has full control of your IP camera is even worse. And, what’s more, a combination of the unauthorized access and some of the RCE vulnerabilities can allow an attacker to achieve root on the IP cameras that are running on the vulnerable firmware.

Mitigation

For the mentioned Geutebrück cameras, a patch is available (Login required) and should be installed as soon as possible. Users are urgently recommended to update to firmware Version 1.12.14.7 or later. Geutebrück worked with RandoriSec to make sure their patch fixes the vulnerabilities.

For users of other IP cameras we can not do much more than to recommend to either disable/replace the cameras and certainly query the vendors to find out whether their cameras suffer from the same vulnerabilities.

As a general advice for users of IoT devices, you can follow these CISA recommendations:

• Change the default passwords of the cameras.
• Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls and isolate them from the business network.
• When remote access is required, use secure methods, such as virtual private networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that a VPN is only as secure as the connected devices.

Vendors of the IP cameras running UDP Technology firmware are encouraged to ask some serious questions about the development of the firmware and why UDP Technology chooses not to work with security researchers in a way that benefits all the IP camera vendors instead of only the one working with the researchers. Geutebrück users know which types are vulnerable and can remedy the vulnerabilities by installing a patch. Users of the other brands are left guessing, from reading between the lines in the RandoriSec blogpost, we fear the worst.

For a complete technical analysis of how the researchers found the vulnerabilities, you are encouraged to read the RadoriSec blog about it.

The post UDP Technology IP Camera firmware vulnerabilities allow for attacker to achieve root appeared first on Malwarebytes Labs.

Before the work week ended last week Friday, a security researcher found a leak of what is claimed to be full phone numbers of users of Clubhouse, the new social media app everyone is talking about and just recently came out of beta.

Clubhouse is an audio-only social media platform where, unlike many popular social sites in the market, users can communicate with each other in voice chat rooms that can accomodate thousands of people. Think of it as Zoom without the video and text chat options. As it got exponentially popular during the pandemic, it was deemed as “the next big social network” following TikTok. And, as one Clubhouse user had put it, “It feels more personal, deeper, than other social media.”

HaveIBeenPwned-creator Troy Hunt, however, was quick to ask the important question before things get completely out of hand. After all, a compromise of 3.8 billion data—in this case, phone numbers—is not something you can easily dismiss.

Below is a partial extract of the text from off the screenshot of that Dark Web forum post:

Clubhouse (valued at over $3 billion USD) is the latest social network including the most influential people in the world.

COMPROMISED DATA:
3.8 billion phone numbers (including cellphones + fixed + private + professional numbers).

Clubhouse is connected in real time to all their users’ phonebooks meaning each time you add a new phone number in your phonebook, the number is automatically added into the secret database of Clubhouse. Each number is ranked by a score (the score corresponds to the number of Clubhouse users who have this specific phone number in their phonebook).

With this score we are able to evaluate the level of the network of each phone number in the world. We can do national and international ranking of each human and organization.

The partial extract. To be honest, the last sentence doesn’t even make sense.

Alon Gal, or @UnderTheBreach on Twitter, CTO of cybercrime intelligence firm Hudson Rock, gave an unabashed take about the hack.

If you’re wondering why we shouldn’t make a big deal out of this so-called breach, Gal further explains in the same Twitter thread:

Jane Manchun Wong, or @wongmjane on Twitter, a security and app researcher, had a similar take.

Many more chimed in, with some shedding light on the dark web forum post (“bad sample”) and on the poster itself (“This seller has a bad past”).

Every breach report, especially if it involves big names and/or big numbers, could drive anyone scrambling to get the full story, how it happened, how many were affected, and what should users do now. However, cybercriminals, being criminals, won’t think twice about using “The Breach angle” as a lure to score thousands of dollars from fellow data-hungry criminals.

As always, stay safe, and don’t believe every report of breach out there until it’s verified by an expert!

The post The Clubhouse database “breach” is likely a non-breach. Here’s why. appeared first on Malwarebytes Labs.

It must not be easy to work at Kaseya right now. While they are working as hard as they can to help customers, and customers of their customers, recover from the REvil ransomware attack at the beginning of July, a new vulnerability in their software has been disclosed.

As a sidenote, Kaseya specifically denies on their website that they did not pay the ransom ($70 million was the initial demand) to stop the critics saying they were encouraging additional ransomware attacks fed by rumors that the decryption key was obtained by paying the ransom.

In the meantime, security researchers warn of three new zero-day vulnerabilities in the Kaseya Unitrends service and advise users not to expose the service to the Internet.

Kaseya Unitrends

Kaseya offers remote monitoring and management solutions for Managed Service Providers (MSPs). MSPs are companies that facilitate the remote management of a business’s technology and network. A managed service provider will remotely manage a business’s network so the business owner doesn’t need to hire a full-time team of their own.

Unitrends is a Kaseya company and a provider of all-in-one enterprise backup and continuity solutions. It can serve as a cloud-based enterprise backup and disaster recovery solution that can be used as a stand-alone solution or as an add-on for the Kaseya VSA remote management platform.

DIVD warns again

As Victor Gevers indicated when he was a guest in our podcast about the Kaseya VSA incident, the Dutch Institute for Vulnerability Disclosure found seven or eight zero-days in the Kaseya software. In their Kaseya limited disclosure post from earlier this month you can find a list of 7 CVE identifiers.

But the DIVD opened a new case file for Kaseya Unitrends. The summary in that case file reveals that a DIVD researcher has identified several vulnerabilities in the Kaseya Unitrends backup product versions that are lower than 10.5.2. The recommendation to mitigate the risks posed by these vulnerabilities is to not expose this service or the clients directly to the internet until Kaseya has patched these vulnerabilities.

The DIVD is all about coordinated vulnerability disclosure. This is done because the full knowledge of the vulnerabilities might enable cybercriminals to leverage the vulnerability and do a lot of harm. Coordinated vulnerability disclosure lets the vendor know what exactly is wrong, but it also informs the users that are affected by the vulnerability what the mitigation instructions are.

So, in this case, the DIVD informed Kaseya Unitrends about the details of the vulnerability and started sharing it with 68 government Computer Emergency Response Teams (CERTs) under the TLP:AMBER designation. When sharing cyber intelligence, sources may use TLP:AMBER when information requires support to be effectively acted upon, but carries risk to privacy, reputation, or operations if shared outside of the organizations involved.

Recipients are supposed to limit the sharing of TLP:AMBER information with staff in their own organization who need to know, or with service providers to mitigate risks to the member’s organization if the providers are contractually obligated to protect the confidentiality of the information. Information can be shared with those parties specified above only as widely as necessary to act on the information.

One of the recipients, however, publicized the content by uploading it to an online analyzing platform.

“An employee uploaded the TLP: AMBER labeled directly to an online analyzing platform and shared its content to all participants of that platform; because we do not have an account on that platform, we immediately requested removing this file.”

The vulnerabilities affecting the Kaseya Unitrends backup service include a mixture of authenticated remote code execution, authenticated privilege escalation, and unauthenticated remote code execution on the client side. A threat actor would need a valid user to perform remote code execution or privilege escalation on the publicly exposed Kaseya Unitrends service. Furthermore, threat actors would already need to have breached a customer network to exploit the unauthenticated client RCE. This reduces the chance of these vulnerabilities having the same impact as the REvil attack that exploited one of the vulnerabilities within Kaseya VSA.

Stay safe, everyone!

The post Kaseya Unitrends has unpatched vulnerabilities that could help attackers expand a breach appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs:

• Stopransomware(dot)gov, a one-stop hub for ransomware resources
• Beware, crypto-scammer seeks foreigner with BLOCK CHAIN ACCOUNT
• Remcos RAT delivered via Visual Basic
• US, EU, UK, NATO blame China for “reckless” exchange attacks
• HiveNightmare zero-day lets anyone be SYSTEM on Windows 10 and 11
• ID theft ghouls targeting Surfside victims is appalling, but no surprise
• The life and death of the ZeuS Trojan
• Pegasus spyware has been here for years. We must stop ignoring it
• Millions of Windows machines affected by ancient printer vulnerability
• Five years for swatter who caused a man’s death for a Twitter handle
• Busted! Fraud as a service gang that sold 2FA-proof phishing arrested
• CNA legal filings lift curtain on a Phoenix cryptolocker ransomware attack
• Avoslocker enters the ransomware scene, asks for partners

Other cybersecurity news

• Pegasus spyware seller: blame our customers, not us, for hacking (Source: BBC)
• A favourite target of Russian hackers, the Olympics are on guard (Source: NBC)
• UK national suspected of hacking Twitter accounts of Joe Biden and Barack Obama is arrested in Southern Spain (Source: El Pais)
• Japan government says companies are being targeted by China-backed cyber hacking group (Source: Reuters)
• New Zealand, China clash over hacking claims (Source: VOA)
• Phishing attacks get smarter as targets struggle to keep up (Source: VentureBeat)
• Discord hosts “significant volumes of malware” in its CDN (Source: The Register)
• Hacker group threatening to sell 1TB of Saudi Aramco data to the highest bidder (Source: TIESS)
• 40 percent of individuals fell victim to a phishing attack in the past month (Source: Help Net Security)
• India and Vietnam rank on list as those most hit by Android malware (Source: Tech Wire Asia)

Stay safe, everyone!

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

Last week, Check Point Research described a new Mac variant of malware they call XLoader. It was identified as being the successor of something called Formbook, a very prevalent threat in the Windows world. According to Check Point, the Mac version of the malware is being “rented” as part of a malware-as-a-service program, at the price of $49 for one month or $99 for three months.

Unfortunately, Check Point was a bit vague on the details of how the Mac version behaves, leaving folks unsure of exactly how to protect themselves against this malware. Fortunately, more details have since come to light.

How XLoader gets installed

XLoader appears to be distributed within a .jar – or Java archive – file. Such a file contains code that can be executed by Java, dropping the malware on the system. One major advantage, for the attacker, of using Java is that the “dropper” (the file responsible for installing the malware) can be cross-platform.

However, this file format has a very significant disadvantage for the attacker, which is that macOS does not, by default, include Java, and has not for quite some time. Back around 2011 to 2012, there was a flood of multiple different pieces of malware designed to infect Macs via vulnerabilities in Java, which at the time was installed on every Mac out of the box. This meant that all Macs were vulnerable, and to make matters worse, despite updates from Oracle (Java’s owner), more vulnerabilities kept being found and exploited.

Apple responded by ripping Java out of the system. Since then, the only way Java can be on a system is if the user has installed it, which most users won’t. This means that Java is no longer a very useful means of attack on modern macOS systems.

There can be a couple reasons why a JAR file might be used on macOS. One is unfamiliarity with modern macOS, from a malware developer who has Java on their system but doesn’t understand this is non-standard for some reason. This is something often seen with more amateurish malware, and there are definitely some indications of that with this malware.

However, another reason is that the malware is targeted at specific individuals who are known to have Java installed. These could be Java developers, for example, at a particular company, or perhaps employees at a company that uses Java-based tools. A source at ESET reported that they had detected this malware back in January, with the JAR file being distributed via email. This points to a targeted campaign.

The installation process

The dropper – named Statement SKBMT 09818.jar in this case – would need to be opened by the user. The good news is that, if it was downloaded from an email client or browser that uses modern file system code, it will be marked with a “quarantine” flag. This means that the Gatekeeper feature of macOS will not allow it to execute by default.

There are ways that Mac users can bypass this and open the file anyway, but not without seeing a similar warning first.

Still, a significant amount of Mac malware droppers in the last year or so have been unsigned, and have given users instructions on what to expect and how to open the file. In such cases, users can and do bypass these warnings and open the malicious installers successfully.

In the event that the user downloads the JAR file using an email client that does not use the right file system code, and thus does not set a quarantine flag, the file will immediately open when double-clicked, without any complaints. The same will also be true if the file is copied onto a non-Mac drive before being opened, such as a Windows network share, where the quarantine flag will be lost.

Once opened, the JAR file will infect the system, and strangely, will also open a .ico (icon) file containing a Microsoft word icon image.

It’s unknown why this is done. It’s not uncommon for malware to open a “decoy document.” In such cases, when the malware pretends to be a document (as in this case, where the malware is pretending to be a statement of some kind), it will then open a document for the user to look at, to assuage suspicions the user would have if no document ever opened, while it’s doing bad stuff behind the scenes.

Is this a really badly botched attempt to open a decoy document? Or is it possible that this wasn’t meant as a public release, and the file being opened is a placeholder? Either would be a reasonable explanation, but we don’t know which is true.

While the user is looking in confusion at this wonderful icon, the JAR code will install the malware in the background. On my test machine, the malware installed the following items:

~/._p1pxXl0Fz4/I8ppUnip.app
~/kIbwf02l
~/NVFFY.ico
~/LaunchAgents/com._p1pxXl0Fz4.I8ppUnip.plist

The launch agent .plist file is used to load the app from the hidden folder (._p1pxXl0Fz4) found in the user folder. The kIbwf02l file is an exact copy of the Mac mach-o executable file found inside the app, but it’s unclear why this is left there, as it isn’t actually used. It’s a suspiciously-named file that will be visible to the user and thus may raise suspicions, so its presence is odd.

The NVFFY.ico file is the Microsoft Word icon file opened by the malware as a “decoy.”

A closer look at the Java code

Extracting the Java code from the JAR file was a painless task, and the code is not obfuscated in any way. The code is quite simple, but is able to drop a payload on either Windows or Mac. If you’re not interested in looking at code, feel free to skip ahead.

The filenames are hard-coded in the JAR file, as seen here.

private static String get_crypted_filename(final int pt) {
    final String exe_ = "fI4sWHkeeeee";
    final String mach_o = "kIbwf02ldddd";
    final String display = "NVFFYfffffff";

It’s a bit of a stretch to call these filenames “encrypted,” as the only thing that has been done to them is that a specific letter has been added to the end, repeating a varying number of times. (What letter is used depends on the string in question, and is also hard-coded.) These characters are stripped off to get the filenames, resulting in the mach-o filename of kIbwf02l and the “display” document filename of NVFFY.

The malware has quite simple code for determining the system it’s running on:

public static int _GetOS() {
    final String OS = System.getProperty("os.name").toLowerCase();
    if (OS.contains("mac")) {
        return 1;
    }
    if (OS.contains("win")) {
        return 2;
    }
    return 0;
}

From there, the malware reads encrypted data from within the JAR file and writes it out to the desired location on the system (in this case, the kIbwf02l file).

private byte[] getFileFromResource(final String name) throws Exception {
    try (final InputStream in = this.getClass().getResourceAsStream("/resources/" + name)) {
        final byte[] data = new byte[16384];
        final ByteArrayOutputStream buffer = new ByteArrayOutputStream();
        int nRead;
        while ((nRead = in.read(data, 0, data.length)) != -1) {
            buffer.write(data, 0, nRead);
        }
        return buffer.toByteArray();
    }
}

From there, the malware launches the malicious process and opens the decoy document (aka “displayFile”).

        if (osFile != null && osFile.length != 0) {
            final String absolutePath = userPath + osFilename + ((os == 1) ? "" : ".exe");
            stubClass.writeBufferToFile(decrpt_data(osFile), absolutePath);
            if (os == 1) {
                final File file = new File(absolutePath);
                final Set<PosixFilePermission> perms = new HashSet<PosixFilePermission>();
                perms.add(PosixFilePermission.OWNER_READ);
                perms.add(PosixFilePermission.OWNER_WRITE);
                perms.add(PosixFilePermission.OWNER_EXECUTE);
                Files.setPosixFilePermissions(file.toPath(), perms);
            }
            processBuilder.command(absolutePath);
            processBuilder.start();
        }
        final byte[] displayFile = stubClass.getFileFromResource(displayFilename);
        if (displayFile != null && displayFile.length != 0) {
            final String absolutePath2 = userPath + displayFilename + getDisplayExt();
            stubClass.writeBufferToFile(decrpt_data(displayFile), absolutePath2);
            final File f = new File(absolutePath2);
            Desktop.getDesktop().open(f);
        }

The malicious application

The malicious Mac application, dropped and executed by the JAR file, is heavily obfuscated, making it hard to learn more about what it does. According to analysis done by SentinelOne, one of the app’s main goals appears to be harvesting credentials.

The app itself is not code signed in any way. However, since it was created by the JAR and not downloaded from anywhere, it can be executed without Gatekeeper examining it or asking for user consent to run it. The launch agent .plist file is used to ensure the app is launched at startup, but explicitly does not try to keep the process alive. This means that if anything terminates the malicious process, it will not re-open until the next reboot.

The app itself has been marked as an LSUIElement, which is done to prevent its icon from showing on the Dock whenever it is running. This is a feature intended to be used by apps responsible for managing some user interface element – such as a menu bar icon – but that do not have a user interface of their own and thus can’t be interacted with directly. This prevents the Dock from being littered with these kinds of apps, but is a common technique used to prevent malicious apps from appearing in the Dock.

TL;DR

To sum up, this malware is likely to be used for targeted attacks against intended victims who are known to have Java installed. Attackers may also have knowledge that something in the victims’ environment will enable users to easily open a JAR file without being blocked by Gatekeeper.

The dropper itself is completely unsophisticated, with barely an attempt to hide anything, while the mach-o executable used in the malicious application installed on the system is quite well protected against prying eyes. This may be an indication that the two components of the malware were developed by different individuals.

This malware will be detected by Malwarebytes for Mac as OSX.XLoader. However, as of yet, data shows that Malwarebytes has not detected a single instance of this malware in the wild.

The post OSX.XLoader hides little except its main purpose: What we learned in the installation process appeared first on Malwarebytes Labs.

The Dutch police announced that they arrested two Dutch citizens, aged 24 and 15, for developing and selling phishing panels. The police also searched the house of another suspect, an 18 year old who was not arrested.

The people behind this illegal business called themselves the Fraud Family and were active on Telegram to sell their panels to interested parties. For cybercriminals that lacked the technical knowledge or means, the Fraud Family also offered to host the phishing sites and backend panels.

Group-IB

During their investigation the police received help from the threat intelligence firm Group-IB that specializes in investigating and preventing cybercrimes. Group-IB published a blogpost that goes into detail about the activities of the Fraud Family and the different panels that were developed by them. If you are interested in more details about the phishing methods, their blog is well worth the read.

2FA bypass

The developers of these phishing kits made sure their customers, fellow cybercriminals, could bypass 2FA. The crooks who use this phishing infrastructure get access to a web panel that interacts, in real time, with the phishing site. When victims submit their banking credentials, the phishing site sends them to the web panel where the fraudster is waiting. This one actually notifies the scammers that a new victim is online. The scammers will lie waiting because the scammers need to react fast enough so they can then request the additional information that will help them to gain access to the bank accounts, two factor authentication tokens, and personal identifiable information (PII). While the phishing site is waiting for further instructions from the attackers, the unsuspecting victim is looking at a “Please wait…” screen.

The lures

The phishers themselves were free to set up methods to get their victims to the phishing sites that were designed to look exactly like the real, legitimate websites. Well-known tactics include phishing emails and texts that ask for urgent, but usually small payments as not to raise suspicion. Another is to act as an interested buyer on an online platform and ask for a 1 cent payment to verify that the seller is not a scammer.

The amount the scammers ask for is not relevant for the end-result as the scammers can enter any number they like on the real banking site while they wait for the victim to provide them with the necessary details.

Delay takedowns

Any successful phishing site will eventually get reported and taken down, or blocked. But the time that such sites stay alive can be prolonged by using certain precautions. The more important part of the service are the panels, and the Fraud Family offered a “plug and play” phishing service that kept the framework under control and prevented it from leaking to the public. By using anti-bot tools developers can prevent crawlers, automated analysis tools, and services like VirusTotal and URLScan from accessing the phishing sites, as well as make it harder for researchers to find them.

Mitigation

There are a few methods for victims to avoid phishing scams that could lead to emptied bank accounts. These are a few pointers to keep in mind:

• Be mindful when providing payment details even if you are only making a small payment. Behind the scenes someone could be altering the number.
• Always go to your banking site directly. Do not use a link provided in a mail or text. Save a shortcut in your browser if you find typing to cumbersome or if you want to avoid typo squatting.
• Double check the payment request with the party that sent it to you by using another method of communication.
• If someone, even if you think it’s one of your loved ones, sends you a text to tell you they have a new phone number, call them on the number you have on record to verify.
• Banks and other reputable organizations do not use URL shorteners when they send you a link.
• Check the information of the website in the address bar. The green padlock is needed but not enough.
• If you think you may be a victim of a phishing attack, quickly communicate with your bank, the organization being impersonated by the fraudsters, and the police. They can issue an alert which may help others and maybe limit the damage.
• Use a password manager. A password manager will not fill out your details if the website’s domain does not fit what it has on record.

For banks:

Do better 2FA than sending verification codes that can be passed along from victims to scammers. Dutch research last year showed that the customers of some banks fall victim more often than others and not because those banks are bigger. Instead, it is because they use less reliable 2FA methods. It’s a lot easier for a scammer to ask their victim for a 4 digit code than it is to get to show them a QR code. And this whole type of scam falls apart if the bank login procedure relies on a hardware key.

Stay safe, everyone!

The post Busted! Fraud-as-a-Service gang that sold 2FA-proof phishing arrested appeared first on Malwarebytes Labs.

Two months after fully restoring its systems, CNA Financial, the leading US insurance company that was attacked by a group using Phoenix CryptoLocker ransomware, issued a legal notice of an information security incident to the Consumer Protection Bureau in New Hampshire.

You may recall that Phoenix CryptoLocker—or simply Phoenix—is a ransomware family that is believed to be linked to the criminal group Evil Corp. CNA’s network was compromised in March 2021. This notice has given every reader an insight into how the attack happened, what CNA did, and what they continue to do for those whose data was affected by this ransomware-attack-slash-data-breach.

Phoenix posed as a browser update

According to CNA, one of its employees was able to download and execute a fake browser update after visiting a legitimate website. The notice didn’t specify if this legitimate website is the official website of the browser this employee is using. The employee not having elevated privileges didn’t stop the threat actors from following through with the attack. Instead, they used “additional malicious activity” to get credentials they need to move forward. Attackers often use privilege escalation exploits to increase their access rights, or tools like Mimikatz that can extract passwords from a computer’s memory.

“With elevated privileges, the Threat Actor moved laterally within the environment to conduct reconnaissance and establish persistence onto certain systems within the environment. Between March 5 and March 20, 2021, the threat actor conducted reconnaissance within CNA’s IT environment using legitimate tools and legitimate credentials to avoid detection and to establish persistence,” the company revealed.

Using legitimate administration tools and accounts in this way to explore a network and spread malware is know as “living off the land”. It allows attackers to keep a low profile as they go about their business because their activity doesn’t look out of place and their tools often aren’t detected by security software by default.

At least 15,000 systems, including devices connected to CNA’s network via VPN, were instantly affected after the threat actors detonated the ransomware.

Data stolen but untouched

CNA Prior to executing Phoenix, the threat actors were able to steal important and sensitive information affecting 75,349 individuals. A significant number of them were names of current and former employees plus their dependents and their Social Security Numbers (SSNs). On the other hand, a small number of those affected had their birth dates, benefit enrolment, and medical information.

As to how these were stolen, the threat actors “copied, compressed and staged unstructured data obtained from file shares found on three CNA virtual servers; and used MEGAsync, a legitimate tool, to copy some of the unstructured data (“Exported Data”) from the CNA environment directly into the threat actor’s cloud-based account (the “Mega Account”) hosted by Mega NZ Limited (“Mega”).”

According to CNA’s notice, it was able to work with the FBI and the “Cloud-Storage Platform” (presumably this means Mega) to “take control of the account and quickly recover CNA’s data”. CNA believes that the data was held so that the attackers could threaten to leak it, a common tactic in modern ransomware attacks. The company reports that its forensic experts could find no evidence that the data was “viewed or otherwise shared”; therefore, it was never accessed by the threat actors themselves to either be sold, traded, or used for other nefarious purposes.

Recovering from ransomware

This information coming to light two months after the attack shows that recovering from ransomware is rarely quick and easy. Aside from the obvious technical problems that have to be overcome to get a business working again, the root causes must be discovered and addressed, and there may be legal and regulatory hurdles to overcome.

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

The post CNA legal filings lift the curtain on a Phoenix CryptoLocker ransomware attack appeared first on Malwarebytes Labs.

This blog post was authored by Hasherezade

In mid-July we responded to an incident that involved an attack on a Microsoft Exchange server. The threat actor used this entry point to get into a Domain Controller and then leveraged it as a springboard to deploy ransomware.

While examining the ransomware payload, we noticed it was a new variant which we had not heard of before. In this blog we will take a look at AvosLocker a solid, yet not too fancy new ransomware family that has already claimed several victims.

This type of ransomware attack is unfortunately all too common these days and has wreaked havoc across many industries. With the disappearance of the infamous REvil, it is possible new threat actors are actively looking to fill the void.

New ransomware, looking for partners

Avos is a relatively new ransomware, that was observed in late June and early July. Its authors started searching for affiliates through various underground forums. They announced a recruitment for “pentesters with Active Directory network experience” and “access brokers” which suggests that they want to cooperate with people who have remote access to hacked infrastructure.

In the other advert they describe the product they offer: a multi-threaded ransomware written in C++:

They offer not only the malware, but also help in managing the communication with the victim, and hosting of the data stolen during the operation. Soon, some victims of this ransomware started to emerge.

Behavioral Analysis

AvosLocker is ran manually by the attacker who remotely accessed the machine. For this reason, it is not trying to be stealthy during its run. In default mode, it works as a console application reporting details about its progress on screen.

A sample log from the run (shortened):

 drive: C:
 drive: D:
 Threads init
 Map: C:
 Searching files on: C:*
 file: C:autoexec.bat
 Map: D:
 Searching files on: D:*
 FindFirstFileA: INVALID_HANDLE_VALUE
 drive D: took 0.002000 seconds
 Start encryption on C:
 Encrypting C:autoexec.bat - ext bat - capped YES
 Searching files on: C:_pin*
 file: C:_pinpinadx-vsextension-3.17.98314-g0c048d619.bat
 Start encryption on C:
 Encrypting C:_pinpinadx-vsextension-3.17.98314-g0c048d619.bat - ext bat - capped YES
[...]
Searching files on: C:Documents and Settings*
 FindFirstFileA: INVALID_HANDLE_VALUE
 Searching files on: C:$Recycle.Bin*
 […]
 drive C: took 52.590000 seconds
 Done!!
 64.620000 seconds

Looking at the log, we can see that the ransomware first “maps” the accessible drives by listing all their files. After that it goes to the encryption. The files are selected for encryption depending on their extensions.

The files that have been encrypted by AvosLocker can be identified with .avos extension appended to the original filename. While the content is unreadable, at the end we find a Base64-encoded block added:

We can assume that this Base64-encoded data contains RSA-protected AES key that was used for encrypting this file. Each attacked directory has a ransom note dropped in it, named GET_YOUR_FILES_BACK.txt:

Interestingly, the ID is not generated during the deployment, but hardcoded in the sample (which we can see easily by viewing the sample strings). This may mean that the distributors generate a sample per victim.

The link given in the ransom note guides to the Onion website, requesting the ID, that was also in the note:

Upon the ID submission, the victim is presented with the individual panel:

In addition to the casual threats about increasing the price after the deadline has passed, this ransomware adds blackmail by doxing. The additional website titled “Press releases” is provided to prove that those aren’t just empty threats:

Visual analysis

Visualizing the content of the encrypted files shows their high entropy. No patterns from the original file content were preserved. Example:

Those properties suggest that a strong encryption algorithm was used, probably in a CBC mode (Cipher Block Chaining).

Also, the same plaintext files have been encrypted into different ciphertext output. This suggests that for each file a new key (or at least a new initialization vector) was generated.

Inside

This ransomware is dedicated to be deployed by the attacker manually on the hacked machines. This purpose is reflected in the design. In contrast to most malware, AvosLocker comes without any protective (crypter) layer. Yet, it’s not completely defenseless: all the strings, and some of the APIs, are obfuscated in order to evade static detection. Yet, during its execution, it yells out on the console the logs of the performed actions, so that the attacker could observe in the real time what the program is doing.

Execution flow

The execution starts in the main function:

First, the malware checks if it was provided with the optional commandline arguments. By supplying them, the attacker can enable/disable some of the features.

Then, the mutex name is decoded (“ievah8eVki3Ho4oo”), and its presence is checked. It is done in order to prevent the ransomware from being run more than once at the time. If the mutex already exists, the execution terminates.

This malware may come with a hardcoded RSA Public Key of the attacker. This key will be further used for encrypting individual AES keys, used for encrypting files. Yet, the presence of the Public Key is optional. In case if it wasn’t provided, the application will generate a new key pair.

After this preparation, the malware proceeds to encrypt files. Depending on the argument given, it may encrypt network resources. Then, unconditionally, it encrypts drives. The encryption operations are run in new threads.

After the encryption was done, it prints information for the attacker. Then, all the running threads are finalized. At the end the malware prints the summary about how long it took to encrypt available resources.

Arguments

By default it runs as a console application, yet the console can be hidden by supplying a specific commandline argument: ‘h’ (hide). There is also a commandline argument allowing to opt out encryption of network resources: ‘n’ (network).

String obfuscation

As mentioned before, Avos uses string obfuscation. All the strings are obfuscated by XOR with the given key, and deobfuscated just before use. Although the algorithm is simple, the way it implements it is especially tedious to counteract. Rather than having one, central deobfuscating function, each of such operations is done inline. Examples:

API obfuscation

As well as the strings, some of the APIs used by the malware are obfuscated. Functions are retrieved by their checksums, which is a common trick used by malware, in order to avoid hardcoding names of the functions which may rise suspicions. Which is lesser common though, is that the function resolving the API is also used as an inline.

This way of obfuscating API calls not only hides the used functions, but also adds volume to the code, making it more unreadable and difficult to follow.

Yet, it is easy to reveal the used function names with the help of tracing and tagging. Example – the above obfuscated function resolved to GetLogicalDrives:

Attacked targets

The ransomware encrypts all attached drives.

Additionally, unless the argument (‘n’) was given from the commandline, the ransomware proceeds to encrypt network shares. Available resources are being enumerated in a loop:

The accessible network shares are getting encrypted:

From each medium, the files are first added to the list. Then, the created list is processed by the encryption routine.

Files with the following extensions are being attacked:

ndoc docx xls xlsx ppt pptx pst ost msg eml vsd vsdx txt csv rtf wks wk1 pdf dwg onetoc2 snt jpeg jpg docb docm dot dotm dotx xlsm xlsb xlw xlt xlm xlc xltx xltm pptm pot pps ppsm ppsx ppam potx potm edb hwp 602 sxi sti sldx sldm sldm vdi vmdk vmx gpg aes ARC PAQ bz2 tbk bak tar tgz gz 7z rar zip backup iso vcd bmp png gif raw cgm tif tiff nef psd ai svg djvu m4u m3u mid wma flv 3g2 mkv 3gp mp4 mov avi asf mpeg vob mpg wmv fla swf wav mp3 sh class jar java rb asp php jsp brd sch dch dip pl vb vbs ps1 bat cmd js asm h pas cpp c cs suo sln ldf mdf ibd myi myd frm odb dbf db mdb accdb sql sqlitedb sqlite3 asc lay6 lay mml sxm otg odg uop std sxd otp odp wb2 slk dif stc sxc ots ods 3dm max 3ds uot stw sxw ott odt pem p12 csr crt key pfx der dat

How the encryption works

Avos uses two strong encryption algorithms. Symmetric: AES – to encrypt files, and asymmetric: RSA – to encrypt the generated AES keys. This is a very common combo which provides strong data protection. It is also often used by variety of ransomware.

The RSA Key

As mentioned before, the RSA Public key may be hardcoded in the Avos sample. In the analyzed case, the following Public Key was hardcoded:

In case of lack of thereof, a new keypair is generated. The Public Key is stored for the further use, and the private key is logged on the screen, as the information for the attacker.

The same Private Key is also dumped in each ransom note, instead of the ID:

This suggests that this mode was created only for testing purposes, and it not intended to be used on victims. Only the mode with the Public Key hardcoded is usable in real attack scenarios.

File encryption

Before the malware proceeds to encrypt particular file, it first retrieves a list of associated processes, that may be blocking the access:

The list is retrieved with the help of RmGetList:

If any processes has been found, they are being terminated. Then the malware proceeds with encryption.

For each file, an AES key generated by a previously deployed routine is retrieved and used to initialize AES context.

After that, the AES encryption is applied on the file content.

The file is encrypted in-place (without creating additional copy), in 64-byte long chunks. A chunk of a plaintext is read, encrypted, and written back to the original file.

As we observed during the behavioral analysis, the block with the RSA encrypted, base64-encoded AES key is written at the end.

AES key generation

The generation of random keys is deployed in the function enumerating the files of a particular directory, prior to the encryption. For each listed file a new key and Initialization Vector are generated, and stored for further use.

As default, the cryptographically strong random generator is used. However, if for some reason this strong generator fails, it falls back to the naive generator (based on the standard rand() function).

This may render a flaw in the full encryption scheme. However, the chance of the strong random generator failing is too small to consider worth the attention in real life scenarios.

The malware fetches a buffer of 512 random bytes per each file, and then generates out of this a 64-character long string for the key, and a 32-characters long string for the Initialization Vector.

This key and the initialization vector are further passed to a function initializing AES context. Although the created key is 64 bytes long, we must note that only 32 first characters are going to be used. Similarly, in the case of the Initialization Vector, only first 16 bytes matter. Both strings are treated as ASCII.

Preview of the file encrypted with the presented key/IV set:

Example – a ChyberChief recipe decrypting the aforementioned file, using the key and initialization vector dumped from the memory:

Valid implementation, unimpressive design

AvosLocker does not distinguish itself much from other ransomware (apart from being unusually noisy). All its features are average. Its encryption scheme seems implemented correctly, so recovering the data is not possible without obtaining the original Private Key for a particular sample. It also uses a well-established pair of algorithms: RSA and AES. Although it contains some inconsistencies in the implementation, they do not impact the main goals of this malware.

We didn’t find in the sample any routines responsible for uploading the stolen files. Yet, since the model of the delivery of this ransomware assumes manual access, it is possible that the data exfiltration is done manually by the attackers.

AvosLocker meets its objective by being a simple tool assisting in the manual attacks, and creating the expected damage.

Protection and recommendations

• Keep software up-to-date and turn on automatic updates whenever possible
• Enforce strong password policies and multi-factor authentication (MFA)
• Perform backups and periodically test restoring them
• Reduce attack surface by removing unused or unnecessary services
• Mitigate brute-force attacks (this is a feature in our Nebula product) 
• Enable tamper protection to prevent attackers from uninstalling your security software (this is a feature in our Nebula product)

AvosLocker is detected without specific signatures by Malwarebytes’ anti-ransomware technology:

Indicators of Compromise

43b7a60c0ef8b4af001f45a0c57410b7374b1d75a6811e0dfc86e4d60f503856

The post AvosLocker enters the ransomware scene, asks for partners appeared first on Malwarebytes Labs.

A very serious security flaw in immensely popular printer drivers has been disclosed and it could affect many millions of Windows systems. The printer driver was issued by HP, but it’s also in use by Samsung and Xerox. All the affected printers are laser printers.

The most surprising about this find is probably that the vulnerability apparently has existed since 2005 and was only found 16 years later.

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. The vulnerability has been listed as CVE-2021-3438 and it is a potential buffer overflow in the software drivers that can be abused to achieve an escalation of privilege.

Vulnerabilities also often receive a severity rating on the CVSS scale. This vulnerability received an 8.8 out of 10 rating on the CVSS scale, which puts it in the high-severity range.

What is a buffer overflow?

A buffer overflow is a type of software vulnerability that exists when an area of memory within a software application reaches an address boundary and writes into an adjacent memory region. Buffer overflows can be used to overwrite useful data, cause network crashes, or replace memory with arbitrary code that the instruction pointer later executes.

In this case the buffer overflow can be used to get administrator permissions on the system as a normal user. So any attacker that wants to use this vulnerability will first need some kind of access to the system. But once they have access they can use the vulnerability to get permissions to install programs, view, change, or delete data, and encrypt files. The vulnerable driver is loaded when the systems boots, so the printer doesn’t even have to be connected to the system anymore for this vulnerability to work. Even worse, the user may not even be aware of the presence of the vulnerable driver.

Discovery

The vulnerability was discovered more or less by coincidence by researchers at SentinelLabs when they were configuring a brand new HP printer. In their post about the vulnerability they state:

“Many of these drivers come preloaded on devices or get silently dropped when installing some innocuous legitimate software bundle and their presence is entirely unknown to the users. These OEM drivers are often decades old and coded without concern for their potential impact on the overall integrity of those systems.”

After the discovery on Feb 18, 2021  the researchers engaged in an “open-ended process of vulnerability discovery.” Which means they spoke to vendors and manufacturers to makes sure the vulnerability had a patch before it could be exploited in the wild. So far as we know, this vulnerability has not been seen abused in the wild yet. But after disclosure and publication of the patches, which will no doubt be reverse engineered, this can happen anytime soon.

Mitigation

HP offers an update to patch the vulnerability. The immense list of affected products can be found at the HP site about the vulnerability. To obtain the update you can go to the HP Software site and search for your printer model, even if that is a Samsung model.

If there is an update for your printer you will see something similar to this after clicking on the Software, Drivers and Firmware button.

From there your can use the Download button to obtain the update and install it. If you are looking for the update because you have an affected Xerox laser printer you can visit the Xerox Support portal where it is available for download.

So far we have found three ssport.sys files that are vulnerable. If you are unsure whether you have such a file on your system check the ssport.sys file in your %windir%system32drivers directory. If it matches one of these SHA-256 hashes:

7cc9ba2df7b9ea6bb17ee342898edd7f54703b93b6ded6a819e83a7ee9f938b4

d3c763fb3f8ca7059a1d124e46014c9b578acef2fdc017f751642e2c66b7b8cc

789d98a3ad0c51e6d6ba6d907b4dbf96040ef244d71b8d53c95bb44ebc8f684b

it is a driver that pre-dates the date of the initial report, so it is very likely vulnerable and needs to be replaced.

Stay safe, everyone!

The post Millions of Windows machines affected by ancient printer vulnerability appeared first on Malwarebytes Labs.