3WoO Day 4: Learning From Malware

When most people receive an email with a malicious attachment, they do one of two things: either they delete it, knowing that it is malicious, or they get fooled into executing the attachment, which ruins their day. Then there is the third category of people. They are people like me. These people intentionally infect a system to see what kinds of interesting things the malware does. Some guys like football. I like to analyze malware. So when I got an unexpected email purporting to be from FedEx, I had to let the attachment loose on a virtual machine.  I’m going to skip the detailed analysis and post a few screenshots, because the purpose of this post will be to convert what we have learned into something that OSSEC can detect.

As you can see, this is a garden-variety fake HDD scanner. It was pretty annoying–hiding my drives, killing my analysis tools, redirecting search results and the other usual things.

There’s one thing that is almost universally true about malware like this; it leaves evidence on the system. Our job is to look for those changes and write rules to the general class of behavior. It wouldn’t make much sense to write a rule looking for the specific, random file names that this trojan dropped; instead, we want to understand what happens in general.

Take a look at what MalwareBytes found. It also added the following to the hosts file:

127.0.0.1 thepiratebay.org
127.0.0.1 www.thepiratebay.org
127.0.0.1 mininova.org
127.0.0.1 www.mininova.org
127.0.0.1 forum.mininova.org
127.0.0.1 blog.mininova.org
127.0.0.1 suprbay.org
127.0.0.1 www.suprbay.org

What can we learn from this? Consider the following:

  1. Three files were added to run at Windows startup. All of them are from locations in the user’s profile. Two of them are particular suspicious, as the run line begins with rundll32.
  2. Several policies were changed. The effect was hiding standard parts of the OS. This may be legitimate for something like a kiosk, but is not generally used.
  3. Two executable files were written to the root of \application data. Normal apps should not do this and I see this particular behavior with malware a lot these days.
  4. Several URLs were  redirected to localhost. Generally, this is only done legitimately to block ad-serving sites, and there are better ways to do that these days.

As you can see, these are behavioral observations. In part II, we’ll take these observations and make them actionable within OSSEC. Stay tuned.

 

Tagged with:
One comment on “3WoO Day 4: Learning From Malware
  1. Charles W says:

    Nice, Mike.
    My fav malware RE tools are:
    Install Watch Pro
    Autorun.exe
    http://www.threatexpert.com

    Looking forward to your next post.
    Charles

1 Pings/Trackbacks for "3WoO Day 4: Learning From Malware"
  1. […] I blogged about some annoying malware. The point was to learn some of the techniques that this general class of malware uses, so we could […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*