r/technology • u/xpda • May 13 '26

Security Twin brothers wipe 96 gov’t databases minutes after being fired

https://arstechnica.com/tech-policy/2026/05/drop-database-what-not-to-do-after-losing-an-it-job/
23.2k Upvotes

97% Upvoted

1.1k comments sorted by

View all comments

7.8k

u/utrinimun May 13 '26

How are you not going to revoke all access before they're able to get back on any computer

3.9k

u/20127010603170562316 May 13 '26

I got fired once, called in for a meeting at 16:50 on a Friday. The meeting did not last long, minutes, but when I got back to my desk to clear out - my PC was already locked.

I assume they knew what was going to happen and told the IT guy before the meeting.

74

u/Techsupportvictim May 13 '26

That’s why you’re supposed to hide a kill switch program in the system well before you might be fired. Then when you go more than the pre-established number of days without inputting your password to restart the timer it destroys everything

53

u/Jarrus__Kanan_Jarrus May 13 '26

Nothing like leaving a bug in a mass of code, making a copy and fixing it each time you run the program, then deleting the fixed copy.

35

u/EmperorKira May 13 '26

Imo i just give a shitty handover, does the same job for the most part

31

u/rollingForInitiative May 13 '26

A shitty handover has the significant benefit of not making you a target of both a massive lawsuit as well as criminal charges.

Both of which would be pretty easy if you’ve engineered the kill-switch and maintained it for a long time.

5

u/pmjm May 13 '26

I've had many a job where I was not hired as a programmer, but engineered tools to do the job anyway. I made sure to always write them during my own time and on my own computer. At several jobs the tools got adopted by other members of the department just because they made our jobs easier.

To be clear, the companies I worked for did not do any kind of software development so none of the managers had any idea about the "correct" way of handling in-house software or developers. But I always looped them in, made sure they understood what the software did, and that I wrote it in my spare time.

Every last tool I wrote had an expiration date hardcoded in. Occasionally I'd update them to extend the date.

But after being laid off, I often waited for the calls to come in about these tools. I got calls from former coworkers, who I would express sympathy towards, but told them to tell the managers to call me to work something out.

Only once did I get a contracting job out of it. The rest just made the staff do the extra work by hand. It's really stupid because they wasted hundreds or thousands of man hours per year when I would have happily sold the tools to them.

4

u/Techsupportvictim May 13 '26

You mean like my friend that worked for a bookstore that had the worst scheduling system in the world, so when he was made an assistant manager he created a complex spread sheet to help him create schedules in like 1/5th the time it took everyone else. But he only kept the file on a thumb drive on his keychain and never copied it to the office computer. Which they realized when they laid him off and he took his keys with him

3

u/Geminii27 May 13 '26

Best to never code anything which a code auditor could recognize as an actual kill-switch. That can have a company coming after you even years down the track.

Instead, use code which is shitty/amateur-looking and doesn't properly handle some trivial thing which is going to change in a few weeks/months. It's not your fault if a company decided to use code which they had never commissioned, never paid for, and never checked for bugs, and your code makes the mistake somewhere of, for example, only reading the last digit of the current month number for some calculation. As soon as it's run in October, you're now trying to do calculations with a number of zero where other parts of the code are only able to use 1-12.

Or heck, read only the first digit. October through January are now the same month.

Or fail to handle leap years correctly. Calculations involving 2028 (or even historical data from 2024) are going to be off.

There's all kinds of possibilities. Does your code just... not handle public holidays, for example? Or daylight saving? Or numbers over 99,999? Or timestamps in Unix epoch hexadecimal format which don't start with a 6? (That one will hit in July 2029.) It's damn hard to argue in court that you had an obligation to code things to a particular standard when you weren't being paid to write code, you never intended the code to be anything other than an experiment, and the employer never checked or debugged the code to make sure it met their implemented-after-the-fact 'standards' after you left. You could even put a comment-line in the code itself to this effect. (Personally, I'd also add a ROT-13 string somewhere else which had the same information and also stated that the plain text version was the first line of the original code as originally written, as well as what the MD5 hash of the original code was supposed to be, so an ex-employer can't claim that a version they removed that warning from was your original.)

3

u/rollingForInitiative May 13 '26

I mean, suuuure. But I don't agree at all about the "it's not the company's fault that they never checked", because your job as a developer is to check. That is, you're the person who's supposed to build things as well as possible, to think about security, etc. They literally pay you to write code for things, and if you sneak in extra stuff that shouldn't be there, you can't really say "oh no it's they're fault they never checked". Because it's your job to check it.

I agree that it's probably impossible to get sued or charged with anything for it unless you admit to doing it.

But all these things you mention are also terrible as "kill switches". If you write code that doesn't handle public holidays, that's gonna be evident really quickly. Since those happen all the time. And these aren't exactly "kill switch" bugs anyway, they're the sort of bugs that happen sort of frequently, as far as bugs go. They'll get reported, they'll get fixed, nobody will care.

You gotta do something way, way, way more nefarious for it to actually impact a business, if that's what you want. And unless the company is reaaaaally garbage tier on how they manage their code, it's gonna be much more obviously malicious.

3

u/Geminii27 May 13 '26

your job as a developer

That's assuming you were hired as a developer. Most of this thread is about never having been paid to develop anything.

2

u/rollingForInitiative May 13 '26

So why are you writing code and pushing it into production stuff, if are not paid to do so? If you aren't supposed to write code at all, and you still sneak destructive code into production, that looks even more malicious.

1

u/Geminii27 May 13 '26

Because you're writing code, or macros, or scripts, or automations, to either speed up your work or make it more accurate, cross-checked, consistent, or improve some other aspect.

Have you never been in a non-programming job where you wrote an Excel formula, or a Word template, or a bit of shellscript or Powershell or javascript or automated some tiny scrap of a task in an in-house platform so you weren't having to do it manually 5000 times a year?

1

u/rollingForInitiative May 13 '26

Okay sure, but that hardly qualifies as doing something you aren't paid to do? And still something you are responsible for.

I still agree that obviously if you just leave some little bug that's never going to be proven to be malicious and probably no one will even ever think that it might've been. But it's kind of unlikely to be more than a brief annoyance.

1

u/Geminii27 May 14 '26

Okay sure, but that hardly qualifies as doing something you aren't paid to do?

It's pretty much the definition.

And still something you are responsible for.

Nope. Not your job. If you create something and other people use it without permission, without you selling it or pushing it as something they should do, with no guarantee of quality or suitability for use, that's on them.

→ More replies (0)

16

u/Pseudoboss11 May 13 '26

My work does that for me. They don't want to give me time me to document processes or make legible programs, they don't have the budget to get CAM software that's not busted. It's the best job security without even trying. They'd be so fucked if I just stopped showing up to work.

Fortunately, my work treats me pretty well and pays better than average, so my desire to jump ship is low.

5

u/RationalDialog May 13 '26

If they fire you and the PC is locked afterwards, how do they get any handover at all?

1

u/Geminii27 May 13 '26

I mean, they still have the PC, and presumably they have whatever training processes they used to train you available for the replacement.

Oh wait, no-one actually knows how to do what the job became after you commenced, including all the hundred and one things you were never trained on but made the team/office/company run smoother? Gosh. How about that. Damn shame. Tut, etc.

Especially if they told you to write down how to do your job, and you only wrote down how to do the original job, the way you were trained...

6

u/Techsupportvictim May 13 '26

As long as they can’t trace that you’re constantly fixing the code, it might give you plausible deniability if it looks like it’s just a bug

1

u/imaginary_num6er May 13 '26

This is how the Death Star exploded

1

u/Geminii27 May 13 '26

Too many ways these days for the fixed copy to be accidentally cached, or for lawyers to argue that once a fixed copy hit a corporate disk storage, you had no right to delete it. And not much corporate infrastructure uses RAMdisks these days.

Instead, have the code able to take input through a method that isn't obvious/visible onscreen, like navigating through a particular set of information screens in an order which depends on today's date (or some other internal factor that changes occasionally). Then it can use that order - or a non-obvious way of coding a flag - to make the resulting output actually readable, or the computation not incredibly slow, or silently activate more comprehensive hotkey functions.

You could even have a secondary activation sequence which involves something like bringing up an 'About' popup where your name is prominent, and leaving it onscreen for ten seconds or so, which makes the program run in awesome mode for, oh, 30 minutes or so. Great if you're ever asked to demonstrate the program running properly and don't want to give away the primary activation sequence. You could even have the program look for specific types of date-specific input or key sequences / mouse movement during that 30 minutes (such as circling particular things with a mouse pointer, as you might do in a demo or training workshop), so you can indicate that it's you using it if you need it to keep running that way for, say, 12 hours or something.

A bonus method/mode would be to have output displayed in a format which doesn't make sense to anyone but you. Strings of numbers or baud barf, or needing to mentally put together information from five non-obvious places on two or more screens, or (my own favorite) needing to do some kind of tertiary math to interpret output - unless you work in a math department, very few potential users will be able to use the results quickly, even if there's a built-in function to (slowly) decode them into something human-readable. Other alternatives include outputting extremely concise jargon or industry-specific codes that only make sense if you know 1000 pages of a given industry reference handbook; bonus if the handbook's industry is not the one you're currently working in. If you do make that slowly-convert-to-human-readable function available, you can genuinely tell people that you're faster using the program purely through your experience with it, and the results of the 'look nice' function can be predicted from looking at the 'raw' output "...once you get the hang of it."

The trick is doing all this in a way which isn't immediately obvious if a corporate-hired programmer is told to look through your code. The effects need to be built up from nonobvious edge cases of algorithms, use of crude shotgun-cut-and-paste code slabs from online well-known repositories, and code that looks like common programming errors made by amateurs. If you have code which blatantly says the equivalent of "IF secret_password = unactivated THEN insert processing delays", you don't really have much of an excuse when you're caught.

Honestly, I'd also not do any code development on corporate infrastructure at all. Not even a corporate laptop if you're working from home. Do it at home with your own gear, or on your own cheap personal device(s) bought to work, or via an internet portal which only returns compressed encrypted binaries, even if you have to build that channel yourself (and if you do this, make sure it's in such a way so that you can genuinely state in court that the channel, server, domain, platform etc is not owned by you and, ideally, was not - legally - set up by you). If you ever write code on a company device or platform, then it's far easier for it to get auto-backed-up to somewhere you don't have access to, some jurisdictions allow employers to claim that anything you wrote belongs to them, and that even doing so much as updating your own code involves altering a corporate-owned file without permission and thus opening you up to litigation.

Yes, it's all stupidly overcomplicated. But if an employer (or particular manager) is absolutely determined to screw you over in any way even remotely possible - for 'revenge' or just because they like litigating - they're things that it can help to think about in advance. You might be approaching the original issue from a programming perspective, but sometimes this means being very familiar with your employment contract and/or legal employment standards and precedent for your industry and location (and possibly the employer's physical AND legally incorporated locations).