Why does a municipal ISAC share "we saw T1078 Valid Accounts" instead of victim usernames?
Select an answer to reveal the explanation.
Short Explanation
"T1078" is a street sign, not a name tag. Peer cities know where to hunt without getting a dump of resident or staff identities—and nobody needs the treasurer's password in the intel packet.
Full Explanation
Municipal ISACs share "we saw T1078 Valid Accounts" because shared TTP language is actionable for every peer SOC and avoids exposing civic personally identifiable information such as staff usernames. Peer cities can hunt valid-account abuse patterns without receiving a dump of resident or employee identities. Technique IDs travel safely across trust boundaries; victim account names usually do not.
Claiming technique IDs are encrypted hashes of the victim's mailbox fails factually—ATT&CK IDs are public catalog keys, not ciphertext of PII. Asserting ISAC sharing is only allowed for MD5 hashes, never ATT&CK technique IDs, inverts modern intel practice and invents a policy ban. Saying Valid Accounts cannot be hunted unless the ISAC also sends the treasurer's password fails on both privacy and necessity—password sharing would be reckless, and technique-directed hunts do not require the credential secret.
Exam caveat: prefer technique sharing over identity dumps; distractors often smuggle PII or passwords into "required" intel packages.
Operational check: scrub usernames, employee IDs, and credentials from outbound ISAC packets; ship ATT&CK technique IDs, time windows, and sanitized infrastructure indicators; confirm receiving municipal SOCs can still run Valid Accounts hunts from that package alone.