{ "id": "61ec29f9-6923-4817-bb66-8b5c4091383c", "created_at": "2026-04-06T00:16:24.730792Z", "updated_at": "2026-04-10T13:12:30.278155Z", "deleted_at": null, "sha1_hash": "178154f525293c916f8a28c88f16fbfc69528744", "title": "Diamond Fox - part 1: introduction and unpacking | Malwarebytes Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 602388, "plain_text": "Diamond Fox - part 1: introduction and unpacking | Malwarebytes\r\nLabs\r\nBy Malwarebytes Labs\r\nPublished: 2017-03-16 · Archived: 2026-04-05 15:46:30 UTC\r\nDiamond Fox (also known as Gorynch) is a stealer written in Visual Basic that has been present on the black\r\nmarket for several years. Some time ago, builders of its older versions (i.e. 4.2.0.650) were cracked and leaked\r\nonline – thanks to this we could have a closer view at the full package that is being sold by the authors to other\r\ncriminals.\r\nIn 2016 the malware was almost completely rewritten – its recent version, called “Crystal” was described some\r\nmonths ago by Dr. Peter Stephenson from SC Media (read more).\r\nIn this short series of posts, we will take a deep dive in a sample of Diamond Fox delivered by the Nebula Exploit\r\nKit (described here). We will also make a brief comparison with the old, leaked version, in order to show the\r\nevolution of this product.\r\nIn this first part, we will take a look at Diamond Fox’s behavior in the system, but the main focus will be\r\nabout unpacking the sample and turning it into a form that can be decompiled by a Visual Basic Decompiler.\r\nAnalyzed samples\r\n92d098a9f2adb0e4c524edd82a81c894 – original sample\r\n05ce32843c7271464b48283fe8f179cc – unpacked stage 1\r\n988e9fa903cc2fbb80e7221072fb2221 – unpacked (final VB payload)\r\nBehavioral analysis\r\nAfter being deployed, Diamond Fox runs silently, however, we can notice some symptoms of its presence in the\r\nsystem. First of all, the UAC (User Account Control) gets disabled and we can see an alert about it:\r\nAnother pop-up is asking the user to restart the system so that this change will take effect:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 1 of 11\n\nThe initial executable is deleted and the malware re-runs itself from the copy installed in the %TEMP% folder. It\r\ndrops two copies of itself – dwn.exe and spoolsv.exe. Viewing the process activity under Process Explorer, we can\r\nobserve the spawned processes:\r\nIt also deploys wscript.exe.\r\nFor persistence, Diamond Fox creates a new folder with a special name (read more about this feature):\r\n%TEMP%lpt8.{20D04FE0-3AEA-1069-A2D8-08002B30309D}.\r\nThanks to this trick, the user cannot access the files dropped inside. Another copy (backup) is dropped in\r\nthe Startup folder.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 2 of 11\n\nWhile running, the malware creates some files with .c extensions in %APPDATA% folder:\r\nAlso, new files are created in the folder from which the sample was run:\r\nThe file keys.c contains an HTML formatted log about the captured user activities, i.e. keystrokes. Here’s an\r\nexample of the report content (displayed as HTML):\r\nThe files log.c and Off.c are unreadable.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 3 of 11\n\nExamining the content of the %TEMP% folder we can also find that the malware dropped downloaded payload\r\ninside:\r\nIt is a XOR encrypted PE file (key in the analyzed case is: 0x2), that turns out to be an update of the main\r\nDiamond Fox bot.\r\nNetwork communication\r\nDiamond Fox communicates with the CnC using an HTTP-based protocol. It beacons to gate.php\r\nData from the bot is sent to the CnC in form of a POST request. Pattern:\r\n13e=\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 4 of 11\n\nResponses from the CnC have the following pattern:\r\n \r\nWe can observe the bot downloading in chunks some encrypted content (probably the payload/bot update):\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 5 of 11\n\nIt also periodically uploads the stolen data. In the example below: sending the report about the logged user\r\nactivities (content of the previously mentioned file keys.c):\r\nUnpacking\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 6 of 11\n\nDiamond Fox is distributed packed by various crypters, that require different approaches for\r\nunpacking. They are not specifically linked with this particular family of malware, that’s why this\r\npart is not going to be described here. However, if you are interested in seeing the complete process\r\nof unpacking the analyzed sample you can follow the video:\r\nAfter defeating the first layer of protection, we can see a new PE file. It is wrapped in another protective stub –\r\nthis time typical for this version of Diamond Fox. The executable has three unnamed sections followed by a\r\nsection named L!NK. The entry point of the program is atypical – set at the point 0.\r\nIt makes loading the application under common debuggers a bit problematic. However, under a disassembler (i.e.\r\nPE-bear) we can see, where this Entry Point really leads to:\r\nThe header of the application is interpreted as code and executed. Following the jump leads to the real Entry\r\nPoint, that is in the second section of the executable:\r\nI changed the the executable Entry Point and set it to the jump target (RVA 0xEDB0).\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 7 of 11\n\nSaved application could be loaded in typical debuggers (i.e. OllyDbg) without any issues, to follow next part of\r\nunpacking.\r\nThe steps to perform at this level are just like in the case of manual unpacking of UPX. The execution of the\r\npacker stub starts by pushing all registers on the stack (instruction PUSHAD). We need to find the point of\r\nexecution where the registers are restored, because it is usually done when the unpacking of the core finished. For\r\nthe purpose of finding it, after the PUSHAD instruction is executed, we follow the address of the stack (pointed by\r\nESP). We set a hardware breakpoint on the access to the first DWORD.\r\nWe resume the execution. The application will stop on the hardware breakpoint just after the POPAD was\r\nexecuted restoring the previous state of the registers.\r\nThis block of code ends with a jump to the unpacked content. We need to follow it in order to see the real core of\r\nthe application and be able to dump it. Following the jump leads to the Entry Point typical for Visual Basic\r\napplications. It is a good symptom because we know that the core of Diamond Fox is a Visual Basic application.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 8 of 11\n\nNow we can copy the address of the real Entry Point (in the analyzed case it is 0x4012D4) and dump the\r\nunpacked executable for further analysis.\r\nI will use Scylla Dumper. Not closing OllyDbg, I attached Scylla to the running process of Diamond Fox (named\r\ns_1.exe in my case).\r\nI set as the OEP (Original Entry Point) the found one, then I clicked IAT Autosearch and Get Imports:\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 9 of 11\n\nScylla found several imports in the unpacked executable:\r\nWe can view the eventual invalid and suspected imports and remove them – however, in this case, it is not\r\nrequired. We can just dump the executable by pressing button Dump.\r\nThen, it is very important to recover the found import table by clicking Fix Dump and pointing to the dumped file.\r\nAs a result, we should get an executable named by Scylla in the following pattern: _dump_SCY.exe.\r\nNow, we got the unpacked file that we can load under the debugger again. But, most importantly, we can\r\ndecompile it by a Visual Basic Decompiler to see all the insights of the code.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 10 of 11\n\nExample of the decompiled code – part responsible for communication with the CnC (click to enlarge):\r\nConclusion\r\nUnpacking Diamond Fox is not difficult, provided we know a few tricks that are typical for this malware family.\r\nFortunately, the resulting code is no further obfuscated. The authors left some open strings that make functionality\r\nof particular blocks of code easy to guess. In the next post, we will have a walk through the decompiled code and\r\nsee the features provided by the latest version of Diamond Fox.\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest\r\nin InfoSec. She loves going in details about malware and sharing threat information with the community. Check\r\nher out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/\r\nPage 11 of 11", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "origins": [ "web" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2017/03/diamond-fox-p1/" ], "report_names": [ "diamond-fox-p1" ], "threat_actors": [], "ts_created_at": 1775434584, "ts_updated_at": 1775826750, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/178154f525293c916f8a28c88f16fbfc69528744.pdf", "text": "https://archive.orkl.eu/178154f525293c916f8a28c88f16fbfc69528744.txt", "img": "https://archive.orkl.eu/178154f525293c916f8a28c88f16fbfc69528744.jpg" } }