Every industrial organisation now lets someone in from the outside — OEM vendors, system integrators, remote engineers. How they get in determines whether a plant’s biggest convenience becomes its biggest breach path. 

Remote Access Has Become OT’s Biggest Front Door 

Operational technology (OT) environments were designed to be isolated. IT/OT convergence ended that: industrial control systems (ICS), SCADA servers, PLCs, and HMIs are now reachable across networks because efficiency, analytics, and remote maintenance demand it. 

That maintenance is rarely done by the plant’s own staff alone. OEMs service their turbines and robots under warranty, system integrators tune SCADA applications, and in-house engineers troubleshoot from home at 2 a.m.

Third-party remote access is no longer an exception granted reluctantly it is a permanent operating requirement of modern industrial environments. 

It is also the front door attackers prefer. Remote access pathways leaked VPN credentials, exposed remote desktop services, vendor connections have featured repeatedly in major industrial intrusions.

And in OT, the stakes are not confined to data: a compromised session can reach equipment whose failure affects production, the environment, and human safety. 

Why OT Environments Can’t Be Secured Like IT 

OT security inverts the priorities IT teams grew up with. Availability and safety outrank confidentiality: an outage or an unsafe state is the disaster, not the leak. 

The equipment reflects that. Industrial assets run on 15-to-25-year lifecycles, often on operating systems past end of support, controlled by devices fragile enough that an ordinary vulnerability scan can crash them.

Patch windows arrive a few times a year, if at all. 

Segmentation frameworks such as the Purdue model respond by structuring plants into zones connected through tightly controlled conduits.

But when patching can’t keep pace and the internals of a zone stay flat, one control matters above all others: deciding precisely who can reach what, over which protocol, for how long.

That is why remote access design not another perimeter appliance has become the defining OT security decision. 

Why VPNs Fall Short for OT Remote Access 

The VPN was built to answer a different question: “how do we put a trusted employee onto the corporate network?” Applied to OT, it answers it far too generously. 

A VPN grants a network location, not a task. Once the tunnel is up, the remote laptop holds a routable path into the zone it lands in and everything reachable from there.

Vendors often share a single account, sessions run over standing tunnels that exist around the clock, nothing is recorded, and an unmanaged contractor laptop can bridge the open internet to the plant floor in one hop. 

The concentrator itself compounds the problem. VPN appliances are, by design, internet-exposed and edge-device vulnerabilities have become one of the most heavily exploited categories in recent years, with attackers mass-scanning for unpatched gateways.

Every inbound port opened for remote maintenance is a firewall exception that quietly undermines the zone-and-conduit segmentation the Purdue model prescribes.

Jump servers soften the blast radius but bring their own sprawl: more credentials to manage, more systems to patch, and still no per-asset authorisation. 

WEBINAR SPOTLIGHT:

OT Remote Access: VPN-less, Controlled, Secure — BeyondTrust’s APJ Tech Talk shows this architecture live: brokered, recorded, asset-level sessions into OT environments with no VPN in the chain.  Reserve your seat here → 

What VPN-less OT Remote Access Actually Means 

VPN-less remote access replaces the tunnel with a broker. Lightweight connectors inside each zone dial outbound over TLS to an access gateway; the remote engineer or vendor reaches that same gateway from a browser.

No inbound firewall rules are created, no ports are exposed, and at no point does a routable network path exist between the remote device and the industrial asset. 

Sessions are protocol-isolated: RDP, SSH, VNC, or an HMI’s web console is rendered through the gateway, so screen output and keystrokes cross the boundary — not raw packets from an untrusted laptop. 

Authorisation is identity-based and per-asset: a vendor is approved for one PLC, one engineering workstation, one time window, under just-in-time policies rather than standing entitlements. 

Credential handling changes just as fundamentally. OT account passwords stay in a vault and are injected into the session by the broker the third party authenticates as themselves, with multi-factor authentication (MFA), and never sees or holds the asset credential at all.

Every session is monitored live, recordable end to end, and terminable in one click. This is zero trust applied to industrial connectivity: never trust a network location; verify an identity, for one asset, every time. 

This is the architecture behind BeyondTrust Privileged Remote Access (PRA), already running in industrial environments where a vendor session that once meant a standing VPN tunnel is now a single brokered, recorded connection to one asset.

Global flavour-and-fragrance manufacturer MANE adopted this approach across its plant environments see how in the case study. 

Inside a Controlled OT Session 

The lifecycle above is what “controlled” means in practice. Access is requested for an asset, never for a network. Identity is verified with MFA before anything connects. The asset owner approves a bounded window.

The broker builds the session, injecting vaulted credentials. Operations teams watch or record everything that happens, and when the window closes, access simply ceases to exist leaving an audit trail instead of an open tunnel. 

Want to see each of these six stages demonstrated against a live environment? The BeyondTrust APJ Tech Talk walks through the full workflow, from vendor request to audit evidence — register here. 

Prefer three minutes right now over a full session? Watch Secure OT Environments with Privileged Remote Access for a short walkthrough of the same brokered-session model. 

FREE ASSESSMENT:

Operational Technology (OT) Cybersecurity Assessment — find out where your own remote access setup stands against the checklist below before you finish reading it. Take the free assessment → 

Mapping VPN-less Access to IEC 62443, NERC CIP, and NIS2 

Controlled remote access is also what the frameworks keep asking for. In IEC 62443 terms, a broker is an enforced conduit between zones implementing identification and authentication control, use control, and logging at exactly the boundary the standard cares about.

NERC CIP requires interactive remote access to pass through an intermediate system with multi-factor authentication and encryption, and expects utilities to know and control vendor remote access as part of supply-chain risk management.

NIS2 pushes the same direction across European critical infrastructure: demonstrable access control, privileged account management, and supply-chain security.

A recorded, time-bound, per-asset session model produces the evidence all three demand something a shared VPN account never will. 

For a clause-by-clause mapping of session controls to utility compliance requirements, see BeyondTrust’s NERC CIP Alignment guide. 

An Evaluation Checklist for OT Remote Access 

Whatever platform you evaluate, hold it to six requirements: 

• Outbound-only architecture — no inbound firewall rules, no exposed ports, no routable path from remote device to asset. 

• Per-asset least privilege — authorisation scoped to individual systems with just-in-time, time-bound windows. 

• Identity-first authentication — MFA and directory integration for employees and third parties alike. 

• Credential vaulting and injection — vendors never see, hold, or reuse OT passwords. 

• Session monitoring, recording, and termination — live oversight with an instant kill switch. 

• Framework-mapped reporting — audit evidence aligned to IEC 62443, NERC CIP, and NIS2. 

A product that cannot meet these is not an OT remote access solution — it is a VPN with better marketing. 

TALK TO AN EXPERT 

Get a Second Opinion on Your OT Remote Access Setup Talk through your specific ICS/SCADA footprint, vendor access model, and compliance requirements with a BeyondTrust OT security expert — no webinar slot required. Talk to an expert → 

FAQ: OT Remote Access 

Is a VPN safe for OT remote access? 

Not by modern standards. A VPN provides standing, network-level access, exposes an internet-facing appliance that attackers actively scan for, and offers no per-asset authorisation or session recording. For third-party access to industrial systems, it should be treated as a legacy pattern. 

What replaces the VPN in OT environments? 

Identity-based, brokered remote access — often called secure or privileged remote access, or zero trust network access for OT. Connections are outbound-only, protocol-isolated, scoped to single assets, time-bound, and fully recorded. 

BeyondTrust Privileged Remote Access (PRA) is built specifically for this model. 

Does VPN-less remote access align with IEC 62443? 

Yes. A brokered session model implements the standard’s zone-and-conduit architecture, its identification and authentication requirements, and its use-control expectations, while generating the audit evidence assessors ask for. 

The Bottom Line 

Remote access to OT is permanent; the tunnel doesn’t have to be. The organisations securing industrial environments most effectively are replacing network-level trust with identity-level control standing tunnels with just-in-time sessions, invisible activity with recorded evidence.

The technology to do it without slowing a single vendor or engineer already exists. 

See it for yourself: Register for the APJ Tech Talk · Take the Free OT Assessment · Talk to an Expert 

The post VPN Is the Biggest Backdoor Into Your Plant — Here’s What Should Replace It on Your OT Network    appeared first on Cyber Security News.

Researchers tie the LinX Coders phishing-as-a-service toolkit to 9,332 compromise events across 94 countries, with 63.7% of victims in the United States and stolen session cookies accounting for more than half of all outcomes.

A phishing-as-a-service (PhaaS) toolkit tracked as Mirage2FA has been linked to the potential compromise of 4,532 Microsoft 365 accounts in a campaign that targeted 3,518 organizations, according to new research published by threat intelligence analysts ShiFu and raptur3 at ANY.RUN.

The kit does not drop malware. Instead, it uses browser-executed HTML, XHTML, and SVG attachments to funnel victims to a fake Microsoft login page backed by an adversary-in-the-middle (AiTM) reverse proxy.

The proxy relays the username, password, and one-time 2FA code to Microsoft in real time and captures the authenticated session cookie that comes back, letting the attacker enter the account without ever typing a password or completing MFA again.

Nearly Half of Targeted Accounts Were Potentially Compromised

ANY.RUN’s telemetry shows the campaign reached 9,426 unique email addresses, and roughly 48% of them were potentially compromised.

Victim activity was logged in 94 countries, but the United States dominates with 2,885 victims, or 63.7% of the total, far ahead of India (5.1%), Singapore (4.1%), the United Kingdom (1.7%), and Canada (1.7%).

Technology companies were hit hardest at 19.2% of victims, followed by manufacturing (11.1%), education (9.9%), consulting (8.3%), telecommunications (6.6%), healthcare (5.4%), and finance (3.1%).

MSSPs also feature among the most affected sectors, a detail that matters because a single compromised provider account can expose the customers it manages.

The operator has been active since at least September 2024, but the tempo changed in 2026.

Sandbox detections began a steady climb in March, and July alone produced 445 Mirage2FA sessions in ANY.RUN’s Interactive Sandbox with the month only partially recorded, out of 1,249 sessions analyzed in total.

Session Cookies Make Up More Than Half of All Thefts

Of the 9,332 compromise events recorded, 4,561 (51%) involved the theft of an authenticated session cookie, affecting 2,541 unique victims.

Another 3,044 events (34%) captured a password together with a 2FA code, 1,339 (15%) were single sign-on logins, and 388 fell into other categories.

The dominance of cookie theft changes the incident response math. Because the attacker holds a valid session rather than just a password, a password reset does not evict them.

Mirage2FA stores the stolen cookies as Base64-encoded .txt dumps on its operator panel, ready to be replayed against Microsoft 365, SSO-connected applications, and internal workflows.

One in three successful login events (33.3%) came from mobile devices, where users have fewer visual cues to spot a phishing page.

The business impact reaches well beyond the mailbox. A hijacked identity gives the attacker trusted access to connected cloud services, enables fraud against employees, customers, and suppliers, and widens the blast radius to every SSO-connected application, while containment costs rise because a credential reset alone no longer closes the door.

The Full Attack Chain: From Attachment to Account Takeover

The attack begins with a phishing email, frequently themed around HR notices or 401(k) benefit updates and sent in volume through Amazon SES (MITRE ATT&CK T1566.001/.002).

The message carries a .htm, .xhtml, or .svg attachment, or a QR code that pushes the victim to open the phishing link on a phone.

When the victim opens the file, the browser runs an embedded stager (T1204.002). The stager carries a per-recipient token, the victim’s email address Base64-encoded into a placeholder named LINXB64EMAIL, and fetches the harvesting logic from a remote loader using a URL of the form /xls/<token>.js (T1105).

In ANY.RUN’s sandbox, the attachment first shows a “Verify you’re human” slider before loading a Microsoft-branded password prompt with the victim’s email already filled in.

Behind the page, the browser pulls the loader from user.cheacker[.]store, opens a WebSocket to the command-and-control server, posts to an xwps.php handler on a second domain, and queries api.ipify.org to fingerprint the victim’s IP address.

The credentials and 2FA code are relayed to the legitimate Microsoft service over that WebSocket channel (T1557, T1111).

Once Microsoft accepts them, the proxy receives a valid authenticated session, which is exfiltrated along with the credentials (T1539) and reused to read mail and impersonate the user (T1071.001).

Across the 1,249 sandbox sessions, the dominant behaviors were phishing, obfuscated JavaScript execution, WebSocket activity tied to the AiTM channel, IP and browser fingerprinting, QR-code delivery, and Amazon SES activity.

Six Stager Variants, Zero Binary Malware

ANY.RUN catalogued 629 .htm samples (453 of them obfuscated), 198 XHTML samples (31 obfuscated), and 187 SVG samples (12 obfuscated).

The plain .htm variant is a two-line stub that sets a uid token and pulls /api/xls/a1p2i.js from the kit’s domain.

The non-obfuscated XHTML version builds a full-screen iframe, writes a document into it, and injects the same a1p2i.js loader, reading the token from a ?ref= parameter.

Its obfuscated counterpart hides the logic behind a hex-to-string decoder, rsy(), and reads the token from ?sdv= or the URL fragment.

The obfuscated .htm variant is self-contained: it Base64-decodes a blob, XORs every byte with 0xAD (173), and passes the result to eval().

SVG files abuse the <script> element in a standalone SVG document to send the browser straight to the phishing URL with the token in the query string.

A dozen samples wrap that redirect in an obfuscator.io-style string-array decoder to hide the destination.

Infrastructure Points to a Single Operator: LinX Coders

The loader and C2 traffic resolve to 185.174.100.224 on AS-Colocrossing, which serves domains including user.cheacker[.]store, hvr.volatilesour[.]store, ver.bandhiem[.]com, and pynutech[.]store.

Loader requests follow a fixed structure, https://<host>/<3-letter-code>/xls/<token>.js, with routing codes such as api, ulr, eor, pxk, dsk, and tsk and token suffixes c2v or cpt. Pivoting on that pattern in ANY.RUN’s Threat Intelligence Lookup surfaced dozens of related loader URLs on the same IP address.

The researchers attribute the kit to a group branding itself LinX Coders. The evidence includes the LINXCODERSEMAIL substitution placeholder, Telegram bots named linxlogsss…bot and linxxlogss…bot, a channel called LinXcoded that advertises a “LinX Sender,” a “2FA Cookies Attachment/Link,” and a “LinXMail Token Link App,” and operator test messages sent from IP addresses in the same 185.174.100.0/24 subnet as the production C2.

Build markers evolved from LINXCODERSEMAIL to LINXEMAIL to LINXB64EMAIL, and the most recent operator test, a login using the password linxz, was logged on July 3, 2026.

The analysts caution that the IP and geolocation data comes from the panel’s own logging and could reflect VPN use or spoofing; the stronger signal is the reuse of the same addresses across multiple bots and their subnet overlap with infrastructure ANY.RUN observed independently.

A single bot ID also ties the 2024–2025 test messages to the 2026 lure activity. Over that period the kit moved from plain loaders to XOR, hex, and obfuscator.io wrappers, added new /xls/ routes and token variants, and rotated its domains.

What Defenders Should Do

ANY.RUN recommends blocking or quarantining .htm, .xhtml, and .svg attachments at the mail gateway, adding detections for HTML smuggling and obfuscated JavaScript, and scrutinizing QR-code lures and mail arriving via Amazon SES.

High-risk users, including administrators, executives, and finance teams, should move to phishing-resistant MFA such as FIDO2/WebAuthn keys or passkeys, backed by shorter session lifetimes, token binding, and Continuous Access Evaluation in Microsoft Entra ID.

For hunting, the report highlights patterns that outlive any single domain:

• Loader requests matching /[a-z]{3}/xls/[a-z0-9]+(?:c2v|cpt)?\.js, with /api/xls/a1p2i.js as the canonical endpoint
• DNS queries where a Base64-encoded email address appears as the subdomain label of cheacker[.]store
• An outbound WebSocket connection to an unknown host immediately after a JavaScript loader fetch
• HTML attachments containing atob(…).map(x => x.charCodeAt(0) ^ 173) followed by eval(…)
• SVG documents with an inline <script type=”application/ecmascript”> that performs a window.location redirect
• LINX* placeholder strings and in-page variables such as uid, self.u, and RSTRING2

When session theft is confirmed, ANY.RUN advises treating it as an identity incident rather than a credential reset: revoke all active sessions and tokens, review Microsoft 365 mail-forwarding rules and OAuth grants, and audit every action taken through the compromised identity.

Indicators of Compromise (Selection)

The full report includes the complete list of more than 60 phishing domains and 21 operator testing IP addresses.

The post Mirage2FA Phishing Kit Bypasses MFA to Hijack Microsoft 365 Sessions, Targeting 3,500+ Organizations appeared first on Cyber Security News.

Threat intelligence (TI) feeds are expected to close visibility gaps that inevitably emerge in enterprise SOCs and make investigations faster and more effective.

This promise sounds particularly attractive to leaders of growing SOC teams that need to face an increasing alert number without constantly hiring more analysts. 

In reality, threat intelligence doesn’t always deliver what vendors promise. Here are three reasons this expectation-reality gap emerges, and how to avoid disappointment by setting clear standards for TI feeds. 

Reason 1: Indicators Without Context Don’t Accelerate Decisions 

One of the primary purposes of threat intelligence is to help analysts determine what deserves immediate attention. In other words, to prioritize alerts according to the context surrounding them. When that context is missing, investigations stall. 

A SOC detects a hash in the system and a matching malicious indicator in its threat intelligence feed. Now they know that an object has been classified as malicious. But TI’s job isn’t done here. The investigation only just begun: the analysts still require context. 

If the feed doesn’t provide it right away, they have to pivot across threat intelligence portals and other external tools, manually getting to the bottom of why the indicator is classified as malicious, what malware behind it does, and how all this relates to their own infrastructure. 

The same indicator can also represent different levels of risk depending on the organization and its attack surface. Without enough context to make fast, defensible decisions, TI creates operational friction instead of reducing it. 

For faster SOC action, choose ANY.RUN TI Feeds. Automate alert enrichment with high-confidence threat data and behavioral context from 16K+ companies. Explore TI Feeds.

Reason 2: Threat Intelligence Loses Value Quickly 

The second expectation is timeliness. Adversary infrastructure changes, gets repurposed, and reassigned extremely quickly. As a result, many IOCs have a surprisingly short operational lifetime.

If TI vendors don’t accelerate their pipelines to match this speed, the data quickly loses value. 

Stale intelligence has another consequence: false positives. When analysts repeatedly investigate matches that turn out to be outdated, irrelevant, or otherwise low-value, this affects their trust in the source. They may even start to ignore more of the source’s alerts, including important ones. 

Reason 3: Connected Doesn’t Mean Useful 

Threat intelligence should ultimately save resources. Integration enables SOCs to automate enrichment and triage, allowing analysts to process more security events without requiring headcount to scale as much. 

Simply connecting a feed to the security stack does not guarantee that outcome: connected doesn’t always mean useful. SOCs still need to decide how to prioritize, validate, and act on the intelligence they receive. 

There might also be a broader management issue behind disappointment in threat intelligence acquisition: organizations do not always define what success should look like before purchasing or integrating a feed. 

Without clear objectives, it becomes difficult to measure its operational impact or ROI.  

How to Make Threat Intelligence Feeds Meet SOC Expectations 

The problems discussed above show that the value of a TI feed is determined by fresh, accurate, contextualized, and easy to apply in day-to-day SOC operations. 

ANY.RUN Threat Intelligence Feeds are built with these challenges in mind, solving them at all stages, from data aggregation to delivering threat data to SIEM, EDR/XDR, TIP, NDR systems via STIX/TAXII. 

Instead of collecting large volumes of unverified indicators, TI Feeds deliver threat data generated from real malware investigations conducted in the ANY.RUN sandbox by over 16,000 SOC teams, filtered to reduce false positives to a near-zero rate.

This gives analysts timely, high-confidence IOCs backed by behavioral, cross-industry evidence they can use to investigate and prioritize threats. 

Fresh indicators help teams identify emerging threats sooner, sandbox verification reduces unnecessary noise, and behavioral context gives analysts the evidence they need to understand what is happening without rebuilding every investigation from scratch.

Broad integrations help SOC teams put this intelligence to use within their existing security workflows. 

For SOC teams, this means TI can fulfill the role it was intended for: accelerating triage, improving prioritization, reducing repetitive investigation work, and helping analysts respond to real threats faster. 

See how ANY.RUN Threat Intelligence Feeds can strengthen your SOC operations and start working with actionable, investigation-ready threat data from 16K+ SOCs -> Integrate TI Feeds 

Conclusion 

Effective threat intelligence feeds should do more than deliver large volumes of IOCs. To create real value for a SOC, threat intelligence needs to be timely, accurate, contextualized, and easy to operationalize.

When these requirements are met, TI can reduce alert noise, speed up investigations, improve threat prioritization, and help security teams respond to real threats faster. 

The post Why Threat Intelligence Feeds Often Fail to Meet SOC Expectations  appeared first on Cyber Security News.

Global malware activity climbed sharply over the past week, with remote access trojans (RATs), information stealers, and loaders all posting significant week-over-week gains, according to threat sample uploads tracked by ANY.RUN.

AsyncRAT topped the chart with 211 uploads, edging out Remcos at 196 and Xworm at 183. This trend signals that RAT-based intrusions remain the dominant tactic for cybercriminals seeking persistent, hands-on-keyboard access to compromised Windows systems.

AsyncRAT held the number one position with 211 total uploads and a modest weekly increase of two samples, reflecting its status as one of the most consistently deployed .NET-based remote access trojans in the current threat landscape. The malware is typically delivered through phishing email attacks containing malicious attachments or links.

Once installed, it grants attackers full remote command execution, keylogging, screen capture, and data exfiltration capabilities.

Recent campaigns have shown AsyncRAT operators abusing trusted cloud infrastructure such as Cloudflare’s free-tier services and TryCloudflare tunnels to host payload delivery servers, making detection significantly harder for conventional security tools.

Top 10 Malware Threats of the Week

Remcos RAT recorded the largest single gain among the top three, rising by 59 samples to reach 196 total uploads, underscoring an intensifying wave of espionage and surveillance-driven campaigns.

Originally marketed as a legitimate remote administration tool, Remcos has evolved into a favored espionage and credential-theft platform for both cybercriminals and initial access brokers.

Newer variants observed in early 2026 have shifted toward real-time surveillance, streaming live webcam footage and transmitting keystrokes instantly rather than waiting to exfiltrate stored data, effectively turning infected machines into live monitoring feeds for attackers.

Xworm followed closely with 183 uploads and a gain of 16, continuing its reputation as a highly adaptable, modular RAT sold through malware-as-a-service channels.

Recent Xworm campaigns have leveraged multiple file formats and scripting languages, including PowerShell, VBS, HTA, and Office macro exploits such as CVE-2018-0802, to stage payloads and evade endpoint defenses.

Beyond typical RAT functions like keylogging and webcam access, newer Xworm builds also incorporate destructive capabilities to deploy stealthy infostealer payloads, file encryption, and distributed denial-of-service (DDoS) features.

AgentTesla ranked fourth with 172 uploads and a sharp 51-sample increase, reaffirming its long-standing role as one of the most prolific credential-stealing Trojans in circulation.

Close behind, Stealc posted the single largest weekly jump of the entire list, up 67 samples to reach 159 total uploads, followed by Vidar at 157 with a smaller rise of six.

Both are widely used information stealers designed to harvest browser credentials, cryptocurrency wallet data, and session tokens from infected endpoints.

As detailed in the weekly threat metrics published in the ANY.RUN malware analysis, DonutLoader climbed 16 samples to 140 uploads, reflecting its growing role as a delivery mechanism for secondary payloads, while Lumma stealer rose 27 samples to 126. Formbook rounded out the mid-tier with 97 uploads, up 21 for the week.

Snake was the only family among the top ten to decline, dropping two samples to close the week at 93 total uploads, a modest but notable exception amid an otherwise broad surge across nearly every major malware category.

Security teams are advised to prioritize detection rules for phishing-based delivery chains, monitor for anomalous PowerShell and HTA execution, and flag traffic to known Remcos, AsyncRAT, and Xworm command-and-control infrastructure to blunt the impact of this activity spike.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.

The post Top 10 Malware Threats of the Week – AsyncRAT, Remcos, and Xworm Lead the Surge appeared first on Cyber Security News.