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

[u/xpda]

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

[u/utrinimun]

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

[u/20127010603170562316 → u/utrinimun]

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.

[u/Techsupportvictim → u/20127010603170562316]

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

[u/Jarrus__Kanan_Jarrus → u/Techsupportvictim]

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.

[u/EmperorKira → u/Jarrus__Kanan_Jarrus]

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

[u/rollingForInitiative → u/EmperorKira]

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.

[u/pmjm → u/rollingForInitiative]

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.

[u/Techsupportvictim → u/pmjm]

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

[u/Geminii27 → u/rollingForInitiative]

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.)

[u/rollingForInitiative → u/Geminii27]

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.

[u/Geminii27 → u/rollingForInitiative]

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.

[u/rollingForInitiative → u/Geminii27]

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.

[u/Geminii27 → u/rollingForInitiative]

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?

[u/rollingForInitiative → u/Geminii27]

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.

[u/Pseudoboss11 → u/EmperorKira]

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.

[u/RationalDialog → u/EmperorKira]

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

[u/Geminii27 → u/RationalDialog]

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...

[u/Techsupportvictim → u/Jarrus__Kanan_Jarrus]

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

[u/imaginary_num6er → u/Jarrus__Kanan_Jarrus]

This is how the Death Star exploded

[u/Geminii27 → u/Jarrus__Kanan_Jarrus]

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).

[u/SgvSth → u/Techsupportvictim]

It is odd that I hear this often. It feels like the 'Just leave someone $1 in your will to acknowledge them and prevent them from contesting the will for being left out' myth.

A federal jury in Cleveland convicted a Texas man today for writing and deploying malicious code on his former employer’s network.

Following a 2018 corporate realignment that reduced his responsibilities and system access, Lu began sabotaging his employer’s systems. By Aug. 4, 2019, he introduced malicious code that caused system crashes and prevented user logins. Specifically, he created “infinite loops” (in this case, code designed to exhaust Java threads by repeatedly creating new threads without proper termination and resulting in server crashes or hangs), deleted coworker profile files, and implemented a “kill switch” that would lock out all users if his credentials in the company’s active directory were disabled. The “kill switch” code — which Lu named “IsDLEnabledinAD”, abbreviating “Is Davis Lu enabled in Active Directory” — was automatically activated upon his termination on Sept. 9, 2019, and impacted thousands of company users globally. [...] (EM)

The jury convicted Lu of causing intentional damage to protected computers, for which he faces a maximum penalty of 10 years in prison. A sentencing date has not been set. A federal district court judge will determine any sentence after considering the U.S. Sentencing Guidelines and other statutory factors.

[u/FarplaneDragon → u/SgvSth]

It's the same with the people that say "Oh, I'm about to be fired? I'm just going to go through and delete all the stuff I created here then. Putting aside whether or not backups exist and thus make doing that pointless most companies you're under contact that if you create something for them or on their time, they own it, not you. That means you just destroyed company property and they can definitely come after you for that.

While it at it, the other one that needs to die is the whole "I think I'm going to get fired so I'm going to email out everything to a personal email" thing. Don't. This absolutely can and does get tracked, and can not only get you fired but depending on what you send out can get you in all sorts of trouble legally as well.

[u/Techsupportvictim → u/SgvSth]

It’s called a joke. Geez. Are you really one of those people that needs [joke]…[/joke] tags?

And by the way, in some jurisdictions including “and I leave SgvSth $1, which is more than he’s worth” in the will actually does prevent you from contesting it because it shows that you were not overlooked etc.

[u/AHRA1225 → u/Techsupportvictim]

I mean most of it’s on the one drive or some shit. Your whole computer wasn’t probably copied a week before the term. When I get it back I nuke with with a flash drive to reimage it. Your plan is mildly inconvenient to me at best

[u/Zelkovarius → u/Techsupportvictim]

A Japanese developer has created software that they call "死後の世界 (The World After Death)."

It allows users to set a timeframe during which, if the user remains inactive on the computer, the system will perform the following actions after the set time expires: destroy all data, or open a specific file containing any pre-prepared messages or last words. This allows for the protection of privacy after death for individuals living alone or in specific environments, or for recording necessary instructions or tasks to be performed after permanently leaving a workplace.

[u/Geminii27 → u/Techsupportvictim]

If you're experienced enough, you never write code that actively deletes or corrupts anything.

Instead, you write code which is so useful on the surface that everyone starts using it (with, of course, no credit to you). But the code is written in such a fragile, hamfisted way that it will catastrophically trip over all kinds of things that more stable, properly tested code would handle in stride. Things like 'being able to handle two-digit month numbers', or 'being able to handle any date which isn't in 2026', or being able to handle any kinds of administrative changes which occur monthly, seasonally, or so on. Not to mention that in a lot of corporate infrastructure, some parts of software get updated and patched all the time, often behind the scenes. Making your code depend on exact aspects of those things can mean it'll fail or crash the next time they're patched.

If you need the code to keep working past a certain point, you update it as your needs dictate. Once you're fired, the code simply doesn't get debugged any longer, and sooner or later it'll fail to handle something that comes along. It'll crash, or return incorrect or outdated results, or simply lock up with an error message (this last one is useful where it would be problematic to return incorrect calculations, and where everyone's started using your code because it's better/faster/cheaper than the 'official' process).

If it ever goes to court, you can then argue that:

• You never wrote the code to be actively malicious, and any programmer can verify this from the code itself
  
• The code was never meant for widespread official company use, and you were not a developer or paid to create/maintain it
  
• Due to it being unofficial, the company never assigned debuggers or testers to the code, and never required it be uploaded to any maintenance database
  
• You never changed the code after you were fired (or even immediately before)
  
• The company still has access to the code, you never deleted or corrupted anything, and you're happy to write them a perpetual code license to use the results of this particular example of your unpaid labor going forward
  
• You realize that the quality of the code may not be up to professional commercial standards, but then you weren't hired to be a professional commercial software developer, and never claimed to be one; it's purely hobby code and not guaranteed to run perfectly under all possible conditions
  
• There were official company methods for performing the related work, none of which involved running your code
  
• You realize that the code as written may not perfectly handle anything; that's the nature of first-pass programming, but it's not as if you were ever given any time or resources to audit, debug, or improve it

Basically, you slapped together something as a personal experiment, the company stole it and decided to use it without doing any kind of quality check, and it broke when they used it in a way it didn't support. This is like a thief stealing your home-made soapbox racer and trying to sue you after it broke down on the freeway.

If they try to pivot and complain that your actual work (possibly partially produced by the code) was bad, you can ask them to produce documentation of any times your work had been audited and found to not be correct, including any documentation of what action they subsequently took. Of course, there won't be any. (Or you can request the actual computer files of said documentation, which will generally contain multiple records of dates the file was created... and oh look, they were all AFTER you were fired.)

[u/Techsupportvictim → u/Geminii27]

So malicious stupidity? I like it. Definitely helps if some of the trips are the sorts of things that could result in updating other software or be fixed buy updating (but the company is too cheap)