Weekly Briefing • November 13, 2026

Attackers took over the remote support accounts of at least six IT providers and used them to reach 286 devices at 47 of their client organizations. Since November 5, Microsoft has been rejecting some legitimate email sent to personal outlook.com, hotmail.com, live.com and msn.com addresses. And on Thursday, November 12, a failure inside Microsoft cut users in the Americas off from their Microsoft 365 email.

Each one started at a company your firm depends on, and only the first is known to be an attack. What your office controls is what happens next: whether anyone knows which remote access tools are on your computers, whether anyone reads the bounces, and whether staff know where to turn when email is down. Here's what happened, and what it means for how your firm operates.

Attackers Used IT Providers' Own Remote Support Tool to Reach Their Clients

Attackers took over ConnectWise ScreenConnect accounts belonging to at least six managed IT providers and used them to reach 286 devices across 47 of those providers' client organizations, according to security company Huntress, which says the count is still rising. ScreenConnect is a remote support tool: it is how a provider's technician sees a client's screen, runs commands and installs updates without being in the room. ConnectWise has confirmed unauthorized access to partner accounts and unauthorized remote access software at customers. Huntress doesn't yet know how the attackers got in, though its data points to stolen logins or hijacked technician sessions. It calls this misuse of the tool's normal features, not a flaw in its code.

Once inside, the attackers used ScreenConnect's own command feature to install extra copies of ScreenConnect that answer to them, not to the provider, so they can keep a way in even if the provider's access changes. ConnectWise suspects more software went in through five add-ons with names that read like ordinary IT tools. It has switched those off for providers on its cloud service, and warns that doing so doesn't clean up anything already installed. It is also checking reports that a technician's own computer was compromised during a remote session with an infected client computer. A technician's computer usually holds access to many clients, so one infected client computer could become a way into the rest.

Two recent briefings asked you to list the outsiders who can reach your systems: on October 23, the apps connected to your Microsoft 365, and on November 6, the people outside your staff who can sign in to your records system. This week's outsider is your IT provider, whose access reaches every computer it supports. Most of the records that would show an attacker at work, such as the command history and sign-in logs, sit in the provider's systems, so you depend on the provider to tell you what happened, and it may still be working that out.

So put three questions to the company that manages your computers, in writing. Do you use ScreenConnect or any of the five add-ons ConnectWise flagged, and what did a review of your logs, going back several months, find? Which remote access tools are installed on our computers, and whose server does each one report to? And does the system your technicians use to reach our computers require multi-factor authentication, a second sign-in step such as a code on a phone, so a stolen password alone can't open it? ConnectWise says an add-on being installed doesn't by itself mean a compromise. Any tool that reports to neither the provider nor a vendor you've approved needs a written explanation. Then check whether your agreement says how quickly the provider must tell you if its own systems or tools are compromised, and if it doesn't, ask for that in writing. That includes us: if Capstone manages your computers, ask us the same questions. Full analysis here: ScreenConnect Attacks Breach MSPs and Impact Dozens of Organizations.

Microsoft Is Rejecting Some Legitimate Email. The Only Record Is the Bounce.

Since November 5, Microsoft's consumer email service has been rejecting some legitimate messages sent to personal addresses ending in outlook.com, hotmail.com, live.com and msn.com, the kind of address many patients and clients use. Most of the rejected mail comes from domains that don't publish a DMARC record, an entry in a domain's DNS settings that tells receiving mail servers what to do with mail that fails the checks confirming who sent it. Microsoft has required DMARC since May 2025, but only from domains that send more than 5,000 messages a day to its consumer mailboxes. These rejections are hitting small senders far below that. Microsoft hasn't announced a policy change or posted a notice. A moderator listed as Microsoft external staff called it a "service degradation" under investigation, and nothing in the reporting points to an attack.

A rejected message never reaches the recipient's inbox or junk folder. The patient waiting on an appointment confirmation, or the client waiting on a document request, never learns it was sent, and your sent folder still shows it as sent. The only record is on the sender's side, usually a bounce in the sender's inbox with wording such as "hotmail.com couldn't confirm that your message was sent from a trusted location," and a bounce full of codes reads like a glitch. For a law or accounting firm, a bounced engagement letter or filing reminder can let a deadline pass while your firm believes the notice went out. Mail your systems send on their own is especially exposed: appointment reminders, e-signature requests and billing statements often go out through an outside service under your name, and nobody reads those bounces.

Ask whoever manages your domain's DNS records, often your IT provider or whoever built your website, to check that your domain, and any other domain or subdomain your outside services send from, publishes a DMARC record. Where one is missing, Frank Dickson of Dickson Research says a monitoring-only record, one that asks receiving servers to send reports and take no action on mail that fails, stops these bounces as long as one of the other two email authentication records, SPF or DKIM, lines up with the domain in the From line. It may not fix every case: some domains with all three records working were reportedly rejected too. If DKIM signing was never turned on for your domain in Microsoft 365, turn it on. Two things to avoid: rewriting your SPF record because a bounce blames SPF, unless someone finds an actual error in it, and loosening your own filtering to get mail through. Loosening it does nothing for mail you send, stays in place after Microsoft fixes this, and weakens the filtering that stops forged mail aimed at your staff. Full analysis here: Microsoft Email Security Blocks Legitimate Business Mail Unexpectedly.

When Microsoft 365 Went Down, the Risk Was What Your Staff Did Next

On Thursday, November 12, users in the Americas lost their connection to Exchange Online, the system behind Microsoft 365 email. Microsoft warned of potential disruption to Teams, SharePoint, Copilot and many other services. It said a large number of its servers had become unavailable, and it began rolling back a network configuration change that coincided with the start, without saying the change caused the outage. The disruption continued into Friday. As of Microsoft's Thursday evening update, restarting affected servers was showing signs of improvement, but Microsoft had not confirmed full recovery. Its status page says: "At this time, we have no evidence of malicious activity associated with this incident."

Your firm couldn't have prevented this outage. What your firm controlled was what people did during it. Staff who can't send email tend to move the work to personal email, text messages or a consumer chat app, and those conversations land outside your firm's records, outside any legal hold, and outside the protections you're responsible for on patient and client information. Outages also make fake help more convincing: emails claiming to be from Microsoft or IT, and phone calls offering to restore access. Separately, Microsoft's November updates, released two days before the outage, fixed CVE-2026-124194, an Outlook flaw Microsoft says attackers have already used: opening a specially crafted file in an affected version of Outlook can expose information an attacker can use to pose as that user. Microsoft hasn't linked it to the outage, but an attachment promising to fix your mailbox is a realistic way to deliver one.

Three things to settle before the next one. Ask whoever handles your IT whether Outlook on every computer has the November updates. Decide your fallback: who tells staff what's down and when to expect the next update, by phone tree or group text with no patient or client details, and how clients and patients will hear from you. And give staff two rules for any outage. Client and patient work moves to the phone or waits, never to personal email or texts. And any email asking them to re-verify an account or open an attachment to restore their mail gets ignored, as does any call offering the same help. Full analysis here: Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams Users.

Also on Our Radar This Week

Attacker Uses Stolen Qubole Credentials to Breach Customers' AWS Environments. Between October 14 and 26, someone holding stolen credentials for Qubole, a data analytics company, used the access Qubole's customers had granted it to get into their Amazon Web Services accounts, including access that had gone unused. The attacker downloaded everything that access could reach, collected 100 stored passwords and keys in seven minutes, and confirmed that some still worked, including app keys for Microsoft Entra ID and Okta, the services that control sign-in to other business applications. Sentra, one of the security companies investigating, confirmed dozens of victims, and one lost millions of files. Most firms reading this don't have their own Amazon Web Services account, but the lesson is the one from October 23: access you grant a vendor stays open until someone removes it, whether or not the vendor still uses it.

Fake Security Tools on GitHub Push Backdoors and Infostealers. Researchers at Dr. Web found more than 2,000 Windows computers infected by a campaign, running for about two years, that now hides its malware in GitHub projects posing as security tools. Building or running one installs a backdoor and a program that steals browser data and VPN settings, and the targets now are security researchers and IT staff, the people who usually hold administrator rights and VPN access. Ask whoever handles your IT, inside the firm or outside it, where they run tools downloaded from GitHub. The right answer is a separate, disposable test machine with no saved logins and no connection to your office systems. A laptop that has run one of these tools can't be trusted to report on itself, because the malware tries to uninstall three common antivirus products and switches off some of Windows' own protections, so it gets rebuilt, and every login used on it gets changed from a different, clean computer.

Brian Sammons has managed IT environments for Ohio professional service firms (medical, dental, legal, accounting, and financial) since 2004. He writes the Weekly Briefing for the owners, administrators, and IT managers responsible for keeping those firms running: what happened in security this week, and what it means for yours.

Questions about how this affects your environment? Schedule 15 minutes and I'll walk you through it.