We found yet another phone with pre-installed malware via the Lifeline Assistance program

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.


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.


  • 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! 


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.

Mac ThiefQuest malware may not be ransomware after all

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.


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.


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?

Members of the security community have made good progress on figuring out how to decrypt files encrypted by this malware. I know of one researcher who was able to successfully decrypt files that I sent him from an infected test system.

Although we don’t have a tool available right now to do the decryption, I suspect one will be available soon. We’ll update when that happens.

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

Lock and Code S1Ep10: Pulling apart the Internet of Things with JP Taggart

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 storeGoogle 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.

Credit card skimmer targets ASP.NET sites

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.

Figure 1: Comparing Linux and Windows based web stacks

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.

Figure 2: A snapshot of victim sites with compromised JS 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.

Figure 3: Malwarebytes blocks a domain when visiting an affected portal

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.

Figure 4: Small code injection calls out malicious remote script

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.

Figure 5: Full skimmer injected directly into legitimate script
Figure 6: Full obfuscated skimmer injected into legitimate script

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.

Figure 7: Checks for credit card pattern and password

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.

Figure 8: Data encoding process

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).

Figure 9: Exfiltration URL build process

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:

Figure 10: Script we wrote to decode exfiltrated data

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


Skimmer infrastructure


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

Do Chromebooks need antivirus protection?

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.

Coughing in the face of scammers: security tips for the 2020 tax season

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.


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.

A zero-day guide for 2020: Recent attacks and advanced preventive techniques

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.


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.


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.

Lock and Code S1Ep9: Strengthening and forgetting passwords with Matt Davey and Kyle Swank

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 Matt Davey, chief operations optimist at 1Password, and Kyle Swank, a member of 1Password’s security team, about—what else—passwords.

We may know it’s important to have a strong, non-guessable, lengthy password, and yet we still probably all know someone who writes their password on a post-it, which is then affixed literally onto their machine. On today’s episode, we discuss secure passwords, password alternatives, and the future—and potential death—of passwords.

Tune in for all this and more on the latest episode of Lock and Code, with host David Ruiz.

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

We cover our own research on:

  • End of Line: We look at what happens in a world where your expensive home devices can lose support without much warning
  • Facial recognition technology: We provide a rundown on which companies recently decided to not provide the technology to law enforcement.

Plus other cybersecurity news:

  • Business email compromise: scam email trends in the age of Coronavirus (Source: Help Net Security)

Stay safe, everyone!

The post Lock and Code S1Ep9: Strengthening and forgetting passwords with Matt Davey and Kyle Swank appeared first on Malwarebytes Labs.

Facial recognition: tech giants take a step back

Last week, a few major tech companies informed the public that they will not provide facial recognition software to law enforcement. These companies are concerned about the way in which their technology might be used.

What happens when software that threatens our privacy falls into the hands of organization which we no longer trust? In general, being aware of tracking software causes a feeling of being spied on and a feeling of insecurity. This insecurity that spreads throughout society is likely causing these companies to revise their strategy. Current developments surely have had an impact on an already distorted social environment. A pandemic and worldwide protests are a mix we have never experienced before in human history.

Definition of facial recognition

The definition of facial recognition, or “face recognition” as the Electronic Frontier Foundation (EFF) defines it, is:

A method of identifying or verifying the identity of an individual using their face. Face recognition systems can be used to identify people in photos, video, or in real-time.

Facial recognition is one of the technologies that even laymen can understand in how it can be used against citizens by a malevolent or untrustworthy government. Other methods like social profiling and behavioral analysis are more elusive and less easy to comprehend.

In an earlier blog, we already discussed the very different rules, laws and regulations that exist around the world when it comes to facial recognition. Depending on the type of government and the state of technology, the rules are very different—or they don’t exist at all.

The stated bans by Amazon, IBM, and Microsoft announced over the course of one week, however, were more or less directly aimed at US organizations, perhaps as a result of a growing distrust about local law enforcement agencies in general and due to the behavior of some police departments in particular. But we can likely expect these bans to spread out across the world. (And I think that is a good thing.) Laws have a tendency to follow the developments in society, always trailing one step behind. But in this case it looks important enough to wait until the development and legislature can go hand in hand.

The companies

Microsoft halted the sale of facial recognition technology to law enforcement in the US, stating that the ban would stick until federal laws regulating the technology’s use were put into place. In other words, they want to have rules in place for the use of the technology before they provide it.

Amazon, which is potentially one of the biggest players in this space, has their own custom tech called Rekognition. It’s being licensed to businesses and law enforcement. Earlier on, Amazon had already announced a similar ban for very much the same reason, letting the public know that it would require “stronger regulations to govern the ethical use of facial recognition technology.”

IBM did not limit the ban to the US but it did explain their motives in a letter to Congress. In this letter the company addressed the subject by writing it had no plans to market facial recognition software if it would be used “for mass surveillance, racial profiling, violations of basic human rights and freedoms, or any purpose which is not consistent with our values and Principles of Trust and Transparency.”

Why we do not want facial recognition

Many groups like American Civil Liberties Union (ACLU) and EFF have made objections against this technology as it is considered a breach of privacy to use biometrics to track and identify individuals without their consent. Many feel that there is already more than enough technology out there that keeps track of our behavior, preferences, and movement. The technology does not necessarily always know who we are down to the level of personally identifiable information (PII). Many people get uneasy when they find out how well aware advertisers and shops are of our preferences by tracking our browsing habits and online purchases.

And some incidents certainly don’t help the case at all. For example, the Baltimore police department reportedly ran social media photos through face recognition to identify protesters and arrest them.

Another example of using this technology for a purpose separate than what it was intended for—and also another possible reason for distrust—was the fact that Minnesota police resorted to what it called “contact-tracing” demonstrators arrested after recent protests. But “contact tracing” is a public health effort to help stop the spread of disease like the COVID-19 outbreak. As it turns out, the Minnesota police are looking at it as a model for criminal investigations.

Facial recognition still has its limits

Another objection against facial recognition technology has always been the inaccuracy. There are significant risks that facial recognition used in law enforcement is unreliable.

Most facial recognition software relies on Artificial Intelligence (AI) and, more precisely, Machine Learning (ML). Where facial recognition relies on machine learning the training data is often incomplete or unrepresentative of the general population. A study from MIT Media Lab shows that facial recognition technology works differently across gender and races. In cases where misidentification can lead to arrest or incarceration, we will surely want to avoid such grave errors due to false positives.

Will we ever be ready for facial recognition to be used by law enforcement?

What surely will need to happen is that law enforcement regains the trust of the public in general and that laws regulating the use of facial recognition software will be made effective to satisfy the demands of the manufacturers of facial recognition software.

Whether that means we can lie back and rely on the forces at work to do the right thing is a whole other topic. A large majority of humanity seems to be torn between “I have nothing to hide” and “they already know everything” anyway. That is not a healthy situation and the degree of unease largely depends on which country you happen to live in and many other circumstances beyond your control.

So, even though the chances of facial recognition getting widely used by law enforcement seem to be put on a lower level in the US, this remains a topic to keep an eye on if you value your privacy.

The post Facial recognition: tech giants take a step back appeared first on Malwarebytes Labs.

Multi-stage APT attack drops Cobalt Strike using Malleable C2 feature

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

On June 10, we found a malicious Word document disguised as a resume that uses template injection to drop a .Net Loader. This is the first part of a multi-stage attack that we believe is associated to an APT attack. In the last stage, the threat actors used Cobalt Strike’s Malleable C2 feature to download the final payload and perform C2 communications.

This attack is particularly clever for its evasion techniques. For instance, we observed an intentional delay in executing the payload from the malicious Word macro. The goal is not to compromise the victim right away, but instead to wait until they restart their machine. Additionally, by hiding shellcode within an innocuous JavaScript and loading it without touching the disk, this APT group can further thwart detection from security products.

Lure with delayed code execution

The lure document was probably distributed through spear phishing emails as a resume from a person allegedly named “Anadia Waleed.” At first, we believed it was targeting India but it is possible that the intended victims could be more widespread.

Figure 1: Resume

The malicious document uses template injection to download a remote template from the following url:


Figure 2: Template injection

The domain used to host the remote template was registered on February 29, 2020 by someone from Hong Kong. Creation time for the document is 15 days after this domain registration.

The downloaded template, “indexa.dotm”, has an embedded macro with five functions:

  • Document_Open
  • VBA_and_Replace
  • Base64Decode
  • ChangeFontSize
  • FileFolderExist.

The following shows the function graph of the embedded macro.

Figure 3: Macro functions graph

The main function is Document_open which is executed upon opening the file. This function drops three files into the victim’s machine:

  • Ecmd.exe: UserForm1 and UserForm2 contain two Base64 encoded payloads. Depending on the version of .Net framework installed on the victim’s machine, the content of UserForm1 (in case of .Net v3.5) or UserForm2 (other versions) is decoded and stored in “C:\ProgramData”.
  • cf.ini: The content of the “cf.ini” file is extracted from UserForm3 and is AES encrypted, which later on is decrypted by ecmd.exe.
  • ecmd.exe.lnk: This is a shortcut file for “ecmd.exe” and is created after Base64 decoding the content of UserForm4. This file is dropped in the Startup directory as a trigger and persistence mechanism.

Ecmd.exe is not executed until after the machine reboots.

Figure 4: Document_Open
Figure 5: Custom Base64 decode function

ChangeFontSize and VBA_and_Replace functions are not malicious and probably have been copied from public resources [1, 2] to mislead static scanners.

Intermediary loader

Ecmd.exe is a .Net executable that pretends to be an ESET command line utility. The following images show the binary certificates, debugger and version information.

The executable has been signed by “ESET, spol. s r.o.” and its version information shows that this is an “Eset command line interface” (Figure 6-8).

Figure 6: Certificate information
Figure 7: Version information
Figure 8: Debugger information

ecmd.exe is a small loader that decrypts and executes the AES encrypted cf.ini file mentioned earlier. It checks the country of the victim’s machine by making a HTTP post request to “http://ip-api.com/xml“. It then parses the XML response and extracts the country code.

Figure 9: Getcon function: make http post request to “ip-api.com”
Figure 10: ip-api.com output

If the country code is “RU” or “US” it exits; otherwise it starts decrypting the content of “cf.ini” using a hard-coded key and IV pair.

Figure 10: ecmd.exe main function

The decrypted content is copied to an allocated memory region and executed as a new thread using VirtualAlloc and CreateThread APIs.

Figure 11: runn function

ShellCode (cf.ini)

A Malleable C2 is a way for an attacker to blend in command and control traffic (beacons between victim and server) with the goal of avoiding detection. A custom profile can be created for each target.

The shell code uses the Cobalt Strike Malleable C2 feature with a jquery Malleable C2 profile to download the second payload from “time.updateeset[.]com”.

Figure 12: Malleable C2 request

This technique has been used by two other recent Chinese APTs—Mustang Panda and APT41.  

The shellcode first finds the address of ntdll.exe using PEB and then calls LoadLibrayExA to load Winint.dll. It then uses InternetOpenA, InternetConnectA, HttpOpenRequestA, InternetSetOptionA and HttpSendRequestA APIs to download the second payload.
The API calls are resolved within two loops and then executed using a jump to the address of the resolved API call.

Figure 13: Building API calls

The malicious payload is downloaded by InternetReadFile and is copied to an allocated memory region.

Figure 14: InternetReadFile

Considering that communication is over HTTPS, Wireshark is not helpful to spot the malicious payload. Fiddler was not able to give us the payload either:

Figure 15: Fiddler output

Using Burp Suite proxy we were able to successfully verify and capture the correct payload downloaded from time.updateeset[.]com/jquery-3.3.1.slim.min.js. As can be seen in Figure 16, the payload is included in the jQuery script returned in the HTTP response:

Figure 16: Payload happened to the end of jquery

After copying the payload into a buffer in memory, the shellcode jumps to the start of the buffer and continues execution. This includes sending continuous beaconing requests to “time.updateeset[.]com/jquery-3.3.1.min.js” and waiting for the potential commands from the C2.  

Figure 17: C2 communications

Using Hollow Hunter we were able to extract the final payload which is Cobalt Strike from ecmd’s memory space.


A precise attribution of this attack is a work in progress but here we provide some insights into who might be behind this attack. Our analysis showed that the attackers excluded Russia and the US. The former could be a false flag, while the latter may be an effort to avoid the attention of US malware analysts.

As mentioned before, the domain hosting the remote template is registered in Hong Kong while the C2 domain “time.updateeset[.]com” was registered under the name of an Iranian company called Ehtesham Rayan on Feb 29, 2020. The company used to provide AV software and is seemingly closed now. However, these are not strong or reliable indicators for attribution.

Figure 11: updateeset.com whois registration information

In terms of TTPs used, Chinese APT groups such as Mustang Panda and APT41 are known to use jQuery and the Malleable C2 feature of Cobalt Strike. Specifically, the latest campaign of Mustang Panda has used the same Cobalt Strike feature with the same jQuery profile to download the final payload which is also Cobalt Strike. This is very similar to what we saw in this campaign, however the initial infection vector and first payload are different in our case.


Anadia Waleed resume.doc

Remote Template: indexa.dotm

Remote Template Url:




Cf.ini shell-code after decryption:

Cobalt Strike downloaded shellcode:

Cobalt Strike payload

The post Multi-stage APT attack drops Cobalt Strike using Malleable C2 feature appeared first on Malwarebytes Labs.