The malware starts off by resolving a list of encoded API addresses by accessing the address of kernel32 from the InMemoryOrderModuleList inside the Process Environment Block (PEB) using FS:[0x30]. It then gets the address of kernel32.LoadLibraryA and kernel32.GetProcAddress from a function which parses kernel32’s memory block. This is despite the malware already importing LoadLibraryA() and GetProcAddress(), and is used presumably to prevent automated systems from detecting massive amounts of calls to those functions.

From there, it gets the address of the other libraries it makes use of – Shlwapi.dll, Shell32.dll, Gdi32.dll, User32.dll, and Advapi32.dll. Once that is done, it calls the function which parses the various DLLs again close to 100 times in order to resolve all the APIs it uses. In the middle of those calls, it checks CheckRemoteDebuggerPresent and does not resolve the APIs from the other DLLs if a debugger is found, which will cause the malware to exit later before doing anything malicious.