Twin brothers wipe 96 government databases minutes after being fired • Hacker News Board

Re: Twin brothers wipe 96 government databases minutes after being fired

#191

Post by scorpioxy » Wed, May 13, 2026, 11:34 PM UTC

bluefirebrand wrote: post #32

scorpioxy wrote: post #13

Earlier quoted context omitted.

I've got a better one. I once had the same argument mentioned to me by my manager at the time when I pointed out that passwords were being stored in clear text. That it needs to be this way so that it is read/sent when the users forget their passwords(which happened a lot). I tried to explain that typically a "reset password" flow is used for that but that fell on deaf ears. That system contained healthcare data. Som…

> Something bad did end up happening due to that lax security and there were oh so many meetings about it. This is the sort of thing that makes me want to check out of the whole circus. Here I am, telling you ahead of time, and you ignored me So how there's a circus that we could have avoided and not only do I get zero recognition for identifying the threat ahead of time, the people who ignored me keep their jobs and…

Yeah, I can relate. It's a problem if you don't bother since you won't be doing your job to the best of your abilities and it's a problem if you do since you might get in trouble with the management for not being a "team player" or some other silliness. Without meaningful consequences, I don't see this situation changing.

Re: Twin brothers wipe 96 government databases minutes after being fired

#192

Post by kQq9oHeAz6wLLS » Wed, May 13, 2026, 11:35 PM UTC

jiggawatts wrote: post #113

game_the0ry wrote: post #41

Earlier quoted context omitted.

> At 4:59 pm, he asked an AI tool, “How do i clear system logs from SQL servers after deleting databases?” He later asked, “How do you clear all event and application logs from Microsoft windows server 2012?” So many red flags, I can't even.

I love how this leaks out the fact that the DHS is running production databases on operating systems that are months away from end of extended support. Windows Server has 5 years of mainstream support, 5 years of extended support, and then an extra 3 years paid Extended Security Updates (ESU) support. For 2012 and 2012 R2 that ends in October 2026. The three years of ESU exists only for organisations like government…

To be fair, this transpired last year, so they actually had one year and some months before losing extended support.

That said, they should have migrated it years ago.

Re: Twin brothers wipe 96 government databases minutes after being fired

#193

Post by colechristensen » Wed, May 13, 2026, 11:35 PM UTC

soVeryTired wrote: post #44

> On March 12, 2025, a search warrant was executed at Sohaib’s home in Alexandria. Agents grabbed plenty of tech gear but also turned up seven firearms and 370 rounds of .30 caliber ammunition. Given his former crimes, Sohaib should have had none of this. For god's sake, don't commit crimes while you're committing crimes.

There is a strong bias towards stupid criminals getting caught.

Re: Twin brothers wipe 96 government databases minutes after being fired

#194

Post by fc417fc802 » Wed, May 13, 2026, 11:37 PM UTC

CyberLily wrote: post #116

jm_l wrote: post #79

Earlier quoted context omitted.

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the cl…

Hashing client side is sufficient because the only service you can breach with the hash is the one you already had to breach in order to read the database.

Of course performing an additional server side hash on top of the client side one is good defense in depth because there's at least some chance that it might make things more difficult for a rogue insider and doing so costs approximately nothing. But it certainly isn't critical because by the time you're dealing with a rogue insider things are already looking quite bad.

Re: Twin brothers wipe 96 government databases minutes after being fired

#195

Post by necovek » Wed, May 13, 2026, 11:38 PM UTC

jmull wrote: post #145

jm_l wrote: post #79

Earlier quoted context omitted.

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

People shouldn't be downvoting this... Hashing client-side is a good idea. You must also hash server-side, for storage/comparison. Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db. They can then try the credentials on other, perhaps more lucrative sites. That's what the brot…

I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side?

This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively malicious IT person would not be deterred.

Re: Twin brothers wipe 96 government databases minutes after being fired

#196

Post by colechristensen » Wed, May 13, 2026, 11:39 PM UTC

JumpCrisscross wrote: post #144

> Muneeb and Sohaib Akhter, now both 34, had been in trouble before. Back in 2015, the brothers pled guilty in Virginia to a scheme involving wire fraud and computers. Muneeb was sentenced to three years in prison, while Sohaib got two. After their stints in jail, the brothers worked their way back into the tech world. In 2023, Muneeb got a job with a Washington, DC, firm that sold software and services to 45 federal…

The article isn't particularly clearly written, but it seems like their background checks were bad and were fired once management figured it out.

Re: Twin brothers wipe 96 government databases minutes after being fired

#197

Post by __turbobrew__ » Wed, May 13, 2026, 11:43 PM UTC

at-fates-hands wrote: post #131

giantg2 wrote: post #109

Earlier quoted context omitted.

It still blows my mind. Shouldn't the government audit their contracting companies for egregious issues like this? Seems extremely reckless not to.

I'm pretty shocked as well. I thought every company stopped doing this like 20 years ago? Even for a legacy system that is a long time to continue storing credentials like that.

My wife works in IT at a mid sized city. They still store credentials in source control.

Re: Twin brothers wipe 96 government databases minutes after being fired

#198

Post by fc417fc802 » Wed, May 13, 2026, 11:45 PM UTC

necovek wrote: post #195

jmull wrote: post #145

Earlier quoted context omitted.

People shouldn't be downvoting this... Hashing client-side is a good idea. You must also hash server-side, for storage/comparison. Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db. They can then try the credentials on other, perhaps more lucrative sites. That's what the brot…

I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side? This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively ma…

Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.

Re: Twin brothers wipe 96 government databases minutes after being fired

#199

Post by lazyasciiart » Wed, May 13, 2026, 11:48 PM UTC

yaur wrote: post #156

scottlamb wrote: post #39

> [Opexus] said that “the individuals responsible for hiring the twins are no longer employed by Opexus.” Getting close to the classic Monty Python line: "Those responsible for sacking the people who have just been sacked, have been sacked." Jokes aside, stuff like this sucks because I suspect many employers will take from it the most extreme, dehumanizing lessons, e.g.: (a) make firings [edit: including lay-offs] as…

Terminating access and rotating passwords (if needed) while the person is in the meeting but has not yet found out they are being let go has been SOP for at least the last 20 years

Amateurs. My employer does mass layoffs by terminating access to everything except their email account at 3am, and then sending an email to the victim saying “you were let go at 3am”. Managers get to figure out who’s left on their team by pinging everyone when they learn about it at work.

Re: Twin brothers wipe 96 government databases minutes after being fired

#200

Post by necovek » Wed, May 13, 2026, 11:49 PM UTC

fc417fc802 wrote: post #198

necovek wrote: post #195

Earlier quoted context omitted.

I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side? This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively ma…

Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.

My question still stands: how do you disallow cleartext password extraction if you are breached, assuming all your IT infrastructure and code is now accessible to an attacker?

I am talking about not logging them ever, using internal TLS and strong hashing in general, and wondering what exact value is added on top with client side hashing.