Observing COM within Malicious Code
Occasionally, malware will take a different route to achieve its desired effects by using Component Object Model objects.
Component Object Model, abbreviated as “COM”, is a technology that allows software components to communicate and interact with one another through the use of COM objects.
When analyzing malware using COM, instances of COM objects are created, allowing the malware to make use of the methods (functions) associated with object’s associated interface.
Fortunately, you don’t have to have an intricate level of knowledge about COM to recognize and understand it when viewing COM functions within disassembled code, especially if you’re using a powerful disassembler like IDA Pro.
Observe the code below, where a COM object instance is created.
Immediately you will notice the call to CoCreateInstance, which creates an instance of the object we’re going to use. A few lines down, and we’ll see another call that’s an offset to the ECX register. In order to determine which function is actually being called, we need to see which interface is being requested to communicate with our new object. This information is located at the parameter titled “riid”, which appears to be an offset.
The term “riid” means reference to interface identifier, or IID. The IID is represented as a universally unique identifier, or UUID, but it’s somewhat harder to read in IDA. If we cleaned it up, it would look like:
If we query the Windows Registry for this value, we can determine which interface our object needs.
It seems the malware wants access to the INetFwMgr interface, which will allow it to access the firewall settings on the infected computer.
To view the Interface methods in IDA, you have to import the corresponding structure for the interface. To do this, open the structures subview and press the Insert key on your keyboard after giving the window focus. Then, click “Add standard structure”.
You will be presented with a list of standard structures provided by the Microsoft SDK. Select InetFwMgrVtbl on the list and click ok. Do not select InetFwMgr, as this structure does not contain the interface methods.
You should now be able to see your structure in IDA. If you expand the structure, you should be able to see the InetFwMgr interface methods, as well as methods for inherited interfaces IDispatch and IUnknown.
With this structure, the identity of the function we saw earlier being called as an offset to ECX can finally be revealed. Simply click on that offset, and select the appropriate method.
IDA cleans up the code, adding comments to function parameters where needed. With this information, it should be safe to say this malware is interested in the user’s firewall policy, likely to permit the malware’s network traffic.
For any questions or feedback, see the comments below. Thanks for reading!
Joshua Cannell is a Malware Intelligence Analyst at Malwarebytes where he performs research and malware analysis. Twitter: @joshcannell