Vendor Portal Attacks: How Attackers Are Using Your IT Firm’s Own Tools Against You in 2024-2025

Vendor portal attacks have quietly become one of the most effective and underreported entry points into small business IT environments. While headlines fixate on phishing and ransomware delivered to end users, a pattern emerging from 2024 and 2025 incident response disclosures tells a different and more alarming story: threat actors are walking in through the tools your IT company uses every day. Support ticketing platforms, remote monitoring software, and vendor management portals are being weaponized – not by breaking them, but by logging into them with credentials that look entirely legitimate. By the time anyone notices something is wrong, the attacker has already moved laterally, elevated their privileges, and positioned themselves for a much larger strike.

1. The Threat Landscape: Why Support Tooling Is the New Attack Surface
2. Who Is Actually at Risk
3. Real-World Disclosures: What the Data Shows
4. How These Attacks Actually Work
5. Why No User-Facing Alerts Fire
6. Defense Posture: What Sound Architecture Looks Like
7. What to Ask Your IT Firm Right Now

The Threat Landscape: Why Support Tooling Is the New Attack Surface

The security community has spent years hardening the perimeter: better email filtering, multi-factor authentication on user accounts, endpoint detection tools. Threat actors adapt. When the front door gets a deadbolt, they find the service entrance.

Support tooling is exactly that service entrance. Remote monitoring and management platforms, help desk ticketing systems, vendor-facing portals, and patch deployment consoles share one critical characteristic: they are explicitly designed to have broad, privileged access to every machine they manage. That is their value. It is also what makes them extraordinarily dangerous when compromised.

CISA has flagged vendor portal attacks repeatedly. The agency’s advisories on threats targeting IT provider tooling note that nation-state and criminal threat actors alike have pivoted to the technology layer that sits between IT providers and their clients. The logic is straightforward: compromise the IT firm’s tooling, and you inherit access to every business that firm manages – often without generating a single user-facing alert.

The 2024 Verizon Data Breach Investigations Report found that attacks involving third-party or vendor access continued to represent a disproportionate share of confirmed breaches relative to all attack vectors. The ratio of attack sophistication to detection difficulty is simply too favorable for attackers to ignore this surface.

Who Is Actually at Risk from Vendor Portal Attacks

The instinct is to assume this threat targets enterprises. It does not. Small businesses are disproportionately exposed for several reasons that compound each other.

First, small businesses rarely audit the access their IT vendor holds. Most business owners can name the software they use internally, but they cannot tell you what remote agent is installed on their servers, which vendor portal has administrative rights to their domain, or when those credentials were last rotated.

Second, small businesses are often managed by IT firms that themselves operate lean. A regional IT provider managing 50 or 100 small business clients is an extremely high-value target: one compromised credential set unlocks an entire client roster.

Third, the compliance and contractual pressure that forces larger organizations to audit third-party access is often absent at the small business level. There is no security questionnaire being returned, no vendor risk program reviewing what access was provisioned and when. The access simply exists, indefinitely, until something goes wrong.

Professional services firms, small healthcare practices, non-profits with board-accountable finances, and pharmaceutical consulting firms with international client obligations are all firmly in the crosshairs. The common thread is not industry – it is that someone at the top of the organization is personally accountable if data is lost or exfiltrated, and that person typically has no visibility into the vendor access layer underneath their IT environment.

Real-World Disclosures: What the Data Shows

Public breach disclosures and regulatory filings from 2024 and early 2025 paint a consistent picture of vendor portal attacks in action. The following are drawn from publicly available incident reports and CISA advisories, not from any single client engagement.

In late 2023 and into 2024, the Scattered Spider threat group demonstrated a refined approach to support channel abuse. Their documented technique involved calling legitimate IT help desks, social-engineering support staff into resetting credentials, and then using those credentials to access remote support tools directly. The FBI and CISA issued a joint advisory in November 2023 specifically warning about this group’s use of legitimate remote access software as a persistence mechanism after gaining initial access through social engineering.

The Change Healthcare breach of February 2024, while primarily associated with a ransomware group targeting healthcare infrastructure, produced disclosures that highlighted how vendor-facing portal credentials without multi-factor authentication allowed attackers to establish a foothold and move laterally over an extended dwell period – weeks of quiet access before the destructive phase of the attack began. That dwell time is the critical variable: long enough to map your environment, identify your most valuable data, and prepare a strike you will not see coming.

ConnectWise ScreenConnect, one of the most widely used remote support platforms in the managed services industry, disclosed critical vulnerabilities in February 2024 (CVE-2024-1708 and CVE-2024-1709) that were actively exploited within days of public disclosure. CISA added both to its Known Exploited Vulnerabilities catalog. What made these vulnerabilities particularly dangerous: exploitation required no interaction from the client organization’s users. The attack happened entirely within the tooling layer that clients never see or touch.

The pattern across these disclosures is consistent. The initial access vector in vendor portal attacks is either a credential compromise against the vendor portal layer, a vulnerability in the support tooling itself, or a social engineering attack against IT support staff. In none of these cases did end users at the targeted organizations receive alerts, click on anything, or do anything wrong. The entire attack surface was in the infrastructure layer between the business and its IT provider.

How Vendor Portal Attacks Actually Work

Understanding the mechanics matters because it reframes where defenses need to be placed.

The attack typically begins with one of three initial access techniques:

• Credential stuffing or phishing against the IT vendor’s own staff accounts, targeting the portals those staff use to manage client environments.
• Exploitation of a known or zero-day vulnerability in the remote monitoring or ticketing platform itself, bypassing authentication entirely.
• Social engineering of a help desk or support function – convincing a technician to take an action (password reset, multi-factor authentication bypass, session handoff) that hands the attacker a foothold.

Once inside the vendor tooling, the attacker does not act immediately. Dwell time in these attacks is measured in weeks, sometimes months. This phase is reconnaissance: understanding the client environment, mapping privileged accounts, identifying high-value data stores, and planning the lateral movement path that reaches the most valuable target without triggering anomaly detection.

Lateral movement through vendor tooling is particularly clean because the activity looks identical to legitimate IT management work. A remote monitoring agent pushing a script to a server, an administrative account querying Active Directory, a support session connecting to a file server – these are all things your IT company does every day. Attackers operating through that same tooling generate exactly the same event signatures, which is why conventional alert logic fails to catch them.

Privilege escalation follows the lateral movement phase. Because vendor portals are often provisioned with domain-level administrative rights – they need those rights to do their job – an attacker may already hold the keys to your entire environment from the moment of initial access. In environments where the vendor’s service account has not been scoped to least-privilege principles, there is nothing left to escalate. The blast radius is total from the first moment of access.

Why No User-Facing Alerts Fire During Vendor Portal Attacks

This is the detail that most small business owners find genuinely surprising: a sophisticated attacker operating through compromised vendor tooling can maintain access to your environment for weeks or months, exfiltrate data, and position ransomware for deployment without any of your users receiving a single warning.

The reason is architectural. User-facing security controls are designed to detect anomalous behavior by user accounts. They watch for a user logging in from an unusual location, accessing files outside their normal pattern, or sending large volumes of data outbound. None of those signatures apply to an attacker operating within a vendor service account or a remote management platform, because those accounts are expected to do exactly those things.

Endpoint detection tools look at process behavior on individual machines. They are largely blind to activity that occurs through a legitimate remote management agent, because that agent is itself a trusted process with elevated permissions. Flagging a trusted IT management tool as malicious would generate constant false positives in a legitimately managed environment, so detection thresholds are typically tuned to exclude it.

Ticketing and support systems do not have anomaly detection by default. If an attacker opens a support ticket through a compromised portal account, the system processes it. If they modify a ticket to escalate a request or alter workflow routing, that too is processed. These are features, not exceptions – and security monitoring rarely extends into the ticketing layer at the small business level.

The result is a detection gap that is structural rather than operational. It cannot be closed by telling users to be more vigilant. It requires architectural work at the vendor access and tooling layer – which is precisely why vendor portal attacks remain so effective against organizations of every size.

Defense Posture: Closing the Vendor Portal Attack Surface

Closing the vendor portal attack surface requires deliberate choices about how vendor access is provisioned, monitored, and scoped. The following practices reflect what a well-architected managed environment should include – and what you should be able to verify your IT firm has actually built.

• Least-privilege provisioning for all vendor service accounts. The account your IT firm uses to manage your servers should have access to exactly the systems it needs, for exactly the functions it performs, and nothing more. Domain administrator rights on a service account that manages patch deployment is a misconfiguration, not a necessity.
• Multi-factor authentication on every vendor portal login, without exception. The Citrix Bleed vulnerability (CVE-2023-4966), the ConnectWise vulnerabilities, and the Scattered Spider social engineering playbook all either targeted or bypassed multi-factor authentication gaps in the vendor access layer. There is no justification for a vendor portal account without it in 2025.
• Logging and alerting on vendor account activity, separate from the vendor’s own logging. If the only record of what your IT firm did in your environment lives in your IT firm’s systems, you have no independent audit trail. Client-side logging that the vendor cannot modify is a basic integrity control.
• Regular access reviews for all vendor-provisioned accounts. Former IT vendors, former employees of current IT vendors, and deprecated integrations are all sources of orphaned privileged access. A semi-annual review of what service accounts exist and what they can reach is not optional at this threat level.
• Network segmentation that limits lateral movement paths. Even if an attacker establishes a foothold through vendor tooling, segmentation limits how far they can travel. A remote support agent that can reach your file server should not be able to reach your backup system, accounting database, or email archive in the same network hop.
• Prompt patching of vendor tooling with a defined schedule. The ConnectWise ScreenConnect vulnerabilities were exploited in the wild within 48 hours of public disclosure. An IT environment where the IT firm’s own tools are not patched on a defined and auditable schedule cannot defend against vendor portal attacks.

For small businesses evaluating their current IT relationship, the question is not whether your IT firm uses these tools. They do, and the tools are not inherently the problem. The question is whether the firm has built the access controls, audit logging, and least-privilege architecture around those tools that the current threat environment demands. An IT firm that treats its own access as self-evidently trustworthy – and therefore unmonitored and unscoped – has not internalized what the 2024-2025 disclosure record actually shows about vendor portal attacks.

At Xact IT Solutions, this architectural discipline is what has produced a zero-client-breach record across every engagement since our founding in 2004. We build environments that do not require constant human intervention to stay secure – and our own access to client environments is governed by the same standards we recommend to clients. Learn more about our approach to cybersecurity architecture for small and mid-sized businesses, or explore our full suite of managed IT services built on this security-first foundation.

What to Ask Your IT Firm Right Now About Vendor Portal Attack Exposure

These are not trick questions. A competent IT firm will answer them clearly and without defensiveness. Evasion or confusion in response to any of them is itself a signal worth taking seriously.

• What service accounts does your firm hold in my environment, and what permissions are attached to each one?
• Are those accounts protected with multi-factor authentication on your side?
• Where are the logs of activity performed under those accounts, and do I have independent access to those logs?
• What is your patch schedule for the remote monitoring and support tools you use to manage my environment?
• If one of your own staff accounts were compromised tomorrow, what controls would limit the blast radius in my environment?
• Have you had an independent security review of your own internal tooling and access controls within the last 12 months?
• What is the process for revoking your access to my environment if I ever need to change providers?

These questions move the conversation from abstract trust to concrete controls – which is exactly where it needs to be, given what the 2024-2025 incident record shows about vendor portal attacks.

The businesses that come through the next major vendor-channel breach without incident will not be the ones with the most vigilant users. They will be the ones whose IT relationships were built on architectural discipline rather than implicit trust in tooling that was never designed to be the last line of defense. Threat actors already know this. The question is whether your IT firm does.

If you want a straight answer on where your environment stands, Book a Free Cybersecurity Strategy Call. Twenty minutes. No pressure. We will tell you what we see.