Try now

Wednesday, July 8, 2020

How Active Directory Security Permissions Control Privileged Access


Folks,

Hello. I hope this finds you doing well. This post is Day-5 of Active Directory Security for Cyber Security Experts.


In today's post, I wanted to make the essence of Active Directory Security super simple for everyone to understand, because this is necessary before we dive into analyzing the many specific examples in the accompanying demo VM.



Active Directory Security, Distilled

Perhaps the best way to understand Active Directory is by distilling it down to ten simple points -


  1. Every thing inside Active Directory is an Active Directory object

  2. Every object in Active Directory is protected by an access control list (ACL)
  3. Every ACL protecting every object contains zero or more access control entries (ACEs)
  4. Every ACE allows or denies one or more security permissions for a specific security principal (SP)
  5. Every security principal (account, group, well-known/F SP) is uniquely identified by its security identifier (SID)
  6. Every account has an access token that contains its SID and the SIDs of all security groups* to which it belongs

  7. Every security permission specified in an ACE is either explicit (set on the object) or inherited (from the parent)
  8. Every security permission is either a standard Active Directory permission, an extended right or a validate write

  9. Every ACE in the ACL is placed in accordance with a precedence order that governs how ACEs impact the resulting (i.e. effective) access for a user, which is:  Explicit Deny > Explicit Allow > Inherited Deny > Inherited Allow

  10. When a user requests access to an AD object, the system performs an access check that examines the ACEs in the object's ACL to determine a) whether or not any SID in the requestor's access token is denied any of the requested access in any of the ACEs in the ACL, and b) whether or not one or more ACEs in the ACL allow all of the requested access rights, and the outcome of this access check governs whether or not the requested access is granted.

    Consequently, the actual (i.e. effective) access that a user has on an AD object is determined by the impact of all ACEs in its ACL that allow or deny some form of access for the user, or for any group* to which the user belongs.



Active Directory Security Permissions

If everything in Active Directory is an AD object protected by an ACL in which lie ACEs that grant various Active Directory security permissions, then we must possess a very good understanding of these Active Directory security permissions.


There are thirteen types of Active Directory Security Permissions -
  1. Read Control (RC) - These permissions control who can read security permissions specified in AD object ACLs.

  2. List Child (LC) - These permissions control who can view the child objects of a specific object in AD.

  3. List Object (LO) - These permissions only come into play in a special mode in Active Directory called the List Object mode, and in that mode they provide more granular control on who can view individual child objects of an object.

  4. Read Property (RP) - These permissions control who can read the properties of an AD object. The Object Type field can be used to specify that they only control read access to a specific property (or a property set) on the object.

  5. Write Property (WP) - These permissions control who can modify the properties of an object. The Object Type field can be used to specify that they only control write access to a specific property (or a property set) on the object.

  6. Create Child (CC) - These permissions control who can create an object under an object in AD. The Object Type field can be used to specify that they only control the creation of objects of a specified object class e.g. user.

  7. Standard Delete (SD) - These permissions controls who can delete an object via a standard delete operation.

  8. Delete Child (DC) - These permissions control who can delete child objects of an object. The Object Type field can be used to specify that they only control the deletion of objects of a specified object class e.g. user.

  9. Delete Tree (DT) - These permissions control who can delete a tree of objects in AD via a delete-tree operation.

  10. Modify Permissions (WD) - These permissions control who can modify permissions protecting an AD object

  11. Modify Owner (WO) - These permissions* control who can modify the owner of an AD object

  12. Extended Right (CR) - These permissions control who can enact special operations in AD. The Object Type field can be used to specify that they only control a specific special operation on an object (e.g. Reset Password etc.)

  13. Validated Write (SW) - These permissions control who can enact certain special writes (that require validation) on certain AD objects. The Object Type field can be used to specify that they only control a specific validated write on an object.

  14. SDDL: The two-letter abbreviations (e.g. RC, LC, LO, RP, WP, CC, SD, DC, DT, WD, WO, CR and SW) that follow the names of these various permissions are the SDDL mnemonics used to specify these permissions.

The above is a simplified explanation of AD security permissions. For details, please refer to Microsoft's documentation.

Once you have a good understanding of these thirteen Active Directory Security Permissions and how they work, it is easy and straightforward to understand how they impact and govern exactly who has what privileged access in Active Directory.



How Active Directory Security Permissions
Control Privileged Access in Active Directory

In light of the above, every privileged action that can be enacted in Active Directory boils down to a user requesting, and the resulting access check permitting, the ability to perform a simple modify operation on an Active Directory object.


Here are the Top-10 administrative (i.e. privileged) tasks in Active Directory AND the modify access they involve -

  1. Create a user account - Requires "Create Child User-object" effective permissions on target object

  2. Enable an account - Requires "Write Property userAccountControl attribute" effective permissions on user object

  3. Reset an account's password - Requires "Extended Right Reset-password" effective permissions on user object

  4. Change a group membership - Requires "Write Property member attribute" effective permissions on group object

  5. Change a user's membership - Requires "Write Property member attribute" effective permissions on group object

  6. Modify an object's ACL - Requires "Modify Permissions" effective permissions on target object

  7. Link a GPO to an OU - Requires "Write Property gpLink attribute" effective permissions on OU object

  8. Change a computer's DNS name: Requires "Validated Write Change DNS Host Name" on computer object

  9. Delete an Organizational Unit (OU) - Requires "Standard-Delete" effective permissions on OU object, or "Delete-Child" effective permissions on parent* object, or "Delete Tree" effective permissions on any ancestor object

  10. Replicate secrets from domain - Requires two extended rights, "Extended Right Get Replication Changes" and "Extended Right Get Replication Changes All" effective permissions on the domain root object

In short, enacting a privileged action in Active Directory requires a specific type of access on specific target AD objects, and anyone who has sufficient required effective permissions on these target objects can enact these privileged actions.

Thus, once you know exactly which security permissions entitle a user to a specific privileged action in AD, you can find out exactly who was what privileged access where and how in AD, by determining who has those effective permissions.



Top-10 Examples of Privileged Access in Active Directory

Here are ten simple, common examples of administrative tasks that require/involve privileged access in Active Directory, and as we have seen above, it is Active Directory security permissions that control exactly who can enact these tasks -

  1. Create a new domain user account for legitimate or nefarious use

  2. Delete an existing account or group, or an OU containing thousands of accounts and groups

  3. Enable a currently disabled domain user account, or unexpired an expired domain user account

  4. Reset a domain user account's password, such as that of the CEO or the default Administrator account

  5. Modify a domain security group's membership, such as that of the all-powerful Domain Admins security group

  6. Modify security permissions on an AD object, such as on the domain root, an OU or the AdminSDHolder object

  7. Link a group policy (GPO) to an OU, for legitimate or nefarious (e.g. unleashing ransomware domain-wide) use

  8. Modify a domain-joined computer's account in AD, such as by setting it to be Trusted for Unconstrained Delegation

  9. Modify the keywords associated with a critical service connection point, such as one used to integrate with Azure.

  10.  Replicate secrets from Active Directory (the enactment of which is almost always for nefarious reasons)

Thus, as you can, virtually every privileged action that somone could enact in any Active Directory deployment worldwide, is controlled and governed by the various Active Directory security permissions that reside in Active Directory object ACLs.



Specifically, if you connect the three dots above (i.e. the three aspects of AD Security described above), then you'll know that ALL privileged access in Active Directory is governed by "who has what effective permissions in Active Directory" because multiple ACEs in an object's ACL could impact whether or not the access requested by a user is granted.




Summary

That'll be all for today. Today, I just wanted to share with you three essential technical aspects of Active Directory Security that today govern and control exactly who has what privileged access at 85% of all organizations across the world today.


Speaking of which, did you know that for years IT professionals at organizations have errantly believed that to find out who has what privileged access in Active Directory, they just need to analyze permissions in Active Directory, whereas in reality, it is not "who has what permissions in Active Directory" but in fact "who has what effective permissions in Active Directory" that governs who has what privileged access in Active Directory.

Consequently, today most organizations do not even possess the means to audit effective permissions in Active Directory; they only possess the means (tools) to find out "who has what permissions" which is vastly insufficient and mostly futile, and as a result, most of them have no idea as to exactly who has what privileged access in their Active Directory today.



That's it for now. There's only one more theory lesson remaining before we can dive into over a dozen exciting examples that exist in the accompanying demo VM, and in the next lesson i.e. Day 6's lesson, I will cover that theory lesson by shedding light into the most important technical aspect of Active Security - Active Directory Effective Permissions.


Best wishes,
Sanjay.



PS: Answers to the 3 simple questions I had asked in my previous post -
  • Number of ACEs domain-wide: 177396 (excluding objects in the System container.)
  • Number of members in Domain Admins security group: 13
  • Number of ACEs that directly/indirectly impact Write Property Member in ACL of the Domain Admins group: 9*
  • Amount of time it took me to make these determinations: Less than 1 minute (each.)

Monday, June 29, 2020

Day 4 - Active Directory Security Permissions, Tooling AND a Challenge


Folks,

Hello. I hope this finds you doing well. This post is Day-4 of Active Directory Security for Cyber Security Experts.


TODAY, we'll begin by 1) re-visiting a simple fact, 2) putting your arsenal together and 3) YOUR first challenge.





Active Directory Security Permissions - The Keys to Every Door in the Kingdom

If you're into IT or cyber security, then you likely already know this ONE simple technical fact which is worth reiterating -

  1. 85% of all organizations worldwide operate on Microsoft Active Directory - From Microsoft to Amazon, and from the White House to the entire U.S. Government, every relevant organization in the world operates on Active Directory.

  2. 100% of everything in Active Directory is an AD object protected by an ACL - From the Domain Admins group to the domain root object, to every employee's (e.g. CEO, CISO etc.) account and computer, to every security group (e.g. All Employees, Executives etc.) used to lockdown access to every IT asset in the organization (i.e. all files, folders, Exchange mailboxes, databases, apps, portals etc.), literally everything is an object in Active Directory.

  3. It is the complete set of Active Directory security permissions that exist in the ACL (access control list) of every Active Directory object that collectively govern exactly who can do what on that Active Directory object.

If you connect the above three dots, you'll arrive at the conclusion that at the end of the day, it is Active Directory security permissions that ultimately protect and govern the security of virtually every IT asset in every organization worldwide.

In short, not just the "Keys to the Kingdom", the "Keys to Every Door in the Kingdom" lie in AD Security Permissions.




Three Technical Pointers

Given the paramount importance that Active Directory Security permissions play in organizational cyber security today, in order to gain proficiency in Active Directory Security, one must know Active Directory Security permissions well.


So, here are a few technical pointers that I recommend we all go through to learn more about them -
  1. Active Directory Security Permissions (here), How Access Checks work (here) & Order of ACEs in a DACL (here)

  2. Best Practices for Delegating Administration in AD, Appendix C: Active Directory Security Permissions (See * below)

  3. Best Practices for Delegating Administration in AD, Chapter 2: How Delegation Works in Active Directory (" * below)

  • * Note: The content referenced in 2 and 3 above was part of a 400 page whitepaper I had written while I was at Microsoft, titled "Best Practices for Delegating Administration in Active Directory". For reasons best known to Microsoft, it was removed from its Technet Site. Fortunately, you can still access it if you know where to find it. The only place it is available is as a part of "Windows Server 2003 Retired Content", which is a massive 150 MB PDF file which you can still download from here. To locate this content in that download, install Adobe PDF Reader (needed to open the massive 150 MB PDF), open the PDF and search for my name in it (Page: 8186.)

Please take a few moments to review and learn from these simple yet vital technical pointers. I apologize that there is no good content online from Microsoft to share with you - not sure why Microsoft has pulled so much important content. :-(


Finally, if you have more time and truly want to gain a deep understanding of how access control, access checks, access assessment etc. all work in Active Directory, you can review this authoritative patent on the subject, which today is cited by Microsoft, Palantir, CyberArk, Quest, Amazon, Vmware, IBM and other notable companies.





Active Directory Permissions Analysis Tooling

Over the next day thirty days, I am going to be issuing ten challenges, each one motivated by the desire to teach you something specific and valuable, and each one involving and requiring you to analyze permissions in Active Directory.


So, please feel free to put together your own arsenal of tools so you can accept these ten simple, educative challenges.

Further, to help you put this together, here's a list of just about every tool that I know of that can help organizations analyze Active Directory Security Permissions today, listed in alphabetical order by name of the tool to ensure objectivity -
  1. Acldiag (Microsoft)
  2. Aclight (CyberArk)
  3. Active Directory ACL Analyzer (Paramount Defenses)
  4. Active Directory ACL Exporter (Paramount Defenses)
  5. Active Directory Effective Permissions Calculator (Paramount Defenses)
  6. Active Directory Effective Access Auditor (Paramount Defenses)
  7. Active Directory Permissions Analyzer (Paramount Defenses)
  8. Active Directory Permissions Reporting Tool (ManageEngine)
  9. Active Directory Privileged Access Auditor (Paramount Defenses)
  10. AD ACL Scanner (Robin Granberg ?)
  11. AD Permissions Reporter (CJWDev)
  12. BeyondTrust Auditor (BeyondTrust)
  13. Bloodhound (SpectreOps)
  14. Dsacls (Microsoft)
  15. Effective Permissions Reporting Tool (Netwrix)
  16. Enterprise Reporter for Active Directory (Quest)
  17. Hyena (Systemtools)
  18. LepideAuditor (Lepide)
  19. Permissions Analyzer for Active Directory (SolarWinds)
  20. PowerShell for Active Directory (Microsoft)
  21. Stealthaudit Active Directory Permissions Analyzer (Stealthbits)
  • Note: The mere mention of any 3rd party tool above is not and should not be considered an endorsement.

The only tools that you cannot currently (i.e. yet) have in your arsenal are those developed by Paramount Defenses.

You're welcome to use any other tools to fulfill the various challenges I'll be sharing soon. If your organization currently uses a particular tool, I recommend using it to see if it can help you get the answers to these upcoming challenges.




Your First Challenge

Your first challenge is a very simple challenge, and I expect each one of you to be able to easily fulfill this challenge.


Using any tool(s) of your choice that are in your Active Directory security arsenal, please analyze the security permissions in the Active Directory Security Lab VM that I have shared, and simply answer the following three simple questions -

  1. Exactly how many security permissions (ACEs) are there domain-wide in the corp.local domain?

  2. Exactly how many members does the Domain Admins security group have? 

  3. Exactly how many security permissions in the ACL protecting the the Domain Admins security group directly or indirectly impact "Write Property - Member" permissions ?

  • These are really simple warm-up questions. Your answer can be as simple as >   1) 100,000     2) 5     3) 4

The answer to question 1 helps determine how large the attack surface is. The answer to question 2 is (sadly) the (mere) extent to which many organizations go to to audit privileged access in Active Directory, and the answer to question 3 begins to scratch the surface when trying to determine who actually has what privileged access in an Active Directory.

You can answer these three simple questions below in a comment, or answer them in my LinkedIn post for today's lesson.




The Importance of Exactness

In Active Directory Security, exactness is very important. In fact, it is paramount because it only takes ONE compromised, malicious or coerced Active Directory privileged user to completely own, compromise and destroy the entire organization.

Here's proof - did you know that almost all major recent cyber security breaches, including JP Morgan, Target, Sony Hack, Snowden, the OPM Breach, Anthem, Avast, the United Nations and others all involved the compromise and misuse of just ONE Active Directory privileged user account.


Perhaps the best way to think of it is this - ask yourself if you would board a flight if I told you that the Metal Detector at the airport was not entirely accurate; you know, one that could do the job with about 75% accuracy (leaving a 25% chance that an explosive device or a firearm could make it past the security checkpoint and on to the plane you're going to be on.)

I know I wouldn't. Would you?   (If you care, don't accept approximate answers ; demand and expect exact answers.)




That's All for Today

Today's simple challenge is intended to lay the foundation for the next ten challenges, and the level of difficulty will only increase with each challenge, so I encourage everyone to accept and embrace this and all following challenges.

By the way, I decided to start simple because there are many folks who are tuned in, and for some of whom, even simple ACL analysis may be a first-time experience. So, to experts who may find these simple challenges simple, please wait for the next challenge, and no matter how advanced you are in Active Directory Security, you will have a worthy challenge :-)

That's it for today. I'll post Day-5 on July 04, and in it, I'll share the answers, including how I make these determinations, AND I'll share your next challenge, which clearly and directly impacts every organization's foundational cyber security today.

I look forward to your answers - answering these 3 questions shouldn't take more than 10 minutes.

Best wishes,
Sanjay.

Thursday, June 25, 2020

Day 3 - Active Directory Security (Privileged Access) Lab Virtual Machine


Folks,

Hello. I hope this finds you doing well. This post is Day-3 of Active Directory Security for Cyber Security Experts.


Today, I'm making available a special Active Directory Security lab virtual machine that everyone can download for free that we built to help organizations and experts worldwide learn advanced Active Directory Security and Privileged Access.



An
Active Directory Security Lab VM

Over the next thirty to sixty days, I'll be teaching the world how to correctly audit privileged access in Active Directory (AD), and to help everyone learn, follow and try it out for themselves, I had a special AD Security VM custom-built for everyone.


This is a free, instantly downloadable, custom-built VM running Windows Server 2019, complete with -
  1. Over 1000 security principals, including domain user accounts, computer accounts and security groups
  2. Over 3000 objects including GPOs, service connection points, print queues and managed service accounts
  3. Over 30 custom real-world administrative delegations provisioned across over 200 organizational units (OUs)
  4. Over 150,000 Active Directory security permissions spanning over 3000 Active Directory access control lists (ACLs)
  5. Custom permissions in the AdminSDHolder ACL as well as on the domain root object, governing Mimikatz DCSync



Active Directory Security Scenarios

Today organizations worldwide need to know how to adequately secure and defend their foundational Active Directory deployments from compromise, especially how to deal with specific advanced Active Directory Security scenarios.


This custom-built Active Directory Security lab VM contains specifically implemented examples of many such advanced Active Directory Security scenarios -
  1. How to correctly audit privileged access (the "Keys to the Kingdom") in Active Directory
  2. How to correctly assess, verify and lockdown privileged access in Active Directory
  3. How to attain and maintain Least Privileged Access (LPA) in Active Directory
  4. How to perform Privileged Account Discovery (PAD) in Active Directory
  5. How to correctly assess various Active Directory Security solutions

  6. How to uncover stealthy admins in Active Directory
  7. How to identify sneaky persistence in Active Directory
  8. How to prevent the spread of ransomware via Active Directory
  9. How to identify (1000s of) privilege escalation Paths in Active Directory
  10. How to eliminate serious risks posed by Bloodhound, Mimikatz DC Sync etc.

Over the next few days, I will walk through crystal-clear examples of each one of these scenarios in this lab VM and show how to identify these scenarios in this lab VM, helping everyone learn how to address these scenarios in real-world ADs.




Fulfilling Active Directory Focused Privileged 
Access Management (PAM) Audit Needs

Organizations worldwide also need to correctly fulfill Privileged Access Management (PAM) focused privileged access audit requirements involving Active Directory, so I'll also show you how to easily and correctly fulfill such requirements.


Specifically, for the benefit of IT, cyber security and compliance audit professionals, I'll share -
  1. How to correctly audit who has what privileged access in and across the entire Active Directory (i.e. domain-wide)
  2. How to correctly audit who has what privileged access on a specific Active Directory object (e.g. the CEO's/CFO's domain user account, the Domain Admins security group, the domain root, a specific OU, AdminSDHolder etc.) 

Today, unfortunately, most organizations and auditors do not know how to correctly do so, so this should be equally helpful.




Real-World Active Directory Contents

This AD Security lab VM contains a Windows Server 2019 powered, Active Directory forest, corp.local, for a fictional multi-national corporation headquartered in USA with worldwide operations across Americas, Europe, the Middle East and Asia.


It has an elaborate, real-world like organizational unit (OU) hierarchy that includes well over 200 OUs, across which realistic, custom administrative delegations have been provisioned for various IT security groups such as Help Desk.





Real-World Privileged Access / Administrative Delegations

This AD Security lab VM has also been custom-configured with over two dozen real-world administrative delegations that have been implemented to over two dozen domain security groups across this fictional domain, just like in the real world.


In particular, privileged/administrative access has been carefully delegated/provisioned in this Active Directory for domain user account (identity) management, security group (access) management, computer (host) management, group policy management etc. just like it is done at most organizations in the real-world, both directly, and via group nesting.

Administrative tasks that have been delegated include account creations (provisioning), object deletions, password resets, account expirations, group membership changes, access control (ACL) modifications, group policy (GPO) linking, etc. etc.





Download Point

This custom-built Active Directory Security is free for everyone to use, and it can be instantly downloaded from HERE.

Download


Its file size is 7,747,920,663 bytes (7.21 GB) and its MD-5 Hash is 80be4b771485303f069a63f8eb7b4c9e.


Step-by-step directions on how to download and get started with this VM in less than five minutes are provided below.





Getting Started

It takes less than five (5) minutes to get started, and here are step-by-step instructions on how to do so -

  1. Download this free Active Directory Security Virtual Machine from here.
  2. Download and install the free version of VMWare Workstation Player from here.
  3. Unzip the VM to extract the "AD Security" folder
  4. Create a "Virtual Machines" folder in "My Documents"
  5. Move the unzipped "AD Security" folder into the "Virtual Machines" folder

  6. Launch VM Workstation Player and select "Open a Virtual Machine"
  7. Point it to the "AD Security.vmx" file in the "My Documents\Virtual Machines\AD Security" folder
  8. Then select the "AD Security VM" and click the play button to start it.
  9. At the logon screen, login as "CORP\Administrator"  (The password is provided below.)
  10. Open a command-prompt, and enter "slmgr /rearm" to rearm the Windows license, then restart the VM.

That's it. Login as Administrator, then launch the "Start here" text file located on the desktop (in the VM) to become acquainted with the contents of this VM, subsequent to which you can launch ADUC to begin exploring AD contents.


  • Note: In step 8 above, you may (or may not) need to change the working directory for the VM. Should you need to do so, click on "Edit Virtual Machine Settings," then select the "Options" tab, and under "General" settings, locate the "Working Directory" text-box in the right-hand side, and modify it.


  • Please do NOT change any contents of this VM yet, especially any security permissions or domain security group memberships as I will be walking you through numerous specific examples, and if the permissions or group memberships have been changed, your results will not be the same.





Password

You will need the password for the Administrator account to login to this virtual machine.


The case-sensitive password for the Administrator account is:     ParamountDefenses!


If you're having problems logging in, feel
free to send me a message on LinkedIn.




Summary

Today, Active Directory is the foundation of IT, cyber security and privileged access at 85% of organizations worldwide.


Those who know how to correctly analyze privileged access inside Active Directory possess substantial power because almost everything in Active Directory Security ultimately boils down to privileged access on Active Directory objects.


Over the next month, I'll be helping millions of IT and Cyber Security professionals worldwide gain this valuable skill, and the remaining lessons over the next 30 to 60 days will all refer to examples in this custom-built AD Security lab VM.

This AD Security Lab VM was custom built to illustrate and demonstrate the scenarios mentioned above and should be very helpful for anyone who may have a desire to gain advanced Active Directory Security and Privileged Access skills.

Best wishes,
Sanjay.

Wednesday, June 17, 2020

Whiff - A Simple, Innocuous Ransomware Example

Folks,

As promised yesterday, today I wanted to share the first piece of innocuous ransomware example that I wrote last week.


Introducing Whiff

The first simple and innocuous illustrative ransomware I wrote is called "Whiff" and it can be downloaded from here.

whiff.exe

It was written to be able to programmatically encrypt or decrypt one specific file, and it uses the same password to do so.

This is NOT real ransomware; it is merely a very small piece of software intended to demonstrate how an actual piece of ransomware with similar capabilities could effortlessly and instantly encrypt and decrypt files on organizational computers.



Purpose

The sole purpose of this sample innocuous illustrative ransomware is to DEMONSTRATE just how quickly and effortlessly someone who could deploy similar ransomware using Active Directory (specifically via Group Policy) could cause files on thousands of machines in an organization to be instantly encrypted.


If you know how to deploy a logon script using Group Policy in Active Directory, then you should have no problem trying it out right away (; Script name: whiff.exe, Parameter: /E .) If you don't know how to deploy a logon script using Group Policy, you'll want to tune back next week, which is when I will provide step-by-step directions on how to do so.




Capabilities

Having been written to illustrate how someone could deploy ransomware using Active Directory, its sole capability is illustrative in nature, and it is specifically programmed to instantly ENCRYPT and DECRYPT a single specific file sample.txt in the location c:\temp.


For your convenience it can also automatically create (and delete) this sample file for you, via the /C (and /X) switch(es).


In case you're wondering why there isn't a "Ransom" payment notice displayed, its because there isn't any actual ransom involved. This is an illustrative piece of ransomware-like-software and you can easily decrypt the file using the /D flag.



Usage

whiff.exe provides four simple options -

  • /C   This option will automatically create a timestamped file c:\temp\sample.txt
  • /E   This option will automatically encrypt the c:\temp\sample.txt file
  • /D   This option will automatically decrypt the encrypted version of c:\temp\sample.txt
  • /X   This option will automatically delete the file c:\temp\sample.txt




How to Easily Deploy it Organization-wide using Active Directory

It takes less than one minute to deploy it organization-wide via Active Directory.


If you know how to deploy a logon script using Group Policy in Active Directory, you should have no problem trying it out right away. (Use script whiff.exe, paramter /E, and make sure that a c:\temp directory exists on domain-joined machines.)

If you don't know how to deploy a logon script using Group Policy, or are having difficulty figuring it out, simply check this blog next week as I will be sharing step-by-step instructions on how exactly to do so.




You Can Also Try It Right Away Without Active Directory

In addition to being able to deploy it via Active Directory, you can also instantly try it out on any Windows computer.


Here's how -
  1. Download whiff.exe from here onto any Windows computer.

  2. Create a folder named temp on C:\ on the same computer.
  3. Open a command-prompt, and navigate to the folder where you saved whiff.exe.
  4. Right-click on the whiff.exe file to check and verify its digital signature.
  5. Type whiff /C and click enter to have it automatically create sample.txt in the c:\temp folder.
  6. Navigate to the c:\temp folder, locate the sample.txt file, and open it to review its plaint-text, then close it.

  7. Next, type, whiff /E and click enter to have it instantly encrypt the file.
  8. Now, open c:\temp\sample.txt again ; it will be encrypted.
  9. To decrypt it, type whiff /D and click enter. Open the file to verify that it has been decrypted.
  10. Finally, should you wish to delete the sample.txt file, simply enter whiff /X.

You can also create your own sample.txt file. The /C option also adds a timestamp to the sample file it creates to help you verify that the program did in fact decrypt the same plain-text version that existed prior to your having encrypted the file.




An Innocuous Ransomware Sample

Ransomware poses a serious and real risk to organizations worldwide, and while organizations strive to employ various measures to protect themselves from being victimized, there are hardly any innocuous, trustworthy samples of illustrative ransomware-like-software available for organizations to try "what-if" scenarios and possibilities.

In that regard, whiff.exe is completely innocuous. It is purposefully intended to accomplish just one illustrative objective i.e. to encrypt and decrypt a single, specific trivial file, i.e. one named sample.txt that resides in the c:\temp folder.

It is also digitally signed to ensure its authenticity and integrity, and it thus provides a safe and trustworthy sample of an illustrative ransomware-like-software so organizations can easily and safely try out "what-if" scenarios and possibilities.


To reiterate, whiff.exe is specifically intended to help organizations see for themselves just how easily anyone who has sufficient access in Active Directory to be able to link a GPO to an(y) organizational unit (OU) or the domain root could potentially wreak havoc by using the power of Group Policy to very quickly deploy ransomware across thousands of machines in an organization.




Folder-wide Encryption

As I had indicated, I've written two such pieces of exemplary ransomware. Whiff is the first piece and by intention it can only encrypt (and decrypt) ONE file, which too is a specific temporary/trivial file.

That said, the second piece of exemplary ransomware that I wrote, and which I may share in days/weeks to come, can automatically encrypt thousands or even millions of files in any specifiable file-system folder.


In short, should it be required, we can also demonstrate (to any and every organization that wants to see so) just how easily actual similar ransomware could be deployed onto thousands of computers via Active Directory and result in the almost instantaneous encryption of entire hard-drives containing thousands of folders and millions of files.


For now though, Whiff should be enough to demonstrate this dire possibility, because to the wise, a "whiff" is enough.

Best,
Sanjay.


PS: Hey Google, define Whiff  for the world.

Monday, June 15, 2020

How Attackers Could Unleash Ransomware on Thousands of Computers in an Organization using Active Directory


Folks,

Hello. Today's post is on ransomware - specifically how a perpetrator could instantly unleash ransomware on thousands of organizational computers, in minutes using Active Directory, instantly encrypting vast amounts of an organization's data.



Ransomware (; needs no introduction.)

Today ransomware undoubtedly poses a clear and present cyber security danger to thousands of organizations worldwide.


Examples of ransomware include CryptoLocker, CryptoWall, WannaCry, Petya, NotPetya, Bad Rabbit, Sodinokibi etc. etc.

According to the New York Times, in 2019 alone, over 200,000 organizations had submitted files that had been hacked in a ransomware attack, and the average payment to release files was over $80,000. This amount doubled in December of 2019, and several organizations have faced ransom demands in the millions of dollars.

Of course, one the most famous and high-profile cases of ransomware involves the multi-billion $ Danish shipping giant Maersk, which fell victim to the Petya ransomware in 2018, and ended up incurring a staggering loss of US $ 250 Million.

Since then so many critical organizations including hospitals, police departments, city governments, law firms, automotive companies etc. etc. have been falling victim to ransomware and so many more are struggling to protect themselves.

For instance, just yesterday, the city of Knoxville became the latest American city to suffer a ransomware attack. Days ago, Honda announced that it had to halt operations due to a ransomware attack. Earlier this year, amongst numerous others, the Miami Beach Police Department suffered a ransomware attack, as did Parkview Medical Center in Colorado. Recently an FBI official said that "We certainly view it as one of the most serious cybercriminal problems we face right now."

In essence, today most do organizations understand the risk posed by ransomware and the need to protect themselves. However, what they may not know is that someone could unleash ransomware on thousands of computers in minutes.




How Much Damage Could Be Inflicted?

In a cyber attack involving an organization becoming a victim of ransomware, generally the extent of damage inflicted is a function of the amount of data that was encrypted (and possibly exfiltrated) and the value of that data to the organization.


That said, almost always, the extent of damage inflicted in a situation wherein ransomware is able to encrypt (/exfiltrate) data on (/from) thousands of computers would be exponentially more than that in a situation involving a few computers.

This begs a question - how easy is it for someone to unleash ransomware on thousands of organizational computers?



Well, lets take a look, shall we, and
the answer lies in what follows...



How Ransomware is Usually Unleashed

In most cases, the avenue for unleashing ransomware in an organization involves simple attack vectors such as phishing an employee, compromising an unpatched machine etc. and it usually begins with a SINGLE machine being victimized.


Subsequently, the mal payload attempts to compromise additional machines on the network, and the degree to which it is successful in spreading within an organization is usually a function of the number of vulnerable machines it can find/infect.

In short, barring the case wherein an Active Directory privileged user's account is compromised, traditional avenues used to unleash malware in an organization cannot usually easily infect THOUSANDS of an organization's computers.



Now, Consider THIS

Consider that an organization is situated in a single centrally air-conditioned building, and that the building's central air-conditioning unit is in a room at the top of the building. In such a scenario, air from the building's central air-conditioning unit has a clear, direct and uninterrupted channel into every room in the building.


Now, consider a situation wherein there is a dangerous virus that threatens humans and that can be spread if airborne.

In such a situation, if someone, such as a perpetrator, could get into the room that houses the central air-conditioning unit, he/she could easily unleash/spray the virus into the central air-conditioning unit, and within minutes of doing so, the virus would effortlessly have found its way into every room in the building, and instantly threaten every person in every room.



Instantly Unleashing Ransomware Using Active Directory

From the United States Government to the Fortune 100, at 85% of all business and government organizations worldwide, at the very foundation of these organizations' cyber security and IT lie their foundational Active Directory deployments.


There exists a direct secure channel between Active Directory and every computer in an organization that is joined to its Active Directory, and via a management feature called Group Policy, organizational IT personnel can easily and instantly control the security of every domain-joined machine, and that includes pushing out logon scripts onto these machines.


If someone, such as a perpetrator, could link a single malicious GPO (Group Policy Object) to an organizational unit (OU) or the domain root in an organization's foundational Active Directory, he/she could almost instantly and effortlessly deploy ransomware to thousands of organizational machines, thereby inflicting colossal damage in a matter of minutes.


In short, in the simple air-conditioned building scenario shared above, a room in the building represents a computer in the organization, and the central air-conditioning unit in the building represents the organization's foundational Active Directory.

All that someone needs to do is link the ransomware to a new/existing group policy and then link that group policy to an OU or domain, and he/she would basically have instantaneously and effortlessly unleashed ransomware onto thousands of organizational computers, because AD has a clear, direct and uninterrupted channel to every domain-joined computer.

In short, in just a few mouse clicks, anyone who had sufficient access in Active Directory to basically be able to link a GPO to an OU/domain, could effortlessly unleash ransomware across the entire organization, by (mis-)using Active Directory.

(This incidentally begs the question - "Do we know exactly who can link GPOs to OUs in our Active Directory today?!")



Sounds Theoretical ( ; Any Proof?)

Most IT and cyber security professionals would likely agree that in theory it sounds doable (because it isn't rocket science.)

At the same time, most of them, including most CISOs, will question whether there's any evidence at all of this simple yet highly potent attack vector in reality/practice. In other words, is this merely theory, or can someone show it in action today?


After all, there's no dearth of theoretical attack vectors in cyber security, so unless this is possible today, why worry :-) ?!




Time to Worry (; Here's Proof.)

I don't know whether or not there exists ransomware that has been shown to leverage Active Directory yet (IMO primarily because the bad guys aren't that smart/capable yet,) and I most definitely do not have the time to research it, BUT/AND...


...to PROVE that this is ABSOLUTELY possible today, last week, I sat down to code, and within a few hours, I had personally written production-level RANSOMWARE that can be easily deployed using Active Directory (via GPOs).


In fact, I wrote TWO of them, and I'll share the FIRST one with the world TOMORROW morning, right here on this blog.


NOW, before you jump to conclusions, let me clearly state that the sole purpose of doing so was to show the world that if I can personally create them in just a few hours, imagine what a professional/state-sponsored adversary/APT could create.


Make no mistake about it - each one of them is simple yet professional-grade*. The first one is very simple and solely for illustrative purposes ; once deployed, it will encrypt one specific file. The second one, which too is deployment-ready, once deployed, will encrypt (and with the right password, decrypt) entire directories on thousands of domain-joined computers.




* I'm not a script kiddie. I don't do .NET, PowerShell, VBScript etc. I write professional-grade code in C & Assembly.


As always, you do not need to take my word for it. Tomorrow, I'll share the link right here on this blog, and everyone will be able to freely download and instantly deploy it in any test/production Active Directory, and see it in action for themselves.




Summary

Ransomware clearly poses a serious cyber risk to thousands of organizations worldwide ; thus far it has been spread using traditional attack vectors, but/and since thousands of organizations operate on Active Directory, it is only a matter of time before perpetrators realize that they can leverage AD to easily unleash it on thousands of computers within organizations.

As an example, consider Mimikatz and Mimikatz DCSync. For years, it has been no secret that theoretically speaking, one could extract credentials from memory, and of course, replicate secrets from Active Directory, and that if materialized, these could be highly potent attack vectors, and sure enough, one day Benjamin Delpy made this trivial for everyone.

Thus, I felt the need to make organizations aware of this highly potent yet unmitigated attack vector as well, well before perpetrators weaponize it, and to demonstrate its feasibility, I've written two harmless pieces of illustrative ransomware.


In short, if you can click a few mouse buttons, you can now see for yourself how someone could leverage Active Directory to unleash ransomware on thousands of computers. It is no longer merely theoretical ; it is completely possible, today.

I'm also not about to wait for perpetrators to start misusing Active Directory to unleash ransomware and wreak havoc at organizations worldwide. In days to come, I'm going to teach and empower organizations to prevent this from happening.


Prevention is always better than cure/recovery, and as we have seen, timely preventive action can be extremely valuable.

Alright then (; until tomorrow.)

Thanks,
Sanjay


PS2: Pardon the delay in getting to Day 3 of Active Directory Security for Cyber Security Experts ; it'll be out on June 18.

Monday, May 25, 2020

In Remembrance, on Memorial Day 2020

Hello,

Today, our entire team would like take a few solemn moments to pay our deepest and highest respect to, and honor the lives of those who have made the ultimate sacrifice in the defense of our great nation, the United States of America.


On this solemn Memorial Day in 2020, we also take a few moments to recognize that in the last ninety (90) days alone, a modern adversary, that warranted swift, earnest and decisive action, has taken ninety thousand (90,000) American lives.


In 2020, in the last 2020 hours alone, America has lost more citizens than it has across all wars it has fought since WW-II.

On this solemn day, we remember all those Americans that made the ultimate sacrifice in the defense of our great nation, and all those Americans that we have lost this year alone to a dangerous adversary that we still have no defense against.


We hope and pray that the scientific community worldwide is able to apply its collective best to swiftly develop sufficient and adequate measures to empower mankind to contain and defeat this dangerous adversary that threatens all nations.

God bless the United States of America, and God equally bless the entire world, and all of mankind.

Respectfully,
Sanjay.

Tuesday, May 12, 2020

Day 2 - Red Teamers, can you hack THIS Active Directory ? (I Doubt It)

Folks,

Hello. I hope this finds you doing well. Welcome to Day-2 of "Active Directory Security for Cyber Security Experts."


Over the next 60 days, I'm going to be drawing upon two decades of experience in Active Directory Security to help thousands of organizations and millions of IT and cyber security personnel worldwide increase their knowledge.


Today, I'd like to pose a simple question / challenge to 1000s of Active Directory Red Teamers /Attackers worldwide -


Can YOU hack THIS Active Directory ?

(i.e. the one described below.)


(Before you arrive at any premature conclusions, please read the "What's the Point?" section that follows.)



An Active Directory Like Ours

Like most organizations worldwide, we (Paramount Defenses) too operate on Microsoft Active Directory, and most of our machines, including those on which reside our billion+ dollar cyber security algorithms, are joined to our Active Directory.

Unlike most organizations worldwide, we DO actually strive
to adequately protect our foundational Active Directory -

  1.  Domain Controller (DC) Security - All DCs are afforded the highest levels of system, network and physical security. I can't divulge details but know that let alone being able to logon to a DC, one couldn't even get physical access to them without multi-factor authN. The same level of security is afforded to all admin workstations and AD backups.

  2. Privileged Access in Active Directory - Privileged access for everything, including identity (user account) and access (group) management, computer and group policy management, access for AD-integrated apps etc. is all precisely and verifiably delegated/provisioned in Active Directory and locked-down based on the principle of least privilege.

  3.  Privileged Account Security - We don't have more than one active Domain Admin equivalent privileged user in Active Directory at any time, including across all default AD admin groups, and all such accounts (e.g. Enterprise Admin, Schema Admin etc.) that possess unrestricted admin access in Active Directory are disabled by default.

  4. Secure Administrative Practices - Every Domain Admin equivalent privileged account user is assigned a dedicated admin workstation exclusively for the purpose of performing activities that require Domain Admin level privileged access, and each such workstation is afforded the same level of security as are our DCs. Logging on to any other machine using Domain Admin credentials is strictly disallowed and could result in termination of employment.

  5. Service Accounts, esp. those require Domain-Admin Equivalent Access -  We only use managed service accounts across our network. Each one of them is AD managed, and has long (>25 character) passwords that are frequently rotated. We do not allow the use of any apps whose service accounts require Domain-Admin (DA) access, because if you understand Windows security, you know that almost nothing actually requires DA level access to accomplish. 

  6. Trustworthy Software - We do not deploy any 3rd-party software that we cannot impose the highest levels of trust in, especially Active Directory mgmt/security/auditing solutions. This is because so many popular AD management and auditing solutions available today are developed outside USA, and some prominent ones are developed in Russia. Also, use of any free* tools or scripts downloaded from the Internet could result in immediate termination.

  7. Empowerment and Accountability - Most importantly, because we understand just how paramount the security of our foundational Active Directory is to our company's security, we have a simple and clear chain of accountability, which is as follows:  CEO - CISO - Director, IT - Enterprise Admin. Finally, I personally ensure that our IT team has whatever it needs to secure our AD, and we only hire the most trustworthy and proficient personnel as AD Admins.

(By the way, none of this takes too much effort or cost to do so. All it really takes is an understanding of and respect for the role that Active Directory plays in our security, and the will to enact just enough simple measures to adequately protect it.)


Now, let me stop right there, for sharing that much is
enough to make a Trillion $ point, which follows.



So, What's the Point?

The point of sharing this with you was to help you understand that in such an environment, no matter how proficient an Active Directory Red Teamer or attacker you might be, you're likely not going to find success using popular credential-theft attack techniques such as Kerberoasting,  Mimikatz etc. or using Mimikatz DCSync, DCShadow, Bloodhound etc.


Perhaps I should elaborate and substantiate this -
  1. Kerberoasting - As you'll agree, given measure #5 above, Kerberoasting just isn't going to be technically possible.

  2. Silver Tickets and Golden Tickets - Given measure #1 above, you're not going to be able to logon to a single DC, so you're never going to be able to generate a Silver or a Golden ticket.

  3. Mimkatz (for password hash extraction and reuse) - Likewise, in light of measures #3, #4 and #6 above, you're not going to get an opportunity to logon to or compromise any computer on to which a single Domain Admin equivalent credential may have ever been entered/used, so you're not about to find success using credential theft techniques that involve extracting and replaying/using password hashes from memory.

  4. Mimikatz DCSync and Mimikatz DC Shadow - Given measure #2 above, we possess the ability to determine and control exactly who can replicate secrets from our Active Directory domain, and as a consequence, we can reduce that number down to virtually zero, leaving you no opportunity whatsoever to even have the sufficient effective permissions needed to run Mimikatz DCSync against our AD. Similarly, because we can determine and control exactly who can create NT-DSA objects in our Active Directory, Mimikatz DCShadow too won't be possible.

  5. Bloodhound - Given measure #2 above, you could run Bloodhound all you want, but you're not going to find a single privilege escalation path leading to anything, because WE found and eliminated ALL of them BEFORE you could.


NOW, in your defense, let me be the first to admit that ours isn't a typical Active Directory environment by any means. Most Active Directory deployments should be secured like so, but they're nowhere near so ; most of them are vastly vulnerable.

That said, I'll be the first to tell you that of the 7 simple Active Directory Security measures that we implement, TODAY, every organization in the world too can implement just about all these measures on their own, except MEASURE #2.

As to measure #2, unfortunately, there's just no way to implement it without having the capability to accurately determine this, and do so domain-wide; sadly, most organizations (likely including $T Microsoft) do not even seem to know that they require this essential capability, let alone having it, so they're very far away from being able to adequately secure their AD.




Now, Consider This

Consider an Active Directory environment in which all measures above, except #2, have been implemented. By the way, in their interest of their own security, all organizations should endeavor to attain at least this level of Active Directory Security.


In such an Active Directory environment, as shared above, what so many folks errantly refer to as common and prevalent "Active Directory attack techniques", i.e. Kerberoasting, Mimikatz, Golden Tickets etc. aren't going to get you anywhere.

In such environments, many may be inclined to think that there's not that much more left to try and attack/compromise.

Yet, if you think about it (, and now since you've heard of Bloodhound, you likely know that) there is still an OCEAN of opportunity left to go after (and for defenders to defend), and unlike credential-theft attack vectors, it actually involves "Active Directory Security."

  • Side-note: I had asked Delpy the same question back in 2016, likely even BEFORE Bloodhound was around.



Active Directory Security

As you'll hopefully agree, the most important and vital aspect of Active Directory security, is the security of its contents.


You know what I'm talking about. Every single one of the most powerful privileged user accounts and groups, the user accounts of all employees and executives, every single domain computer account (including those of DCs), every single domain security group used to protect most IT assets across the network, every single group policy used to secure and protect all domain-joined hosts etc. all have one thing in common - they constitute the very contents of Active Directory.

In essence, the most valuable assets of any organization operating on Active Directory are INSIDE their Active Directory.

Now, each one of these assets is represented as an Active Directory object, and protected by an access control list (ACL), within which reside numerous security permissions, each one of which allow or deny some form of access to some security principal, and together they collectively determine exactly who can do what on each one of these Active Directory objects.

In other words, there's a vast OCEAN of Active Directory security permissions in every organization's Active Directory.

Within this ocean lies a vast amount of privileged access, and sadly, because it is very difficult to accurately assess it, much of it is excessive (unauthorized), just waiting to be found and exploited, or found and eliminated (locked-down.)



Simply put, its a race, and whoever (i.e. the good or the bad guys) accurately identifies it first WINS (i.e. controls AD.)

  • Side-note: Incidentally, Bloodhound, a promising tool that so many Active Directory Red Teamers, attackers and perpetrators have come to like and use, is based on identifying privilege escalation paths in this very ocean of AD security permissions; its underlying theory can be found here. However, it barely scratches the surface, and sadly it is inaccurate because it makes the same classic mistake that 1000s of organizations have themselves been making for years - it too relies on determining "Who has what permissions in AD" which is virtually futile.

    Finally, as pointed above, even if it were accurate, implementing measure #2 above would render it useless.


In essence, if you could correctly analyze this vast ocean of Active Directory security permissions, you could instantly find thousands of privilege escalation paths leading to every object in Active Directory, from Domain Admin accounts to the CEO's account, and from the Domain Admins group to a group protecting high-value IT assets across the network.

From an organizational standpoint, you would then have the ability to lockdown all such identified, existent unauthorized privileged access and eliminate all such paths, securing your Active Directory. From an attacker's standpoint you would have identified thousands of easily exploitable privilege escalation paths leading to whatever you want to compromise.


The key to correctly analyzing this vast ocean of security permissions and privileged access in Active Directory, and thus the key to being able to identify who can do what, where and how, on any and every object in Active Directory lies in this, and in days to come, it is my intention to help everyone learn more about this vast ocean, and how to correctly analyze it.





Conclusion

Today's post was intended to convey that the attack methodologies that most Active Directory Red Teamers and Attackers use to attack Active Directory security, don't actually have much to do with Active Directory Security per se, and can be thwarted by implementing a few common sense measures (, which sadly most organizations have yet to implement.)

As a segue, the second point I wanted to make was that actual crux of and the innards of "Active Directory Security" reside inside the ocean of security permissions that exist in every organization's Active Directory, and in days to come, that's what I intend to help the world better understand, because collectively across the world, they secure Trillions of $ of real wealth.

To be continued on Day 3, May 18, 2020 (; will share VM then, and from which point on, it should be every alternate day.)

Best wishes,
Sanjay



PS: Regarding measure #2 above -

There's a little $1.4 Trillion company out there called Microsoft. They built Active Directory. You should ask them if they can help you do this accurately and adequately on even a single object in AD, let alone do so domain-wide. (They can't.)

(If you can't find them in the Security aisle, look for them in the Sales aisle; they've been quite busy pitching their Cloud offering to the world, and recently, offering free Teams meeting accounts during COVID-19 to increase their user-base.)

Then ask CrowdStrike, FireEye, Symantec, CyberArk, Tanium, Amazon, Google etc. if perhaps they can. (They too can't.)

Next, perhaps ask Quest, Centrify, BeyondTrust, Varonis, Netwrix, Preempt and other popular AD Security companies.

Finally, ask Gartner, those Magic Quadrant gurus, if they know of someone who could. (They may not have a clue.)

Paramount Defenses Logo

© 2006 - 2019 Paramount Defenses.
All Rights Reserved.

Your Privacy

We use cookies to give you the best online experience. Please let us know if you accept these cookies.