Four separate pieces of threat intelligence crossed my desk this week, different malware families, different platforms, different regions. Every one told the same story: the attacker didn’t break anything. They borrowed something.
A cloned AI development repository. A macOS “verification” prompt. A routine software-update notice. A remote monitoring platform your own MSP relies on. In each case, the payload was the least interesting part. What mattered was what the attacker chose to impersonate: not a stranger, but someone already trusted.
That’s the strategic flaw few say out loud: most security programs are built to catch intruders, not impostors. We’ve hardened the perimeter against people who don’t belong and left ourselves exposed to code that looks exactly like it does.
At CPX, we’ve been seeing this shift reflected in how organizations need to think about security validation across the UAE and Gulf region. The question is increasingly not just whether an attacker can get in, but whether the organization can recognize when something trusted is being used against it.
The entry point doesn’t always have to be a crack in the wall. Sometimes it’s the door the organization has deliberately left open for someone—or something—it recognizes.
Read the pattern, not the shot
Competitive tennis teaches this directly. At a serious level, you stop reacting only to the ball and start reading tendencies, the toss height, the shoulder turn, because by the time the ball is in the air it’s too late to out-guess it.
Today’s intrusion tradecraft is built the same way. A recent macOS campaign, for example, uses environmental fingerprinting before revealing its malicious lure, helping distinguish ordinary users from researchers and automated analysis. Elsewhere, attackers are increasingly able to skip custom malware altogether, riding in on a digitally signed remote-management client that, once installed, can look to security tools like your own administrator logging in.
The engagement that actually tests this
A compliance-driven pentest, run once against a fixed scope, can’t find this, it was never built to. It validates that known vulnerability classes are patched. It doesn’t answer the harder question: if your environment were handed a convincing impersonation of something it already trusts, would anyone notice? That calls for a live-fire exercise, not a checklist, cloning the trusted resource, mimicking the update notice, standing up the “legitimate” remote session, and timing how long it survives before someone asks why an admin tool is behaving just slightly differently.
Fully autonomous AI red teaming should be considered carefully. Benchmarking frontier models against exactly this class of problem, the honest finding is that AI accelerates the mechanics: recon, correlation, first-pass triage, but doesn’t yet replicate the adversarial judgment behind these campaigns: the decision to fingerprint before revealing a lure, the patience to let a compromised admin console sit quietly. That’s still a human call. AI can hand you a faster racket; it can’t yet read the opponent’s toss.
At CPX, our approach combines AI-accelerated recon and triage with human-led adversarial design. The machine finds the surface faster. The human decides which impersonation a specific environment would find most convincing, and that decision is what separates a useful exercise from a fast one.
One regional wrinkle worth naming: a meaningful share of GCC critical-infrastructure and government engagements run air-gapped, by design. Most offensive tooling assumes constant cloud connectivity, a capability that can’t operate disconnected can’t test the environments that need it most. That gap is quietly becoming one of the more consequential differentiators in this market.
The real advantage isn’t a longer list of patched CVEs. It’s an organization that has already rehearsed the moment its trust gets exploited and knows, because it’s been tested, not assumed, what happens next.
