{ "id": "7cb3164b-5588-4de5-8c92-d37bd91a48e0", "created_at": "2026-04-06T00:17:59.582938Z", "updated_at": "2026-04-10T13:12:28.217088Z", "deleted_at": null, "sha1_hash": "5f5756e36190ea5c5b90e7a5c33a3edc95a764c4", "title": "DorkBot: An Investigation - Check Point Research", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 90765, "plain_text": "DorkBot: An Investigation - Check Point Research\r\nBy deugenio\r\nPublished: 2018-02-04 · Archived: 2026-04-05 13:57:07 UTC\r\nResearch By: Mark Lechtik\r\nOverview:\r\nDorkBot is a known malware that dates back to 2012. It is thought to be distributed via links on social media,\r\ninstant messaging applications or infected removable media. Although it is a veteran among the notorious\r\nmalware families, we believe that more networks have been infected with Dorkbot than previously expected, with\r\nthe most affected countries being Sri Lanka, India and Russia.\r\nGeneral geographic distribution of the Dorkbot infections\r\nThe malware essentially serves as a general purpose downloader and launcher of other binary components, mostly\r\nmodules for conducting DDoS attacks or stealing passwords. The analysis in this case was based on the sample\r\nthat was observed in multiple infections in the wild in the past month.\r\nThe DorkBot malware comes packed within a simple dropper, in which the payload is embedded as an RC4\r\nencrypted blob. This blob can be found at the resource section of the binary, encoded with Base64.\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 1 of 13\n\nFigure 1: Base64 encoded \u0026 RC4 encrypted resource\r\nThe RC4 ciphertext is prepended with 32 bytes of metadata containing the RC4 key for decryption in bytes 8-12.\r\nFigure 2: Structure of the decoded resource\r\nThe dropper decodes the Base64 payload and decrypts the result, which consists of a PE loading shellcode and the\r\nraw binary of the malware. Right after decryption, control is passed to the shellcode which locates the raw binary,\r\nloads it and then passes execution to its entry point.\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 2 of 13\n\nFigure 3: Decryption and execution of the payload embedded within the resource    \r\nThe malware’s dropper can be identified by a peculiar loop which invokes a message box to an undefined handle\r\nwith the value 0xFFFFA481 and the text “Will exec“.\r\nPayload\r\nThe payload consists of the following actions taking place consecutively:\r\nArgument check: If a filename is passed as an argument, it will be looked up in the current directory and\r\nexecuted with ShellExecuteW. However, if the argument ends with “\\” it will be assumed to be a directory\r\nname. In the latter case, it will be opened in a new window by spawning “explorer.exe” using\r\nShellExecuteW, with the directory path appended to the current directory as an argument. This feature\r\nexists for the purpose of running other processes under the malware, and is leveraged to replace all\r\nshortcuts to run the malware first and then use it to spawn the actual shortcut path, thereby achieving\r\npersistence in the system.\r\nSelf-copy: The malware creates a copy of itself in %appdata%.\r\nAntiVM Check: Uses SetupDiGetDeviceRegistryPropertyA to obtain a string with the device name of the\r\nhard drive, and checks whether it contains one of the following as substrings: “vbox“, “qemu“, “vmware“,\r\n“virtual hd“. In case it does, the malware infers it runs in a VM and terminates.\r\nStart-up process termination: Enumerates all the following registry keys in order to shut down all non-malware related start-up processes:\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 3 of 13\n\nFigure 4: Enumeration and termination of start-up process,\r\naccording to paths from registry run keys.\r\nComputer ID calculation: Each infected machine gets an ID of the format “\u003ccomputer_name\u003e#\r\n\u003ccalculated_md5\u003e“, where the 2nd parameter is the MD5 hash of a system info buffer with the following\r\nstructure:\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 4 of 13\n\nAn example of such structure in run-time can be seen here:\r\nFigure\r\n5: Structure of the buffer used for\r\ncalculating the hash value for the machine ID.\r\nGUID calculation: Most of the objects in the malware (events, mutexes, file-names etc.) are given a name\r\nbased on a generated GUID, which is built the following way (based on the system info struct explained\r\nearlier, SID of the current process owner and a key passed to the GUID generation function as an\r\nargument):\r\nDWORD Data1: MD5(sysinfo)[0..3] xor key\r\nDWORD Data2|Data3: MD5(sysinfo)[4..7] xor key\r\nDWORD Data4[0..3]: MD5(sysinfo)[8..11] xor CRC32(user_SID)\r\nDWORD Data4[4..7]: MD5(sysinfo)[12..15] xor CRC32(user_SID)\r\nAPC injection: Creates a suspended exe process, writes the contents of the malware’s mapped image to it,\r\nqueues the main worker thread control function (described next) as an APC and resumes its main thread.\r\nConsequently, the aforementioned function starts to run in the context of the initiated svchost.exe process.\r\nWorker thread control function: This routine contains the major bulk of the malware’s functionality, and\r\ninvokes its various features as threads. It is expected that this function will run under svchost.exe as a result\r\nof the injection described earlier, and in case this fails will run in the context of the current process.\r\nHowever, the latter will not happen in reality due to a bug in the code, where the handle of the initiated\r\nsvchost.exe main thread is closed right after the process handle is closed. This causes the process to crash,\r\navoiding any further malicious activity to occur.\r\nThe flow of the actions taken by the function itself is:\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 5 of 13\n\nPE loading actions, namely applying relocations and resolving imports for the malware’s mapped\r\nexecutable.\r\nCreation of a hidden scheduled task (with the use of the ITask COM class) which is set to start upon the\r\ncurrent user’s logon.\r\nCreation of a registry runkey under HKCM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run. The key’s\r\nname is a GUID generated beforehand and the path is set to the file copied to %appdata%.\r\nDeletion of the original malware file in a separate thread (only if the malware runs from a non-removable\r\ndrive, and successfully injected to svchost.exe).\r\nIf the malware is executed from removable media, it will register a designated class for it under\r\nHCKU\\Software\\Classes\\CLSID, with the classes name being a calculated GUID with the key 0xDEADBEEF.\r\nFigure 6: Registration of a class for the malware\r\nFile modification watchdog: A thread that constantly calculates the CRC32 of the copied malware binary in\r\n%appdata% and compares it with the original file’s CRC32. In case this changes, the copied file is deleted and\r\nrewritten it with the contents of the original one.\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 6 of 13\n\nFigure 7: File modification watchdog code\r\nShortcut replacement thread: Iterates through all mounted drives (obtained with GetLogicalDriveStringsW)\r\nand enumerates all files in order to find those with “.lnk” extension. In case such a file is found, it’s target\r\npath is modified (using the IPersistFile COM class) to execute cmd.exe with an argument consisting of:\r\nPath generated by the malware, containing the malware’s copy.\r\nThe enumerated file’s path, which will be invoked through the execution of the malware itself.\r\nInjection of process watchdog code: The malware will enumerate all running processes and will exclude 64 bit\r\nprocesses, the current process and ones which run an image with the names “teamviewer.exe“\\”tv_w32.exe”\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 7 of 13\n\nFigure 8: Exclusion of TeamViewer from targeted processes for injection\r\nAll other processes (as well as a malware created notepad.exe process) will get injected with the following piece\r\nof code:\r\nFigure 9: Injected process watchdog code\r\nwhere the pointers 0x11111111, 0x22222222, 0x33333333 and 0x44444444 will be replaced by the injecting\r\nfunction prior to writing the code, as can be seen below:\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 8 of 13\n\nFigure 10: Replacement of invalid pointers in the process watchdog\r\npayloads to actual function pointers.\r\nThe injected code itself will wait indefinitely on an event, which will be signaled when the original malware\r\nprocess is terminated. In case this happens the malware is spawned again.\r\nCommunication: All C2 domains are resident within the binary as AES256-CBC encrypted blobs, ordered in a\r\npointer table that can be found in offset 16 of the .data section.\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 9 of 13\n\nFigure 11: Encrypted CnC domain table\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 10 of 13\n\nThe key for decryption is “GD!brWJJBeTgTGSgEFB/quRcfCkBHWgl“\r\nFigure 12: Decryption routine for the CnC domains\r\nThe following types of communication can be observed in the malware:\r\n1. HTTP GET request to obtain a file from one of the sample’s CnCs. The CnC is contacted through a\r\nsubdomain of the format “v%d“, where the numeric value is obtained from a global variable set during run-time. If a file is returned from the server, it is being written with a random 10 character name under\r\n%appdata% and initiated with CreateProcessW.\r\nNote: other variants of the malware may use different subdomains, e.g. “up%d“.\r\n2. A raw protocol over TCP, used to obtain new CnC addresses from which files can be downloaded. The\r\nprotocol request message is a buffer that consists of 170 bytes, and has the following structure:\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 11 of 13\n\nFigure 13: Structure of a raw protocol request to the CnC\r\nThe response consists of 517 bytes and has the following structure:\r\nFigure 14: Response packet from the CnC\r\nIOCs:\r\n153a3104fe52062844fed64c7a033d8378f7977f – Dropper 0cf0f00b7c78d68365b4c890c76941051e244e6f\r\n– Unpacked payload\r\nWe have 9 active Anti-Bot signatures for DorkBot family:\r\nWin32.Dorkbot.E\r\nWin32.Dorkbot.G\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 12 of 13\n\nWin32.Dorkbot.H\r\nWin32.Dorkbot.I\r\nWin32.Dorkbot.J\r\nWin32.Dorkbot.K\r\nWin32.Dorkbot.L\r\nWIN32.DorkBot.A\r\nWIN32.DorkBot.B\r\nSource: https://research.checkpoint.com/dorkbot-an-investigation/\r\nhttps://research.checkpoint.com/dorkbot-an-investigation/\r\nPage 13 of 13", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://research.checkpoint.com/dorkbot-an-investigation/" ], "report_names": [ "dorkbot-an-investigation" ], "threat_actors": [ { "id": "f9806b99-e392-46f1-9c13-885e376b239f", "created_at": "2023-01-06T13:46:39.431871Z", "updated_at": "2026-04-10T02:00:03.325163Z", "deleted_at": null, "main_name": "Watchdog", "aliases": [ "Thief Libra" ], "source_name": "MISPGALAXY:Watchdog", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434679, "ts_updated_at": 1775826748, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/5f5756e36190ea5c5b90e7a5c33a3edc95a764c4.pdf", "text": "https://archive.orkl.eu/5f5756e36190ea5c5b90e7a5c33a3edc95a764c4.txt", "img": "https://archive.orkl.eu/5f5756e36190ea5c5b90e7a5c33a3edc95a764c4.jpg" } }