{
	"id": "70a63cc0-3cbc-4313-a913-255e56a836cb",
	"created_at": "2026-04-06T00:07:23.65559Z",
	"updated_at": "2026-04-10T13:13:06.859429Z",
	"deleted_at": null,
	"sha1_hash": "fed3d84de76e7f52127b673936ec361f5534c1a6",
	"title": "Shifu – the rise of a self-destructive banking trojan",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2080977,
	"plain_text": "Shifu – the rise of a self-destructive banking trojan\r\nBy Floser Bacurio Jr Fortinet, SingaporeWayne LowFortinet, SingaporeEditor: Martijn Grooten\r\nArchived: 2026-04-05 22:52:11 UTC\r\n2015-11-02\r\nAbstract\r\nThe banking trojan Shifu appears to inherit some of its features from several other well-known banking trojans. Floser\r\nBacurio and Wayne Low decided to take a close look at one of its droppers.\r\nCopyright © 2015 Virus Bulletin\r\nFollowing takedown operations against various notorious banking trojans, including Zeus, Dridex and Gozi, a freshly\r\nbrewed banking trojan, Shifu, has recently made the news; we believe it inherits some features from the earlier well-known\r\nbanking trojans. We decided to dive deeper into one of its droppers (MD5: E60F72FFA76386079F2645BE2ED84E53;\r\nSHA1: 963BFC778F94FE190FDD1DD66284E9BC9DD2BED6). A number of features caught our eye when looking at its\r\nunderlying code.\r\nDropper\r\nExploiting CVE-2015-0003\r\nOn our first look at the dropper, we observed that the dropper code is not heavily obfuscated, although most of the strings\r\nare encoded; it turns out that the strings can easily be decoded using a simple XOR operation.\r\nAt the entry point, we can immediately tell that Shifu attempts to exploit a local privilege escalation vulnerability. The\r\nvulnerability was assigned the CVE number CVE-2015-0003 in February 2015 and can be used to elevate the privilege of a\r\nprocess to system privilege on Windows 7 and above. The exploit code can easily be found on the Internet, so it is not\r\nsurprising that the malware attempts to exploit this (patched) vulnerability. This means that the malware may not execute\r\nproperly without sufficient privileges and also serves as a reminder that Windows users should always install the latest\r\nWindows updates.\r\nAfter performing the local privilege escalation routine, we arrive at the code where the malware will extract the payloads\r\nembedded in its binary. The payloads consist of two aPLib compressed blobs for 32-bit and 64-bit platforms, which is a very\r\ncommon technique used by malware nowadays. The use of the aPLib compressor suggests that Shifu might have adopted\r\nsome of the techniques used by malware like Zeus (aka Zbot) or Rovnix (and thus Carberp), for which the source code has\r\nbeen leaked.\r\nMalware don’t like HIPS\r\nOne of the most notable things observed in the code injection routine is an attempt to obfuscate the MZPE header by\r\noverwriting random bytes in it. This action does not affect the execution of the payload since the payload code will be\r\ninjected into the memory of the remote process and will be executed directly in the context of the remote process via an\r\nasynchronous thread. The purpose of overwriting bytes in the MZPE header is to defeat behavioural analysis systems and\r\nHIPS technology – with a corrupted MZPE header, the sample does not look like a legitimate binary file and could thus\r\nbypass some trivial PE signature checks.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 1 of 16\n\nFigure 1. Corrupting the MZPE header.\r\nCode obscuring\r\nAnalysing the decompressed buffer directly might result in an incorrect AddressOfEntryPoint as Shifu’s author has\r\nintentionally obfuscated the entry point address by XORing with a widely used XOR key, 0x31337, throughout the program\r\nregardless of the dropper or payload. Shifu will first try injecting the payload code into explorer.exe. When the code\r\ninjection into explorer.exe fails, to play it safe, Shifu’s author implements an additional routine which will create or spawn a\r\nrandom Windows process found in C:\\Windows\\system32, or in C:\\Windows\\syswow64 if it is a 64-bit platform. Under\r\nnormal circumstances, most Windows executable files (for instance svchost.exe) can be executed, but will quit immediately\r\nwhen called by non-Windows services. In order to circumvent this behaviour, Shifu first creates a suspended Windows\r\nprocess and then injects an infinite sleep, Sleep(-1), routine and executes it in the memory of the suspended process. After\r\nthat, the suspended process will be resumed and continue execution, but it will not quit immediately unless it is forced to\r\nexit explicitly. Once the targeted process has been determined, Shifu will carry out another code injection routine to execute\r\nthe payload via CreateRemoteThread or RtlCreateUserThread (Figure 2).\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 2 of 16\n\nFigure 2. Remote code execution using CreateRemoteThread/RtlCreateUserThread.\r\nAnti-sandbox and anti-VM\r\nThere are many anti-sandbox and anti-VM detection techniques in the dropper, as is common in mal-ware nowadays. Some\r\nof these checks have been documented in a McAfee blog post [1], so Table 1 lists some of the process names, as well as their\r\nhashes (computed by checking well-known process names using the Windows API function RtlComputeCrc32) that are\r\n‘blacklisted’ by Shifu. Shifu checks a list of active processes running on the machine, as well as the sample’s file name,\r\nagainst hard-coded CRC32 hashes in order to avoid the malware being analysed by a sandbox or by virtual machines that are\r\nbuilt to perform dynamic analysis of malware samples.\r\nProcess name CRC32 hash\r\nvmwareuser.exe 0x99DD4432\r\nvmwaretray.exe 0x1F413C1F\r\nvboxservice.exe 0x64340DCE\r\nvboxtray.exe 0x63C54474\r\nwireshark.exe 0x77AE10F7\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 3 of 16\n\nProcess name CRC32 hash\r\nprocmon.exe 0x5BA9B1FE\r\nprocexp.exe 0x3CE2BEF3\r\nfortitracer.exe 0x332FD095\r\nollydbg.exe 0xAF2015F2\r\npython.exe 0xD2EFC6C4\r\nsysanalyzer.exe 0x4231F0AD\r\nsniff_hit.exe 0xD20981E0\r\njoeboxserver.exe 0x2AAA273B\r\njoeboxcontrol.exe 0x777BE06C\r\nTable 1. Process names that are ‘blacklisted’ by Shifu.\r\nIt also employs a check against the file names shown in Table 2.\r\nDropper’s file name CRC32 hash\r\nsample.exe 0xE84126B8\r\nmalware.exe 0x3C164BED\r\ntest.exe 0xC19DADCE\r\nTable 2. File names that are checked.\r\nPayload\r\nOn analysing the decompressed payload using a disassembler, it turns out that we have landed at an invalid code entry point,\r\nas mentioned in the previous section, and the disassembler will complain that the import address table is corrupted. The\r\npayload cannot be analysed in a disassembler directly without first ‘fixing’ the file. We later realized that, besides the code\r\nentry point obfuscation, Shifu’s author has also deployed some other trivial tricks to the payload to mislead analysts:\r\nObfuscating the import table address – the original import table address can be restored by XORing with the key\r\n0x31337.\r\nObfuscating import function names (Figure 3 and Figure 4) – the function names are encoded using the static XOR\r\nkey 0xFF. (In the Appendix, we provide a simple IDAPython script to fix the function names under IDA Pro.)\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 4 of 16\n\nFigure 3. Obfuscated import function names.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 5 of 16\n\nFigure 4. Shifu deobfuscating the import table address before loading the DLL by name.\r\n(Click here to view a larger version of Figure 4.)\r\nShifu’s author also utilized multi-threading to add complexity to the malware and make dynamic analysis more challenging.\r\nOn the other hand, from a static analysis perspective, the malware’s encoding/encryption routine is insignificant and most of\r\nthe strings in the binary can trivially be decoded and fixed within IDA Pro with a few lines of code (Figure 5). However,\r\nsome of the strings, such as the command-and-control server name, are encrypted using RC4.\r\nFigure 5. A simple script to decode the encoded string.\r\n(Click here to view a larger version of Figure 5.)\r\nMultiple process code injection\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 6 of 16\n\nBefore Shifu is able to carry out its wide range of information-stealing activities, it needs to make sure its payload code will\r\nbe injected into the relevant processes. When the payload is injected by the dropper, the very first thing it will do is traverse\r\nthe running processes and transfer its code into any process that does not already contain it. In other words, all the active\r\nprocesses apart from the system processes will contain a copy of the payload code whenever the machine is infected.\r\nAfterwards, a named pipe will be created in order to allow communication between the payloads in different processes.\r\nComprehensive data theft features\r\nKeylogger and screenshot capture\r\nLooking into Shifu’s data theft features, we could see that the malware is equipped with some of the keylogging features\r\nfound in traditional keyloggers, as well as having the ability to steal numerous banking credentials from the victim. Shifu\r\nalso uses the Windows API-hooking technique in order to steal other credentials. Table 3 shows a short summary of the\r\nhooked Windows APIs along with their respective purposes.\r\nHooked Windows API Purpose\r\nUser32!GetClipboardData\r\nCaptures the ASCII and UNICODE text currently saved in the\r\nclipboard window\r\nUser32!TranslateMessage Captures the keyboard’s keystrokes\r\nUser32!GetMessageA/User32!GetMessageW\r\nThe hook’s handler performs the same thing as the\r\nuser32!TranslateMessage hook’s handler\r\nTable 3. Hooked Windows APIs and their purposes.\r\nUnder normal circumstances, these Windows API hooks should be able to capture the keystrokes on an infected machine.\r\nHowever, Shifu also tries to capture virtual keyboards, which are commonly used in Internet banking, by taking screenshots\r\nof the infected machine whenever the malware detects a mouse click. It is also noteworthy that the virtual keyboard screen\r\nwill only be grabbed when the malware detects an opened screen with one of the following titles, all of which are used by\r\nItalian Internet banking websites:\r\nPassword\r\nTelemaco\r\nScelta e Login dispositivo\r\nTLQ Web\r\ndb Corporate Banking Web\r\nSecureStoreCSP - enter PIN\r\nCertificate capture\r\nShifu manipulates Windows API hooks in order to intercept the certificate password when a certificate is being imported to\r\nthe certificate store. All the certificate blob data and passwords found in the Crypt32!PFXImportCertStore API will be\r\nintercepted, unless the process contains the string ‘torrent’.\r\nThe imported public keys on the infected machine will also be captured. This is possible, using the Windows\r\nCrypt32!CertEnumSystemStore API, without having access to the private key.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 7 of 16\n\nThese hooks may be useful to the attackers when the victim imports certificates using a Windows PGP client like Gpg4win;\r\nthe hook handlers could intercept the private key and certificate and save it to Shifu’s specified log directory as\r\n‘randomhexavalue_cert.pfx’. Furthermore, it could be useful if the attackers want to access the cryptocurrency wallet\r\ndownloaded from the victim machine, which is encrypted using an RSA key pair.\r\nShifu’s author and its operators will be able to abuse the stolen certificates for nefarious purposes.\r\nOther data thefts\r\nIn line with the current cryptocurrency hype, Shifu also targets Bitcoin and Litecoin wallet files found on the victim’s\r\nmachine. Shifu tries to steal VPN and VNC login credentials by checking the command line of running executables. If a\r\nremote desktop protocol (RDP or VNC) or VPN process is found with the configuration file name specified in the command\r\nline, Shifu attempts to save a copy of the configuration file.\r\nIt appears that this trojan steals far more information than a typical banking trojan would: from keylogging, screenshot\r\ncapture, certificate capture and cryptocurrency wallet grabbing, to FTP and POP3 credentials grabbing. The malware also\r\nappears to target point-of-sale terminals for payment card data as well as some financial institutions themselves. It scans the\r\nmachines if one of the following strings is found in the path of the executable file of the current process:\r\ntellerplus\r\nbancline\r\nfidelity\r\nmicrsolv\r\nbankman\r\nvanity\r\nepisys\r\njack henry\r\ncruisenet\r\ngplusmain\r\nsilverlake\r\nv48d0250s1\r\nWhen a potential POS machine is found, the malware will send a flag, ‘ETC’, back to its C\u0026C server. Based on the malware\r\ncode, there is no immediate action after the machine has been recognized as a POS system; perhaps a memory-scrapping\r\nmodule will be deployed by the botnet operators to this machine at a later time.\r\nStealthy banking trojan stays under the radar?\r\nWhen analysing Shifu’s Windows API-hooking mechanisms, we also discovered that the malware tries to remain hidden\r\nfrom the victim. The malware conceals its presence from the running processes by hijacking the Windows\r\nntdll!ZwQuerySystemInformation API, which is called whenever a user-mode program attempts to enumerate a list of active\r\nprocesses using one of various process enumeration APIs. However, this is a well-known technique and is defeated by all\r\nmodern security tools. Apparently, the purpose of this trick is to remain concealed from non-tech-savvy users, however what\r\nconfused us is that the malware also hijacks Windows API calls used for DNS resolution, such as ws2_32!gethostbyname,\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 8 of 16\n\nws2_32!getaddrinfo and ws2_32!GetAddrInfoExW, to redirect URLs that contain the pattern ‘secure\\..*\\.moz\\..*’ to\r\n‘google.com’. Essentially, this seems to dismiss the idea of the malware being stealthy, as hijacking a website is often a clear\r\nsign of infection.\r\nHome sweet home\r\nWhen a new machine is infected, the malware will report the new victim to the command-and-control (C\u0026C) server by\r\nconnecting to a domain that is hard-coded in the code, using the path ‘/news/userlogin.php’. The following is the\r\ninformation on the machine that will be stored in the botnet’s control panel (also see Figure 6):\r\nbotid – username and computer name\r\nver – botnet version\r\nup – uptime of the infected machine\r\nos – operating system identifier of the infected machine\r\nltime – local timestamp of the infected machine\r\ntoken – existence of smart card information\r\ncn – unknown\r\nav – name of the security solution installed\r\ndmn – domain name of the workstation\r\nFigure 6. Machine information sent back to the C\u0026C control panel.\r\nAll the data sent and received is obfuscated to prevent direct exposure by a packet sniffer program. The data is encoded and\r\ndecoded using the RC4 algorithm with the key ‘a7zoSTHljZylEx4o3mJ2eqIdsEguKC15KnyQdfx4RTc5sjH’.\r\nWhen information is collected on the machine, it is immediately sent back to the C\u0026C server via the path\r\n‘/news/userpanel.php’. A fake HTTP referrer, ‘www1.google.com’, is used throughout the C\u0026C communications.\r\nWhen there is a need to generate a random domain name via a domain generation algorithm (DGA), the malware contacts\r\nthe master C\u0026C server first to retrieve some configuration data via the path ‘/news/users.php’.\r\nIn the payload of the most recently distributed Shifu, with a compilation date of 06 Oct 2015, we have noticed a subtle\r\nupdate: it no longer connects to the C\u0026C server on machines that are found to have Man-in-the-Middle (MitM) interception\r\nfor HTTPS connections. It makes this check by comparing the certificate’s MD5 fingerprint with those of some well-known\r\nwebsites (see Figure 7):\r\nmicrosoft.com\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 9 of 16\n\ndropbox.com\r\ntwitter.com\r\nsendspace.com\r\netrade.com\r\nfacebook.com\r\ninstagram.com\r\ngithub.com\r\nicloud.com\r\npython.org\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 10 of 16\n\nFigure 7. Checking the existence of MitM interception on HTTPS.\r\nThe purpose for this update is believed to be to avoid the malware’s SSL traffic being intercepted and analysed by\r\nresearchers and by intrusion detection systems that typically have SSL traffic inspection capabilities.\r\nOne browser plug-in kills them all\r\nIt seems that Shifu’s author feels nostalgic about the PhishWall anti-phishing solution from SecureBrain. All third-party\r\nbrowser plug-ins will be disabled immediately via a single registry value, ‘Enable Browser Extensions’, located in\r\nHKCU\\Software\\Microsoft\\Internet Explorer\\Main, if PhishWall is found to be installed as an Internet Explorer plug-in.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 11 of 16\n\nThis makes sense, given that Shifu was first found to be actively spread in Japan, as SecureBrain is a Japanese security\r\nprovider. Moreover, it appears that Shifu’s author is cautious with the SecureBrain solution and does not want to create\r\nobvious noise – for example by disabling all browser plug-ins – that could easily alert non-tech-savvy victims.\r\nIn addition to disabling third-party IE plug-ins, it also disables the pop-up blocker in IE through a registry key:\r\nHKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\Zones\\3\r\n\"1406\" = 0\r\nBotnet-like banking trojan\r\nLast but not least, Shifu also allows the botnet operator to download and execute additional modules, hence it supports a\r\nlimited set of commands. The following is a list of commands currently supported by the malware:\r\nwebinject\r\nWebinjection to the targeted Internet banking sites is carried out through a local Apache server installed silently by Shifu. In\r\nthe underlying code, we realized that the botnet operators issue mitm_mod and mitm_script commands to download a copy\r\nof the Apache web server software as well as the webinjection script and its associated configuration file, config.xml. When\r\nthese files are in place on the infected machine, the malware will first modify and make sure the Apache server is properly\r\nconfigured by setting the server’s address to localhost (127.0.0.1) using a random port for both HTTP and HTTPS. After the\r\nserver’s configuration file is set, the server’s process will be started and its status will be monitored periodically through an\r\nasynchronous thread every second to make sure it keeps running.\r\nWebinjection through the local HTTP server won’t work without setting up a hook on the browser process. However, the\r\nhook implementation is simpler than that of traditional banking trojans. Table 4 shows a summary of the hooks on the\r\nWinsock API. Besides hooking the Winsock API, it also hijacks the SSL verification API used by the browser process so that\r\nthe verification is always successful regardless of whether the presented SSL certificates are valid.\r\nHook Windows API Purpose\r\nws2_32!connect ws2_32!connectEx\r\nRedirect all the HTTP/HTTPS traffic to a local\r\nHTTP server to carry out man-in-the-middle\r\noperation\r\ncrypt32!CertVerifyCertificateChainPolicy\r\nnss3.dll!SSL_AuthCertificateHook\r\nnspr4.dll!SSL_AuthCertificateHook\r\nAlways return success when the browser’s SSL\r\nverification process takes place\r\nTable 4. Hooks on the Winsock API.\r\nwipe_cookies\r\nIt is assumed that Shifu is mainly distributed via Flash-based exploit kits. This module allows the botherder to make the\r\nbotnet clean up Flash cookies found in the %APPDATA%\\Macromedia folder to cover the presence of the exploited Flash\r\nfiles.\r\nupdate\r\nLike most software, the botnet also supports automatic updates. As the malware uses a trivial protection method to prevent\r\nthe removal of the malware file – through an opened file handle – it must first close the file handle before being able to\r\nreplace the new binary file.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 12 of 16\n\nload\r\nThis allows for the execution of arbitrary executables downloaded from the C\u0026C server.\r\nkill_os\r\nThe real reason why the botnet supports the self-destruction feature (which destroys both the malware and the operating\r\nsystem) is still a mystery to us. But based on the nature of the botnet – it copies lots of ideas and codes from different\r\nnotorious malware – and the fact that it tries to evade analysis by both auto-analysis systems and manual analysis, we can\r\nsafely assume that the self-destruction routine will be executed when it is found to be executing on an unwilling platform.\r\nThe self-destruction routine (see Figure 8) is pretty straightforward:\r\nRemove all the files attached to removable drives, for instance thumb drives.\r\nCorrupt the filesystem (e.g. NTFS/FAT) by overwriting its boot sector.\r\nShut down the machine.\r\nIn case the shutdown operation is not successful, it terminates itself.\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 13 of 16\n\nFigure 8. Shifu’s self-destruction routine.\r\nConclusion\r\nIn conclusion, Shifu is an enhanced or improved piece of banking malware that has borrowed a lot of techniques from its\r\npredecessors; it rectified and refined the weaknesses possibly found in other renowned competitors. The author clearly has a\r\ngood understanding of how to deal with thread synchronization in multi-threaded applications – which could indicate that\r\nhe/she is an experienced programmer. However, the use of some old-school techniques in Shifu can be easily spotted and\r\nblocked by many security products.\r\nBibliography\r\nAppendix\r\nTable A1 shows the sample SHA1 used in the analysis.\r\nCompilation\r\ntimestamp\r\nDropper’s SHA1 X86 Payload’s SHA1\r\n18 August\r\n2015\r\n963BFC778F94FE190FDD1DD66284E9BC9DD2BED6 16E4476146511F6B9D8DDF4B232D896D7EC91F\r\n06 October\r\n2015\r\nB4ED692D6E8C35F3C611084E6785972CCAE8DCDC 8FC58220FD84F3A59F20D52F4A07F07657474467\r\nTable 5. Sample SHA1 used in the analysis.\r\nshifu_fix_iat.py\r\nimport idaapi\r\nimport idautils\r\n# Global variables\r\nIMG_BASE = idaapi.get_imagebase()\r\nlist_seg = []\r\nfor seg in idautils.Segments():\r\n list_seg.append(seg)\r\nIMG_END = idc.SegEnd(list_seg[len(list_seg)-1])\r\ndef decrypt(ea, key):\r\n \r\n # Virtual address to IMAGE_IMPORT_DESCRIPTOR-\u003eFirstThunk\r\n va_iat = 0\r\n # Virtual address to IMAGE_IMPORT_DESCRIPTOR-\u003eOriginalFirstThunk\r\n va_int = 0\r\n tmp_ea = ea\r\n # Back-tracing to locate the IMAGE_IMPORT_DESCRIPTOR from import address table passed from the callback\r\n for xref in idautils.XrefsTo(ea, 0):\r\n if XrefTypeName(xref.type) == ‘Data_Offset’:\r\n va_iat = xref.frm - 0x10\r\n if va_iat != 0:\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 14 of 16\n\nprint “Import Name Table-\u003e%08x” % (idaapi.get_long(va_iat) + IMG_BASE)\r\n va_int = idaapi.get_long(va_iat) + IMG_BASE\r\n else:\r\n return\r\n if va_int != 0:\r\n va_itd = idaapi.get_long(va_int)\r\n # Enumerate array of IMAGE_THUNK_DATA\r\n while va_itd != 0:\r\n va_itd = va_itd + IMG_BASE\r\n if va_itd \u003e IMG_BASE and va_itd \u003c= IMG_END:\r\n print «Image thunk data-\u003e%08x» % va_itd\r\n va_ibn = va_itd + 2\r\n ch = idaapi.get_byte(va_ibn)\r\n str = ‘’\r\n while ch != 0 and ch != 255:\r\n str += chr(ch ^ key)\r\n va_ibn += 1\r\n ch = idaapi.get_byte(va_ibn)\r\n # Save the decoded import name\r\n print «IMAGE_IMPORT_BY_NAME-\u003eName (%08x): %s» % (va_itd+2, str)\r\n idc.MakeName(tmp_ea, str)\r\n tmp_ea += 4\r\n # Next IMAGE_THUNK_DATA\r\n va_int += 4\r\n va_itd = idaapi.get_long(va_int)\r\n else:\r\n return\r\ndef imp_cb(ea, name, ord):\r\n if not name:\r\n print «%08x: ord#%d» % (ea, ord)\r\n else:\r\n print «%08x: %s (ord#%d)» % (ea, name, ord)\r\n # The decrypt function will be responsible to enumerate IMPORT_DESCRIPTOR_TABLE to decode all the function na\r\n decrypt(ea, 0xFF)\r\n # We only want to callback once for every imported DLL\r\n return False\r\n# Main\r\nnimps = idaapi.get_import_module_qty()\r\nfor i in xrange(0, nimps):\r\n name = idaapi.get_import_module_name(i)\r\n if not name:\r\n print «Failed to get import module name for #%d» % i\r\n continue\r\n print «Walking-\u003e %s» % name\r\n idaapi.enum_import_names(i, imp_cb)\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 15 of 16\n\nprint «All done...»\r\nSource: https://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nhttps://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2015/11/shifu-rise-self-destructive-banking-trojan"
	],
	"report_names": [
		"shifu-rise-self-destructive-banking-trojan"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434043,
	"ts_updated_at": 1775826786,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fed3d84de76e7f52127b673936ec361f5534c1a6.pdf",
		"text": "https://archive.orkl.eu/fed3d84de76e7f52127b673936ec361f5534c1a6.txt",
		"img": "https://archive.orkl.eu/fed3d84de76e7f52127b673936ec361f5534c1a6.jpg"
	}
}