When investigating Malware, there are two general approaches, either statically or dynamically. Static being a state of analysis where the malicious executable isn't actually running and can be analyzed with a disassembler like IDA, hex editor, or scanned with other tools like an antivirus or VirusTotal to verify that it is actually a malicious file. You can get some basic to advanced levels of information from this style of analysis, depending on your methods. You can analyze strings that could possibly inform us of a url the executable tried accessing, or give some listed API system calls or functions that were generated by the malware, which is highly technical and requires highly qualified analysts that have a solid background in programming and reverse engineering.You don't have to worry about working in a safe environment with static analysis, and I believe you can also grab some file signatures or hash marks of the malicious file, to check and see if they are indeed malicious, or use these hashes to search and see if this malware is in the wild. One of the difficulties of static analysis aside from parsing assembly by hand, are anti reversing techniques such as packers and obfuscation. These anti reversing techniques cause IDA to come to a screeching halt, making it unable to disassemble up 90% of the code, i think i read somewhere, if my memory serves me correctly. Although i think there are plugins for IDA that help combat against these techniques. Again, this really is outside my level of experience.
The best way to analyze a malicious file is through Dynamic analysis, which is when you analyze and disassemble malware while it is running in a safe environment with a debugger like Ollydbg. Safe environments usually involve a virtual machine or a dedicated physical system that is disconnected from any other computers or important networks. There are more things that are visible when running malware, watching the malware's behavior and what is was designed to do. Also, when malware is running, it unpacks itself in order to run, showing more to the analyst. Malware recognizes the types of environments they're running in, so they usually won't run unless they have a networked connection, or even sometimes won't run until a specific users action has been performed.
Technically both of these methods are forms of reverse engineering. My intentions aren't to attempt reverse engineering malware samples, but instead try and simulate a malware incident at its most basic form. If a company or a personal computer was a victim of a malware infection the first course of action would be to run an Antivirus to contain the malicious files. As we know there are many evasion techniques that can circumvent a firewall, IDS, or AV, whether it's because of obfuscation or because there isn't a signature for the malware open to the public yet. If a company has told you they ran their antivirus program, and see there has been malware contained, you can mark down the CVE number and see what other forums have to say about the type of malware it is. But, the system may not be entirely clean, and there may be files left behind that have either hidden their presence with a rootkit, or some other anti-forensic technique. So the first steps in responding to a malware incident, is figuring out if indeed you were infected, how you were infected, and what was taken or left behind. There is an order of volatility that a responder must follow. I will sequentially attempt to check each layer with the malware sample i will be analyzing.
Malware incident response
When responding to a malware incident, there are a few methods to choose from when deciding which way is the best to collect data in a live response scenario. An incident responder has a toolkit which can include a live cd with a multitude of tools running inside of it, (like FTK imager lite or Sysinternal's toolset, SIFT, Helix, Winhex, you name it..), that can be used to boot up into a virtual environment, running entirely inside memory, as to prevent from writing itself to disk and erasing any information. But this unfortunately overwrites valuable volatile data that exists inside the suspects memory, for the sake of maintaining the purity of the suspects hard drive. This is a bit of a bummer because there are tons of toolkits out there that are fantastic for performing live analysis, but not so great at maintaining the forensic sate of a suspects memory. There's gotta be other ways.
An alternative to live cd's are running batch files from a usb drive like Memoryze. Batch files are a series of MS-DOS commands typed in a file that are generally devised to execute certain programs that are either already installed on the system, or from an external location where the tools may be located. If you have the appropriate settings configured, they can automatically execute.
So you will have to first properly install Memoryze to your host PC, then install those executables onto your USB drive. I don't want to get into that process since there are already step by step guides out there on how to do this, ex: Put Memoryze on USB.
Once you have your USB with Memoryze plugged into a suspects system, start running the suspects cmd with admin privileges, and navigate to your directory (with cd command) to where your tools are located on your usb drive, so you can run the executables that are in the usb drive. Granted, when running these tools from your usb prevents you from having to download these tools to the suspects system, but sadly you are still running an executable (memorize.exe), from your usb that is being loaded into memory, and overwriting data. Tools like memoryze will also need to download extra drivers in order for your USB to have a connection to the suspects memory.
Even though you're disrupting a lot of data, it is still less intrusive to the systems memory than running from Live CD's. Keep in mind that up to 50 percent of incident responders still use live cd's. (I read that somewhere, i don't know personally if that's true.) Again, this is a tool that is run and executed within the cmd, and no gui's are used. The GUI for Memoryze is Redline. Think of their relationship as the type of relationship that exists between The Sleuth Kit and Autopsy. You can configure Memoryze's output to be redirected to your usb drive. Batch files are text commands (scripts) that will run the executables tools that are inside your usb drive when you initiate it with an auto start setting or from the suspects command line. Memoryze doesn't rely on the suspects operating system, so they can uncover possibly hidden files.
Running tools locally have their ups and downs, and have clearly been the preferred method in which to acquire a live forensic copy of a running systems hard drive, (not so if this is true when wanting to capture system memory.) If you want to know the impact a live cd has on a systems filesystem or registry, using tools like File Monitor (FileMon), and Registry Monitor (RegMon), can be very useful when capturing the state of a system and comparing the effecting changes a Live CD will have on a system after it was run.
But what if you're miles away and you can't make it to the suspects location with a live cd? A third alternative is via a remote acquisition. I'll get into that a little later. For now, i'd like to cover some basic technologies in Windows 7 that allow for file sharing and remote connections. I know this is off topic from a security discussion, but you'll see how it ties in later on. You can skip this section if you don't want to read about basic Windows 7 OS operations.
How Win7 shares files locally/remotely
When dealing with a malware incident, analyzing a systems Network Shares becomes an important facet of investigation. Although malicious code does not always have functionality to propagate through network shares, some specimens identify and affect shares on an infected system. (Malware Forensics, 2008). What are Network Shares? It's simply sharing one computers files with another computer either locally, or remotely over the internet.
Networking tips: On Microsoft Windows, a network share is provided by the Windows network component "File and Printer Sharing for Microsoft Networks", using Microsoft's SMB (Server Message Block) protocol, (I'll get into what SMB is later on. SMB protocol can be used on a LAN network, or can be used to traverse the internet over TCP. Now i only want to talk about Network sharing that doesn't involve the internet). Network Discovery is a network setting in Windows 7 that affects whether your computer can find other computers and devices on the network YOUR CURRENTLY connected to, and/or whether other computers on the network can find your computer. Network shares under network discovery is turned off by default. When dealing with the network discovery tools under windows 7, you're specifically sharing files with other people that are on your local area network. This has nothing to do with sharing files over the internet. Be able to remotely share and access files from a computer on the other side of the world is implemented with a totally different technology, which we will get into later. Hint example: RDP ;). The reason why I'm going over the Network Discovery tools is because they allow you to share with other computers on your same network, which would/could also be the same method in which malware would propagate or spread its infection on other computers in the same network.
When it comes to Network Discovery settings on Win7, there are four types of configurations you can choose from; home, work, public, domain.
If you click on control panel, and then click on "network and internet", you'll see both the "network and sharing center", and the "HomeGroup", sharing options. (Homegroup is a feature new to Win7 that allows you to share files with other computers that are on your local network. HomeGroup is a true peer-to-peer networking system). If you click on "network and sharing center", you'll see "Change advanced sharing settings", where you'll then see the share settings for both your Home network and share settings for you Public network. If you were to manage the setting under Home, you're basically dealing with all the local sharing that goes on with your homegroup. But, if you were to change the settings under Public, you'll be changing the network discovery settings that will apply to all other computers that exist on the same network. This is generally a simple introduction into how windows can share files and folders with other computers on the same network. But what is you wanted to share files and folder remotely? Well lets see how Windows pulls this off.
(I know i should have included screen shots to help you the reader follow along, i just don't want to sway too far from what this post is all about.)
So with all of these local network sharing options, you can share files in a folder (or with a mapped drive with an assigned drive letter), or assign your shared folders to your HomeGroup, which have specific people assigned to them with privileged access that is also password protected.
The technologies integrated into Win7 to share files is good to know when investigating an incident, but as far as acquisitions are concerned, don't really help us too much. Or even if i'm a hacker that is doing port scans, it would come in handy to know what ports and protocols are enabling remote connections to exploit vulnerabilities in order to accomplish a remote shell.
When we want to perform a remote acquisition, there are many third party tools we can use. But what about native tools? Native tools are always going to leave less of an altering impact on a suspects computer. Just like command line tools will alway be less forensically impacting that GUI's, native tools should alway taken into consideration. (Albeit the less likely choice, since they won't offer as many capabilities or security when performing a remote acquisition.)
A Win7 native tool that allows you to connect to remote computers is Remote Desktop. Remote Desktop provides “the closest thing to being there,” with the ability to dis- play desktop background images, play videos, and so on. It’s ideal for connecting to another computer on your internal network. It also works well for connections over the Internet—but only after you properly configure your network router and rewall, which is not always easy to do. RDP is a very important tool used in Windows 7.
If you're using a Windows computer, you can type mstsc in the command line to start using RDP Remote Desktop Protocol which is native to Windows, and is used for remotely controlling another windows computer with a gui when you enter in their domain address or public IP address. The other computer you want to connect to needs to be in a listening state and allow remote connections that can be enabled under their system properties. (Update: you can remotely activate a remote system to start running RDP that isn't already running by using regedit, and since i haven't tried yet, i can't explain how it's done). Since RDP is an open protocol, their are some security issues involved. Without a high level of encryption, anyone listening or sniffing on this open connection will be able to see and steal your transmitting data. Before you begin establishing a remote connection, make sure your firewalls are configured properly to accept connection to certain incoming addressing, or work around firewall blocks by whitelisting a port or with port forwarding.
So why am i bringing up RDP? Well since we're going to be talking about a remote acquisitions, forensically speaking, if you were inclined to use RDP as your means to connect to another windows 7 machine with RDP listening, this transaction would cause less of a damaging disturbance than what you would see from installing 3rd party tools. In other words, less evidence would be lost or damaged, (I would assume). But, it's not advised to try a forensic acquisition with RDP, since it is so insecure and slow. Plus, given its low level of encryption, hackers frequently take advantage of this protocol, as they often like to with the Server Message Block SMB protocol.
So if you remember earlier I mentioned SMB being the go to protocol for file sharing on a LAN or WAN on Windows computers. It is used for both client/server engagements, and is also used when you share within your local LAN. SMB is considered a "Windows" protocol that is used by Windows when you want to share files either locally or remotely. This protocol is used when windows computers "communicate with each other", say for example when you are setting up a remote connection with RDP, or you are sharing file in a homegroup, or when remotely accessing a printer. SMB is simply a protocol of communication that windows primarily uses when trying to share files. Mac OS X uses this as their go to file sharing protocol as well i believe when sharing files with a Windows computer. Otherwise, if a Mac is sharing files with another Mac, it uses FTP. FTP is like Macs SMB. SMB can be used over the internet, but it is highly discouraged.
An investigator could send his tools over an SMB protocol so they can be accessed on a victims machine, but it is not recommended. SMB communicates directly over the TCP/IP using port 445 or by working with the NetBIOS protocol using a port between 137 and 139. SMB is a protocol frequently exploited by hackers, and is used as a route to traffic their malware onto a targeted machine that is running the SMB protocol with a vulnerability. When analyzing possible malware behavior, looking into the NetBios table for which remote connections were made with SMB, this will start to make more sense when you find yourself looking for which processes used an SMB connection, (if any at all) and traces are left inside the table. You can check what processes made a remote connection via SMB with the net statistics command. Again, I'm jumping the gun a bit here trying to discuss SMB before discussing how it pertains to malware and intrusions.
Remote Acquisitions
Since RDP isn't really a reliable and secure way in which to gain remote access to a suspects computer, we need to focus on what third party tools will allow just that in Windows. And before i continue, in order to use any of the many remote connecting tools available, you need to make sure both your Windows 7 machines that your network discovery settings are open to the public, your "file and print sharing" activated, in order for your workstation to connect to the target machine. Not only do they need to have open networks, but generally a suspect system that is being remotely accessed, will need to have he software installed on the suspect system. So for example, if you wanted to use SSH (or Putty on Windows 7), you would need to somehow install Putty on the target system, (usually by physically installing it on the target system), and start running it. SSH (Secure Shell) is an interactive login and remote connecting tool that allows a user to obtain an emulated "secure shell" on the remote system and is natively based in linux. SSH gives you shell control over the suspect system, and allows you to control the remote system quite effectively. SSH allows you to run commands on the suspect machine right away. (RDP gives you a GUI management, and SSH gives you a text based terminal shell, allowing you to transfer files or management the system in one of many different ways, ex: iso, tcpdump, netcat, port scanning, etc.). Again, SSH is primarily used in linux, but on Mac OS X it is incredibly simple to setup a SSH server listening client on your laptop when you navigate to your sharing folder under system preferences and toggle SSH "on", then Mac will show you what your user name is. Once you've got your Mac in listening mode, you can open a terminal on another computer and type, ssh Aaron@IPaddress, and hit enter. You will be prompted for a password, which will be the password of the computer you're trying to access. Once you've entered the password and are now connected to that computer, that computer will generate a cryptographic key that will now be matched with your remoting system, so that in the future you won't need to type the password again (passing the hash):
You can you use SSH, as a portal to run something like a dd imaging command. Putty comes with tools like PSCP that allows you to copy files from your target system, but dd with ssh is really what you will want to use for a remote acquisition. A downside to SSH, when it comes to remote acquisitions, is you can only run tools that are installed on the remote system, whether you as the host installed them on the remote system, or they were there to begin with. This you can imagine, will change the state of the system if you're installing programs onto the target system.
Since Putty and SSH are secure protocols, you can also run RDP over SSH, for a more secure line. SSH is a secure tunnel of transportation that protects against man in the middle attacks, and is also a terminal shell emulator. Since i have an Ubuntu machine, i would need to install OpenSSH in order to connect to it with my Mac buy installing it first (Because in Ubuntu, SSH isn't installed by default); sudo apt-get install openssl-server. Then once installed, just type ssh username@ipaddress, presuming the other machine, like my Mac, is in a listening state.
Very important::: Once you've installed OpenSSH on your ubuntu machine, realize your system now acts like an SSH server, accepting requests from anyone who knows your user name and IP. There are settings in SSH that allows you to prohibit a certain amount of login attempts to ward off any brute forcing. I don't have a solid enough user experience with SSH to show what commands would allow you to do this. Just keep it in mind when hosting an SSH server, you've opened a window of attack. And also, putty is a client, not a server protocol. If you were to install something like SSH Server on to Windows, well now you would have the same issues of vulnerabilities, and people now trying to brute your SSH portal.
When you're working with something like Encase, you will install an Encase servlet on your target system first that will allow you to have an encrypted connection between your host and target. Working with expensive propriety software is always the easiest and most effective when performing remote acquisitions. But, i don't have $4,000. So whats for free?.
Well the first tool that creates a connection with encryption is crypcat. Cyrptcat is based on netcat, and allows you to use the same commands that exist for netcat. Crypcat is simply the encrypted version of netcat. Having something like netcat is great for port scanning and remotely gaining "shell access" to a remote computer. Unlike RDP, which is a gui interface, netcat is a text based shell interpreter, which means you can control the remote system from your host computers command line. Do not send sensitive data using just netcat UNLESS you use it with a VPN. Otherwise, just go with cryptcat.
But both my windows systems that i have at home are both running commercial VPN software. So i could get away with sending sensitive data with just netcat, since my VPN application sends all of its data over the tcp/ip channel. There is a newer version of netcat with the famous Nmap toolset called ncat. The reason nmap adopted netcat and turned it into ncat with slight modifications, is because netcat is also designed to be used as a port scanner, and not just a remote shell interpreter.
To setup a connection with netcat, you need to install it on both systems, place your zip file within a decided path location so cmd will be able to identify your newly downloaded netcat tool, preferably in your system32 path, but you don't have to declare any variable path locations. (Update: after running a few different versions of netcat, i've noticed with some versions, you in fact do need to declare its path as an environment variable.) Once you have it installed and are ready to run, you need to open cmd, make sure you change your cmd directories location into the folder where your nc.exe is located by using the cd command.
Running nectat: On your work station, run your cmd as administrator, and put your computer into a listening state by typing this command:
nc -v -l -p 2222
nc (tool) -v (puts netcat into verbose mode) -p (is put before your specified port, which is 2222) Press enter, and now our workstation is in server mode, (listening mode).
*** Now that my workstation is in a listening mode, this means anyone that knows what port I'm listening on, can obtain access to my system because netcat doesn't use authentication by default like SSH does. And any data you send over netcat is unencrypted.
The first thing you'll get when entering this command, is an error by Windows firewall (just check public and allow access):
Now go to your target system that has netcat already installed on it, and type the following command:
nc IP_address_of_what your_workstation_is 2222 then hit enter.
You now have a two way shell between these two machines. Any comments you type on either one and then press enter, the comments will show up on the others terminal like a chat session:
 |
| When i type text on my target system |
 |
| I receive this on my workstation |
This is pointless i know. Well in a real world scenario, say if i'm an attacker, i would first need to compromise a system with meterpreter and install netcat onto the target system in the first place. Well you're probably asking, if i'm using metasploit and i've already compromised the system, what's the point of netcat? Well, opening up a socket on your port of choice, allows you to MAINTAIN an open port with netcat, sort of like a backdoor. Well this client/server chat example gives me nothing from the target. How do i get files from the target? Well if you have an established connection like the one up top, you have to cancel the connection all-together, because that's how netcat works. Depending on what commands you appended when you first made the connection, dictates what control you have over the target. This means if i setup a chat session, i couldn't then decide to start transferring files. I would need to create a whole new session.
Ok, let me try and make this clear with some examples:
Create chat session:
(on workstation) nc -l -v -p 2222 (on target) nc ip_address_of_workstation 2222
Transfer files:
(on workstation) nc -l -v -p 2222 > place_incoming_file_here.txt (on target) nc ip_address_of_workstation 2222 < send_this_file.txt
***When sending or receiving files, you use either > or < symbols. When we first setup our listening station, we NEED to indicate there is an incoming file before it's even sent to us, and give it a location on our system by typing > put file here.txt. So again, if there is someone on our target system that wants to send a file to our workstation, on our workstation you type nc -l -v -p 2222 > place_incoming_file_here.txt, press enter, then on our target system, whatever file you want to send that is on our target system, you type nc ip_address_of_workstation 2222 < send_this_file.txt, then press enter, and your file from your target system will send and save inside the file you have specified on your workstation.
 |
| This is my workstations prompt, where i first initiate as listening. |
 |
| This is my suspects prompt, where i cd to where my file is located then use the less than symbol to push the "Evidence.txt" file to the workstation. |
Now after waiting a few seconds just head over to your Local Disk (C:), then under users, then under your username, you will find your file in this directory. See below:
Control of suspects shell: (when a system is in a listening state with netcat, it can be configured to run an executable (like cmd.exe or /bin/bash) whenever a remote system connects to it. So say i want to have control of a suspects (targets) terminal or command prompt, they need to put their netcat into a listening state with the commands: (on target) nc -l -v -p 2222 -e cmd.exe. The -e switch goes before the executable you will make available to whoever connects to your system. So say for example you put your suspects system into a listening state on a windows machine, they would need to type in their command prompt the command above, and once the workstation/client machine connects to it, even if i connect to it from a linux machine, i will have control of the suspects cmd.exe, and will be able to run commands as if i were in front of the suspects command prompt (I believe this is what they call a "reverse shell"):
 |
| This Ubuntu machine is my workstation this time, and i am connecting to a victims machine that is a windows machine that is in a listening state while offering me their cmd.exe made available with the -e switch. While connected you can see the C:\Users\ turns up on my terminal, and i type in netstat -ano to get a listing of network connections and their respective PID numbers. |
Not only can i run text based commands and receive text based output, i can also start applications from this reverse shell but simply typing start firefox, you will see firefox will open on the remote box. (This really is the equivalent to owning a box, having this shell control.)
Using dd with netcat (This can only be used when both systems are Linux machines):
It is advised to used either SSH or a VPN or Cryptcat when sending a bit by bit copy of someones drive. So lets say there is a partition on my targets system that is /dev/sda, and i want to send a copy of that partition to my workstation, which is located at partition /dev/sdb?
(on your workstation): nc -v -l -w 30 -p 2222 | dd bs= 512 of= /dev/sdb/image.img. (This is saying any dd data packets that come to this station, send them to image.img that will be located on this hard drive at /dev/sdb.)
(on your target): dd if= /dev/sda | nc IP_address_of_workstation 2222. Once you hit enter, the cloning process begins. There are a few articles that recommend booting your suspects computer into a live cd, so you can unmount the active partition in order to copy it. Well, you can still use dd against a mounted partition, just make sure there aren't any current processes actively writing to the partition because this MAY cause read errors.
So at the end of the day, what tool is the best for performing a remote acquisition? That award will have to go to a third party command line tool called Psexec. Once you've downloaded and declared it under environment variables, you can connect to other windows computers remotely, even if the remote system doesn't have the Psexec tool installed. This is a huge advantage that really sets this tool apart from the others. This is also one of the reasons why it is so valuable to a pen-tester. Psexec uses the RPC protocol, which is built into windows, which allows for remote logins like ssh in Mac's. So all you need to have at your disposal, are the admin credentials of the remote system you're trying to log in to. One other thing, you need to make sure file sharing is enabled on both systems. Enable sharing to the public.
This tool is practically every other tool we talked about all rolled into one. You need administrative rights, so when you're initiating this tool, you will need to supply a user name and password. An example of typing this into your cmd workstation would look like this: \\IP_address_of_target -u username of account -p password of users account = psexec \\IP_address_of_target -u Aaron -p 123password cmd.exe.
(***Update #1: I've tried getting this tool to work for over a week now. Every time i try the above command to access a remote computer that is on the same network as me, I keep getting an "access denied". I see other people had the same issue, so i followed their possible solutions. None of them worked. I tried configuring the firewalls on both systems, i enabled admin$ shares on both systems, i even tried configuring the registry like this post suggested: Edit registry 1, and that didn't work, so there was another suggesting alternative if the first one didn't work: Registry edit 2, which i didn't attempt because i don't want to possibly screw up my system. Besides, if this is a tool that requires me to make registry changes, then no thanks. I spent a considerable amount of time trying to get psexec to work. Both computers have admin privileges, so i have no idea why it didn't work. I must say, it is incredibly frustrating not being able to get a tool to work and wasting this much time and not getting it to work. Plus, not being able to find the solution online makes this even mor. exceedingly rare and frustrating. I'll continue explaining this tool and what it's "supposed to do", and maybe someone out there has had similar difficulty with the "access denied" error.)
(***Update #2: Ok, so you are in fact able to get this tool working if you make some changes to the registry. The solution is available here: Edit Registry #3.
The command above is supposed to give you complete control of the remote computers command prompt, and any command you type in, you will receive that information inside your cmd.
An added bonus you get with psexec, is the ability to push (install) any tools you have on your workstation, to the remote system, and install them on the remote system until they are done executing. After they are finished running, psexec will delete the installed application. This is accomplished with the -c switch, ex: psexec \\IP_address_of_target -u Aaron -p 123password -c C:\Program Files\Autopsy-3.1.1\autopsy. You need to specify the tools entire path location.
There are other neat and handy tricks psexec can allow you to perform, like opening GUI's on your workstation that controls the target system, but for now, i'm calling it quits because i'm long over due in posting this. It took too long trying to figure out how to run this tools. And even now, i'm finding it hard to believe that i have to edit the registry on the targets system, in order to get it working. Both my workstations account and targets system account are admin accounts, and are both on the same Homegroup. So maybe someone out there can tell me what their experiences are with trying to run this tool. I dunno, we'll see. Oh ya, when you're logging in with psexec, the username and password are in plain text, and packets aren't encrypted until you have successfully logged into the remote machine. Like i said, there are more things i wanted to delve into with this tool, but it simply ate up too much of my time.
This is a part 1 to a series of posts that i will be attempting to discuss and present the steps one would take when responding to an incident that involved malware. This series will have a ground up approach that should involve some of the basic concepts one should know when attempting to respond to a malicious incident, hence the reason why this post focused more on the basic concepts that relate to a malware incident response, instead of just jumping right into it.
No comments:
Post a Comment