Silicon Shecky

Infosec Practitioner

  • About
  • Categories
    • General
    • Computers
    • Software
    • Rants
    • Security
    • Internet/Music
    • Reviews
    • Microsoft
    • Hardware
    • Mobile Computing
  • Links
    • Infosec
      • Burbsec
      • Infosec Exchange Mastodon
      • Hacks4Pancakes Blog
      • Krebs On Security
      • Bleeping Computer
  • Archives

Connect

  • Bluesky
  • LinkedIn
  • Mastodon
  • RSS
  • Twitter

[footer_backtotop]

Copyright © 2025 ·Sixteen Nine Pro Theme · Genesis Framework by StudioPress · WordPress

DCSync, where the heck did that come from?

October 25, 2018 By Michael Kavka Leave a Comment

Have you every had a pentest or red team report that talks about DCSync? How much of it has been hair pulling? What is DCSync and what is the significance of it?

When securing Active Directory, there are a ton of moving parts, and even more rights available, especially when you add in extended rights. There is a set though, that can get assigned, which are used for synchronizing all of Active Directory. Two of them work together and allow for the copying of secret information, such as password hashes. This right is important when do certain types of sign on using AD credentials, such as Sharepoint, or synchronizing with Azure. It also allows for Domain Controllers to synchronize all the domain information between them. The rights, “Replicating Domain Changes” and “Replicating Domain Changes All”, have that much power, but to be able to get a full sync with password hashes you need both rights. The idea is to keep these rights, especially the All right, to a bare minimum of user/services accounts. This is important to prevent Mimikatz’s DCSync attack, which essentially makes a copy of all the AD information so one can crack passwords offline.

One would think this should not be a big deal, but it can get out of control very quickly. For starters, the only place that you can directly see these rights is at the root of the domain when using ADUC (Active Directory Users and Computers). Even when propagated down you cannot just see it as part of the advanced security section of the properties, to remove it. Second, you can get it by being granted full control, or part of a group that is granted full control, of a group that either has the right granted directly from the root, or from a group that already has the rights propagated down to it. You can see this sort of delegation of rights by using a tool such as BloodhoundAD to map out the relationships. Another way one can get this right is through being assigned it through delegation at the root of the domain. The end result of all of this is that, there should be little to no reason for normal, or even admin users to have the Replicating Domain Changes All right. Certain services account that are not allowed interactive logon may need it, such as a service account to replicate to Azure as mentioned before. Bottom line, this right should not be given out unless absolutely necessary.

So we have a tool in BloodhoundAD that can show us what accounts and groups have this right. It shows if they are getting it through a security assignment such as Full Control, or if it is because of being a member of a group with the right. The fear on removing the right is knowing if it will break anything. How do we know what accounts are actually using said right? Windows Logs come in handy on this instance, as long as you are getting them from Domain Controllers.

Finding the search string happened for me while learning about information I was getting from a search I found in the Blue Team Field Manual, which gives some nice searches using Powershell for event logs. The one that started everything for me was their Domain Service Access – Audit Directory Service Access. More specifically, Event ID 4662is the one to search for. From there, I started looking at what Access Masks meant what, finding that Access Mask 0x100  is the Control Access property. The actual rights that it uses are given in GUID format. Some searching on the GUIDs gave me the following that relate to the extended rights “Replicating Directory Changes” GUID:{19195a5b\-6da0\-11d0\-afd3\-00c04fd930c9\}  and “Replicating Directory Changes All” GUID:{1131f6aa\-9c07\-11d1\-f79f\-00c04fc2dcd2} . The big thing is that it shows Computer Accounts, such as Domain Controllers, using the rights to synchronize between themselves, and any user accounts that are actually using the rights, such as an Azure service account, that is using it. Filtering out the computer accounts will show what accounts are actually doing any synchronization. This allows for one to ask account owners why they might be synchronizing the domain with said account. Through that, one can easily get a good idea of what will happen if the Replicating Directory Changes All right is removed, and reassign accounts that actually need the right to have it directly from the root of the domain, thereby allowing removal the right from groups also. In Graylog the search if you are using NXLog into a GELF input to parse the Event Log information properly the search would like like this:

EventID:4662 AND AccessMask:0x100 AND ObjectType:"%\{19195a5b\-6da0\-11d0\-afd3\-00c04fd930c9\}" AND "{1131f6aa\-9c07\-11d1\-f79f\-00c04fc2dcd2}" AND NOT SubjectUserName:*$

Mind you that using *$ requires in Graylog that you have configured Graylog to accept wildcards as the start of a search string. If that is not configured you should be able to put the first character of your naming scheme then the wildcard and $. In Splunk the search would be similar, making sure you use the proper index and field name for EventIDs in Splunk.

This gives a basic way to search for an attacker attempting to make a copy of the domain. You could potentially remove the GUID for Replicating Domain Changes ALL from the search and see anyone trying to copy all the non-secret information from the domain, again a way for attachers to do searches through the domain offline, and thereby making less noise.

As always, if I have made any errors in this, feel free to let me know, and feel free to discuss all of this

Filed Under: General Tagged With: Blue Team, DCSync, Graylog, Replicating Directory Changes, Replicating Directory Changes All, SIEM

Sportsball and Infosec

February 8, 2018 By Michael Kavka Leave a Comment

This past weekend was the Superbowl (yeah suck it NFL, I am using the word), and of course you get all the people who are not into sports with their meme’s and complaints about so much talk on sportsball. Hold on a moment though, there are similarities between our world of infosec and the world of sports, and I do not mean poker, chess or any of the other things along those lines. I mean the big name sports.

Back in the 90’s I was a coach for youth football. It was a volunteer position, and I enjoyed it. In fact, I have always enjoyed sports, but recently I started to wonder if there were lessons I could learn from understanding sports, that could be applied to the world of infosec. The answer is yes. Lets take a look at the “Big 4”, football, baseball, basketball and hockey, and how they can relate to the world of infosec.

The big 4 sports are all strategy based. Some, like baseball, are more individual compared to team based. I am not saying there is not a team aspect to baseball, but it is not as important in the overall strategy. The thing with all of them is you watch, you record stats, you analyze, you make a plan and then you adjust on the fly(if your coaching staff is any good). Baseball is a slower paced game, hockey and basketball are constant motion, and football is in between. Hockey and Basketball really can represent a full on attack with an active defense. The constant motion means everything is constantly changing. No break. Thin of this like dealing with an ongoing incident. Baseball, with its much slower pace is more along the lines of setting up new policies, procedures and technology. You have time, you can look at things and make a long term decision. Football I see as more the day to day type activities, but does encompass both the speed at times of baseball and of Hockey/basketball. I think it also has the most to teach us.

Football, at least at the college and pro levels, works like this. You have an opponent that you are facing. Over the past week you have watched film on them, devised a plan to stop them when they are on offense, and break through their defense, or in our terms blue and red team. When on defense you have to get everything right to stop them. The smallest mistake and they advance (or score). When on offense you only need to find the one weakness in the defense. When the play is actually going, it is fast paced, decisions have to be made split second. Take a wrong angle, you miss stopping them. Slip and they get past you. In between plays you get a chance to set up for the next attack. this setup is usually based on tendencies discovered between watching film of prior games the opponent has played, and statistics available, or in our world going through logs and stats and doing research. Conversely, when on offense the use the same research or OSINT to find the holes on defense and exploit them. During the course of the game it has to be agile and fast responses. Without that agility they get pwned er scored on.

So what can we learn from all of this? First, our world is not much different than the world of sports. Our ball (or puck) is data, our goal (basket, base) are locations (servers, folders, shares). Studying how the coaches come up with their plans in sports may give us better ideas on how to plan out our world, red and blue team. How they have learned to make fast adjustments is a skill we can learn. How they innovate can give us insight in how we can do that better.

This is just a small look, a quick overview of the similarities. Just a thought I had while watching the Superbowl this weekend, and something I am continuing to look at. Our world gets stagnant and we need to find other ways and angles to look at it otherwise we are sunk. This is just one idea.

Filed Under: General Tagged With: Blue Team, InfoSec, OSINT, Red team

RSS Taggart Institute Intel Feed

  • Shaq's new ride gets jaq'ed in haq attaq October 26, 2025 Brandon Vigliarolo
  • The Kavanaugh stop, 50 days later October 26, 2025 Chris Geidner
  • Kaitai Struct WebIDE, (Sun, Oct 26th) October 26, 2025
  • [REVIVE-SA-2025-002] Revive Adserver Vulnerability October 26, 2025
  • [REVIVE-SA-2025-001] Revive Adserver Vulnerability October 26, 2025
  • New CoPhish attack steals OAuth tokens via Copilot Studio agents October 25, 2025 Bill Toulas
  • What Really Doomed Napoleon’s Army? Scientists Find New Clues in DNA October 25, 2025 Becky Ferreira
  • MPs urge government to stop Britain's phone theft wave through tech October 25, 2025 Lindsay Clark
  • Beyond good ol’ Run key, Part 153 October 25, 2025 adam
  • Cloud Discovery With AzureHound October 24, 2025 Margaret Kelley

Browse by tags

Active Directory Android Antivirus Apple Beta Chrome Computers Exchange Exchange 2007 Firefox General Thoughts Google InfoSec Internet Explorer iOS iPad IT Linux Mac Malware Microsoft OS OSx Patches Rants SBS SBS 2008 Security Security Patches Server SMB Software Support Surface TechEd Tweets Ubuntu Verizon Virus Vista vulnerabilities Windows Windows 7 Windows 8 XP