Quick Answer: Attackers increasingly blend in by logging in with stolen credentials and using legitimate admin tools, trusted software updates and AI agents with broad permissions. At ChannelCon 2026, ConnectWise’s Bryson Medlock urged MSPs to audit their trust assumptions: What they trust, why, how that trust could be abused and how they’ll detect, respond and recover when it is.
For years, cybersecurity professionals learned to look for the intruder: The strange executable, the suspicious connection, the vulnerability being exploited from outside the network. Bryson Medlock, director of threat intelligence and evangelism at ConnectWise, argued that the more dangerous question had become what happens when the attacker doesn't look like an attacker at all?
During a session at ChannelCon 2026, Medlock described a threat landscape increasingly defined by attackers abusing legitimate credentials, familiar software, trusted automation and ordinary user behavior. Drawing from incidents documented in the ConnectWise 2026 MSP Threat Report, Medlock argued that the security assumptions MSPs made every day had themselves become part of the attack surface, and he illustrated his point with a bomb of a statement. “The thing is you're not secure. You're never secure. There's no such thing as secure. It's really a matter of risk,” he said.
Today’s Attackers Look Legitimate
Medlock contrasted contemporary intrusions with the traditional model many security practitioners learned through penetration testing: Reconnaissance, scanning, enumeration, vulnerability discovery and exploitation. “That’s not how hacking works today,” he said.
Akira ransomware incidents observed by ConnectWise offered a much different starting point. Medlock said that when researchers traced successful incidents backward through the logs, the first indicator was often remarkably mundane: A legitimate VPN user logged in.
Attackers could purchase stolen credentials from initial access brokers and simply authenticate. Once inside, they could continue blending into the environment by using software that legitimate administrators used themselves.
Medlock pointed to Advanced IP Scanner as one example. MSP technicians might use the tool to map a network. An attacker could do the same thing. Attackers could also identify systems without endpoint detection and response coverage and establish themselves where defenders had less visibility. “They’re using the same tools everybody else is using,” he said.
That changes the defensive problem. Spotting an obviously malicious application is one thing. Determining whether an authorized account using an approved application is actually an attacker requires defenders to understand behavior and context—not simply whether a tool belongs on the network.
Trust Is the New Attack Surface
The same principle extends well beyond credentials. Medlock highlighted ClickFix attacks which exploit users' familiarity with routine verification prompts. A victim might encounter what appears to be a CAPTCHA or troubleshooting instruction and be directed through keyboard commands that ultimately execute malicious code. The attacker isn’t defeating the user's computer so much as exploiting a behavior the user has learned to trust.
Software supply chains create an even more difficult version of the problem. Medlock discussed compromises involving NPM packages in which malicious code could propagate through dependencies as developers perform ordinary updates. He also revisited the XZ Utils backdoor attempt, an especially instructive example because the malicious behavior was concealed within the build process rather than appearing plainly in the source code developers expected to inspect.
The common thread wasn't a particular vulnerability, malware family or attack vector. It was an assumption.
A credential is trusted because it belongs to an authorized user. An RMM tool is trusted because administrators intentionally installed it. An update is trusted because it arrived through an established software process. An automation is trusted because organizations designed it to perform repetitive work without constant human intervention. Attackers increasingly benefit from these assumptions.
“You can’t automatically trust your RMM tools,” Medlock said. “You can’t automatically trust your SaaS tools. You can’t trust your APIs.”
AI Amplifies the Trust Problem
AI agents add another complication because dangerous behavior no longer necessarily requires an attacker controlling every action. Medlock emphasized that his argument wasn’t against using AI. It was an argument against granting an AI system broad access and assuming it would always accomplish a task in the way its operator expected.
“You shouldn't really just trust AI to do what you should have guardrails around,” he said. “These AIs, they do things they're not supposed to all the time.”
The distinction matters. A compromised credential represents trust transferred to the wrong person. An agent could potentially create risk while operating with exactly the identity and permissions it was supposed to have.
If an AI chatbot can query an entire customer database, for example, a user authorized to access one account might attempt to persuade it to retrieve information from another. Medlock argued that organizations instead need to constrain the agent itself, limiting its database access according to the permissions of the person interacting with it.
In that sense, AI amplifies an existing security problem rather than creating an entirely new one: Organizations have to decide how much authority to give systems they cannot assume will behave perfectly.
5 Questions to Audit Trust
When evaluating a trusted account, application, process or AI agent, ask:
- What do we trust?
- Why do we trust it?
- How could an attacker inherit, impersonate or exploit that trust?
- How would we recognize trusted access being abused?
- What happens when the protection we expected to work fails?
The objective isn’t to eliminate trust. Modern IT can’t function without it. Medlock’s argument is to treat trust as something that requires controls, monitoring and contingency planning—not as evidence that an activity is safe.
Shift from “Secure” to “Prepared”
Medlock ultimately reduced the problem to a short series of questions. “What do you trust? Why do you trust it?” he said. “And then thinking about how can it be abused?” That approach shifts security away from a binary judgment about whether something is safe. MFA can fail. EDR coverage can have gaps. VPN credentials can be stolen. Trusted software can be compromised. Even protections specifically introduced to reduce risk can eventually become assumptions an attacker learns to exploit.
The answer isn't to abandon those technologies. It is to stop treating any of them as the end of the security conversation. Medlock encouraged MSPs to consider not only how they protected trusted systems, but how they would detect when those protections failed, respond when trusted access was abused and recover afterward. Paranoia, in that formulation, isn’t indiscriminate suspicion. It is refusing to confuse familiarity with proof.
And for MSPs entrusted with access to multiple customer environments, that distinction may determine whether an attacker stands out or looks like someone who belongs there.
