{
	"id": "be500689-cdc0-42de-820c-bbeea8add213",
	"created_at": "2026-04-06T01:30:44.600182Z",
	"updated_at": "2026-04-10T03:21:00.617469Z",
	"deleted_at": null,
	"sha1_hash": "22432b80cc09296db120ad70cf87ac3dd1dac2f0",
	"title": "SYNful Knock - A Cisco router implant - Part I | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1164828,
	"plain_text": "SYNful Knock - A Cisco router implant - Part I | Mandiant\r\nBy Mandiant\r\nPublished: 2015-09-15 · Archived: 2026-04-06 01:20:13 UTC\r\nWritten by: Bill Hau, Tony Lee, Josh Homan\r\nOverview\r\nRouter implants, from any vendor in the enterprise space, have been largely believed to be theoretical in nature\r\nand especially in use. However, recent vendor advisories indicate that these have been seen in the wild. Mandiant\r\ncan confirm the existence of at least 14 such router implants spread across four different countries: Ukraine,\r\nPhilippines, Mexico, and India.\r\nSYNful Knock is a stealthy modification of the router's firmware image that can be used to maintain persistence\r\nwithin a victim's network. It is customizable and modular in nature and thus can be updated once implanted. Even\r\nthe presence of the backdoor can be difficult to detect as it uses non-standard packets as a form of pseudo-authentication.\r\nThe initial infection vector does not appear to leverage a zero-day vulnerability. It is believed that the credentials\r\nare either default or discovered by the attacker in order to install the backdoor. However, the router's position in\r\nthe network makes it an ideal target for re-entry or further infection.\r\nFinding backdoors within your network can be challenging; finding a router implant, even more so. This article\r\nnot only dissects the implant, but also provides practical methods and tools for detecting a SYNful Knock\r\ncompromise.\r\nThe impact of finding this implant on your network is severe and most likely indicates the presence of other\r\nfootholds or compromised systems. This backdoor provides ample capability for the attacker to propagate and\r\ncompromise other hosts and critical data using this as a very stealthy beachhead.\r\nImplant Summary\r\nThe implant consists of a modified Cisco IOS image that allows the attacker to load different functional modules\r\nfrom the anonymity of the internet. The implant also provides unrestricted access using a secret backdoor\r\npassword. Each of the modules are enabled via the HTTP protocol (not HTTPS), using a specifically crafted TCP\r\npackets sent to the routers interface. The packets have a nonstandard sequence and corresponding\r\nacknowledgment numbers. The modules can manifest themselves as independent executable code or hooks within\r\nthe routers IOS that provide functionality similar to the backdoor password. The backdoor password provides\r\naccess to the router through the console and Telnet.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 1 of 14\n\nKnown Affected Hardware\r\nCisco 1841 router\r\nCisco 2811 router\r\nCisco 3825 router\r\nNote: Our initial identification revealed that other models are likely affected based on the similarity in core\r\nfunctionality and IOS code base.\r\nPersistence\r\nThe implant resides within a modified Cisco IOS image and, when loaded, maintains its persistence in the\r\nenvironment, even after a system reboot. However, any further modules loaded by the attacker will only exist in\r\nthe router’s volatile memory and will not be available for use after reboot. From a forensic standpoint, if the\r\nmodules are loaded in volatile memory, one can analyze them by obtaining a core dump of the router image[1].\r\nDetails\r\nModifications to the IOS binary can be broken down into the following four functions:\r\n1. Modify the translation lookaside buffer (TLB) Read/Write attributes\r\n2. Modify a legitimate IOS function to call and initialize the malware\r\n3. Overwrite legitimate protocol handling functions with malicious code\r\n4. Overwrite strings referenced by legitimate functions with strings used by the malware\r\nTLB Read /Write Attributes\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 2 of 14\n\nThe malware forces all TLB Read and Write attributes to be Read-Write (RW). We believe this change is made to\r\nsupport the hooking of IOS functions by loaded modules. If the TLB attributes are not set to RW, then\r\nmodifications to the cached pages may not be propagated to the original page in memory.\r\nThis is accomplished with two single-byte modifications made to the IOS function suspected to be responsible for\r\nconfiguring the TLB. The unmodified function set the first two bits of a register to 1, and the modified function\r\nsets the first three bits to 1. Mandiant believes that the third bit controls the Write permissions on the TLB entry.\r\nFigure 3 shows the modified instructions.\r\nFigure 3: Modification to TLB attributes\r\nThis brings us to one of the host-based indicators discussed above. The TLB attributes can be examined using the\r\nenable mode command \"show platform\". The TLB output of an unmodified IOS image is shown below in Figure\r\n4.\r\nFigure 4: TLB entries for a legitimate IOS image\r\nIf the router has been implanted with a modified IOS image, the RW attributes should be:\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 3 of 14\n\nFigure 5: TLB entries for a modified IOS image\r\nDepending on router hardware, certain ranges of memory addresses are typically read only executable code\r\nsections. The simplest way to determine if the router has been modified is to use the \"show platform | include RO,\r\nValid\" command. The IOS image may have been tampered with to allow the modification of executable code if no\r\nresults are displayed.\r\nInitialize the Malware\r\nTo execute the malware during IOS image loading, Mandiant believes that a function associated with process\r\nscheduling was modified. This was chosen because the modified function is called early on during the IOS boot\r\nsequence, and is always called, as long as the IOS boots correctly. The target address of a function call is modified\r\nto point to the malware hook processing function. Our research has shown that the malware is initialized after the\r\nhook processing function checks the calling function is valid in the modified IOS. Now that the malware is up and\r\nrunning, it executes the original IOS function so no one is the wiser.\r\nMandiant believes the modified function is linked with the process scheduling task, the behavior is such that it\r\nenters an infinite loop once called. In addition, several of the sub functions reference strings associated with\r\nprocess scheduling, such as \"Threshold: %s CPU Utilization(Total/Intr):...\".\r\nMalware Executable Code Placement\r\nTo prevent the size of the image from changing, the malware overwrites several legitimate IOS functions with its\r\nown executable code. The attackers will examine the current functionality of the router and determine functions\r\nthat can be overwritten without causing issues on the router. Thus, the overwritten functions will vary upon\r\ndeployment.\r\nMalware Strings and Configuration\r\nKeeping with the theme mentioned above, since the image size cannot change, the implant also overwrote some\r\nreporting strings with its own configuration. This is another indicator of compromise that can be used for detection\r\npurposes. The legitimate strings that are overwritten are shown in Figure 6.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 4 of 14\n\nFigure 6: Strings associated with a valid function overwritten by the malware\r\nThe contents shown in Figure 6 were replaced with the contents shown below in Figure 7. Clearly visible are the\r\nmalware’s strings included in the HTTP header used in Command and Control, along with the default password,\r\nwhich we have intentionally blanked. This will provide potential victims time to search their own networks for\r\ncompromise and remediate the issue. Feel free to contact us via email at synfulknock-at-fireeye.com and we can\r\nprovide the password after you suspect you have been compromised.\r\nFigure 7: Malware strings\r\nAgain we arrive at another host-based indicator that can potentially be used to identify the presence of the implant;\r\nhowever, the location of the configuration strings may vary depending on deployment and must first be\r\ndiscovered.\r\nA modified IOS image will produce a very different and suspicious result when running what would seem to be an\r\nordinary IOS command.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 5 of 14\n\nBackdoor Password\r\nThe attacker can utilize the secret backdoor password in three different authentication scenarios. The implant will\r\nfirst check to see if the user input is the backdoor password. If so, access is granted. Otherwise, the implanted\r\ncode will pass the credentials on for verification of potentially valid credentials. This ensures that the least amount\r\nof suspicion is raised. The following three instances were verified to enable access using the backdoor password:\r\nTable 1: Authentication functions in which the secret backdoor password can be used\r\nResearch has shown that SSH or HTTPS sessions do not provide access for the backdoor password. This could be\r\na configuration issue and may vary on compromise.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 6 of 14\n\nFigure 8: Subtle difference between authenticating using a legitimate password and the backdoor password\r\nNetwork Command and Control (CnC)\r\nThe Command and Control portion of the implant is modular and allows additional functionality to be loaded into\r\nthe IOS. The CnC functionality is stealthy because it requires a series of TCP trigger packets that the malware\r\nmonitors for specific TCP header values and content. Even if filters are enabled on the router, the TCP trigger is\r\nprocessed by the malware. The malware will respond to trigger packets sent to three different addresses: the router\r\ninterface, the broadcast IP, and the network address (the first IP in a subnet).\r\n1. To initiate the process, a uniquely crafted TCP SYN packet is sent to port 80 of the “implanted” router. It is\r\nimportant to note that the difference between the sequence and acknowledgment numbers must be set to\r\n0xC123D. Also the ACK number doesn’t need to be zero.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 7 of 14\n\nFigure 9: TCP SYN with sequence and acknowledgement offset of 0xC123D\r\n1. As typical with a 3-way handshake, the malware responds with a TCP SYN-ACK message acknowledging the\r\nfirst SYN message. However, the following conditions will be present:\r\nThe differential between the acknowledgment and sequence numbers is now 0xC123E\r\nThe following hard-coded TCP options are set: \"02 04 05 b4 01 01 04 02 01 03 03 05\"\r\nThe urgent pointer is also set to 0x0001 but the urgent flag is not set\r\nThe malware also copies the acknowledgment number from the SYN packet for the sequence number. A\r\ntypical server usually generates a random sequence number, thus this is not a standard TCP handshake.\r\nThese unique conditions are the anomalies that Mandiant used to write network detection signatures and tools.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 8 of 14\n\nFigure 10: TCP SYN-ACK with sequence and acknowledgement offset of 0xC123E\r\n1. After the final ACK to complete the 3-way handshake, the controller then sends the following TCP message:\r\nThe PUSH and ACK flags are set\r\nFrom the start of the TCP header, at offset 0x62, the string \"text\" is written\r\nThe command shown below is at offset 0x67 from the TCP header\r\nThe command is in the following format:\r\nThe [CMD Data] is XOR encoded with a static key. There is a checksum algorithm, which is a four-byte XOR of\r\nthe decoded [CMD Data].\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 9 of 14\n\nFigure 11: Controller command packet\r\n1. The malware response is encapsulated in the following static HTTP/HTML server response. Fortunately, the\r\nresponse from the malware is not XOR encoded and will be easy to decipher.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 10 of 14\n\nFigure 12: Victim response\r\nSupported Commands\r\nWe mentioned previous that this implant is modular. The five commands shown in the table below are used for\r\nloading additional modules and functionality on the victim router. A total of 100 additional modules can be loaded,\r\nhowever these modules are memory resident and will not persist after a reboot or reload.\r\nCommand messages set the first WORD (4-byte big-endian) to zero. The second WORD identifies the message\r\ntype (values zero through four). All message types will start with the following eight bytes:\r\nID Description\r\n0 List loaded modules and their current state. The response contains a word representing the ID number\r\nfollowed by a word representing the state for each loaded module.\r\nValid states are as follows:\r\n00 - Memory is allocated\r\n01 - Module is loaded into memory\r\n02 - Module is activated\r\nFor example, if the malware responds with this message:\r\n00 00 00 03 00 00 02\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 11 of 14\n\nID Description\r\nThen, the message would indicate module 03 is in the activated state (02).\r\nList loaded modules and their current state. The response contains a word representing the ID number\r\nfollowed by a word representing the state for each loaded module.\r\nValid states are as follows:\r\n00 - Memory is allocated\r\n01 - Module is loaded into memory\r\n02 - Module is activated\r\nFor example, if the malware responds with this message:\r\n00 00 00 03 00 00 02\r\nThen, the message would indicate module 03 is in the activated state (02).\r\n1 Allocate space for an additional module to be loaded. The command provides the module size for two\r\nrequired buffers. The malware allocates the memory for two buffers and returns the addresses in the\r\nresponse. The first buffer is the executable code, and we suspect that the second buffer is for\r\nconfiguration and storage. The syntax for this message follows this format:\r\n[WORD ID][WORD first buffer length][WORD second buffer length]\r\nAn example command that tells the malware to allocate 0x0C bytes for the first buffer and 0x90 bytes\r\nfor the second buffer of module ID 0x02:\r\n00 00 00 02 00 00 00 0C 00 00 00 90\r\nAn example response from the server shows the first buffer is at memory address 0x66012C4C and the\r\nsecond is at 0x650DCD20:\r\n66 01 2C 4C 65 0D CD 20\r\nAfter executing this command, the module state is set to zero. Allocate space for an additional module\r\nto be loaded. The command provides the module size for two required buffers. The malware allocates\r\nthe memory for two buffers and returns the addresses in the response. The first buffer is the executable\r\ncode, and we suspect that the second buffer is for configuration and storage. The syntax for this\r\nmessage follows this format:\r\n[WORD ID][WORD first buffer length][WORD second buffer length]\r\nAn example command that tells the malware to allocate 0x0C bytes for the first buffer and 0x90 bytes\r\nfor the second buffer of module ID 0x02:\r\n00 00 00 02 00 00 00 0C 00 00 00 90\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 12 of 14\n\nID Description\r\nAn example response from the server shows the first buffer is at memory address 0x66012C4C and the\r\nsecond is at 0x650DCD20:\r\n66 01 2C 4C 65 0D CD 20\r\nAfter executing this command, the module state is set to zero.\r\n2\r\nPopulate the memory allocated for the module. This command is used to populate the executable code\r\nand suspected configuration data.\r\n[0x80 Bytes hook data][WORD first buffer length][WORD second buffer length] [First buffer...]\r\n[Second buffer...]\r\nSimilar to how the default password hook functions, the hook data buffer is used to inject additional\r\nhooks into the IOS. The hook buffer provides addresses within the IOS where hooks should be installed,\r\nand the code that should be run when the hooks are executed.\r\nAfter executing this command, the module state is set to one.\r\nPopulate the memory allocated for the module. This command is used to populate the executable code\r\nand suspected configuration data.\r\n[0x80 Bytes hook data][WORD first buffer length][WORD second buffer length] [First buffer...]\r\n[Second buffer...]\r\nSimilar to how the default password hook functions, the hook data buffer is used to inject additional\r\nhooks into the IOS. The hook buffer provides addresses within the IOS where hooks should be installed,\r\nand the code that should be run when the hooks are executed.\r\nAfter executing this command, the module state is set to one.\r\n3\r\nActivate a loaded module. The malware parses the hook data buffer and creates the necessary hooks\r\nwithin the OS to execute a module. The only argument is a WORD representing the module ID.\r\nAfter executing this command, the module state is set to two.\r\nActivate a loaded module. The malware parses the hook data buffer and creates the necessary hooks\r\nwithin the OS to execute a module. The only argument is a WORD representing the module ID.\r\nAfter executing this command, the module state is set to two.\r\n4\r\nRemove a module. The memory allocated for the module is released and the state is set to zero. The\r\nmodule will no longer show up in the active modules command.\r\nRemove a module. The memory allocated for the module is released and the state is set to zero. The\r\nmodule will no longer show up in the active modules command.\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 13 of 14\n\nTable 2: Supported Commands\r\nIf the first WORD of a message is not zero, the code associated with the module ID of the first WORD is\r\nexecuted. This enables the execution of code that is not hooked into an IOS function.\r\nConclusion\r\nWe hope that this post has advanced the understanding of this flexible and stealthy router implant. It should be\r\nevident now that this attack vector is very much a reality and will most likely grow in popularity and prevalence.\r\nIn the next part of this series, we will examine methods that can be used to passively and actively detect this\r\nimplant.\r\nThe following blog entry shows how to produce a Cisco IOS core dump: http://blogs.cisco.com/security/offline-analysis-of-ios-image-integrity\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nhttps://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/"
	],
	"report_names": [
		"synful-knock-acis"
	],
	"threat_actors": [],
	"ts_created_at": 1775439044,
	"ts_updated_at": 1775791260,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/22432b80cc09296db120ad70cf87ac3dd1dac2f0.pdf",
		"text": "https://archive.orkl.eu/22432b80cc09296db120ad70cf87ac3dd1dac2f0.txt",
		"img": "https://archive.orkl.eu/22432b80cc09296db120ad70cf87ac3dd1dac2f0.jpg"
	}
}