Blog
Exploiting trust: the modern cyber threat
Modern cyberattacks no longer need to break in – they log in. Attackers exploit trusted identities, tools, and software supply chains. Learn why trust is today’s biggest attack surface and how MDR, context, and continuous validation help organisations defend against it.
Jump to
- Trusted identities: the easiest way in
- When modern intrusions imitate normal work
- Trusted software: your hidden attack surface
- Why Zero Trust is not the full answer
- AI can accelerate investigations, but it cannot replace trust
- The defensive answer: nurture trust, do not assume it
- Trust also requires transparency
- Trust is not the weakness. Unexamined trust is.
Trust is one of the most important foundations of business. We trust employees to access the systems they need. We trust administrators to maintain critical infrastructure. We trust vendors to support our operations. We trust open-source maintainers and software providers to deliver code that does what it claims to do.
Although cybersecurity has traditionally treated trust as something to be controlled, modern threat actors increasingly treat trust as something to be exploited.
They no longer need to “break in” if they can log in, and no longer need custom malware if they can use approved tools. They also no longer need to attack every organisation directly if they can compromise a trusted supplier, SaaS provider, developer account, or software dependency.
This is the defining pattern of many modern intrusions: attackers are not only exploiting technical vulnerabilities. They are exploiting the relationships, identities, tools, and dependencies that organisations already rely on.
Trusted identities: the easiest way in
Credential compromise has become one of the most effective ways to enter corporate environments because it allows attackers to appear legitimate. Verizon’s 2025 DBIR found that credential abuse and vulnerability exploitation remained leading initial attack vectors, with credential abuse accounting for 22% and vulnerability exploitation for 20% of breaches analysed. The same report also found that third-party involvement in breaches doubled to 30%, highlighting how trust relationships beyond the organisation’s own perimeter are becoming part of the attack surface. (Verizon)
This trend is reinforced across other threat reporting. IBM X-Force reported that abuse of user identities remained the preferred entry point for attackers in 2024, occurring in 30% of cases, while stolen credentials continued to be traded at scale across underground markets. (IBM) Mandiant’s M-Trends 2026 report also emphasises that defenders need to move beyond static controls and continuously monitor identity behaviour, especially as interactive social engineering, SaaS compromise, stolen credentials, and session abuse continue to bypass traditional defences. (Google Cloud)
The reason is simple: a valid login does not look like an intrusion at first glance. A user signs in from a plausible location. An administrator opens a remote management tool. A script runs under an approved service account. A cloud token is used against an API. From the perspective of many security systems, these actions may initially look authorised.
This is where trust becomes dangerous. Not because trust is wrong, but because trust is often treated as static. Once an identity, tool, vendor, or workflow has been approved, organisations may stop asking whether its current behaviour still makes sense.
When modern intrusions imitate normal work
Attackers are deliberately moving away from noisy techniques and toward activity that blends into normal business. CrowdStrike’s 2026 Global Threat Report states that 82% of detections in 2025 were malware-free, with adversaries using valid credentials, trusted identity flows, approved SaaS integrations, and inherited software supply chains to move across environments. (CrowdStrike)
This is a major shift for defenders. Traditional detection often looks for malicious files, suspicious binaries, or known indicators of compromise. But what happens when the attacker uses legitimate tools? What happens when the activity comes from a real account? What happens when the attacker operates during normal working hours and follows patterns that resemble IT administration?
In such cases, the question is no longer only “is this file malicious?” but instead: “is this behaviour expected for this identity, this asset, this business process, and this moment in time?”
That question cannot be answered by tools alone. It requires context.
Trusted software: your hidden attack surface
Trust is not limited to human users. Every modern organisation also trusts software supply chains.
Applications are rarely built from scratch. They are assembled from frameworks, libraries, packages, containers, CI/CD workflows, and third-party services. This creates enormous efficiency, but it also creates inherited risk. A single compromised maintainer account, poisoned package, or tampered build workflow can affect thousands of downstream environments.
In 2025, the compromise of the popular tj-actions/changed-files GitHub Action impacted more than 23,000 repositories. Attackers modified version tags to point to malicious code that exposed CI/CD secrets in workflow logs, creating a risk of unauthorised access to source code, infrastructure, and production environments. Source: GitHub)
The Nx “s1ngularity” supply-chain attack showed a similar pattern. According to the project’s own postmortem, attackers exploited a GitHub Actions injection vulnerability to steal an NPM token. NVD later described the incident as malicious code inserted into Nx packages and related plugins, with affected versions scanning file systems, collecting credentials, and posting them to GitHub repositories under users’ accounts. (Source: Nx)
These incidents matter because they demonstrate an uncomfortable truth: trusted software can become hostile without changing its name, reputation, or place in the dependency tree.
An organisation may not have been directly targeted, its developers may not have made an obvious mistake, and its perimeter may not have been breached. Yet malicious code can still arrive through a trusted component that was safe yesterday and dangerous today.
Why Zero Trust is not the full answer
At first glance, the obvious answer might be to adopt Zero Trust.
And to be clear, Zero Trust is an essential security principle. NIST defines Zero Trust as a model where trust is not implicitly granted based on network location or ownership, and where access to resources is continuously evaluated. (Source: NIST Computer Security Resource Center)
But Zero Trust is not a magic shield against every form of trust exploitation.
Zero Trust can reduce implicit access. It can enforce stronger authentication, least privilege, device posture checks, segmentation, and conditional access. These controls matter. They make compromise harder and lateral movement more difficult.
But Zero Trust does not automatically know whether an administrator is behaving unusually if nobody has defined what “usual” looks like. It does not automatically know whether a vendor integration is being abused if the integration is technically allowed. It does not automatically know whether a software dependency has been tampered with unless software supply-chain telemetry, package governance, and threat intelligence are integrated into detection and response.
In other words, Zero Trust reduces blind trust. But it does not replace operational understanding.
Stolen administrator credentials, a compromised SaaS token, and a poisoned software package are all still dangerous. So is a trusted remote management tool used by an attacker.
The real challenge is not only to remove trust, but to manage it continuously.
Guide: Secure AI 2026 – effective & future-proof AI
Cut through the hype and standalone technical fixes. Deepen your understanding of AI by recognising that it is not merely a matter of innovation or security, but of governance, responsibility, and lon…
AI can accelerate investigations, but it cannot replace trust
Artificial intelligence is already becoming useful in security operations: it can help summarise alerts, correlate large volumes of telemetry, enrich investigations, identify recurring patterns, and reduce the time analysts spend on repetitive work.
That matters. Security teams are under pressure to investigate more signals, across more systems, with less time. In this environment, AI can become a powerful assistant.
But a fully autonomous, agentic AI SOC is not the complete answer as things are today.
The reason is that modern intrusions are not only technical puzzles. They are behavioural, operational, and contextual. An attacker using a stolen administrator account may not trigger a simple “malicious” verdict. A legitimate remote management tool may be used for both valid maintenance and hands-on-keyboard intrusion. A developer downloading a new package may be part of normal engineering work, or the first step in introducing a poisoned dependency into the environment.
The difference between normal and suspicious often depends on context. In order to work that out, you have to answer the following questions:
Is this action expected for this user?
Is this system normally accessed at this time?
Is this administrator performing a task that aligns with the client’s business process?
Would automatic containment disrupt a critical service?
Is this software dependency actually used in production, or only in a test environment?
Does this alert matter more because of the client’s industry, geography, exposure, or current threat landscape?
These questions require judgement and are not purely binary. AI can assist with that judgment, but it cannot reliably replace the human understanding required to make security decisions in a specific business context. Used poorly, it can create more noise. Trusted blindly, it can miss the nuance that separates malicious activity from unusual but legitimate behaviour.
AI can assist with the investigation, but it cannot fully replace the relationship between a client and a security team that understands their environment. It does not automatically know which assets are business-critical, which users have unusual but legitimate workflows, which vendors are essential, or which response actions are acceptable under specific business conditions.
This is why the future of MDR should not be “AI instead of analysts.” It should be AI-augmented analysts working within a transparent, intelligence-led operating model.
At Conscia, we see AI as a way to help our analysts move faster, reduce noise, and focus more attention on the decisions that matter. But the quality of those decisions still depends on human expertise, client-specific knowledge, and a trusted partnership.
Because when attackers exploit trust, defenders cannot rely only on automation. They need context, accountability, and judgment.
The defensive answer: nurture trust, do not assume it
The answer to exploited trust is not distrust. It is better trust.
For cybersecurity providers, this means moving beyond transactional service delivery. A managed detection and response provider should not be just an external alert handler. The relationship should become a security partnership built on shared context, continuous feedback, and mutual understanding.
That kind of trust is not blind. It is active.
A trusted MDR partner learns the client’s environment: critical assets, normal user behaviour, privileged workflows, exposed services, business processes, technology stack, third-party dependencies, and acceptable operational patterns. This knowledge can then be translated into better detections, more accurate triage, stronger threat hunting, and faster response.
When we understand what normal looks like, abnormal becomes easier to detect.
When we know which identities are business-critical, we can prioritise suspicious activity around them.
When we understand which systems support essential operations, we can treat unusual access differently.
When we know which vendors, SaaS platforms, and software components matter to the organisation, we can monitor the external threat landscape with relevance instead of noise.
This is where MDR becomes more than monitoring. It becomes operationalised trust, supported by shared context, transparent investigation, and continuous collaboration.
Trust also requires transparency
But trust cannot be one-sided.
A strong MDR partnership is not built by simply asking clients to share more information with their security provider. It also requires transparency from the provider back to the client.
At Conscia, we believe clients should understand not only what we detect, but also how we work. They should be able to see what our analysts see, how investigations are handled, how conclusions are reached, and how response decisions are made. All in real-time.
That is why transparency is built into our MDR operating model.
Through our dedicated MDR Client Portal, clients gain visibility into security cases, analyst findings, response actions, asset information, indicator of compromise management and configurable response policies. Instead of treating MDR as a black box, the portal gives clients direct insight into how their environment is monitored and protected. It also allows them to actively shape how response should happen in line with their business risk, operational needs, and internal processes.
This matters because trust is easier to maintain when both sides have visibility.
Clients share knowledge about their assets, users, business processes, and priorities. We share insight into our detection logic, investigation process, analyst reasoning, and response approach. This two-way transparency creates a stronger security relationship than a traditional client-provider model.
It also makes cybersecurity more practical. When a client can see why something was escalated, why an action was taken, or how a conclusion was reached, security becomes less abstract. It becomes a shared operational discipline.
And because security decisions often need to happen quickly, this visibility should not be limited to a desktop experience. With our MDR mobile app, clients can access relevant information, review security activity, and stay connected to their MDR service more easily, even when they are away from their desk.
In a threat landscape where attackers exploit hidden assumptions and blind trust, transparency becomes a defensive advantage.
Observability – because business and IT are two sides of the same coin
As organisations grow more digital, even small performance or security issues can have an immediate impact on operations and the bottom line. Observability brings clarity by unifying real‑time perform…
Trust is not the weakness. Unexamined trust is.
Trust will always be part of business, and organisations cannot operate without trusted employees, trusted administrators, trusted vendors, trusted software, and trusted service providers.
But the mistake is treating trust as permanent.
Modern threat actors understand this better than many defenders, as they know that a valid credential can be more powerful than malware. They are aware that a trusted vendor can be a shortcut into many environments. They know that a legitimate software package can become a delivery mechanism. They know that normal business activity is the best camouflage.
So the future of cybersecurity is not about eliminating trust. It is about continuously validating it.
Zero Trust gives organisations an important architectural foundation. But resilient defence also requires intelligence, context, partnership, and continuous understanding of how the business actually operates.
That is where trust becomes a strength again.
Not assumed trust or blind trust, but nurtured, tested, intelligence-led trust between organisations and the security partners helping protect them.
About the author
David Kasabji
Head of Threat Intelligence
David Kasabji is the Head of Threat Intelligence at the Conscia Group. He leads the development and delivery of actionable intelligence across cyber defense and managed security operations, translating complex threat activity into clear outcomes for different audiences — from SOC analysts and incident responders to executive stakeholders and external communications. His work spans end-to-end intelligence operations: collection and analysis of adversary activity, threat actor and campaign profiling, IOC and TTP development, and intelligence-driven guidance for detection, threat hunting, and security prioritization. David is also actively involved in Digital Forensics and Incident Response, supporting investigations and crisis situations with rapid triage, context, and strategic recommendations. A strong focus of his role is continuously improving how intelligence is operationalized through standardization and automation to ensure it is timely, relevant, and measurable.nd strategic crisis management during incidents.
Related
