Dec 5, 2017
Comments Off on Children and young adults: the next-generation money mules

Children and young adults: the next-generation money mules

According to Cifas, a nonprofit fraud prevention organization based in the United Kingdom, more than 8,500 cases of bank account misuse have been filed against 18- to 24-year-olds between January and September 2017. Cifas has linked the account abuse to an uptick in young people acting as money mules,  allowing their bank account to be used in order to facilitate the movement of criminal funds. The number of young people engaged in this kind of money laundering scheme doubled in the last four years, painting a troubling picture.

Earlier this year, the Metropolitan Police in the UK claimed that children as young as 13 years old have also been used by gangs or criminals to move stolen money on their behalf. The youngsters were either approached—often with threats of violence—right outside their schools, or they responded to adverts they saw on social media or video sharing sites that offered cash rewards of at least $67 (£50) for money transfer work. Some posts were even advertised as legitimate work under the likely titles of “Financial Manager,” “Monet transfer Agent,” or “Payment processing agent.”

Money mules (aka smurfers) usually get a cut from moving money, but it was found that youngsters were often never paid.

This worrying trend has inspired Cifas and Financial Fraud Action (FFA) UK to launch the Don’t Be Fooled campaign this week, aiming to educate would-be smurfers of the consequences of money muling.

This video sheds light on significant crimes that are enabled by money muling.

What children and young adults may not seem to realize is that money muling is a form of money laundering. Those caught could face imprisonment of up to 14 years. Their bank accounts will also be closed, their credit scores will likely reflect a low or poor rating, and they will face a significant challenge should they wish to apply for student loans, mobile phone contracts, and other products or services that require an account.

Parents and caregivers, if you opened an account for your child and she or he is active on social media, we urge you to monitor for money coming in and out from unknown sources. It may also be time to talk about them about money muling, what it is, and how it affects others—particularly, the victims of these crimes. Here are a few online sources to read so you can guide them on protecting themselves from being part of a criminal scheme:

Read: Stranger danger and the sociable child

Europol has a dedicated page for money muling awareness and prevention here. Cifas, too, has put out several resources, one of which is a flyer called A mule’s life is a fool’s life [PDF]. It contains a trove of information about who these criminals target when they go out to recruit mules, what tactics they use to trick their prospects, and what signs to watch out for if one is likely being led to such a scheme.

If you already believe that you or someone you know is acting as a money mule, cease transferring money immediately and notify your bank, the service you use in making the transactions, and law enforcement. Remember, one cannot claim ignorance when caught red-handed.

Sadly, money muling isn’t the only financial crime children and young adults could be exposed to. Other “easy money” schemes include selling bank accounts, conducting payments that they know will bounce, and opening credit or retail accounts and phone contracts without the intention of honoring the credit agreements.

“With Christmas only a few weeks away, we want to warn young people, in particular students, to be wary of anyone approaching them in the student union or elsewhere with promises of cash for the use of their bank account,” said Cifas Chief Executive Simon Dukes in a BBC interview. “Criminals may make it sound attractive by offering a cash payment, but the reality is that letting other people use your account in this way is fraud and it is illegal.”

Stay safe!

The post Children and young adults: the next-generation money mules appeared first on Malwarebytes Labs.

Powered by WPeMatico

Dec 4, 2017
Comments Off on Seamless campaign serves RIG EK via Punycode

Seamless campaign serves RIG EK via Punycode

The Seamless campaign is one of the most prolific malvertising chains pushing the RIG exploit kit and almost exclusively delivering the Ramnit Trojan. Identification of Seamless is typically easy, due to its use of static strings and an IP literal URLs. However, for over a week now we have been seeing another Seamless campaign running in parallel, making use of special characters.

Rather than using an IP address, this Seamless chain uses a Cyrillic-based domain name, which is transcribed into recognizable characters via Punycode, a visual representation of Unicode. In this blog post, we’ll do a quick historical review of the Seamless gate and describe this latest iteration in a new format.


We noted redirections via adult sites around March 2017 (as pictured below) that were going through a new gate targeting Canada. Due to the presence of the string of the same name in its code, Cisco named this new campaign “Seamless.” Seamless dropped the Ramnit banking Trojan from the very beginning and still continues to do so.

The URL patterns were typically:

These days, web traffic to Seamless still comes from adult portals serving malvertising, eventually redirecting to the same IP literal URLs containing the string test followed by three digits:

Seamless and Punycode

It wasn’t until recent years that domain registrars began to allow for non-English (ASCII) characters in domain names, defined by the Internationalized Domain Names (IDNs) for Applications framework. This allowed for countries to customize services with their own alphabets, which include what we’d otherwise call “special characters,” but have in fact existed long before the Internet was born.

Punycode is a representation of Unicode characters into ASCII used for hostnames, which allows for IDNs, while DNS lookups can still be performed using ASCII characters. The threat actors behind Seamless have been using a domain name containing Cyrillic characters (mostly found in Eastern European countries), which we noticed in our honeypot captures via its Punycode representation.

The call to the Seamless gate was initiated by a malvertising redirection:

It is worth noting that Punycode has been exploited by scammers crafting phishing domain names resembling official brands, as sometimes certain Unicode characters are hard to distinguish from ASCII ones.

It is unclear whether this was a deliberate attempt to bypass intrusion detection systems or if it is simply an odd case similar to previous ones such as the Decimal IP campaign. Time will tell if the Seamless operators maintain it or abandon it in favor of the long-used IP literal URLs.

Indicators of compromise (IOCs)

Note: These IOCs are specific to the Punycode Seamless campaign.


xn--80af6acaaaj9h .xn--p1acf/test441.php
xn--80af6acaaaj9h .xn--p1acf/test551.php

IP address:



The post Seamless campaign serves RIG EK via Punycode appeared first on Malwarebytes Labs.

Powered by WPeMatico

Dec 4, 2017
Comments Off on A week in security (November 27 – December 03)

A week in security (November 27 – December 03)

Last week on Labs, we touched on a huge macOS High Sierra vulnerability, a PayPal phish, and Terror EK’s new tactic. We also took a crack at identity theft protection services, drive-by cryptomining, and rounded up interesting talks while attending a security conference in Ireland called IRISSCON.

Other news

  • Our friends at Zimperium investigated a fake WhatsApp on Google Play, and found that this app displays an advertisement of a malicious game called Cold Jewel Lines (already removed from the Play Store) that further infects users with a second malware “capable of click fraud, data extraction, and SMS surveillance.” (Source: SC Magazine)
  • A question to parents: Should you buy your child smart toys for Christmas? Security experts say that whatever your decision is, make sure you read up on the potential risks first. (Source: Help Net Security)
  • Facebook users, rejoice! The social media network now has a tool that tells you which posts you have liked that are mere propaganda from Russia. (Source: Facebook Newsroom)
  • Imgur confirmed that they have been breached for the second time, affecting 1.7 million users. Email addresses and passwords were compromised. (Source: Help Net Security)
  • Finally, the “revenge porn” bill is introduced in the Senate. (Source: TechCrunch)
  • Vice’s Motherboard released a guide to avoiding (passive and active) state surveillance, which can be a handy reference to those who want to achieve more privacy online. (Source: The Motherboard)
  • What do hotcakes and ransomware have in common? They’re both selling. (Source: Security Brief)
  • Fake Victoria’s Secret apps are found being advertised on the Dark Web, prompting security experts to posit that criminals may be targeting VS shoppers this Christmas season. (Source: The Telegraph)
  • Afraid of insider threats? According to NTT security, most of them happen by accident. (Source: Help Net Security)
  • Cryptocurrency is more popular than ever at this point. This, of course, sprung up the creation of cryptocurrency apps. Be warned, though: a majority of these popular apps do not protect user information. (Source: Kroddos)

Stay safe everyone!

The post A week in security (November 27 – December 03) appeared first on Malwarebytes Labs.

Powered by WPeMatico

Dec 4, 2017
Comments Off on Yet another flaw in Apple’s “iamroot” bug fix

Yet another flaw in Apple’s “iamroot” bug fix

Last week, we discussed a particularly serious vulnerability, dubbed “iamroot,” in macOS 10.13 (High Sierra). To sum up, the vulnerability allows an attacker to gain access to the ultra-powerful root user on any Mac running macOS 10.13.0 or 10.13.1. Worse, the vulnerability can be exploited remotely if screen sharing is turned on.

Security Update 2017-001

In response to this, Apple quickly pushed a fix out the door in the form of Security Update 2017-001. Confusingly, Apple has already released a Security Update 2017-001 several times. It released two back in March, for macOS 10.9 and 10.10 (Yosemite and El Capitan). It released another in October for macOS 10.11 (Sierra). Yes, you read that right…Apple’s using the same name for unrelated security fixes for different versions of the system.

Okay, back to the fix. Security Update 2017-001—the one for High Sierra—was released to fix the “iamroot” bug, and it was released for both macOS 10.13.0 and 10.13.1. Because of the severity of the problem, this update was pushed out automatically. In other words, if you don’t install it right away, it will be installed automatically after a fairly short interval. It’s a quick install and doesn’t require a reboot.

Great, the bug is fixed. We can all go home now! Wait, what’s that you say, Bob? Something’s wrong with file sharing?

Apparently, Apple’s first attempt at fixing the bug had a problem. Specifically, it made file sharing stop working. So if you relied on being able to use file sharing to move files from one Mac to another, this update wreaked havoc with your workflow.

Security Update 2017-001 2.0

Apple quickly released a technical note about the file sharing problem, and how to fix it, and then re-issued Security Update 2017-001. Yup, that’s a second Security Update 2017-001, not Security Update 2017-002. Thus, people who had already installed Security Update 2017-001 found themselves wondering why they had to install it again. Fortunately, again, the update was automatic. So if you didn’t do it manually, your confusion wasn’t going to keep you from getting the update.

Great, now everything’s fixed. Time to go home for real. Sorry, Bob. You’re going to have to go back to your desk in IT. You’ve got another problem to deal with now. Take note of the fact that this second update increments the build number of macOS to 17B1003. This will be important later.

Remember how we said that Security Update 2017-001 could be applied to both macOS 10.13.0 and 10.13.1? What happens if you install the update on 10.13.0, then update later to 10.13.1? Turns out, it’s bad.

If you install Security Update 2017-001 on 10.13.0, then update to 10.13.1, the bug will re-emerge. The process of installing the 10.13.1 undoes the fix that was applied by Security Update 2017-001, making the machine vulnerable to the “iamroot” bug again.

Of course, Security Update 2017-001 exists for 10.13.1 as well, and will be automatically re-applied sometime after the 10.13.1 update. Crisis averted, right? Bob, you’re really going to have to stop jumping out of your chair every couple paragraphs. I know you want to go home, but unfortunately, there’s still a problem.

You’ve upgraded from 10.13.0 to 10.13.1. You’ve installed Security Update 2017-001. And you’ve verified that you’re running macOS 10.13.1 build 17B1003 (which you can do by choosing About This Mac from the Apple menu and clicking the version number in the window that opens). Unfortunately, you are still vulnerable!

How to fix the problem

So, to sum up, what we’ve described above involves the following steps:

  1. Install Security Update 2017-001 on macOS 10.13.0
  2. Update to macOS 10.13.1
  3. Install Security Update 2017-001 again
  4. Verify that you’re running macOS 10.13.1 build 17B1003

After doing this, you should be safe from “iamroot.” However, in reality, an attacker would still be able to trigger the original vulnerability and gain root access.

It turns out that restarting the computer will fix the problem, with no further changes needed. This begs the question, though: Why is this necessary? After all, Security Update 2017-001 doesn’t normally require a restart. Why is one required in this specific case?

Since the update doesn’t require a restart, and since many Mac users can be rather averse to restarting, this means that people upgrading from 10.13.0 to 10.13.1 could easily end up being vulnerable to this bug for weeks or months, until they next decide to restart. Keep in mind that nearly all 10.13.0 users have probably already had Security Update 2017-001 installed automatically at this point, putting them into a pipeline heading straight for this issue.

Over the weekend, Apple released a fix and added a mention of the problem to their notes on Security Update 2017-001. Rather than releasing yet another iteration of Security Update 2017-001, Apple added a fix to the MRT application. MRT, which stands for Malware Removal Tool, is not something Apple talks about, and little is known about exactly how it works. It is known, though, that MRT is designed to remove malware that has already infected the system.

If you’re wondering why Apple would release a fix for this bug in MRT, that’s an excellent question. It doesn’t seem to make much sense and feels a bit like a hack to me. My guess is that MRT was something that could be easily and quietly updated, so that’s what they did.

A series of unfortunate events

Now, to be fair, Apple reacted to the original vulnerability quickly, and any rushed fix has a risk of problems. However, this isn’t an isolated incident, and it has Apple fans worried.

In October, there was a problem with certain authentication dialogs revealing the password in the place of the password hint. That has been followed up with the “iamroot” bug and an embarrassing series of buggy responses, which prompted Apple to issue a rare public apology. Now, the latest response to the bugs in the “iamroot” fixes feels more like a hack meant to go unnoticed than anything else.

On top of all that, this weekend, Apple released iOS 11.2 on a Saturday (which is unusual), apparently to address a problem that caused many iOS devices to start crashing on December 2 after 12:15 am. This suggests that the iOS 11.2 release was probably rushed, and time will tell whether there are any issues with the update as a result.

This has many worried about what’s going on at Apple these days. I’ve been using Apple products since 1984, and I’ll be honest: I’m worried about the future of the Mac. Admittedly, I’m not as worried as I was back in the 90s, when Apple was floundering and looked like it could go out of business. However, I do hope that Apple is able to put some of its vast resources to the task of improving the quality assurance process and reverse the worrying trend of increasing bugginess of macOS releases.

The post Yet another flaw in Apple’s “iamroot” bug fix appeared first on Malwarebytes Labs.

Powered by WPeMatico

Dec 1, 2017
Comments Off on PayPal phish asks to verify transactions—don’t do it

PayPal phish asks to verify transactions—don’t do it

There’s a number of fake PayPal emails going around right now claiming that a recent transaction can’t be verified. If your response to this is, “What transaction?” read on. If your response to this is, “Oh no, not my recent transaction!” you should still read on. Why? Because scammers have both eyes and at least one virtual hand on your cash, assuming you follow their direction.

Here’s two examples of how these mails are being named from one of our mailboxes:

paypal phish mails

Click to enlarge

[New Transaction Statements] we’re letting you know : We couldn’t verify your recent transactions

[New Activity Statements] [Account Hold] Re : Your payments processed cannot completed

Here’s the most recent email in question:

paypal phish mail

Click to enlarge

We couldn’t verify your recent transaction Dear Client,We just wanted to confirm that you’ve changed your password. If you didn’t make this change, please check information in here. It’s important that you let us know because it helps us prevent unauthorised persons from accessing the PayPal network and your account information.
We’ve noticed some changes to your unsual selling activities and will need some more information about your recent sales.

Verify Information Now
Thank you for your understanding and cooperation. If you need further assistance, please click Contact at the bottom of any PayPal page.Sincerely,PayPal

Clicking the button takes potential victims to a fake PayPal landing page, which tries very hard to direct them to a “resolution center.” The URL is:


fake paypal landing page

Click to enlarge

ΡayΡaI is constantly working to ensure security by regularly screening the accounts in our system. We recently reviewed your account, To help us
provide you with a secure service. We would like to return your account to regular standing as soon as possible. We apologise for the inconvenience.
Why is my account access limited?

Your account access has been limited for the following reason(s)

December 1, 2017: We notice some unusualy activity on your PayPaI account.

As a security precaution to protect your account until we have more details from you, we’ve place a limitation on your account
( Your case ID for this reason is PP-003-523- 280- 570 )
How can I help resolve the issue on my account?

It’s usually easy to resolve issues like this. Most of the time, we just need a little more information about your account transactions
To help us resolve this issue, please log in to your account and go to the ResoIution Center to find out what information
You need to provide. We’ll review the information you provide and email you if we need more details.
Completing all the checklist items will automatically restore your account access.

From here, it’s a quick jump to two pages that ask for the following slices of personal information and payment data:

  1. Name, street address, city, state, zip, country, phone number, mother’s maiden name, and date of birth
  2. Credit card information (name, number, expiration code, security code)

paypal phish website personal info request

Click to enlarge

paypal phish website card request

Click to enlarge

Sadly, anyone submitting their information to this scam will have more to worry about than a fictional declined payment, and may well wander into the land of multiple actual not-declined-at-all payments instead. With a tactic such as the above, scammers are onto a winner—there’ll always be someone who panics and clicks through on a “payment failed” missive, just in case. It’s an especially sneaky tactic in the run up to December, as many people struggle to remember the who/what/when/where/why of their festive spending.

Whatever your particular spending circumstance, wean yourself away from clicking on any email link where claims of payment or requests for personal information are concerned. Take a few seconds to manually navigate to the website in question. and log in directly instead. If there are any payment hiccups happening behind the scenes, you can sort things out from there. Scammers are banking on the holiday rush combined with the convenience of “click link, do thing” to steal cash out from under your nose.

Make it an (early) New Year’s resolution to make things as difficult for the scammers as possible. You can report PayPal phishing attempts here. And if in doubt, at least delete the email.

The post PayPal phish asks to verify transactions—don’t do it appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 30, 2017
Comments Off on An IRISSCON 2018 roundup

An IRISSCON 2018 roundup

Last week, some 400-plus attendees listened to a wide variety of infosec topics at the ninth annual IRISSCON, Ireland’s longest-running security event.

I already talked a fair bit about this one a few weeks back, so rather than repeat myself, I’ll let the videos do the talking. First up, the Keynote:

Next, a great and brutally honest talk by Quentyn Taylor about the day-to-day dealings of a CISO. Humorous and filled with truth bombs—What could be better?

Back in July, I gave my Mahkra ni Orroz talk at SteelCon, and I was lucky enough to give a retooled version for IRISSCON, now with revised slides, additional content, extra information, and a few of the wrinkles mentioned in this blog post ironed out.

If you want a good introduction to the world of physical security and social engineering your way into places you shouldn’t be, then this talk by FreakyClown will likely be just what the tailgating doctor ordered:

The tale of how Lee Munson got into security—and stayed there—is definitely worth checking out, especially as it shines a light on how many people with no security qualifications make valuable contributions to the industry.

A splash of human nature to go with your computer security, courtesy of Dr. Jessica Barker:

There’s a few pieces of coverage for the event over on The Register [1], [2], [3], and you can catch the rest of the talks on the official IRISSCERT Youtube channel.

The post An IRISSCON 2018 roundup appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 29, 2017
Comments Off on Persistent drive-by cryptomining coming to a browser near you

Persistent drive-by cryptomining coming to a browser near you

Since our last blog on drive-by cryptomining, we are witnessing more and more cases of abuse involving the infamous Coinhive service that allows websites to use their visitors to mine the Monero cryptocurrency. Servers continue to get hacked with mining code, and plugins get hijacked and affect hundreds or even thousands of sites at once.

One of the major drawbacks of web-based cryptomining we mentioned in our paper was its ephemeral nature compared to persistent malware that can run a miner for as long as the computer remains infected. Indeed, when users close their browser, the cryptomining activity will also stop, thereby cutting out the perpetrators’ profit.

However, we have come across a technique that allows dubious website owners or attackers that have compromised sites to keep mining for Monero even after the browser window is closed. Our tests were conducted using the latest version of the Google Chrome browser. Results may vary with other browsers. What we observed was the following:

  • A user visits a website, which silently loads cryptomining code.
  • CPU activity rises but is not maxed out.
  • The user leaves the site and closes the Chrome window.
  • CPU activity remains higher than normal as cryptomining continues.

The trick is that although the visible browser windows are closed, there is a hidden one that remains opened. This is due to a pop-under which is sized to fit right under the taskbar and hides behind the clock. The hidden window’s coordinates will vary based on each user’s screen resolution, but follow this rule:

  • Horizontal position = ( current screen x resolution ) – 100
  • Vertical position = ( current screen y resolution ) – 40

If your Windows theme allows for taskbar transparency, you can catch a glimpse of the rogue window. Otherwise, to expose it you can simply resize the taskbar and it will magically pop it back up:

A look under the hood

This particular event was caught on an adult site that was already using aggressive advertising tricks. Looking at the network traffic, we can see where the rogue browser window came from and what it loaded.

The pop-under window (elthamely[.]com) is launched by the Ad Maven ad network (see previous post about bypassing adblockers), which in turn loads resources from Amazon (cloudfront[.]net). This is not the first cryptominer being hosted on AWS, but this one does things a little bit differently by retrieving a payload from yet another domain (

We notice some functions that come straight from the Coinhive documentation, such as .hasWASMSupport(), which checks whether the browser supports WebAssembly, a newer format that allows users to take full advantage of the hardware’s capability directly from the browser. If it doesn’t, it would revert to the slower JavaScript version (asm.js).

The WebAssembly module (.wasm) is downloaded from hatevery[.]info and contains references to cryptonight, the API used to mine Monero. As mentioned above, the mining is being throttled to have a moderate impact on users’ machines so that it stays under the radar.


This type of pop-under is designed to bypass adblockers and is a lot harder to identify because of how cleverly it hides itself. Closing the browser using the “X” is no longer sufficient. The more technical users will want to run Task Manager to ensure there is no remnant running browser processes and terminate them. Alternatively, the taskbar will still show the browser’s icon with slight highlighting, indicating that it is still running.

More abuse on the horizon

Nearly two months since Coinhive’s inception, browser-based cryptomining remains highly popular, but for all the wrong reasons. Forced mining (no opt-in) is a bad practice, and any tricks like the one detailed in this blog are only going to erode any confidence some might have had in mining as an ad replacement. History shows us that trying to get rid of ads failed before, but only time will tell if this will be any different.

Unscrupulous website owners and miscreants alike will no doubt continue to seek ways to deliver drive-by mining, and users will try to fight back by downloading more adblockers, extensions, and other tools to protect themselves. If malvertising wasn’t bad enough as is, now it has a new weapon that works on all platforms and browsers.

Indicators of compromise,yourporn[.]sexy,Adult site,elthamely[.]com,Ad Maven popunder,d3iz6lralvg77g[.],Advertiser's launchpad,hatevery[.]info,Cryptomining site

Cryptonight WebAssembly module:


The post Persistent drive-by cryptomining coming to a browser near you appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 29, 2017
Comments Off on Serious macOS vulnerability exposes the root user

Serious macOS vulnerability exposes the root user

Update: 9:29 am PT: Apple has now released a fix for the bug described here. That fix is part of Security Update 2017-001, which is available from the Mac App Store, in the Updates tab, with the label “Install this update as soon as possible.” (Somewhat confusingly, there have already been previous Security Update 2017-001 releases, for unrelated issues, for Sierra, El Capitan and Yosemite.) This update should be installed as soon as possible, and does not require a restart.

On Tuesday afternoon, a tweet about a vulnerability in macOS High Sierra set off a firestorm of commentary throughout the Twitterverse and elsewhere.

It turns out that the issue in question works with any authentication dialog in High Sierra. For example, in any pane in System Preferences, click the padlock icon to unlock it and an authentication dialog will appear. Similarly, if you try to move a file into a folder you don’t have access to, you’ll be asked to authenticate:

Enter “root” as the username, and leave the password field blank. Try this a few times, and it may work on the first try, but more likely you’ll have to try two or a few more times.

When the authentication window disappears, whatever action you were attempting will be done, without any password required.

Let’s take a step back for just a moment and consider what this means. On a Unix system, such as macOS, there is one user to rule them all. (One user to find them. One user to bring them all and in the darkness bind them. /end obligatory nerdy Lord of the Rings reference>)

That user is the “root” user. The root user is given the power to change anything on the system. There are some exceptions to that on recent versions of macOS, but even so, the root user is the single most powerful user with more control over the system than any other.

Being able to authenticate as the root user without a password is serious, but unfortunately, the problem gets worse. After this has bug has been triggered, it turns out you can do anything as root on the first try, without a password.

The root user, which has no password by default, is normally disabled. While the root user is disabled, it should not be possible for anyone to log in as root. This is how macOS has worked since day one, and it has never been an issue before, but this vulnerability causes the root user to become enabled… with no password.

Unfortunately, this means that anyone will be able to log into your Mac using user “root” and no password!

Note that this does not require that the login window be set to always ask for a username and password. If you have it set to display a list of user icons instead, after triggering this vulnerability, there will be an “Other…” icon that will be present on the login screen. Clicking that will allow you to manually enter “root” with no password.

Remote access

This bug does not appear to be exploitable through some of the remote access services that can be enabled in the Sharing pane of System Preferences. Remote Login, which enables access via SSH, does not appear to be exploitable in our testing, nor does File Sharing. Even after triggering the bug and, thus, enabling the root user with no password, we were not able to connect to the vulnerable Mac through these methods.

Unfortunately, it looks like Screen Sharing, which allows you to view and remotely control the screen of your Mac, is vulnerable to this bug. In fact, it can actually be used to trigger this bug, without needing to rely on the root user already having been enabled!

In the screen sharing authentication window on a remote Mac, the same technique can be used. We were able to connect via screen sharing, using “root” as the username and no password, on the second attempt. At that point, the root user was enabled on the remote Mac, and we were able to log in to the root account via screen sharing without any blatant indication that we were doing so appearing on the screen shown to the logged in user on the target Mac. (An icon does appear in the menu bar on the target Mac, but it is not immediately obvious what that icon means. The average user will likely never notice the new icon.)

Unforeseen consequences

Once someone is logged into your Mac as root, they can do whatever they want, including accessing your files, installing spyware, you name it. So, in other words, if you were to leave your Mac unattended for 30 seconds, someone could backdoor it and have a very powerful way in later.

Suppose that you are Suzy, an average office worker in a cubicle farm. You step away from your desk for a moment to grab a cup of coffee. You’ll only be gone for about a minute, and don’t bother locking your screen. While you’re gone, Bob from the next cubicle comes over and “roots” your computer.

Later, you go to lunch. You’re gone for an hour, and Bob knows this because he’s familiar with your routine. He uses the root user to log into your Mac and install spyware—perhaps something to peep through the webcam, hoping to catch you in a compromising position later on when you’ve taken your MacBook Pro home with you.

Of course, all that’s even easier if you have screen sharing turned on, and he can install the spyware remotely, without ever touching your Mac.

Creeped out yet?

Fortunately, if you have your Mac’s hard drive encrypted with FileVault, this will prevent the attacker from having a persistent backdoor. In order to log in, the attacker would have to know the password that will unlock FileVault. Not even the all-powerful root user can access an encrypted FileVault drive without the password.

It’s also worth pointing out that a well-prepared attacker with access to your unlocked Mac could install spyware in less than a minute without relying on this vulnerability and without needing an admin password of any kind (depending on what the spyware does). Some spyware can be installed with normal user privileges.

Further, with a longer interval of unsupervised physical access to any Mac that doesn’t have FileVault turned on, an attacker can install spyware of any kind without needing an admin password.

Avoiding an attack using this vulnerability is actually fairly trivial. Just turn on FileVault, and always lock your Mac’s screen or log out when you’re away from it. While you’re at it, set a firmware password. And, to prevent remote access, turn off all services in System Preferences -> Sharing as a precaution.

Still, this is a very serious vulnerability, which Apple needs to address as quickly as possible. We contacted Apple for comment, but by the time of this writing, had not heard back.

Undoing the damage

If you, like many, have tried this out on your own Mac, you’ve opened up a potential backdoor. Fortunately, closing that door isn’t particularly hard, if you know the door is there and that it’s open.

First, open the Directory Utility application. It’s buried deep in the system where it’s hard to find, but there’s an easy way to open it. Just use Spotlight. Click the magnifying glass icon at the right side of the menu bar, or press command-space, to invoke Spotlight. Then start typing Directory Utility in the search window. Once the application is found, simply double-click it in the list to open it. (Or, even easier, press return once it’s selected in the search results.)

Once Directory Utility opens, click the lock icon in the bottom left corner of the window to unlock it. Then, pull down the Edit menu.

If you see an item reading Enable Root User, as shown in the screenshot above, you’re good. Whatever you did, the root user wasn’t enabled. Quit Directory Utility, and go about your business.

If, instead, you see an item reading Disable Root User, choose that. The root user will be disabled again, as it should be, and it will no longer be possible to log in as the root user from the login screen. Just be aware that this does nothing to protect against the vulnerability, so the root user could easily be enabled again.

Be sure to take the other measures described above to secure your system against unauthorized physical access. Namely,  turn on FileVault, always lock your Mac’s screen or log out when you’re away from it, set a firmware password, and turn off all services in System Preferences -> Sharing.

The post Serious macOS vulnerability exposes the root user appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 28, 2017
Comments Off on Please don’t buy this: identity theft protection services

Please don’t buy this: identity theft protection services

With an ever-increasing tempo of third-party breaches spilling consumer data all across the dark web, a natural impulse for a security-savvy user is to do something proactive to protect their sensitive information. After Equifax, there was an explosion of interest in credit monitoring and identity theft protection services. But most of these services offer limited value for the money, and in many cases, are subsidiaries of entities prone to leaking information in the first place. Sometimes doing something isn’t always the best option.

What do they do?

Before we get into the problems with identity theft protection services, let’s break down which services are actually offered, and in exchange for what. Identity protection services usually start by collecting your personal information, including the following:

  • your birthdate
  • your social security number
  • your address
  • your email address(es)
  • your phone number(s)

A company like Lifelock would then use “proprietary technology that searches for a wide range of threats to your identity.” (Sidenote: Subsuming an entire discussion of one’s product under “technology that searches” is usually a red flag, albeit a small one.) If any threats are found, they will notify you and provide some handholding to rectify the situation. In addition, they offer an insurance policy that provides reimbursement of any monetary losses. Starting price for these services runs around $109 per year.

IdentityWorks is another service run by one of the major credit bureaus, Experian. IdentityWorks has an introductory product for $9.99 per month that offers credit monitoring, a credit lock (something different from a freeze), identity theft insurance, and a customer service line for fraud resolution.

IdentityForce tends to be ranked higher in comparison to other services. They provide credit monitoring, bank account monitoring (not found in most other products), change of address monitoring, court record monitoring, as well as general personal information protection. Their recovery services are mostly the same though, including a customer service line for fraud resolution, identity theft protection insurance, and stolen funds replacement up to $1 million, depending on where you live. Standard cost is $17.95 per month.

Why shouldn’t I buy it?

Brian Krebs, a security researcher who’s arguably one of the biggest public targets for identity theft and financial crime, wrote a blog on credit monitoring services, stating that while some of these and other ID protection services are helpful for those who’ve already been snaked by ID thieves, they don’t do much to prevent the crime from happening in the first place.

Searching the darknet for your personal information is something advertised by almost all of these companies. What they don’t disclose is that a darknet site is almost always hosted on a “bulletproof” hosting service that will not respond to takedown requests or legal threats. So while essentially anybody can fire up the TOR browser and find your social security number on a dark website, almost nobody (including those in ID protection services) can actually do anything about it. All they can do is alert you.

Our big issue with paying for an identity theft protection service—besides the fact that the service doesn’t actually protect against identity theft—is that the insurance you would be forking out for is coverage most users already have under Visa and Mastercard zero liability rules. Another is the narrow focus on credit, typically to the exclusion of bank accounts, mortgage loans, and tax fraud. Lastly, account application notifications can’t actually prevent creditors from doing a “hard pull” on your credit, which dings your credit score.

Who else is looking at your data?

Somewhat more concerning is the lack of transparency concerning where these companies draw their data for analysis and alerting. Lifelock, in particular, outsources its credit monitoring services to… Equifax. In September of this year, the LA Times reported the relationship with Lifelock and Equifax, noting that in some instances, purchasing services would require the end user to give Equifax more information than it would otherwise have.

Does anyone, anywhere, want to give more personal data to Equifax?

How many competing companies also rely on the credit bureaus for monitoring services? While Equifax was the loudest and most recent breach in memory, odds are good that the other credit bureaus operating on an identical business model have identical security practices. As a reminder, Experian offers its own service, IdentityWorks, backed by data services it does not disclose and personal information you did not consent to give.

As well as the red flags above, there’s some slightly more ambiguous questions regarding these services that users should evaluate before purchase. For example: Is it a responsible threat model to protect against third-party data breaches by handing over, even more, data to a third party? Doesn’t that create ostensibly the biggest online target in the world?

And looking at the problem from another angle: If the biggest players in the industry rely on agreements with credit bureaus to do at least a portion of their monitoring, why aren’t the bureaus doing this for all of us? Given that Transunion, Equifax, and Experian took it upon themselves to collect our financial data without consent, don’t they have a responsibility to protect it with industry standard best practices? As a reminder, Equifax was not breached by an arcane APT attack. They were breached by negligence.


Identity theft monitoring services sound great on the surface. They’re not that expensive and seem to provide peace of mind against an avalanche of ever-more damaging breaches. But they don’t, at present, protect against the worst impacts of identity theft—the theft itself. Instead, they duplicate free services and, worst of all, let the credit bureaus off the hook for improving their security.

Please don’t buy this. Instead, you can stay relatively safe by learning about credit freezes and other steps to take in order to protect your identity when data is stolen or tax fraud is committed.

The post Please don’t buy this: identity theft protection services appeared first on Malwarebytes Labs.

Powered by WPeMatico

Nov 27, 2017
Comments Off on Terror exploit kit goes HTTPS all the way

Terror exploit kit goes HTTPS all the way

We’ve been following the Terror exploit kit during the past few months and observed notable changes in both its redirection mechanism and infrastructure, which have made capturing it in the wild a more challenging task.

Unlike the RIG exploit kit, which uses predictable URI patterns and distribution channels, Terror EK is constantly attempting to evade detection by using malvertising chains without any static upper referrers (at least to our knowledge) combined with multi-step filtering in some cases, as well as HTTPS throughout the delivery sequence.

Traffic redirection

We’ve noticed consistent malvertising incidents via the Propeller Ads Media ad network, followed by the advertiser’s campaign, which we were able to recognize through URI patterns and other identifying creative choices. Ultimately, the ad redirected to the exploit kit’s first check-in page, which acts as both a decoy and launchpad.

Over time, the threat actors behind Terror have been trying to hide the call to the exploit kit. In one example, they created overly long URLs and used obfuscation to mask their iframe. Interestingly, in other sequences, we witnessed an additional type of filtering that uses unique subdomains. The user is first taken to a page whose current theme is cheap flights and hotels, containing what looks like an affiliate link to the travel site

But the main point of focus here is the additional invisible iframe, created with a unique 15-digit subdomain and refreshed for each new visit:

This iframe is what creates the final call to the exploit kit landing page. We believe this setup may be to prevent replays that attempt to step over the normal redirection flow, although it was only used for a short period of time.

HTTPS all the things

In late August 2017, we saw Terror EK make an attempt at HTTPS by using free SSL certificates, although it kept switching back and forth between HTTP and HTTPS. At times, there also seemed to be problems with domains that had the wrong certificate:

However, in recent days we’ve observed a constant use of SSL, not only for the exploit kit itself but also at the upper redirection stage.

This is what the traffic looks like using a customized version of the Fiddler web debugger set up as a man-in-the-middle proxy:

Without using a MITM proxy, network administrators will see the SSL handshake with the corresponding server’s IP address, but not the full URIs or content being sent:

Terror EK is one of few exploit kits to have used SSL encryption this year, the other well-documented one being Astrum EK, used in large malvertising attacks via the AdGholas group. Also, unlike RIG EK, which appears to have permanently switched to IP literal URIs after operation ShadowFall, Terror is making full use of domains using new/abused TLDs.

As usual, Terror EK is dropping Smoke Loader, which in turn downloads several more payloads, likely to generate a lot of noise on the network:


Despite no significant advancement with more powerful vulnerabilities being integrated, exploit kit authors are nonetheless still leveraging malvertising as their primary distribution method and attempting to evade detection from the security community, which they monitor closely.

In light of these new challenges, security defenders must also understand the malicious techniques that are used by threat actors in order to adapt their tools and procedures and keep tracking the new campaigns taking place.

Indicators of compromise

Terror EK-related IP addresses and domains:

SSL certificates:

CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US

[Serial Numbers]



Smoke Loader


Other drops:


The post Terror exploit kit goes HTTPS all the way appeared first on Malwarebytes Labs.

Powered by WPeMatico


Location and hours

Txt/Email or CALL NOW to discuss your recovery plan.
Computer repair association logo