From the Field: Over-privileged Service Accounts

🔎 𝗙𝗿𝗼𝗺 𝘁𝗵𝗲 𝗙𝗶𝗲𝗹𝗱 — Real-World Findings from Security Assessments

💥 𝟰𝟳.𝟲% of infrastructures I’ve assessed 𝗱𝗼 𝗻𝗼𝘁 𝘂𝘀𝗲 𝘁𝗵𝗲 𝗹𝗲𝗮𝘀𝘁 𝗽𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲 𝗺𝗼𝗱𝗲𝗹 𝗳𝗼𝗿 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀

Most environments still rely on basic domain user accounts as service accounts — and they’re usually highly privileged. 𝗧𝗵𝗶𝘀 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝘀𝗲𝘃𝗲𝗿𝗮𝗹 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀:

1️⃣ 𝗣𝗮𝘀𝘀𝘄𝗼𝗿𝗱𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗯𝗮𝗰𝗸𝗴𝗿𝗼𝘂𝗻𝗱 – These accounts have regular passwords, which are often weak and almost never rotated (without a 3rd-party solution). 𝗜 𝗳𝗿𝗲𝗾𝘂𝗲𝗻𝘁𝗹𝘆 𝘀𝗲𝗲 𝗽𝗿𝗲𝗵𝗶𝘀𝘁𝗼𝗿𝗶𝗰 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀 from 2003 that nobody dares to touch — because when disabled, something breaks. Many of them have 5–8 character passwords.

2️⃣ 𝗞𝗲𝗿𝗯𝗲𝗿𝗼𝗮𝘀𝘁𝗶𝗻𝗴 𝗿𝗶𝘀𝗸 – If a Service Principal Name (SPN) is registered, anyone can request a Ticket Granting Service (TGS) ticket. These are 𝗲𝗻𝗰𝗿𝘆𝗽𝘁𝗲𝗱 𝘄𝗶𝘁𝗵 𝗮 𝗸𝗲𝘆 𝗱𝗲𝗿𝗶𝘃𝗲𝗱 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁’𝘀 𝗽𝗮𝘀𝘀𝘄𝗼𝗿𝗱. If that password is weak, attackers can crack it offline and gain access.

𝗛𝗼𝘄 𝘁𝗼 𝗵𝗮𝗻𝗱𝗹𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀 𝗽𝗿𝗼𝗽𝗲𝗿𝗹𝘆:

🔹 𝗗𝗼𝗻’𝘁 𝘂𝘀𝗲 basic domain user accounts for services.

🔹 If access is needed only to local resources → use 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀 (VSA).

🔹 If access to domain resources is needed → use 𝗠𝗮𝗻𝗮𝗴𝗲𝗱 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗔𝗰𝗰𝗼𝘂𝗻𝘁𝘀 (MSA / gMSA / dMSA).

👉 With Windows Server 2025, you can more easily replace your service accounts with dMSAs.

𝗜𝗳 𝘆𝗼𝘂 𝗺𝘂𝘀𝘁 𝘂𝘀𝗲 𝗯𝗮𝘀𝗶𝗰 𝘂𝘀𝗲𝗿 𝗮𝗰𝗰𝗼𝘂𝗻𝘁𝘀:

🔸 Use long, random passwords (20+ characters).

🔸 Restrict Kerberos encryption to AES only.

✅ And the main thing, always 𝗽𝗿𝗼𝘃𝗶𝗱𝗲 𝗷𝘂𝘀𝘁 𝗲𝗻𝗼𝘂𝗴𝗵 𝗽𝗿𝗶𝘃𝗶𝗹𝗲𝗴𝗲𝘀 𝘁𝗼 𝗳𝗶𝗻𝗶𝘀𝗵 𝘁𝗵𝗲 𝘁𝗮𝘀𝗸. Do not use highly privileged groups, just because somebody asks you to, there is usually a better way.