{
	"id": "022c9987-21b5-4e0a-965d-3d135e4914cd",
	"created_at": "2026-04-06T00:15:32.830806Z",
	"updated_at": "2026-04-10T13:12:19.208322Z",
	"deleted_at": null,
	"sha1_hash": "b590c86c89fa4f3d1a3bcc885176ad3d35eb8d91",
	"title": "ACBackdoor: Analysis of a New Multiplatform Backdoor",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1051862,
	"plain_text": "ACBackdoor: Analysis of a New Multiplatform Backdoor\r\nBy Ignacio Sanmillan\r\nPublished: 2019-11-18 · Archived: 2026-04-05 17:08:37 UTC\r\nIntroduction\r\nWe have discovered an undetected Linux backdoor which does not have any known connections to other threat\r\ngroups.\r\nVirusTotal detection rate of ACBackdoor Linux variant\r\nIn addition, we have found Windows variants of the same malware. As is common with most Windows variants,\r\nthis variant has a higher detection rate than its Linux counterpart.\r\nVirusTotal detection rate of ACBackdoor Windows variant\r\nThis malware seems to be unknown or at least undocumented to the infosec community, which may indicate\r\nretooling of a known threat group or the formation of a new one.\r\nWe have dubbed this malware ACBackdoor. ACBackdoor provides arbitrary execution of shell commands,\r\narbitrary binary execution, persistence, and update capabilities.\r\nIn this blog post we will explain the technical analysis of both ACBackdoor variants and highlight their\r\ndifferences in implementation. The findings we present strongly suggest the group behind this malware has\r\nprevious experience targeting Linux systems, and is expanding its coverage by porting ACBackdoor to Windows.\r\nTechnical Analysis\r\nThe Linux binary is a statically linked ELF file, while the Windows binary is a dynamically linked PE file.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 1 of 10\n\nBoth instances of this malware are practically identical in terms of overall functionality, with minor\r\nimplementation differences. However, if we pay close attention to each instance we can draw some conclusions\r\nregarding the nature of the authors.\r\nBoth malware instances share the same protocol to communicate with the same CNC server. However, these\r\ninstances have different delivery vectors:\r\nVirusTotal intelligence graph depicting connections between the samples\r\nInitially, we located the Linux instance in a Romanian-hosted server. Unfortunately, we do not have further\r\ninsights regarding the delivery vector used to deploy the Linux variant.\r\nWe later discovered via @nao_sec that the Windows instance was delivered via Fallout Exploit Kit.\r\nTo understand more about the delivery system of Fallout Exploit Kit we highly recommend reading nao_sec’s\r\ncomprehensive article on the subject matter.\r\nThis finding suggests that the operators behind ACBackdoor had sufficient funding to purchase Fallout Exploit\r\nKit and that they are currently using it to spread their Windows malware via malvertising campaigns.\r\nBackdoor Analysis\r\nThe Windows variant of this malware does not represent a complex threat in terms of Windows malware.\r\nConversely, the Linux variant shows more sophistication in regards to the implementation details used to replicate\r\nthe same functionality.\r\nWe first noticed the compiled Windows binary was generated using the MinGW compiler.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 2 of 10\n\nMinGW strings identified in ACBackdoor Windows instance\r\nThis indicates information regarding the malware authors’ development environment preference.\r\nThe main function is not obfuscated and appears to be straightforward in logic. In the Windows variant we can see\r\nhow some strings are decoded in the beginning of the function.\r\nWindows instance main function\r\nWe can see Linux-specific strings among the decrypted strings, such as a kernel thread process name or a path\r\nbelonging to a Linux file system.\r\nThese same strings are used in the Linux instance of this malware. In addition, these strings do not have any other\r\ncross-references among the binary, which may imply that the developers were too lazy to remove them when they\r\nwere porting code from their Linux implementation onto their Windows version.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 3 of 10\n\nACBackdoor Linux instance main function\r\nAfter initial string decoding the malware serializes the victim by collecting architecture, system, and MAC\r\naddress information.\r\nThe way the Windows variant collects this information is by calling the correspondent Windows API functions in\r\norder to retrieve the subject information such as IsWow64Process; to determine the architecture of the operating\r\nsystem or GetAdaptersInfo to retrieve the system’s MAC address.\r\nThe Linux variant, on the other hand, uses a different technique that mainly relies on uname system call to retrieve\r\narchitecture and system information, in addition to a combination of socket  / ioctl system calls to retrieve the\r\nMAC address.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 4 of 10\n\nSimilarities in code structure between ACBackdoor Linux and Windows instances\r\nAfter this information is collected, the malware will concatenate each of these fields, add the string ‘0.5’ likely\r\ndenoting some kind of versioning ID, and will then MD5 hash the resulting string.\r\nCompromised host information collected from both ACBackdoor samples\r\nAfter victim information has been serialized, the malware will apply some persistence mechanisms. The Windows\r\ninstance will initialize a registry entry so that the malware will be executed on system start-up. The Linux instance\r\nwill set up various symbolic links and add an initrd script for the malware to also run on system start-up. The\r\nWindows instance uses one of the most common registry entries used in Windows malware:\r\nHKCUSOFTWAREMicrosoftWindowsCurrentVersionRun\r\nThe use of this registry entry indicates this actor’s level of inexperience by using less conventional persistence\r\ntechniques to write more complex Windows malware.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 5 of 10\n\nPersistence implementations across ACBackdoor samples\r\nBased on the names chosen to label the persistent instances of this malware, we can see that the Windows instance\r\ntries to masquerade itself as a Microsoft Anti Spyware utility (MsMpEng.exe), while the Linux instance attempts\r\nto masquerade itself as the Ubuntu release update utility (update-notifier).\r\nThe Linux instance will then set an independent session via fork/setsid system calls in order to create an\r\nindependent process. It will close unnecessary file descriptors using prlimit/close system calls to then rename its\r\nprocess name to that of a kernel thread, specifically “[kworker/u8:7-ev]”.\r\nIf we run the ps command on a compromised Linux system we will see this process name among the listed\r\nprocesses:\r\nProcess renaming performed by ACBackdoor Linux instance\r\nCommand and Control Communication\r\nThe malware will proceed to communicate with the CNC. Both malware instances share the same CNC server and\r\ntransport protocol, that being HTTPS.\r\nThe malware will send an initial packet to the CNC with the previously collected victim information. The client\r\ndoes not appear to verify the authenticity of the certificate on TLS handshake, therefore the communication is\r\nprone to MITM attacks.\r\nThe malware creates the headers for the HTTP request in which some custom headers are included which embed\r\nspecific information for the server to collect. The following visual is an intercepted initial TLS stripped packet\r\nfrom a compromised Linux host which displays these headers:\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 6 of 10\n\nIntercepted TLS stripped HTTPS packet\r\nAmong the different headers we can highlight the ‘Access-Control’ and ‘X-Access’ headers which are\r\nunconventional HTTP headers.\r\nAccess-Control contains the base64 encoded string of the command type. In this case the type ‘info’, which\r\nis the preliminary packet sent to the CNC.\r\nX-Access contains an MD5 hash used as an integrity check for the contained payload. This MD5 hash was\r\npreviously generated after victim information was collected as documented above.\r\nThe payload is base64 encoded and it contains the crafted string containing all of the compromised host’s\r\ncollected information.\r\nThe malware then expects a response to this preliminary package in order to execute commands.\r\nThere is a total of four commands supported by ACBackdoor: these being info, run, execute, and update.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 7 of 10\n\nControl flow graph similarities on command handling across samples\r\nAs previously mentioned, the info command is really the first point of contact between the client and the CNC.\r\nThe run command is intended to run arbitrary shell commands. The execute command is capable of executing a\r\ngiven binary in the compromised host, and the update command updates the client itself.\r\nThese commands vary in implementation between the different instances of this malware. However, an additional\r\nhint may indicate the authors behind this malware have more experience writing Linux malware. This can be\r\nfound by examining the implementation of the execute command.\r\nIn the Windows instance, this command is implemented via CreateFile and CreateProcess Win32 API functions. In\r\nLinux, a combination of memfd_create, fork, and execveat system calls are used:\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 8 of 10\n\nExecute command implementation across ACBackdoor samples\r\nAt first glance, the implementations of these execute commands may not seem to be much different from each\r\nother in terms of functionality. However, it’s important to highlight that the Linux instance implementation does\r\nprovide a means to execute fileless code. This is not the case with the Windows implementation.\r\nThese specific details along with the analysis above have led us to conclude that the authors behind ACBackdoor\r\nare more comfortable operating in Linux systems, while they may currently be experimenting in Windows by\r\nporting their malware to this system.\r\nConclusion\r\nWe have covered the technical analysis of this multi-platform malware which we have named ACBackdoor. After\r\nfurther analysis of the Windows instance we have gotten a sense that the authors behind ACBackdoor have a lack\r\nof experience in writing Windows malware.\r\nIn addition, we have identified some strings belonging to the Linux version which are also present in the Windows\r\ninstance of ACBackdoor, implying that the Linux version was likely written before the Windows version.\r\nApart from having a lower detection rate, the Linux version is overall similar in logic to the Windows variant. The\r\nLinux implant has noticeably been written better than the Windows implant, highlighting the implementation of\r\nthe persistence mechanism along with the different backdoor commands and additional features not seen in the\r\nWindows version such as independent process creation and process renaming.\r\nWe can assess with high confidence that this threat group has experience developing Linux-based malware.\r\nBecause there is no attributable information documented on this backdoor, there is a possibility that some known\r\nLinux-based threat group is updating its toolset.\r\nIn addition, this is further evidence that Linux variants have consistently lower detection rates than Windows.\r\nThe binary code from both ACBackdoor implants have been indexed in Intezer Analyze. Users can now detect\r\nand classify Linux and Windows variants of this threat by uploading their suspicious file(s) or scanning the code\r\nrunning in their endpoint via analyze.intezer.com.\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 9 of 10\n\nIOCs\r\n5d51dbf649d34cd6927efdb6ef082f27a6ccb25a92e892800c583a881bbf9415\r\n907e1dfde652b17338d307b6a13a5af7a8f6ced93a7a71f7f65d40123b93f2b8\r\n193[.]29[.]15[.]147\r\n185[.]198[.]56[.]53\r\nSource: https://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nhttps://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.intezer.com/blog/research/acbackdoor-analysis-of-a-new-multiplatform-backdoor/"
	],
	"report_names": [
		"acbackdoor-analysis-of-a-new-multiplatform-backdoor"
	],
	"threat_actors": [],
	"ts_created_at": 1775434532,
	"ts_updated_at": 1775826739,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b590c86c89fa4f3d1a3bcc885176ad3d35eb8d91.pdf",
		"text": "https://archive.orkl.eu/b590c86c89fa4f3d1a3bcc885176ad3d35eb8d91.txt",
		"img": "https://archive.orkl.eu/b590c86c89fa4f3d1a3bcc885176ad3d35eb8d91.jpg"
	}
}