{
	"id": "3cefbf59-b850-4821-8c2d-d9a793958ba1",
	"created_at": "2026-04-06T15:53:59.717871Z",
	"updated_at": "2026-04-10T03:21:57.45647Z",
	"deleted_at": null,
	"sha1_hash": "39bdfe250d4ab38e0e5e5e312dc1fab14cf01aeb",
	"title": "Attractive Accounts for Credential Theft",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 42841,
	"plain_text": "Attractive Accounts for Credential Theft\r\nBy robinharwood\r\nArchived: 2026-04-06 15:14:17 UTC\r\nCredential theft attacks are those in which an attacker initially gains highest-privilege (root, Administrator, or\r\nSYSTEM, depending on the operating system in use) access to a computer on a network and then uses freely\r\navailable tooling to extract credentials from the sessions of other logged-on accounts. Depending on the system\r\nconfiguration, these credentials can be extracted in the form of hashes, tickets, or even plaintext passwords. If any\r\nof the harvested credentials are for local accounts that are likely to exist on other computers on the network (for\r\nexample, Administrator accounts in Windows, or root accounts in OSX, UNIX, or Linux), the attacker presents the\r\ncredentials to other computers on the network to propagate compromise to additional computers and to try to\r\nobtain the credentials of two specific types of accounts:\r\n1. Privileged domain accounts with both broad and deep privileges (that is, accounts that have administrator-level privileges on many computers and in Active Directory). These accounts may not be members of any\r\nof the highest-privilege groups in Active Directory, but they may have been granted Administrator-level\r\nprivilege across many servers and workstations in the domain or forest, which makes them effectively as\r\npowerful as members of privileged groups in Active Directory. In most cases, accounts that have been\r\ngranted high levels of privilege across broad swaths of the Windows infrastructure are service accounts, so\r\nservice accounts should always be assessed for breadth and depth of privilege.\r\n2. \"Very Important Person\" (VIP) domain accounts. In the context of this document, a VIP account is any\r\naccount that has access to information an attacker wants (intellectual property and other sensitive\r\ninformation), or any account that can be used to grant the attacker access to that information. Examples of\r\nthese user accounts include:\r\n1. Executives whose accounts have access to sensitive corporate information\r\n2. Accounts for Help Desk staff who are responsible for maintaining the computers and applications\r\nused by executives\r\n3. Accounts for legal staff who have access to an organization's bid and contract documents, whether\r\nthe documents are for their own organization or client organizations\r\n4. Product planners who have access to plans and specifications for products in an company's\r\ndevelopment pipeline, regardless of the types of products the company makes\r\n5. Researchers whose accounts are used to access study data, product formulations, or any other\r\nresearch of interest to an attacker\r\nBecause highly privileged accounts in Active Directory can be used to propagate compromise and to manipulate\r\nVIP accounts or the data that they can access, the most useful accounts for credential theft attacks are accounts\r\nhttps://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft\r\nPage 1 of 4\n\nthat are members of Enterprise Admins, Domain Admins, and Administrators groups in Active Directory.\r\nBecause domain controllers are the repositories for the AD DS database and domain controllers have full access to\r\nall of the data in Active Directory, domain controllers are also targeted for compromise, whether in parallel with\r\ncredential theft attacks, or after one or more highly privileged Active Directory accounts have been compromised.\r\nAlthough numerous publications (and many attackers) focus on the Domain Admins group memberships when\r\ndescribing pass-the-hash and other credential theft attacks (as is described in Reducing the Active Directory\r\nAttack Surface), an account that is a member of any of the groups listed here can be used to compromise the entire\r\nAD DS installation.\r\nBecause the target of credential theft is usually highly privileged domain accounts and VIP accounts, it is\r\nimportant for administrators to be conscious of activities that increase the likelihood of success of a credential-theft attack. Although attackers also target VIP accounts, if VIPs are not given high levels of privilege on systems\r\nor in the domain, theft of their credentials requires other types of attacks, such as socially engineering the VIP to\r\nprovide secret information. Or the attacker must first obtain privileged access to a system on which VIP\r\ncredentials are cached. Because of this, activities that increase the likelihood of credential theft described here are\r\nfocused primarily on preventing the acquisition of highly privileged administrative credentials. These activities are\r\ncommon mechanisms by which attackers are able to compromise systems to obtain privileged credentials.\r\nThe core vulnerability that allows credential theft attacks to succeed is the act of logging on to computers that are\r\nnot secure with accounts that are broadly and deeply privileged throughout the environment. These logons can be\r\nthe result of various misconfigurations described here.\r\nAlthough this is relatively uncommon, in assessing various AD DS installations, we have found IT employees\r\nusing a single account for all of their work. The account is a member of at least one of the most highly privileged\r\ngroups in Active Directory and is the same account that the employees use to log on to their workstations in the\r\nmorning, check their email, browse Internet sites, and download content to their computers. When users run with\r\naccounts that are granted local Administrator rights and permissions, they expose the local computer to complete\r\ncompromise. When those accounts are also members of the most privileged groups in Active Directory, they\r\nexpose the entire forest to compromise, making it trivially easy for an attacker to gain complete control of the\r\nActive Directory and Windows environment.\r\nSimilarly, in some environments, we've found that the same user names and passwords are used for root accounts\r\non non-Windows computers as are used in the Windows environment, which allows attackers to extend\r\ncompromise from UNIX or Linux systems to Windows systems and vice versa.\r\nWhen a highly privileged domain account is used to log on interactively to a compromised workstation or member\r\nserver, that compromised computer may harvest credentials from any account that logs on to the system.\r\nIn many organizations, IT staff use multiple accounts. One account is used for logon to the employee's\r\nworkstation, and because these are IT staff, they often have local Administrator rights on their workstations. In\r\nsome cases, UAC is left enabled so that the user at least receives a split access token at logon and must elevate\r\nwhen privileges are required. When these users are performing maintenance activities, they typically use locally\r\ninstalled management tools and provide the credentials for their domain-privileged accounts, by selecting the Run\r\nhttps://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft\r\nPage 2 of 4\n\nas Administrator option or by providing the credentials when prompted. Although this configuration may seem\r\nappropriate, it exposes the environment to compromise because:\r\nThe \"regular\" user account that the employee uses to log on to their workstation has local Administrator\r\nrights, the computer is vulnerable to drive-by download attacks in which the user is convinced to install\r\nmalware.\r\nThe malware is installed in the context of an administrative account, the computer can now be used to\r\ncapture keystrokes, clipboard contents, screenshots, and memory-resident credentials, any of which can\r\nresult in exposure of the credentials of a powerful domain account.\r\nThe problems in this scenario are twofold. First, although separate accounts are used for local and domain\r\nadministration, the computer is unsecured and does not protect the accounts against theft. Second, the regular user\r\naccount and the administrative account have been granted excessive rights and permissions.\r\nUsers who log on to computers with accounts that are members of the local Administrators group on the computer,\r\nor members of privileged groups in Active Directory, and who then browse the Internet (or a compromised\r\nintranet) expose the local computer and the directory to compromise.\r\nAccessing a maliciously crafted website with a browser running with administrative privileges can allow an\r\nattacker to deposit malicious code on the local computer in the context of the privileged user. If the user has local\r\nAdministrator rights on the computer, attackers may deceive the user into downloading malicious code or opening\r\nemail attachments that leverage application vulnerabilities and leverage the user's privileges to extract locally\r\ncached credentials for all active users on the computer. If the user has administrative rights in the directory by\r\nmembership in the Enterprise Admins, Domain Admins, or Administrators groups in Active Directory, the attacker\r\ncan extract the domain credentials and use them to compromise the entire AD DS domain or forest, without\r\nneeding to compromise any other computer in the forest.\r\nConfiguring the same local Administrator account name and password on many or all computers enables\r\ncredentials stolen from the SAM database on one computer to be used to compromise all other computers that use\r\nthe same credentials. At a minimum, you should use different passwords for local Administrator accounts across\r\neach domain-joined system. Local Administrator accounts may also be uniquely named, but using different\r\npasswords for each system's privileged local accounts is sufficient to ensure that credentials cannot be used on\r\nother systems.\r\nGranting membership in the EA, DA, or BA groups in a domain creates a target for attackers. The greater the\r\nnumber of members of these groups, the greater the likelihood that a privileged user may inadvertently misuse the\r\ncredentials and expose them to credential theft attacks. Every workstation or server to which a privileged domain\r\nuser logs on presents a possible mechanism by which the privileged user's credentials may be harvested and used\r\nto compromise the AD DS domain and forest.\r\nDomain controllers house a replica of a domain's AD DS database. In the case of read-only domain controllers, the\r\nlocal replica of the database contains the credentials for only a subset of the accounts in the directory, none of\r\nwhich are privileged domain accounts by default. On read-write domain controllers, each domain controller\r\nmaintains a full replica of the AD DS database, including credentials not only for privileged users like Domain\r\nAdmins, but privileged accounts such as domain controller accounts or the domain's Krbtgt account, which is the\r\nhttps://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft\r\nPage 3 of 4\n\naccount that is associated with the KDC service on domain controllers. If additional applications that are not\r\nnecessary for domain controller functionality are installed on domain controllers, or if domain controllers are not\r\nstringently patched and secured, attackers may compromise them via unpatched vulnerabilities, or they may\r\nleverage other attack vectors to install malicious software directly on them.\r\nRegardless of the attack methods used, Active Directory is always targeted when a Windows environment is\r\nattacked, because it ultimately controls access to whatever the attackers want. This does not mean that the entire\r\ndirectory is targeted, however. Specific accounts, servers, and infrastructure components are usually the primary\r\ntargets of attacks against Active Directory. These accounts are described as follows.\r\nBecause the introduction of Active Directory, it has been possible to use highly privileged accounts to build the\r\nActive Directory forest and then to delegate rights and permissions required to perform day-to-day administration\r\nto less-privileged accounts. Membership in the Enterprise Admins, Domain Admins, or Administrators groups in\r\nActive Directory is required only temporarily and infrequently in an environment that implements least-privilege\r\napproaches to daily administration.\r\nPermanent privileged accounts are accounts that have been placed in privileged groups and left there from day to\r\nday. If your organization places five accounts into the Domain Admins group for a domain, those five accounts\r\ncan be targeted 24-hours a day, seven days a week. However, the actual need to use accounts with Domain Admins\r\nprivileges is typically only for specific domain-wide configuration, and for short periods of time.\r\nAn often overlooked target in Active Directory breaches is the accounts of \"very important persons\" (or VIPs) in\r\nan organization. Privileged accounts are targeted because those accounts can grant access to attackers, which\r\nallows them to compromise or even destroy targeted systems, as described earlier in this section.\r\n\"Privilege-attached\" Active Directory accounts are domain accounts that have not been made members of any of\r\nthe groups that have the highest levels of privilege in Active Directory, but have instead been granted high levels\r\nof privilege on many servers and workstations in the environment. These accounts are most often domain-based\r\naccounts that are configured to run services on domain-joined systems, typically for applications running on large\r\nsections of the infrastructure. Although these accounts have no privileges in Active Directory, if they are granted\r\nhigh privilege on large numbers of systems, they can be used to compromise or even destroy large segments of the\r\ninfrastructure, achieving the same effect as compromise of a privileged Active Directory account.\r\nSource: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft\r\nhttps://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/attractive-accounts-for-credential-theft"
	],
	"report_names": [
		"attractive-accounts-for-credential-theft"
	],
	"threat_actors": [],
	"ts_created_at": 1775490839,
	"ts_updated_at": 1775791317,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/39bdfe250d4ab38e0e5e5e312dc1fab14cf01aeb.pdf",
		"text": "https://archive.orkl.eu/39bdfe250d4ab38e0e5e5e312dc1fab14cf01aeb.txt",
		"img": "https://archive.orkl.eu/39bdfe250d4ab38e0e5e5e312dc1fab14cf01aeb.jpg"
	}
}