Malware Journey Day 5

Overall the general apporach I am learning so far is that looking for changes made by VirtualAlloc is a excellent first step. Changes made by VirtualProtect can also change how the memory is mapped and the goal becomes to deobfuscate any memory.

Next is a look at remcos which is a .NET executable. Without going into the details I found that debugging this malware is comparable to others. Looking at changes made by VirtualAlloc in the dumped memory as well as changes made by VirtualProtect is a first good step. Next is looking at and process winapi’s. So changes made by CreateProcessInternalW could lead to possible susspened states. So setting other breakpoints like NtResumeThread could allow for investigating a process. Also looking for contents mapped in memory could lead to investigations in PEBear and PEStudio. Signatures to look for would be Microsoft Visual C++ which could tell us it is unpacked. Finally looking at imports could indicate what the malware is attempting to us. Strings is also benefical since it can indicate what the malware is attempting to do. Strings can also tell what packer is being used.

Moving away from Malware analysis, im going to look into malware development to understand more why these WIN API’s are being used.

When it comes to WIN APIs they tend to use a populated structure as formatting. An example of a Win API that uses a populated structure as input can be CreateFile, which populates it fields with input like defining what SecurityAttributes value would be. This CreateFile API Function is exported from kernel32.dll. This is actually known as a subsystem dll. I noticed a trend of after a process is called, it calls an equalivent process. Like VirtualAlloc would generally call NtAllocateVirutalMemory later on. In this case CreateFile would call NtCreateFile. This comes through Ntdll, not kernel32.dll. Currently this all happened in UserMode. Eventually its led into kernelmode when the ntdll executes the assembly in syscall which is in kernelmode.

I tried experimenting this with a malware called muster, currently I am having no success.

From the above screenshot I can see I hit the desired breakpoint of CreateFileW. I note the library to be what is expected and I regonize I am currently in usermode. My next call should be NtCreateFile, so I can execute this usermode function in the kernel. Currently I am not seeing it.When I set a breakpoint at that kernel function I notice its setting a breakpoint apphelp.dll. I expect to see Ntdll.dll. Prehaps my sample is packed so the debugger is unable to find Ntdll.dll. When trying to set a breakpoint by bp ntdll!NtCreateFile I get unavailable address.