A Linux espionage toolkit identified in two South Korean organizations has revealed an unusual approach to maintaining access within enterprise infrastructure: embedding a backdoor directly into a legitimate HAProxy load balancer. The implant, known as ted, allowed the compromised service to continue processing normal traffic while providing the attacker with capabilities for remote command execution, HTTP traffic interception, and selective modification of web responses.
The toolkit also included curlRAT, an SSH credential-harvesting component, and trojanized Linux system daemons, indicating an operation designed to support persistent access and intelligence collection. The activity is assessed to be associated with North Korean state-sponsored cyber operations, although the specific actor responsible remains unconfirmed. The initial access vector and the full scope of the compromise have not been established.
The intrusion is particularly significant because it targeted a trusted traffic-processing component rather than relying solely on a conventional endpoint backdoor. By operating inside HAProxy, the attacker could potentially access sensitive application traffic and conceal certain malicious requests from backend systems. This creates a visibility gap for organizations that rely primarily on application logs or the load balancer’s own statistics to identify suspicious activity.
The case highlights the importance of verifying infrastructure integrity, correlating independent telemetry, and assessing potential credential and session exposure following a compromise. It also demonstrates why a functioning service and an expected software version should not be treated as sufficient evidence that the underlying system remains trustworthy.
The activity involved a previously undocumented Linux toolkit found in the environments of two organizations operating in South Korea’s automotive and media sectors. The toolkit combined several components: a backdoor embedded in HAProxy, a remote access tool known as curlRAT, an SSH credential-harvesting component, a stager, and modified Linux system daemons.
The central component, ted, was compiled into HAProxy 2.8.12 through a custom filter. It used the application’s native processing mechanisms to inspect HTTP traffic and perform malicious actions without preventing the load balancer from carrying out its normal duties.
The attacker could use the implant to communicate with external infrastructure, execute commands, transfer files, collect selected traffic information, and alter responses delivered to particular visitors. The supporting toolkit provided additional access, persistence, and credential-harvesting capabilities.
The precise date of the initial compromise has not been established. Related malware samples appeared in public malware repositories in mid-2025, and the activity may have begun earlier. The available evidence does not establish the full number of affected organizations beyond the two identified victims.
The activity is assessed to be associated with North Korean state-sponsored cyber operations, with medium confidence. The assessment is supported by the targeting of South Korean organizations, characteristics of the toolkit, and infrastructure relationships associated with previously documented DPRK-linked activity.
The specific operator remains unresolved. APT37, Lazarus, and Kimsuky are relevant to the attribution discussion, but the available evidence does not justify assigning the operation definitively to any one of them.
Similar targeting, infrastructure overlap, and familiar malware techniques can strengthen an attribution hypothesis, but none is conclusive on its own. Infrastructure can be reused or shared between operations, and historical associations do not necessarily identify the operator behind a new intrusion.
The most defensible conclusion is therefore a DPRK-nexus espionage operation, with the precise actor cluster remaining unconfirmed.
The initial access vector remains unknown.
Both affected environments included internet-facing edge infrastructure exposing web and mail services. A Groupware login portal and mail server were identified as plausible entry points, but no specific vulnerability or exploitation method has been confirmed.
The reconstructed intrusion sequence suggests that the attacker first obtained access to an edge system, established persistence, and collected credentials. From there, the operator could move into internal Linux infrastructure and deploy additional components.
A stager was used to inspect the target environment and deliver malicious binaries. The toolkit also included a modified SSH daemon capable of capturing plaintext passwords during authentication. curlRAT provided remote access and supported continued control over infected systems.
The ted backdoor was positioned inside the HAProxy load balancer, where it could interact with traffic passing between users and backend applications.
The distinction between observed activity and reconstructed sequence matters here. The malware components and their capabilities are documented, but the complete path from initial access to deployment has not been established. A specific Groupware vulnerability should not be presented as the confirmed entry point without additional forensic evidence.
The malicious build was not the result of exploiting a vulnerability in HAProxy’s normal code. The attacker modified the software after obtaining sufficient access to the environment.
This means a conventional vulnerability-management workflow may not identify the central problem. A system can report an expected software version while the executable itself contains unauthorized functionality.
The relevant question is not only whether the application is up to date, but whether the deployed binary matches a trusted build and whether its deployment history can be accounted for.
HAProxy commonly sits between users and backend applications. Depending on the configuration, it may terminate TLS connections, inspect HTTP requests, and forward traffic to internal services.
That position can expose information that would otherwise remain protected in transit. A compromised load balancer may have access to session cookies, authentication-related headers, and other application data processed at that point.
Ted used this position to inspect traffic and selectively alter responses. The implant could apply conditions based on request characteristics and deliver modified content only to particular visitors.
This selective behavior is significant. A website may appear normal during routine checks while a smaller group of users receives attacker-controlled content. The same infrastructure can therefore serve legitimate traffic and support further targeting at the same time.
One of the more consequential features of ted was its handling of command-and-control requests. Certain requests were processed inside HAProxy rather than forwarded to backend servers. The implant also manipulated internal connection counters to reduce the visibility of those exchanges.
As a result, backend application logs may not contain the relevant requests, while the load balancer’s own statistics may not accurately reflect the malicious activity.
This creates a visibility gap. A security team relying only on backend logs or the compromised service’s internal metrics could overlook activity that occurred before the request reached the application.
The absence of suspicious entries in those sources should therefore not be treated as conclusive evidence that no malicious traffic occurred.
The available evidence establishes that the toolkit included a trojanized HAProxy build, a companion RAT, credential-harvesting functionality, and modified Linux system components. Two South Korean organizations have been identified as victims, and the activity is assessed to have a DPRK connection.
Important gaps remain. The initial access vector and complete operational timeline have not been confirmed, the specific actor remains unresolved, and there is currently no evidence establishing deployment across a broader set of organizations.
The combination of credential harvesting, remote access, persistence, and traffic manipulation suggests an operation designed for sustained access rather than a short-lived compromise. These capabilities are consistent with an espionage objective, although their presence alone does not show how extensively they were used or what information was ultimately obtained.
Infrastructure overlaps may point to related activity, but the evidence currently supports a narrow scope: two identified organizations and an unresolved DPRK-linked operator. Expanding that assessment would require independently verified connections to additional infrastructure, malware, or victim environments.
The defining feature of this intrusion is not simply the presence of another Linux backdoor, but where the attacker placed it. By integrating ted directly into HAProxy, the operator gained a position between users and backend applications while the service continued performing its normal function.
The attacker did not need to exploit a vulnerability in HAProxy itself. Once sufficient access to the host had been obtained, the legitimate binary could be modified and replaced with a trojanized build. From that position, the backdoor could inspect traffic, collect session-related information, execute commands, transfer files, and selectively manipulate content returned to users.
Some malicious requests could also be handled within HAProxy without reaching backend systems. Application logs may therefore provide an incomplete record of attacker activity, while statistics generated by the compromised service may no longer be reliable.
For defenders, the incident goes beyond a conventional malware infection. Once a component responsible for processing and observing traffic is compromised, the integrity of both the service and the telemetry it produces comes into question. A load balancer can remain available and continue processing legitimate traffic even after the binary performing that function has become part of the intrusion.
Detection should focus on the integrity of the infrastructure and the behavior occurring around it, rather than relying on a single indicator or software version.
Verify deployed binaries against trusted builds. Organizations should compare production HAProxy binaries with known-good versions and investigate unexpected differences. Where custom builds are used, the build process, source code, and deployment artifacts should be documented and independently verifiable.
Review changes to critical system components. Unexpected modifications to HAProxy, SSH, cron, and other system daemons should be investigated. File timestamps and process names alone are not sufficient to establish legitimacy, particularly when an attacker may have manipulated them.
Correlate independent network telemetry. Traffic observed outside the load balancer should be compared with proxy and backend application logs. Unexplained discrepancies, unusual outbound connections, or requests that appear in network records but not in expected application telemetry may warrant further investigation.
Investigate credential-related anomalies. Unexpected privileged logins, unusual SSH authentication behavior, credential reuse, and access from unfamiliar systems may indicate that harvested credentials have been used beyond the original host.
Review persistence and deployment history. Security teams should examine service definitions, startup mechanisms, scheduled tasks, and recent changes to production infrastructure. Unauthorized binary replacement should be treated as a potential compromise even when the affected service continues to operate normally.
Use indicators as a starting point, not a conclusion. Known hashes, domains, and file paths can support triage, but they should be evaluated alongside behavioral and forensic evidence. The absence of a published IOC does not rule out a related intrusion.
Organizations that identify evidence consistent with this activity should treat the affected infrastructure as potentially compromised rather than attempting to resolve the issue through a routine software update alone.
The first priority is to preserve relevant evidence and contain the affected systems where operationally feasible. Investigators should establish the scope of unauthorized access, identify modified binaries and persistence mechanisms, and determine whether credentials or session material may have been exposed.
Affected software should be restored from trusted sources. Where the integrity of the operating system cannot be established, rebuilding the host may be more reliable than attempting to remove individual malicious components.
Credentials that may have been exposed should be rotated according to the assessed scope of compromise. This may include privileged accounts, service credentials, SSH keys, and application secrets. Active sessions should also be reviewed where session material may have been accessible to the attacker.
Organizations should strengthen controls around production binary deployment, restrict administrative access to edge infrastructure, and maintain independent security telemetry. Load balancers and reverse proxies should also be included in incident response and threat-hunting procedures, rather than treated solely as networking components.
External intelligence can add another layer to that investigation.
A compromised load balancer is an internal security problem, but the activity around an intrusion can also leave signals outside the organization. Compromised credentials, threat actor infrastructure, dark web discussions, leaked data, or related indicators may provide additional context during an investigation.
This is where ThreatMon can help. Its intelligence workflows can support the monitoring of relevant threat activity, enrichment of known indicators, and correlation of infrastructure relationships. Dark web monitoring and HUMINT may also provide context when threat actors discuss compromised access, infrastructure, or related operations.
In a case involving a trojanized load balancer, these external signals can help analysts determine whether known indicators have appeared elsewhere, identify potentially related infrastructure, and assess whether additional activity warrants investigation. Such findings must be validated before they are treated as evidence of a broader campaign or additional victims.
External intelligence does not replace host forensics or internal security monitoring. It can, however, help organizations prioritize what to investigate and place technical findings within a broader operational context. Combining those perspectives gives security teams a more complete basis for assessing exposure and responding to a potential compromise.
The ted intrusion demonstrates how a trusted infrastructure component can become part of an attacker’s operating environment without losing its normal functionality.
For defenders, the practical lesson is to treat infrastructure integrity as part of the detection problem. A service can be available, process traffic normally, and report the expected software version while still being compromised. Trusted builds, independent telemetry, credential exposure assessment, and external threat intelligence can help security teams determine whether the infrastructure they rely on can still be trusted.
More posts
Share this article
Found it interesting? Don’t hesitate to share it to wow your friends or colleagues
Subscribe to our blog newsletter to follow the latest posts
