New trophies !!

 

Welcome back. What follows is my review of the SANs FOR-610 GIAC Reverse Engineering Malware (GREM)  course led by the magnificent instructor Lenny Zeltser. I intend to not only give you a day-by-day breakdown but also my thoughts, mindset and overall sentiment. But before all of that let’s rewind to Jan 2019.

Fresh off of nailing OSCE I was desperately searching for something to latch onto. Could you imagine how big my eyes were when my boss informed me I would be able to take a SANs training. I felt Malware Analysis would compliment my Exploit Development experience in addition make me more valuable at work. Studying is baked into my life I never foresee this ever changing. I love to learn. I love to struggle. The dedication. The disciple. The concerted effort. I love the internal fight I always have with myself. Did I mention this event was in Orlando !? So the day of my flight comes I’m freaking pumped!

3 hour flight was fine landed safely had to strip out the hoodie because it was about 75 degrees & sunny. Checked in received all the course materials and some swag. Grabbed a bite to eat and tried to get a good nights rest. I could barely sleep like a kid on Christmas eve.

Day 1 – Malware Analysis Fundamentals

If you’ve never (sorry to hear that) been to a SANs training you get a book for each day that you work through. We were provided with 2 VMs one Windows and one REMnux (Lenny created and maintains this it’s a stripped down Ubuntu system pre-loaded with all the tools. Once again if you want a reoccurring theme here it’s he’s awesome & very intelligent) It’s quite intense as you get bombarded with tons of material. After a short introduction he jumps straight into the material. We discussed what malware is & general goals we wish to accomplish with our analysis. Some things that won’t make the sexy list but were important was how to build a analysis lab and how to create and deliver analysis report. Now is when the cool things begin to happen. “Okay class go to malware folder day one and double click on it to begin analyzing your first piece of malware”. I’m like this sounds like a mistake but let’s do it! We got pretty intimate with this piece of malware analyzing it statically dynamically and a tiny bit of code reversing in IDA. This malware had C2 functionality & dropped an encrypted config file on the system along with persistence. Here are some of the tools we’d come to use for today and remaining days

• PE Studio
• Strings/pestr
• Process Hacker
• Process Monitor
• Process Hacker
• Regshot
• Wireshark
• IDA
• x64 debug
• fakedns
• inetsim

After class let out for that day I grabbed a bite to eat and decided to crash instead of going for one of the evening talks.

Day 2 – Reversing Malicious Code

This day I heard was most feared depending on your background. I actually enjoyed it a lot. The entire day was spent inside IDA and looking through the assembly. Some things we learned this day were

• Intel Processor
• Registers
• Pointers
• Memory Addressing
• Branching
• Calling Conventions
• How functions work
• The Stack
• Control Flow

The 2nd half of the taught us how to recognize common API patterns in Malware. Keyloggers, Downloaders, Droppers ect. There was a tiny section on 64-bit code analysis that we didn’t spend much time on.  I didn’t go to any evening talk I crawled in the bed an reviewed the days materials.

Day 3 – Malicious Web and Document Files

This day was my favorite. If yesterday beat you up this day was here to pick you back up. It wasn’t easy it was fun. Since this is a way that most malware is introduced inside organizations I was very interested in this days topics. It didn’t disappoint me! We saw so much naughty malware this day. We started out deobfuscating scripts using browser debuggers, and then using standalone interpreters. Again things are intimate here so you’re learning the internal format down to the nitty gritty of the different document types and the tools you use for analyzing them. There was malicious PDFs, Office Documents (Macros), and RTF documents. What blew my mind this day was the amount of ways that JavaScript can hurt you. And why Windows has binaries to execute JavaScript. I guess being naive I simply thought about JS and what it could do inside the browser. Some tools we used this day were:

• js (SpiderMonkey)
• pdf-parser
• base64dump
• oledump
• olevba
• xor-kpa
• rtfdump

After this days class I was excited to see what this NetWars hype was all about. So when the time hit I grabbed my machine & headed down.

The atmosphere was incredible being in a room full of hackers and us going head to head. There’s nothing else like it. There was a guy who had over 400 points when the next highest guy had like 50. They took his name off the board because they said they “Didn’t want to depress us anymore” That guy was insane. I did well actually it was a lot of Linux commands, wireshark analysis. The part that tripped me up was image analysis I struggled with this and lost so much time. I fell from 4th to like 20th by end of first day.

Day 4 – In-Depth Malware Analysis

We learned a ton of stuff this day. Recognizing and unpacking malware. Debugging packed malware. The  2nd half of the day we learned and examined a fileless piece of malware. It was wicked! Some topics in the 2nd half of the day we learned were API Hooking and Code Injection. We also spent time learning a little bit of memory forensics. Some tools we used this day were

• upx
• scdbg
• volatility

I decided not go to the 2nd day of netwars. Went on a walk exploring the area where our hotel was and chillen by the pool.

Day 5 – Examining Self-Defending Malware

Awesome day spent learning about malware that fights you back or purposely makes it difficult to analyse. We learned about Process Hollowing and the normal techniques malware authors employ to detect debugging. Some tools used this day were

• brxor
• bbcrack
• floss
• scylla

Last day of learning & it’s Friday but who care because I’m spent. Went to the room and crashed.

Day 6 – CTF

Get to class at 8:30 and setup my machine, grab my Redbull and prepare for the fight. There’s about 20 people in the class most of them seemed very intelligent. I knew a few of them were fulltime malware analyst but it’s always fun to see where you end up when competing with others. I enjoy the competition. So the CTF was everyone on their own no teams and top 5 people win coins. We had our own scoring server that updated in real time as you earned points so it was intense. For 5 hours we leveraged what we learned to answer questions about different malware samples. Now when we first started on Monday I had to think about everything because it was all new to me. On this day I remember running to the bathroom and thinking damn! You’re not even thinking about this you’re just doing it. Gave myself a bro hug. When the dust settled I had a coin & it was the perfect icing on the cake.

Studying For The CERT

When I fly back home I immediately reviewed each book. I don’t create an index but I use the color tab thingy’s to mark sections I think are important and also highlight anything relevant of course. The end result of this madness looks similar to this

This was like retaking the entire course it really helped me reinforce topics I knew I was weak on. It also helped me understand where things were in each book. This is valuable because although the exam is open-book you don’t have much time to search for things. After this was done I got access to the MP3 recordings. I listed to all of them in the car, on the train, at lunch, and evening time this was the only thing I did. I went to sleep to Lenny’s voice and woke up to it. This again was like taking the course again it helps tremendously. In between this time I also took the 2 practice test they give you. I scored a 76 on first one and 84 on the second one. It was great to have an idea of the type of questions. So I originally scheduled the exam for a Saturday. At this point I felt like I took the class 3 times and went thru the books like a zillion times. It was Thursday night. I said forget waiting until Saturday you’re taking this exam tomorrow. Luckily the testing center had availability and I rescheduled it. After I did it I though “You’re a fucking fool” But let’s do this!

The Exam

Wake up gather my materials, buy  a Redbull and a water and off I go. I gave myself ample time to get to the testing center absolutely can’t be late. I got there 1 hour early at 8 AM and they allowed me to take the exam immediately. Astonished I couldn’t bring my Redbull in the testing area so I downed it. Testing at a center is so funny because you can’t have anything besides your materials all your belongings get stored in an assigned locker. They made me lift up my hair, pants legs I was like WTF those folks would make awesome TSA agents. The exam was HARD but I felt prepared. I finished it in 1 hour and this is what it ended up as

I was soo proud of myself!
And when you get 90 (90.7 counts) or higher you get an invitation to the GIAC Advisory Board.

I encourage you to take the class if you can but only if it’s with Lenny. He answered 1 million and one of my questions & he gives off good vibes.
Take care guys – until next time.

The post GIAC Reverse Engineering Malware (GREM) Review appeared first on Certification Chronicles.

Prologue

I feel like I should confess. Why? Because I’ve fought with myself for the past hour debating on how to spend this Friday evening. I 100% should be continuing my Malware Analysis Workbook to keep making steady progress in preparation for the exam. GREM should be fun, I’m looking forward to it & blogging about the entire experience. At the moment I really don’t feel like “analyzing” anything. I feel like doing! Attempting to make or break something. The brain wants what the brain wants. Here’s how I rationalize things to myself in these situations. If the thing that I’ve yet to figure out what it is, is in someway somehow related to what I should really be doing then guess what, IT’S FINE. So shoot let’s just start an entirely new series on something I totally just came up with.

I have come to understand that there are patterns in malware. But before that – ask yourself what exactly is malware? Here’s where I think the definition from Lenny’s course rings volumes. It’s incredibly non-technical and very subtle. “Malware is code that is used to perform malicious actions.” This leads you to the realization that it’s not per se the capabilities of the software but the intent of the person using or authoring it. We’ll stop right there because my purpose isn’t malware analysis in this post. (You can wait until I take the certification I”ll be sure to blog about the entire process from the first day of the course through to the cert) It’s about patterns remember. So sir, what are these patterns you speak of?

Software is typically developed in a high level language & compiled into a binary executable. What’s the best language to develop?  I always enjoy this debate because I’ve played with most of them & can usually argue either way depending on the side my opponent takes. Truthfully it’s preference & how familiar the developer is with the language. Different jobs are accomplished utilizing different tools. Some popular high-level languages are C/C++, Python, Delphi, and Java. Now I purposely left out scripting and interpreted languages , I include Python just because it’s awesome & you can usually accomplish the same as a compiled language with it. I know Java and the JVM so you don’t have to beat me up. Majority of malware is written in C/C++ you could also use Python using CTypes and then compile into an executable but let’s not account for that. It shouldn’t surprise you that malware needs to accomplish many of the same task as ordinary software. Things like reading and writing to disk, network communication, spawning child processes, allocate dynamic memory, painting to the screen and the list goes on. Now these things individually aren’t particularly nefarious. But in groups you can get an idea of what it’s trying to do.

How do you leverage C to write malware? You leverage this surprisingly unicornishly resource call the Windows API from MSDN. It’s how you programmatically interact with everything in the Windows environment. And if you’re thinking they missed a inch, they didn’t! So much so, there’s a group of folks who scoured the entire API (documented and undocumented), pre-loaded binaries and DLLs and created LOL-Living Off The Land. To say that the API is rich would be an understatement. You can do any and everything with it because what’s the point of have an Operating System if it’s not extensible & account for each and every obscure thing a developer might ever want to do. Poor Microsoft.

Here’s an example, we get a malware sample and during the static analysis we look at it’s imports and see function calls to, GetKeyState – GetAsyncKeyState – SetWindowsHookExA. Very quickly you can get a feel for what it potentially might be maybe without even visiting the documentation. In this case a keylogger potentially. This is what I mean when I mention patterns above. This series will begin with the small building blocks before we go full blown into replicating our own malware. This is what I meant when I said I wanted to “attempt to make or break something”. Again, learning is a contact sport and maybe from failing & being stuck so much I don’t mind it. I haven’t developed professionally in years and if I do anything now Python’s usually my go to. So pure C is a challenge I’m totally up for and I hope by the end I can say I improved. I’ve also never written a piece of malware nor it’s components. I encourage you to fight through the cryptic naming conventions grab a C book if you need and just persevere. The best way is to just start. I spun up a VM specifically for developing, downloaded & installed the latest VisualStudio and off I went.

Process & Thread Enumeration

I figured this was an awesome place to begin because it’s pervasive throughout malware. Possibly for anti-debugging, maybe to send off as information gathering to a C2, or searching for vulnerabilities that may aid in privilege escalation. Whatever the reason it’s widespread, gives me a reason to be writing this and is a friendly introduction to C. I will present the code & then explain it in plain English.

1
#include stdio.h
#include Windows.h
#include TlHelp32.h
#include tchar.h

2
BOOL GetProcessList();
BOOL ListAssociatedThreads(DWORD dwProcessID);

3
int main(void)
{
	GetProcessList();
	return 0;
}

4
BOOL GetProcessList()
{
	PROCESSENTRY32 process_structure; 
	HANDLE handleToProcessSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); 5

        6
	if (handleToProcessSnapshot == INVALID_HANDLE_VALUE) {
		_tprintf("Failed To Obtain Handle To Process Snapshot");
		return FALSE;
	}

        7
	process_structure.dwSize = sizeof(PROCESSENTRY32);

        8
	if ( !Process32First(handleToProcessSnapshot, &process_structure) ) {
		_tprintf("Failed To Get Obtain Data About First Process - Last Error = %d\n", GetLastError());
		CloseHandle(handleToProcessSnapshot);
		return FALSE;
	}
	do
	{
                9
		_tprintf("\n\n=====================================================");
		_tprintf("\n Process Name:  %s",           process_structure.szExeFile);
		_tprintf("\n Process ID:  0x%08X",         process_structure.th32ProcessID);
		_tprintf("\n Parent Process ID: 0x%08X",   process_structure.th32ParentProcessID);
		_tprintf("\n Thread Count:  %d\n",         process_structure.cntThreads);
              
                10
		ListAssociatedThreads(process_structure.th32ProcessID);
		_tprintf("\n\n=====================================================");

        11
	} while ( Process32Next(handleToProcessSnapshot, &process_structure) );
	CloseHandle( handleToProcessSnapshot );
	return( TRUE );
}

BOOL ListAssociatedThreads( DWORD dwProcessID ) 
{
	THREADENTRY32 thread_structure;
	HANDLE handleToThreadSnapshot = CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, 0 );

	if ( handleToThreadSnapshot == INVALID_HANDLE_VALUE ) {
		_tprintf("Failed To Obtain Handle To Thread Snapshot");
		return FALSE;
	}
	thread_structure.dwSize = sizeof( THREADENTRY32 );

	if ( !Thread32First(handleToThreadSnapshot, &thread_structure) ) {
		_tprintf("Failed To Get Obtain Data About First Thread - Last Error = %d\n", GetLastError());
		CloseHandle( handleToThreadSnapshot );
		return FALSE;
	}
	DWORD dwThreadCount = 1;
	do {
		if ( thread_structure.th32OwnerProcessID == dwProcessID ) {
			_tprintf("\tThread ID-%d: 0x%08X\n", dwThreadCount, thread_structure.th32ThreadID);
			dwThreadCount++;
		}
	} while ( Thread32Next(handleToThreadSnapshot, &thread_structure) );
}

You may have noticed that I didn’t bother numbering the second function call. That’s because it’s basically identical to the first. I will illustrate the difference when we reach a piece that’s different.

1. These are the imports. An import is just a library that holds tons of functions for us to call. They only exist to be used by us so long as we import them first. This makes them happy.
2. Function declarations. These are used to help with compile time error checking. In this case it says we’re creating 2 function, that are of type Boolean(true/false), their respective names, and any arguments they may expect. It’s like an early warning system. For instance, if we began to write the function body (that one takes an argument named dwProcessID) and we forgot to include it, the compiler understands from our declaration it should be there. So it immediately complains, we call ourselves silly – correct it and move on.
3. Main method. It’s the entry-point for the entire program. Execution starts here you don’t need to think about it. We call our 1st function here and for clarity include the return statement.
4. This looks similar to the function declaration but without the ; and statements within the { } brackets. Inside these brackets is our function body (the purpose of the function).
5. I like to think about a Window’s Handle as a pointer to a system resource. It’s a more abstract level for instance if you wanted to read a file, you’d call the appropriate function – obviously passing it amonst other things the filename. You wouldn’t get a file back or an object you’d get back a Handle. Then all further processing you refer to the handle.In our case we make a call to CreateToolhelp32Snapshot this function comes from the tlhelp32.h import. We search MSDN and understand the arguments to pass it, one being TH32CS_SNAPPROCESS along with the 0 argument says, “Give me a handle snapshot of all the running processes on the system at this point in time”.In the 2nd function this call is also made again but this time with a different 1st argument TH32CS_SNAPTHREAD. Appropriately named since the first functions grabs all the processes then we find each processes associated threads.
   
6.  Error checking. From MSDN we know that if the call to get the process snapshot fails it’ll return that symbolic constant INVALID_HANDLE_VALUE. You could make a call to GetLastError() to further debug.
7. Important. MSDN told me this. You need to set the size field of the structure before you make the call to the next function. If you don’t do this, the call automatically fails.
8. Call to Process32First this is how we actually make a call to get the first process. It takes as arguments, the handle and the structure who’s member we had to initialize. We put this call inside an if statement, if we encounter an issue we fall into the error printing statements included in that statement and close the handle so it’s not a stray.
9. Success! If we reach here it means we’re good – we’ve gotten the data associated with our first process in the snapshot. That structure we set the size on now is populated with the relevant data returned from the function call. Some of those things are the process’s name, ID,  it’s parent process ID, thread count and a host of other thing. Break after the call to view all the relevant fields in the structure or just Google it.
10. Determine which threads belong to this process. As mentioned earlier that function is very similar except it takes a snapshot of all the threads, and then we compare the process ID we pass into the function to the threads parent process ID.
11. Notice the call to the Process32Next function as the continuing condition for the do-while loop. This function will move to the next process in the snapshot.

Here’s some output:

 

Epilogue

We’re going to build up to something awesome I promise. Obviously this is for educational purposes only.
NOTE: If you want to compile the code just remove the numbers I included to explain the different sections.

Until next time!

The post The Usual Suspects – Malware Snippets – Part 1 appeared first on Certification Chronicles.