Typo fixes & grammar updates

docs/library/windows/active_directory_replication.md

@@ -20,9 +20,9 @@ More information about the control access rights can be found [here](https://doc
 
 The DC-to-DC interaction for replication and management of data in Active Directory is performed via the Directory Replication Service (DRS) Remote Protocol. If A DC wants to connect to a DC in a particular domain, the DC constructs a service principal name (SPN) specifying the fixed DRS RPC interface GUID "E3514235-4B06-11D1-AB04-00C04FC2DCD2". The format of the SPN constructed by the DC is the following:
 
-[<DRS interface GUID>/<DSA GUID>/<DNS domain name>](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/41efc56e-0007-4e88-bafe-d7af61efd91f)
+[\<DRS interface GUID>/\<DSA GUID>/\<DNS domain name>](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/41efc56e-0007-4e88-bafe-d7af61efd91f)
 
-[<DRS interface GUID>](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/41efc56e-0007-4e88-bafe-d7af61efd91f) is the fixed Directory Replication Service (DRS) RPC interface GUID, which, as mentioned before, has the well-known value of "E3514235-4B06-11D1-AB04-00C04FC2DCD2".
+[\<DRS interface GUID>](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/41efc56e-0007-4e88-bafe-d7af61efd91f) is the fixed Directory Replication Service (DRS) RPC interface GUID, which, as mentioned before, has the well-known value of "E3514235-4B06-11D1-AB04-00C04FC2DCD2".
 
 ## Directory Replication Services Auditing
 
@@ -37,8 +37,8 @@ Events generated by the replication activity on the targeted DC are available an
 
 ## Extra Notes:
 
-* Remember that adversaries willing to perform a DCSync or activer directory replication attack, could also use any domain account to perform the task, despite being in no privileged groups, having no malicious sidHistory, and not having local admin rights on the domain controller itself.
-* An adversary will just need to add the three ad replication access rights shown in the table above to the unprivileged account to create a DCSync user backdoor.
+* Remember that adversaries willing to perform a DCSync or Active Directory replication attack can also use any domain account to perform the task despite being in no privileged groups, having no malicious sidHistory, and not having local admin rights on a domain controller.
+* An adversary only needs to add the three ad replication access rights shown in the table above to an unprivileged account to create a DCSync user backdoor.
 
 ## References
 

docs/library/windows/adfs_dkm_keys.md

@@ -20,7 +20,7 @@ Distributed Key Manager (DKM) is a client-side functionality that uses a set of
 ## ADFS DKM Master Key
 
 * The ADFS DKM master key(s) are stored in Active Directory (AD).
-* An examplle of an ADFS DKM Container in AD would be `CN=ADFS,CN=Microsoft,CN=Program Data,DC=azsentinel,DC=local`
+* An example of an ADFS DKM Container in AD would be `CN=ADFS,CN=Microsoft,CN=Program Data,DC=azsentinel,DC=local`
 * Inside of the AD container there are groups and inside of one of them there is an AD contact object that contains the DKM key used to decrypt AD FS certificates.
 * The DKM key is stored in the `thumbnailPhoto` attribute of the AD contact object.
 * One could read the DKM key as a byte array and convert it to a usable string from AD by running the following command:
@@ -103,4 +103,4 @@ Set-AuditRule -AdObjectPath 'AD:\CN=<Contact Object>,CN=<DKM Container>,CN=ADFS,
 * https://github.com/fireeye/ADFSDump/tree/master/ADFSDump
 * https://www.powershellgallery.com/packages/AADInternals/0.2.5/Content/ADFS_utils.ps1
 * https://www.powershellgallery.com/packages/AADInternals/0.2.3/Content/Export-ADFSSigninCertificate.ps1
-* https://msresource.wordpress.com/2016/05/04/the-use-of-distributed-key-manager-dkm-in-active-directory-federation-services-ad-fs/
+* https://msresource.wordpress.com/2016/05/04/the-use-of-distributed-key-manager-dkm-in-active-directory-federation-services-ad-fs/

docs/library/windows/data_protection_api.md

@@ -1,10 +1,10 @@
 # Data Protection API
 
-Starting with Microsoft® Windows® 2000, the operating system began to provide a data protection application-programming interface (API). This Data Protection API (DPAPI) is a pair of function calls  `(CryptProtectData / CryptUnprotectData)` that provide operating system-level data protection services to user and system processes. By operating system-level, we mean a service that is provided by the operating system itself and does not require any additional libraries. By data protection, we mean a service that provides confidentiality of data by using encryption. Because data protection is part of the operating system, every application can now secure data without needing any specific cryptographic code other than the necessary function calls to DPAPI. 
+Starting with Microsoft® Windows® 2000, the operating system began to provide a data protection application-programming interface (API). This Data Protection API (DPAPI) is a pair of function calls  `(CryptProtectData / CryptUnprotectData)` that provide operating system-level data protection services to user and system processes. By operating system-level, we mean a service that is provided by the operating system itself and does not require any additional libraries. By data protection, we mean a service that provides confidentiality of data by using encryption. Since data protection is part of the operating system, every application can now secure data without needing any specific cryptographic code other than the necessary function calls to DPAPI. 
 
 ## Password Based Data Protection Service
 
-DPAPI is a password-based data protection service. It requires a password to provide protection. The drawback, of course, is that all protection provided by DPAPI rests on the password provided. Because DPAPI is focused on providing protection for users and requires a password to provide this protection, it logically uses the user's logon password for protection. Because DPAPI requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. A small drawback to using the logon password is that all applications running under the same user can access any protected data that they know about.
+DPAPI is a password-based data protection service. It requires a password to provide protection. The drawback, of course, is that all protection provided by DPAPI rests on the password provided. Because DPAPI is focused on providing protection for users and requires a password to provide this protection, it logically uses the user's logon password for protection. Since DPAPI requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. A small drawback to using the logon password is that all applications running under the same user can access any protected data that they know about.
 
 DPAPI initially generates a strong key called a MasterKey, which is protected by the user's password. DPAPI uses a standard cryptographic process called Password-Based Key Derivation to generate a key from the password. This password-derived key is then used with Triple-DES to encrypt the MasterKey, which is finally stored in the user's profile directory.
 

docs/library/windows/logon_session.md

@@ -1,8 +1,8 @@
 # Logon Session
 
-According to Microsoft documentation, A logon session is a computing session that begins when a user authentication is successful and ends when the user logs off of the system.
+According to Microsoft documentation, a logon session is a computing session that begins when a user authentication is successful and ends when the user logs off of the system.
 
-When a user is successfully authenticated, the authentication package creates a logon session and returns information to the Local Security Authority (LSA) that is used to create a token for the new user. This token includes, among other things, a locally unique identifier (LUID) for the logon session, called the logon Id.
+When a user is successfully authenticated, the authentication package creates a logon session and returns information to the Local Security Authority (LSA) that is used to create a token for the new user. This token includes, among other things, a locally unique identifier (LUID) for the logon session, called the logon_id.
 
 From a security event perspective the logon_id is first seen when a successful authentication event occurs.
 Based on the documentation provided by Microsoft and OSSEM, events from the Audit Logon subcategory are related to the creation of logon sessions and occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For a network logon, such as accessing a share, events are generated on the computer that hosts the resource that was accessed.

docs/library/windows/lsa_policy_objects.md

@@ -23,7 +23,7 @@ The Account object is used to assign privileges, system access, and special quot
 
 ### Private Data Object
 
-A limited number of private data objects are available on each system for the purpose of storing information in a protected, encrypted, fashion.
+A limited number of private data objects are available on each system for the purpose of protecting and encrypting information.
 
 Private data objects are provided primarily to support storage of server account passwords. This is useful for servers that run in a specific account. The password of the server account is private data that should be secured but is needed to log the server on.
 

docs/library/windows/process_access_rights.md

@@ -6,7 +6,7 @@
 
 ## Details
 
-The Microsoft Windows security model enables you to control access to process objects. When a user logs in, the system collects a set of data that uniquely identifies the user during the authentication process, and stores it in an access token. This access token describes the security context of all processes associated with the user. The security context of a process is the set of credentials given to the process or the user account that created the process.You can use a token to specify the current security context for a process using the CreateProcessWithTokenW function. You can specify a security descriptor for a process when you call the CreateProcess, CreateProcessAsUser, or CreateProcessWithLogonW function. If you specify NULL, the process gets a default security descriptor. The ACLs in the default security descriptor for a process come from the primary or impersonation token of the creator.To retrieve a process's security descriptor, call the GetSecurityInfo function. To change a process's security descriptor, call the SetSecurityInfo function.The valid access rights for process objects include the standard access rights and some process-specific access rights.
+The Microsoft Windows security model enables you to control access to process objects. When a user logs in, the system collects a set of data that uniquely identifies the user during the authentication process, and stores it in an access token. This access token describes the security context of all processes associated with the user. The security context of a process is the set of credentials given to the process or the user account that created the process.You can use a token to specify the current security context for a process using the CreateProcessWithTokenW function. You can specify a security descriptor for a process when you call the CreateProcess, CreateProcessAsUser, or CreateProcessWithLogonW function. If you specify NULL, the process gets a default security descriptor. The ACLs in the default security descriptor for a process come from the primary or impersonation token of the creator. To retrieve a process's security descriptor, call the GetSecurityInfo function. To change a process's security descriptor, call the SetSecurityInfo function. The valid access rights for process objects include the standard access rights and some process-specific access rights.
 
 | Value | Meaning |
 |---------|---------|

docs/library/windows/security_account_manager_database.md

@@ -1,6 +1,6 @@
 # Security Account Manager (SAM) Database
 
-Every computer that runs Windows has its own local domain; that is, it has an account database for accounts that are specific to that computer. Conceptually, this is an account database like any other with accounts, groups, SIDs, and so on. These are referred to as local accounts, local groups, and so on. Because computers typically do not trust each other for account information, these identities stay local to the computer on which they were created.
+Every computer that runs Windows has its own local domain; that is, it has an account database for accounts that are specific to that computer. Conceptually, this is an account database like any other with accounts, groups, SIDs, and so on. These are referred to as local accounts, local groups, and so on. Since computers typically do not trust each other for account information, these identities stay local to the computer on which they were created.
 
 The Security Account Manager (SAM) is a database that is present on computers running Windows operating systems that stores user accounts and security descriptors for users on the local computer.
 

docs/library/windows/security_account_manager_protocol.md

@@ -1,12 +1,12 @@
 # Security Account Manager Remote Protocol (SAMRP)
 
-Accounts are always created relative to an issuing authority. In Windows, the issuing authority is referred to as a domain. A domain can be either a local domain or extend across a network. Domains store information about their accounts in an account database. Windows uses Active Directory as the account database in domain-based environments, whereas in environments that are not domain-based, it uses the security account manager (SAM) built-in database as the account database.
+Accounts are always created relative to an issuing authority. In Windows, the issuing authority is referred to as a domain. A domain can be either a local domain or extend across a network. Domains store information about their accounts in an account database. Windows uses Active Directory as the account database in domain-based environments. In environments that are not domain-based, it uses the security account manager (SAM) built-in database as the account database.
 
 ## Security Account Manager Remote Protocol (SAMRP) Client-To-Server (C)
 
 The Security Account Manager (SAM) Remote Protocol (Client-to-Server) depends on the RPC protocol (uses RPC as a transport), and provides management functionality for an account store or directory containing users and groups. The goal of this protocol is to enable IT administrators and end users to manage users, groups, and computers. This protocol achieves its goal by enabling the creation, reading, updating, and deleting of security principal information. These security principals could be in any account store. Windows implements this protocol, for example, in a directory service (Active Directory) and in a computer-local security account database known as the Security Account Manager (SAM) database.
 
-This protocol follows two perspectives when understanding and implementing this protocol:
+This protocol follows two perspectives when understanding and implementing this protocol: object-based and method based.
 
 ## Object-based perspective