 This is the analysis of the first dropper Excel file used in APT's attack known as "Ukraine's Power Grid Incident" that occurred on December 23, 2015 in Prykarpattya Oblenergo ["Prikarptya Regional Energy Company" from Ukrainian] in Ivano-Frankivsk, Ukraine.
Outline: I. File Characteristics II. Malicious VBA payload III. Dropped Files IV. Yara Signature V. Anti-Virus Report This Excel requires enabled macros. [translated from Ukrainian] I. File Characteristics Malware Sample Source: malwr File Name: BlackEnergy.xls, Додаток1.xls ["Supplemental" - from Ukrainian] Last Author: LSW Creation Datetime: 2015-02-04 07:35:08 Author: user1 Last Saved: 2015-03-18 07:41:04 Application Name: Microsoft Excel Code Page: Cyrillic [Ukrainian] File Size: 717.5 KB
0 Comments
 Source: VirusShare
Malware Family: Backdoor, Implant, RAM Scraper Static Analysis Tools: pestudio, Immunity Debugger, CFF Explorer, PEID, BinText, IDA Pro Dynamic Analysis Tools: pexplorer, ProcMon, RegShot, ProcDump, Autoruns, Wireshark, Sandboxie, VMWare, Comodo, Payload Security Sandbox Reports: (1) Comodo: http://camas.comodo.com/cgi-bin/submit?file=4dae7fcde64a7ed61c51b17a57ffd2510381271a53d59beee730f59ae6c75352 (2) VirusTotal: https://www.virustotal.com/en/file/74fe8c68d878cc9699a2781be515bb003931ffa2ad21dc0c2c48eb91caba4b44/analysis/1450745229/ I . Static Analysis: Filename: loader.exe File Type: Win32 EXE Original Name: лиса. Dll [“fox” in Russian] Product: NT Kernel & System Target machine: Intel 386 or later processors and compatible processors Compilation Timestamp: 2015-06-18 04:37:16 Entry Point: 0x000011FC Subsystem: Windows GUI Number of Sections: 3 File Info: Microsoft Visual Basic 6.0 (when unpacked) Source: OpenSecurityTraining System Calls Revisited •You need to see the full path, and know that attackers can hook basically everywhere along the path.  Source: OpenSecurityTraining Purpose of the course
• Give you a deep understanding of the mechanics of software exploitation • Prepare you to identify vulnerabilities in software source code • Help you understand the how and why of exploit mitigation technology • Depth not breadth. We will cover a few key concepts deeply, rather than covering many topics briefly. Course Outline 1 • Basic stack overflows • Shellcode • More on stack overflows • Heaps and Heap overflows Course outline 2 • Other Vulnerable Scenarios • Recognizing vulnerabilities • Finding Vulnerabilities • Exploit mitigation technology What are we trying to achieve? • Arbitrary code execution • Examples – Forcing ssh to give you root access to the power grid (like Trinity in the previous slide!) – Turning your vanilla HTTP session with a web server into a root shell session. – Forcing a privileged administrator process to execute code your normally wouldn’t be able to. – Etc…. x86 Review Lab - The EBP register points to the base of the stack frame. Local variables, which are stored on the stack, are referenced via this base pointer. - Every time a function is called, a new stack frame is setup so that the function has its own fresh context (its own clean set of local variables). - The call instruction also puts a return address on the stack so that the function knows where to return execution to. - Key point: local function variables are stored in the same place where return addresses are. Source: fumalwareanalysis OllyDBG Cheat Sheet:
Change the EIP instruction in Immunity Debugger: From a Python Shell >>> imm = immlib.Debugger() >>> imm.setReg('EIP',int("hex value",16)) F9 (continue) is often used to continue from a breakpoint. Notice that the debugger automatically handles a lot of exceptions for you. If you want to intercept all exceptions, you should use SHIFT+F9 Goal: The objective today is to analyze the code snippet from 0x413BC8 to 0x413BD8. Answer the following questions. We will post the solution to these questions in the comments area. Q1. What is the value of EAX at 0x413BD5 (right before int 2d is executed)? The value of EAX is 00000001 at the memory location. Q2. Is the instruction "RET" at 0x413BD7 ever executed? No, EAX is an interrupt instruction; it skips the RET function. Q3. If you change the value of EAX to 0 (at 0x413BD5), does it make any difference for Q2? Yes. It makes its way to the RET function. Q4. Can you change the value of EIP at 0x413BD5 so that the int 2d instruction is skipped? Yes. Done in Immunity Debugger via ImmLib Python script. Q5. Modify the int 2d instruction at (0x413BD7) to "NOP" (no operations) and save the file as "max2[.]exe". Execute max2[.]exe. Do you observe any difference of the malware behavior? The sample does not run without the INT 2D function.  Sophisticated, advanced rootkit dropper/trojan
Source: InfoSec Institute [http://resources.infosecinstitute.com/step-by-step-tutorial-on-reverse-engineering-malware-the-zeroaccessmaxsmiscer-crimeware-rootkit/]
Usually, when a rootkit infects a host, the workflow is structured as follows:
ZeroAccess has some powerful rootkit capabilities, such as:
Source: OpenSecurityTraining.info I.What is a rootkit? •It’s an overused term is what it is •It's neither a root, nor a kit •An attacker tool •NOT how they get root •"A rootkit is a set of programs which *PATCH* and *TROJAN* existing execution paths within the system. This process violates the *INTEGRITY* of the TRUSTED COMPUTING BASE (TCB)." - Greg Hoglund, •The only universal truth about rootkits is that they are trying to hide the attacker’s presence •2 basic categorization schemes though Rings •Ring 3 – Userspace-Based •Ring 0 – Kernel-Based •“Ring -1” – Virtualization-Based –Intel VT-x(Virtualization Technology for x86), AMD-V (AMD Virtualization), Hypervisor subverted •"Ring -1.5?" - Post-BIOS, Pre OS/VMM –e.g. Master Boot Record (MBR) "bootkit" –Peripherals with DMA (Direct Memory Access) (this can be ring 0, -1, or -1.5 depending on whether VT-d is being used) –Not a generally acknowledged "ring", but the place I think it fits best • “Ring -2” – System Management Mode (SMM) • "Ring -2.5" - BIOS (Basic Input Output System), EFI (Extensible Firmware Interface) –because they are the first code to execute on the CPU and they control what gets loaded into SMM –Not a generally acknowledged "ring", but the place I think it fits best • “Ring -3” – Chipset Based –Intel AMT(Active Management Technology) Stealth Malware Taxonomy •Type 0: Uses only legitimate system features •Type 1: Modifies things which should be static •Type 2: Modifies things which are dynamic •Type 3: Exists outside the operating system •Type 4: Exists outside the main CPU/RAM Detecting Type 0
Example Type 1 Malware •Most in-the-wild rootkits are a mix of Type 1 and Type 2 IAT Hook SSDT Hook (System Service Descriptor Table) Inline Hook Detecting Type 1 • Tuluka, GMER, RootkitUnhooker, IceSword, Helios Lite, RootkitRevealer, System Virginity Verifier(SVV), WinDbg !chkimg, VICE, RAIDE, chkrootkit, etc; • [VMWatcher] for out of band integrity checks • Strider [GhostBuster] for cross-view of hiding things on disk (but you can generally detect bootkits with memory integrity checks, and you can’t get GhostBuster anyway) Preventing Type 1 •PatchGuard. Windows x64 •[NICKLE]. Assumes virtualized system Example Type 2 Malware •Direct Kernel Object Manipulation [DKOM] •Kernel Object Hooking [KOH] •Hook function pointers in dynamically allocated objects in the kernel •typedef struct { SHORT Type; UCHAR Number; UCHAR Importance; LIST_ENTRY DpcListEntry; PKDEFERRED_ROUTINE DeferredRoutine; PVOID DeferredContext; PVOID SystemArgument1; PVOID SystemArgument2; PULONG Lock; } KDPC, *PKDPC; Detecting Type 2
•In some cases you may be able to automatically infer semantic constraints on data structures and verify them at runtime [Petroni][LKIM] •Recent academic interest in KOH –[HookMap], [HookSafe], [HookScout] Detecting Type 4 – Ring -3 •Use other ring -3 detectors and get there first? TPM can verify a compatible BIOS, but what about everything else? [DeepWatch] wasn’t designed for it, but can it help? •Self-attestation [SWATT][SBAP][Pioneer] Spoiler Alert •There are ~8 rootkits leveraging ~10 techniques in the example VM, depending on how you count.  !chkimg
•You can also find modifications to static code/data areas with the !chkimg windbg command. It checks the version in memory against the file on disk System Virginity Verifier •http://invisiblethings.org/tools/svv/svv-2.3-src.zip •Like !chkimg but tries to apply some heuristics to the modifications it found to apply a severity score. Stuxnet use of inline hooks •From the Stuxnet Dossier: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf •"~WTR4141.tmp then loads ~WTR4132.tmp, but before doing so, it attempts to hide the files on the removable drive. Hiding the files on the removable drive as early in the infection process as possible is important for the threat since the rootkit functionality is not installed yet, as described in the Windows Rootkit Functionality section. Thus, ~WTR4141.tmp implements its own less-robust technique in the meantime. •WTR4141.tmp hooks the following APIs from kernel32.dll and Ntdll.dll: •From Kernel32.dll –FindFirstFileW –FindNextFileW –FindFirstFileExW •From Ntdll.dll –NtQueryDirectoryFile –ZwQueryDirectoryFile" Review: IAT Hooking •When the IAT is fully resolved, it is basically an array of function pointers. Somewhere, in some code path, there’s something which is going to take an IAT address, and use whatever’s in that memory location as the destination of the code it should call. •What if the “whatever’s in that memory location” gets changed after the OS loader is done? What if it points at attacker code? Review: IAT Hooking 2 •Well, that would mean the attacker’s code would functionally be “man-in-the-middle”ing the call to the function. He can then change parameters before forwarding the call on to the original function, and filter results that come back from the function, or simply never call the original function, and send back whatever status he pleases. –Think rootkits. Say you’re calling OpenFile. It looks at the file name and if you’re asking for a file it wants to hide, it simply returns “no file found.” •But how does the attacker change the IAT entries? This is a question of assumptions about where the attacker is. Review: IAT Hooking 3 •In a traditional memory-corrupting exploit, the attacker is, by definition, in the memory space of the attacked process, upon successfully gaining arbitrary code execution. The attacker can now change memory such as the IAT for this process only, because remember (from OS class or Intermediate x86) each process has a separate memory space. •If the attacker wants to change the IAT on other processes, he must be in their memory spaces as well. Typically the attacker will format some of his code as a DLL and then perform “DLL Injection” in order to get his code in other process’ memory space. •The ability to do something like DLL injection is generally a prerequisite in order to leverage IAT hooking across many userspace processes. In the kernel, kernel modules are generally all sharing the same memory space with the kernel, and therefore one subverted kernel module can hook the IAT of any other modules that it wants. Review: DLL Injection Review: Lab: IAT hooking •http://www.codeproject.com/KB/vista/api-hooks.aspx –This will hook NtQuerySystemInformation(), which is what taskmgr.exe uses in order to list the currently running processes. It will replace this with HookedNtQuerySystemInformation(), which will hide calc.exe –I modified that code to use IAT hooking rather than inline (which is much simpler actually) •Steps: –Compile AppInitHookIAT.dll –Place at C:\AppInitHookIAT.dll for simplicity –Use regedit.exe to add C:\AppInitHookIAT.dll as the value for the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT \CurrentVersion\Windows\AppInit_DLLs (if there is already something there, separate the entries with a comma) –Start calc.exe, start taskmgr.exe, confirm that calc.exe doesn't show up in the list of running processes. –Remove C:\AppInitHookIAT.dll from AppInit_DLLs and restart taskmgr.exe. –Confirm calc.exe shows up in the list of running processes. –(This is a basic "userspace rootkit" technique. Because of this, all entries in this registry key should always be looked upon with suspicion.) Go with what you know: IDT This indicates that interrupt index 0xE in the Interrupt Descriptor Table (IDT) does not point as its normal location, it points at memory address 0xF9F55A40, and GMER has not been able to determine which driver, if any, is associated with that memory range (thanks to another rootkit we'll learn about later.) References •[VMWatcher] http://www.csc.ncsu.edu/faculty/jiang/pubs/CCS07.pdf •[NICKLE]: http://friends.cs.purdue.edu/dokuwiki/doku.php?id=nickle •[3] “TDL rootkit x64 goes wild” http://www.prevx.com/blog/154/TDL-rootkit-x-goes-in-the-wild.html •[HyperSentry] http://discovery.csc.ncsu.edu/pubs/ccs10.pdf •[HookMap] http://www4.ncsu.edu/~zwang15/files/raid08.pdf •[HookSafe] http://www4.ncsu.edu/~zwang15/files/ccs09.pdf •[HookScout] http://www.ecs.syr.edu/faculty/yin/pubs/hookscout-dimva10.pdf •[8] “Don’t Tell Joanna, The Virtualized Rootkit Is Dead” https://www.blackhat.com/presentations/bh-usa-07/Ptacek_Goldsmith_and_Lawson/Presentation/bh-usa-07-ptacek_goldsmith_and_lawson.pdf •[9] “Compatibility is Not Transparency: VMM Detection Myths and Realities” http://www.usenix.org/event/hotos07/tech/full_papers/garfinkel/garfinkel_html/ •[DKOM] “VICE – Catch the hookers”- http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-butler/bh-us-04-butler.pdf •[KOH] “Kernel Object Hooking (KOH) Rootkits” - http://www.rootkit.com/newsread.php?newsid=501 •[DeepWatch] “Chipset Based Approach to Detect Virtualization Malware” http://www.blackhat.com/presentations/bh-usa-08/Bulygin/bulygin_Chip_Based_Approach_to_Detect_Rootkits.pdf Source: VirusShare
Malware Family: RAM Scraper Static Analysis Tools: pestudio, CFF Explorer, PEID, BinText, IDA Pro Dynamic Analysis Tools: pexplorer, ProcMon, RegShot, ProcDump, Autoruns, Wireshark, Sandboxie, Comodo Reports: (1) Malwr: https://malwr.com/analysis/MDk3OGEwNjc5NTY5NDViNmJlMGRiZjRiOTM1Yjk4YTY/ (2) VirusTotal: https://www.virustotal.com/en/file/686dbe5eb148db706e48a74eba627270055ed1ba534a98d5d00690577eb42e49/analysis/1451436599/ I . Static Analysis: File type: Win32 EXE Target machine: Intel 386 or later processors and compatible processors Compilation Timestamp: 2015-02-22 17:23:22 Entry Point: 0x0000151D Number of Sections: 3 MD5: af13e7583ed1b27c4ae219e344a37e2b SHA256: 686dbe5eb148db706e48a74eba627270055ed1ba534a98d5d00690577eb42e49 Source: VirusShare Malware Family: RAM Scraper Static Analysis Tools: pestudio, CFF Explorer, PEID, BinText, IDA Pro Dynamic Analysis Tools: pexplorer, ProcMon, RegShot, ProcDump, Autoruns, Wireshark, Sandboxie, Comodo Reports: (1) Malwr: https://malwr.com/analysis/MjNhOWI2NDgwZjZiNDE0MzhhYWQ1NzU5ZDUwYmNhODc/ (2) VirusTotal: https://www.virustotal.com/en/file/d7a08338bcb30cc688a827b611fe9b26c54f3ba35c02355fa1d468da8cbbd903/analysis/ I . Static Analysis: Internal File name: Verifone32.exe File type: Win32 EXE Target machine: Intel 386 or later processors and compatible processors Compilation Timestamp: 2014-10-01 22:24:35 Entry Point: 0x00005140 Number of Sections: 5  Contains 3 embedded files:
Source: VirusShare Malware Family: Backdoor, RAM Scraper Static Analysis Tools: pestudio, CFF Explorer, PEID, BinText, IDA Pro Dynamic Analysis Tools: pexplorer, ProcMon, RegShot, ProcDump, Autoruns, Wireshark, Sandboxie, Comodo Reports: (1) TotalHash: https://totalhash.cymru.com/analysis/?a6eb86b55148a7a491093f1f6af6a15c4b44b96c (2) VirusTotal: https://www.virustotal.com/en/file/11591204155db5eb5e9c5a3adbb23e99a75c3b25207d07d7e52a6407c7ad0165/analysis/1451210102/ I . Static Analysis: File type: Win32 EXE Target machine: Intel 386 or later processors and compatible processors Compilation Timestamp: 2014-12-31 14:47:27 Entry Point: 0x0000FA46 Number of Sections: 4  |
AuthorVitali Kremez Archives
September 2016
Categories |
RSS Feed
