NEWS

WastedLocker is a new ransomware operated by a malware exploitation gang commonly known as the Evil Corp gang. The same gang that is associated with Dridex and BitPaymer.

The attribution is not based on the malware variants as WastedLocker is very different from BitPaymer. What was kept was the ability to add specific modules for different targets.

The attacks performed using WastedLocker are highly targeted at very specific organizations. It is suspected that during a first penetration attempt an assessment of active defenses is made and the next attempt will be specifically designed to circumvent the active security software and other perimeter protection.

The ransomware name is derived from the filename it creates which includes an abbreviation of the victim’s name and the string “wasted”.

For each encrypted file, the attackers create a separate file that contains the ransomware note. The ransom note has the same name as the associated file with the addition of “_info”.

The ransom demands are steep, ranging from $500,000 to over $10 million in Bitcoin. Given that the operators make every effort to go after any backups, some organizations may feel the need to pay up. Where other ransomware operators are adding the exfiltration and even auction of stolen data to their arsenal, the Evil Corp gang has shown no inclination in that direction yet.

Historically the Evil Corp gang targets mostly US organizations and it looks like they are staying on that track with a few victims in Europe. The main players in the group are believed to be Russian.

The importance of offline backups

In general, we can state that if this gang has found an entrance into your network it will be impossible to stop them from encrypting at least part of your files. The only thing that can help you salvage your files in such a case is if you have either roll-back technology or a form of off-line backups. With online, or otherwise connected backups you run the chance of your backup files being encrypted as well, which makes the whole point of having them moot. Please note that the roll-back technologies are reliant on the activity of the processes monitoring your systems. And the danger exists that these processes will be on the target list of the ransomware gang. Meaning that these processes will be shut down once they gain access to your network.

As you may have noticed this is a very sophisticated and highly targeted type of ransomware. Which means that, given the ransom demands, most of the affected companies will have a dedicated cyber- security department. It is imperative that this staff is alert on the early warning signs of these attacks which may be indicated by breach attempts. At later stages more disruptive actions may be taken, such as disabled security software, dropped files, and deleted backups

Unlike other ransomware operators Evil Corp does not exfiltrate stolen data and publish or auction the data that belong to “clients” that are unwilling to pay the ransom.

Infection details

One of the methods found to date is the usage of fake software update alerts embedded in existing websites.

The malware from these websites is a penetration testing and exploration kit designed to create a foothold and gather information about the network. Historically Evil Corp has targeted file servers, database services, virtual machines, and cloud environments.

Once the exploration phase has completed the gang will drop the ransomware on the compromised systems.

The ransomware itself is custom built for each client so there is nothing to be gained by doing a full analysis. The attacks do have some commonalities though which we will discuss here.

• Deletes shadow copies, which are the default backups made by the Windows OS.
• The main executable for the ransomware is copied to the system folder and gets elevated permissions
• A service is created that runs during encryption.
• During encryption the encrypted files are renamed, and the ransom notes are created.
• A log file is created that lists the number of targeted files, the number of encrypted files, and the number of files that were not encrypted due to access rights issues.
• The service is stopped and deleted.

Overview

• WastedLocker has been actively deployed since May 2020.
• Evil Corp behind: this group previously associated to the Dridex malware and BitPaymer aka IEcrypt aka FriedEx aka WastedLocker.
• Evil Corp has been using WastedLocker to request ransoms in the range of millions of USD, with some demands going above $10 million.
• WastedLocker replaces BitPaymer in the group’s operations.
• Technically, WastedLocker does not have much in common with BitPaymer
• The ransomware name is derived from the filename it creates which includes an abbreviation of the victim’s name and the string ‘wasted’. 
• Encrypted files extension is set according to the targeted organisations name along with the prefix wasted
• Example: test.txt.orgnamewasted (encrypted data) and test.txt.orgnamewasted_info (ransomware note)
• No data theft and no leak site.
• Each ransomware victim has a custom build configured or compiled for them.
• Note contains: Protonmail and Tutanota email domains, as well as Eclipso and Airmail email addresses. The email addresses listed in the ransom messages are numeric – usually 5 digit numbers.

Infection highlights

• Delete shadow copies
• Copy the ransomware binary file to %windir%system32 and take ownership of it (takeown.exe /F filepath) and reset the ACL permissions. In other cases an Alternate Data Stream (ADS) is used as a means to run the ransomware processes.
• Create and run a service. The service is deleted once the encryption process is completed.

IOC’s

*wasted and *wasted_info filenames for encrypted files and the ransom notes

Basic layout of the content of the ransom note:

*ORGANIZATION_NAME*
YOUR NETWORK IS ENCRYPTED NOW
USE *EMAIL1* | *EMAIL2* TO GET THE PRICE FOR YOUR DATA
DO NOT GIVE THIS EMAIL TO 3RD PARTIES
DO NOT RENAME OR MOVE THE FILE
THE FILE IS ENCRYPTED WITH THE FOLLOWING KEY:
[begin_key]*[end_key] KEEP IT

The email addresses are usually numeric and 5 digits, one at Protonmail and the other at Airmail, but we have also seen Tutanota and Eclipso email addresses.

Malwarebytes detection

Malwarebytes detects WastedLocker ransomware as Ransom.BinADS.

Stay safe everyone!

The post Threat spotlight: WastedLocker, customized ransomware appeared first on Malwarebytes Labs.

We have discovered, yet again, another phone model with pre-installed malware provided from the Lifeline Assistance program via Assurance Wireless by Virgin Mobile.  This time, an ANS (American Network Solutions) UL40 running Android OS 7.1.1.  

After our writing back in January—”United States government-funded phones come pre-installed with unremovable malware“—we heard an outcry from Malwarebytes patrons.  Some claimed that various ANS phone models were experiencing similar issues to the UMX (Unimax) U683CL.  However, it’s very hard to verify such cases without physically having the mobile device in hand. For this reason, I could not confidently write about such cases publicly. Thankfully, we had one Malwarebytes patron committed to proving his case. Thank you to Malwarebytes patron Rameez H. Anwar for sending us your ANS UL40 for further research! Your cyber-security expertise and persistence into this case will surely aid others!

Clarification of availability

To clarify, it is unclear if the phone in question, the ANS UL40, is currently available by Assurance Wireless. However, the ANS UL40 User Manual is listed (at the time of this writing) on the Assurance Wireless website.

Therefore, we can only assume it is still available to Assurance Wireless customers. Regardless, the ANS UL40 was sold at some point and some customers could still be affected.

Infection types

Just like the UMX U683CL, the ANS UL40 comes infected with a compromised Settings app and Wireless Update app. Although this may be true, they are not infected with the same malware variants. The infections are similar but have their own unique infection characteristics. Here’s a rundown of the infected apps.

Settings

• Package Name: com.android.settings
• MD5: 7ADA4AAEA49383499B405E4CE0A9447F
• App Name: Settings
• Detection: Android/Trojan.Downloader.Wotby.SEK

The Settings app is exactly what it sounds like—it is the required system app used to control all the mobile device’s settings. Thus, removing it would leave the device unusable. For the case of the ANS UL40, it is infected with Android/Trojan.Downloader.Wotby.SEK.

Proof of infection is based on several similarities to other variants of Downloader Wotby. Although the infected Settings app is heavily obfuscated, we were able to find identical malicious code. Additionally, it shares the same receiver name: com.sek.y.ac; service name: com.sek.y.as; and activity names: com.sek.y.st, com.sek.y.st2, and com.sek.y.st3. Some variants also share a text file found in its assets directory named wiz.txt. It appears to be a list of “top apps” to download from a third-party app store.  Here’s snippet of code from the text file.

To be fair, no malicious activity triggered for us from this infected Settings app. We were expecting to see some kind of notification or browser popup populated with info from the code above displayed. Unfortunately, that never happened. But we also didn’t spend the normal amount of time a typical user would on the mobile device. Nor was a SIM card installed into the device, which could impact how the malware behaves. Nevertheless, there is enough evidence that this Settings app has the ability to download apps from a third-party app store. This is not okay. For this reason, the detection stands.

Although unsettling, it’s important to note that the apps from the third-party app store appear to be malware-free. This was verified by manually downloading a couple for ourselves for analysis. That’s not to say that malicious versions couldn’t be uploaded at a later date. Nor did we verify every sample. Nevertheless, we believe the sample set we did verify holds true for other apps on the site. Under those circumstances, even if the ANS’s Settings app had downloaded an app from the list, it’s still not as nefarious as the Settings app seen on the UMX U683CL.

WirelessUpdate

• Package Name: com.fota.wirelessupdate
• MD5: 282C8C0F0D089E3CD522B4315C48E201
• App Name: WirelessUpdate
• Detections: Three variants of Android/PUP.Riskware.Autoins.Fota
  • Variants .INS, .fscbv, and .fbcv

WirelessUpdate is categized as a Potentially Unwanted Program (PUP) riskware auto-installer that has the ability to auto-install apps without user consent or knowledge. It also functions as the mobile device’s main source of updating security patches, OS updates, etc.

Android/PUP.Riskware.Autoins.Fota in particular is known for installing various variants of Android/Trojan.HiddenAds—and indeed it did! In fact, it auto installed four different variants of HiddenAds as seen below!

• Package Name: com.covering.troops.merican
• MD5: 66C7451E7C87AD5145596012C6E9F9A0
• App Name: Merica
• Detection: Android/Trojan.HiddenAds.MERI

• Package Name: com.sstfsk.cleanmaster
• MD5: 286AB10A7F1DDE7E3A30238D1D61AFF4
• App Name: Clean Master
• Detection: Android/Trojan.HiddenAds.BER

• Package Name: com.sffwsa.fdsufds
• MD5: 4B4E307B32D7BB2FF89812D4264E5214
• App Name: Beauty
• Detection: Android/Trojan.HiddenAds.SFFW

• Package Name: com.slacken.work.mischie
• MD5: 0FF11FCB09415F0C542C459182CCA9C6
• App Name: Mischi
• Detection: Android/Trojan.HiddenAds.MIS

Payload drop verification

Now you might be wondering, “How did you verify which of the two pre-installed infected system apps is dropping the payloads?” The process works as follows. You disable one of them upon initially setting up the mobile device. In both the UMX and ANS cases, picking which one to disable was easy to decide. That’s because disabling the Settings app renders the phone unusable. So, disabling WirelessUpdate was the obvious choice in both cases. The next step in the process is waiting a couple of weeks to see if anything happens. And yes, you sometimes need to wait this long for the malware to drop payloads. If nothing happens after a couple of weeks, then it’s time to re-enable the infected system app again and start the waiting game all over.

Using this process, we found in the case of the UMX U683CL, the Settings app was the culprit. For the ANS UL40, after not seeing any dropped payload(s) for weeks, I re-enabled WirelessUpdate. Within 24 hours, it installed the four HiddenAds variants! Caught red-handed, WirelessUpdate!

The tie between UMX and ANS

With our findings, we imagine some are left wondering: Is this a correlation or coincidence? We know that both the UMX and ANS mobile devices have the same infected system apps. However, the malware variants on the U683CL model and the UL40 are different. As a result, I initially didn’t think there was any ties between the two brands. I summed it up to be a coincidence rather than a correlation. That is until I stumbled upon evidence suggesting otherwise. 

The Settings app found on the ANS UL40 is signed with a digital certificate with the common name of teleepoch. Searching teleepoch comes up with the company TeleEpoch Ltd along with a link to their website. Right there on the homepage of TeleEpoch Ltd it states, Teleepoch registered brand “UMX” in the United States. 

Let’s review. We have a Settings app found on an ANS UL40 with a digital certificate signed by a company that is a registered brand of UMX.  For the scoreboard, that’s two different Settings apps with two different malware variants on two different phone manufactures & models that appear to all tie back to TeleEpoch Ltd. Additionally, thus far the only two brands found to have preinstalled malware in the Settings app via the Lifeline Assistance program are ANS and UMX.

This led me to do further research into the correlation by looking at cases in our support system of other ANS models that might have preinstalled malware. That’s when I found the ANS L51. For the record, the L51 was another model being boasted as having preinstalled malware within the comments of the UMX article in January. I discovered that the ANS L51 had the same exact malware variants as the UMX U683CL! There, within previous support tickets, was hard proof of the ANS L51 infected with Android/Trojan.Dropper.Agent.UMX and Android/PUP.Riskware.Autoins.Fota.fbcvd. Driving home the triage of TeleEpoch, UMX, and ANS correlation! 

Solutions

We have the utmost faith that ANS will quickly find a resolution to this issue. Just as UMX did as stated in the UPDATE: February 11, 2020 section of the January writing. As a silver lining, we did not find the Settings app on the ANS to be nearly as vicious as on the UMX.  Thus, the urgency is not as severe this time around.

In the meantime, frustrated users with the ANS UL40 can halt the reinfection of HiddenAds by using this method to uninstall WirelessUpdate for current user (details in link below):

Removal instructions for Adups

Warning: Make sure to read Restoring apps onto the device (without factory reset) in the rare case you need to revert/restore app.  For instance, if you like to restore WirelessUpdate to check if there are important system updates.

Use this/these command(s) during step 7 under Uninstalling Adups via ADB command line to remove:

adb shell pm uninstall -k –user 0 com.fota.wirelessupdate

Budget should not equate to malware

There are tradeoffs when choosing a budget mobile device. Some expected tradeoffs are performance, battery life, storage size, screen quality, and list of other things in order to make a mobile device light on the wallet. 

However, budget should never mean compromising one’s safety with pre-installed malware. Period.

The post We found yet another phone with pre-installed malware via the Lifeline Assistance program appeared first on Malwarebytes Labs.

This week on Lock and Code, we discuss the top security headlines generated right here on Labs and around the Internet. In addition, we talk to JP Taggart, senior security researcher at Malwarebytes, about the Internet of Things.

For years, Internet capabilities have crept into modern consumer products, providing sometimes convenient, sometimes extraneous Internet connectivity. This increase in IoT devices has an obvious outcome—a broader attack surface for threat actors. Not only that, but with more devices connecting to the Internet, there are also more devices collecting your data and analyzing it to send you more ads, more frequently, for more products.

Tune in to hear about the development of IoT devices, their cybersecurity and data privacy lapses, and more, on the latest episode of Lock and Code, with host David Ruiz.

You can also find us on the Apple iTunes store, Google Play Music, and Spotify, plus whatever preferred podcast platform you use.

We cover our own research on:

• Of Bluetooth and beacons: We took a look at how companies use Bluetooth to track you and use that capability for their benefit.
• A malicious installer of the Little Snitch app was brought to our attention, and it happens to be a new Mac ransomware we now call ThiefQuest.
• The Chromebook, they say, is a system that doesn’t need antivirus protection. Or does it? We took a deep dive into this claim to see if it truly holds water.

Plus other cybersecurity news:

• Another ransomware attack struck a school, this time the University of California, who admitted to paying the ransom to the tune of 1.4 USD. (Source: Computer Business Review)
• A known APT threat actor called Promethium, aka StrongPity, was spotted by multiple security researchers pushing Trojanized installers that mimic legitimate programs to target countries, which include India and Canada, for intelligence gathering. (Source: ZDNet)
• Website owner and bloggers, beware! There’s a “secure DNS” scam making rounds, purporting to “help” you. (Source: Sophos’s Naked Security Blog)
• Attackers compromised several US newspaper websites, and then used them as launchpads to distribute code that allows for the downloading of ransomware to visitors, of which are mostly huge organizations. (Source: Dark Reading)
• TrickBot, a nefarious and very tricky Trojan, has a new quirk: it checks for the screen resolution spec of victim machine to identify if it is running on a virtual machine or not. (Source: BleepingComputer)

Stay safe, everyone!

The post Lock and Code S1Ep10: Pulling apart the Internet of Things with JP Taggart appeared first on Malwarebytes Labs.

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.