Internal Tools Security: Why Your Admin Portals Are Your Biggest Vulnerability
TLDR: In December 2024, a 19-year-old named Matthew Lane used stolen credentials to log into PowerSchool’s internal support portal — PowerSource. No MFA was required. The portal had a maintenance tool that gave engineers access to every customer’s student database. Lane used it to extract data on 62 million students and 9.5 million teachers — the largest breach of children’s personal data in US history. PowerSchool paid a $2.85 million ransom. The attackers extorted schools again five months later anyway. The portal that enabled all of this wasn’t the customer-facing product. It was the internal tool nobody had hardened.
The Door Nobody Locked
PowerSchool is not a small operation. They serve over 18,000 school organisations across 90 countries. Their software touches the daily lives of tens of millions of students. They have invested, in their own words, “significantly in cybersecurity.”
And yet their internal support portal — the tool their engineers used to remotely access customer databases for troubleshooting — had no multi-factor authentication. A username and password was all it took.
Matthew Lane, a 19-year-old student at Assumption University in Massachusetts, obtained those credentials — most likely through phishing. Between December 19 and 28, 2024, he logged in repeatedly, used a built-in “export data manager” maintenance tool, and methodically pulled the Students and Teachers tables from customer databases across the US and Canada. Names, dates of birth, Social Security numbers, medical alert information, contact details. Decades of records. All accessible through one internal tool with one set of compromised credentials.
The Department of Justice later confirmed a guilty plea. Lane was sentenced to four years in federal prison. The data, despite PowerSchool paying $2.85 million in Bitcoin, resurfaced for extortion five months later.
None of this required exploiting a single line of code. The door to one of the most sensitive datasets in American education was unlocked. All an attacker had to do was walk through it.
The Pattern Nobody Talks About
Here is something I see consistently during security assessments: organisations spend real money and real effort hardening their customer-facing application. Login flows have MFA. Sessions expire. Penetration tests are scoped to cover it. The public surface is treated like the threat surface.
Then there’s everything else.
The internal admin panel built in a sprint three years ago because the team needed a quick way to manage user accounts. The support dashboard that customer success uses — built by a developer who left the company in 2023, never formally documented, still live. The CI/CD interface. The staging environment with a clone of production data. The vendor access portal that gives your third-party contractor a window into your systems.
These tools were built for internal use. They were built quickly, for people who are trusted, to solve operational problems. Security wasn’t the priority — speed was. And unlike your main application, they don’t go through the same scrutiny, the same testing cycle, or the same hardening process.
That gap is where attackers go. Not because it’s clever. Because it’s easy.
What I Actually Find When I Test Internal Tools
Across assessments, these are the failures that appear most consistently in internal tooling:
No MFA on admin access. The PowerSchool story precisely. An admin portal protected by only a password is one phishing email, one credential database leak, or one reused password away from full compromise. This is especially critical given that MFA alone isn’t always enough — but having none is indefensible.
One portal that sees everything. PowerSource didn’t just see one customer’s data. It saw every customer’s data. Internal tools are frequently built with broad access because restricting access adds development friction. The result: a single compromised account unlocks the entire organisation’s data, not just one slice of it.
No access logging or alerting. Lane accessed PowerSource repeatedly over nine days before anyone noticed. Without logging that would flag “this account exported 62 million records across 1,200 customer databases,” there was no tripwire. Internal tools routinely lack the audit logging that customer-facing applications have as standard.
Shared credentials across team members. “We all just use the same login for the admin panel” is a sentence I hear more often than it should be possible. When credentials are shared, you lose the ability to attribute actions, rotate access when someone leaves, or scope access to what each person actually needs.
No session timeout. A session left open on an unattended laptop, a shared workstation, or a stolen device becomes a persistent entry point. Internal tools frequently have no session expiry because the people who built them find it annoying to log in repeatedly.
Accessible from the public internet without VPN. The most common version of this: a developer runs an admin panel, an internal API, or a staging environment on a public IP during development and never restricts access afterward. The staging environment sitting at staging.yourcompany.com with a copy of production data is accessible to anyone who finds it.
The Vendor Access Problem
The Coinbase insider case — which we covered in detail here — introduces another dimension: it’s not just your own team’s access that matters. It’s every third-party contractor, vendor, and integration partner who has been granted access to your internal systems.
Vendors need access to do their jobs. Support tools, monitoring dashboards, billing integrations, infrastructure providers — all of them hold credentials to parts of your internal infrastructure. The question most organisations haven’t answered is: how much access does each vendor actually need, and when was it last reviewed?
Broad vendor access doesn’t just create risk through attacks on the vendor. It creates risk through vendor employees, through compromised vendor credentials, and through vendor relationships that end but whose access is never revoked. Every vendor with standing access to your systems is an extension of your attack surface.
What You Can Do This Week
You don’t need a full security programme to address the most critical gaps. Start here:
Inventory every internal tool that touches sensitive data. Admin panels, support dashboards, CI/CD interfaces, staging environments, vendor portals. If you can’t name them all from memory, you have a discovery problem before you have a security problem.
Enforce MFA on every admin and internal tool — no exceptions. If the tool doesn’t support MFA natively, put it behind a VPN that requires MFA before it’s reachable. This one control would have prevented the PowerSchool breach entirely.
Restrict internal tools to VPN or IP allowlist. Your admin panel should not be accessible from the public internet. It should require the user to be on a trusted network or authenticated VPN first. This doesn’t eliminate risk — but it eliminates the most opportunistic attacks.
Audit vendor access quarterly. Pull a list of every third-party with access to your systems. Verify each one still needs it. Revoke access for vendors you no longer work with. For active vendors, apply the same principle as internal access: least privilege, scoped to what they actually need.
Enable access logging on every internal tool. You cannot investigate an incident without logs. And you cannot detect an ongoing attack — like nine days of systematic data exfiltration — without alerting on anomalous behaviour. If your internal tools don’t log who accessed what and when, that’s the first thing to fix. Check out our cloud security checklist for specifics on AWS-level logging.
How Kuboid Can Help
A security assessment that only tests your customer-facing application is testing half your attack surface. Our assessments cover the full picture — including internal tools, admin panels, staging environments, and vendor access configurations that fall outside the typical pen test scope.
If you’re not sure what internal tools your organisation has, who has access to them, or whether they’re hardened to the same standard as your main application, that’s exactly the conversation to have before an attacker has it for you. You can also explore our web application and infrastructure testing services to understand what a full-scope assessment looks like.
Has your team ever audited the security of your internal tools with the same rigour as your customer-facing product? Or is there an admin panel somewhere that was built quickly and never revisited? Drop a comment — this is one of the most common gaps we find, and one of the easiest to miss from the inside.
Kuboid provides full-scope security assessments for growing businesses — covering your entire attack surface, not just what your customers see. Learn more at kuboid.in/services.