{"id":15709,"date":"2013-07-08T13:18:58","date_gmt":"2013-07-08T20:18:58","guid":{"rendered":"http:\/\/www.intego.com\/mac-security-blog\/?p=15709"},"modified":"2016-02-12T10:40:38","modified_gmt":"2016-02-12T18:40:38","slug":"how-malware-is-researched-part-2","status":"publish","type":"post","link":"https:\/\/www.intego.com\/mac-security-blog\/how-malware-is-researched-part-2\/","title":{"rendered":"How Malware is Researched \u2013 Part 2"},"content":{"rendered":"

\"Goat\"<\/a><\/p>\n

There are lots of useful ways of looking at a file to determine whether it\u2019s malware, and if it is, what it\u2019s trying to do. Some of those ways involve dissecting the file on disk for clues to a file\u2019s structure (static analysis), and some of those ways involve watching the file in action (dynamically) to see what it actually does. These are both useful pieces of the puzzle, and in most instances researchers will first use static and then dynamic methods of analyzing the file.<\/p>\n

In Part 1 \u2013 Static Analysis<\/a> we covered some methods of Static analysis; namely Text View, Hex View and Assembler View. All three methods are ways of looking for clues that tell you what a file might be trying to do. For instance, is the file armored in some way to dissuade analysis? Is the text in the file indicative of a professional piece of software, or is it more casual, using curse-words or \u201cleetspeak<\/a>?\u201d Does the file have structures that seem to be indicative of exploiting vulnerabilities in other software, or does it seem to be trying to achieve persistence? These things are not conclusive evidence alone, but help create a picture of what the file is trying to do.<\/p>\n

The other important part of static analysis is to figure out what sorts of dependencies a file has. The first and most obvious dependency is the type of operating system \u2013 does this file run on Windows, OS X or Linux, for example? A file may have other requirements to run too, depending on what programming language it was written in, or if it tries to spread (such as through an instant messaging or peer-to-peer file sharing app) or infect certain types of files.<\/p>\n

Once we have given the file a thorough look with static analysis methods, we hopefully have a good picture of how we need to set up our test environments.<\/p>\n

Goat Machines<\/b><\/h3>\n

You know that scene in Jurassic Park where they\u2019re driving through the park and a goat is brought up as a snack for the T-Rex<\/a>? (Apologies, I could only find the scene with added sheep-commentary.) In malware analysis, we have a similar idea for tempting malware to do its thing. Researchers use what we call a \u201csacrificial goat machine\u201d \u2013 or just \u201cgoat\u201d for short. This machine is set up to be the tastiest possible treat for the malware, by giving it all the conditions it needs to do what it intends to do, and appearing as much as possible to be a real user\u2019s machine rather than a safely quarantined test machine.<\/p>\n

In order to do this quickly, most researchers have several standard \u201cimages\u201d that are either physical or virtual machines that can be quickly taken back to a known-clean state. This is helpful for either repeating analysis on one file if needed, or getting ready to analyze other files. Usually these include an image for various different OS versions, to see if the malware behaves differently on one versus another. If, for instance, a researcher specializes in just Mac threats they might have an image for all the supported version of OS X plus any versions that are in beta. The same goes for researchers specializing in other operating systems as well. (Though things get complicated when you throw in different Linux flavors or the limitations of different carrier or handset-manufacturers\u2019 versions of Android.)<\/p>\n

Once a researcher has an image all set up, the next thing he or she needs to do is start up any recording tools they might have, so they can see what changes are made by the file. A lot of malware is essentially silent, if you\u2019re just looking at it on your screen, so we need to have tools that will report any system changes or network traffic. And those tools need to be smart enough not to be fooled by rootkit techniques<\/a> that try to hide the changes.<\/p>\n

When everything\u2019s all ready to go, the researcher will start the file up (usually just double-clicking it), and then let it do its thing for a few minutes. Sometimes the file will need a little extra coaxing to perform its various actions, so a researcher will usually spend those minutes interacting with the goat system like a regular user would, by opening files and moving around the system. This can activate various trigger-events that malware sometimes have, hoping to verify that it is on a real user\u2019s machine rather than in an automated honeypot<\/a> machine.<\/p>\n

Debugging Files<\/b><\/h3>\n

Sometimes it can be helpful to isolate specific parts of a file\u2019s behavior, especially if a sample is going to extraordinary lengths to hide its actions \u2013 and for this purpose, we have what\u2019s called a Debugger. These tools were originally created for programmers to help them step through small sections of code, so they could find and correct bugs. Debugging files can be equally useful to a malware researcher that wants to step through small sections of code to figure out certain specific behavior within a file. It can be very helpful to get a file\u2019s decryption routine, or to figure out passwords they use to join C&C channels<\/a>, as well as to identify certain conditions used for trigger events, for instance.<\/p>\n

\"Debug\"<\/a><\/p>\n

If you have ever wondered why you sometimes see really in-depth analysis way after a particular malware was first discovered, it\u2019s often because the researcher went through much of the malware\u2019s code with a debugger. Most malware is pretty small in size, but much of the code is usually convoluted and repetitive. Going through a sample in a debugger may require analyzing a section of code once, changing a variable, stepping back through the code again, then changing another variable and doing it yet again\u2026 it can be a very arduous and time-consuming process. This sort of thorough analysis isn\u2019t something that gets done with every sample, but with high profile or particularly tricky malware as needed.<\/p>\n

In the End<\/b><\/h3>\n

Malware analysis can be a fairly quick and dirty process or a months-long process, depending on the skill and effort of the malware author that created it as well as the malware analyst that receives it. If an analyst is looking at his or her umpteenth variant of a family that\u2019s been publicly released, it can be dealt with in a matter of minutes. If it\u2019s the first sample of a heavily armored and feature-rich spyware that\u2019s hitting hundreds of thousands of users, dozens of researchers around the world are probably going to spend a lot of long nights trying to provide useful and juicy tidbits about its behavior. Hopefully we\u2019ve given you some insight into what that process entails, so it\u2019ll seem less mysterious.<\/p>\n

photo credit: ‘Sing It Again<\/a>‘ Found on flickrcc<\/a><\/i><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

There are lots of useful ways of looking at a file to determine whether it\u2019s malware, and if it is, what it\u2019s trying to do. Some of those ways involve dissecting the file on disk for clues to a file\u2019s structure (static analysis), and some of those ways involve watching the file in action (dynamically) […]<\/p>\n","protected":false},"author":6,"featured_media":15771,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[190],"tags":[493,489,491,495],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\t\n\t\n\t\n