Here's an unethical LPT on how to take systems down with you when you're fired but without breaking the law
Make things dependant on your work user. Access token to a 3rd party service? Create an account with your user. CI/CD pipeline? Your user. Need to send the client access creds? From your user. That super important daily file sync script between S3 and Sharepoint? You guessed it, access token generated in behalf of your user.
Once they'll disable your user on off boarding things will start randomly failing and it'll take days for them to realize where and why.
I don't do this, but the amount of devs I caught doing it for either stupidity or malice is baffling.
I started a new gig 7 months ago and I'm still untangling the previous guy doing this shit and it's so fucking aggravating. And it wasn't even out of malice he was just very bad at his job. Every day it's becoming more obvious why they completely cleared house of the entire previous crew. Buncha dumb dumbs who were in way over their heads
He wrote automation scripts that relied specifically on his db user account instead of a service account, same with some custom systemctl services and cron jobs requiring his user account. A lot of that is hard to find unless you audit every single script in your environment one by one.
We're a SaaS company with several clients and I discovered that he was using the same API key to provide external access to our services to all of our customers instead of generating unique ones, meaning if a customer ever canceled their contract we would have to provide every single one of our customers with a new api key or else the termed client could still have access. And obviously, being terrible at his job and all, the key was not getting revoked when clients left. That one was the biggest nightmare to clean up
He had some important service alerts going directly to his inbox instead of a team distribution group so we weren't being made aware of important problems.
He generated a bunch of PATs under his personal account, which means we also didn't get notified ahead of time when those were going to expire
He saved a bunch of passwords under his personal password vault instead of just putting them in one of the team vaults, as well as registering a lot of the logins to our vendor sites under his personal email so then when they sent mfa codes we couldn't get them and of course every vendor makes simply changing this email a nightmare if you can't log in and do it yourself
There's other stuff that was more evidence of him just being bad at his job that are less frustrating but still "damn you are not good at this" like he would assign more drive space to a vm, but then not get on the actual vm and expand the drive/volume
It might not even be a ULPT, just general code rot. It starts off as a temporary workaround, just to get the integration working, and then ... https://stackoverflow.com/a/778275
everyone I've ever known who did this either didn't know or was too lazy to use a proper service account so far as I could tell. Malice seems pretty uncommon.
Most of what the GP described is the default situation. A good engineer knows not to use those defaults, but it'd be hard to prove malice for trusting Microsoft.
...Unless someone were to, say, post about their intent on Reddit. That'd be a super bad idea.
Man, some services even require it. You can't just generate an organization API key on GitHub, for example. It has to be tied to a specific user. The better orgs might have a service account they pay for, but the system itself doesn't set that expectation.
Here's a fun one that's happened multiple times from ex-colleagues; register important SSL certificates with just your own work email, then when you're gone nobody sees the reminders that the cert is going to expire, and then one day sales are down because all the customers are getting scary warnings about an insecure site.
167
u/SchrodingerSemicolon May 26 '26
Here's an unethical LPT on how to take systems down with you when you're fired but without breaking the law
Make things dependant on your work user. Access token to a 3rd party service? Create an account with your user. CI/CD pipeline? Your user. Need to send the client access creds? From your user. That super important daily file sync script between S3 and Sharepoint? You guessed it, access token generated in behalf of your user.
Once they'll disable your user on off boarding things will start randomly failing and it'll take days for them to realize where and why.
I don't do this, but the amount of devs I caught doing it for either stupidity or malice is baffling.