Supplier Hack Scenario: Your IT Service Provider Has Been Compromised

TL;DR

When your IT service provider is compromised, you must assume that your systems are also affected — because the provider typically has admin access to your infrastructure.
Immediate measure number one: Cut all provider access. Close VPN tunnels, disable remote access tools, lock all accounts used by the provider.
Do not blindly trust the provider's information about the scope of the compromise. Conduct your own independent assessment of your systems.
NIS2 sets explicit requirements for supply chain security. Companies must contractually regulate and regularly verify the security practices of their service providers.
The incident is a wake-up call to rethink the service provider relationship: How much access does the provider actually need? Is there a just-in-time access model? Are accesses logged and monitored?

Monday, 11:23 AM: The Call That Changes Everything

Fischer Medizintechnik GmbH develops and distributes diagnostic devices for medical practices. 85 employees, based in Freiburg, certified under ISO 13485 (medical devices) and ISO 27001. IT is largely managed by a Managed Service Provider (MSP) called ComTech Solutions. ComTech administers the servers, Active Directory, firewall, and backup system for Fischer Medizintechnik. For this purpose, ComTech has a permanent VPN tunnel and several admin accounts in Fischer GmbH's domain.

On Monday morning at 11:23 AM, ComTech's CEO personally calls IT manager Katharina Berger. He sounds tense.

"Katharina, I need to inform you about a security incident. Over the weekend, we discovered that our internal RMM system was compromised. The attackers had access to our remote management tool, which we use to administer our clients' systems. We cannot rule out that your systems are also affected. We are working with forensic investigators and will keep you updated."

RMM stands for Remote Monitoring and Management. It is the central tool MSPs use to remotely manage their clients' IT systems. Anyone with access to an MSP's RMM system potentially has admin access to all client systems managed through it. For a mid-sized MSP like ComTech, that typically means 30 to 80 companies.

Katharina immediately understands the implications. The next few hours will determine whether Fischer Medizintechnik is only a potential victim or an actual one.

Why Supply Chain Attacks Are So Dangerous

Before we continue with the timeline, a look at the mechanism. Supply chain attacks are among the most effective forms of attack because they exploit the trust relationship between a company and its service providers. The attacker does not compromise the actual target but rather a supplier that has privileged access to the target's systems.

For attackers, this model offers an enormous scaling effect: instead of attacking 50 companies individually, they compromise the one MSP that manages all 50. A successful attack on the MSP's RMM system opens 50 doors simultaneously.

Well-known examples like Kaseya (2021) and SolarWinds (2020) have shown that even large, security-conscious organizations can be hit through their supply chain. The article on supply chain attacks describes the various attack vectors in detail. In SMEs, where MSP relationships are often based on trust and handshakes and contractual security requirements are thin, the risk is even higher.

Monday, 11:30 AM: Immediate Measures

Katharina has 15 minutes to make the right decisions. She reaches for the emergency plan and simultaneously calls her remaining in-house IT colleague Thomas.

Immediate Measure 1: Cut All Provider Access

This is the most important measure and it must happen immediately — before management is informed, before the extent is known, before anyone can say "But we need ComTech for support."

Katharina and Thomas execute the following steps over the next 20 minutes:

Close the VPN tunnel. The firewall has a site-to-site VPN tunnel to ComTech. Katharina deactivates the tunnel on her own firewall. This severs the permanent network connection to the MSP.

Disable the RMM agent. On every server and every managed client at Fischer Medizintechnik, a ComTech RMM agent is running — a small program that enables remote access for the MSP. If the MSP's RMM system is compromised, this agent is the direct attack vector. Thomas disables the agent on all servers via Group Policy and creates a script that stops the agent on all clients. This takes about 30 minutes for the servers and up to two hours for all clients.

Lock all MSP accounts. ComTech has three named admin accounts in Fischer GmbH's Active Directory domain. Katharina disables all three and resets their passwords. Additionally, she checks whether ComTech has access to other systems that do not authenticate through Active Directory: firewall management, backup software, hypervisor. These access points are also locked.

Block Remote Desktop access. In addition to the VPN tunnel, ComTech had a fallback connection through a Remote Desktop Gateway. Katharina disables the gateway access for all external sources.

Immediate Measure 2: Check Your Own Systems

The fact that ComTech has been compromised does not automatically mean Fischer Medizintechnik has been compromised as well. But it must be assumed until proven otherwise. Katharina starts a first visual inspection:

Are there unknown admin accounts in Active Directory?
Are there suspicious scheduled tasks on the servers?
Do the firewall logs show unusual outbound connections?
Are there logins from ComTech accounts at unusual times (weekends, nights)?

The initial inspection reveals no obvious anomalies, but Katharina knows this means little. A professional attacker rarely leaves obvious traces. The deep analysis must be handled by an external forensic investigator.

Immediate Measure 3: Inform Management

Katharina informs CEO Dr. Fischer personally, not by email. She describes three things: what happened (MSP compromised), what she has done (all access cut), and what she needs (approval for external forensics and a decision about continued operations).

Dr. Fischer asks the question every CEO asks in this situation: "How long will we be without IT support?" Katharina's honest answer: "We can keep the basic systems running ourselves. But major changes, patches, and backup management have been handled by ComTech. If we need to cover that internally, I'll need short-term external support from a different provider."

Monday, 02:00 PM: The Uncomfortable Truth About Provider Access

While Thomas exports the firewall logs from the last 30 days, Katharina takes an hour to document the actual scope of ComTech's access. The result is sobering:

ComTech had access to:

All Windows servers (Domain Admin)
The firewall (Full Admin)
The backup system (Full Admin)
The hypervisor (Full Admin)
The network switches (Full Admin)
Every single client via the RMM agent (SYSTEM-level rights)

ComTech did not have:

Access to the ERP system (separate vendor support)
Access to the development systems (separate network, self-managed)
Physical access to the server room

In other words: ComTech had the same rights as an internal IT administrator. In normal operations, that is convenient; in a compromise scenario, it is a nightmare. Because the attacker potentially had the same access through the RMM system that ComTech uses in daily operations.

Katharina notes: After this incident, the access model must be fundamentally revised.

Tuesday: Forensics and Assessment

The external forensic investigator begins analysis on Tuesday morning. The task is clearly defined: determine whether Fischer Medizintechnik's systems were actually attacked through the compromised MSP access.

The Analysis

The forensic investigator checks multiple data sources:

RMM logs. The local logs of the RMM agent on Fischer GmbH's servers show which actions were performed through the tool. The analysis reveals: in the last two weeks, there were three sessions through the RMM tool that do not match the usual patterns — two of them over the past weekend, when ComTech claims to have discovered the incident. The sessions executed PowerShell commands that appear to be reconnaissance activities: reading user accounts, network shares, and installed software.

Active Directory logs. No new suspicious accounts, no changes to group memberships. This suggests the attacker was in the reconnaissance phase and had not yet established persistence.

Firewall logs. No unusual outbound connections, no data exfiltration detected.

Conclusion. The attacker was active on Fischer Medizintechnik's systems, but the compromise is at an early stage. Reconnaissance was conducted, but no exfiltration or persistence was established. Katharina's quick response — cutting all access within an hour of the call — likely prevented the attack from escalating further.

Reset Anyway

Even though no deep damage is found, the forensic investigator recommends a comprehensive credential reset. All admin passwords are changed, the krbtgt account is double-reset, and all service account passwords are renewed. The rationale: it cannot be ruled out with absolute certainty that the attacker extracted credentials that are not visible in the logs.

Wednesday: Communication on All Levels

Communication with ComTech

Katharina conducts a structured conversation with ComTech. She wants answers to specific questions:

When exactly was the compromise discovered, and when did it actually begin?
Which clients are affected, and how were they prioritized?
What forensic measures has ComTech taken?
What information can ComTech provide about activities on Fischer GmbH's systems?
What specific security measures will ComTech implement before collaboration resumes?

ComTech can answer some questions, others not. Forensics is still ongoing. What strikes Katharina: ComTech discovered the incident over the weekend but only informed her on Monday morning. When asked about the delay, ComTech says they wanted to stabilize their own systems before informing clients. Katharina notes: the contractual agreement with the MSP contains no defined notification timeline for security incidents. That will change.

Communication with Authorities

Katharina reviews reporting obligations:

NIS2. Fischer Medizintechnik, as a manufacturer of medical devices, falls under NIS2 regulation. The incident must be reported to the BSI as an initial notification within 24 hours, even though the company's own compromise was limited. The incident potentially impacted the availability and integrity of systems.

GDPR. Since the forensic investigator confirmed the attacker conducted reconnaissance activities but did not exfiltrate data, the GDPR reporting obligation is a borderline case. Katharina decides, in consultation with the data protection officer, to file a voluntary notification — to be on the safe side in case further impacts are discovered later.

Communication with Customers

Fischer Medizintechnik distributes diagnostic devices to medical practices and clinics that can view device data through a cloud portal. Katharina checks whether this portal is affected in any way. The portal runs on a separate cloud infrastructure not managed by ComTech. Nevertheless, she proactively informs key customers that there was a security incident at an IT service provider and that precautionary measures have been taken.

Week 2: Reassessing the Service Provider Relationship

The acute incident is resolved, but the real work begins now: a fundamental overhaul of the collaboration with IT service providers.

Revising the Access Model

The previous model was simple and convenient: permanent VPN tunnel, permanent admin access, RMM agent on every system. This model is replaced by a more restrictive one:

Just-in-time access. ComTech no longer receives permanent admin access. Instead, a system is set up where ComTech employees must request time-limited access for a specific task. Access is automatically deactivated once the task is completed. This requires more effort but drastically reduces the attack surface.

Separate credentials. The admin accounts ComTech uses are separated from internal admin accounts. ComTech accounts only have the permissions necessary for the respective task — not blanket domain admin rights.

Session recording. All ComTech access to Fischer GmbH's systems is recorded. Not for surveillance, but for traceability and in case of another incident.

Replace the RMM agent. The previous RMM agent, which had SYSTEM-level rights and maintained a permanent connection to ComTech's management server, is replaced with a more restrictive remote access tool that is only active on demand and whose connections are logged.

Contractual Adjustments

Katharina works with the company's lawyer to draft an amendment to the MSP contract. The supplier security policy serves as the foundation:

Notification obligation. ComTech must notify Fischer GmbH within four hours of discovering a security incident that potentially affects client systems. Notification must be in writing and contain the known facts.

Security audits. Fischer GmbH is granted the right to conduct an annual security review of the relevant ComTech systems or to have one conducted by an independent third party.

Security standards. ComTech must maintain a minimum level of security standards: MFA for all admin access, encrypted communication, regular penetration testing of their own RMM system, documented patch management.

Liability. The liability provision is adjusted: in cases of demonstrable negligence (such as missing security updates for the RMM system), ComTech is liable for the direct damages caused to the customer by the compromise.

Exit strategy. The contract includes a clear provision for termination of the collaboration: handover of all credentials, documentation, configurations, and the complete deactivation of all ComTech access within 48 hours.

NIS2 and the Supply Chain

NIS2 sets explicit requirements in Art. 21(2)(d) for the "security of the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." This means specifically:

Risk assessment of suppliers. Companies must systematically assess the security risks of their service providers, for example using a security questionnaire. An MSP with admin access to the entire IT infrastructure is a high-risk supplier and must be treated accordingly.

Contractual security requirements. Security requirements for the service provider must be contractually fixed — not as a vague statement of intent but as specific, verifiable requirements.

Regular verification. Compliance with the agreed security standards must be regularly verified — through audits, certification evidence, or security questionnaires.

Incident response coordination. For incidents at the service provider, a coordinated process must exist: who informs whom, within what timeframe, through which channel, and what immediate measures are triggered.

The Alternative Provider

Katharina uses the incident to evaluate a dual-vendor concept. The dependency on a single MSP was one of the greatest risk factors. If ComTech disappears from the market tomorrow or is compromised again, Fischer GmbH has no IT support.

The solution: Critical competencies are built internally (a second IT employee is hired), and for specialized tasks, a second provider with a framework contract is engaged who can step in during emergencies.

Lessons Learned

Three weeks after the incident, Katharina conducts the lessons-learned workshop. The key findings concern less the technical response (which was good) than the structural prerequisites:

What worked:

The fast response within an hour of the call limited the compromise to the reconnaissance phase
The separate management of development systems and the cloud portal prevented critical areas from being affected
The incident response plan had a chapter on "Provider compromise" that structured the first steps

What did not work:

The permanent VPN tunnel and permanent admin access created an unnecessarily large attack surface
There was no monitoring of provider access; RMM activities were not logged
The contractual security requirements for ComTech were insufficient: no notification timeline, no audit rights, no defined security standards
There was no plan B for the case that ComTech fails

The most important takeaway: Trust is not a security strategy. In ISMS Lite, service provider relationships can be documented, security requirements tracked, and incidents from supply chain events reviewed in a structured manner. The relationship with an MSP must be based on the same principles as any other security-critical relationship: minimal rights, maximum transparency, contractual safeguards, and regular verification. This applies regardless of how long the collaboration has existed and how trustworthy the partner appears.