{
	"id": "ff9567ad-b48d-48e6-9045-c4f83019f232",
	"created_at": "2026-04-06T00:15:05.80975Z",
	"updated_at": "2026-04-10T13:11:38.59001Z",
	"deleted_at": null,
	"sha1_hash": "6fd58aa4f179d8cc08ae23e60ba445ebc178d7f1",
	"title": "TOLLBOOTH: What's yours, IIS mine",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 9842697,
	"plain_text": "TOLLBOOTH: What's yours, IIS mine\r\nBy Daniel Stepanic, Jia Yu Chan, Salim Bitam, Seth Goodwin, Andrew Pease, Braxton Williams\r\nPublished: 2025-10-22 · Archived: 2026-04-05 20:07:34 UTC\r\nIntroduction\r\nIn September 2025, Texas A\u0026M University System (TAMUS) Cybersecurity, a managed detection and response provider in\r\ncollaboration with Elastic Security Labs, discovered post-exploitation activity by a Chinese-speaking threat actor who\r\ninstalled a malicious IIS module, which we are calling TOLLBOOTH. During this time, we observed a Godzilla-forked\r\nwebshell framework, the use of the Remote Monitoring and Management (RMM) tool GotoHTTP, along with a malicious\r\ndriver used to conceal their activity. The threat actor exploited a misconfigured IIS web server that used ASP.NET machine\r\nkeys found in public resources, such as Microsoft’s documentation or StackOverflow support pages.\r\nA similar chain of events was first reported by Microsoft in February, earlier this year. Our team believes this is the\r\ncontinuation of the same threat activity that AhnLab also detailed in April, based on similar malware and behaviors. During\r\nthis event, we were able to leverage our partnership with Texas A\u0026M System Cybersecurity to collect insights around the\r\nactivity. Additionally, through collaboration with Validin, leveraging their global scanning infrastructure, we’ve determined\r\nthat organizations worldwide have been impacted by this campaign. The following report will detail the events and tooling\r\nused in this activity cluster, known as REF3927. Our hope is to raise more awareness of this activity among defenders and\r\norganizations, as it is actively being abused at a global scale.\r\nKey takeaways\r\nThreat actors are abusing misconfigured IIS servers using publicly exposed machine keys\r\nPost-compromise behaviors include using a malicious driver, remote monitoring tooling, credential dumping,\r\nwebshell deployment, and IIS malware\r\nThreat actors adapted the open source “Hidden” rootkit project to hide their presence\r\nThe main objective appears to be to install an IIS backdoor, called TOLLBOOTH, that includes SEO cloaking and\r\nwebshell capabilities\r\nThis campaign included large-scale exploitation across geographies and industry verticals\r\nCampaign Overview\r\nAttack vector\r\nLast month, Elastic Security Labs and Texas A\u0026M System Cybersecurity investigated an intrusion involving a\r\nmisconfigured Windows IIS server. This was directly related to a server configured with ASP.NET machine keys that were\r\npreviously published on the Internet. Machine keys used in ASP.NET applications refer to cryptographic keys used to\r\nencrypt and validate data. These keys are composed of two parts, ValidationKey and DecryptionKey , which are used to\r\nsecure ASP.NET features such as ViewState and authentication cookies.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 1 of 24\n\nREF3927 attack pattern \u0026 TOLLBOOTH SEO cloaking workflow\r\nViewState is a mechanism used by ASP.NET web applications to preserve the state of a page and its controls across HTTP\r\nrequests. Since HTTP is a stateless protocol, ViewState allows data to be collected when the page is submitted and\r\nrendered again. This data is stored in a hidden field ( __VIEWSTATE ) on the page that is serialized and encoded in Base64.\r\nThis ViewState field is susceptible to deserialization attacks, allowing an attacker to forge payloads using the application's\r\nmachine keys. We have reason to believe this is part of an opportunistic campaign targeting Windows web servers using\r\npublicly exposed machine keys.\r\nBelow is an example of this type of deserialization attack, demonstrated via a POST request in a virtual environment using\r\nan open source .NET deserialization payload generator. The __VIEWSTATE field contains a URL-encoded and Base64-\r\nencoded payload that will perform a whoami and write a file to a directory. With a successful exploitation request, the\r\nserver will respond with an HTTP/1.1 500 Internal Server Error .\r\nPacket capture showing an example of a successful deserialization attack\r\nPost-compromise activity\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 2 of 24\n\nUpon initial access through ViewState injection, REF3927 was observed deploying webshells, including a Godzilla shell\r\nframework, to facilitate persistent access. They then enumerated privileges and attempted (unsuccessfully) to create their\r\nown user accounts. When account creation attempts failed, the actor then uploaded and executed the GotoHTTP Remote\r\nMonitoring and Management (RMM) tool. The threat actor created an Administrator account and attempted to dump\r\ncredentials using Mimikatz, but this was prevented by Elastic Defend.\r\nElastic Defend alerting showing hands-on post-compromise activity\r\nWith attempts to further expand the scope of the intrusion blocked, the threat actor deployed their traffic hijacking IIS\r\nModule, TOLLBOOTH, as a means to monetize their access. The actor also attempted to deploy a modified version of the\r\nopen-source Hidden rootkit to obfuscate their malware. In the observed intrusion, Elastic Defend prevented both\r\nTOLLBOOTH and the rootkit from being executed.\r\nActor attempts to deploy Mimikatz, HIDDENDRIVER, and TOLLBOOTH\r\nGodzilla EKP analysis\r\nOne of the main tools used by this group is a Godzilla-forked framework called Z-Godzilla_ekp written by ekkoo-z. This\r\ntool piggybacks off the previous Godzilla project by adding new features such as an AMSI bypass plugin and masquerading\r\nits network traffic to appear more legitimate. This toolkit allows operators to generate ASP.NET, Java, C#, and PHP\r\npayloads, connect to targets, and provides different encryption options to hide network traffic. This framework uses a plugin\r\nsystem driven by a GUI with many features, including:\r\nDiscovery/enumeration capabilities\r\nPrivilege escalation techniques\r\nCommand execution/file execution\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 3 of 24\n\nShellcode loader, meterpreter, in-memory PE execution\r\nFile management, zipping utility\r\nCred stealing plugin ( lemon ) - Retrieves FileZilla, Navicat, WinSCP, and Xmanager credentials\r\nBrowser password scraping\r\nPort scanning, HTTP proxy configuration, note-taking\r\nCommand execution plugin from Z-Godzilla_ekp\r\nBelow is a network traffic example showing the operator traffic to the webshell ( error.aspx ) using Z-Godzilla_ekp . The\r\nwebshell will take the Base64-encoded AES-encrypted data from the HTTP POST request, then execute the .NET assembly\r\nin-memory. These requests are disguised by embedding the encrypted data in HTTP POST parameters in order to blend in as\r\nnormal network traffic.\r\nExample of POST request using Z-Godzilla_ekp\r\nRootkit analysis\r\nThe attacker hid their presence on the infected machine by deploying a kernel rootkit. This rootkit works in conjunction with\r\na userland application named HijackDriverManager, whose interface strings are written in Chinese, to interact with the\r\ndriver. For this analysis, we examined both the malicious rootkit and the code from the original “Hidden” open-source\r\nproject from which it was derived. Internally, we are calling the rootkit HIDDENDRIVER and the userland application\r\nHIDDENCLI .\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 4 of 24\n\nThis malicious software is a modified version of the open source rootkit Hidden, which has been available on GitHub for\r\nyears. The malware author made minor modifications before compilation. For example, the rootkit uses Direct Kernel\r\nObject Manipulation (DKOM) to hide its presence and maintain persistence on the compromised system. The compiled\r\ndriver still has “hidden” within the compilation path string, indicating that they used the “Hidden” rootkit project.\r\nRookit’s string showing the compilation path\r\nUpon initial loading into the kernel, the driver prioritizes a series of critical initialization steps. It first invokes seven\r\ninitialization functions:\r\nInitializeConfigs\r\nInitializeKernelAnalyzer\r\nInitializePsMonitor\r\nInitializeFSMiniFilter\r\nInitializeRegistryFilter\r\nInitializeDevice\r\nInitializeStealthMode\r\nTo prepare its internal components before populating its driver object and associated fields, such as major functions.\r\nMalicious rootkit initialization function\r\nThe following sections will elaborate on each of these seven critical initialization functions, detailing their purpose.\r\nInitializeConfigs\r\nThe rootkit's initial action is to run the InitializeConfigs function. This function's sole purpose is to read the rootkit's\r\nconfiguration from the driver's service key in the Windows registry, which is populated by the userland application. These\r\nvalues are extracted and put in global configuration variables that will be later used by the rootkit.\r\nThe following table summarizes the configuration parameters that the rootkit extracts from the registry:\r\nRegistry name Description Type\r\nKbj_WinkbjFsDirs A list of directory paths to be hidden string\r\nKbj_WinkbjFsFiles A list of file paths to be hidden string\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 5 of 24\n\nRegistry name Description Type\r\nKbj_WinkbjRegKeys A list of registry keys to be hidden string\r\nKbj_WinkbjRegValues A list of registry values to be hidden string\r\nKbj_FangxingImages A list of process images to whitelist string\r\nKbj_BaohuImages A list of process images to protect string\r\nKbj_WinkbjImages A list of process images to be hidden string\r\nKbj_Zhuangtai A global kill switch that is set from userland bool\r\nKbj_YinshenMode This flag signals that the rootkit must conceal its artifacts. bool\r\nRootkit retrieves values from its configuration stored in the registry\r\nInitializeKernelAnalyzer\r\nIts purpose is to dynamically scan the kernel memory to find the addresses of the PspCidTable and ActiveProcessLinks\r\nthat are needed.\r\nThe PspCidTable is the kernel's structure that serves as a table for process and thread IDs, while ActiveProcessLinks\r\nunder the _EPROCESS structure serves as a doubly-linked list connecting all currently running processes. It allows the\r\nsystem to track and traverse all active processes. By removing entries from this list, it is possible to hide processes from\r\nenumeration tools like Process Explorer.\r\nLookForPspCidTable\r\nIt searches for the PspCidTable address by disassembling the function PsLookupProcessByProcessId with the library\r\nZydis and parsing it.\r\nOriginal hidden code: PspCidTable lookup\r\nLookForActiveProcessLinks\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 6 of 24\n\nThis function determines the offset of the ActiveProcessLinks field within the _EPROCESS structure. It uses hardcoded\r\noffset values specific to different Windows versions. It has a fast scanning process that relies on these hardcoded values to\r\nfind the ActiveProcessLinks field, which will be validated by another function. In case it fails to find it with the hardcoded\r\nvalues, it takes a brute-force approach by starting from a hardcoded relative offset to the maximum possible offset.\r\nInitializePsMonitor\r\nInitializePsMonitor sets up the rootkit's process monitoring and manipulation engine. This is the heart of its ability to\r\nhide processes.\r\nIt first initializes three AVL tree structures to hold information (rules) for excluding, protecting, and hiding processes. It uses\r\nRtlInitializeGenericTableAvl for high-speed lookups and populates them with data from the configuration. It then sets\r\nup different kernel callbacks to monitor the system using the set of rules.\r\nRegistering object manager callback with (ObRegisterCallbacks)\r\nThis hook registers the ProcessPreCallback and ThreadPreCallback functions. The kernel's Object Manager executes\r\nthis code before it completes any request to create or duplicate a handle to a process or thread.\r\nRootkit registering process and thread precallbacks\r\nWhen a process tries to get a handle on another process, the callback function ProcessPreCallback is called. It will first\r\ncheck if the destination process is a protected process (in the list). If it is the case, instead of not granting access, it will\r\nsimply downgrade its rights over the protected process with the access set to SYNCHRONIZE |\r\nPROCESS_QUERY_LIMITED_INFORMATION .\r\nThis will ensure that processes cannot interact with/inspect, or kill the protected process.\r\nThe same mechanism applies to threads.\r\nProcess Creation Callback(PsSetCreateProcessNotifyRoutineEx)\r\nThe rootkit registers a callback with the PsSetCreateProcessNotifyRoutineEx API on process creation. When a new\r\nprocess is launched, this callback runs a function CheckProcessFlags that checks the process’s image against the\r\nconfigured list of image paths. It then creates an entry for this new process in its internal tracking table, setting its\r\nexcluded , protected , and hidden flags accordingly.\r\nBehavior based on flags:\r\nExcluded\r\nThe rootkit will ignore the process and just let it run as expected.\r\nProtected\r\nThe rootkit will not allow any other process to get a privileged handle on it, similar to what happens in\r\nProcessPreCallback .\r\nHidden\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 7 of 24\n\nThe rootkit will hide the process by Direct Kernel Object Manipulation (DKOM). Directly manipulating a\r\nprocess's kernel structures at the very instant of its creation can be unstable. In the process creation callback, if\r\na process needs to be hidden, it is unlinked from the ActiveProcessLinks list. However, it sets a\r\npostponeHiding flag that will be explained below.\r\nThe Image Load callback (PsSetLoadImageNotifyRoutine)\r\nThis registers the LoadProcessImageNotifyCallback using PsSetLoadImageNotifyRoutine , which the kernel calls\r\nwhenever an executable image (a .exe or .dll ) is loaded into a process's memory.\r\nWhen the image is loaded, the callback checks the postponeHiding flag; if set, it calls UnlinkProcessFromCidTable to\r\nremove it from the master process ID table ( PspCidTable ).\r\nInitializeFSMiniFilter\r\nThe function defines its capabilities in the FilterRegistration structure(FLT_REGISTRATION) . This structure tells the\r\noperating system which functions to call for which types of file system operations. It registers callbacks for the following\r\nrequests:\r\nIRP_MJ_CREATE : Intercepts any attempt to open or create a file or directory.\r\nIRP_MJ_DIRECTORY_CONTROL : Intercepts any attempt to list the contents of a directory.\r\nFltCreatePreOperation(IRP_MJ_CREATE)\r\nThis is a pre-operation callback, when a process tries to create/open a file, this function is triggered. It will check the path\r\nagainst its list of files to be hidden. If a match is found, it will change the operation result of the IRP request to\r\nSTATUS_NO_SUCH_FILE , indicating to the requesting process that the file does not exist, except if the process is included in\r\nthe excluded list.\r\nFltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)\r\nThis is a post-operation callback; the implemented hook essentially intercepts the directory listening generated by the system\r\nand modifies it by removing any files listed as hidden.\r\nInitializeRegistryFilter\r\nAfter concealing its processes and files, the rootkit's next step is to erase entries from the Windows Registry. The\r\nInitializeRegistryFilter function accomplishes this by installing a registry filtering callback to intercept and modify\r\nregistry operations.\r\nIt registers a callback using the CmRegisterCallbackEx API, using the same principle as with files. If the registry key or\r\nvalue is in the hidden registry list, the callback function will return the status STATUS_NOT_FOUND .\r\nInitializeDevice\r\nThe InitializeDevice function does the driver initialization needed, and it sets up an IOCTL communication so that the\r\nuserland application can communicate with it directly\r\nThe following is a table describing each IOCTL command handled by the driver.\r\nIOCTL command Description\r\nHID_IOCTL_SET_DRIVER_STATE\r\nSoft enable/disable the rootkit functionalities by setting a global state flag\r\nthat acts as a master on/off switch.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 8 of 24\n\nIOCTL command Description\r\nHID_IOCTL_GET_DRIVER_STATE Retrieve the current state of the rootkit (enabled/disabled).\r\nHID_IOCTL_ADD_HIDDEN_OBJECT Adds a new rule to hide a specific file, directory, registry key, or value.\r\nHID_IOCTL_REMOVE_HIDDEN_OBJECT Removes a single hiding rule by its unique ID.\r\nHID_IOCTL_REMOVE_ALL_HIDDEN_OBJECTS\r\nRemove all hidden objects for a specific object type(registry keys/values,\r\nfiles, directories).\r\nHID_IOCTL_ADD_OBJECT\r\nAdds a new rule to automatically hide, protect, or exclude a process based\r\non its image path.\r\nHID_IOCTL_GET_OBJECT_STATE\r\nQueries the current state (hidden, protected, or excluded) of a specific\r\nrunning process by its PID.\r\nHID_IOCTL_SET_OBJECT_STATE\r\nThis command modifies the state (hidden, protected, or excluded) of a\r\nspecific running process, identified by its PID.\r\nHID_IOCTL_REMOVE_OBJECT Removes a single process rule (hide, protect, or exclude) by its unique ID.\r\nHID_IOCTL_REMOVE_ALL_OBJECTS This command clears all process states and image rules of a specific type.\r\nInitializeStealthMode\r\nAfter successfully setting up its configuration, process callbacks, and file system filters, the rootkit executes its final\r\ninitialization routine: InitializeStealthMode . If the configuration flag Kbj_YinshenMode is enabled, it will hide every\r\nartifact associated with the rootkit, including registry keys, the .sys file, and other related components, using the same\r\ntechniques described above.\r\nCode Variations\r\nWhile the malware is heavily based on the HIDDENDRIVER source code, our analysis identified several minor alterations.\r\nThe following section breaks down the notable code differences we observed.\r\nThe original code in the IsProcessExcluded function consistently excludes the system process (PID 4) from the rootkit's\r\noperations. However, the malicious rootkit has an exclusion list for additional process names, as illustrated in the provided\r\nscreenshot.\r\nDifference between “Hidden” and the rootkit function IsProcessExcluded\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 9 of 24\n\nThe original code's callback for filtering system information (including files, directories, and registries) used the\r\nIsDriverEnabled function to verify if the driver functionalities were enabled. However, the observed rootkit introduced an\r\nadditional, automatic whitelist check for processes with the image name hijack, which corresponds to the userland\r\napplication.\r\n“Hidden” source code: FltDirCtrlPostOperation callback\r\n“Hidden” source code: PsGetProcessImageFileName usage\r\nRMM usage\r\nThe GotoHTTP tool is a legitimate Remote Monitoring and Management (RMM) application, deployed by the threat actor\r\nto maintain easier access to the compromised IIS server. Its “Browser-to-Client” architecture allows the attacker to control\r\nthe server from any standard web browser over common web ports ( 80 / 443 ) by routing all traffic through GotoHTTP’s\r\nown platform, preventing direct network connection to the attacker’s own infrastructure.\r\ngotohttp[.]com landing page\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 10 of 24\n\nRMMs continue to increase in popularity for use at multiple points of the cyber kill chain and by various threat actors. Most\r\nanti-malware vendors do not consider them malicious in isolation and therefore do not block them outright. RMM C2 also\r\nonly flows to legitimate RMM provider websites, and therefore has the same dynamics for network-based protections and\r\nmonitoring.\r\nBlocking the mass of currently active RMMs and allowing only the enterprise's preferred RMM would be the optimal\r\nprotection mechanism. However, this paradigm is only available to enterprises with the right technical knowledge, defensive\r\ntooling, mature organizational policies, and coordination across departments.\r\nIIS module analysis\r\nThe threat actor was observed deploying both 32-bit and 64-bit versions of TOLLBOOTH, a malicious IIS module.\r\nTOLLBOOTH has been previously discussed by Ahnlab and the security researcher, @Azaka. Some of the malware’s key\r\ncapabilities include SEO cloaking, a management channel, and a publicly accessible webshell. We discovered both native\r\nand .NET managed versions being deployed in the wild.\r\nMalware Config Structure\r\nTOLLBOOTH retrieves its configuration dynamically from\r\nhxxps://c[.]cseo99[.]com/config/\u003cvictim_HTTP_host_value\u003e.json, and the creation of each victim’s JSON config file is\r\nhandled by the threat actor’s infrastructure. However, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json responded,\r\nshowing a lack of anti-analysis checks - allowing us to retrieve a copy of a config file for analysis. It can be viewed in this\r\nGitHub Gist, and we will reference how some of the fields are used as appropriate.\r\nFor native modules, the config and other temporary cache files are Gzip-compressed and stored locally at a hardcoded path\r\nC:\\\\Windows\\\\Temp\\\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\\\ . For the managed module, these are AES-encrypted\r\nwith key YourSecretKey123 and IV 0123456789ABCDEF , Gzip-compressed, and stored at\r\nC:\\\\Windows\\\\Temp\\\\AcpLogs\\\\ .\r\nWebshell\r\nTOLLBOOTH exposes a webshell at the /mywebdll path, requiring a password of hack123456! for file uploads and\r\nexecution of commands. Form submission sends a POST request to the /scjg endpoint.\r\nWebshell interface\r\nThe password is hardcoded in the binary, and this webshell feature is present in both v1.6.0 and v1.6.1 of the native\r\nversion of TOLLBOOTH.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 11 of 24\n\nThe file upload functionality contains a bug that stems from its sequential, order-dependent parsing of multipart/form-data fields. The standard HTML form is structured such that the file input field appears before the directory input fields.\r\nThe server processing the request parts attempts to handle the file data before the destination directory, creating a\r\ndependency conflict that causes standard uploads to fail. By manually reordering the multipart/form-data parts, a\r\nsuccessful file upload can still be triggered.\r\nFile upload PoC\r\nManagement Channel\r\nTOLLBOOTH exposes a few additional endpoints for C2 operators’ management/debug purposes. They are only accessible\r\nby setting the User Agent to one of the following (though it is configurable):\r\nHijackbot\r\ngooqlebot\r\nGooglebot/2.;\r\nGooglébot\r\nGooglêbot\r\nGooglebót;\r\nGooglebôt;\r\nGooglebõt;\r\nGooglèbot;\r\nGooglëbot;\r\nBinqbot\r\nbingbot/2.;\r\nBíngbot\r\nBìngbot\r\nBîngbot\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 12 of 24\n\nBïngbot\r\nBingbót;\r\nBingbôt;\r\nBingbõt;\r\nThe /health endpoint provides a quick way to assess the module’s health, returning the file name to access the config\r\nstored at c[.]cseo99[.]com , disk space information, the module's installation path, and the version of TOLLBOOTH.\r\nHealth endpoint response\r\nThe /debug endpoint provides more details, including a summary of the configuration, cache directory, HTTP request\r\ninformation, etc.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 13 of 24\n\n/debug content\r\nThe parsed configuration is accessible at /conf .\r\n/conf content\r\nThe /clean endpoint allows the operator to clear the current configuration by deleting the config files stored locally\r\n( clean?type=conf ) in order to update them on the victim server, clear any other temporary caches the malware uses\r\n( clean?type=conf ), or clear both - everything in the C:\\\\Windows\\\\Temp\\\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\\\\r\npath ( clean?type=all ).\r\nSEO Cloaking\r\nThe main goal of TOLLBOOTH is SEO cloaking, a process that involves presenting keyword-optimized content to search\r\nengine crawlers, while concealing it from casual user browsing, to achieve higher search rankings for the page. Once a\r\nhuman visitor clicks the link from the boosted search results, the malware redirects them to a malicious or fraudulent page.\r\nThis tactic is an effective way to increase traffic to malicious pages compared to alternatives like direct phishing, because\r\nusers trust search engine results they request more than unsolicited emails.\r\nTOLLBOOTH differentiates between bots and visitors by checking the User Agent and the Referer headers for values\r\ndefined in the config.\r\nBoth the native and the managed modules are implemented almost identically. The only difference is that native modules\r\nv1.6.0 and v1.6.1 check both the User Agent and Referer against the seoGroupRefererMatchRules list, and the .NET\r\nmodule v1.6.1 checks the User Agent against the seoGroupUaMatchRules list and Referer against the\r\nseoGroupRefererMatchRules list.\r\nBased on the current configuration, the values for seoGroupUaMatchRules and seoGroupRefererMatchRules are\r\ngooglebot and google , respectively. A GoogleBot crawler would have a User Agent match and not a Referer match,\r\nwhereas a human visitor would have a Referer match but not a User Agent match. Looking at the fallback list containing\r\nboth bing and yahoo suggests that those search engines were targeted in the past as well.\r\nFunctions and fallback lists for User Agent and Referer checks\r\nThe code snippet below is responsible for building a page filled with keyword-stuffed links that search engine crawlers will\r\nsee.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 14 of 24\n\nFunction for generating page that links to SEO content\r\nThe module constructs a link farm in two phases. First, to build internal link density, it retrieves a list of random keywords\r\nfrom resource URIs defined in the affLinkMainWordSeoResArr configuration field. For each keyword, it generates a \"local\r\nlink\" pointing to another SEO page on the same compromised website. Next, it builds the external network by retrieving\r\n\"affiliate link resources\" from the affLinkSeoResArr field. These resources are a list of URIs pointing to SEO pages on\r\nother external domains that are also infected with TOLLBOOTH. The URIs look like\r\nhxxps://f[.]fseo99[.]com/\u003cdate\u003e/\u003cmd5_file_hash\u003e\u003c.txt/.html\u003e in the configuration. The module then creates\r\nhyperlinks from the current site to these other victims. This technique, known as link farming, is designed to artificially\r\ninflate search engine rankings across the entire network of compromised sites.\r\nBelow is an example of what a crawler bot would see when visiting the landing page of a web server infected with\r\nTOLLBOOTH.\r\nVisiting the landing page with User Agent “google”\r\nURL path prefixes to the SEO pages contain words or phrases from the seoGroupUrlMatchRules config field. This is also\r\nreferenced in the site redirection logic targeting visitors. These are currently:\r\nstock\r\ninvest\r\nsummary\r\ndatamining\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 15 of 24\n\nmarket-outlook\r\nbullish-on\r\nnews-overview\r\nnews-volatility\r\nvideo/\r\napp/\r\nblank/\r\nExample local links\r\nTemplates and content for SEO pages are also externally retrieved from URIs that look like\r\nhxxps://f[.]fseo99[.]com/\u003cdate\u003e/\u003cmd5_file_hash\u003e\u003c.txt/.html\u003e in the config. Here is an example of what one of the\r\nSEO pages looks like:\r\nExample SEO page\r\nFor the user redirection logic, the module first gathers a fingerprint of the visitor, including their IP address, user agent,\r\nreferrer, and the SEO page’s target keyword. It then sends this information via a POST request to\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 16 of 24\n\nhxxps://api[.]aseo99[.]com/client/landpage . If the request is successful, the server responds with a JSON object\r\ncontaining a specific landpageUrl , which becomes the destination for the redirect.\r\nRequesting for page to redirect to\r\nIf the communication fails for any reason, TOLLBOOTH falls back to constructing a new URL pointing to the same C2\r\nendpoint but instead encodes the visitor’s information directly into the URL as GET parameters. Finally, the chosen URL -\r\neither from the successful C2 response or the fallback - is embedded into a JavaScript snippet ( window.location.href ) and\r\nsent to the victim’s browser, forcing an immediate redirection.\r\nFallback request for the page to redirect to\r\nPage Hijacker\r\nFor the native modules, if the URI path contains xlb , TOLLBOOTH responds with a custom loader page containing a\r\nscript tag. This script's src attribute points to a dynamically generated URL, mlxya[.]oss-accelerate[.]aliyuncs[.]com/\u003c12_random_alphanumeric_characters\u003e , which is used to retrieve an obfuscated next-stage\r\nJavaScript payload.\r\nRandom characters appended to domain hosting JS payload\r\nThe deobfuscated payload appears to be a page-replacement tool that executes based on specific trigger keywords (e.g.,\r\nxlbh , mxlb ) found in the URL. Once triggered, it contacts one of the attacker-controlled endpoints at asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= or ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key= , appending the current page’s URL as a Base64-encoded parameter to identify\r\nthe compromised site. The script then uses document.write() to completely wipe the current page’s DOM and replace it\r\nwith the server’s response. While the final payload could not be retrieved at the time of writing, this technique is designed to\r\ninject attacker-controlled content, most commonly a malicious HTML page or a JS redirect to another malicious site.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 17 of 24\n\nDeobfuscated page hijacker payload\r\nCampaign targeting\r\nWhile conducting the analysis of TOLLBOOTH and its associated webshell, we identified multiple mechanisms to identify\r\nadditional victims through active and semi-passive collection methods.\r\nWe then partnered with @SreekarMad at Validin to leverage his expertise and their scanning infrastructure in an effort to\r\ndevelop a more comprehensive list of victims.\r\nAt the time of publication, 571 IIS server victims were identified with active TOLLBOOTH infections.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 18 of 24\n\nGeographic distribution of victims serving TOLLBOOTH SEO cloaking\r\nThese servers are globally distributed (with one major exception, described below), and do not fit into any neat industry\r\nvertical buckets. For these reasons, along with the sheer scale of the operation, we are led to believe that victim selection is\r\nuntargeted and leverages automated scanning to identify IIS servers reusing publicly listed machine keys.\r\nThe collaboration with Validin and Texas A\u0026M System Cybersecurity yielded a robust amount of metadata about the\r\nadditional TOLLBOOTH-infected victims.\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 19 of 24\n\nMetadata collected from an additional victim\r\nAutomated exploitation may also be employed, but TAMUS Cybersecurity noted that the post-exploitation activity appeared\r\nto be interactive.\r\nValidin discovered other potentially infected domains linked through the SEO farming link configs, but when checked for\r\nthe webshell interface, found it inaccessible on some. After conducting a deeper manual investigation into these servers, we\r\ndetermined that they had been, in fact, TOLLBOOTH-infected, but either the owners remediated the issue or the attackers\r\nbacked themselves out.\r\nSubsequent scanning revealed that many of the same servers were reinfected. We have taken this to indicate that remediation\r\nwas incomplete. One plausible explanation is that merely removing the threat does not close the vulnerability left open by\r\nthe machine key reuse. So, victims who omit this final step are likely to be reinfected through the same mechanism. See the\r\n“Remediating REF3927” section below for additional details.\r\nGeography\r\nThe geographic distribution of victims notably excludes any servers within China’s borders. One server was identified in\r\nHong Kong, but it was hosting a .co.uk domain. This probable geofencing aligns with behavioral patterns from other\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 20 of 24\n\ncriminal threats, where they implement mechanisms to ensure they do not target systems in their home countries. This\r\nmitigates their risk of prosecution as the governments of these countries tend to turn a blind eye toward, if not outright\r\nendorse, criminal activity targeting foreigners.\r\nDiamond model\r\nElastic Security Labs utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities,\r\ninfrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions and\r\nleverages Activity Threading (section 8) to create relationships between incidents, an adversary-centered (section 7.1.4)\r\napproach allows for a single diamond.\r\nREF3927 Diamond Model\r\nRemediating REF3927\r\nRemediation of the infection itself can be completed through industry best practices, such as reverting to a clean state and\r\naddressing malware and persistence mechanisms. However, in the face of potential automated scanning and exploitation, the\r\nvulnerability of the reused machine key remains for whichever bad actor wants to take over the server.\r\nTherefore, remediation must include rotation of machine keys to a new, properly generated key.\r\nConclusion\r\nThe REF3927 campaign highlights how a simple configuration error, such as using a publicly exposed machine key, can\r\nlead to significant compromise. In this event, Texas A\u0026M University System Cybersecurity and the affected customer took\r\nswift action to remediate the server, but based on our research, there continue to be other victims targeted using the same\r\ntechniques.\r\nThe threat actor’s integration of open-source tooling, RMM software, and a malicious driver is an effective combination of\r\ntechniques that have proven successful in their operations. Administrators of publicly exposed IIS environments should audit\r\ntheir machine key configurations, ensure robust security logging, and leverage endpoint detection solutions such as Elastic\r\nDefend during potential incidents.\r\nDetection logic\r\nDetection rules\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 21 of 24\n\nWeb Shell Detection: Script Process Child of Common Web Processes\r\nPrevention rules\r\nSuspicious Execution via Windows Services\r\nPotential Shellcode Injection via a WebShell\r\nExecution from Suspicious Directory\r\nYARA signatures\r\nElastic Security has created the following YARA rules to prevent the malware observed in REF3927:\r\nWindows.Trojan.Tollbooth\r\nWindows.Trojan.HiddenCli\r\nWindows.Trojan.HiddenDriver\r\nREF3927 through MITRE ATT\u0026CK\r\nElastic uses the MITRE ATT\u0026CK framework to document common tactics, techniques, and procedures that threats use\r\nagainst enterprise networks.\r\nTactics\r\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an\r\naction.\r\nInitial Access\r\nExecution\r\nDefense Evasion\r\nCredential Access\r\nCollection\r\nExfiltration\r\nTechniques\r\nTechniques represent how an adversary achieves a tactical goal by performing an action.\r\nExploit Public-Facing Application\r\nServer Software Component: IIS Components\r\nOS Credential Dumping\r\nHide Artifacts: Hidden Files and Directories\r\nData from Local System\r\nRootkit\r\nValid Accounts\r\nObservations\r\nThe following observables were discussed in this research.\r\nObservable Type Name Reference\r\n913431f1d36ee843886bb052bfc89c0e5db903c673b5e6894c49aabc19f1e2fc\r\nSHA-256\r\nWingtbCLI.exe HIDDENCLI\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 22 of 24\n\nObservable Type Name Reference\r\nf9dd0b57a5c133ca0c4cab3cca1ac8debdc4a798b452167a1e5af78653af00c1\r\nSHA-256\r\nWinkbj.sys HIDDENDRIV\r\nc1ca053e3c346513bac332b5740848ed9c496895201abc734f2de131ec1b9fb2\r\nSHA-256\r\ncaches.dll TOLLBOOTH\r\nc348996e27fc14e3dce8a2a476d22e52c6b97bf24dd9ed165890caf88154edd2\r\nSHA-256\r\nscripts.dll TOLLBOOTH\r\n82b7f077021df9dc2cf1db802ed48e0dec8f6fa39a34e3f2ade2f0b63a1b5788\r\nSHA-256\r\nscripts.dll TOLLBOOTH\r\nbd2de6ca6c561cec1c1c525e7853f6f73bf6f2406198cd104ecb2ad00859f7d3\r\nSHA-256\r\ncaches.dll TOLLBOOTH\r\n915441b7d7ddb7d885ecfe75b11eed512079b49875fc288cd65b023ce1e05964\r\nSHA-256\r\nCustomIISModule.dll TOLLBOOTH\r\nc[.]cseo99[.]com\r\ndomain-nameTOLLBOOTH\r\nconfig server\r\nf[.]fseo99[.]com\r\ndomain-name\r\nTOLLBOOTH\r\nSEO farming\r\nconfig server\r\napi[.]aseo99[.]com\r\ndomain-name\r\nTOLLBOOTH\r\ncrawler reportin\r\n\u0026 page redirect\r\nAPI\r\nmlxya[.]oss-accelerate.aliyuncs[.]com\r\ndomain-name\r\nTOLLBOOTH\r\npage hijacker\r\npayload hosting\r\nserver\r\nasf-sikkeiyjga[.]cn-shenzhen[.]fcapp.run\r\ndomain-name\r\nTOLLBOOTH\r\npage hijacker\r\ncontent-fetchin\r\nserver\r\nask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run\r\ndomain-name\r\nTOLLBOOTH\r\npage hijacker\r\ncontent-fetchin\r\nserver\r\nbae5a7722814948fbba197e9b0f8ec5a6fe8328c7078c3adcca0022a533a84fe\r\nSHA-256\r\n1.aspx\r\nGodzilla-forked\r\nwebshell (Simi\r\nsample from\r\nVirusTotal)\r\n230b84398e873938bbcc7e4a1a358bde4345385d58eb45c1726cee22028026e9\r\nSHA-256\r\nGotoHTTP.exe GotoHTTP\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 23 of 24\n\nObservable Type Name Reference\r\nMozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13)\r\nGecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw)\r\nPresto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64;\r\nx64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0\r\nSafari/537.36\r\nUser-Agent\r\nUser-Agent\r\nobserved during\r\nexploitation via\r\nIIS ViewState\r\ninjection\r\nReferences\r\nThe following were referenced throughout the above research:\r\nhttps://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/\r\nhttps://asec.ahnlab.com/en/87804/\r\nhttps://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/\r\nhttps://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters\r\nhttps://github.com/ekkoo-z/Z-Godzilla_ekp\r\nhttps://x.com/AzakaSekai_/status/1969294757978652947\r\nAddendum\r\nHarfangLab posted their draft research on this threat the same day this post was released. In it, there are additional\r\ncomplementary insights:\r\nhttps://x.com/securechicken/status/1980715257791193420\r\nhttps://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/\r\nSource: https://www.elastic.co/security-labs/tollbooth\r\nhttps://www.elastic.co/security-labs/tollbooth\r\nPage 24 of 24",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.elastic.co/security-labs/tollbooth"
	],
	"report_names": [
		"tollbooth"
	],
	"threat_actors": [],
	"ts_created_at": 1775434505,
	"ts_updated_at": 1775826698,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6fd58aa4f179d8cc08ae23e60ba445ebc178d7f1.pdf",
		"text": "https://archive.orkl.eu/6fd58aa4f179d8cc08ae23e60ba445ebc178d7f1.txt",
		"img": "https://archive.orkl.eu/6fd58aa4f179d8cc08ae23e60ba445ebc178d7f1.jpg"
	}
}