Security Is the Engineering of Justified Trust

What Cavern C2 reveals about blind trust, blind distrust, and the security decisions in between.

Joe Shachaf

TL;DR

Project CAV3RN is interesting not

because DNS, HTTPS, Google Apps Script, or Microsoft Graph are inherently

suspicious, but because attackers can compose legitimate services into

malicious infrastructure. That exposes a broader problem: too often, “trusted”

is where security analysis stops.

Blind trust is dangerous, but blind

distrust is not the answer. If we respond to every abuse of a legitimate

platform by blocking, restricting, or inspecting everything, we can end up

protecting systems so aggressively that they no longer serve their purpose.

The better model is justified trust:

trust that is explicit, bounded, supported by evidence, appropriate to the

layer where it is used, and revisited when assumptions change. Sometimes that

assurance is built internally; sometimes it is inherited or bought through

audits, contracts, managed services, certifications, and other mechanisms. The

important part is understanding exactly what assurance was obtained — and what

it does not guarantee.

CAV3RN also raises a temporal problem.

Activity that looks normal today may become meaningful only after new threat

intelligence appears. Logging, retention, and context therefore matter not only

for detecting attacks now, but for recognizing yesterday’s attack tomorrow.

There may be no single checkbox or patch

for this class of problem because nothing necessarily broke. The systems may

have done exactly what they were designed to do. The security work is in

architecture, visibility, context, privilege, proportional controls, and

deliberate trust decisions.

Security is the engineering of

justified trust.

Or skip to the main text

Cavern: when legitimate infrastructure becomes part of the attack

In August 2026, Kaspersky published new research on Project CAV3RN, a cyberespionage toolkit that had already been observed using legitimate cloud services for command-and-control.

The newer findings added another layer: CAV3RN could choose, transaction by transaction, between communicating directly over HTTPS and relaying its traffic through Google Apps Script. DNS was used as part of that decision process.

That matters because none of those technologies are inherently suspicious.

DNS is fundamental infrastructure. HTTPS is normal. Google Apps Script is a legitimate low-code automation platform used every day to connect services and automate workflows.

In fact, that last part is uncomfortably familiar to me. I use platforms such as Jira, Apps Script, and other automation tools for exactly what they were designed to enable: taking useful capabilities from different systems and composing them into something new.

Attackers do the same thing.

The difference is not necessarily the platform, the protocol, or even the engineering pattern.

It is intent.

CAV3RN is particularly interesting because this was not its first use of legitimate services. Earlier research described related tooling that used Microsoft 365 calendar events and Microsoft Graph as part of the covert communications. The newer version moved some of that thinking into Google Apps Script while using DNS to help decide how traffic should be routed.

The obvious reaction is to look at those services and ask what we should block.

I think that is the wrong question.

The more interesting question is much older: When we say we trust something, what exactly do we mean?

Because there are at least three very different answers.

There is blind trust.

There is blind distrust.

And somewhere between them is the thing security actually requires: justified trust.

Blind trust

Years ago, during one of my early application security classes, I had a student who was very enthusiastic about Linux.

So am I. Linux is my operating system of choice.

The problem was not that he preferred Linux.

The problem was that, according to him, Linux was better IN EVERYTHING.

Not better for a particular workload.

Not better under certain constraints.

Not a tradeoff.

Everything.

And if he had made the same claim about Windows, macOS, or Imaginary OS 2.0, I would have reacted exactly the same way.

Because the issue was not Linux.

The issue was certainty so absolute that the disadvantages had disappeared from view.

So I gave him a deliberately simplistic and provocative question.

When you run sudo apt update — or the equivalent package-management command — you are allowing a root-privileged process to obtain information that will influence what software gets installed on the system.

Where does that information come from?

He immediately named an Ubuntu repository.

So I asked:

Are you sure? How do you know?

And we started walking backward through the trust chain.

The package manager relies on its configured repositories.

Those repositories depend on DNS and network infrastructure.

The repository you think of simply as “Ubuntu” may actually be a mirror operated by a university, a company, another organization, or even an individual.

Then there is the signing infrastructure, the trusted keys, repository metadata, package verification, and the controls that exist specifically to make sure that “some random mirror gave me a package” is not the end of the security model.

That distinction matters.

My example was intentionally simplified and provocative.

I was not arguing that apt is insecure.

Quite the opposite: there are multiple controls in the chain precisely because blindly trusting the source would be a terrible design.

The point was that his original statement — “I trust Ubuntu” — hid most of the actual security model.

He had reduced a complicated chain of dependencies, controls, identities, and assumptions to a simple label:

trusted.

And once that label was applied, the analysis stopped.

That is blind trust.

“It’s Google.”

Cavern brings the same problem into a much more modern environment.

“It’s DNS.”
“It’s HTTPS.”
“It’s Google Apps Script.”
“It’s Microsoft Graph.”

All of those statements can be completely true.

None of them tells us what the actor behind the traffic is trying to accomplish.

A DNS response does not become trustworthy merely because DNS is normal.

Traffic to Google infrastructure does not become benign merely because Google infrastructure is legitimate.

A Microsoft API does not become harmless merely because Microsoft designed it for legitimate use.

The service tells us something about where an interaction is happening.

It does not necessarily tell us why.

That distinction becomes increasingly important as systems are built from other systems.

Cloud platforms, APIs, SaaS applications, package repositories, identity providers, low-code platforms, and automation services are all designed to be composed.

That is one of their greatest strengths.

It is also something an attacker can exploit without necessarily compromising the platform itself.

Sometimes the attacker simply uses the platform correctly.

Just not for the purpose we expected.

Where does the trust stop?

The phrase “trusted service” is useful shorthand.

But shorthand becomes dangerous when it replaces the analysis underneath it.

If I trust Google, what exactly am I trusting?
Its authentication?
Its infrastructure?
Its malware detection?
Its application-review process?
Its availability?
Its employees?
Every application running on its platforms?
Every user who has permission to create something there?

Those are very different guarantees.

The same question applies to Microsoft, AWS, an internal network, a vendor, an identity provider, or a package repository.

Trust has scope.

If we cannot explain that scope, then “trusted” may simply mean:

this is where we stopped asking questions.

And sometimes that is not a trust boundary at all.

It is just an assumption..

Blind distrust

If blind trust is one failure mode, the obvious reaction is to swing hard in the other direction.

Block it.

Inspect it.

Restrict it.

Whitelist everything.

Assume every unfamiliar behaviour is hostile.

That sounds safer.

Sometimes it is.

But security has another failure mode: protecting the system so aggressively that the system stops being useful.

A note locked inside a safe at the bottom of the ocean is very secure.

Confidentiality is excellent.

Availability is less impressive.

That absurd example is useful because it exposes the underlying problem: Security is not about maximizing controls.

It is about applying the right controls while preserving the purpose of the thing being protected.

When reducing attack surface becomes the attack

Years ago, during a major coordinated hacktivist campaign, I was involved in the defensive response for a public-sector organization.

The warnings were alarming.

Very alarming.

So alarming that, despite explicit objections from our side, the organization decided to dramatically reduce the attack surface of its public website.

Interactive services were removed.
Self-service functions were disabled.
Search was disabled.
Information-gathering functionality was removed.
The site was reduced largely to static pages.

Technically, the attack surface had been reduced.

That part was true.

Later, when we analyzed what had actually happened during the campaign, we found almost no meaningful attempts to attack that organization. We had intelligence indicating this was not because attackers had detected the reduced functionality and moved on.

The organization had effectively denied much of its own service before the attackers needed to do anything.

That is an uncomfortable outcome.

A defensive control had succeeded technically while failing operationally.

The service was safer from attack.

It was also less capable of serving the people it existed to serve.

The opposite mistake

This is why Cavern should not lead us to the conclusion that we need to distrust everything.

Google Apps Script can be abused.

So can Microsoft Graph.

So can DNS.

So can HTTPS.

So can cloud platforms, code repositories, collaboration tools, automation systems, and almost every other useful general-purpose service.

If the response to every example of abuse is to block the underlying capability, we eventually arrive at a perfectly controlled environment that nobody can use.

We have recreated the safe at the bottom of the ocean.

The problem with blind distrust is the same as the problem with blind trust.

Both replace analysis with an absolute.

Blind trust says:

“I trust it, so I do not need to examine it.”

Blind distrust says:

“I do not trust it, so I should prevent it.”

Neither asks the more useful questions:

What are we protecting?
From what?
What is the likelihood?
What is the impact?
What control is proportionate?
And what will that control cost the mission?

Security is not the art of saying no.

It is not the art of saying yes either.

It is the discipline of deciding when each answer is justified.

Justified trust

If blind trust says “I trust it, so I do not need to examine it,” and blind distrust says “I do not trust it, so I should prevent it,” then justified

trust asks a harder question:

Why should I trust it?

Not philosophically.

Operationally.

What evidence supports the decision?

What exactly am I trusting?

Under which conditions?

For what purpose?

For how long?

And what happens when one of those conditions changes?

That is a very different way to think about trust.

Trust is not binary

Security discussions often reduce trust to a switch:

Trusted / Untrusted / Allow / Block / Inside / Outside

But real systems do not work that neatly.

I may trust an identity provider to authenticate a user without trusting every action that user performs afterward.
I may trust a cloud provider to operate infrastructure securely without trusting every application deployed on that infrastructure.
I may trust a package repository's signing process without assuming every package is appropriate for my environment.
I may trust DNS to resolve a name without assuming the answer tells me anything about the intent of the software making the request.

Trust has scope.

It has conditions.

It has dependencies.

And, importantly, it has limits.

The word “because” matters

A useful trust statement should survive the word because.

“I trust this service because…”

“I trust this identity because…”

“I trust this package because…”

“I trust this connection because…”

What comes after “because” is where the security model begins.

Maybe the answer is cryptographic verification.

Maybe it is authentication plus device posture.

Maybe it is a vendor assessment.

Maybe it is contractual assurance.

Maybe it is behavioural history.

Maybe it is simply that the potential impact is low enough that stronger controls would cost more than the risk justifies.

All of those can be valid answers.

What matters is that there is an answer.

And that we understand what that answer does not guarantee.

Trust should be earned at the level where it is used

Cavern is a good example of why this matters.

Knowing that traffic is going to Google infrastructure may legitimately increase our confidence in certain things.

We may have confidence that the TLS connection terminates where expected.

We may have confidence that Google operates the underlying infrastructure.

We may have confidence that the service itself is available and behaving according to its design.

None of that proves that the workload using the service is benign.

Those are different layers of trust.

If we take assurance from one layer and silently promote it into assurance at another, we have created a gap.

And attackers are very good at living in gaps.

The right question is not:

“Do I trust Google?”

It is:

“What am I trusting Google to guarantee in this specific interaction?”

That is a much narrower question.

It is also a much more useful one.

Trust has a price — and sometimes you should pay it

Justified trust does not mean maximum verification.

If every interaction required independent validation of every dependency, no useful system would survive the process.

At some point, we have to rely on other people, other systems, other organizations, and other controls.

That is not a failure.

That is architecture.

The engineering problem is deciding where to rely on them, how much assurance to inherit, and where our own controls still need to begin.

And sometimes, we pay for that assurance.

Audits, certifications, assessments, contractual commitments, managed services, insurance — these are all ways of buying evidence, accountability, or risk transfer instead of building every assurance mechanism ourselves.

That can be completely rational.

What is not rational is treating the label as the analysis.

In an organization I worked with, one part of the vendor-review process effectively amounted to:

“They have SOC X. They’re good.”

Not which SOC report.
Not Type I or Type II.
Not scope.
Not period.
Not exceptions.
Not whether the controls actually mapped to our risk.

Just:

SOC something = trusted.

That was one of the first things I threw out.

A SOC report can absolutely contribute to justified trust.

But only if you understand what assurance it actually provides.

You can buy assurance. You cannot buy permission to stop thinking.

Sometimes the correct answer is to add another control.
Sometimes the correct answer is to accept the risk.
Sometimes the correct answer is to monitor rather than block.
Sometimes the correct answer is to do absolutely nothing because the additional control would cost more than the risk it reduces.

That is not weak security.

That is risk management.

Trust is a decision, not a label

This is the point where blind trust and blind distrust finally meet.

The goal is not to eliminate trust.

That is impossible.

The goal is not to maximize trust either.

That would be reckless.

The goal is to make trust explicit, bounded, and defensible.

To know why it exists.

To know what it covers.

To know what it does not cover.

And to know when it should be reconsidered.

That is justified trust.

And, increasingly, I think that is what security engineering actually is:

the engineering of justified trust.

When yesterday’s normal becomes tomorrow’s IOC

There is another problem with trust that is easy to miss:

Sometimes the evidence exists before we know what it means.

That is one of the reasons Cavern is interesting.

A DNS lookup.

Traffic to a legitimate cloud service.

A call to Microsoft Graph.

A request routed through Google Apps Script.

Seen in isolation, none of those necessarily looks malicious.

At the time, they may look completely ordinary.

Then new intelligence appears.

A campaign is exposed.

A technique is documented.

A previously benign-looking pattern becomes associated with command-and-control.

And suddenly yesterday’s normal traffic becomes today’s indicator.

The HNDL parallel

This reminds me of Harvest Now, Decrypt Later.

The logic behind HNDL is simple:

An attacker steals encrypted data today, even if they cannot decrypt it yet.

They keep it.

Later, when technology, keys, cryptanalysis, or computing capability changes, that old data may become readable.

The compromise happens first.

The ability to exploit it comes later.

Something similar can happen with detection.

The malicious activity may already have happened.

The logs may already exist.

The DNS queries may already be stored.

The cloud activity may already be in the audit trail.

But the ability to recognize the pattern as malicious arrives later.

That creates a different kind of temporal risk.

Not:

“Can we detect this attack now?”

But:

“Will we still have enough evidence to recognize it when we finally understand what we are looking at?”

Retention is part of detection

That changes how we think about logging.

Logs are often treated as operational exhaust.

Store enough for troubleshooting.

Keep enough for compliance.

Delete the rest when retention expires.

But if techniques evolve faster than our ability to recognize them, then historical telemetry has another value:

future interpretation.

A DNS event that means nothing today may become highly relevant six months from now.

A cloud API call that looked normal may suddenly match a newly documented behavior.

A sequence of legitimate actions may only become suspicious when intelligence gives us the missing context.

That does not mean “store everything forever.”

That would simply be another version of the safe at the bottom of the ocean.

Retention has cost.

Storage has cost.

Privacy has cost.

Analysis has cost.

But it does mean that retention decisions are part of the detection architecture, not merely an administrative setting.

Context matters as much as the event

There is another trap here.

Keeping the raw event may not be enough.

A single DNS record without the process that requested it may be useless.

A cloud API call without the identity behind it may be meaningless.

A network connection without endpoint context may tell us very little.

If we want the option to revisit historical activity, we need to preserve enough context to make that activity interpretable later.

That may include:

identity,
endpoint,
process,
destination,
timing,
authentication context,
cloud audit data,
related events,
and whatever else is proportionate to the environment and risk.

The point is not maximum telemetry.

The point is useful telemetry.

Yesterday may need another look

Threat hunting is often described as looking for attackers who bypassed detection.

There is another version:

Looking again at activity we already saw, after learning something we did not know the first time.

That is a powerful idea.

Because an IOC is not always malicious-looking when it first appears.

Sometimes it becomes an IOC only after the rest of the story is known.

So one of the questions security teams should ask is not only:

“Would we detect this today?”

But also:

“If we learn something important tomorrow, can we go back and recognize what happened yesterday?”

That is where trust, detection, and time intersect.

And it is another reason why justified trust cannot be static.

The evidence changes.

The context changes.

Our understanding changes.

So sometimes the right security decision is not to distrust everything now.

It is to preserve enough context to reconsider what we trusted later.

What do we actually do about it?

This is the point where security articles usually become disappointing.

After describing a complicated problem, they end with something like:

Patch your systems.

Block the indicators.

Update your detections.

Train your users.

That is useful when there is a clear vulnerability, a clear exploit path, or a clear malicious infrastructure pattern.

Cavern is harder.

The services being abused are legitimate.

DNS is legitimate.

Google Apps Script is legitimate.

Microsoft Graph is legitimate.

HTTPS is legitimate.

The problem is not that these technologies are broken.

The problem is that legitimate capabilities can be composed into a malicious system.

That means there may be no single low-effort control that solves the problem.

And that is not unusual.

Start with expected behaviour

If a service is allowed in your environment, that does not mean every use of that service should be treated equally.

The useful question is not:

“Is Google Apps Script allowed?”

It is:

“What does normal use of Google Apps Script look like here?”

Which users should be using it?
Which systems?
For what purpose?
From where?
At what volume?
With which identities?

The same applies to DNS, Graph, GitHub, Slack, cloud APIs, package repositories, or any other general-purpose platform.

Legitimate services become easier to abuse when our only model is:

allowed or blocked.

Expected behaviour gives us a third option:

allowed, but understood.

Correlation matters more than isolated events

A DNS query by itself may mean very little.

A connection to Google infrastructure may mean very little.

A process making an outbound HTTPS request may mean very little.

Together, they may mean much more.

This is why detection increasingly depends on correlation between layers:

endpoint activity,
process context,
identity,
DNS,
network telemetry,
cloud audit logs,
authentication,
and application behaviour.

The goal is not to inspect everything equally.

The goal is to understand enough of the surrounding context that legitimate infrastructure does not automatically become a blind spot.

Limit unnecessary privilege

General-purpose platforms are powerful because they are flexible.

That flexibility is also what makes them attractive to attackers.

The answer is not to eliminate the platforms.

It is to make sure users, workloads, and integrations have only the authority they actually need.

If a process does not need access to a service, do not give it access.

If an identity does not need broad API permissions, do not grant them.

If a workload can operate within a smaller boundary, keep it there.

That does not prevent every abuse.

It reduces what successful abuse can accomplish.

Preserve enough evidence to look back

As discussed earlier, some malicious behaviour only becomes recognizable after new intelligence appears.

That means retention and context matter.

You do not need to store everything forever.

But you should know which telemetry would be valuable if you had to investigate the past.

Can you determine which process made the request?

Which identity was involved?

Which endpoint?

Which destination?

What happened before and after?

If the answer is no, then future intelligence may tell you that something was suspicious while leaving you unable to determine whether it happened in your environment.

Accept that some risk remains

This may be the least satisfying mitigation, but it is one of the most important.

You cannot eliminate all risk created by general-purpose platforms.

You cannot verify every dependency independently.

You cannot inspect every action with the same intensity.

And you should not try.

Some risk must be accepted.

The security decision is whether that risk is understood, proportionate, and monitored appropriately.

That is very different from ignoring it.

Do not solve abuse by destroying utility

The temptation after reading about a technique like Cavern is to respond with another rule.

Block the service.

Restrict the platform.

Inspect more traffic.

Add another gateway.

Sometimes that is correct.

Sometimes it recreates the safe at the bottom of the ocean.

A control that prevents legitimate work may reduce one risk while creating another.

Availability, usability, productivity, and mission impact are part of security too.

The objective is not maximum restriction.

It is proportionate control.

There is no magic checkbox

That may be the most important mitigation lesson here.

Some attacks do not have a patch because nothing was broken.

The systems did exactly what they were built to do.

The attacker simply used those capabilities in a different way.

When that happens, the answer is rarely a single product or setting.

It is architecture.
It is visibility.
It is context.
It is privilege management.
It is retention.
It is detection.

And, above all, it is making deliberate decisions about what you trust, why you trust it, and what that trust actually allows.

Security is the engineering of justified trust

Cavern is interesting because it looks modern.

DNS.

Google Apps Script.

Microsoft Graph.

Cloud services used as part of command-and-control.

But the security problem underneath it is not new.

We have always had to decide what we trust.

What has changed is the number of things we depend on, the speed at which they change, and how many trust relationships are hidden behind abstractions.

A modern system may rely on dozens of external services before a user does anything that appears interesting.

An identity provider authenticates them.

A cloud platform runs the workload.

A package ecosystem supplies dependencies.

An API connects another service.

A DNS provider tells the system where to go.

A SaaS platform performs some part of the workflow.

An automation layer connects the pieces.

Each one comes with controls.

Each one also comes with assumptions.

The mistake is not trusting them.

The mistake is forgetting that trust was a decision.

Trust should be explicit

A good trust decision should be explainable.

We should be able to say:

what we trust,

why we trust it,

what evidence supports that trust,

what the trust actually covers,

where it stops,

and what would cause us to reconsider it.

That does not mean documenting every dependency in an encyclopedia-sized threat model.

It means making important trust relationships visible enough that they can be challenged.

Because hidden trust is very hard to manage.

Trust should be bounded

Trust should not silently expand.

Trusting an identity provider to authenticate a user is not the same as trusting every action that follows.

Trusting a cloud provider's infrastructure is not the same as trusting every workload running on it.

Trusting a vendor's audit is not the same as trusting every part of the vendor's security posture.

Trusting a DNS response is not the same as trusting the intent of the process that asked for it.

A trust boundary is useful only if we understand what crosses it.

Otherwise, it is not really a boundary.

It is a label.

Trust should be revisited

Trust is also not permanent.

Vendors change.

Architectures change.

Threats change.

Controls improve.

Controls fail.

New intelligence appears.

A service that was appropriate yesterday may not be appropriate tomorrow.

A behavior that looked normal last month may become significant when a new campaign is exposed.

A security decision that made sense under one set of assumptions may become wrong when those assumptions change.

That does not mean reassessing everything constantly.

It means recognizing that trust has a lifecycle.

The goal is not zero trust

“Zero Trust” is useful as an architectural principle because it challenges implicit trust.

But no real system operates with literally zero trust.

At some point, something has to be believed.

A cryptographic key.

An identity provider.

A root certificate.

A hardware component.

A human decision.

A cloud platform.

A piece of code.

Security cannot eliminate trust.

What it can do is make trust more deliberate.

More visible.

More constrained.

More defensible.

That is why I keep coming back to the same conclusion:

Security is the engineering of justified trust.

Not blind trust.

Not blind distrust.

Not maximum control.

Not minimum friction.

Just enough trust, for the right reason, at the right layer, with the right boundaries.

And enough humility to revisit the decision when the world changes.

And maybe this becomes a profession

We already have risk analysts, risk managers, security engineers, solution architects, privacy professionals, reliability engineers, and many other specialists involved in these decisions. Each sees an important part of the problem. But expertise also creates a lens.

A risk manager will naturally look for the risks and how to document them. A security engineer will look for controls. An architect will look at dependencies and boundaries. A privacy professional will look at data and its use.

None of those perspectives is wrong.

The problem is that justified trust often exists between them. Someone still has to connect the dots. To look at the risk, the controls, the architecture, the dependencies, the business need, the cost of restriction, the inherited assurance, and the consequences of being wrong - and arrive at an informed level of trust.

Maybe that eventually becomes its own discipline.

Justified Trust Engineering.

A multidisciplinary practice focused not on eliminating trust, but on determining where trust is justified, how far it should extend, and when it needs to change. Five years from now, “Justified Trust Engineer” may sound completely ordinary. I suspect the work already exists.

We just have not given it a name yet.

Prefer an offline copy?

This Insight became longer and more extensive than I originally expected. You can download it as a PDF for reading, or as Markdown if you prefer a portable, plain-text format.

Download PDF · Download Markdown