Malware analysts are a professionality itself in infosec. Though, when people in infosec hear "malware analysis" most jump directly to binary analysis and reverse engineering. While this is not untrue, this certainly isn't "the whole" truth.

Malware analysis =/= reverse engineering

That statement seems quite obvious, but it really isn't. Of course many people in malware analysis use reverse engineering, either to assembly or a decompiler tries to recognize and rebuild the program in the original programming language. To make this harder malware devs use polymorphic code and other fancy tricks to make it a pain in the ass to understand what their program does by just looking at the program code. So, while reverse engineering is a huge benefit for malware analysts and malware devs actively work against it, there are also other ways to analyze a program.

Malware Analysis: The Overlooked

Many people tend to use terms, but not actively think about them or the meaning they convey. This isn't just a problem in this instance, but generally throughout the public as a whole. The overlooked part of malware analysis really is the analysis part. Analysis in short basically just means the observation of something, seeing how it behaves in a specific environment etc. So instead of just looking at the low level assembly and similar, malware analysts are free to go to higher abstraction layers.

Simple things like setting up a virtual machine, running the malware inside it and looking at the network traffic or generally observing the virtual machine before and during the malware was unleashed can reveal much about the malware itself and the approach of the malware developer, maybe even hinting what vulnerability in the system they used.

My analogies are well known from people around me to be either quite inappropriate or "special", but to me analyzing the code vs observing it running inside a secured environment is like the difference between neurology & psychology. Both have their important roles and work together in harmony for the professional, but sometimes you want to choose one over the other, or approach a given problem with a method from one speciality first, before you go to the next and get the bigger picture as a result in the end.

It's not as easy as that though

Unfortunately, setting up a virtual machine and expecting any piece of malware to run inside it is quite unrealistic. If malware devs were generous enough to make things a lot less complicated, our job would be much easier. Obviously, this isn't the case though. One of the common approaches of malware is to check things like the temperature of the CPU for example. If the temperature can't be read or something similar to that, the malware assumes that it's run inside a virtual machine and either just won't run or takes measurements to ruin your whole day, trying to analyze the malware.

Conclusion

This was a quite short article, but one I wanted to make before I forget doing so. I've heard from some or a few analysts at least, that this is what bothers them about the infosec community's perception of malware analysis as a topic. Funnily enough, the people who seemingly take the "lazy approach" to malware analysis are the most respected ones. They either don't bother with reverse engineering, because they really just don't know it and don't have the nerves to learn it, or they just do it because it gets their job done. This is also quite an important conclusion to myself and a reminder for everybody in infosec. Why make your job harder than it already is? It's not like we're competing with who makes the biggest effort in our industry, we should strive to become as efficient as possible. Cheers.