Overview

A new Linux toolkit, identified by Rapid7 Labs, has been targeting organizations across South Korea’s automotive and media industries with minimal detection. The campaign made use of a HAProxy instance named “ted backdoor”, alongside trojanized versions of crond, agetty, atd, sshd, and polkitd. This previously undocumented framework enabled threat actors to execute remote commands on compromised servers, inject malicious scripts into web traffic, perform credential harvesting, and engage in long-term surveillance.

The standout feature of this toolkit is its depth of integration with the target environment. The ted backdoor is compiled as part of the victim’s existing HAProxy version 2.8.12. It uses its native filter API, internal memory pools, event scheduler, and process management infrastructure to intercept traffic and hide from monitoring, while genuine load balancing traffic operates as expected.

Operating alongside this are an SSH keylogger, a curl-based RAT, and a stager. The RAT maintains a watchdog thread dedicated to tracking HAProxy’s health, and reporting it back to the operator’s infrastructure. The earliest uploads on VirusTotal date back to mid-2025 and the involved HAProxy 2.8.12-0fdb194 was released on 22 November 2024, establishing this as the earliest possible compilation date for this build.

The toolkit is attributed with medium confidence to DPRK APTs, given that the attacks Rapid7 observed were targeting South Korean media and automotive sectors, likely aiming at long-term espionage, the usage of simple xor-based encryption, custom substitution cipher, and the list of C2s hardcoded is associated to APT37 by ThreatFox and maltrail. Analysis shows that the ted backdoor could be part of a broader framework covering nginx backdoor as well. The ted plugin registers a custom HAProxy filter that hooks the HTTP parser to inspect and log high-value traffic, steal session cookies, and perform a client IP selection to decide whether to inject custom scripts in the webpage being rendered.

Technical analysis

Rapid7 researchers revealed that the toolkit was used in campaigns targeting South Korean automotive and media sectors likely dating back to early 2025. The number of trojanized binaries and functionalities found suggest the scope could be long-term cyber espionage and surveillance. However, gathered evidence does not suffice to establish a timeline nor how the initial access was performed.

At the time of analysis, both victims were running an edge webserver with ports 80, 443, and 25 exposed. Port 443 hosted the Groupware login portal and port 25 exposed a mail server. Either surface represents a plausible initial access vector consistent with documented Kimsuky tradecraft. Since the beginning of 2026 Kimsuky has been observed exploiting RCE vulnerabilities in externally accessible mail servers to compromise South Korean groupware vendors, while Groupware web portals represent the kind of exposed authenticated application that DPRK-nexus actors have repeatedly targeted for credential harvesting and exploitation. The specific entry point and any associated CVE remain unconfirmed pending further forensic evidence.

The scenario shown in Figure 1 assumes the initial access is obtained by exploitation of CVEs related to the Groupware portal.

⠀

The threat actor begins by exploiting a vulnerability in the Groupware login portal running on the edge webserver, gaining an initial foothold in the DMZ. From there, they establish persistence and harvest credentials from the compromised edge host (e.g. SSH keylogger), which also doubles as a staging server hosting the trojanized system ELFs.

With a foothold on the edge, the attacker pivots inward and drops the stager onto internal servers. The stager checks for the presence of either crond or HAProxy, and only then deploys CurlRAT retrieving it either from its data section or the edge webserver. 

In parallel, ted backdoor is dropped onto the HAProxy load balancer. Once active,it establishes its own C2 channel to the external operator infrastructure, enabling data exfiltration, command execution, and script injection. On the victim side, the compromised load balancer silently redirects or serves malicious content to selected clients browsing through it, completing the watering-hole loop.

SSH keylogger

4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5 intercepts legitimate users' plaintext passwords and saves them to an encrypted log file under /var/lib/sshd/c8c68e629bba773a10ac80012d10bf19.

⠀

After checking that entered credentials are not equal to TA’s master passwords, userauth_passwd() proceeds to encrypt them using a custom substitution cipher recurring throughout the toolkit and base64 encoding.

⠀

Pivoting from the above cipher, instances of polkitd, crond, agetty and atd binaries were identified using a similar encryption algorithm. Crond binaries were found to be delivered by a stager.

CurlRAT Stager

The stager 5db1b6d52faf60b4f32d6fd0c7c938e4d05d29a14c32ded4a9668357c08b6a91 starts by decrypting its configuration strings using a 1-byte XOR, then verifies root privileges and profiles the OS checking system hostname, OS distribution and version IDs, kernel release and version numbers and CPU architecture to select the correct payload to drop. It decrypts the trojanized crond binary in memory, overwrites the system's legitimate daemon, and restarts the service. As shown below, only if HAProxy or cron are running on the system will it proceed to drop the backdoored crond.

⠀

Checking for HAProxy presence is done as the binary, named by TA as ted backdoor. It also has RAT capabilities and plays a major role in the campaigns described. The embedded crond versions supported are CentOS 7.7, 7.8, 7.9 and Ubuntu 22.04 and after installing the backdoor, timestomping ensures the crond binary gets the same creation timestamp of /usr/bin/ssh. The stager ends by filtering out keywords such as tmp, wget cron and crond from Linux system logs using a staging file named /tmp/jasper-log, likely to blend in as the JSP (JavaServer Pages) engine in old Apache Tomcat versions, erasing any traces of the installation. The logs affected by the selective erasure are /root/.bash_history and the following under /var/log: messages, audit/audit.log, cmd.log, secure, syslog, auth.log.

09739441ed4599bac2f8159028f772f71e4b25c8badfff95574e56d7384f3dbe and fea1bc36632c71e5a839803469ef60ac47595d36b2c50934ac109ade6df06e61 are a different variant of the stager that fetches backdoored binaries from a compromised victim’s server without embedding any payloads.

CurlRAT

The Ubuntu version is analyzed below, though CentOS samples follow the same logic except for the filepath used to hide config/staging files.

As for the stager, feeea9d0bf6ae7396d28271baa51ae50df5169ce5d32a516865856f91abc50b3 starts by decrypting configuration strings using a 1-byte XOR key (0x58).

⠀

The main logic added to crond is executed via two threads. The first thread runs the start_routine function that creates the staging directory snapd under /var/lib, where it attempts to load the victim ID from /var/lib/snapd/g580. If network failures were previously recorded, it reaches out to a secondary domain – img.darklights.store – authenticating with api_token/ecd427ea8330a4ff73618483e00b9b41 and setting the User-token header to the victim ID to fetch updated configuration under /tmp/nimon.unix-docbase.8564479396043450766-db6fb4443bc, where it’s then copied into /var/lib/snapd/g105.

To decrypt the configuration, the first byte of the file initializes the seed of a feedback xor based cipher. Each poll cycle, a config file is fetched from the C2 server over HTTPS (falling back to HTTP on failure) using libcurl, with the victim token embedded in the User-token header. The fetched config is parsed for three single-character delimiters — ! terminates the credential field, # marks the payload section, and * separates arguments — after which the credential field is compared against the local victim token.

If authentication succeeds, a single-character mode byte (ASCII '0' through '5') preceding the delimiter “#” selects one of six handler routines via a jump table. Payloads embedded in the config are decoded through a two-stage pipeline: standard Base64 decoding followed by a rolling cumulative XOR cipher keyed from the decoded header. The C2 task handler sleeps for 43,200 seconds (12 hours) between polls by default, but the operator can activate a fast-poll mode by setting a flag, reducing the interval to 30 seconds. A retry loop calls the handler up to six times per cycle with five-second intervals, failing fast if the first attempt does not succeed. The table below shows the C2 commands accepted.

Modes 0–2 and 4 use libcurl-based HTTP/HTTPS, hence the name curlRAT. All modes use Base64+XOR encoding/decoding applied to the payload. The victim ID is obtained by concatenating "cron_3.0pl1-137ubuntu3", system hostname, ipv4 address, and the hardware/OS UUID (read from /sys/class/dmi/id/product_uuid), then applying MD5 hash and converting it to uppercase.

The layer of encryption used for all C2 interactions consists of a feedback xor cipher using an initial random seed (modulo 240 + 10, 0<=seed<=249) and then applying Base64 encoding. The malware encapsulates the encrypted and encoded payload, the service name, and the telemetry type into a formatted application/x-www-form-urlencoded HTTP POST body (name=%s&value=%s&type=%d) which is sent to the C2 and authenticated using an hardcoded API token, including the victim ID in the User-token header.

The second thread acts as the HAProxy watchdog. Before entering the monitoring loop, it checks for the presence of the file /usr/lib/libvirtlog.so.0 to ensure the target is running in a virtualized environment, otherwise it sleeps 6 minutes and aborts. Then it accesses the MD5 victim ID under /var/lib/snapd/g580 to check if the node is active and compromised. Every hour the watchdog reads the pid at /var/run/haproxy.pid and monitors the status of HAProxy by polling /proc/pid. The status can be one of the following codes:

• 0 (Started): Process transitioned from stopped to running
• 1 (Stopped): Process is no longer active in the kernel process table
• 2 (Restarted): PID file timestamp modified, and a new PID is detected
• 3 (Reloaded): PID file timestamp modified, but the PID remained identical

The status is then sent to the C2 endpoint “writeservice_info” using the custom crypto layer and the telemetry type set to 0 (Figure 6).

⠀

The CentOS versions of curlRAT contain the same functionalities, except that functions are masqueraded as atd_ routines to blend in during static analysis.

⠀

Below is the table summarizing the main RAT components.

Earlier version of the RAT hardcode C2 without using XOR encryption (Figure 8).

⠀

The atd_get_info() is a recon routine likely used to decide which binary trojanized next to ensure persistence on the node. It collects the service name of the compromised machine and sends it to the C2 via the atd_response routine together with Ipv4 address, OS version, and the list of services and listening port (Figure 9).

⠀

MODE, DELAY and SERVER_URL are parsed from the config file discussed previously. During the campaign observed by Rapid7, the RAT acts as a framework and constitutes the codebase to edit legitimate system daemons. Other trojanized instances found are agetty and polkitd, where we identified a similar pattern lacking the HAProxy monitor: the creation of a thread to run curlRAT, reaching to img.worksongo.store and img.socialteams.store respectively.

atd_encrypt_url and atd_decrypt_url leverages the substitution cipher “E1x0X3f2R5w4g7u6D968kAeCdBPEpDhGJF4IiHHKzJvMtLlOnNcQmPNSjR2UFTUWOVTYIXZZ5aWcQbbeqd7gYf3i8hykGjCmsl9oonrqSp0sVrauKtLwAvBy1xMz=.#,+/--__" shared with the ssh keylogger.

Ted backdoor

The TA recompiled the HAProxy build 2.8.12 72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558 (18MB) to include a custom plugin (named ted_plugin) leaving debug strings naming the backdoor.

⠀

Figure 10 shows that the plugin was directly compiled with the rest of HAProxy source code and hooks directly the built-in HTTP parser relying on internal HAProxy structure for searching HTTP request headers. The custom filter defined to capture traffic is loaded via the ted_load_filter_config routine. 

⠀

The routine reads the implant's operational configuration from ~/cache/haproxy-1000.cache. Each field is decrypted in two layers: first ngx_decode applies a chained XOR seeded by the file's first byte; then ngx_decrypt_script applies a monoalphabetic substitution whose 67-entry mapping table is built at startup in ted_init_util from “E1x0X3f2R5w4g7u6D968kAeCdBPEpDhGJF4IiHHKzJvMtLlOnNcQmPNSjR2UFTUWOVTYIXZZ5aWcQbbeqd7gYf3i8hykGjCmsl9oonrqSp0sVrauKtLwAvBy1xMz=.#,+/--__" , and held in the ted_dec_dict uthash table keyed by Jenkins hash for O(1) lookup. The config carries the operating mode, all targeting regexes, every script rule with its payload paths and filenames, and the allowed operator keys. IP-based access control lists are loaded from haproxy-1001.cache and haproxy-1002.cache via the same decryption scheme. In other ted backdoor samples, the my_filter_config struct includes regexes to capture cookies as well.

After loading its configuration, it sets up signal handling via ted_register_reload_signal_handler() and saves its C2 pipe under HAPROXY_MWORKER_PP_READ and HAPROXY_MWORKER_PP_WRITE environmental variables to survive reloads and restarts, saving child process activity via ted_extra_log().

Below is the list of functions defined by the ted_plugin:

The HAProxy trace_ops struct is copied into my_filter_ops, and contains a hooked tracing method.

⠀

trace_chn_start_analyze() is hooked via ted_chn_analyze_for_htx_constprop_0() that parses the HTX buffer — the memory region where HAProxy stores parsed, SSL-decrypted HTTP request. If an incoming request matches the endpoint "/favorite_list_2x_m500_ico.jpg" (Figure 13), the malware drops into a Command & Control mode, setting the field flag to 1 in the ted_rep_state structure that tracks the response state. 

⠀

⠀

First, it reaches into HAProxy's internal counters to decrement active connection stats, referencing fields from the proxy struct via hardcoded 2.8.12 offsets to clear any trace left: the per-backend beconn/feconn and the global actconn, then 64-bit fields within be_counters (cum_conn, cum_req, bytes_in, bytes_out) guarded against underflow, and 32-bit peak metrics (sps_max, conn_max, cps_max) decremented only when exactly 1. Secondly, it parses a custom hardcoded 14-byte header to obtain the payload length, then creates FIFO pipes via ted_make_pipe_name and ted_create_multi_pipe_file keyed on HAProxy's connection ID under /tmp (e.g. /tmp/t[ID]_w.pipe). If HAProxy is running in master-worker mode (MODE_MWORKER, bit 0x80), the connection ID is written to the pp_w2m pipe so the master process runs the dispatcher; otherwise a detached thread runs ted_pipe_worker_thread locally (Figure 13).

The HTX walk filters on block type 4, which is HTX_BLK_DATA, and writes each block straight into fdPipe with write(). Any short write aborts and closes the pipe. Afterwards to_forward, output, buf.head and buf.data on the request channel are all zeroed. That tells HAProxy there is nothing left to forward, so the attacker's command body never reaches a backend server. The C2 request terminates at the load balancer, and no backend ever logs it.

The C2 dispatcher logic is resumed in the table below.

All five handlers write the same “HTTP/1.0 200 OK” header with Content-Type: text/html into the read pipe before the body. That's what the response task then relays out via send() on the raw socket, which is why the traffic looks like an ordinary HTTP response on the wire despite never passing through HAProxy's response path. Output back to the operator uses a rolling XOR cipher where each plaintext block is the key used to encrypt the next block with a random 1-byte seed.

If the initial endpoint check does not match "/favorite_list_2x_m500_ico.jpg" and the filter is in capture mode, then traffic is selectively logged and victims are identified based on the capturelist_set field within the my_filter_config struct (Figure 11), containing the list of targeted IPs and subnets. It uses regular expressions to filter the incoming HTTP traffic, waiting for high-value requests (like a user hitting a /login endpoint or an admin panel).

When a victim's request matches the attacker's filters, the backdoor goes to work.

It extracts the victim's source IP, the requested Host, the Referer, and the User-Agent formatting the data in a single-line record using exclamation marks as separators.

⠀

The execution flow continues based on conf->action; zero means passive logging only, non-zero starts the injection path. A request then has to clear four conditions. It needs a User-Agent, and if agent_pattern is configured that regex has to match. Second, the code scans the User-Agent for the bytes x,6,4, it selects between the two payload paths the matched rule retrieving them ted_script_config struct (path_32 at offset 0x18 and path_64 at 0x20). Third, the script rule list is walked until one ted_script_config entry's URL and referer regexes both match, with a null referer counting as an automatic pass. Thus the operator catches a victim arriving at a specific page from a specific referrer, rather than spraying at everyone hitting a URL.

⠀

⠀

Fourth, the implant parses Accept-Language splitting on ; and =, pulling four operator-controlled fields: mrt for the 64-byte uid credential, msc for an 8-byte status, mst for an 8-byte score, and a fourth keyword read from off_355407 for a 1024-byte info blob. Parsing is order-independent and any subset can appear. If mrt yields a key, it must exist in allow_id_set, and that credential overrides IP filtering entirely, letting the operator reach the requested page from anywhere. It also upgrades the log record to the *-prefixed format carrying uid, status, score, and info. With no key, the fallback is IP-based: action == 1 requires whitelist membership, action == 2 requires blacklist absence, both checked twice, once with the final octet zeroed for /24 subnet matching and once for the exact host. 

Once all checks are cleared the chosen file is opened, stored in the per-connection ted_rep_state as fpAppend and nTotal, alongside a script_conf back-reference to the matched rule. The replace byte at offset 0x00 of that rule sets flag to 4 when zero and 2 when non-zero, distinguishing appending content from substituting it. Finally the code sets its filter flag and increments nb_rsp_data_filters or nb_req_data_filters on the stream, which is HAProxy's documented opt-in for body access– this time reusing the internal structure of the load balancer to inject code into the page at delivery time.

⠀

Once a victim is marked for injection, two callbacks finish the job on the way out. ted_http_headers_for_htx runs first, and only when the data is on the response side, a state block is initialized during the request, and the transaction flag is set. It rechecks the response against the rule that matched earlier, testing Content-Type and the status line, so a payload is delivered only when the reply is a document worth modifying. It then reshapes the response to fit the incoming file: sets Content-Type, adds a Content-Disposition filename if the rule has one, writes the new body length into the custom length header, deletes Accept-Ranges so the client cannot request byte ranges and spot the size mismatch, and forces the status to 200 OK if it was anything else.

ted_http_payload performs the swap. For each body chunk, it takes only as much as the payload file has left, reads that slice from disk, decrypts it with ngx_decrypt_script, and substitutes it through HAProxy's own body-editing calls. When the replacement changes the body length, the code shifts every remaining filter's offset by the difference, so nothing downstream sees an inconsistency. With the rewritten length header and range support stripped, the size change leaves no trace.

trace_http_end handles the leftover bytes. The previous callback can only overwrite bytes that already exist in the response, so when the payload is larger than the original body there is a remainder with nowhere to go. This function runs at the end of the response and appends it. It checks that the state block is in an injection mode, that the headers were already rewritten, and that fewer bytes have been delivered than the payload holds. If so, it measures the free space left in the response buffer, reads exactly that much from the payload file, decrypts it with ngx_decrypt_script, and appends it as a new data block, bumping the channel's output count to match. 

The result is that a payload of any size can be delivered across as many passes as it takes, using HAProxy's own scheduler to drive the process.

To ensure persistence, curlRAT is integrated and hidden as libc routines.

⠀

Attacker infrastructure

The observed infrastructure follows a consistent pattern: Domains are registered under low-cost commodity TLDs — .store, .space, .site, .autos — and use subdomain schemes mimicking image-serving CDN endpoints (img.) They then blend payload delivery traffic into normal web browsing. The naming convention across suggests a shared registration workflow rather than ad-hoc infrastructure. The img.responsive.pstatic.autos mimics Naver's pstatic.net static content domain, a South Korean web platform, which combined with the watering-hole delivery model adopted by the ted backdoor is consistent with targeting of Korean-speaking users.

Attribution

At the time of the analysis, compromised servers had exposed the Groupware login portal on port 443, which is heavily present in Korean enterprise environments. The targeting of regional software (Groupware), mimicking Naver's static content domain, usage of simple xor and substitution ciphers and the watering-hole model already documented in the Operation Code on Toast (APT37) and Operation Synchole (Lazarus), allows medium confidence attribution to DPRK APT. The list of C2s hardcoded is associated with APT37 by ThreatFox and maltrail.

The campaign's timeline and delivery mechanism overlap with Operation SyncHole, a concurrent Lazarus campaign documented by Kaspersky running from November 2024 through February 2025, in which Lazarus compromised South Korean media sites to redirect visitors to pages serving malicious JavaScript payloads. APT37 and Lazarus Group are distinct North Korean state-sponsored threat clusters assessed by Mandiant to operate under different DPRK agencies — APT37 under the Ministry of State Security, Lazarus under the Reconnaissance General Bureau — though both conduct cyber espionage targeting South Korean entities. Lazarus has been observed to deploy backdoored open-source programs to deliver malware and use feedback XOR + base64 to interact with the C2 by Kaspersky. As of July 2026, similar suspected initial access has been reported by ENKI WhiteHat, suggesting that if a vulnerability in South Korean mail appliances exists, the exploitation could still be ongoing and leveraged by DPRK APTs.

Further evidence is necessary to make a more definitive assessment. Moreover, the presence of ngx_* prefixed routines within the ted backdoor suggest code reused from an nginx backdoor. The ngx_* prefixed routines were observed during the latest Funnull campaign, where (similar to our case) a custom nginx filter was registered to hook HTTP traffic, and simple XOR encryption was applied to the configuration file. However, other than a similar naming convention, no significant code-level overlaps exist to support a stronger linkage.

Conclusion

ted backdoor and curlRAT were designed to persist during long-term espionage operations with the ability to steal cookie sessions, credentials, redirect selected users, conduct drive-by download attacks, and hide evidence of the tampered page to a specific range of IPs to evade detection. Defenders should treat any edge component managing user traffic, SSL, or runtime modules with the same strict security standards as their main application servers. Relying on the component's own logs is not enough; securing these systems requires independent network correlation, memory behavioral analysis, and binary integrity checks.

MITRE ATT&CK techniques

Indicators of compromise (IOCs)

CurlRAT Stager

5db1b6d52faf60b4f32d6fd0c7c938e4d05d29a14c32ded4a9668357c08b6a91

09739441ed4599bac2f8159028f772f71e4b25c8badfff95574e56d7384f3dbe

fea1bc36632c71e5a839803469ef60ac47595d36b2c50934ac109ade6df06e61

CurlRAT

83f7d565b0465546027052b597af46eae3a199e7a91fcc2ab936341147349130

7007a78d50a993cb174c685eba96eb442c9507e38fd9d8e5dffc712f613ec110

6cf1b5e92a9c0756f597a5ddefb38eba32961c52efac7ab2a0aa52c639a8fc53

ed72f4cd8d467b5c5d95ae6aeca4aaeea14d79565d379c1ca5871a714727be16

feeea9d0bf6ae7396d28271baa51ae50df5169ce5d32a516865856f91abc50b3

6cf1b5e92a9c0756f597a5ddefb38eba32961c52efac7ab2a0aa52c639a8fc53

d53c760c23b4405eb04ad0f20ead375440344b3bdf1fb7854ed12e40d155eabe - cronie

2f02b09d61d432134e994ad671258f523bbf289ae6091fd4eae192c60bd51b6f - agetty

8f30b57928934ae67478d0e690c91d046e35a638da098d02922a4a88a0fdb66c - atd

a1d8af3a6acb731f07f72040eccb3450c1c83d40e29f736c2a63d35388660be4 - polkitd

12810854c8b2c391b23e2e18b013e873d0369b0637aa3cf993136c07188ba3b8

009a1e2d7a582a24e50cf2ffc2a005482c8e38f22bf5ed416053855f8d054e1e

SSH keylogger

4bb923eb040aa13ca8fd409c31ee4729c60ddff32e350efe1c5a4a9168a065f5

Ted backdoor

94630b96f628c96a6bff7904b40ffc9ad67c86f8a4ff6080c3b524831c93f402

72e70936f0dbe459142a1d867617c35f8d0cce5d18c6a49e1090a2a5adc8e558

a8bfab4de81a1acb04aacdf757346946b0f5e30f0c9f402004016d0e425119c7

C2

img.monderhouse.space

img.smartnords.site

img.darklights.store

img.responsive.pstatic.autos

img.socialteams.store

img.worksongo.store

Rapid7 customers

If you spend your days building, shipping, defending, or fixing systems, you already know how this goes. A new technique shows up in a research thread, someone drops a “has anyone checked if we’re exposed?” comment, and suddenly you’re juggling risk, patches, logging gaps, and whatever tool is in the blast radius this week.

That day-to-day reality is why Rapid7 Labs is launching Hacktics and Telemetry, a bi-weekly video and audio podcast with episodes built to fit into a lunch break or a commute. It’s hosted by Rapid7's Douglas McKee, bringing to the pod years of deep technical and leadership experience, then co-hosted by Jonah ‘CryptoCat’ Burgess – a strong researcher with a solid pulse on the cybersecurity community.

The format stays consistent on purpose. Each episode starts with a scan of what’s emerging, shifts into a guest conversation, then closes with a short segment that ties the story back to mitigation and tooling. The goal is simple: move past theory, show what’s happening with real examples, and leave you with something you can act on.

Episode 1: OpenClaw Risks, RCEs, and Metasploit Pro Updates

Doug and Jonah open by digging into two AI-centric stories from the past week. The first is PhoneLeak, described as data exfiltration in Gemini via phone call. It’s the kind of uncomfortable example that forces practical questions: how do you defend against mobile clickjacking when it's disguised as a routine CAPTCHA? When an AI assistant has deep extensions into a user's workspace, how do you prevent malicious prompts from quietly accessing sensitive data like 2FA codes? And perhaps most importantly, how do defenders anticipate and monitor for bizarre, out-of-the-box exfiltration methods—like an AI bypassing SMS confirmations to leak data via DTMF tones on a phone call?

The second story comes from the other side of the AI conversation: an AI agent reportedly identifying an RCE in BeyondTrust remote support, plus discussion of older privileged remote access versions. More automation can mean faster discovery, which shrinks the window between “interesting finding” and “you need to patch this.” That changes how defenders think about exposure, patch prioritization, and what “good enough” means (and looks like) when it comes to monitoring.

In the guest segment, Greg Richardson (Global Advisory CISO & AI Thought Leader, 6 Levers AI) walks through how he uses AI agents in his workflow while keeping control tight. He talks about setting tasks while he sleeps, but the constraints are the point: access is locked down, the agent only touches files he explicitly provides, communication is limited, and token limits help cap the size of any mistake. He also makes a strong case for starting small, with one task at a time, instead of trying to automate dozens of things on day one.

To close out this inaugural episode, the team hits on a SolarWinds Help Desk vulnerability, then shares a quick look at Metasploit Pro 5.0 updates – including more granular payload selection and a walkthrough of the new UI.

If your idea of useful content includes threat trade-offs, concrete mitigations, and a bit of candid “how this actually plays out,” you’re in the right place.

Catch the full episode below:

⠀

Following our recent published advisories, this publication is intended to outline a summary of the cyber activities associated with the tension. Based on the available information, we believe the conflict is beginning to show signs of expanding beyond a strictly regional crisis. Initial threat reporting pointed to a measurable increase in cyber activity linked to the crisis predominantly focused on hacktivist mobilization, with reports of phishing campaigns, and claims of data theft and disruptive operations. For a companion piece focused around our customers, dive into Rapid7 Detection Coverage for Iran-Linked Cyber Activity.

Cyber activity by groups associated with Iran and their affiliated ecosystems have begun to surface. Much of the visible activity currently appears to have limited immediate operational impact as it consists primarily of website defacements, distributed denial-of-service (DDoS) attacks, coordinated messaging campaigns, phishing attempts, and reconnaissance against exposed digital infrastructure. While these incidents may appear opportunistic or symbolic, historical patterns of such behavior suggest that this activity can represent early-stage signaling, pressure, and preparatory shaping operations rather than isolated disruption.

Iran’s cyber ecosystem operates through a layered structure that includes state-linked advanced persistent threat (APT) groups, proxy actors, hacktivist personas, and sympathetic foreign collectives. Even when not centrally coordinated, these actors often converge on the same narratives and target sets during geopolitical crises, enabling simultaneous visible disruption and covert intelligence-driven intrusion activity. As the conflict evolves, this ecosystem provides a scalable and deniable tool for retaliation that can gradually intensify.

It is very likely that the cyber risk will widen accordingly as the current conflict continues. Governments and organizations located in regions hosting U.S. military infrastructure or closely aligned with U.S. and Israeli positions may face increased exposure, particularly across sectors such as logistics, critical infrastructure, public administration, energy, and telecommunications.

Strategic context and operational trends

Iran does not operate according to a single publicly articulated cyberwarfare doctrine. Instead, its cyber strategy has evolved pragmatically as part of the country’s broader asymmetric security model. Since 2010, there has been an expansion of its cyber capabilities as instruments for intelligence gathering, internal control, retaliation, coercive messaging, and regional influence. Cyber operations are therefore best understood not as a separate military domain with a fully transparent doctrine, but as an adaptable component of the regime’s survival and strategic competition against outsiders.

Broadly speaking, Iranian cyber activity tends to serve three overlapping strategic objectives. The first is regime security and domestic control, in which cyber tools support surveillance, information control, and disruption of dissident or opposition networks. The second is strategic intelligence collection, in which state-linked actors target governments, defense organizations, technology providers, telecommunications firms, and critical infrastructure to gather political, military, and economic intelligence. The third is coercive signaling and regional influence, in which cyber operations impose costs on adversaries, shape perceptions, and demonstrate retaliatory capability while remaining below the threshold of overt interstate war.

A key feature of this regime’s approach is the development of long-term access. Iranian APT groups often conduct sustained intrusion campaigns focused not only on immediate collection but also on access persistence, credential harvesting, and network familiarity. In a crisis environment, these pre-existing footholds can become strategically important, supporting either intelligence collection or later disruptive operations. This is one reason current low-visibility intrusions deserve as much analytical attention as public hacktivist claims. The visible DDoS or defacement campaign may dominate headlines, but the more significant strategic risk often lies in covert access established inside other targets. 

Another defining feature of Iran’s cyber strategy is its layered operational model. State-linked APT groups frequently operate alongside contractors, proxies, persona-driven influence actors, and hacktivist collectives. This structure offers several advantages: it creates deniability, increases operational tempo; broadens the range of possible targets; and allows Iran-aligned ecosystems to combine disruptive spectacle with intelligence-driven depth. During periods of heightened tension, this blended model enables visible pressure operations to coexist with quieter espionage or pre-positioning campaigns. Current reporting on the conflict strongly supports this interpretation, with activist and proxy campaigns surging in parallel to concern over state-linked phishing, malware, wipers, and infrastructure-focused targeting.

Iran’s threat actor landscape

State sponsored 

Iran’s cyber capabilities are distributed across a hybrid ecosystem of state institutions, intelligence services, military structures, and semi-official operators. Rather than relying on a single centralized cyber command, Tehran appears to allocate responsibilities across different organs, primarily the Islamic Revolutionary Guard Corps and the Ministry of Intelligence and Security, with support from contractors, front entities, and affiliated personas. Strategic coordination of the cyber domain is overseen by the Supreme Council of Cyberspace, while operational activities are carried out through a mix of official and semi-official channels.

IRGC-linked actors

The Islamic Revolution Guard Corp (IRGC) maintains one of Iran’s most visible offensive cyber capabilities and has been associated with cyber espionage, influence operations, credential theft, and politically aligned disruptive activity. Among the principal IRGC-linked actors are APT35 (also known as Charming Kitten or Mint Sandstorm), which has long conducted spear-phishing and credential-harvesting operations against diplomats, journalists, researchers, and policy communities; APT42 is an actor particularly associated with surveillance and social engineering targeting dissidents, activists, journalists, and policy experts. Cotton Sandstorm (also known as Holy Souls and Emennet Pasargad), meanwhile, has been linked to both espionage and influence-oriented operations targeting regional adversaries and Western institutions. Recent reporting also highlights continued concern around malware associated with this broader actor set, including infostealing and espionage tooling used in phishing-led operations.

MOIS-linked actors

The Ministry of Intelligence and Security (MOIS) operates parallel cyber capabilities that tend to emphasize intelligence collection, long-term access, and strategic espionage. The most prominent groups in this cluster include MuddyWater and OilRig (also known as APT34). CISA has previously described MuddyWater as an Iranian government-sponsored actor conducting cyber espionage and malicious cyber operations across multiple sectors, while current reporting continues to place the group among the most operationally relevant Iranian state-linked threats in the present crisis environment. OilRig remains a longstanding espionage actor focused on governments, financial institutions, energy entities, and other strategic organizations.

These actors illustrate Iran’s distributed cyber-operational model: Intelligence-driven access development, influence, psychological pressure, and opportunistic disruptive action are not separate lines of effort but parts of a broader strategic continuum.

Parallel hacktivist and proxies

Beginning in June 2025, a noticeable surge in hacktivist and proxy cyber activity accompanied the broader escalation of tensions in the Middle East. This reflects a recurring pattern observed during previous geopolitical crises, in which ideologically aligned non-state cyber actors mobilize alongside, or in parallel with, state-linked cyber operations. In the current confrontation, this dynamic has again expanded the cyber landscape beyond traditional state-directed espionage or sabotage.

By early March 2026, several dozen hacktivists or proxy collectives emerged related to the conflict. These groups vary significantly in capability and reliability. Some focus on distributed denial-of-service (DDoS) attacks, while others conduct website defacements or hack-and-leak campaigns. Some primarily amplify claims of compromise that are exaggerated or only partially verifiable. Their significance, therefore, lies less in technical sophistication than in the cumulative pressure they place on defenders and the broader information environment.

In crisis situations, this activity can produce strategic effects. Numerous low-impact incidents can consume defensive resources, complicate attribution, and obscure more sophisticated intrusions occurring simultaneously. Hacktivist campaigns may therefore function as distractions, signals, or psychological pressure while more capable actors pursue quieter access to high-value networks. For this reason, the analytical distinction between advanced persistent threat (APT) activity and hacktivism can become blurred during periods of geopolitical confrontation.

Several collectives active in the current environment publicly position themselves as ideologically aligned with Iran or with members of the so-called “Axis of Resistance.” Among the more visible groups are Handala Hack Team, Dienet, FAD Team, APT IRAN, Cyber Islamic Resistance, and Fatimion cyber team. These actors frequently frame their operations as retaliatory cyber campaigns targeting Israeli, Western, or allied regional entities, claiming responsibility for activities such as website defacements, DDoS attacks, and hack-and-leak operations targeting mainly government, telecommunications, energy, and financial entities. Although many claims remain difficult to verify independently, their messaging strategy often emphasizes their psychological and reputational impact.

In parallel, several pro-Russia hacktivist groups have also engaged in operations linked to the confrontation, including NoName057(16), Sever Killer, and Russian Legion. These groups typically conduct large-scale DDoS campaigns targeting government portals, financial services, and transportation or telecommunications infrastructure in states perceived as supporting Israel or broader Western policy positions. Their participation illustrates how regional conflicts can attract cyber actors from outside the immediate theater when ideological alignment or strategic narratives converge.

Cyber activities linked to the ongoing conflict

Iranian APT group operations 

Beyond the highly visible hacktivist activity circulating on social media, defacement platforms, and Telegram channels, a quieter but more strategically significant layer of cyber operations is unfolding through Iranian state-linked APT groups. These operations appear ongoing and aligned with broader geopolitical objectives tied to the current conflict environment.

Recent threat reporting indicates continued operations by the Iranian APT group, MuddyWater, which is widely assessed to be linked to MOIS. Since at least early February 2026, reporting has suggested potential compromises or attempted intrusions targeting organizations associated with the United States and allied interests. 

According to public reporting, activity linked to the group was reportedly observed within the networks of a United States–based bank, a United States airport, a nonprofit organization operating across the United States and Canada, and a software company with operations in Israel. In several of these incidents, threat actors reportedly deployed a previously undocumented backdoor known as Dindoor, suggesting a coordinated, ongoing campaign rather than isolated compromise events.

Hacktivist and proxy disruption activities

The most visible form of cyber activity so far remains hacktivist and proxy-led disruption.

DDoS attacks are among the most common tactics employed by hacktivist groups. Pro-Russia groups such as NoName057(16) and Server Killers, along with other pro-Iran collectives affiliated with them, have been linked to waves of coordinated DDoS attacks against Israel, Qatar, Bahrain, and other politically symbolic targets. These attacks are generally inexpensive and cause only short-term technical damage, but they remain strategically useful because they disrupt public services, tie up defense resources, generate media coverage, and fuel the narrative of a sustained cyber response.

⠀

Website defacement also remains a common tactic. Groups such as FAD Team, 313, and Cyber Islamic Resistance have been associated with claims of attacks on several websites. Although defacements are technically simple to execute, they remain analytically significant: They are highly visible, rapidly disseminated, and psychologically impactful, often creating an exaggerated perception of widespread systemic compromise.

Data breaches represent a far more significant dimension of cyber operations. The Iranian-aligned group Handala, in particular, continues to blend political messaging with claims of data theft and the selective release of allegedly compromised information. The group recently asserted that it had infiltrated a Saudi energy company and exfiltrated internal documents, framing the operation as a combination of data exfiltration, coercive pressure, and psychological warfare targeting the energy sector. Even when the full authenticity of released datasets cannot be independently verified, the publication of partially credible material can still generate substantial reputational damage and potential operational disruption for affected organizations.

Targeting critical infrastructure has emerged as one of the most concerning aspects of the current cyber activity by pro-Iran hacktivists and proxy collectives. Groups operating in this ecosystem, including Iranian APTs, Handala, and networks associated with the Cyber Islamic Resistance umbrella, have publicly claimed operations targeting infrastructure across the region. Recent Telegram posts indicate that an Iranian APT group claimed responsibility for attempts to sabotage Jordanian critical infrastructure, while other Iran-aligned hacktivist personas have asserted access to sectors including fuel systems, water utilities, and other operational technology environments.

In a separate case, the Handala Hack Team has alleged that it compromised both Oil and gas companies in the United Arab Emirates and Israel, claiming to have exfiltrated more than 1.3 TB of sensitive data from oil and gas sector networks. These claims, which would represent a significant intrusion into Middle Eastern energy infrastructure if confirmed, have circulated primarily through hacktivist communication channels and social media reporting and have not been independently verified.

⠀

Although many of these claims remain difficult to independently verify, the recurring focus on industrial control systems and essential services is analytically significant. Hacktivist collectives aligned with Iranian geopolitical narratives frequently leverage infrastructure-related claims as part of information operations designed to amplify perceived impact, generate psychological pressure, and signal the potential for escalation into operational technology environments. Even when technical disruption is limited or exaggerated, the persistent narrative around infrastructure compromise can shape defensive priorities and highlight potential escalation pathways within the broader cyber conflict.

Sectoral exposure and risk landscape

In the current geopolitical context, cyberattacks extend far beyond military networks and defense institutions. Modern cyber operations increasingly aim to affect the broader ecosystem that supports government activity, economic stability, and public trust. Consequently, adversaries seek not only technically vulnerable targets but also organizations whose compromise or disruption can increase visibility, influence public perception, or create cascading effects across interconnected systems.

A successful intrusion into a widely used service provider, a major infrastructure operator, or a publicly accessible institution can quickly produce consequences that extend far beyond the initial target, affecting supply chains, service availability, and public confidence. In this context, cyber operations often serve multiple purposes simultaneously: intelligence gathering, strategic positioning within critical networks, and generating disruption or exerting influence during periods of heightened geopolitical tension.

At present, several sectors appear particularly exposed:

• Government institutions and public administration

• Defense and aerospace industry

• Energy sector, including oil, gas, and electricity

• Telecommunications providers

• Financial services

• Transportation systems

However, the risk landscape extends beyond these sectors themselves. Organizations that form part of the broader digital supply chain supporting these industries may also represent attractive entry points. This includes cloud service providers, managed service providers, technology vendors, and other third-party platforms that maintain privileged access to client environments. Compromising such intermediaries can allow adversaries to reach high-value targets indirectly. By gaining access to a supplier or service provider, attackers may obtain pathways into multiple networks simultaneously, access sensitive information, or move laterally across interconnected operational systems. Supply chain compromise, therefore, offers both scale and stealth, making it an increasingly common tactic in sophisticated cyber campaigns.

Geopolitical alignment can also influence targeting decisions. Organizations based in countries that host United States military assets or are publicly aligned with United States or Israeli policy positions may attract additional attention from adversaries. In these cases, targeting can carry symbolic, political, or strategic value beyond the immediate technical impact of the intrusion. Within this environment, cyber exposure can generally be understood through three overlapping targeting dynamics.

Symbolic targets include municipalities, universities, media outlets, and public institutions. These organizations may be targeted primarily for visibility, messaging, or propaganda purposes. Even limited disruption or data exposure can generate headlines and amplify the perceived reach of the attackers.

Operational targets include sectors that support everyday economic and social activity, such as telecommunications providers, transportation systems, payment networks, and fuel distribution infrastructure. Disruptions in these areas can quickly affect daily life, creating public anxiety and increasing pressure on authorities to respond.

Strategic targets consist of entities whose compromise offers long-term intelligence or operational value. This category includes defense contractors, major financial institutions, government networks, and operators of critical infrastructure. In these cases, adversaries may prioritize persistence and stealth to collect intelligence, monitor decision-making processes, or maintain access that could be leveraged during future crises.

Taken together, these targeting patterns illustrate a broader shift in cyber operations: Attackers are increasingly selecting targets not only for their intrinsic value, but for the broader political, economic, and societal effects that disruption or compromise can produce.

What should organizations monitor?

In the current phase of the conflict, organizations should continue to monitor for indicators that activity is shifting from opportunistic disruption toward deliberate intrusion or access preparation.

Internet-facing infrastructure is often the initial entry point. Elevated scanning or probing of public websites, VPN gateways, remote access portals, cloud services, and email authentication infrastructure may indicate early reconnaissance. While some scanning is routine, sudden increases in probing activity or authentication attempts should be treated as potential precursors to intrusion.

Phishing and social engineering campaigns are also likely to intensify. Threat actors may exploit developments in the conflict by using lures that reference civil defense alerts, battlefield updates, humanitarian messaging, or urgent requests that appear to originate from leadership or trusted partners. In some cases, malicious applications or replicas of legitimate services may be used to harvest credentials or deploy malware.

Credential misuse remains a primary access vector. Security teams should monitor for abnormal authentication patterns, including logins from unusual geographic locations, access at unexpected hours, repeated failed logins followed by success, changes to multi-factor authentication settings, or the creation of new privileged accounts.

Organizations operating critical infrastructure should closely monitor activities within their operational environments. Suspicious access to remote management platforms, unusual connectivity between IT and OT networks, or unexpected activity involving engineering workstations or vendor access channels may signal reconnaissance within sensitive systems.

Finally, monitoring the broader information environment can provide early warning and signal the need to increase monitoring. Hacktivist groups frequently use platforms such as Telegram and X to circulate target lists, claim attacks, or release fragments of allegedly stolen data tied to geopolitical events. Tracking these channels can help organizations identify potential targets and strengthen their defensive posture before malicious activity reaches their networks.

Additional reading from Rapid7 Labs, for Rapid7 customers: Rapid7 Detection Coverage for Iran-Linked Cyber Activity