{
	"id": "ac8e6c38-d39c-496d-b939-a338fbc37af1",
	"created_at": "2026-04-06T00:17:49.074106Z",
	"updated_at": "2026-04-10T03:24:29.750533Z",
	"deleted_at": null,
	"sha1_hash": "0e4c3fe0bab2c3df7a7fbab1aa88af43602c0b28",
	"title": "Tracking Lateral Movement Part One - Special Groups and Specific Service Accounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 762951,
	"plain_text": "Tracking Lateral Movement Part One - Special Groups and\r\nSpecific Service Accounts\r\nBy kexugit\r\nArchived: 2026-04-05 20:39:15 UTC\r\nLateral Movement - the moving of an attacker from one compromised host throughout your domain until they find\r\nwhat they are looking for - is something we see many just about all attackers doing during compromise. I've talked\r\na lot about the attacker behavior and how to stop it - strong protective controls can serve as powerful detective\r\ncontrols.\r\nThe problem for most of our customers is that they lack the visibility/documentation to comfortably put Lateral\r\nMovement preventions in place without breaking everything. Even before we put the protective controls in place\r\nwe can put some of the detective controls in place - which will give us greater insight into what is currently\r\nhappening in the environment so we can get the protective controls in faster.\r\nOne very powerful detective control I mentioned in my Ignite Australia session on monitoring : Special Groups.\r\nSpecial Groups were introduced in Windows 2008/Vista as a way to track when particular accounts log onto a\r\nsystem. Which is pretty awesome from a security/Lateral Account Movement perspective. Especially since you\r\nget to define just what group is a special group! For Lateral Account Movement and credential hygiene, we want\r\nto know if administrative accounts or highly privileged (Tier 0 in MSFT speak) accounts logon to systems,\r\nespecially systems in the workstation or member server tiers.  When you enable Special Groups, you get a unique\r\nEvent ID (4964) in the Security log that you can send to Windows Event Forwarding (which naturally you have in\r\nyour environment now because of my blog post or the in depth Microsoft Virtual Academy session . :) )\r\nGetting Event ID 4964 to show up does require some configuration, which is best done via Group Policy\r\nPreferences.\r\nFirst, we need to make sure the audit policies applied to our machines are in fact auditing for Special Logon.\r\nConfigure your GPO so Computer Configuration\\Windows Settings\\Security Settings\\Advanced Audit\r\nConfiguration\\Account Management\\Audit Special Logon is set to log Success and Failure (we do want failure\r\nhere, it's very useful once we get those protective controls in place.)\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 1 of 14\n\nNext we need to determine who is a Special Group in the organization. For the purposes of tracking Bad Guy\r\nBehaviors as well as preparing for Lateral Account Movement lockdowns I'd really like at least the following\r\nthings considered \"Special Groups.\"\r\nLocal Account : S-1-5-113 - this will help track the local accounts people may be using on your network so\r\nyou can put the Lateral Movement blocks for Local Account in later without breaking things, as well as\r\ntrack Bad Guy Behavior.\r\nDomain Admins : S-1-5-21domain-512 - we need to know if there are any workflows that are currently in\r\nplace in an organization that would lead to credential exposure before putting protective controls in place,\r\nand also alerts on Bad Guy Behavior.\r\nEnterprise Admins : S-1-5-21root domain-519 - same as Domain Admins, just Enterprise wide. Even if you\r\nonly have one domain, monitor this.\r\nSpecial Group: I recommend creating a group specifically for things you want to track with Special Logon\r\nlater, and adding it to the registry policy now. You could nest the other groups into it as well, but you might\r\nwant those specifically defined. You can use this group to add Service Accounts to for instance, then if one\r\nis used across workstations, you know you have a problem.\r\nI'd also like to see Built In Administrators : S-1-5-32-544 - we want to know when someone is logging on with\r\nadmin privileges in general from a forensic stand point often. But this may be just far too noisy in some\r\nenvironments for the first pass. Give it a try if you can.\r\nWe're using Special Group not just to track Bad Guy Behavior, but potentially dangerous administrator behaviors\r\nthat will be blocked by Lateral Movement mitigations. One of the workflows to worry about is Domain Admins\r\nusing \"Run as a Different User\" on their normal workstations. Many people now have secondary admin accounts\r\n(which is great!) but use RunAs when they are doing admin activities - such as running Active Directory Users\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 2 of 14\n\nand Computers from the same computer they are logged on and surfing the web/checking email. This behavior\r\nmay seem safe, but a RunAs is a full interactive logon that leaves credentials behind in memory.\r\n(This is why we stress the need for a hardware separation between regular and administrative credentials so much\r\nin the Pass the Hash Whitepapers.)\r\nWe need to now assemble our SIDs. Even for Domain/Enterprise Admins you can get the SID of from attribute\r\neditor, under the objectSID attribute.\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 3 of 14\n\nYou can also use the power of https://support.microsoft.com/en-us/kb/243330  to know the Domain Admins SID is\r\nalways S-1-5-21domain-512 and fill in the \"domain\" part based on another group in your domain, or you could\r\nlogon on to a Domain Controller as a Domain Admin and run whoami /groups. If you pipe it out to a text file as\r\nshown, you can get the SID from there (useful trick for other stuff too.)\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 4 of 14\n\nSo now that we have our SIDs, either make a new GPO or edit one that applies where you need it (which, is pretty\r\nmuch everywhere. Except maybe Tier 0/Domain Controllers to reduce initial noise.) Navigate to Computer\r\nConfiguration\\Preferences\\Windows Settings\\Registry\\ and create a New Registry Item. You'll want to fill it in\r\nlike the screenshot below, with the key\r\nHKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\Audit\\SpecialGroups set to a REG_SZ\r\n(string) value that contains your SIDs of interest separated by ; (semi colons.)\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 5 of 14\n\nPublic Service Announcement : whenever you're making a Group Policy Preference like a registry key, make sure\r\nto check the box on the Common tab for \"Remove this item when it is no longer applied.\" This will make sure\r\nwhen you unlink the GPO the setting is cleaned up, otherwise you can sometimes get weird tattoos on your\r\nregistry of settings you unlinked ages ago.\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 6 of 14\n\nOnce you're done, the GPO should look something like this.\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 7 of 14\n\nSo now, when Bob the Domain Admin does the dangerous behavior of Shift+ Right Click +Run as Different User\r\non his Bob the Regular User workstation we get a very descriptive alert telling us what Bob did and what group it\r\nwas that triggered the alert.\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 8 of 14\n\nNow that we have an Event ID, we can make a Subscription for this in Windows Event Forwarding. I already\r\ncovered the basics of WEF in another post, so if you haven't read that go back to get the basics.\r\nOur 4964 subscription can be quite simple :\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 9 of 14\n\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 10 of 14\n\nNow you have way more insight into what is happening on your network - both in preparation for Lateral\r\nMovement lockdowns and to keep track of Bad Guy Behaviors.\r\nAnother barrier to getting Lateral Account Movement lockdowns in place or removing Service Accounts from\r\nhigh privileged groups like Domain Admins is often the accounts are in those groups for legacy reasons, and have\r\nbeen for years. When nobody knows why the account is there, or what might break it can make even the very real\r\nand very easy to exploit threat of a Service Account in the Domain Admins difficult to mitigate for some\r\ncustomers. This is another case where Windows Event Forwarding can come to the rescue!\r\nCreating a WEF subscription for \"Where all did Service Account X log in\" is very easy to do. I recommend\r\nmaking these subscriptions one or two accounts at a time, to make it easier to narrow down what it's doing, and I\r\nrecommend making sure the subscription is targeted to both Domain Computers and Domain Controllers for\r\nvisibility into any local/NTLM logons that might not hit the Domain Controllers.\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 11 of 14\n\nI've covered the basics of Windows Event Forwarding in both an Ignite Session on Channel 9 and a previous blog\r\npost so we'll skip to just the Xpath filter you'll need to track down a specific account :\r\n\u003cQueryList\u003e\r\n\u003cQuery Id=\"0\" Path=\"Security\"\u003e\r\n\u003cSelect Path=\"Security\"\u003e\r\n(*[EventData[Data[@Name=\"TargetUserName\"] = \"Interesting Account Name 1\"]]) or\r\n(*[EventData[Data[@Name=\"TargetUserName\"] = \"Interesting Account Name 2\"]]) or\r\n(*[EventData[Data[@Name=\"TargetUserName\"] = \"Interesting Account Name ….\"]])\r\nand\r\n(*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4624 or EventID=4625 or\r\nEventID=4648)]])\r\n\u003c/Select\u003e\r\n\u003c/Query\u003e\r\n\u003c/QueryList\u003e\r\nReplace Interesting Account name with the user names you're interested in. EventID 4624 will get you all of the\r\nlogon types, service/batch/interactive so should go a long way to tracking down what is going on, but 4625 will\r\ntrack failed logons for you - which help not just with potential security issues but with troubleshooting after you\r\nreduce privileges/credential exposure. Event ID 4648 is for explicit credential logon, which is used by bad guys\r\ndoing lateral movement and sysadmins doing things like runas/mapping drives, so it's definitely an Event ID you'll\r\nwant. :)\r\nGetting these monitors enabled in your domain will not only go a long way to helping you lock down and monitor\r\nLateral Account Movement, they'll also be a huge help if you ever need an Incident Response.\r\nGood luck and happy logging!\r\n-Jessica @jepayneMSFT\r\nAnonymous\r\nNovember 28, 2015\r\nLast week at Ignite Australia I presented a session ( available here ) on something I don't think\r\nAnonymous\r\nDecember 14, 2015\r\nHi there!\r\nIn your GPO SO Audit Settings report you have specified Domain Admins SID and two strange looking\r\nSIDs:\r\nS-1-5-15-113\r\nS-1-5-115-114\r\nWhat's the purpose of that additional SIDs if their meaning is nowhere to be found?\r\nAnonymous\r\nDecember 14, 2015\r\nS-1-5-113 and S-1-5-114 are two new \"well known SIDs\" that came out with Windows 8.1 and 2012R2\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 12 of 14\n\nthat are the \"Local Account\" and \"Local Account and member of administrators\" groups. They also got\r\nbackported to Windows 7 and 2008R2 with KB2871997, so you can use them in older environments as\r\nwell! That's so you can block local accounts from being used as part of Lateral Movement, which is very\r\nvaluable and highly recommended.\r\nWell known SIDs : https://support.microsoft.com/en-us/kb/243330\r\nKB2871997 overview : http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspx\r\nPost on blocking local accounts : http://blogs.technet.com/b/secguide/archive/2014/09/02/blocking-remote-use-of-local-accounts.aspx\r\nThanks for reading!\r\n-Jessica\r\nAnonymous\r\nDecember 14, 2015\r\nExcellent post, Jessica! I'm looking forward to part 2!\r\nAnonymous\r\nDecember 15, 2015\r\n\"Pretty awesome\" Like for sure... totally tubular Jess.\r\nAnonymous\r\nDecember 18, 2015\r\nThere is a typo for these new SIDs, both in the article and in the comment from Jess.\r\nThe right ones are S-1-5-113 and S-1-5-114.\r\nWell-Known SID Structures: https://msdn.microsoft.com/en-us/library/cc980032.aspx?\r\nf=255\u0026MSPPError=-2147217396\r\nAnonymous\r\nDecember 18, 2015\r\nI don't know if there's an issue with the post versions but, I did Control+F/find from what Jean-Marc has\r\nand it's what's in the article and comment for me. But if you're seeing some old version, yes Jean-Marc's\r\nlink is correct for the SIDs. Sorry if there's any confusion.\r\n-Jessica\r\nAnonymous\r\nDecember 28, 2015\r\nHi, Jessica Payne from Microsoft Enterprise Cybersecurity Group's Global Incident Response and\r\nRecovery\r\nAnonymous\r\nJuly 29, 2016\r\nGreat information, thanks! I can't seem to get \"Local account with administrator\" to work on Windows 7\r\nhosts. When an account is local and an administrator, I don't get anything logged. Local account that is not\r\nan administrator works fine. I have a case open with support, so hoping to get it worked out.\r\nAnonymous\r\nJuly 30, 2016\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 13 of 14\n\nI'm helping out your support engineer - once we get it pinned down we'll make sure to update your\r\ncase and I'll post to the blog post. Thanks for pointing it out to us! -Jessica\r\nSource: https://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accou\r\nnts\r\nhttps://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts\r\nPage 14 of 14\n\n https://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts       \nSo now, when Bob the Domain Admin does the dangerous behavior of Shift+ Right Click +Run as Different User\non his Bob the Regular User workstation we get a very descriptive alert telling us what Bob did and what group it\nwas that triggered the alert.       \n   Page 8 of 14    \n\nAnonymous December 14, 2015      \nS-1-5-113 and S-1-5-114 are two new \"well known SIDs\" that came out with Windows 8.1 and 2012R2\n   Page 12 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts"
	],
	"report_names": [
		"tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434669,
	"ts_updated_at": 1775791469,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0e4c3fe0bab2c3df7a7fbab1aa88af43602c0b28.pdf",
		"text": "https://archive.orkl.eu/0e4c3fe0bab2c3df7a7fbab1aa88af43602c0b28.txt",
		"img": "https://archive.orkl.eu/0e4c3fe0bab2c3df7a7fbab1aa88af43602c0b28.jpg"
	}
}