Week-3

Malware Defense

Yara

Introduction: Working through confusion

I started off this week (again) generally confused about what was going on. After following the lecture videos as closely as I could, I was able to determine I was supposed to scan the windows system32 directory for potential malware string matches. Turns out (again) I was overthinking it, as I dug into slack and piazza to see where and how we were supposed to run the malware examples. After rewatching the lab lectures again I came to terms with running File Insights on the malware to grab strings and then comparing the strings found across malware files.

Down to business: Finding the common strings

The first step, as I mentioned above, was for me to find the file samples and run file insights’ strings plugin on each one. I ran strings All at first but realized there was a bit too much there for me to find anything useful, and I settled on the simpler strings plugin. I saved each of the 7 sample results to .txt file so I could investigate but pretty quickly I noticed a pattern string “Jenna Jam”. This caught my eye because as some more innocent folk may or may not know, Jenna Jameson is an adult film actress and the likelyhood of a permutation of her name ending up in the system32 directory is miniscule.

As it turned out, this was a reference indeed to the film actress, as a list of movies popped up in a couple of the strings results. My guess is these are a list of popular and enticing movie titles that would get a lot of clicks if they were to be posted as free downloads. I owned the whole CKY Bam Margera dvds when I was younger. I might have clicked on a download for these if I was feeling especially piratey back in my college years.

Another common string that came up a few times was jJo!, so I figured I’d keep that one in my back pocket in case “Jenna Jam” wasn’t found in all of the sample files. Turns out, it is indeed in every one so I set out to test my luck with yara.

Yara: Test against the malware samples

I had found a common string “Jenna Jam” and I had set out to test it using Yara. The first hurdle however didn’t even come with the tooling, as I had trouble finding the executable. After using the windows search bar, I attempted for about 10 minutes to execute the directory containing the .exe file without luck. Finally realizing that the snippet I was attempting to run was in fact targetting a directory, I was able to bring up the yara help options at last. I was also able to locate the yara editor next to the yara exe and wrote my first yara rule set.

The code here depicts my yara rule after a few frustrating iterations. I had remembered in lecture the professor describing a difference between string types “ascii” and “wide” and I naively hoped he was must mentioning that to be informative but alas when I ran my yara rule as it was originally written, I was not able to target a single one of the sample files. I was sure the strings existed in there, as I’d pulled every string plugin to text and analyzed, so I figured it was the case that I was targetting the improper string types.

I was able to find some pretty spiffy documentation at the YARA site.which came in very useful. They recommended to catch all string types that I pass both keywords ‘wide’ and ‘ascii’ to my string definition and just like that, I had matches!

I finally had a rule matching against the malware samples. But would it be good enough to ignore all files within system32? (My guess, yes).

It turned out I was correct!

. There were a few files that yara likely does not have permission to scan and those show here, but otherwise there wer no hits! I contemplated this being a false positive, so I changed my yara rule to strings: "file" just to make sure and many hits were logged so I knew that my yara rule had passed the test.

Pros: My yara rule is so simple! No windows files were hurt in the running of this yara scan.

Cons: Like the professor mentioned what about the next iteration of this malware? Jenna Jameson films will probably fall out of favor at some point, my yara rules will not fair well as time passes. This ruleset could be exanpded on to target the structure of the data rather than the film names themselves, I imagine that this would be far more robust in that sense if I were able to write a rule for that case instead.

Cuckoo

Analyzing 068D5

The first sample that I took a look at seems to me not to be malicious. From what I can tell, it seems to be a keyboard driver. There’s a chance that it’s a key logger, but from what I can see there’s nothing particularly malicious. I found an itneresting method name ImmDoThings which doesn’t strike me as very Microsoft-y but poorly named functions hardly mean malware. There’s a series of calls that loop through an array and call KeyHandle which makes me think it’s just attaching handlers to keyboard keys. I’m going to shelve this sample and move on to the second one.

To add, there was also no suspicious network traffic that I could see on fakenet.

Analyzing 00670F

I attempted to run this one but unfortunately nothing showed in the cuckoo logs. I had the bad file on the desktop but there was no network traffic captured on the fakenet trap and nothing added to the cuckoo logs. I’m going to move on from this one and move onto the next sample. There was however a suspicious dx.bat file that appeared on the desktop..

Analyzing 4844FD

Okay, I think I’m having trouble with cuckoo in general now. Analyzer spins up, reports a failure and displays a quick stack trace and then exits. I’m going to try reverting my snapshot even further in case something got messed up. I keep getting this error:

Going back to #2 -> 00670F

I suspect this one is doing something malicious. It’s adding a dx.bat file to the desktop and also adding a shortcut to a (probably fake) internet explorer. However I still can’t get any loglines to show inthe C:\cuckoo\logs directory. I realized that I can’t be running fakenet when I kick off the program, but for whatever reason the cuckoo program still failed. I’ll try again on the third sample, 4844FD

Going for #4 -> A1874F

I finally got cuckoo to output some logs. There are three files, the second largest is has the process bad (the first is cmd.exe and the third has what I imagine is a pid of 292).

I started parsing through csv lines and I started googling .dll libs that I came across. One that caught my eye was ntshrui….dll. When I typed in the beginning and googled it, the results came back with a dll library that allows for file transfer via the network. This has potential to be suspicious! Transferring files over a network is normal but obviously is more risky than moving files around on a single computer.

I had a feeling I didn’t google the dll name correctly so I googled the full name ntshruis2.dll and the first hit claims that this lib is indeed dangerous! We have a winner. Further investigation on macafee show that this is likely a trojan.

Every time I’d run the program, it would delete istelf from the desktop. I finally found the line in the program where it deletes the virus source

A simple rule that I can imagine would naively catch this file specifically would be

rule fineBad
{
strings:
$a = “ntshruis2.dll” wide ascii
condition:
$a
}
Unfortunately because the the trojan deletes itself after running I don’t think that this rule actually is all that useful.

Conclusion

There is still a lot for me to learn. I feel I will be able to get a better feel for yara and cuckoo over the next few weeks. I ran into a lot of logistical issues keeping the vm running, getting cuckoo to run properly and getting it to activate the bad files. I’m hoping that by exposing myself to more tooling and samples, the logistical part of the process will get easier.

On a side note, I would be interested to know if the professional virus hunters use the same vms were using. They are slow, the desktop area space is really small (can’t show many things at the same time) and the OS keeps freezing, not responding and the screen keeps blacking out. Do professionsls use somethign different? In lecture, I remember the professor noting that they use a really old version of windows because it’s usually guaranteed to allow the virus to run. If so, that is a rough job!

Until next week!