Microsoft had recently updated the Defender portal, and I was spending time getting familiar with it. While reviewing the results of one of my queries, I noticed activity suggesting that an application had tried to interfere with Microsoft Defender and SentinelOne.

That was enough to make me stop what I was doing and take a closer look.

The activity had happened about 24 hours earlier. Fortunately, this was a new computer that had been disconnected from the network for most of that time. That limited its opportunity to communicate externally or reach other systems, but it was still clear that something was wrong.

What surprised me most was that there was no active threat waiting in one of our usual alert queues.

Following the evidence

I started working backward from the event in Defender.

As I reviewed the processes, files, security changes, and surrounding activity, the events began to form a much clearer picture. There were attempts to avoid endpoint protection, evidence of persistence, and indicators related to credential-capture capabilities.

No single event told the entire story. It was the combination that made the compromise clear.

I checked SentinelOne and Huntress as part of the investigation. Both platforms had recorded useful information connected to the activity, but it had not been classified as an active threat in our consoles.

A product can record an event without turning it into an alert.

By the time I contacted our vendors, I had already worked out the main facts of the compromise. Their teams investigated independently and came back with the same findings. That confirmation mattered. It gave me confidence that I had interpreted the evidence correctly.

They also explained that the activity their systems observed had not met the criteria for an active-threat alert. This was a new campaign, and the individual behaviors had not been connected with enough confidence at the time they occurred.

I do not see that as a reason to blame any one product or vendor. Emerging threats are difficult by nature. Security products have to balance catching suspicious activity against flooding their users with false positives.

Still, it left me with a question: if an application tries to avoid or interfere with multiple endpoint-security products, how much additional evidence should be required before someone is notified?

In this case, the attempted security evasion appeared alongside indicators associated with credential theft and keylogging-related capabilities. Even without a known malware signature, that combination deserved attention.

The FakeAgent campaign

The compromise was connected to a campaign Huntress calls FakeAgent.

According to Huntress’ investigation, users searching Bing for the Claude desktop application encountered malicious sponsored results. One of those results led to a user-created page hosted on the legitimate Claude.ai domain.

That legitimate domain made the page look convincing. Clicking its download button, however, redirected the user to an attacker-controlled site that delivered a fake ClaudeDesktop.exe installer.

The installer used legitimate signed applications to load malicious DLLs. It then established persistence and ultimately delivered SectopRAT, a remote-access trojan with credential-stealing and remote-control capabilities. Huntress reported finding the campaign across at least 29 organizations between July 21 and July 22, 2026.

BleepingComputer’s summary explains that the malware also used techniques intended to make analysis more difficult. These included VMProtect packing, virtual-machine checks, GPU checks, scheduled tasks, and command-and-control information stored in blockchain transactions.

It was not a simple malicious executable that every security product already knew by its hash. It was a layered infection chain that mixed legitimate files, malicious DLLs, anti-analysis techniques, and newly identified infrastructure.

Why KQL made the difference

I was not performing a formal threat hunt when I found the computer. I was learning.

KQL gave me a way to look beyond the information already selected for the main dashboards. Instead of asking only whether we had active alerts, I could ask more specific questions:

  • Which devices recorded attempts to change security settings?
  • What process initiated the change?
  • What ran immediately before and after it?
  • Did the process create a scheduled task or another persistence mechanism?
  • Did the same file or behavior appear on any other endpoint?
  • What network connections followed the execution?

That ability to follow the activity instead of waiting for a final verdict is what led me to the compromised device.

The experience also reminded me that time spent learning a tool is not separate from “real” work. I found this incident because I was curious enough to test queries and examine results that did not look normal.

A fortunate detail

The affected computer had only recently been deployed and was disconnected from the network for most of the 24 hours between the initial activity and my investigation.

That was lucky.

Its limited connectivity reduced the time available for the malware to communicate externally, download anything else, steal information, or interact with other systems.

It did not mean the computer was safe. Once I had evidence of malicious execution, it had to be treated as compromised. But its disconnected state reduced the potential exposure while the activity remained undiscovered.

What stayed with me

My biggest takeaway is not that endpoint-security products cannot be trusted. The tools did exactly what I needed during the investigation: they preserved evidence, provided different views of the activity, and helped validate what I found.

The incident showed me why we use layers.

Defender gave me the event that started the investigation. SentinelOne and Huntress provided additional information. The vendors independently confirmed my findings. None of those pieces would have told the story as clearly on its own.

It also showed me why the alert queue cannot be the only place we look.

Security products have to make decisions about which events deserve immediate attention. With a brand-new campaign, the complete context may not exist yet. Sometimes the person reviewing the telemetry is the one who has to connect the pieces first.

In this case, a new computer, a new threat, and a few hours spent learning KQL happened to intersect at the right time.

Sometimes the most important investigation starts with an alert.
This one started with a question.