You are browsing the archive for 2012 August.

Finding Smoking Gun and going beyond that – Helpful Forensic Artifacts

August 23, 2012 in Compromise Detection, Forensic Analysis, Malware Analysis, Preaching, Tips & Tricks

While I am quite critical about the idea of collecting IOCs (Indicator of Compromise) describing various malware, traces of hacking, etc in a form of hashes, even fuzzy hashes, file names, sizes, etc., etc.  I do believe that there is a certain number of IOCs (or as I call them: HFA –  Helpful Forensic Artifact – as they are not necessary relevant to compromise itself) that are universal and worth collecting. I am talking about artifacts that are common to malware functionality and offensive activities on the system in general as well as any other artifact that may help both attackers and… in investigation (thanks to ‘helpful’ users that leave unencrypted credentials in text files, watch movies on critical systems, etc.).

In this post, I will provide some practical examples of what I mean by that.

Before I kick it off, just a quick reminder – the reasons why I am critical about bloated IOC databases is that they have a very limited applicability in a general sense; and the limitations come as a result of various techniques used by malware authors, offensive teams, etc. including, but not limited to:

  • metamorphism
  • randomization
  • encryption
  • data (e.g. strings) build on the fly (instead of hardcoding)
  • shellcode-like payloads
  • fast-flux
  • P2P
  • covert channels
  • etc.

Notably, antivirus detections of very advanced, metamorphic malware rely on state machines not strings and it’s naive to assume that collecting file names like sdra64.exe is going to save the day…

Anyway…

If we talk about good, interesting HFAs I think of things that:

  • are very often used in malware because of a simple fact they need to be there (dropping files, autostart, etc.)
  • traces of activities that must be carried on the compromised system (recon, downloading toolchests, etc.)
  • also (notably) traces of user activity that support attacker’s work (e.g. a file password.txt is not an IOC, but it’s HFA)
  • traces of system being affected in a negative way e.g. if system has been compromised previously by a generic malware, certain settings could have been changed (e.g. disabled tracing, blocked Task Manager, etc.); they are IOCs in a generic sense, but not really relevant to the actually investigated compromise; you can think of it of these aspects of system security that place the system on the opposite side to the properly secured and hardened box; it also included previously detected/removed malware – imho AV logs are not ‘clear’ IOCs as long as they relate to the event that is not related to investigated compromise

If we talk about a typical random malware, it’s usually stupidly written, using snippets copied&pasted from many sources on the internet. The authors are lazy and don’t even bother to encrypt strings, so detection is really easy. You can grep the file or a memory dump of a suspected process for typical autorun strings with strings, BinText, HexDive and most of the time you will find the smoking gun. If the attacker is advanced, all you will deal with is a blob of binary data that has no visible trace of being malicious unless disassembled – that is, a relocation independent, shellcode-like piece of mixed code/data in a metamorphic form that doesn’t require all the fuss of inline DLL/EXE loading, but it’s just a pure piece of code. It’s actually simple to write with a basic knowledge of assembly language and knowledge of OS internals. I honestly don’t know how to detect such malware in a generic way. I do believe that’s where the future of advanced malware is though (apart from going mobile). And I chuckle when I see malware that is 20MB in size (no matter how advanced the functionality).

When we talk about IOC/HFAs and offensive security practices, it is worth mentioning that we need to follow the mind process of an attacker. Let me give you an example. Assuming that the attacker gets on the system. What things s/he can do? If the malware is already there, it’s easy as the functionality is out there and can be leveraged, malicious payload updated and attacker can do anything that the actual payload is programmed to do and within the boundaries of what environment where it runs permits. On the other hand, if it is an attack that comes through a typical hacking attempt, the situation is different. In fact, the attacker is very limited when it comes to available tools/functionality and often has to leverage existing OS tools. This means exactly what it says – attacker operates in a minimalistic environment and is going to use any possible tool available on OS to his/her benefit. If we talk about Windows system, it can be

  • net.exe (and also net1.exe)
  • telnet.exe
  • ftp.exe

but also

  • command.com
  • cmd.exe
  • debug.exe
  • makecab.exe
  • diantz.exe
  • netsh.exe
  • netstat.exe
  • route.exe
  • hostname.exe
  • sc.exe
  • arp.exe
  • shutdown.exe
  • findstr.exe
  • at.exe
  • attrib.exe
  • cacls.exe
  • xcacls.exe
  • ping.exe
  • tracert.exe
  • runas.exe
  • more.com

and OS commands

  • echo
  • type
  • dir
  • md/mkdir
  • systeminfo

and many other command line tools and commands.

So, if you analyze memory dump from a Windows system, it’s good to search for presence of a file name associated with built-in windows utilities and look at the context i.e. surrounding memory region to see what can be possibly the reason of it being there (cmd.exe /c being the most common I guess).

Back to the original reason of this post – since I wanted to provide some real/practical examples of HFAs that one can utilize to analyze hosts, let me start with a simple classification by functionality/purpose:

  • information gathering
    • net.exe
    • net1.exe
    • psexec.exe/psexesvc.exe
    • dsquery.exe
    • arp.exe
    • traces of shell being used (cmd.exe /c)
    • passwords.txt, password.txt, pass.txt, etc.
  • data collection
    • type of files storing collected data
      • possibly password protected archives
      • encrypted data (e..g credit cards/track data)
    • various 3rd party tools to archive data:
      • rar, 7z, pkzip, tar, arj, lha, kgb, xz, etc.
    • OS-based tools
      • compress.exe
      • makecab.exe
      • iexpress.exe
      • diantz.exe
    • type of collected data
      • screen captures often saved as .jpg (small size)
      • screen captures file names often include date
      • keystroke names and their variants
        • PgDn, [PgDn],{PgDn}
        • VK_NEXT
        • PageDown, [PageDown] {PageDown}
      • timestamps (note that there are regional settings)
      • predictable Windows titles
        • [ C:\WINDOWS\system32\notepad.exe ]
        • [ C:\WINDOWS\system32\calc.exe ]
        • [http://google.com/ – Windows Internet Explorer]
        • [Google – Windows Internet Explorer]
        • [InPrivate – Windows Internet Explorer – [InPrivate]]
      • possible excluded window class names
        • msctls_progress32
        • SysTabControl32
        • SysTreeView32
      • content of the address bar
      • attractive data for attackers
        • regexes for PII (searching for names/dictionary/, states, countries, phone numbers, etc. may help)
        • anything that matches Luhn algorithm (credit cards)
      • input field names from web pages and related to intercepted/recognized credentials
        • user
        • username
        • password
        • pin
      • predictable user-generated content
        • internet searches
        • chats (acronymes, swearwords, smileys, etc.)
  • data exfiltration
    • who
      • username/passwords
    • how
      • ftp client (ftp.exe, far.exe, etc.)
      • browser (POSTs, more advanced: GETs)
      • DNS requests
      • USB stick
      • burnt CD
      • printer
    • how
      • just in time (frequent network connection)
      • ‘coming back’ to the system
    • configuration
      • file
      • registry
      • uses GUI (lots of good keywords!)
    • where to:
      • URLs
      • FTP server names
      • SMTP servers
      • mapped drives (\\foo\c$)
      • mapped remote paths (e.g. \\tsclient)
  • malicious code
    • any .exe/.zip in TEMP/APPLICATION DATA subfolders
    • processes that have a low editing distance between their names and known system processes (e.g. lsass.exe vs. lsas.exe)
    • processes that use known system processes but start from a different path
    • areas of memory containing “islands” with raw addresses of APIs typically used by malware e.g. CreateRemoteThread, WriteProcessMemory, wininet functions
  • mistakes
    • Event logs
    • AV logs/quarantine files
    • leftovers (files, etc.)

Many of these HFAs form a very managable set that when put together can be applied to different data sets (file names, file paths, file content, registry settings, memory content, process dumps, etc.).

In other words – instead of chasing after a sample/family/hacking group-specific stuff, we look for traces of all these things that make a malware – malware, a weak system – weak, a hack – hack and attack-supporting user – victim.

HexDive 0.4

August 19, 2012 in HexDive, Malware Analysis, Software Releases

It’s been a while since I updated HexDive, so I took some time today to fix a few things + add new keywords.

So, what’s new?

Mainly lots of new keyword sets. Some are just a tip of an iceberg and I will be extending these as I go through a malware collection in the future, but even at this stage these should certainly help in picking up some new interesting stuff, including but not limited to:

  • new banking-related strings
  • more information stealing strings (PStore, Firefox, FTP programs, Certificates, etc.)
  • keystrokes (thx Corey)
  • anti-sandbox tricks (partially based on an excellent summary post from Joe Security LLC and interesting new technique described by F-Secure)
  • swearwords
  • lots of new registry keys related to settings, games, P2P, and lots of other applications
  • some default passwords occasionally used by worms
  • generic malware strings (lots of them, I still need to classify them, but at least they are already in the set)

You can download current version of HexDive here. If your .exe download is blocked, you can try a zip file.

p.s.

I still don’t pay too much attention to a Linux version – this is lower priority than a different feature I am currently working on (stay tuned).

 

Bonus update:

hdive ran over two gauss samples

  • 08D7DDB11E16B86544E0C3E677A60E10_100-dskapi.ocx
  • 5604A86CE596A239DD5B232AE32E02C6_smdk.ocx

Various classes of interesting strings are highlighted:

08D7DDB11E16B86544E0C3E677A60E10_100-dskapi.ocx

CorExitProcess
mscoree.dll
null
null
support
open
support
support
kernel32.dll
local
local
local
default
local
dddd, MMMM dd, yyyy
GetLastActivePopup
GetActiveWindow
MessageBoxA
USER32.DLL
SunMonTueWedThuFriSat
urlmon.dll
SeTakeOwnershipPrivilege
inflate
deflate
abcd
ABCD
abcd
SeRestorePrivilege
SeTakeOwnershipPrivilege
SeRestorePrivilege
LoadLibraryW
kernel32.dll
GetCommandLineW
Sleep
kernel32.dll
FreeLibrary
kernel32.dll
VirtualFree
kernel32.dll
ExitThread
kernel32.dll
DeleteFileA
kernel32.dll
MoveFileExA
kernel32.dll
ntdll.dll
SeRestorePrivilege
SeBackupPrivilege
RegCreateKeyExW
RegSaveKeyW
RegRestoreKeyW
RegOpenKeyExW
RegFlushKey
RegCloseKey
RegSetValueExW
RegDeleteValueW
RegQueryValueExW
ObtainUserAgentString
HttpSendRequestW
InternetQueryOptionW
InternetSetOptionW
InternetCloseHandle
InternetQueryDataAvailable
HttpAddRequestHeadersW
InternetReadFile
HttpQueryInfoW
InternetOpenW
InternetConnectW
HttpOpenRequestW
OpenProcessToken
ImpersonateLoggedOnUser
AdjustTokenPrivileges
LookupPrivilegeValueW
RegDeleteKeyW
SetEntriesInAclW
FreeSid
MoveFileExW
CloseHandle
DeleteFileW
CreateMutexW
Sleep
GetCurrentProcessId
VirtualAlloc
LoadLibraryW
CreateThread
GetModuleFileNameW
VirtualFree
GetCurrentProcess
GetModuleHandleA
OpenProcess
GetLastError
GetFileSize
ReadFile
CreateFileW
GetPrivateProfileStringW
FreeLibrary
GetProcAddress
GetSystemTime
DuplicateHandle
MultiByteToWideChar
LoadResource
SizeofResource
LockResource
GetVersionExW
CreateToolhelp32Snapshot
GetFileAttributesW
GetModuleHandleW
SetFileTime
WriteFile
Process32FirstW
ReadProcessMemory
Process32NextW
WriteProcessMemory
VirtualAllocEx
CreateRemoteThread
VirtualFreeEx
LocalFree
LocalAlloc
LoadLibraryA
TerminateProcess
SetUnhandledExceptionFilter
IsDebuggerPresent
GetCurrentThreadId
GetCommandLineA
HeapFree
GetVersionExA
HeapAlloc
ExitProcess
GetFileType
GetStartupInfoA
DeleteCriticalSection
GetModuleFileNameA
FreeEnvironmentStringsA
GetEnvironmentStrings
FreeEnvironmentStringsW
WideCharToMultiByte
GetEnvironmentStringsW
HeapDestroy
HeapCreate
QueryPerformanceCounter
GetTickCount
GetSystemTimeAsFileTime
GetCPInfo
GetACP
LeaveCriticalSection
EnterCriticalSection
InitializeCriticalSection
SetFilePointer
GetStringTypeA
GetStringTypeW
GetLocaleInfoA
WriteConsoleA
WriteConsoleW
CreateFileA
FlushFileBuffers
GetSystemMetrics

5604A86CE596A239DD5B232AE32E02C6_smdk.ocx

CorExitProcess
mscoree.dll
null
null
support
open
support
support
local
local
local
default
local
kernel32.dll
dddd, MMMM dd, yyyy
england
chinese
chinese
chinese
chinese
GetProcessWindowStation
GetLastActivePopup
GetActiveWindow
MessageBoxA
USER32.DLL
SunMonTueWedThuFriSat
deflate
Jean-loup Gailly
Mark Adler
true
RegOpenKeyW
RegCloseKey
RegQueryValueExW
RegOpenKeyExW
TerminateThread
CreateThread
Process32NextW
CreateToolhelp32Snapshot
GetLastError
Process32FirstW
DuplicateHandle
GetCurrentProcess
SetEvent
GetLogicalDriveStringsW
GetSystemTime
DeviceIoControl
CreateFileW
GetDriveTypeW
FindClose
FindFirstFileW
FindNextFileW
LocalAlloc
GetProcAddress
FreeLibrary
LoadLibraryA
TerminateProcess
SetUnhandledExceptionFilter
IsDebuggerPresent
GetCurrentThreadId
GetCommandLineA
HeapFree
GetVersionExA
HeapAlloc
GetModuleHandleA
Sleep
ExitProcess
GetFileType
GetStartupInfoA
DeleteCriticalSection
GetModuleFileNameA
FreeEnvironmentStringsA
GetEnvironmentStrings
FreeEnvironmentStringsW
WideCharToMultiByte
GetEnvironmentStringsW
HeapDestroy
HeapCreate
VirtualFree
QueryPerformanceCounter
GetTickCount
GetCurrentProcessId
GetSystemTimeAsFileTime
GetCPInfo
GetACP
LeaveCriticalSection
EnterCriticalSection
VirtualAlloc
WriteFile
InitializeCriticalSection
MultiByteToWideChar
GetStringTypeA
GetStringTypeW
GetLocaleInfoA
SetFilePointer
WriteConsoleA
WriteConsoleW
CreateFileA
FlushFileBuffers
GetFileSize
GetFileAttributesW