Today's picture
Microsoft issued a formal warning about a documented attack pattern that uses the Teams external collaboration feature to impersonate IT helpdesk staff, walk employees through handing over remote access, and then move across the network using tools that look indistinguishable from legitimate IT activity. No malware, no exploits. Just a conversation and a trusted application. Separately, researchers disclosed 22 vulnerabilities in serial-to-IP converters from Lantronix and Silex, with roughly 20,000 of these devices exposed on the internet, many of them sitting in front of industrial control systems.
Threat snapshot
2 new · 3 monitoring
New
Threat Intel
Attackers impersonating IT helpdesk in Teams external chats. No exploit needed. Just a conversation.
External Teams chat to employee. Fake helpdesk role. Quick Assist for remote access. WinRM for lateral movement. Rclone for exfiltration. Each step looks like normal IT work.
New
OT Risk
BRIDGE:BREAK discloses 22 vulnerabilities in serial-to-IP converters. 20,000 exposed devices online.
Lantronix and Silex devices used to bridge legacy industrial systems to IP networks. Flaws allow full device takeover. Most organizations do not know these devices exist on their network.
Monitoring
Defender RedSun and UnDefend. No patch. Moves to monitoring this issue.
Seven days without a patch. Still exploited in the wild. Detection via signature update timestamps remains the only reliable early indicator.
Detailed intelligence
Full analysis
01 New Threat Intel
Attackers impersonating IT helpdesk staff through Teams external chats. No exploit required.
Microsoft Advisory
What happened
Microsoft published a warning about a documented and recurring attack pattern where threat actors use the external collaboration feature in Microsoft Teams to initiate conversations with enterprise employees, presenting themselves as internal IT support or helpdesk staff. The tactic exploits the fact that Teams allows cross-tenant messaging by default, meaning anyone with a Microsoft account can reach employees at other organizations unless the receiving organization has restricted this.
The attack chain Microsoft observed follows a consistent playbook. An employee receives a Teams message from what appears to be internal IT support, often citing a security issue, expired password, or pending update requiring assistance. The attacker guides the employee into opening a Quick Assist remote session, handing over direct control of the machine. From there, the attacker performs reconnaissance using Command Prompt and PowerShell, checks privileges and network reachability, then drops a payload bundle in user-writable directories such as ProgramData. The payload executes by sideloading a malicious DLL through a trusted, signed application including Autodesk, Adobe Reader, or Windows Error Reporting, so the process tree looks legitimate. Command and control communication runs over HTTPS and blends into normal traffic. Lateral movement uses Windows Remote Management to reach domain-joined systems and domain controllers. Data exfiltration uses Rclone to transfer filtered, high-value files to external cloud storage.
Microsoft's incident response team confirmed at least one real-world case where this chain ran to completion. The entire campaign relies on no software vulnerabilities. Every step uses legitimate tools and user-approved actions.
CyberSip Take
The reason this pattern keeps working is that it exploits a reasonable assumption: if someone contacts you on Teams, they probably work at your company or at a trusted partner. That assumption is wrong by default because Teams external collaboration is on unless you turn it off. An attacker only needs a Microsoft account and your employee's name to initiate a convincing conversation.
What makes this harder to detect than typical phishing is that each individual action in the chain is legitimate. An employee opening Quick Assist for IT support is not suspicious behavior. WinRM being used to manage Windows systems is not suspicious behavior. Rclone moving data to cloud storage is not suspicious by itself. The compromise only becomes visible when you look at the sequence: external Teams contact, then remote access, then privilege checks, then lateral movement. That requires behavioral detection and correlation across tools, not just signature matching on any individual event.
There are two immediate and practical mitigations worth taking today. First, review your Teams external access settings and consider restricting inbound external chat to approved domains only rather than allowing any Microsoft account. Second, run a test: ask five employees what they would do if an IT support person reached out to them on Teams and asked them to open Quick Assist. The answer most organizations will get is not reassuring.
Recommended actions
- Review Microsoft Teams external access settings. Restrict inbound external chat to approved domains or disable it entirely if external collaboration is not a business requirement.
- Add Quick Assist and other remote access tools to your security awareness materials. Employees should know that legitimate IT support will never initiate contact through an external Teams account asking them to open a remote session.
- If Quick Assist is not used by your IT team, consider blocking or restricting it through policy. It is a legitimate tool being actively abused as an initial access vector.
- Review alerts for WinRM activity originating from user workstations rather than management systems. Lateral movement via WinRM from an endpoint is an anomaly worth investigating.
- Monitor for Rclone execution on endpoints. This tool appears in multiple documented data exfiltration campaigns and has limited legitimate uses in most enterprise environments.
Derived from Microsoft threat intelligence advisory and confirmed incident response case documentation
02 New OT Risk
BRIDGE:BREAK discloses 22 vulnerabilities in serial-to-IP converters. 20,000 exposed devices online.
BRIDGE:BREAK
What happened
Forescout Research Vedere Labs disclosed a set of 22 vulnerabilities across popular models of serial-to-Ethernet converters from Lantronix and Silex, collectively naming the research BRIDGE:BREAK. Serial-to-IP converters are hardware devices that allow legacy serial equipment to be accessed and managed over an IP network. In industrial and operational technology environments they serve as the bridge between legacy programmable logic controllers, sensors, and control systems that only speak serial protocols and the modern IP-based networks those environments now run on.
Researchers identified nearly 20,000 of these devices exposed directly on the internet. The vulnerabilities include flaws that allow full device takeover, credential theft, and in some cases direct manipulation of the serial traffic flowing through the device. An attacker who compromises one of these converters gains the ability to send arbitrary commands to whatever industrial equipment is connected on the other end. Affected firmware versions span multiple product lines from both vendors. Patches are available from both Lantronix and Silex for the most severe vulnerabilities, though many of these devices run in environments where firmware updates are operationally difficult.
CyberSip Take
The most important thing to understand about serial-to-IP converters is that most organizations do not know they have them. They were installed years or decades ago by an OT or facilities team to connect a specific piece of equipment to the network, and they have been running silently ever since without appearing in any IT asset inventory. No one patched them. No one monitored them. They do not show up in vulnerability scans because nobody knew to look.
The 20,000 internet-exposed devices in this research represent the population someone bothered to count. The actual number of devices in this category that sit on internal networks with no internet exposure but also no monitoring or patching is likely much larger. For organizations in manufacturing, utilities, healthcare facilities, building automation, or any sector running legacy OT equipment, the practical first step is not patching. It is inventory. Run a discovery scan that covers the IP ranges your OT and facilities equipment lives on and find out what is actually there. A serial-to-IP converter that controls a building HVAC system or a manufacturing process should not be reachable from the internet or from corporate workstations, and it almost certainly should not be running firmware from 2018.
Recommended actions
- Run a network discovery scan covering OT, facilities, and building automation network segments. Look specifically for Lantronix and Silex devices. Many of these will not appear in your standard IT asset inventory.
- Any serial-to-IP converter that is reachable from the public internet should be treated as a critical finding. Firewall it off immediately, then assess whether it needs internet exposure at all.
- For identified Lantronix and Silex devices, check the vendor advisories for the BRIDGE:BREAK disclosures and prioritize firmware updates on internet-exposed or IT-network-reachable units first.
- Segment serial-to-IP converters from corporate network segments where possible. A device bridging industrial equipment to IP should not be reachable from user workstations.
Derived from Forescout Vedere Labs research and vendor security advisories
Still watching
Aging items · days 2–7
Items here remain operationally relevant but have no significant new developments. They drop off after 7 days.
Defender RedSun and UnDefend. Seven days without a patch. Active exploitation continues. Detection relies on checking actual signature update timestamps, not service status. Moves to monitoring this issue as stated in Issue 9.
Day 7
Cisco SD-WAN CVE-2026-20122/28/33 (Issue 9). Federal deadline was yesterday. If you have not patched, CISA Emergency Directive 26-03 guidance still applies. Patch to versions 20.9.8.2, 20.12.5.3, 20.15.4.2, or 20.18.2.1.
Day 2
Vercel breach via Context.ai OAuth (Issue 8). Investigation ongoing. Audit Google Workspace OAuth grants and check for the compromised Client ID if not yet done.
Day 3
Apache ActiveMQ CVE-2026-34197 (Issue 6). Federal deadline April 30. Patch to version 5.19.4 or 6.2.3. Active exploitation continues.
Day 6
Cross-source standouts
What connects this week
01
The most effective attacks this month required no exploits at all
Looking across Issue 10's two new items and the Vercel breach from Issue 8, the pattern is consistent. The Vercel attacker used OAuth credentials from a compromised third-party tool. The Teams helpdesk campaign uses a legitimate chat feature and legitimate remote access software. The Booking.com follow-on attacks from Issue 5 used real reservation data to make phone calls sound legitimate. In each case the attacker walked through a door that was designed to be open and used tools that were designed to be trusted. Technical controls alone cannot close these gaps. The question worth asking is whether your employees know what a social engineering attack looks like when it arrives through a trusted application rather than a suspicious email.
02
OT attack surface is larger than most IT inventories suggest
The BRIDGE:BREAK research is the second OT-related item in the brief this month after the GRU router campaign from Issue 1. Both share the same characteristic: devices that were installed years ago, connected to sensitive systems, and never made it into the security team's asset inventory. Serial-to-IP converters are particularly invisible because they were often deployed by facilities or engineering teams with no involvement from IT. Any organization running manufacturing, building automation, healthcare equipment, or utility infrastructure should treat the absence of OT devices in the asset inventory as a gap to close rather than evidence they do not exist.
Past issues · 7-day archive