DEV Community: Charles P

11 Months Undetected: Inside a Silent Data Exfiltration Through a Trusted Vendor's Remote-Access Tool

Charles P — Mon, 27 Apr 2026 19:44:18 +0000

The Call That Changed Everything

It started with an anomaly that almost nobody noticed.

A regional accounting firm — mid-sized, 60+ employees, handling tax filings and financial audits for hundreds of business clients — reached out after their cyber insurance provider flagged unusual outbound traffic during a routine policy renewal review. The firm's internal IT contact assumed it was a misconfigured backup job. It wasn't.

What we uncovered over the next several weeks was eleven months of silent, systematic data exfiltration. Client financial records, PII, tax identification numbers, business banking details. All of it leaving the network through a vector nobody had thought to question: a remote-access tool installed by a third-party payroll software vendor.

This is the story of how it happened, how we found it, and what it took to contain the damage without destroying the trust that firm had spent decades building.

The Attack Vector Nobody Audited

The vendor in question was a legitimate payroll software company the firm had used for years. During a routine product update roughly eleven months prior, the vendor's support team had remotely installed a lightweight remote desktop agent — standard practice for troubleshooting. The installation was authorized. The agent itself was legitimate.

The problem: the vendor had been compromised. Attackers had obtained credentials to the vendor's internal support infrastructure and were using it as a launchpad into every client environment where their remote-access agent was deployed.

This is a classic supply chain intrusion, and it's devastatingly effective because:

The remote-access tool is already trusted by endpoint security
Traffic originates from a known, whitelisted IP range
The activity looks like normal vendor support behavior
There's no malware on the victim's systems to detect

The attackers weren't noisy. They exfiltrated data in small, irregular bursts — typically during business hours, mimicking legitimate support sessions. Over eleven months, they systematically harvested the firm's file shares.

How We Uncovered It

The insurance provider's anomaly flag gave us a starting point, but it was vague: elevated outbound data volume to a third-party IP. Our investigation began with log analysis.

# Reconstructing outbound session data from firewall logs
grep "PERMIT" firewall.log | awk '{print $6, $7, $8, $12}' \
  | sort -k4 -rn \
  | head -50

Sorting by data volume revealed dozens of sessions to a single IP range — all attributed in the logs to the payroll vendor's support domain. At first glance, nothing alarming. But cross-referencing timestamps with the vendor's actual support ticket history showed a critical gap: most of these sessions had no corresponding support ticket.

We then pulled endpoint telemetry from the remote-access agent's own activity logs:

[2023-03-14 10:42:17] Session initiated — user: vendor_support_01
[2023-03-14 10:42:19] File browse: \\FILESERVER01\ClientRecords\2022\
[2023-03-14 10:43:04] File copy: 47 files transferred
[2023-03-14 10:43:31] Session closed

No support ticket. No email from the client requesting help. A session opened, files copied, session closed. Repeated hundreds of times across eleven months.

The attacker was methodical. They never triggered volume thresholds that would have alerted on a single session. They rotated through directories slowly, never grabbing everything at once.

Containment: What You Do and Don't Do

Here's where firms make their worst mistakes. The instinct is to immediately kill everything — terminate vendor access, wipe affected systems, rotate all credentials simultaneously. That instinct can destroy forensic evidence and tip off attackers to cover their tracks before you've mapped the full scope.

Our containment sequence:

Isolate, don't disconnect. We moved the compromised file server to a quarantine VLAN before terminating vendor access. This preserved live artifacts.
Snapshot before remediation. Full disk images before any credential rotation or system changes.
Notify vendor security team in parallel. They confirmed their support infrastructure had been compromised. Eleven other clients were affected.
Map the blast radius. Using the session logs, we reconstructed exactly which directories, which files, which client records were accessed. This took four days.
Staged credential rotation. Rotating everything at once in an active environment causes outages. We sequenced rotations across 72 hours.

The Client Relationship Problem Is Harder Than the Technical Problem

This is what the incident response playbooks don't tell you: notifying clients of a breach involving their financial data, when you're a firm whose entire value proposition is trust, is existentially dangerous.

The firm had approximately 340 business clients whose data may have been accessed. Legal counsel advised notification within the breach window required by their state. We advised being specific about what was and wasn't accessed, rather than issuing a vague blanket notification.

The session logs saved them. Because we could reconstruct precisely which client folders were accessed in which sessions, the firm was able to notify clients with specific detail:

"Your 2021 and 2022 tax filing records were accessed in three sessions between April and June 2023. The following file types were involved..."

Specificity is uncomfortable. It's also the only thing that preserves credibility. Clients who received vague "we may have had an incident" letters were more likely to churn. Clients who received detailed, honest disclosures with a clear remediation timeline largely stayed.

What Should Have Prevented This

The hard truth: this breach was preventable with controls the firm hadn't prioritized.

Vendor access reviews. A quarterly audit of all active third-party remote-access agents would have caught an agent with no recent legitimate sessions.
Session logging with anomaly baselining. If you authorize vendor remote access, log every session and baseline what "normal" looks like.
Just-in-time access. Rather than a persistent always-on agent, require vendors to request access for a defined window. The agent activates, the session occurs, the access closes.
Outbound DLP rules. Even basic data-volume thresholds per destination IP would have flagged this within weeks, not months.

If you're evaluating your own third-party access posture and aren't sure where to start, the advisory team at www.asktechgurus.com has published vendor risk frameworks specifically designed for professional services firms managing sensitive client data.

The Lesson That Doesn't Age

Supply chain attacks succeed not because defenders are incompetent, but because they extend trust to familiar names and stop asking questions. The remote-access agent was legitimate. The vendor was legitimate. The traffic looked legitimate.

The attackers exploited a gap between authorized and audited.

Every tool you've permitted into your environment is a door. The question isn't whether you trust whoever gave you the key — it's whether you're watching who walks through.

Eleven months is a long time for a door to be open.

I Applied to 47 Internships Across 6 Spreadsheets and Still Blew It: A Postmortem

Charles P — Mon, 27 Apr 2026 19:11:36 +0000

Let me tell you about the most embarrassing professional mistake I made as a CS student. I missed a follow-up deadline for an internship offer — not because I didn't care, but because I had buried it under six layers of organizational chaos I genuinely believed was "a system."

This is that story. It's cringeworthy. It's specific. And if you're managing your internship hunt with a patchwork of spreadsheets, sticky notes, and gut feelings, you need to read it.

The Setup: Six Spreadsheets and a False Sense of Control

By February of my junior year, I had applied to 47 internships. Here's what my "tracking system" actually looked like:

Sheet 1 — "Applications Master List" (last updated January 3rd)
Sheet 2 — "FAANG + Big Tech" (a separate tab because these felt special)
Sheet 3 — "Startups 2024" (copied from a Reddit post, half the companies were dead)
Sheet 4 — "Applied But No Portal Confirmation" (a graveyard)
Sheet 5 — a friend's shared doc I had been given edit access to "for inspiration"
Sheet 6 — an export from LinkedIn's saved jobs feature that I reformatted exactly once

Then there were the sticky notes. Three of them. On my monitor. One said "FOLLOW UP - APEX???" with two question marks. Another said "Resume v7 or v8??" The third was a phone number with no name attached. I never figured out whose it was.

Each spreadsheet had slightly different columns. Some tracked "date applied." Some tracked "last contact." Some had a status column with values like "applied," "waiting," "maybe?", and — I'm not kidding — "vibes."

What Actually Happened

In early March, a mid-size fintech company sent me an offer letter via email. It was a real offer. Competitive pay, good location, solid team. They gave me a 10-day window to respond.

I saw the email. I remember feeling genuinely excited. I opened one of my spreadsheets, looked for the company name, didn't find it immediately, told myself I'd log it "later," and then got distracted by a problem set.

I logged it four days later — in the wrong spreadsheet. Under the company's parent company name, which I only half-remembered. The deadline column said "March 19th" but I had typed it wrong. It was actually March 17th.

On March 18th, I was catching up on emails and saw the offer. I also saw a follow-up from their recruiter sent March 16th asking if I had questions. I had never replied to that either.

I emailed them the morning of March 19th, apologized, said I was still interested. They had already extended the offer to another candidate. Offer rescinded. Done.

The Technical Failure Analysis

If you treat your job search like an engineering problem (you should), here's what went wrong at a systems level:

Single point of failure: human memory. My spreadsheets were write-only. I wrote data in but had no mechanism for surfacing critical deadlines proactively. A calendar reminder, a cron job, literally anything automated would have caught this.

No canonical source of truth. Six spreadsheets means six chances for data to be stale, duplicated, or wrong. Every lookup required reconciling multiple sources mentally. That's O(n) cognitive overhead per decision.

Status fields were undefined. "Vibes" is not a status. "Maybe?" is not actionable. I had no consistent finite state machine for applications: Applied → Screen Scheduled → Interview → Offer → Decision Due → Accepted/Rejected. Without clear states, I couldn't see what actually needed attention.

No deadline-first view. Every spreadsheet was sorted by company name or date applied — not by urgency. The most important row was buried alphabetically under "F."

What I Should Have Done Differently

Centralize immediately. One place. Non-negotiable. Every application gets logged the moment you submit, not later.

Deadline tracking is primary, not a column. Deadlines should drive your dashboard. You should open your tracker and see "3 things need action in the next 48 hours" before you see anything else.

Status as a finite state machine. Define your stages and stick to them. Knowing an application is in "Offer Received — Decision Due March 17" is operationally different from "offer!!!" in a cell somewhere.

Automate reminders. Even a simple Google Apps Script that emails you when a deadline column is within 72 hours would have saved me. Spreadsheets can do this. Set it up once.

After that disaster I eventually rebuilt my workflow from scratch — I ended up building InternshipTracker partly because I wanted something that treated deadlines as first-class objects rather than afterthoughts buried in a column.

The Broader Lesson

The painful irony is that I had more data than most of my peers. 47 applications. Six tracking documents. I was thorough in the wrong direction — optimizing for logging breadth instead of decision support.

Your tracking system isn't a historical record. It's a control panel. It should answer one question at any given moment: what do I need to do right now?

If your spreadsheet can't answer that without you mentally joining tables across six tabs, it's not a system. It's archaeology.

Don't let a recruiter's 10-day window expire because your deadline was in the wrong spreadsheet under the wrong name. That mistake is avoidable. I learned it the hard way so you don't have to.