Week-5

This week we’re taking a look at rootkits. I’m glad the the instructor Aditya has included some review of past tools in the first lecture, as I’m still feeling a bit shaky on a lot of the subject matter. I have found the tools somewhat user friendly to use in the moment, but I imagine like many software tools, using them consistently over a longer period of time leads to a deeper understanding.

Cuckoo and Agony

Running the sample

This week I’ll start off by booting up the Agony sample from lecture and taking a look through cuckoo with it. The goal here being to determine whether cuckoo can pick up on any of the nuances of this particular rootkit. My hypothesis is, no, we won’t see anything particularly interesting or else why would we be learning alternative methods to analyze malware like this!

As always, I immediately run into an issue. The file requires a password, after piazza-ing around for a moment I found the password, ‘infected’ which I guess I should have tried to begin with. Fakenet has been started and I attempt to run cuckoo!

Wathing the cuckoo terminal I immediately see a windows permission error, although I do see cuckoo attempting to run the agony virus (yay!). The mouse starts moving around the vm as I expect but eventually, cuckoo hits an irrecoverable error, something like “bad status line” and exits. Even more interesting, it looks like “bad” has stopped working and has crashed.

Time to analyze some logs!

Log analyze

First I thought I’d take a look at fakenet to see if there are any clues I can look at in the cuckoo logs. Right off the bat I see some interesting behavior, it looks like two requests were made, the first was made to toolbar.google.com on port 80 and the second was made to microsoft.com on port 80. It’s hard for me to tell if there is anything really malicious going on here because as far as I can see, these are legitimate hosts.

Looking at the cuckoo logs, it’s hard for me to know exactly whether or not changing perms in the system and updating registers is suspicious or not, but it surely looks suspicious to me!

To me it looks like here agony looks up whether it has permissions for something, adjusts the permissions, then saves some values to the computers registers, then finally goes off to install soemthing from the interent. This is pretty sketchy in my opinion but again, I’m not very familiar with windows apis or exe/dlls. This could be normal, but again most programs I can think of can operate within their given permission boundaries just fine without the need to update them on the system they’re executing on.

As was pointed out in lecture, there were three files created that cuckoo was able to capture

Running *.sys on the directory, I was also able to find the hidden sys fyles (pretty cool!)

Tuluka also turns up those suspicious running processes. Tuluka seems like a really helpful tool! I wonder how it would run on the first few samples we’ve run in the class from weeks 1 and 2.

Live Kernal Debugging

I’ve been trying to figure out what to connect windbg, the lecture just quickly skips over that part. I have Tuluka up with the three suspicious processes running, I have windbg open which is not connected, the only options that I can see to connect ask for connection strings? I’ll keep pushing forward with the lectures in the hopes that more will become clear.

Still having trouble:

I will just finish out this lecture and try to summarize my learnings.

In summary: this lab is intended to highlight the hooking abuse that some malware exploits. The malware has inserted itself to sit as a proxy between calls to (in this case) find next file and the actual execution of the find next file code. The debugging exercise is so that me as an anti virus expert, can step through the system function calls and watch as different instructions get run, noting their spot in memory. As I step through, I will see instructions that will send the execution pointer outside of teh kernal memory set. This is where the malicious code is being run. After this code gets executed, we will see the return address point back to a spot within the kernal. The ask by the instructor here is to step through and find the offeset of memory where the hook has jumped us to outside of the kernal. I’m a bit fuzzy on why the offset is important and not the actual spot in memory where the code is executed from, but I’m hoping that more will be revealed in the next series of lectures.

I’m glad the instructor in the following lectures spent time going over the concept. I think I had it pretty clear but the expansion of what a C program would look like to hadnle this problem was particularly illuminating for me. If I wanted to NOT do this by hand using windbg, I would write a C program that would find the kernal memory boundaries, read through my SSDT table and identify any memory addresses that were outside of this boundary, walk through the malicious non-kernal code and identify the return memory address (which persumably would be the original kernal address). If for whatever reason teh return address also falls outside of the kernal, we could do the walk through all over again. Finally, once the kernal address has been identified, we would patch the SSDT table with the kernal address so that the api call would no longer be hooked. The malicious code would still exist, but it would esentially be inert (at least for the purpose of hooking that api call.)

Week 5 Homework

A big portion of my learning this week was focused on working through the homework assignment! My work uses linux computers to run its server so I thought it would be a good idea for my career to work through this assignment on linux. The assignment asks for a fair amount of process statistics, so the first thing that came to my mind was to use something like bash scripts. There are some pretty simple ones like ps a which could easily fulfill the requirements for requirement 1 “Display running processes”. I thought this felt a little too much like cheating so I decided that I was going to write the whole thing in C!

/proc

As it turns out, the proc directory isn’t exactly your normal directory! It’s a special directory that’s managed by the operating system. It is where the system stores information regarding processes and the libraries to which those processes depend. This sounds exactly like what we want to accomplish this assignment. Running processes each get a directory in the /proc folder with their pid as the directory name. This means that to show what the running processes are currently, we just need to iterate through the /proc folder and print any files that are numeric in name.

Threads

From what I can tell about the behavior of /proc, threads are not given their own top level proc directory. Instead, they are added to the parent proceses /proc//task directory. To display which threads are running for which process, we can reuse the read directory code from before and simply read the task directory of the targetted process. Easy!

Child processes

Showing the currently running threads can give us a good amount of information about what’s going on on the host computer, but I thought it would also be useful to include child processes in the display as well! As it turns out, within the proc/ directory there’s a children file that contains all the child processes! Easy! All we have to do is to write this file to screen.

Shared libraries

This becomes bit more complicated than the previous tasks. Once again the /proc directory has the answers we need! Within the /proc//maps file lists all of the included binaries and their memory addresses used by the process! Perfect! Writing this to screen should satisfy the requirement, however I began running into permission issues. As it turns out, reading other bits of memory is generally not okay for a regular user like me! To solve this, I popped into a docker container which automatically runs as root. This way I could explore the proc directory unhindered.

Examine memory

The /proc//maps indicates which binaries are being used and at what memory adresses, so to examine memory I took the ending location and subtracted it from the starting location. With the size of the binary in hand, we can walk through the memory addresses at the library start and printing each byte to screen!

Summary

This project turned out to be harder than I had anticipated. As it turned out, I’d completely forgotton most of what I knew about C and furthermore, reading memory turns out to be somewhat complicated. I’m not entirely sure I was able to read the correct values, as I learned that each process has its own virtual memory addresses. Overall it was a good experience to dive into a linux machine for once and explore the system.

Until next week!