TIKTOUK: Tracing a WordPress Credential Collection Toolkit

TIKTOUK brings together WordPress probing, collection of exposed configuration data, recovery of encrypted email credentials, and JavaScript secret scanning. Its two Python components and Go-based Linux crawler turn website responses into structured results for a central hub: an HTTP service that distributes target tasks and receives collected data and status reports.

The key security issue is the combination of exposed configuration material and encrypted plugin settings: the collection component used the corresponding keys to recover plaintext email credentials.

The analysis combines source review, reverse engineering, and controlled executions to reconstruct the behavior demonstrated by the three components.

Three Components, a Shared Reporting Model

Each component retrieved its own tasks from the hub, which centralized target distribution and collection of the results.

From WordPress Probes to Data Collection

The probing sequence begins with wp2s_poll.py retrieving a target list and fetching pages to identify WordPress sites. It then sent REST batch requests containing the malformed path http://: together with a DELETE operation against /wp/v2/categories/0 and a POST operation against /wp/v2/block-renderer/core/paragraph. This combination probes REST route handling and gives defenders a specific request pattern to investigate.

After JSON requests received HTTP 403 responses, the component retried using multipart encoding and received HTTP 200. The retry matters for detection because the same probing sequence used more than one request format. It also collected secret-pattern matches from page content alongside its target classifications, turning the page inspection into a search for exposed credentials.

Reading Configuration and Option Values

In a separate task stream, wp2s_crack.py retrieved wp-config.php.bak and parsed database credentials and WordPress key material from the returned configuration. It then sent nested REST batch requests carrying author_exclude and UNION ALL SELECT expressions to request database option values. A query for the options table name came first; subsequent queries used the name returned in the response to address that table.

The response parser decoded hexadecimal values enclosed by ||| markers into text, making the returned plugin settings and keys available for credential processing.

The component also requested .env, .git/config, backup.sql, and wp-content/debug.log, checking for application data exposed through configuration, repository, backup, and log files. Its result messages contained database configuration, SMTP records, AWS credential pairs, and API key patterns extracted from the responses. A separate task in aws mode returned an AWS credential record, demonstrating collection focused on cloud credentials.

Returning the Collected Data

The collection component sent per-target records to /api/crack/report, while the probing component used /v1/ingest. These submissions transferred the collected values, including recovered plaintext credentials, to the hub rather than leaving them only in local processing.

Recovering Credentials from Encrypted Settings

Reverse engineering of wp2s_crack.py identified separate decoding routines for WP Mail SMTP, Easy WP SMTP, and FluentSMTP settings. Function checks recovered the expected plaintext for all three formats, and network reports contained the matching values.

These routines used the corresponding keys or WordPress configuration material to decrypt the settings; the result was credential recovery with available keys, not a break of the encryption algorithms.

The same checks demonstrated pure Python decryption with the optional cryptographic library paths disabled, showing that those dependencies were not required for these tested operations. The component also derived an SES SMTP password from the supplied AWS secret, matching an independent calculation and converting that secret into the service’s SMTP credential format.

Collecting Secrets from JavaScript

The third component, jscrawl-amd64, is a stripped Go executable for Linux. It fetched pages and referenced scripts, scanned their contents, and submitted findings to /v1/ingest, collecting secret-like values from client-delivered code. Recovered Go function metadata links script processing to the secret scanner and supports the observed collection path.

The returned findings included SendGrid, Anthropic, and Bedrock token patterns, together with AWS-shaped credential pairs.

WordPress Vulnerability Context

Two WordPress advisories provide context for the request structures in this analysis.

• CVE-2026-60137 describes insufficient sanitization of the author__not_in parameter in WP_Query, enabling SQL injection when untrusted input reaches that parameter.

• CVE-2026-63030 describes REST batch-route confusion that can be combined with the SQL injection to achieve remote code execution (RCE).

The batch-route advisory identifies affected WordPress 6.9.x releases before 6.9.5 and 7.0.x releases before 7.0.2. Successful exploitation of either CVE was not demonstrated: the target simulator returned prepared responses without executing SQL.

WordPress security advisories: CVE-2026-60137; CVE-2026-63030

Detection and Response

Use the following investigation leads together; individual paths or parameter names alone do not establish malicious activity.

• Review REST batch requests containing http://: together with nested author_exclude or UNION expressions, especially when JSON requests are followed by multipart requests.
• Correlate requests for exposed configuration, backup, and environment files with subsequent result submissions from the same process or host.
• Use the sample hashes below for file identification; investigate matching executions alongside their HTTP activity.
• Treat /v1/ingest and /api/crack/report as contextual features of the observed workflow, and evaluate them with the payload and sample identity.

Limitations

The executions used synthetic target data and independently supplied tasks through an analyst-controlled hub. They establish component behavior, not a live-site breach, valid stolen credentials, or an automatic handoff between components.

Confirm an incident by correlating the request patterns and data submissions with the affected system’s own records.

Incident Observations

Ben Lee, a Security Analyst at LevelBlue, provided additional indicators observed during a real-world attack. According to the incident telemetry, the victim host retrieved the payloads from 31.56[.]58.59 and continued communicating with the same host, which operated as the controller. The tasking requests, target domains, and subsequent communication were observed through this controller infrastructure.

Additionally, LevelBlue Analyst Leon Cottrell examined a leaked TIKTOUK panel that showed ~50k real server-side credentials across ~37k domains, including hundreds of actor-validated live AWS keys with SES/EC2/Bedrock abuse potential; the operation was already active at scale when first observed.

Currently monitoring and have found additional TIKTOUK panels at 193.32.162[.]134 and 195.178.110[.]209. Investigation also identified a related Golang-compiled botnet binary with remote command execution capability.

Indicators of Compromise

The following hashes identify the analyzed samples and their supplied archive.

wp2s_poll.py: WordPress probing component

• SHA-256: c6b8d0cdb53da98a5d15e79b7bb9e9f4c272c4f9592acdc291089f126f892f45

wp2s_crack.py: Credential-collection component

• SHA-256: 0d8ea89a63070f68286249aa437aece0e040c1609b8c5c0950ebbc90e6f70f02

jscrawl-amd64: JavaScript secret scanner

• SHA-256: 1e22fde68d3277ed0fe7a8a7b554f0ae118260a2fa143f8e1bdc84c994ebbe90

Golang-compiled botnet binary with remote command execution capability

• SHA1: 9903f4576980ff7cfd560ca57c665a4b59b3c30d

The following IP Addresses were also found associated with this campaign.

TIKTOUK C2 panels

• 193.32.162[.]134

• 195.178.110[.]209

Payload Host

• 31.56.58[.]59