We’re well into the new year and moving fast with our latest updates. This month, we’re closing the visibility gaps that modern adversaries use to bypass traditional geo-fencing and identity controls with the launch of Silent Push Traffic Origin.
By exposing the true upstream country-of-origin behind residential proxies, VPNs, and laptop farms, Traffic Origin provides “origin certainty” for KYC, KYE, AML, and fraud workflows. This allows investigators to identify high-risk sessions earlier, improving regulatory compliance and avoiding the fines associated with sanctioned-region access and identity deception.
Traffic Origin
Traffic Origin unmasks the infrastructure behind residential proxies, VPNs, and laptop farms. It allows security teams to identify the high-risk or sanctioned region where a session originates, even when the surface IP appears domestic or clean.
Upstream Attribution: Safely identify and block “origin mismatches” without disrupting legitimate users.
Sanctioned Region Detection: Flag traffic originating from regions such as the DPRK, Iran, or Russia that is hidden behind obfuscated paths.
Total View Integration: A new tab provides Map and Table views to correlate surface geolocation with hidden upstream links.
Threat Check
Threat Check is now available as a native module in the Silent Push platform, enabling centralized validation of high-volume indicators across multiple data sources
Native IOFA™ Integration: Validate IPs, domains, and hashes against proprietary Indicators of Future Attack™ (IOFA™) feeds.
Consolidated Risk Logic: Threat Check now automatically incorporates Traffic Origin data to detect sanctioned country routing during lookups.
On-Demand Validation: Support for unlimited queries to identify attacker infrastructure before it is used in an active campaign.
Platform Performance
The console has been updated to unify the investigative experience and increase processing speed.
Unified Search: A standalone module that serves as the single entry point for querying all Silent Push data sources.
Asynchronous Processing: Full migration to the latest SPQL version enables faster result delivery without session disruption.
Navigation Update: A redesigned landing page and consolidated similarity data reduce the steps required to pivot between indicators.
Traffic Origin and Threat Check are available now for Enterprise Edition customers. Contact your account team to enable Traffic Origin permissions for your organization.
As organizations expand remote work, cloud access, and third-party connectivity, security and risk teams rely on IP reputation and GeoIP data to support KYC (Know Your Customer), AML (Anti-Money Laundering), KYE (Know Your Employee), and fraud controls. These tools, however, only evaluate the visible entry point of a connection.
When adversaries use residential proxies, virtual private networks (VPNs), or laptop farms, access can appear local even when it is remotely controlled from high-risk or sanctioned regions. This creates a blind spot where hostile activity blends into trusted access.
Address the Gap With Traffic Origin
Designed to address identity obfuscation, Traffic Origin unmasks proxy layers that hide fraudulent hires and state-sponsored actors in modern enterprise environments. Alongside a mix of new capabilities, Traffic Origin is being integrated into the Silent Push platform.
Even when the observed IP and geolocation appear clean, Traffic Origin identifies the upstream of origin behind a connection. Rather than relying on last-hop indicators, it shifts attribution to where web traffic is actually routed and controlled, providing origin certainty where traditional tools cannot.
By exposing upstream origin mismatch, organizations can identify high-risk sessions earlier, detect identity deception missed by existing controls, and intervene before activity escalates into fraud, regulatory exposure, or financial loss.
“Modern adversaries no longer rely on obviously malicious infrastructure,” said Ken Bagnall, Co-Founder and CEO of Silent Push. “They deliberately operate through clean networks to blend in. Traffic Origin gives security teams the ability to see past that deception and make decisions based on where access is actually being controlled.”
Threat Check
Threat Check is a new native module in the Silent Push console. It validates suspicious IPs and domains against continuously mapped attacker infrastructure, including Indicators of Future Attack™ (IOFA™). Customers can ingest their own indicators, run Threat Check across multiple data sources, and review results through dashboards and analytics.
This enables earlier identification of attacker infrastructure, reduces alert noise, accelerates investigations, and provides measurable lead-time metrics that demonstrate return on investment. Traffic Origin serves as an additional data source for Threat Check, providing upstream origin certainty that enhances the detection of identity obfuscation and malicious activity.
The Silent Push standalone platform is also available via API, integrating with a wide range of security tools, including SIEM & XDR, SOAR, TIP, and OSINT, to provide automated enrichment and actionable intelligence.
Interested in Learning More?
Connect with our preemptive cyber defense experts for an overview of the Silent Push Enterprise Edition platform and a demonstration of Traffic Origin and Threat Check.
Using a custom-built SystemBC tracker, Silent Push Preemptive Cyber Defense Analysts identified more than 10,000 unique infected IP addresses as part of this botnet. While we don’t have immediate visibility on any follow-on malware payloads deployed via this current SystemBC botnet, historically, many threat actors have used SystemBC to deploy ransomware on compromised networks, highlighting the importance of remediation.
Our analysis shows SystemBC infections are globally distributed at scale, with the highest concentration of infected IP addresses observed in the United States, followed by Germany, France, Singapore, and India.
We identified SystemBC infections within sensitive infrastructure, including compromised IP addresses hosting government websites in Burkina Faso and Vietnam.
SystemBC command-and-control (C2) infrastructure has been observed leveraging abuse-tolerant bulletproof hosting, including BTHoster (bthoster[.]com) and AS213790 (BTCloud).
Our research uncovered a previously undocumented SystemBC variant written in Perl, indicating continued development activity and ongoing evolution of the malware family.
Executive Summary
First documented publicly in 2019, SystemBC (also known as “Coroxy” or “DroxiDat”) is a long-running, multi-platform proxy malware that converts compromised systems into SOCKS5 proxies—and, in some cases, deploys additional malware.
Serving two primary functions, SystemBC proxies traffic through compromised systems and acts as a backdoor to maintain external access to infected internal networks. Some variants, including the Windows version, have been observed dropping additional malware, often alongside ransomware payloads, to tunnel malicious traffic back to attacker-controlled C2 infrastructure. The result is a resilient, anonymizing design that expands the potential blast radius of a compromise.
In May 2024, SystemBC was among the malware families targeted during Europol’s Operation Endgame, a coordinated effort to disrupt large-scale criminal infrastructure. That attention mirrors years of public reporting linking SystemBC activity to breaches that culminated in ransomware deployment—reinforcing why early detection of this activity matters.
Silent Push began tracking SystemBC in 2025, which led to the development of a SystemBC-specific tracking fingerprint to expand visibility into active infections and supporting infrastructure. Using that fingerprint, our team identified more than 10,000 unique infected IP addresses worldwide. Across the dataset, infections were widespread: the largest concentrations of detected victims appeared in the U.S., followed by Germany, France, Singapore, and India.
The dataset also captured infections in sensitive government environments, such as compromised high-density IP addresses hosting official websites in Burkina Faso and Vietnam. That same analysis revealed a previously undocumented SystemBC variant written in Perl, underscoring that this malware is continuing to evolve.
SystemBC is a multi-platform proxy malware that turns infected systems into SOCKS5 proxies, allowing all kinds of malicious traffic to be sent through them. Also known as “Coroxy” or “DroxiDat,” SystemBC was first documented by Proofpoint in 2019. Upon reviewing several forum posts by the creator, written in Russian, our team believes the creator may be Russian or have ties to the country.
SystemBC is commonly used to proxy traffic through compromised systems or to maintain persistent access to internal networks. In some cases, including observed Windows variants, SystemBC has also been used to deploy additional malware, meaning its presence may indicate broader compromise or follow-on infections on the affected system. When a victim server is compromised, SystemBC uses a custom binary protocol and RC4 encryption to encapsulate SOCKS5 traffic.
Unlike virtual private networks (VPNs), SOCKS/SOCKS5 is a specific internet protocol for proxies. Proxies are versatile network protocols that act as middlemen, or relays, between devices and the internet. They can route internet traffic (TCP, UDP, etc.) for different applications, masking IP addresses to bypass online blocks, access geo-restricted content, and enhance privacy for specific applications. Many threat actors use proxies to hide their real infrastructure from defenders.
Since most infected systems are not directly reachable over the internet, SystemBC employs a “backconnect,” or rotating, architecture: clients connect to the exposed C2 servers, which then relay traffic through the infected systems, acting as proxies. This design enables threat actors to route external traffic through compromised hosts and expose otherwise internal networks to external access, thereby significantly increasing the potential impact of any compromise.
Simple map of SystemBC’s network traffic
Initial Intelligence
Investigations have repeatedly documented SystemBC’s role in intrusions that later escalate into ransomware deployment. SystemBC was targeted during Europol’s Operation Endgame in May 2024, but updates from its developer, “psevdo,” continue to appear on the Russian-language forum forum[.]exploit[.]in. This activity prompted deeper analysis—uncovering a highly active SystemBC C2 cluster, a previously undocumented Perl variant, and a trail of global victims.
Psevdo’s updates are written in Russian, with selected translations shown below:
Screenshot of psevdo’s announcements (in Russian), posted on July 19, 2018
Post-Endgame forum activity shows the codebase continuing to evolve:
Announcement of “Linux bot and C2 server updates” (Russian text translated to English)
Announcement of “global tests and bug fixes” (Russian text translated to English)
The continued forum activity suggests that Operation Endgame did not, in fact, mark the end of SystemBC development.
Same Threat, New Platform
Files we saw communicating with a known C2 in this cluster included an unusual Perl script, which had zero detections across the 62 antivirus engines on VirusTotal.
The SafeObject file is a UPX-packed variant of StringHash. Once unpacked, it recursively hunts for writable directories before dropping and executing 264 embedded SystemBC payloads, including both ELF and Perl variants.
Behavior aside, the dropper is unusually noisy and littered with Russian-language strings—an unscientific but familiar clue about the threat actor’s origins.
Screenshot of Russian strings observed
Where Infections Hit Hardest
Much of the SystemBC C2 infrastructure observed here appears to rely on hosting tied to abuse-tolerant providers, including BTHoster-linked environments and AS213790 (BTCloud). Zeroing in on the AS213790-hosted cluster alone, we identified more than 10,340 distinct victim IP addresses. Activity was steady—averaging roughly 2,888 victim IPs per day—with infections persisting far longer than typical. On average, systems remained infected for 38 days, with some lasting more than 100 days.
The highest concentration of infected systems seen in our analysis was in the U.S., with more than 4,300 affected IPs. Germany (829), France (448), Singapore (419), and India (294) followed.
Global distribution of IP addresses map
ASNs Tied to Victim IP Addresses
Looking at the ASNs tied to victim IPs, this cluster overwhelmingly targets hosting providers rather than residential networks, which helps explain why infections tend to linger—residential IPs typically change far more frequently.
ASN
AS Name
AS Type
19871
NETWORK-SOLUTIONS-HOSTING
Hosting
46606
UNIFIEDLAYER-AS-1
Hosting
22612
NAMECHEAP-NET
Hosting
398101
GO-DADDY-COM-LLC
Hosting
8560
IONOS-AS
Hosting
16509
AMAZON-02
Hosting
16276
OVH
Hosting
24940
HETZNER-AS
Hosting
26496
AS-26496-GO-DADDY-COM-LLC
Hosting
14061
DIGITALOCEAN-ASN
Hosting
Table of the top 10 ASNs tied to victim IP addresses
Reviewing PADNS data led to an unexpected finding: infections tied to multiple government domains. One example surfaced at IP address 103.28.36[.]105, a sizable cloud host that was also found hosting phutho.duchop[.]gov[.]vn, a Vietnamese provincial government website.
Silent Push Total View of IP address 103.28.36[.]105
Silent Push Total View of domain phutho.duchop[.]gov[.]vn
Screenshot of phutho.duchop[.]gov[.]vn website
IP address 196.13.207[.]92, meanwhile, was linked to domains associated with the Government of Burkina Faso in West Africa.
Screenshot of IP address 196.13.207[.]92 revealing ties to the Burkina Faso government
Screenshot of concours[.]gov[.]bf website
Many infected IP addresses have been reported in VirusTotal comments for engaging in WordPress exploitation activity. Taken together, these observations indicate that threat actors are using SystemBC-associated proxies to target WordPress websites.
Interested in Learning More About Preemptive Cyber Defense?
Our enterprise customers have access to the exclusive report we created for the SystemBC botnet family. If you would like to learn more about our capabilities for tracking adversarial frameworks—or how you can hunt for them on our platform—we encourage you/your organization to reach out to our team for a demonstration of Silent Push cyber defense technology.
Connect with our platform experts for an overview of the Silent Push Enterprise Edition platform. We are happy to provide you with a tailored walkthrough for your specific use case, along with insights into integrations and API capabilities.
Mitigation
SystemBC-associated infrastructure presents a sustained risk due to its role early in intrusion chains and its use across multiple threat actors. Proactive monitoring is critical, as activity tied to SystemBC is often a precursor to ransomware deployment and other follow-on abuse.
Our analysts have developed SystemBC-specific Indicators of Future Attack™ (IOFA™) feeds to help identify related infrastructure and emerging variants before they cause downstream impact. These feeds include:
SystemBC C2 Domains
SystemBC C2 IPs
SystemBC Infected IPs
The IOFA™ feeds are available as part of a Silent Push Enterprise subscription. Enterprise users can ingest this data into their security stack to inform their detection protocols or use it to pivot across attacker infrastructure using the Silent Push Console and Feed Analytics screen.
Ready to dive deeper into the world of preemptive cyber defense? Take our technology for a test drive with the free Silent Push Community Edition today.
Our threat intelligence and research teams will continue to track the SystemBC malware while expanding our understanding of the code variants, victims, and methods for monitoring the associated infrastructure. We believe SystemBC remains an active threat to major enterprises and expect the Tactics, Techniques, and Procedures (TTPs) of the multiple threat actors leveraging this malware to continue evolving indefinitely.
If you or your organization has any information to share regarding the findings of this report, we would love to hear from you.
A massive identity-theft campaign is currently active, targeting Okta Single Sign-On (SSO) and other SSO platform accounts across 100+ high-value enterprises.
Silent Push has identified a surge in infrastructure deployment that mirrors the TTPs (Tactics, Techniques, and Procedures) of SLSH—a predatory alliance between Scattered Spider, LAPSUS$, and ShinyHunters. This isn’t a standard automated spray-and-pray attack; it is a human-led, high-interaction voice phishing (“vishing”) operation designed to bypass even hardened Multi-Factor Authentication (MFA) setups.
The Threat: SLSH “Supergroup”
SLSH (Scattered LAPSUS$ Hunters) is an aggressive cybercrime group that emerged from “The Com” ecosystem. By merging Scattered Spider’s social engineering expertise with LAPSUS$’ extortion models, they have created a sophisticated initial access strategy that targets enterprise organizations through their identity providers.
The primary infrastructure being used is a new “Live Phishing Panel.” This allows a human attacker to sit in the middle of a login session, intercepting credentials and MFA tokens in real-time to gain immediate, persistent access to corporate dashboards.
Critical Target List (Last 30 Days)
If your organization is listed below, Silent Push has detected active targeting or infrastructure preparation directed at your domain within the last month.
Amway, Carvana, Do it Best, GameStop, Murphy USA, Sargento Foods, Sonos, Spin Master, Lamb Weston.
Insurance
HBF Health, Mercury Insurance, Risk Strategies.
Legal Services
Jones Day, Paul Hastings LLP, Perkins Coie.
Media, Education & Hospitality
Cengage, Choice Hotels, Hearst.
Telecommunications
Telstra.
Why Immediate Action Is Required
Standard security awareness training often fails to stop this specific threat. SLSH operators are highly persuasive, frequently calling help desks and employees while simultaneously manipulating a live phishing page to match the victim’s specific login prompts.
The Risk
Total SSO takeover: Once an Okta or another SSO provider’s session is hijacked, the attacker has a “skeleton key” to every app in your environment.
Data extortion: Following the LAPSUS$ playbook, these actors prioritize rapid data exfiltration for public extortion.
Lateral movement: The attackers use the initial SSO breach to move into internal communications (such as with Slack or Teams) to social-engineer higher-privilege admins.
Data encryption: A final step in an SLSH attack after data exfiltration is often to encrypt enterprise data and then blackmail organizations into paying ransom to acquire decryption keys.
Defensive Requirements
Organizations should not wait for a breach notification and immediately:
Warn customer support and employees about ongoing SLSH attacks: The best way to prevent unexpected vishing campaigns from succeeding is to alert your employees about ongoing attacks targeting your company. If someone receives any suspicious messages, calls, or emails during this time, they should be immediately escalated to managers and security teams for review.
Audit Okta system and other SSO provider logs: Hunt for “New Device Enrolled” events immediately followed by a login from an unfamiliar IP address.
Deploy pre-attack intelligence: Silent Push identifies these attack surfaces at the DNS level before vishing calls begin. Use of Silent Push Indicators of Future Attack™ (IOFA™) feeds can block malicious look-alike domains before they go live.
FAQs
What is the SLSH threat group? SLSH is a cybercriminal alliance of Scattered Spider, LAPSUS$, and ShinyHunters, specializing in vishing, SSO credential theft, and ransomware campaigns.
How does a live phishing panel work? It allows an attacker to intercept MFA tokens and login credentials in real-time, enabling them to bypass security prompts while the victim is on the phone.
How can I protect my Okta or other SSO provider account from vishing? The most effective defense is to use phishing-resistant MFA (FIDO2) and to verify all IT support calls through an official out-of-band channel.
Launch of Traffic Origin provides first dedicated defense layer against state-sponsored identity fraud and “laptop farm” infiltrations
Reston, VA, January 22, 2026—Silent Push, a leading preemptive cybersecurity vendor, today announced the debut of Traffic Origin, a unique cybersecurity solution that shifts an organization’s security posture from reactive to proactive by exposing the true upstream origin of adversaries—whether they are hiding via residential proxy, laptop farm, virtual private network (VPN), or other obfuscation technique.
Silent Push Traffic Origin continues the company’s mission to give defenders the advantage by providing origin certainty where other defensive tools see nothing but obfuscation. Traffic Origin allows investigators to identify high-risk remote sessions before they escalate into attacks or credential theft.
Traffic Origin Key Capabilities and Detection
Traffic Origin unmasks the “masking layer” of state-sponsored and cyber criminal actors through three core pillars:
Upstream Traffic Discovery: Goes beyond the surface to reveal the true origin of web traffic. Traffic Origin identifies the “Countries Connected” to an IP, analyzing upstream routing sources, IP address reputation and density, as well as host diversity and categorization (VPN, proxy, Tor, or residential proxy).
High-Confidence Risk Indicators: Eliminate analyst guesswork. Traffic Origin provides a definitive indicator when a residential proxy is routing traffic from sanctioned or high-risk countries (such as DPRK/North Korea, Iran, or Russia).
Total View Context: Visual correlation within the Silent Push platform. See the “UK” or “US” flag on an IP while simultaneously viewing the direct link to upstream traffic from high-risk zones.
“Silent Push Traffic Origin empowers organizations to detect if seemingly legitimate web traffic is actually being routed from high-risk regions or adversary-controlled infrastructure,” said Ken Bagnall, Co-Founder & CEO at Silent Push. “This gives security teams the immediate capabilities to mitigate fraud, identify high-risk logins, vet remote workers, and improve processes of Know Your Customer (KYC) and Anti-Money Laundering (AML).”
The “Invisible” Insider Threat that Organizations Face
Traditional cyber defense is inherently reactive, detecting attacker infrastructure only after it is used in an attack. Today’s most sophisticated adversaries, especially DPRK (North Korea) IT workers, exploit this lag by “hiding in plain sight.”
A significant example of this threat actor behavior is the use of fraudulent personas to gain legitimate employment, followed by the use of sophisticated obfuscation techniques to bypass geographic restrictions, which include:
Laptop Farms: U.S.-based facilitators host company laptops accessed via hardware KVM switches.
Residential Proxies: Masking true locations (often sanctioned jurisdictions) to appear as local, domestic residential traffic.
Infrastructure Mimicry: Using valid credentials and domestic IPs to bypass standard Conditional Access and MFA policies.
The result is high-risk actors that appear as legitimate remote employees, creating a devastating insider threat that traditional defenses cannot detect.
To learn more, start a conversation with Silent Push preemptive cyber defense experts and Book a Demo to see how we can help you uncover attacker infrastructure by searching smarter, faster, and with greater confidence.
About Silent Push
Silent Push is a preemptive cyber defense company. It is the first and only solution to provide a complete view of emerging threat infrastructure in real time, exposing malicious intent through its Indicators Of Future Attack™ (IOFA™) data, enabling security teams to proactively block hidden threats and avoid loss. The Silent Push standalone platform is also available via API, integrating with various security tools, including SIEM & XDR, SOAR, TIP, and OSINT, providing automated enrichment and actionable intelligence. Customers include some of the world’s largest enterprises within the Fortune 500 as well as government agencies. A free Community Edition is available. For more information, visit www.silentpush.com or follow on LinkedIn and X.
North Korean operatives and professional money launderers have been drawing six-figure salaries from Fortune Global 500 companies by exploiting a fundamental flaw in identity verification.
The Silent Push preemptive cyber defense team has found domestic U.S. IP addresses being used by North Koreans, likely as part of their efforts to appear as suitable candidates for jobs with major U.S. corporations.
Traditional KYC (Know Your Company) and AML (Anti Money Laundering) protocols rely on static document validation. These processes fail when an adversary presents a legitimate, stolen identity that is backed by a clean residential IP address.
When organizations cannot distinguish between a local user and a Keyboard-Video-Mouse (KVM)-over-IP relay, their payroll systems become vulnerable to funding sanctioned entities.
Traditional tools only see the local address used to hide a connection. Traffic Origin unmasks the hidden upstream infrastructure used to spoof locations, identifying if a connection actually starts in a high-risk or sanctioned country instead of just the domestic IP where it ends.
Traditional security tools too often rely on historical databases to flag known malicious actors. This reactive approach fails against modern adversaries who constantly rotate infrastructure.
According to recent Department of Justice (DOJ) enforcement actions, thousands of highly skilled cyber operatives have deployed into the global digital workforce using fraudulent identities. Standard security stacks are particularly vulnerable to the tactics they use, including:
Residential Proxy-as-a-Service (RPaaS): Fraudsters and sanctioned actors use residential proxies to appear as legitimate domestic customers. This allows them to bypass geo-fencing and pass initial KYC checks undetected.
Laptop Farms and KVM Switches: Adversaries host physical hardware in a domestic residence and access it remotely via KVM-over-IP hardware.
The FBI issued specific guidance on how these schemes use domestic hardware to thwart standard detection. Because the software runs on a legitimate local machine, security tools see a domestic ISP and a local MAC address.
Beyond the “Last Mile” Geolocation
Traditional identity systems are easily deceived because they only see the exit node or the “last hop.” If the IP address says “London,” an alert is dismissed. This can create a catastrophic blind spot, allowing illicit funds to be washed through banks that cannot see a transaction’s true geographic origin.
The result is a massive money laundering engine. Illicit revenue is systematically moved through shell companies and Electronic Money Institutions (EMIs) to evade international sanctions or cash out from high-risk crypto mixers.
The UK’s Office of Financial Sanctions Implementation (OFSI) has highlighted several indicators of this activity, including upstream connection mismatches where domestic IPs show active links to high-risk jurisdictions.
The KYC & AML Checklist: Spotting the Digital Invisible Insider
While identity thieves and state actors work hard to blend in, their technical infrastructure leaves distinct fingerprints. Monitoring for the following “High Risk” indicators creates opportunities for defenders to disrupt these threat actors:
Red Flag
Technical Indicator
Risk Profile
Geographic mismatch
Domestic IP with an active upstream connection to a sanctioned or high-risk zone.
High (sanctions evasion)
Infrastructure Density
Numerous unrelated devices (High Host Diversity) appear to originate from a single residential IP.
Medium/high (proxy usage)
Interview & meeting friction
Persistent refusal to appear on camera, unusual audio lags, or background environments inconsistent with claimed locations.
High (identity spoofing)
Employment anomaly
A “highly skilled” employee who fails to complete basic tasks, refuses 1:1 video syncs, or delegates work to “partners.”
High (work outsourcing, potentially DPRK)
Financial redirection
Urgent requests to pivot salary payments to an EMI or third-party account shortly after onboarding.
High (money laundering)
Traffic Origin: True-Origin Determination
To solve this dilemma, organizations must move beyond document checks to verify the technical origin of a connection. Silent PushTraffic Origin addresses this visibility gap by providing the highest-confidence attribution indicator available today.
We extend this visibility through true-origin determination. This capability provides targeted, high-confidence attribution, revealing the true geographic origin for identified high-risk infrastructure even when masked by VPNs or residential proxies. While traditional tools only see the final residential hop, Traffic Origin identifies a true upstream source.
Through deep, multidimensional analysis, the Traffic Origin platform evaluates host diversity, subnet reputation, and behavioral density to provide technical clarity.
Verification in the Age of Invisible Insiders
Trust is a liability in an era where an adversary can rent a domestic identity and a clean residential IP for a few dollars. Accurate compliance requires more than just checking a passport. It requires verifying the physical and technical reality of the connection.
Traffic Origin can protect your organization by providing the visibility required to ensure your KYC, AML, and fraud workflows are grounded in technical truth rather than digital deception.
Without the ability to unmask upstream inception points, your security posture remains reactive and incomplete. You lose the critical window to block professional fraudsters and “Invisible Insiders” before they bypass your existing gatekeepers.
Evaluate your network visibility today with Traffic Origin and IP Context to move toward a preemptive posture grounded in technical truth.
Understanding Residential Proxy Detection and Upstream IP Attribution
Adversaries hide in plain sight by mimicking employee footprints. When attackers mask their true location behind Residential Proxies and Laptop Farms, traditional perimeters fail to see the threat. The result? A high-risk actor appears as a legitimate remote employee, creating a devastating insider threat that traditional defenses are not equipped to detect.
Download our free White Paper
Learn how to unmask geographic deception and end the risk of DPRK insider threats, AML compliance failures, and identity fraud driven by residential proxies and domestic laptop farms.
Achieving Origin Certainty
Traffic Origin unmasks the upstream source managing the connection. Move your posture from reactive blocking to proactive validation by exposing the true country of origin before high-risk actors can escalate access.
Unmask the True Origin: Move beyond deceptive geolocations to identify the true country of origin for every connection.
Optimize Security Ops: Reduce alert fatigue and investigation times by replacing ambiguous IP data with definitive, verifiable origin intelligence.
Automate Proactive Defense: Integrate high-confidence origin data into your SIEM and IdP to block location deception in real-time.
1. What is the risk of using residential proxies for identity obfuscation?
Residential proxies allow adversaries, such as state-sponsored actors, to mask their true country of origin by routing traffic through domestic home networks. This bypasses traditional geofencing and makes a high-risk connection from a sanctioned jurisdiction appear as a legitimate remote employee.
2. How does Traffic Origin expose connections routed through laptop farms?
Traffic Origin unmasks the upstream source managing the connection. By identifying the technical metadata of the upstream controller, it exposes when a domestic connection is actually being backhauled from a high risk region through a proxy service or laptop farm infrastructure.
3. Why is IP geolocation insufficient for modern perimeter defense?
Standard geolocation only identifies the “last-mile” IP address, which adversaries easily manipulate. To achieve origin certainty, organizations must move beyond the IP and validate the true point of inception to prevent geographic deception and unauthorized access.
Silent Push Preemptive Cyber Defense Analysts recently uncovered an extensive network of domains associated with a long-term, ongoing web-skimmer campaign, known under the umbrella name: “Magecart.”
Several global payment networks are currently being targeted, including American Express, Diners Club, Discover, and Mastercard.
The most likely victims of this web-skimming campaign are online shoppers, the e-commerce stores that are compromised, and the payment providers.
This campaign has been active since at least January 2022.
Executive Summary
While investigating intelligence shared with us, a set of indicators that were also found on our Bulletproof Host Indicators Of Future Attack™ (IOFA™) feeds, our team discovered a vast network of domains related to a long-term and ongoing credit card skimming campaign. Current findings suggest this campaign has been active for several years, dating back to the beginning of 2022.
This campaign utilizes scripts targeting at least six major payment network providers: American Express, Diners Club, Discover (a subsidiary of Capital One), JCB Co., Ltd., Mastercard, and UnionPay. Enterprise organizations that are clients of these payment providers are the most likely to be impacted.
This blog provides an overview of online credit card skimming (a practice referred to as “Magecart”) and how our technology uncovered the campaign’s infrastructure. Due to operational security (OpSec) concerns, we cannot disclose all of the methods developed by our analysts to track this specific campaign. Please contact our Sales team for access if you would like details.
Web skimming attacks, also known as credit card skimmer attacks, are cyberattacks where malicious code, often JavaScript, is injected into legitimate e-commerce websites or payment portals to stealthily intercept and steal customers’ credit card information and other sensitive personal data during the checkout process.
These attacks typically operate client-side, meaning the code runs in the victim’s browser and is thus nearly invisible to both users and site owners. The goal for the threat actor is to harvest card payment details for fraudulent transactions, identity theft, or resale on dark web marketplaces, ultimately leading to acts of identity fraud and/or bank fraud. This often depends on whether the threat actor is involved in the actual looting themselves or if they’re more interested in simply reselling the data.
As previously noted, the common term used to refer to this type of online credit card theft is “Magecart.” Initially, however, the term Magecart referred to a coalition of cybercriminal groups targeting web shops that used the e-commerce software Magento. Over time, as these attacks proliferated and diversified against other e-commerce products, the name “Magecart” shifted from denoting specific actors targeting the Magento e-commerce software to that of a general label for nearly all web-based credit card skimming, web skimming, and formjacking attacks, regardless of which threat group or technology is, or was, involved.
These days, “Magecart” is an accepted term used to describe the entire class of client-side attacks that covertly exfiltrate sensitive user data from web forms during online transactions, encompassing activity from both the original groups from which the moniker originated and all subsequent copycat groups.
Process of a Web-Skimmer Attack: Step by Step
Silent Push infographic chronicling steps in the web skimmer process
Magecart Unmasked Webinar: February 3, 2026
Join us for a special Silent Push threat intelligence webinar, where we will discuss identifying hidden Magecart activity, defeating client-side threats that steal data from online transactions, and the steps to take in protecting your organization from sophisticated web-skimming networks.
We’ll be hosting three sessions: AMER (1pm ET), EMEA (12pm CET), and APJ (10am SGT) to support our global community.
What Did Our Threat Team Observe?
One of the indicators we started from was cdn-cookie[.]com, which pointed to an IP address on ASN 209847, which was only recently acquired by the European-sanctioned entity, PQ.Hosting/Stark Industries, also known as THE.Hosting/WorkTitans B.V.
During initial analysis, our team determined that this domain was hosting a few URLs that loaded highly obfuscated scripts, such as:
cdn-cookie[.]com/recorder.js
Further analysis of the scripts and related domains revealed a broader picture: a long-term web-skimming campaign with several ongoing infections dating back to approximately 2022.
We identified additional technical fingerprints that extend beyond the current campaign’s infrastructure. However, due to OpSec concerns and our desire not to highlight mistakes the threat actor is making in its deployments, those details are only available to our enterprise clients and law enforcement. Please contact our Sales team for access if you would like more information or book a demonstration with our experts.
Before examining the web skimming code and its operation, let’s first highlight how we utilize the Silent Push platform to identify additional indicators and compromised websites related to this campaign.
Besides a simple search for the indicator itself, one of the first queries performed is often done to see whether a given indicator has been loaded in the context of any other website in our database. To achieve this, we utilize our proprietary Web Resources data set, which contains data on all resources loaded by any websites that Silent Push has scanned.
The query below showcases this for the initial seed domain: cdn-cookie[.]com.
datasource = ["webresources"] AND resource_hostname = "cdn-cookie.com" AND hostname != "cdn-cookie.com" AND hostname != "www.cdn-cookie.com"
In the results below, notice that the “hostname” field includes numerous seemingly unrelated domains. You can see that our Web Scanner caught this domain loaded as a resource on several different websites. In this instance, that means those returned domains are actually the compromised domains embedding this specific injector domain:
Our Web Search query revealed more than a dozen results
Also of note, the following files were loaded from this domain:
/1-197056a9.js
/763825
/cplnfwtlrkb.js
/tab-gtm.js
Opening any of these files will present the viewer with obfuscated code, as with the previous “recorder.js” file.
Our team examined which pages were loading these external files. It did not take long to see that three out of four pages we logged as loading code from cdn-cookie[.]com are clearly identifiable webshops. At the same time, one of the three webshops currently presents visitors with a rather interesting message that informs its customers about recent payment system issues, which was further confirmation that we were on the right track.
Webshops are especially prone to credit card skimming attacks, as seen here, where the four websites from our query are all from different vendors, on various infrastructure and in other countries, each loading strange, obfuscated code from a domain hosted on a known bulletproof host.
Next up in our investigation was an examination of the actively compromised website (at time of writing): hxxps[:]//colunexshop[.]com/. Pulling it up in our Web Resources data and using the hostname field as well as resource_hostname to check for any references to it, the results made it apparent that this site contacts the previously discovered malicious domain via the following file: “1-97056a9[.]js”
datasource = [“webresources”] AND resource_hostname = “*cdn-cookie[.]com*” AND hostname != “cdn-cookie[.]com”
Web Search of cdn-cookie[.]com
Opening the link in a web browser in a safe environment returned the following script:
Screenshot of the script observed in a safe environment
This page displays obfuscated JavaScript code, and the script’s analysis is provided below. Before we dive in, however, we want to first find out how the infected website loads the code in question. This can be done by analyzing the website via a Web Developer Console.
As referenced earlier, web skimmers aim to manipulate the payment process of a legitimate e-commerce website to steal credit card details. Due to this, many of them only initiate their injection process when the checkout page is accessed, and the payment process begins.
To identify where a web skimmer’s starting point may be, one can go through the normal steps of buying an item until reaching the “checkout” page, where a visitor is typically asked to enter their personal details and preferred payment method. The exact layout of this process varies by webshop; however, once we open the checkout page for colunexshop[.]com, we can see the expected web request to the file mentioned above, “1-97056a9[.]js”:
Malicious file callout on the checkout page for colunexshop[.]com
If we click on the “initiator” link, we can see the file that triggered the web request in our console. It even focuses on the piece of code that triggered the request in the larger file.
Screenshot in our console examining the initiator link that triggered the web request
In the case of colunexshop[.]com, the initiation of the request is done by a small piece of code in the file:
This code tries to imitate a Facebook-related code-loading script. However, it does a bad job of faking this, as no known Facebook script uses a list of character concatenations from a long string. An obfuscated code segment then creates a self-executing function that gets called with three arguments. These arguments are:
f = hxxps[:]//connect[.]facebook[.]net/en_US/fbevents.js (defanged by Silent Push)
b = window
e = teancmLodlErvNsipbxH925zfhuCR0M6yjZG4YS8TA1SIVGSJ4NoWBiMWEmXHr2zdhgcdNJChca11pvh0GtB17ExVpOu1onzFpd4rIx4mc7i2LXMrRSguok6z3xxdpph
Working our way through, this “e” argument is used regularly throughout the script. It serves as an alphabet used by the code to derive strings. For example, e[2] = a, e[8] = d, e[10] = E and so on. We can thus use it to deobfuscate the strings and derive the following code (comments added for clarity, with the last string shortened for brevity):
Example of the code strings
This code does not load the actual Facebook fbevents[.]js file; instead, it reaches out to a base64-obfuscated URL and injects the returned code. It can be seen in the script located at:
hxxps[:]//cdn-cookie[.]com/1-197056a9.js
Given that this code is highly obfuscated and loaded via a purposely obfuscated JavaScript, the red flags here are enough to know we are headed in the right direction.
This code is also loaded via the “wp_enqueue_scripts” functionality, as shown below, which is an action hook mechanism in WordPress that allows WordPress to load scripts and CSS at the proper time during the website’s rendering in the browser.
add_action('wp_enqueue_scripts', function () { echo '<code here>'; });
The action hook is ordinarily intended to run at the optimal time during page load to ensure that all relevant scripts and styles are included in the correct order, with proper dependency management, thereby preventing conflicts between themes and plugins.
However, this is not typically done by directly echoing JavaScript code, as is done here. The attacker’s improper use of the code actually results in a visible bug on the infected website, revealing that segment at the bottom of the page, as shown in the red box below:
Improper use of code results in a visible bug on the infected website
Despite this bug, the code as a whole indicates that this attacker has advanced knowledge of WordPress’s inner workings and integrates even lesser-known features into their attack chain.
Skimmer Analysis
In addition to being highly obfuscated, the code employs several techniques, including string concatenation, array-based string storage, self-executing anonymous functions, and other encodings.
Deobfuscation of the code reveals that, as expected, we encounter approximately 600 lines of JavaScript code implementing the credit card skimmer. The code is then split into several functions, each with functionality related to a larger attack.
The following is a step-by-step walkthrough from initial execution to the end goal of victim credential theft:
Screenshot of initial code executed by the web skimmer, establishing content monitoring and WordPress Admin evasion
The inject begins its execution by setting up a MutationObserver (a JavaScript API that provides the ability to detect modifications made to the Document Object Model (DOM) tree), which will execute the function “a()” every time the webpage’s DOM is changed.
The DOM is a tree-like representation of all HTML elements on a webpage that browsers create when loading a page. It’s essentially a live, interactive map where each HTML tag becomes a “node” that can be accessed, modified, or monitored by JavaScript. When users interact with the page (by clicking, typing, or loading content), the DOM changes in real-time.
This MutationObserver ensures that any change made to the website will cause the web skimmer to reattempt execution.
After starting the Observer, the “a()” function is executed a single time in what could be described as an independent initial execution attempt.
The code continues by executing a check for the Element “wpadminbar” in the current DOM, looking for the WordPress Admin Bar, which is a horizontal toolbar that appears at the top of WordPress websites when logged-in administrators or users with appropriate permissions are viewing the site. It provides quick access to standard WordPress functions, such as editing posts, managing users, accessing the dashboard, and viewing site statistics, without requiring navigation to the admin area.
If the wpadminbar element is defined in the DOM, the code will completely remove itself from the current DOM. It does so by removing any injected code and terminating the MutationObserver. This is done to evade the prying eyes of website administrators, increasing the chance of the malware’s survival.
The image below shows the “a()” function, which is called both on every DOM change and once initially.
Screenshot of the “a()” function
This function is designed to check if the website is prepared to execute the skimmer. It first checks to see if the page has loaded fully by looking for the WooCommerce “BlockUI” element. The BlockUI element is a native WooCommerce overlay (typically a semi-transparent div with a “Please wait…” message) that WooCommerce displays when it is processing checkout data, loading payment methods, or updating cart contents. It is intended to block user interaction until the complete page has been loaded successfully.
The presence of elements with the class blockUI in the DOM indicates that WooCommerce is still performing background operations. The skimmer code then waits 1000 ms (or one second) before re-execution.
Once the blockUI check is passed successfully, the code checks to see if the “Stripe” payment method was selected on the website. Notably, this indicates that the skimmer was specifically designed for the type of webshop it was injected into, as not all WooCommerce websites utilize Stripe.
If Stripe is selected, the skimmer checks to see if the fake payment form it will create is already loaded, which would indicate that a previous execution of the skimmer has already changed the page. It also checks to see if there is a “wc_cart_hash” element in the website’s localStorage.
The malware uses the localStorage variable “wc_cart_hash” to indicate whether it has already successfully skimmed a victim. It is set to be “true” for successful credit card exfiltration and serves as a re-execution prevention measure.
If the Stripe form hasn’t been injected yet, the visitor hasn’t chosen Stripe as their payment method, or an error occurs, then the malware re-runs “a()” every 500 ms.
The real web skimmer execution starts with the function “i()”. Since this function exceeds 500 lines of code, we will break it down into several steps.
Screenshot of the “i()” function
The “i” function first executes yet another check for the existence of the “wc-stripe-form.” If it does not exist but the “wc-stripe-upe-form” does, this means that the legitimate Stripe “Universal Payment Elements” form has loaded.
If this is the case, the skimmer gets to work. It makes sure that the legitimate Stripe Payment Form is hidden by setting its style.display variable to “none.” The skimmer then creates a malicious iframe in which it renders a fake Stripe Payment Form with legitimate-looking variable names, titles, styling, and so on. The iframe is then added to the legitimate container for the Stripe Payment method.
Screenshot of the web skimmer creating a malicious iframe
The code then continues by adding features that make the injected iframe responsive to changes in the website’s size, further enhancing its “legitimate” look and feel.
Next, it opens the iframe and writes a complete fake Stripe Payment Form into it. This particular payment form is in Portuguese, the same language as the compromised website. The HTML form contains three input fields with the IDs “cardnumber-Input,” “expiry-Input,” and “cvc-Input.”
At this point, the skimmer has effectively replaced the real payment form with its own malicious payment form, which, as previous code sections have already indicated, has the ID “wc-stripe-form.” Thereafter, all re-executions of the earlier “a()” function will fail because the fake form already exists.
With the fake form successfully injected, the skimmer then defines the logic to make the payment form appear functional. This includes adding script-based checks for “card brand” detection on input credit card numbers.
Providers that the script explicitly recognizes include:
Mastercard
American Express
JCB Co., Ltd.
Diners Club
Discover
UnionPay
Note: The companies listed here are the payment transaction providers themselves. This means that the skimmer most likely covers most issued credit cards globally, even if the card itself is branded by one’s local bank or payment card provider (Source: The Motley Fool)
The skimmer then uses this information to automatically adapt the input field with an image of the correct card brand, making the input form appear even more legitimate. The image below shows the changes for a Mastercard and a JCB card.
Screenshots of the skimmer showing branded images for Mastercard and JCB payment methods
Additional features added for the sake of legitimacy include:
Automatic formatting of the validity date entered
Automatic formatting of the entered credit card number according to the card’s brand
American Express: 4-6-4 and a 4-digit CVC
Diners Club: 4-6-4
Most other cards: 4-4-4-4
Automatic error highlighting in red if a field loses focus, but the entered details are invalid.
Verify the credit card number’s validity by ensuring it is associated with a recognized brand, not an unknown one, and has a length of at least 13 characters.
Check that the entered date is valid by ensuring its year is not in the past, at least five characters long, has a “/” separator, and contains a month between 1 and 12.
CVC is at least one character long
These checks are relatively simple compared to more advanced ones, like the Luhn algorithm.
Screenshot showing the malicious script features used to validate credit card fields
The styling and validation features are added to the three input fields via EventListeners.
After this step, the web skimmer monitors all input forms of the checkout page. It uses two state variables, “w” and “h”, to store even partial input data, as long as there are at least two characters.
Stolen data is not limited to just credit card details. Every input element on the website is collected, including the name, address, and shipping address fields.
Data is then stored as key-value pairs, where the input field’s ID serves as the key and the entered value becomes the corresponding value.
A correctly formatted value for “w”, after a victim has filled out the form, would then look like the following:
w = { "billing_first_name": "John", "billing_last_name": "Doe", "billing_email": "[email protected]", "billing_phone": "555-1234", "billing_address_1": "123 Main St", // ... etc }
Duplicate content would be in the “h” value.
The “w” value is never used after it is created and filled with the various values. The reason for that is unknown; however, it could be that “w” is simply a code artifact leftover from a previous version.
On the other hand, the “h” value is crucial for the exfiltration process. It is dynamically filled during the victim’s entire form-filling process. While the victim is filling out the payment data forms, the skimmer has additionally hijacked another feature of the payment site: the “Place Order” button.
The relevant code for this starts as:
Example of the relevant code
The code is designed to add an EventListener to a button that reacts to a click event. This event is the equivalent of the victim having finished filling out the entire web form, including the Stripe payment information, and wanting to submit the order. When clicked, the code executes and stores each checkout form’s value in a new set of variables, one field at a time.
It does this by first checking if the value for the field was previously captured by the dynamic data storage functionality that stores data into the “w” and “h” variables. In this case, the data stored in the “h” variable is used for the queried key.
Suppose the dynamic data parser fails to store the specific key-value pair queried. If that happens, the code will then fall back to using the value currently stored in the field, accessing it directly via the “getElementById()” function.
A more thorough check is done for the payment data values entered into the fake Stripe Payment Form, shown here:
The code checks for prior skimming execution against the current intended victim
This code explicitly checks to ensure there has been no prior skimming execution against the current victim by checking the local storage variable wc_cart_hash.
It then prevents the hijacked form’s default functionality and ensures that none of the three credit card data input fields are empty.
If any of the fields are empty, the empty fields are changed to throw the same red error styling that the previous checks applied in case any of the entered card data did not pass the value checks. This prompts a victim to correct the missing data issues before proceeding further.
If these checks are passed, the skimming code then prepares the collected data for exfiltration by creating a data object that contains all previously collected data.
An example of this can be seen here:
The skimming code creates a data object that contains the previously collected data
Some of the collected data is reformatted before exfiltration. For example, the first name and last name of the billing form are joined around a “ ” to create the space in a victim’s “Full Name.”
Once the data structure has been created, the skimmer moves to the actual exfiltration.
Screenshot of the skimmer moving to exfiltration
It begins by ensuring that the previously created data object is JSON-formatted, XOR-encrypted, and Base64-encoded using the hardcoded key “777.”
The skimmer then sends an HTTP POST request to the Exfiltration Server via the following URL:
hxxps[:]//lasorie[.]com/api/add
This URL is a base64-encoded data string prepended by “data=” as the body.
Once this request has been sent, the skimmer then cleans itself from the current checkout page, removing the fake payment form it had created previously.
Screenshot of the skimmer clearing itself from the checkout page
After that has been removed, it restores the legitimate Stripe input form, changing its display style back to “block.” Finally, it sets the localStorage variable “wc_cart_hash” to “true,” preventing the skimmer from being executed again for the current victim. It concludes by simulating a “click” on the actual checkout button to initiate the actual payment process.
Important note: As the victim entered their credit card details into a fake form instead of the real Stripe payment form, which was initially hidden by the skimmer when they initially filled it out, the payment page will display an error. This makes it appear as if the victim had simply entered their payment details incorrectly.
Most of the time, online shoppers are unaware that they have just been victimized. Instead, they will assume they made a mistake, then re-enter their credentials, and proceed as usual. The second payment attempt will then be processed successfully as they interact with the original benign payment form.
The only chance a non-technical victim would have to detect this attack would be noticing this error when trying to pay, and seeing that their information has disappeared after filling out the form.
The effectiveness of this is further reinforced by work shared by security researcher Mikhail Kasimov, who attributed several of these older domains to Magecart activity more than three years ago, demonstrating the threat actor’s staying power.
Indicators Of Future Attack™ (IOFA)™
The following are a small sample of the indicators gathered by our team for the Magecart network.
cdn-cookie[.]com
lasorie[.]com
Mitigation
Taking Defensive Measures Against Web Skimmer Campaigns
There are several defensive measures that both vendors and consumers can take to help protect themselves from web skimmer campaigns.
Defensive Measures for Vendors
Implement a Content Security Policy(CSP) to restrict the loading of external resources, particularly JavaScript, thereby reducing the risk of malicious code injection.
Comply with Payment Card Industry Data Security Standard (PCI DSS) Requirements. Following the PCI DSS standard helps ensure secure storage, processing, and transmission of cardholder and authentication data.
Keep Systems Up to Date. Regularly maintain software components, including content management system (CMS) platforms, plugins, and security patches, to minimize vulnerabilities that threat actors might exploit.
Enforce Strong Access Controls. Use complex, unique credentials for administrative accounts and enable multi-factor authentication to prevent unauthorized access.
Testing From the User Perspective. Website administrators should periodically review their sites using either their browser’s incognito/private mode or after clearing the browser cache and history. This practice is essential because many web injection-based threats employ detection mechanisms that identify administrative users through cookies and deliberately avoid executing malicious code in their presence. By viewing the site without administrative credentials or cached data, administrators can detect threats that would otherwise remain hidden.
Defensive Measures for Consumers
Shop on Trusted Platforms: Select established and reputable e-commerce websites with a proven track record of security.
Carefully Evaluate Offers: Be cautious of deals that appear excessively discounted or unrealistic, as these may indicate fraudulent sites or malicious vendors. When offers sound too good to be true, they probably are.
Monitor Financial Activity: Review bank and credit card statements regularly to promptly detect any unauthorized transactions.
Beware of Checkout Anomalies: If a payment page unexpectedly displays errors after entering your card details, consider abandoning the transaction and report the issue as suspicious.
Leverage Security Tools: Use browser or endpoint security solutions that block known malicious domains and scripts to enhance your online safety.
Ready to dive deeper into the world of preemptive cyber defense? Take our technology for a test drive with the free Silent Push Community Edition today.
Our team will continue to track Magecart campaigns while expanding our understanding of the obfuscations and skimmer variants being delivered throughout 2026.
We believe Magecart remains an active threat to both online stores and their customers worldwide, and expect this multi-year campaign to continue indefinitely.
If you or your organization has any information to share regarding the findings in this report, we would love to hear from you.
The DPRK remote worker program functions as a high-volume revenue engine for the North Korean regime. These state-sponsored operatives use stolen identities to secure remote roles within Western enterprises. They establish long-term persistence inside corporate infrastructure before their first meeting. These actors bypass standard IAM and EDR by mimicking the behavior, location, and hardware signatures of a domestic employee.
The Weaponization of Remote Onboarding
The Department of Justice and the FBI have issued urgent warnings regarding North Korean IT workers. These operatives use sophisticated identity theft to secure high-paying remote roles at Western enterprises.
These fake IT workers are strategic assets used to:
Generate untraceable revenue for prohibited weapons programs.
Gain administrative access to sensitive codebases.
Establish “living off the land” persistence within corporate infrastructure.
The “Invisible Insider” scheme: How fake IT workers from DPRK are bypassing existing security controls
The Two Variants of the DPRK “Invisible Insider”
Based on recent research, the DPRK typically utilizes two distinct variants of this infiltration:
Variant 1: The long term infiltrator: This is an IT worker who secures a legitimate role to earn a salary or gain administrative access. They may perform their job for months without spreading malware, focusing instead on revenue generation and establishing long term persistence within your infrastructure.
Variant 2: The front company lure: The regime creates fake front companies that mimic real software firms to lure high value victims into interviews. These interviews involve skill assessments that eventually lead to the victim executing malicious code. This puts the entire company at risk of a breach, turning a standard hiring interaction into a systemic threat through calculated deception.
Applicants frequently seek new opportunities while still employed. Our analyst team has observed instances where candidates inadvertently compromise their current employer’s security by using corporate devices for job-seeking activities, leading to malware infections.
The Identity Verification Trap
Traditional security stacks verify who a person is based on their credentials. If a worker provides a valid Social Security Number, passes a third-party background check, and clears a video interview using AI-driven deepfake filters, they are into your system.
Suspected fake persona: Mehmet Demir hxxps://linkedin[.]com/in/mehmet-demir-godev Backend Developer | Golang, Python
Once onboarded, your logs show a “local” employee. They use Western residential IP addresses to appear as though they are working from a suburban home.
Why Geographic Certainty is Fading
Security teams often rely on IP geolocation to flag suspicious logins. While geofencing does catch many low level attempts, the public is often unaware of which specific IPs or providers the DPRK is currently leveraging. Through our research, we constantly discover new IPs and new VPN or proxy providers that these state-sponsored actors use to stay hidden.
To defeat advanced geofencing, the DPRK utilizes a multi layered proxy chain. By routing traffic through a domestic “hop” (i.e., a physical laptop inside the US) the worker bypasses simple geo-fencing. To your SIEM, the traffic looks identical to a standard remote employee.
This creates three critical visibility gaps:
The residential IP fallacy: You trust the traffic because it originates from a standard ISP like Comcast or AT&T rather than a datacenter.
The background check gap: Providers verify the stolen identity, not the person behind the keyboard.
The hardware authenticity trap: Unlike botnets using virtual machines, these “laptop farms” use real hardware. They pass MAC address checks and device posture assessments.
The Cost of a “Bad Hire”
Discovery of a DPRK operative on your payroll involves more than a simple termination:
Sanctions risks
Your company may be in violation of OFAC regulations for inadvertently funding a sanctioned regime.
Intellectual property lost
By the time state-sponsored actors are caught, proprietary code or customer data is likely already exfiltrated.
Incident response burnout
Cleaning up backdoors left by a state-sponsored operative requires a total infrastructure audit.
Secure Your Hiring Perimeter
When state-sponsored actors use stolen identities and spoofed locations, background checks are not enough to protect your organization. You need to verify that remote employees are physically located where they claim to be.
Silent Push Traffic Origin unmasks the deceptive network paths used by these operatives to hide their true location. We help you spot the residential proxies and suspicious connection patterns that state sponsored groups use to bypass traditional geofencing. This allows you to identify high risk infrastructure before a new hire is granted access to your sensitive systems.
Most of us in cybersecurity have fallen into a bit of a trap. We have been taught to defend our networks by looking at the past. We rely on Indicators of Compromise (IOCs). These are things like malicious IPs or file hashes. Using them as a primary defense is not really a strategy. It is just playing catch-up.
An IOC is a record of a crime that has already happened. By the time it shows up on your screen, you are already “right of boom.” You are struggling to clean up a mess while the attacker has already achieved what they wanted. It is forensics, not defense.
The first victim problem
I have spent years seeing people deploy and then rip out overhyped technologies that promised the world and delivered nothing. IOC-based security is a bit like that. It is a reactive cycle that is actually quite grim when you look at it. For a piece of intelligence to exist in that model, someone else has to get hit first. A domain only becomes an indicator after it has been used to successfully strike a company.
While we wait for these lists of “known bad” assets to update, criminals are using automation to spin up new infrastructure in seconds. They use techniques like fast flux to rotate IPs or hide their intent behind big providers like AWS and Azure. Most security tools are essentially blind to the majority of what these groups are doing.
Why we do the hard work
When John Jensen and I built Silent Push, we knew we had to stop looking at what happened and start looking at what is being built. To do that properly, you cannot rely on third-party feeds or recycled data. You have to manage the collection and contextualization of the data yourself.
We took on the task of setting up the most aggressive data collection platform to monitor all internet infrastructure and its changing relationships as it is the only way to get an unadulterated view of the world. We do not wait for a threat actor to hit someone. We look for the fingerprints they leave behind while they are still in the staging phase.
Finding the fingerprints
I like to think of the current cyber crime landscape like the era of privateers. These groups have a subtle nod from their home government to commit crimes as long as the money comes home and there are no domestic victims. But they are creatures of habit. They leave signatures in their DNS records and the way they configure their web servers.
By tracking all internet signals in one place, we can see an attack being prepared. We spot the “activation” events where a parked domain suddenly switches over to an attacker-controlled server. This gives us what we call Indicators of Future Attack (IOFA). On average, this approach provides a lead time of 104 days. That is months of warning before a strike is even launched.
No more guesswork (it’s possible)
I have no time for tools that give you “maybe suspicious” alerts or vague probability scores. That just leads to alert fatigue and burns out your team. The focus has to be on deterministic data. It is either attacker infrastructure or it is not.
When you have that level of clarity, you do not have to guess. You see the threat actor’s intent as it is being organized and you shut it down. It is about moving away from the “first victim” model and finally staying one step ahead of them.
![Silent Push Total View of IP address 103.28.36[.]105](https://www.silentpush.com/wp-content/uploads/sysbc-image-10-total-view-screenshot.png)
![Silent Push Total View of domain phutho.duchop[.]gov[.]vn](https://www.silentpush.com/wp-content/uploads/sysbc-image-11-phuto-total-view.png)
![Screenshot of phutho.duchop[.]gov[.]vn website](https://www.silentpush.com/wp-content/uploads/sysbc-image-12-phuto-site.png)
![Screenshot of IP address 196.13.207[.]92 revealing ties to the Burkina Faso government](https://www.silentpush.com/wp-content/uploads/sysbc-image-13-table-burkina-faso.png)
![Screenshot of concours[.]gov[.]bf website](https://www.silentpush.com/wp-content/uploads/sysbc-image-14-concours-bf.png)
![Screenshot of 202.142.184[.]234 on VirusTotal](https://www.silentpush.com/wp-content/uploads/sysbc-image-15-202-142-184-234.png)
![Screenshot of 148.113.208[.]227 on VirusTotal](https://www.silentpush.com/wp-content/uploads/sysbc-image-16-148-113-208-227.png)
![Screenshot of 103.112.211[.]167 on VirusTotal](https://www.silentpush.com/wp-content/uploads/sysbc-image-17-103-112-211-167.png)
![Total View image of cdn-cookie[.]com](https://www.silentpush.com/wp-content/uploads/mage-2-cdn-cookie-total-view-scaled.jpeg)
![Screenshot of the Web Search for cdn-cookie[.]com](https://www.silentpush.com/wp-content/uploads/mage-3-datasource-hostname-scaled.jpeg)
![Screenshot of colunexshop[.]com code](https://www.silentpush.com/wp-content/uploads/mage-6-colunexshop-com-code.jpg)
