Malware Analysis Patterns (Part 20)

As usual a new pattern arises with the need to communicate analysis findings. Most often when analyzing malware we don’t have symbol files (No Component Symbols) for an Unknown Module. By looking at IAT (if any present) we can guess module purpose. Sometimes a module itself is not malicious but is used in the larger malicious context such as screen grabbing:

10002000  76376101 gdi32!CreateCompatibleDC
10002004  763793d6 gdi32!StretchBlt
10002008  76377461 gdi32!CreateDIBSection
1000200c  763762a0 gdi32!SelectObject
10002010  00000000
10002024  77429ced user32!ReleaseDC
10002028  77423ba7 user32!NtUserGetWindowDC
1000202c  77430e21 user32!GetWindowRect
10002030  00000000
10002034  744a75e9 GdiPlus!GdiplusStartup
10002038  744976dd GdiPlus!GdipSaveImageToStream
1000203c  744cdd38 GdiPlus!GdipGetImageEncodersSize
10002040  744971cf GdiPlus!GdipDisposeImage
10002044  744a8591 GdiPlus!GdipCreateBitmapFromHBITMAP
10002048  744cdbae GdiPlus!GdipGetImageEncoders

There are also cases where these API names are not in IAT but found as String Hint in raw data such LoadLibrary / GetProcAddress and even a group of modules themselves as a collective API:

00058e20  "kernel32.dll"
00058e3c  "user32.dll"
00058e54  "ws2_32.dll"
00058e6c  "ntdll.dll"
00058e80  "wininet.dll"
00058e98  "nspr4.dll"
00058eac  "ssl3.dll"

We name this pattern Namespace.

- Dmitry Vostokov @ + -

Leave a Reply

You must be logged in to post a comment.