RDX Perspective
We spent a decade building zero trust for employees, contractors, vendors, devices, and apps. We never put it around the one moment that comes right before all of them: the interview. It runs on a personal laptop, over a consumer meeting link, with a person who wants the job. That is now an attack surface, and attackers have noticed.
The interview was for an "Advanced Cyber Security Engineer" role. It was arranged through a staffing firm that claimed a connection to a large IT services company. By the end of it, a single line of text had run on my Mac four times, and I had to treat the machine as compromised.
Here is the part worth sitting with. I do this for a living. The interview still very nearly worked. So this is not a story about one careless person. It is a story about a workflow that every professional walks into with their guard down, on the one computer that holds the keys to everything.
Names are left out on purpose, and every technical indicator here has been defanged so nothing on this page can be copied and run. The point is the pattern, not the accusation.
What actually happened
The invite was for 3:00 PM. At the start time there was no working client link and no interviewer I could identify from the company's real email domain. Around 4:42 PM a personal Microsoft Teams Free link arrived, and the session was pushed to about 5:00 PM. During the call I was asked to hold my driver's license up to the camera to verify my identity.
Then came the technical part. As is normal in these lures, a supposed environment or setup step was presented, and I ended up running a command that had been handed to me. The screen froze. I ran it again. In total it executed four times.
The one line that did the damage
This is what I was told to run. The web address is base64 encoded, which is the whole trick. It looks like meaningless noise, so you do not react to it the way you would react to a strange link.
Exhibit, defanged
Here is what that one line set in motion:
- Download and run, blind. The flags tell it to ignore certificate warnings and stay silent, and the pipe into the shell runs whatever the server sends back. You never see the code.
- Stage two calls home. The first script quietly pulls a second one from a different attacker domain and feeds it straight into macOS scripting. No file is written for you to notice or click.
- Collect. The second stage sweeps for the valuable things a working machine keeps unlocked: browser sessions and saved logins, readable config and environment files, API tokens, source code, wallet data.
- Package and ship. It zips the loot to a temporary file and uploads it in chunks, with retries, to the attacker. Then it deletes the archive so there is little left to find.
Afterward there was no lingering virus to point at. No startup entries, no altered login files, no leftover process. That is by design. This class of tool is grab and go. It does its work in seconds while you are logged in, and staying resident would only get it caught. The absence of wreckage is not reassurance. It is the method.
The absence of wreckage is not reassurance. It is the method.
One detail cut the damage down. I never typed my Mac password into any prompt, which is the usual path to the system keychain. What stays exposed is still serious: anything readable while I was logged in, and any browser session cookie, which can let an attacker walk straight past two factor login on accounts that were already open.

What a modern interview actually touches
Think about the computer a developer, founder, or engineer joins a call from. It is not a kiosk. It is the same machine that, minutes earlier, was signed into the things that run their life and their business:
- Cloud consoles, with live logged-in sessions
- A password manager, unlocked for the day
- Private source code and signing keys
- API tokens sitting in files and environment variables
- Production credentials for deploys, DNS, and billing
- Crypto wallets, as browser extensions or apps
- Session cookies that have already cleared two factor
- And your identity, the ID you just held up to the camera
On that last point: a license shown to a webcam, on a call that may be recorded, should be treated as captured. Name, photo, address, date of birth, license number, and expiration are enough to start real identity fraud. A legitimate employer verifies identity through an approved provider after an offer, never as a webcam show-and-tell during a first screen.
The gap nobody modeled
Every trust relationship a company has now gets verified, scoped, and logged. Employees, contractors, vendors, devices, apps. The one relationship left wide open is the one that happens right before employment: the interview. It runs on a personal endpoint, over a consumer meeting link, with a human who is motivated to be helpful, to hide technical embarrassment, and to not lose the opportunity. That is a near perfect setup for social engineering.
The answer: an Interview Trust Gateway
The answer is not to be more careful. Willpower is not a control. The answer is to move the risk off the person and onto a system. At RDX we frame it the way we frame all of our work: human-led, agent-assisted, evidence-proven. Applied to hiring, it looks like five controls.
RDX Diagram 01
The Interview Trust Gateway
Five controls that move the risk off the candidate and onto a governed process, from verifying the recruiter to producing an evidence package if something trips.
Verify the recruiter and the invite. Weigh the sender domain and its mail authentication, the requisition, the employer's real careers page, the meeting tenant, and the domain's age and reputation. Then hand a person a clear pursue, verify, or reject call. A real Microsoft or Google domain is never treated as proof that the organizer is real.
Contain the technical screen. Take-homes and live coding run in a throwaway environment with no saved passwords, no cloud sessions, no production source, no wallets, no SSH keys, and no API tokens. Clipboard, downloads, and outbound network are restricted, and the whole thing is destroyed when the call ends.
Block the dangerous patterns. Watch for exactly what this attack used: a download piped into a shell, a base64 blob decoded and run on the spot, remote scripts sent to a shell, prompts to turn off protections, and anything launched from a temp or downloads folder. Stop them, and ask a human.
Shield your identity. Government ID is never shown on an unverified video call, emailed, or dropped into a recruiter's form. Verification happens only through an approved identity or background provider, with real terms for storage, retention, and deletion.
Prove what happened. If something does trip, capture the evidence, hash it, build the timeline, block the connection, list the credentials that were in reach, get human approval to rotate them, and produce a package ready for an insurer or the FBI. That part is not theory. It is exactly the record this event produced within a couple of hours.
If this already happened to you
Do this now, from a different, clean device:
- Rotate and sign out everywhere. Change passwords and then revoke active sessions, starting with your email, since stolen cookies survive a password change on their own. Then your cloud, code, payments, registrar, and bank.
- Kill the keys that sat in files. Rotate any API tokens, deploy keys, and secrets that lived on the machine in plain text.
- Freeze your credit at all three bureaus if you showed an ID, and watch for identity misuse. It is free.
- Rebuild the machine. For an info-stealer, back up documents only, then erase and reinstall the operating system. Do not restore apps, profiles, or the old keychain.
- Report it to the FBI at ic3.gov and the FTC, and tell the real company through a contact you verify independently, not the recruiter.
The lesson is not that one interview was fake. It is that we conduct interviews from the same privileged endpoints we use to run companies, cloud environments, code, money, and infrastructure, and we never put that moment behind a single control. Put the interview behind verification, isolation, approval, and evidence. Control the action. Prove the outcome.
William Farrell
Founder and CEO, RDX Enterprise, LLC
Secure. Automate. Optimize.
If your team runs remote technical interviews, that process is now part of your attack surface. RDX Enterprise builds governed automation for the moments security tooling forgot, with a human in the loop and evidence behind every decision.

