This term, I’ve been working with two amazing colleagues to learn about the science and art of malware analysis. I’ve had many successes throughout the course, but my greatest breakthrough has to be the expansion of my knowledge around how executable files work and how they interact with the environment they run in.
This past summer I had my first opportunity to really learn about how executable files interact with the operating system at a lower level in my Operating Systems course. However, since that was only an introductory course to the lower level interactions that executable files have, I was eager to learn more in this capstone course. Analyzing malware certainly gave me more hands-on experience with that, but to be honest it was quite a struggle at first. Since my first programming language is Python (and thus the language I am most comfortable with), I was not as confident with understanding how executable files work since they are generally built with compiled languages. Therefore, I had to perform quite a bit of research and ask my teammates questions in the early stages of the project.
Over time, I learned more about how executable files utilize dependencies by either statically importing libraries during compilation time or dynamically importing them during runtime. This was a huge breakthrough for me, because I felt confused about how to perform the static analysis of the malware strains my team analyzed. Prior to learning this course, I didn’t really understand that you can still learn quite a bit about a program (both malicious and non-malicious ones) outside of using decompilers like Ghidra or Ida. Of course certain compiled programs may not yield a great deal of information if they are compiled in a way that doesn’t allow for tools like Dependency Walker or Strings to yield helpful observations, but for ones that aren’t it is very possible to learn about a program without running it.
Once I overcame this challenge, learning about the various libraries that our chosen malware utilized was much easier. Of course, I had to read lots of documentation about the various functions that each library utilized, but that in turn allowed me to understand how the malware interacts with the environment it is in. The malware we analyzed had several interesting interactions with the Windows XP environment including utilizing sockets to perform network requests, creating new files, and writing to the registry. While I won’t go into the details of how each malware sample worked (I’ll save that for my groups final project), I will say I feel much more confident in being able to ask the right questions to understand how a program works and how it interacts with the environment it is in.
This is an important breakthrough for me as an emerging cybersecurity professional, because whatever area of cybersecurity I end up in, I am confident that this capstone project will be one of the most formative experiences of my career. Outside of the technical lessons I learned, I also learned that I enjoy malware analysis quite a bit. I’m not entirely sure I would want to be a full-time malware analyst, but I know I will be able to use the skills I learned this term in whatever job I end up working in.
