{
	"id": "b2b53295-844a-4970-af60-0df1ffb09825",
	"created_at": "2026-04-06T00:17:33.060243Z",
	"updated_at": "2026-04-10T03:21:05.385758Z",
	"deleted_at": null,
	"sha1_hash": "fa3be253e3c87630ba09c1d8fabf0e444f4a8e42",
	"title": "ZeroAccess uses Self-Debugging",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 88946,
	"plain_text": "ZeroAccess uses Self-Debugging\r\nBy Joshua Cannell\r\nPublished: 2013-07-24 · Archived: 2026-04-05 21:28:59 UTC\r\nDebuggers—a tool traditionally used to find errors (called “bugs”) in code—are also used by security experts. In\r\nthe field of malware analysis, debuggers are a vital tool used to reverse-engineer malware binaries, helping\r\nanalysts to understand the purpose and functionality of malware when dynamic analysis isn’t enough.\r\nBecause they’re such a valuable tool, sometimes malware authors try to prevent analysts from using them. By\r\nemploying various techniques in the code (known as “anti-debugging”), malware can successfully thwart junior\r\nanalysts.\r\nRecently I found an interesting anti-debugging technique I haven’t seen before. I discovered this technique while\r\nreversing a ZeroAccess Trojan (seems it’s always ZeroAccess lately, right?).\r\nThe technique employs various native Win32 APIs used for debugging a process. By using these APIs, the analyst\r\ncannot use their own debugger, since only one debugger can be attached to a process at a time.\r\nTo connect to the debugger at the API level, the Trojan uses DbgUIConnectToDbg. This API along with others\r\nused to communicate with the Windows Debugger all seem to be undocumented by Microsoft.\r\nNext the Trojan creates a child process using the calling EXE (new-sirefef.exe). This was not surprising, as\r\nmalware usually does this while unpacking. Allow me to explain.\r\nhttps://blog.malwarebytes.com/threat-analysis/2013/07/zeroaccess-anti-debug-uses-debugger/\r\nPage 1 of 3\n\nTypically, a parent process creates a suspended child process using the calling EXE. Afterward, the parent will de-obfuscate some code and then place it in the child. Whenever this is complete, the parent makes a call to execute\r\nthe child (usually with ResumeThread), which is now completely different from the calling EXE. And thus, while\r\nyou have two processes that appear identical, they are completely different when viewed internally.\r\nThis sample doesn’t quite work this way. Under the creation flags parameter for the CreateProcess function, the\r\nCREATE_SUSPENDED flag was not being used, but instead the DEBUG_PROCESS flag. There was also\r\nanother used, called CREATE_PRESERVE_CODE_AUTHZ_LEVEL (Note: for a list of process creation flags,\r\nclick here).\r\nNow both the parent and child process are being debugged, which means we can’t attach an additional debugger\r\nto either. This complicates matters as the debugger is the primary tool we use to step through code.\r\nHowever, we can still observe what’s happening statically using our IDA dump. The parent process appears to\r\nhandle debug event codes and performs an action for each event (for a list of all codes, see here). After an event\r\nhas been processed the Trojan continues debugging and receives another event using DbgUiContinue.\r\nWhen an EXCEPTION_DEBUG_EVENT code is received, the Trojan enters a function that decrypts a PE DLL\r\nfile to the heap. The new PE is then placed into the memory space of the child process.\r\nhttps://blog.malwarebytes.com/threat-analysis/2013/07/zeroaccess-anti-debug-uses-debugger/\r\nPage 2 of 3\n\nThe new PE file is actually the final unpacked version of the rootkit. We can dump the memory from here and\r\nload it into IDA to perform some static analysis. Looks like we have some websites in plain-text the Trojan is\r\ngoing to contact, possibly to locate the infected user (geoip_country_code).\r\nThis is just another example of how malware authors attempt to prevent reverse-engineering of their code with\r\nanti-debugging. In this example, however, the ZeroAccess Trojan does not allow the analyst to use their own\r\ndebugger by connecting to the Windows Debugger itself. All in all I think it’s a very interesting technique, and\r\nwe’re sure to see more of it in the future.\r\n_______________________________________________________________________________\r\nJoshua Cannell is a Malware Intelligence Analyst at Malwarebytes where he performs research and in-depth\r\nanalysis on current malware threats. He has over 5 years of experience working with US defense intelligence\r\nagencies where he analyzed malware and developed defense strategies through reverse engineering techniques.\r\nHis articles on the Unpacked blog feature the latest news in malware as well as full-length technical analysis. \r\nFollow him on Twitter @joshcannell\r\nAbout the author\r\nGathers threat intelligence and reverse engineers malware like a boss.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2013/07/zeroaccess-anti-debug-uses-debugger/\r\nhttps://blog.malwarebytes.com/threat-analysis/2013/07/zeroaccess-anti-debug-uses-debugger/\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2013/07/zeroaccess-anti-debug-uses-debugger/"
	],
	"report_names": [
		"zeroaccess-anti-debug-uses-debugger"
	],
	"threat_actors": [],
	"ts_created_at": 1775434653,
	"ts_updated_at": 1775791265,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fa3be253e3c87630ba09c1d8fabf0e444f4a8e42.pdf",
		"text": "https://archive.orkl.eu/fa3be253e3c87630ba09c1d8fabf0e444f4a8e42.txt",
		"img": "https://archive.orkl.eu/fa3be253e3c87630ba09c1d8fabf0e444f4a8e42.jpg"
	}
}