UK sixth-form student found Active Directory admin passwords in a description field

PWNED is back with a story that should make every IT director sit up straight: a UK sixth-form network left Active Directory wide open, and a student found admin-level power plus passwords sitting in a description field. The passwords were not hidden. They were right there, as readable text, inside Active Directory itself.

Nathan, 17, connected his laptop to the school’s Active Directory domain and hit a system that, in his account, did not require admin authentication for what he could see. He was able to view domain controller tools in view mode, browse policy maps, and then locate the domain administrator account. The admin password was written in the account description field as “horse fence ditch.” In the same area, he also found backup accounts with passwords such as “bd” and “bigbaddog.”

Once Nathan had what the story frames as “God mode” enabled, he described a level of access that is hard to overstate for a school environment. He said he could see student and staff data, gain Remote Desktop access to any server or domain controller, and even access LanSchool, a popular classroom management application. He also said he could have accessed sensitive leadership documents, reset passwords, deleted accounts, or wiped the whole network. Then, crucially, he did not do those things. Because he was a student and did not want trouble, he kept his head down, graduated without incident, and did not report the vulnerabilities, leaving open the question of whether the issues still exist today.

This is not just a “gotcha” tale about sloppy IT. It is an example of how small configuration decisions in enterprise identity systems can cascade into total compromise. Active Directory is the identity backbone for many organizations. If you can enumerate accounts, view or map policies, and reach domain controller tooling with more visibility than you should, you do not just find information. You find pathways. Paths to change security policies, elevate privileges, move laterally, and reach endpoints that look unrelated but are all connected through the same trust relationships.

The stakes get even bigger when the school’s environment included Google Workspace synchronization. Nathan’s access extended to user mailboxes because the system was synced with Google Workspace. He also found firewall settings and security policies he could change, along with keystroke histories. Read that last part carefully: keystroke history is the kind of capability that turns an identity misconfiguration into something closer to surveillance. And in an education setting, that matters on two levels at once: personal privacy for students and staff, and the integrity of school operations that depend on trustworthy systems.

Now, zoom out. Organizations typically treat identity and directory permissions as “internal” and therefore “safe enough.” Meanwhile, attackers often succeed not by cracking cryptography, but by exploiting the boring stuff: default permissions, readable secrets, mis-scoped visibility, and weak operational hygiene. Here, the failure is almost painfully mundane. Storing passwords in a description field is the opposite of defense-in-depth. It also violates basic security design instincts: treat secrets as secrets, do not embed them in fields that are meant for human-readable metadata.

There is also a regulatory and governance angle, even if this specific report does not cite a regulator or a legal finding. In many jurisdictions, organizations handling student data face scrutiny over confidentiality, integrity, and access controls. A network that could expose student data, staff data, and mailbox content is exactly the kind of risk that boards and leadership teams are asked to manage, not by trusting the network is “probably fine,” but by proving it. That means auditing privileged access, restricting visibility into directory objects, and ensuring that any integration with systems like Google Workspace uses compartmentalized admin credentials.

So what should executives take from Nathan’s restraint, and from the fact that it was restraint rather than controls that prevented harm? One: “someone could have done X” is not a theoretical risk when the system was configured in a way that made X reachable. Two: the cleanest security upgrade is often the simplest one, like removing cleartext passwords from Active Directory fields and enforcing that administrators authenticate properly for privileged actions. Three: if you let identity systems drift, you can end up with outcomes that are operationally indistinguishable from an external breach, even if the “attacker” was a student who chose not to act.

The Register ends with a pointed lesson set: do not store passwords in description fields for Active Directory. Do not store passwords in cleartext anywhere without serious controls. And Nathan’s experience suggests there should have been stronger permission boundaries so he could not have seen Active Directory domain controller tools in the first place. For decision-makers, the strategic takeaway is simple and uncomfortable: in environments where identity, classroom tooling, and email synchronization all interlock, a single misconfiguration can turn an academic network into an all-access map. The only reason it stayed a map, not a takeover, was a 17-year-old’s decision not to press the buttons.