All the passwords were stored in Active Directory description fields PWNED Welcome back to PWNED, the weekly column where we talk about weak security policies and how to avoid them. Hopefully, we can learn from others’ mistakes – or at least have a good laugh at them. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available …
Once in AD, the hackers found plenty of passwords, which came with full domain access. They used this access to delete all the backups and execute ransomware. In total, the crimes put 2000+ users out of action by encrypting Hyper-V hypervisors and their hosts. The company was taken offline for months.
Wow, I'm surprised the Company survived at all
The we used to have IT icon -->
I interpreted the absence of any real identifying information as meaning the company is still trading…
However, I have sympathise for the company, privileged credential manage,ent systems are relatively expensive and don’t tend to fit smaller companies - with their correspondingly small IT estate very well.
I’ve also come across IT service and support companies holding the privileged credentials and/or access of all their customers in the same system (eg. TeamViewer), , so anyone gaining access to one of their engineer’s login, also gained admin access to all their customers…
Active Directory fields can be secured, everything in detail possible to adjust which AD fields can be read of changed. But the default is "read" as "anonymous". Even with Server 2025 with a new AD. The "Pre Win2000" group is still filled with those old defaults. The only change of "security" for a fresh Server 2025 AD I found tripped the MS-Security tool (which was updated later): Only a domain admin can see whether the "DOMAIN\Guest" account is disabled or not, all other see it as "enabled" even when disabled, which raised an alarm in Sentinel (or whatever it is called today, tomorrow etc). That is really a weird default.
There still is but - uselessly - like the rest, it's only displayed at the top of the article once you've already opened it.
Why they can't go back to displaying it somewhere in the article list, I don't know - I guess at this point they're just being bloody minded. And yes, I'm still using the Archive view (https://www.theregister.com/archive) to make the site usable. As you say, it's the kind of stupidity you expect/accept from other sites, but it's odd from El Reg.
In ElReg forums(*) I have created a topic to flag there is no consistent place for us to feedback - if you really want your users to be beta testers you do need to make it easy for them to report problems.
>” but it's odd from El Reg.”
Probably did the project on the cheap using a team zero experience of production system change management and engagement.
(*) It’s under: User topics - Café Vulture - El Reg matters - May 2026 Website Redesign
I couldn't put it in \\domain\SYSVOL, I don't have write permission there! They were too secure for me! And they forgot to update the comment of DOMAIN\Administrator, and after 5877489295 tries to hack the password I just gave up... Computer too slow. And all other domain admins never put their password in the comment, violating the company policy...
Well, you need two slaves. One with the encrypted password, another with "ROT13" similarly tattooed. Even then, when the recipient has received the slave, shaved their head and read the message, it needs to be securely deleted. In this day and age, most office workers are sadly squeamish about gore, so that creates a problem.
Another thought, given hair regrowth time the data rate will be bloody awful, even if you're just sending them to another floor in the same building.
"IT changes your email password, and emails it to you. Which has happened to me."
These days it would be so unusual for anybody to make a voice call.
If I received an email from one of my sisters that they were trapped somewhere and needed some money for a bus/train/plane, I'd know it was a scam. If they can send an email and were in a tight spot, why wouldn't they call and talk to me? Yet, it's the sort of scam that people fall for.
Best practice would be a call to a number on file with a temp password that let's a person log in to a place where they can create a new password that is activated when they follow the link in an confirmation email that expires in a short amount of time.
I regularly get emails with very, very confidential information about pupils from one local authority.
The attachments are zipped and passworded, with the password in a second email sent at the same time.
I've now trained that office to use a consistent password, so it doesn't need to be sent each time.
The new password is the school name plus 1! which is no better...
How else do you send a temporary password to a user that has no phone and may be on a different shift?
When I set up a new user in our production system, I email them the temporary password. Yes, it's email. But it's from one Exchange account to another inside the same company, not unencrypted over public internet. And the production system isn't accessible via public internet either.
I put the password in a text file, put that in an encrypted archive, email the file, then send the password out of band (Slack DM, SMS, Post-It etc).
It’s not perfect (especially with corporate mail systems that block encrypted attachments…) but it’s about the best method that works with widely-available tools.
In our case, we don't have Slack, I don't have the user's phone number, and a Post-It might take a few days to get to them (if it makes it at all); these are users I rarely ever meet. And many of them would probably struggle with opening an encrypted zipfile and might not know what a text file is. Sending from my corporate email account to theirs (so never leaves our Exchange server) for a temporary, forced to change upon login for a system that can't be reached from the Internet seems a good compromise between security and user accessibility.
Certainly seen auth against (open)ldap's internal password implementation (and without TLS) which is weaker† than NIS with systems using MD5 hashes. :(
Surprising what you can fish out of an AD server using ldapsearch — the stuff that is stored in LDAP…
I always assumed AD used Kerberos V for auth and that any Linux client could directly auth off the MS Kerberos service. I suppose legacy lanman and nt password hashes might be stored in ldap - I think that was an option in samba (3 or 4?) - which is an equally grim prospect.
Everyday reading el Rego makes me gladder that none of these train wrecks are my problem or a consequence of anything still running that has my dabs on.
† the worst unsalted sha1 hash {SHA}; Salted MD5 {SMD5} has only one round of hashing so arguably worse that $1$...
I skipped mentioning following IMPORTANT details in my previous comment somewhere above:
You cannot access the password hashes, only the normal properties. Which is more than I would like to, 'cause "last logon" "last pwd change" "what hashtypes are allowed for that account" and many other properties must not be readable by everyone. Similar for bitlocker keys stored in AD, you have to be enabled to access them. And since MS-upgraded the "LAPS" the LAPS password is encrypted as well with clearly defined structure who can access it (default: Not even domain admins). The older LAPS stored it unencrypted, but at least secured the access...
The article stated that the password was stored in an AD field, which in detail probably means: It was ADDITIONALLY stored within one of those AD fields, not where the PW hash is.
I'm now wondering if this a company I used to contract with (briefly), they asked me to do some auditing of AD and I discovered this same issue and they thought I was incredibly paranoid until I showed them just how much info you can query out of AD as a standard user.
I doubt they've changed anything in the 6 months since I left there, also gently suggested that they should be blocking access to the command prompt and PowerShell (amongst many other changes) in their GPOs, which appeared to have been barely changed since the Server 2003 defaults.
Blocking two tools to access something instead of blocking the access itself is very stupid.
"Here, we revoke these to types of keycard which allow you to go through that always open and unwatched door".
Not that I am against blocking cmd and powershell on a terminal server, but on a lot of things this is like shooting your foot to prevent it from getting damaged to kick something.
It’s ignorance; I’ve seen multiple occurrences of this because it’s ‘helpful’ for the helpdesk to remind users as to their password. Ignorance due to many people not realising that the description field is fully viewable to ‘world+wife’, unless you have gone to great lengths to lock it out.
I make some effort to not know the passwords for any of my clients, which often surprises them ‘but you are an admin so surely you know....’, ‘eh no, we don't, but I can reset it to a one-time password, which you will absolutely have to change on first login*.
Unfortunately, proper security can, and often does, run headlong into corporate ‘just make it work OK, or else.....’ So what do you do?
* Yes I know, how do you securely transmit this one-time password to the user, and are you sure that it really is the user they are claiming to be?
"how do you securely transmit this one-time password to the user, and are you sure that it really is the user they are claiming to be?"
A voice call to that person with a phone number on file that hasn't been changed in a certain amount of time. If that can't be done, a personal visit. If that can't be done, overnight mail, maybe. Not cheap, but less expensive than a breach and that should be something that doesn't crop up very often.
If you are working for a company and responsible for something important, if you are required to do things that compromise that thing, make a fuss and leave if your advice isn't going to be followed. There's no point to remaining since you will be left hanging on a hook when it all goes wrong. That's never looks good on a resumé.
People assume that normal users can't see the information, and it does require either command line/PowerShell queries or local admin rights in order to install the AD tools to access the information.
I remember once being asked to get a list of AD users and when their passwords were last changed, and the guy who asked couldn't understand how I'd done it in 5 minutes without access to a DC. He had no idea how much info is accessible in AD to a standard user with no additional rights.
See also people who put passwords on post-it notes under their keyboard, insist on having non-expiring insecure passwords, or don't bother with any sort of basic security as "their data isn't worth stealing".
> People assume that normal users can't see the information, and it does require either command line/PowerShell queries
> or local admin rights in order to install the AD tools to access the information.
You don't need local admin rights and / or RSAT tools. Example for powershell, though your account must have some AD-access...
$searcher = [adsisearcher]"(&(objectClass=user)(objectCategory=person)(samAccountName=*user*))"
$null = $searcher.PropertiesToLoad.Add('SamAccountName')
$null = $searcher.PropertiesToLoad.Add('pwdLastSet')
$searcher.FindAll()
Easy to extend to when the password will expire and so on.
Apart from that: Tons of tools out there to do the same, in a nice tree-like fashion, using either [ADSI] or LDAP(S). Similar queries can, for example, find the renamed DOMAIN\Administrator of your AD and so on.
I don't see a point to expiring passwords. To me, it only seems to be useful in the case of a brute force attack, but even then......
A pass-phrase that isn't "Mary had a little lamb" can be easier to remember and won't need to be written down. I'd choose something like, "it hung in the air much in the way that bricks don't". No numbers, no capitals, no other characters and no formula. I might even substitute some leet letters just to make is harder.
If I have to change a password every 30 days and I can't use one I've had in the last year, I likely need to write it down and have it handy somewhere until I have it memorized. If I'm forced into a scheme that make it more difficult to remember what password I need, I'll have to find ways (usually simple) to look them up. I don't put stickies on the edge of my monitors, but I've taped things to the underside of the KB.
I worked in a place where the support desk server security was like Swiss cheese. It was an uphill battle to fix, because it was not simply a case of fixing software / OS configurations, it was trying to alter the ingrained culture amongst the non-techie users.
The PHBs decided the fix would be secure passwords - as if that would fix the underlying problems! From that point onwards, the 200 or so servers each had the admin password changed monthly, on a rolling rollout - 7 or so machines had the password changed daily.
Each machine had a unique password - generated by a random generator that produced 10 character (I think) passwords containing random letters, numbers and some symbols.
This made it a lot easier for me. if they'd forgotten to send me the latest password list,and I needed to log into a machine after the staff had gone home, I could just wander into their office and the password lists would be lying around on desks. This wasn't possible when the passwords were memorable!
I don't see a point to expiring passwords.
It's an attack protection for cases where the password is shared. Which is the traditional model for a "pass word". You have the pass word of the day, and change it every day, because it's not securely held.
It's also a protection against reading *past* or *future* content, which is historically important for other military use cases.
I've seen some insane uses of shared non-rotated passwords that you wouldn't believe. Like "We've had a database break in, so we've changed the password used by our hundreds of remote franchises"
Your machine passwords (which you don't see) are frequently rotated. In the current threat landscape, it's now generally held that rotation of personal passwords is a mistake, and causes more problems than it solves for most (commercial or personal) use cases.
"I don't see a point to expiring passwords."
It's another of those things that has changed over the years, changing passwords once a month was seen as "good" security in the days when laptops weren't the default, not everyone had smartphones and services like OWA were much more commonly used and exposed to the internet. Most services exposed to the internet these days will have some sort of MFA.
It is like pre-set security question options. The ideal is a phrase which will suggest to you - and only you - a word. To use a well known to the public example ''Twas brillig and the slithy toves' would suggest jabberwocky.
Instead of 'name of your first pet' you could have 'Fido + 1' which could be the name of a subsequent one. A sibling's nickname etc. Plenty of choice, meaningless to others, and much better than 'a memorable date' (which one?)
"Instead of 'name of your first pet' you could have 'Fido + 1' which could be the name of a subsequent one. A sibling's nickname etc. Plenty of choice, meaningless to others, and much better than 'a memorable date' (which one?)"
I've run across lists like that where none of the things apply. "Name of first pet", good grief, I've had pets all my life and if put down Brandy, a St Bernard, the next time I might remember that Charlie the cat came before. Naming a "favorite" is just as bad. Pick your favorite child. If you only have one child, that will be in the data file.
One password I was able to define myself was the restaurant we'd always go to when a certain friend was in town. That it's not around anymore is even better. I haven't talked to that person in years either.
I'm not so sure that Jabberwocky is that well known these days, but for those that know it, yes, that part would be a good first guess. One could modernize the grammar and do some substitution.
* The description attribute was designed in the late 1990s as a simple informational field.
* Microsoft assumes administrators understand basic security principles (e.g., least privilege and not storing secrets in readable fields).
* Modern guidance (Defender for Identity, security baselines, and breach post-mortems) treats this as common knowledge rather than something that needs repeating in the 20+ year-old schema docs.
less than a year ago, a customer relationship manager (CRM) in my company had got an e-mail from their customer complaining about access to an SFTP server. Rather than asking important details (WHICH sftp server? -- my team alone managed around 30, and there were lots more at other teams) What is the error message? What account name?), they just blindly forwarded the useless e-mail to a randomly selected team in the company. They forwarded it on to other randomly selected teams. Probably six or seven forwards before it hit me -- don't know if it is one of my servers, but at least I'm going to ask the questions. By this point, there are probably 100 individual people in this e-mail thread.
"What server is this regarding? What, exactly, is the error they are seeing? What is the login name they are using? DO NOT SEND ME THE PASSWORD". Yes, I explicitly told them not to send the password. Why? Because I'm aware of the intelligence of the average CRM at my company. A few minutes later...the CRM "REPLY-ALL"s with the username, the server name, AND THE PASSWORD FOR THE ACCOUNT (but not the error message). The password has just been sent to 100 users, many of them off-shore people probably paid a few pennies a day and ZERO loyalty to the company. I'm starting to write a salty e-mail, but my boss beats me too it, "The password must be changed now", and a brief notice of how out-of-line this person was to do such a stupid thing. (I don't remember what the problem was, but it was a real problem, but easy to fix)
I set a new password, send it to the CRM and only the CRM, to be conveyed to the customer (yes, this process is wrong, too...but it's how they do it). A few minutes later, the CRM REPLY-ALLs the same e-mail thread, INCLUDING THE NEW PASSWORD. I lost it. I Instant Messenger her back and say, "you are an F***ing idiot. You just forwarded the password AGAIN to the entire list" -- except I spelled it out. No asterisks. And I give her a new password to send to the customer AGAIN. CRM responds, "HOW DARE YOU SPEAK TO ME LIKE THIS!" I told her, just be glad I'm not your boss.
Now...I don't speak like that normally. I certainly don't put it in writing, well, ever. And it was a very carefully considered message then. But in this particular case, the polite message completely failed to get the point across, I felt it was entirely appropriate.
A few days later...I get the expected call from HR. They give me the required speech about business appropriate language, etc. I tell them point blank -- she got plenty of polite and proper warnings about the proper things to do, she ignored them. I'm not backing down. I'm not apologizing. She doesn't belong dealing with customer data, she's inept. I know what security training she was supposed to have -- and she took none of it seriously. Somewhat entertainingly, I'm normally a Work From Home person, but that day, I was in the office -- a very open office. So a lot of people heard me, I'm sure. "She hurt the company, I hurt her feelings. I'm not apologizing". They assure me that while they are talking to me about this incident, her reporting it triggered a security review with her, the "she hurt the company" part was noticed. The HR person couldn't say she was agreeing with me, but the tone in her voice pretty well indicated she was, at this point, just doing the required actions.
And one of those actions was to send me a form to sign, stating that we had discussed this incident. Ok, great. I read through it...and the complaint says, "See attached", but there's no attachment. I mention this to the HR person, they acknowledge the error, and send me a screen shot the CRM sent to HR as part of her complaint. And there in the screen shot is....the third password...which has now also been exposed to more inappropriate people. I point this out to the HR people.
"wait, that's the CURRENT password?", the HR person asks me.
"yes"
I could almost hear the HR person's eyes rolling. And yes, another password change was triggered.
I told the HR person, "Well, I guess I do owe someone an apology. I had hoped my use of non-businesslike language might shock her into understanding proper process, but apparently I failed at that"
Apparently HR talked to my manager minutes later, he popped out of his office to tell me "don't worry about this at all". In fact, that was about the only time I heard anything resembling useful from my manager in the 3.5 years I was there about my job performance. (translation: we will lay you off due to being a failing company, not for disciplinary reasons. And yes, I am no longer there due to layoff).
This is a big (but shrinking) company, servicing banks and credit card companies (and other companies) in the US and Europe. Yes, be scared.
that's just one recent story...I got lots more.
Back in the 80's, a friend of mine worked in the local university managing their Cray II.
His boss had a bee in his bonnet about passwords, specifically rude passwords, which he decided were unprofessional, which is odd, because the passwords are secret, right.
Ahh, no, because he had this bee in his bonnet about rude words on his network, the passwords were plain text, and it was my friend's job to keep an eye out for rude passwords.
Makes comeplete sense...
This hole has been known for 50 years. Store passwords using cryptographic hash functions. One way encryption guarantees that even if you dump files or memory of a static system, the passwords are unusable. When someone enters a PW you instantly compute the cryptographic hash value and destroy the plain text. Then you compare that hash with the PW hashes stored to see if it's valid. This minimizes the window to a very tiny period. As opposed to all day. The hashed PW is not invertible and cannot be used by a user to authenticate, since on input value would be hashed again before being compared to the store hashed value. .
Government officials should not be shielded from personal liability.
The same technique can be used for other critical data.
