Risks from third parties developing internal tools

Ask a security team at a real estate, retail or manufacturing company to name its riskiest vendors, and you'll usually hear about SaaS platforms, payment processors and cloud providers. Those vendors went through onboarding. They filled out questionnaires. They have SOC 2 reports on file.

The vendor we want to talk about never went through any of that. It had admin access to production, it deployed code whenever it needed to, and its email domain was easy to impersonate. The TPRM program didn't know it existed, because the system it worked on was called "internal".

This is a real finding from a recent Lema engagement, anonymized. It shows a blind spot that's especially common in traditional industries: the small service providers who build and run the systems you think of as in-house.

An app full of sensitive data

The company is a large US commercial real estate owner and operator. It runs an in-house app to manage physical security across a large portfolio of retail properties. Security directors and guards use it to log incidents, track assets and file reports.

It's the system of record for physical security, and the data in it is sensitive:

• Names, descriptions and photos of shoplifting suspects
• Records of injured visitors
• People who were given trespass notices
• Incidents involving minors

By any reasonable standard, a vendor holding this data would be rated critical. In fact, the company's TPRM team had already assessed an outside SaaS product that does the same job, and rated it Critical.

The in-house app was never assessed at all. It was "internal", so it never entered the TPRM process.

Who actually maintains the "internal" app

"Internal" described who owned the app, not who worked on it. A small custom software development firm maintains it. The firm took over from a previous development firm, and its engineers:

• Have their own accounts inside the company's environment
• Hold local admin on production servers, including the right to install software
• Deploy code directly to production

That's privileged, ongoing access to a critical system, held by a company that was never onboarded as a vendor.

Anyone could send email as the vendor

We ran a simple outside-in check on the firm's email domain:

The vendor's domain had no DMARC policy, and none of its subdomains had SPF. Nothing told receiving mail servers to reject a message that faked the vendor's address. That made impersonating them cheap and easy.

The subdomains matter. The vendor has about a dozen, including API and production app hosts. An attacker could send from an address like deploy@app.vendor.com, which looks even more believable in a "please approve tonight's release" email.

Why DMARC is the piece that counts: SPF, where it exists, only checks a hidden technical sender address, not the From name and address people see in their inbox. DMARC is what ties authentication to that visible From address. Without it, there's no instruction to reject a fake.

Some mail filters apply their own rules and may still catch a fake email, so success isn't guaranteed. But spoofing this vendor is much easier than it should be.

The vendor's website named the client

The firm's website also features a case study about this engagement. It names the client, names the app and describes the maintenance work.

Put those together and an attacker has everything needed for a convincing phishing email:

• Who to impersonate: the vendor, whose domain has no DMARC
• Who to target: the people at the company who work with that vendor
• What to write: "Please approve this access request for tonight's release." Or: "Our bank details have changed."

Target breach started the same way

None of this needs a zero-day. It needs public information, a trusted relationship and one person who acts on a believable request. Two well-known cases show how it plays out.

Target (2013). Attackers first compromised Target's HVAC and refrigeration contractor with an email malware attack. They then used the contractor's stolen network credentials to get into Target's network, and eventually stole data on about 40 million payment cards. A small service provider with access was the way in. (KrebsOnSecurity, follow-up)

Our case combines both patterns: a small provider with privileged access, and a public page that tells an attacker exactly who to impersonate and what to say.

What the vendor access looked like from inside

The email gap was the outside view. The company's own endpoint data showed what an unmanaged vendor relationship looks like from the inside:

• The previous firm was never fully offboarded. Two accounts that most likely belonged to the previous provider were still active. Services still ran under one of them. Together they had produced hundreds of thousands of failed logins, and no one had noticed.
• Vendor accounts without clear owners. Some non-employee accounts with install rights on production couldn't be tied to a named person. One confirmed vendor admin account hadn't changed its password in more than a year. There was no list of which vendor people should have access.
• A shared Domain Admin account with no owner existed on every server in the app's environment, and it had been used recently.
• A second provider with a half-open door. The company's managed service provider could reach the app's servers over the network but had no working login. Either the network access was never removed, or the logins were never set up.

None of these are exotic. They're what happens when nobody owns the vendor relationship.

How we found it, and why TPRM missed it

The discovery started inside the environment, not outside it:

1. We analyzed host metadata from the company's EDR to find servers it runs together with an outside provider.
2. We matched each of those server environments to the provider behind it.
3. That led us to the vendor, and to its public case study naming the client and the app.
4. We ran outside-in checks on the vendor's domain and found the email-authentication gap.

To be clear, step 4 is easy. Once you know who the vendor is, anyone can run a DNS lookup. The hard part is step 1: the vendor wasn't in any inventory.

That's why existing tools didn't catch it:

• Questionnaires and security ratings only cover vendors the TPRM program already knows about.
• Security tools can see the accounts, but they don't know there's a vendor relationship behind them. At best they open a ticket to fix a setting.

Lema connects the two sides. Inside telemetry reveals the vendor. TPRM context sets the risk level: a comparable vendor was already rated Critical. And the result is a vendor action, not just a config ticket. You onboard the vendor, restrict it, renegotiate, re-review or offboard it.

What we recommended

If this pattern sounds familiar, these are the steps we recommended:

• Onboard the development firm as a vendor. Rate the app's inherent risk the same way you'd rate a SaaS product doing the same job. Here, that meant Critical.
• Require DMARC from vendors with privileged access. Ask the vendor to publish a DMARC policy and move to p=reject. Make email authentication a contract requirement.
• Verify access and payment requests out of band. Any request to approve access, add a user or change bank details gets confirmed another way, like a call to a known phone number.
• Keep a list of approved vendor accounts. Record which named vendor people have which access. Remove everything else.
• Finish offboarding previous providers. Disable their accounts and move any services still running under them.
• Give every shared admin account an owner, or remove it.
• Add a marketing-disclosure clause to vendor contracts. Vendors shouldn't publicly name you, your internal systems or their access without your approval.

Takeaways for traditional industries

• Your riskiest vendors may not be your SaaS apps. They may be the small firms that build and run your "internal" systems: dev shops, MSPs, building-systems integrators.
• "Internal app" is a TPRM blind spot. If an outside party writes the code, deploys it or holds admin access, it's a third party.
• Small providers often have basic gaps, like missing email authentication, stale accounts and shared admin accounts. They also tend to advertise their clients, which makes impersonating them easy.
• Vendor handovers leave leftovers. When one provider replaces another, the old provider's access often stays behind.
• You can't manage vendors you don't know about. Find them where they actually work: inside your environment.

This isn't a one-off

The same engagement turned up more of the same pattern:

• A building-automation integrator's service account was local admin on dozens of building-control servers. Its password hadn't changed in about a decade, and it was still being used for remote-desktop logins this year.
• Hundreds of hosts ran two or three remote-management tools at once, one of them a years-old version predating a well-known authentication-bypass fix. Each tool is another outside party with a way in.

Sources

• KrebsOnSecurity, Target Hackers Broke in Via HVAC Company (Feb 5, 2014)
• KrebsOnSecurity, Email Attack on Vendor Set Up Breach at Target (Feb 12, 2014)
• TechCrunch, MGM Resorts cyberattack and Scattered Spider (Sep 14, 2023)
• BleepingComputer, MGM Resorts ransomware attack led to $100 million loss