AI-Driven Automated Penetration Attacks: Infrastructure Tracing and Defensive Practices

Note: This article is a technical abstraction and secondary analysis of publicly disclosed attack activity. To reduce the risk of secondary abuse, direct indicators pointing to the attacker, such as addresses, autonomous system numbers, and repository identifiers, are omitted. Role labels such as C2-A and Relay-B are used instead. Structural facts such as port counts, file counts, and timelines are retained to illustrate the tracing methodology.

1. Event Overview: A Console-Like Attack Platform

Publicly disclosed information paints a fairly complete picture: the attackers did not rely on one-off scripted payloads. Instead, they built a platform-like intrusion system with a login interface, an administrative console, and link-maintenance modules. A notable feature is its “AI-intensive” workflow: analysis, payload generation, and log summarization were delegated to large-model inference services. This moved attack efficiency from “manually writing exploits” to “describing targets in natural language and having the model generate candidate paths.”

This leads to a conclusion defenders must take seriously: the marginal cost of offense is being flattened by inference services. Multi-stage operations that once required advanced threat actor resources can now be replicated by a small team using models.

Four-Layer Attack Pipeline

Layer	Component	Role
Decision layer	Primary LLM inference interface	Vulnerability reasoning, payload generation, report summarization
Redundancy layer	2–3 backup model interfaces	Automatic fallback when the primary model is rate-limited or unavailable
Transit layer	Reseller or aggregator domains	Hide the real call origin and spread key-related risk
Landing layer	C2 server + relay host + reverse tunnel	Maintain sessions, return data, and evade tracing

The key point is that some model calls were not directly connected to official APIs; they passed through third-party reseller domains. The business model of such transit services is typically “bulk purchase of quota and secondary distribution,” with little review of downstream use. For attackers, the value is not only cost reduction but also limiting the impact of key leakage—if one transit key is burned, the primary channel remains unaffected.

2. C2 Server Profile: Turning “Penetration” into SaaS

Independent scanning of the C2 host revealed a set of highly telling exposures:

• A total of 15 ports were open, giving a much larger exposure surface than a normal business host.
• Ports 443 and 8090 both provided login pages, with the page title written in Chinese: “Autonomous Penetration Testing Console.” The attackers did not hide their intent; this reflects a “tool-as-product” mindset.
• The same host also ran a model-to-API gateway management console and a forward proxy service in parallel.

The fact that these three components coexist on one host reveals two things. First, model calls and compromised-endpoint traffic share the same egress, which simplifies unified billing and unified auditing—even attackers need an operational view. Second, the proxy service itself is a major forensic entry point: proxy access logs often contain target addresses, timestamps, and source information. If the host is seized or its configuration is exposed, the attacker effectively hands over an operational ledger.

Why Exposing the Management Interface on Public Port 8090 Is a Bad Idea

Using a nonstandard high port to “hide” a service is ineffective security. Asset-mapping platforms have high identification accuracy for ports such as 8090, 9000, and 7001. Attackers and researchers see the same picture. Security boundaries must rely on authentication and network policies, not on unusual port numbers.

3. Related Tracing: From a Single Host to the Relay Chain

Information from a single host is limited; the real breakthrough came from horizontal correlation. After searching shared mapping data, researchers found that an Asia-Pacific relay host (Relay-B) in an autonomous system had an open directory index.

The directory structure was highly indicative:

• It contained 2 subdirectories and 42 files, totaling about 105 MB.
• The same directory was recorded by mapping platforms on September 5, September 26, and October 5—three independent observations spanning about one month. This suggests it was not a temporary upload artifact but a long-term operational area.

An open directory is itself a basic misconfiguration, but its contents are even more informative. A configuration file explicitly labeled the C2 host as a “relay host” and included a comment reminding the operator not to paste credentials into chat sessions. That file was sitting in an unauthenticated public directory—writing security advice in the least secure place is a typical trait of this kind of attack infrastructure.

Three Link-Maintenance Scripts

The three scripts in the directory were used to: keep a reverse SSH tunnel alive, run a local relay, and copy files to the relay host. One tunnel was named after a model-to-API service, directly confirming that “the tunnel carries model-call traffic.”

The intent of this design is clear: separate the model-call egress from the compromised-endpoint ingress across two hosts in different jurisdictions. Even if one side is taken down, the other can continue operating. The separation of the three scripts also means single-point failures can self-heal—if the reverse tunnel drops, the keep-alive script reconnects; if data is lost, the synchronization script restores it.

Compromised target --(reverse SSH/encrypted tunnel)--> Relay-B (relay, forwarding, sync)
                                                     |
                                                     +--(encrypted tunnel)--> C2-A (C2, login surface, proxy, model gateway)
                                                                           |
                                                                           +--> Model inference APIs (primary / backup / transit)

4. Enterprise Detection: Focus on the Invariant “Tunnel”

Models, domains, and ports change, but the physical shape of the link remains stable: long-lived connections, fixed heartbeats, low-volume traffic, and highly concentrated destinations. Detection should be built around these properties rather than chasing indicators of compromise like whack-a-mole.

4.1 Long-Lived Connections and Heartbeat Features

# Example: Find SSH sessions that have been alive for more than 6 hours
# with no data transfer but still connected
ss -tnpo state established '( sport = :22 or dport = :22 )' \
  | awk 'NR>1 {print $4, $5, $6}'
# Example: Count session re-establishment attempts to a single overseas
# destination IP every 5 minutes. Fixed-period re-establishment
# (for example, 60s ± 2s) is a strong indicator of a keep-alive script.

Judgment logic: normal operational sessions are “heavy operation, short-lived”; tunnel-like connections are “long-lived, low-throughput, and periodically fixed.” A fixed period is itself a signal—human operations rarely follow second-level precision.

4.2 Destination Concentration of Egress Traffic

Once a compromised endpoint lands, its requests to external models inevitably converge on a few API endpoints. Frequency statistics on egress DNS and TLS SNI can identify anomalous hosts where “a single domain accounts for more than 60% of the host’s total outbound requests.” Such indicators rarely appear on business servers.

4.3 A Sigma-Style Rule

title: Suspicious coexistence of reverse tunnel and proxy components
status: experimental
logsource:
  category: process_creation
detection:
  tunnel_tools:
    Process|endswith: ['\ssh.exe', '\ssh', '\plink.exe', '\autossh']
  tunnel_args:
    CommandLine|contains: [' -R ', '-N -T', '-D 1080']
  proxy_components:
    Process|endswith: ['\tinyproxy', '\squid', '\gost', '\frpc']
  condition: tunnel_tools and tunnel_args and proxy_components
falsepositives:
  - Bastion host outbound scenarios (need to be narrowed down by account whitelist)
level: high

4.4 Detecting “Metadata Leakage” in Configuration Files

Open-directory problems often accompany enabled directory listings on web services. Two engineering practices are recommended:

1. Asset-side inspection: Regularly check whether your own web services allow anonymous access to directory listings, backup files (.bak, .zip, .tar.gz), and editor temporary files.
2. Source-code/config-side scanning: During CI, match submitted content against secret patterns and block immediately on a hit—leaked keys do not recall themselves.

5. Credential Governance: Turn “Do Not Paste Credentials” into a Mechanism

That ironic reminder file points to a real and frequent failure point: developers and operators paste API keys, tokens, and internal passwords directly into conversational AI tools or chat sessions. This creates three risks: session content may be retained by the service provider; keys may enter logs and indexes; and keys may lose rotatability.

Actionable mechanisms:

• Keep keys out of chat: Wrap model calls in a unified client SDK. Inject credentials from environment variables or a secret-management service so the application layer never sees plaintext.
• Prefer short-lived credentials: Replace long-lived AK/SK with temporary credentials such as STS, reducing the leakage window to hours.
• Quota and anomaly detection on the calling side: Assign separate quotas and rate limits to each application type. If model calls suddenly spike 20 times, trigger an alert—normal business rarely has such a slope.
• Understand the risk of transit channels: When using third-party aggregator or reseller APIs, assume they have full plaintext visibility and retention capability. Never transmit business-sensitive data through them, and always enforce egress network policies with an allowlist of accessible domains.

6. Ecosystem Governance: Public Code and Images Do Not Disappear When Deleted

Disclosure information shows that the tool’s related code-hosting repository and container images were removed on October 11, but forked repositories and image mirrors still exist. This is a structural reality of the open-source ecosystem:

• Forks are irreversible: Anyone can create a fork in seconds; deleting the upstream cannot recall downstream copies.
• Image layers can be rebuilt: Due to distribution characteristics of image registries, any pulled layer may appear in third-party caches.
• Docs and screenshots remain: Domains and configuration snippets in READMEs, demo recordings, and community discussions are often the most overlooked IOC-rich sources.

For defenders, this suggests a practical path: treat the public ecosystem as a continuous intelligence source. Regularly search code-hosting platforms, public image-registry listings, and technical-community discussions. This can reveal new infrastructure earlier than waiting for vendor disclosure.

For content platforms and image providers, clearer judgment and handling workflows are needed to balance distribution convenience against abuse prevention, including malicious-tool feature identification, batch handling of same-family forks, and continued monitoring of derivative versions after takedown.

7. Cloud Defense: Fill Control Points with General Capability Categories

Against highly automated, multi-relay, AI-driven attacks, enterprises do not need to buy a specific product. Instead, they can combine several general capability categories into a closed loop:

• Log services: Centrally collect intrusion-detection logs, web access logs, egress traffic logs, and audit logs, and retain them long enough for tracing.
• Monitoring and alerting: Build baseline alerts for “long-lived one-way overseas connections,” “directory-traversal scanning,” and “sudden outbound traffic spikes on a single host,” rather than relying only on fixed thresholds.
• Secret management and access control: Centrally host credentials, issue them on demand, rotate them automatically, and enforce least privilege.
• Container platforms and security baselines: Enforce image signature verification, prohibit privileged containers, limit unnecessary egress, and block the path where an image is replaced with a backdoored version.
• Object storage: Provide immutable (WORM) storage for forensic images, packet captures, and log archives to preserve evidence-chain integrity.

For example, Baidu AI Cloud maps these capabilities to general product categories such as log services, cloud monitoring, key management, container services, and object storage. Specific configurations and specifications should follow the official documentation. This article does not assume any specific API parameters.

8. Disclosure and Collaboration: What Makes a Report Adequate

The disclosure process has two points worth learning from:

1. Notify before publishing: First notify national-level emergency-response coordination bodies in relevant countries, provide a remediation window, and then disclose technical details.
2. Data minimization: Do not include personal records or plaintext credentials in public reports.

When writing such reports, it is recommended to include: a timeline (first observation—duration—handling date), an infrastructure structure diagram, verifiable technical features (not just IOCs), and layered remediation advice (emergency response / short-term hardening / long-term construction). A report with only IOCs has a half-life of a few days; a report that provides detection ideas can become defensive capability.

9. Checklist for Defenders

• Do you know all externally exposed management interfaces on your own assets, including those on nonstandard ports?
• Are there unauthenticated directory indexes, backup files, or configuration archives?
• Does egress have domain allowlists and destination-concentration alerts?
• Can you detect “long-lived + periodic heartbeat” encrypted tunnels?
• Have API keys been moved into centralized hosting and automatic rotation?
• Are credentials prohibited from being pasted into any conversational tool, with technical safeguards in place?
• Are container images subject to mandatory origin verification and egress restrictions?
• Have you established a routine intelligence practice of continuously searching public ecosystems?

Conclusion

The real signal from this activity is not that “AI was used in attacks”—that is no longer news—but the engineering maturity of the attack campaign: a console, multi-model redundancy, transit billing, self-healing links, and cross-jurisdiction relays. It demonstrates, through a complete operational methodology, how attackers treat AI as infrastructure.

The defenders’ equivalent response must also be engineering-driven: build detection around link shape rather than labels; turn credential governance from verbal reminders into mechanism-based constraints; and turn intelligence collection from passive waiting into active searching. When even the attacker’s “reminder file” warns against leaking credentials, defenders have no excuse to rely on employee self-discipline alone.