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 @ DumpAnalysis.org + TraceAnalysis.org -