I work in a security position and one thing I have heard a lot of confusion about is some of the generations of newer infections and why even newer machine learning and AI based AV solutions cannot detect some of these infections. I am not aiming to do a largely technical tear down of any of these threats as there are labs with better resources and who are more knowledgeable who can do a far better job than I could hope to at this point (there is a tremendous amount of work that goes into tearing an infection apart). In short, this is going to be a high level introduction to the basics of what I am terming Object-Oriented Malware for lack of a better term explaining some of how it works and why it is so efficient at cutting through security solutions.
What Does Object-Oriented Mean?
When it comes to programming, one of the most popular techniques is Object Oriented programming. To simplify this as much as possible (so excuse any technicalities if you have programmed before), this basically means you make objects which contain both data and functionality for said data. Concepts like encapsulation and polymorphism mean that objects can encapsulate their own data and provide, or not provide, ways to interface with internal data, and that objects can be defined like cat and dog which are derived from animal which can then have shared functionality that is applied differently in the derived class respectively. Basically, objects allow greater abstraction and functionality than traditional methods and allow a way to make components reusable and able to better interface at a higher level.
So What Does This Have To Do With Malware?
We’ve covered the programming side of an object oriented approach, but how does this apply to malware? Newer classes of infection like Trickbot or similar will use a heavily distributed approach that resembles certain object oriented approaches. For newer infections, you will see many small pieces each working together to create a larger effect which would be hard to surmise from looking at the smaller, individual pieces. Certain pieces will be innocuous on analysis, others set up processes and persistence without anything malicious, and others may just tie these pieces together to create the final payload. These are able to evade antivirus software as nothing in this chain except the final payload actually does anything malicious, and even then, there are techniques they employ to launch the payload in ways traditional security suites struggle to detect.
To further complicate this, some of these processes may use somewhat legitimate looking processes to hide the infection from the OS or to begin trying to obfuscate the process further in order to confuse AV. These obfuscation methods may leverage exploits, or even launch a separate class of infection via several levels of redirections to test the waters on what the infection can do. Due to the heavily modular nature of these infections and their payloads, most individual pieces are effectively obfuscated to the point a single piece doesn’t even have any kind of reference of details on what it actually does, it merely performs its singular function as requested.
The above diagram shows how this process works from a combination of a couple techniques I have seen in recent infections. This diagram is heavily simplified, but that will be touched on below. Basically, these are typically loaded by an infected file (usually a document like a fake invoice or similar). From here, some kind of exploit takes place (the exact exploit depends on the malware itself, but it’s usually some kind of arbitrary code execution or zero day) which then runs a main process which will then pass its duties off to either another process, or a combination of processes which look for further exploits on the machine or run through whatever logic there may be. The infection piece which kicks this off typically does not try to do too much at this point except get ready for the actual infection (though it may do more depending on the design).
From here, the exploit process will try to establish permanence if it can via a mix of scheduled tasks or services. There are other processes which it can follow for this, but again, this depends on design. If this process is blocked or fails, the infection may be able to continue with another predesigned exploit process from the main infection process. Some of these have even been tied to previous “drive by” attacks where the site will have a random attack or set of attacks which are mainly looking to mine data on how the site will respond. There is not goal at this point, though they may “smash and grab” data if the opportunity presents itself. The exploit process will look to begin doing the more in depth infection and actual payload delivery via multiple pieces.
Why These Elude Detection
One way to prevent detection is to not incorporate a fixed payload or even a downloader in the main process. I typically see multiple “downloader” processes at this point which serve to download obfuscated parts of the final payload. You may see the file split, you may see multiple files which are combined in some algorithmic way in order to create a payload. There are so many levels of obfuscation that this can follow for infection. These processes are also typically handed off in a way to make forensics harder without a test machine too. The infection may start a process a certain way, infiltrate the process, then hand this off to another process which serves as the downloader.
A process to obfuscate the payload may be involved as well. This process serves merely to hide what is going on or to cover tracks. It typically does this without anything malicious unless a rootkit has been delivered, in which case, it may still do something which is not malicious but with extremely malicious intent. A payload combiner will probably be separately launched as well in order to combine the payload however it can in order to obfuscate the intent of the process. Something else will probably be kicked off in a similar fashion in order to actually launch the payload. Another thing to keep in mind, just because one of these may fail, does not mean the process will fail. The point of establishing permanence is to be able to reload and relaunch this many different ways over and over again until a success condition is reached.
These processes can be further obfuscated in many different ways depending on the creator or toolkit employed to design this type of infection. Each sub-process may recursively follow this flowchart to perform each step just to add difficulty in tracking down the infection or to increase the chances of success. The thing that complicates this is that some infections generate new methods on the fly as well. The use of machine learning and AI is not just limited to antivirus solutions. There are toolkits which use machine learning and similar to generate horrendously obfuscated code that makes no sense without careful analysis.
Conclusion
By splitting up the infections into multiple, smaller components and objects, these classes of infections can get around a lot of security setups when they’re launched, but preventing them from launch or preventing them from being run will ultimately provide the best protection possible. Educating users to not blindly run macros for documents can mitigate a good number of these types of exploits. Proper antivirus and mail filtering will help prevent the chance for a lot of these to even make it to the end users as well. Object oriented malware is only going to get more and more common, so stopping these infections before they get hooked is ultimately the safest defense.
Image by S. Hermann & F. Richter from Pixabay