mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-15 01:17:36 +00:00
GitBook: [#3430] No subject
This commit is contained in:
CPol
gitbook-bot
parent
7b041cc7cc
commit
b7957a6a84
3 changed files with 159 additions and 21 deletions
|
|
@ -156,7 +156,8 @@
|
|||
* [Windows C Payloads](windows-hardening/windows-local-privilege-escalation/windows-c-payloads.md)
|
||||
* [Active Directory Methodology](windows-hardening/active-directory-methodology/README.md)
|
||||
* [Abusing Active Directory ACLs/ACEs](windows-hardening/active-directory-methodology/acl-persistence-abuse.md)
|
||||
* [AD Certificates](windows-hardening/active-directory-methodology/ad-certificates.md)
|
||||
* [AD Certificates](windows-hardening/active-directory-methodology/ad-certificates/README.md)
|
||||
* [Certificate Theft](windows-hardening/active-directory-methodology/ad-certificates/certificate-theft.md)
|
||||
* [AD information in printers](windows-hardening/active-directory-methodology/ad-information-in-printers.md)
|
||||
* [ASREPRoast](windows-hardening/active-directory-methodology/asreproast.md)
|
||||
* [BloodHound](windows-hardening/active-directory-methodology/bloodhound.md)
|
||||
|
|
|
|||
|
|
@ -16,14 +16,16 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
|
||||
</details>
|
||||
|
||||
## Parts of a certificate
|
||||
## Basic Information
|
||||
|
||||
### Parts of a certificate
|
||||
|
||||
* **Subject** - The owner of the certificate.
|
||||
* **Public Key** - Associates the Subject with a private key stored separately.
|
||||
* **NotBefore and NotAfter dates** - Define the duration that the certificate is valid.
|
||||
* **Serial Number** - An identifier for the certificate assigned by the CA.
|
||||
* **Issuer** - Identifies who issued the certificate (commonly a CA).
|
||||
* **SubjectAlternativeName** - Defines one or more alternate names that the Subject may go by.
|
||||
* **SubjectAlternativeName** - Defines one or more alternate names that the Subject may go by. (_Check below_)
|
||||
* **Basic Constraints** - Identifies if the certificate is a CA or an end entity, and if there are any constraints when using the certificate.
|
||||
* **Extended Key Usages (EKUs)** - Object identifiers (OIDs) that describe **how the certificate will be used**. Also known as Enhanced Key Usage in Microsoft parlance. Common EKU OIDs include:
|
||||
* Code Signing (OID 1.3.6.1.5.5.7.3.3) - The certificate is for signing executable code.
|
||||
|
|
@ -35,7 +37,13 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
|||
* **Signature Algorithm** - Specifies the algorithm used to sign the certificate.
|
||||
* **Signature** - The signature of the certificates body made using the issuer’s (e.g., a CA’s) private key.
|
||||
|
||||
## CAs
|
||||
#### Subject Alternative Names
|
||||
|
||||
A **Subject Alternative Name** (SAN) is an X.509v3 extension. It allows **additional identities** to be bound to a **certificate**. For example, if a web server hosts **content for multiple domains**, **each** applicable **domain** could be **included** in the **SAN** so that the web server only needs a single HTTPS certificate.
|
||||
|
||||
By default, during certificate-based authentication, one way AD maps certificates to user accounts based on a UPN specified in the SAN. If an attacker can **specify an arbitrary SAN** when requesting a certificate that has an **EKU enabling client authentication**, and the CA creates and signs a certificate using the attacker supplied SAN, the **attacker can become any user in the domain**.
|
||||
|
||||
### CAs
|
||||
|
||||
AD CS defines CA certificates the AD forest trusts in four locations under the container `CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>`, each differing by their purpose:
|
||||
|
||||
|
|
@ -53,9 +61,9 @@ In AD environments, **clients interact with Enterprise CAs to request a certific
|
|||
* The **NTAuthCertificates** AD object defines CA certificates that enable authentication to AD. This object has an **objectClass** of **`certificationAuthority`** and the object’s **`cACertificate`** property defines an array of **trusted CA certificates**. AD-joined Windows machines propagate these CAs to the Intermediate Certification Authorities certificate store on each machine. **Client** applications can **authenticate** to AD using a certificate only if one the **CAs defined by the NTAuthCertificates** object has **signed** the authenticating client’s certificate.
|
||||
* The **AIA** (Authority Information Access) container holds the AD objects of intermediate and cross CAs. **Intermediate CAs are “children” of root CAs** in the PKI tree hierarchy; as such, this container exists to aid in **validating certificate chains**. Like the Certification Authorities container, each **CA is represented as an AD object** in the AIA container where the objectClass attribute is set to certificationAuthority and the **`cACertificate`** property contains the **bytes** of the **CA’s certificate**. These CAs are propagated to the Intermediate Certification Authorities certificate store on each Windows machine.
|
||||
|
||||
## Client Certificate Request Flow
|
||||
### Client Certificate Request Flow
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image.png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It's the process to **obtain a certificate** from AD CS. At a high level, during enrolment clients first **find an Enterprise CA** based on the **objects in the Enrolment Services** container discussed above.
|
||||
|
||||
|
|
@ -64,7 +72,7 @@ It's the process to **obtain a certificate** from AD CS. At a high level, during
|
|||
3. The **CA** server checks if the client **can request certificates**. If so, it determines if it will issue a certificate by looking up the **certificate template** AD object specified in the CSR. The CA will check if the certificate template AD object’s **permissions allow** the authenticating account to **obtain a certificate**.
|
||||
4. If so, the **CA generates a certificate** using the “blueprint” settings defined by the **certificate template** (e.g., EKUs, cryptography settings, and issuance requirements) and using the other information supplied in the CSR if allowed by the certificate’s template settings. The **CA signs the certificate** using its private key and then returns it to the client.
|
||||
|
||||
## Certificate Templates
|
||||
### Certificate Templates
|
||||
|
||||
AD CS stores available certificate templates as AD objects with an **objectClass** of **`pKICertificateTemplate`** located in the following container: 
|
||||
|
||||
|
|
@ -74,7 +82,7 @@ An AD certificate template object’s attributes **define its settings, and its
|
|||
|
||||
The **`pKIExtendedKeyUsage`** attribute on an AD certificate template object contains an **array of OIDs** enabled in the template. These EKU OIDs affect **what the certificate can be used for.** You can find a [list of possible OIDs here](https://www.pkisolutions.com/object-identifiers-oid-in-pki/).
|
||||
|
||||
### Authentication OIDs
|
||||
#### Authentication OIDs
|
||||
|
||||
* `1.3.6.1.5.5.7.3.2`: Client Authentication
|
||||
* `1.3.6.1.5.2.3.4`: PKINIT Client Authentication (needed to be added manually)
|
||||
|
|
@ -87,7 +95,7 @@ The **`pKIExtendedKeyUsage`** attribute on an AD certificate template object con
|
|||
|
||||
An admin needs to **create the certificate** template and then an **Enterprise CA “publishes”** the template, making it available to clients to enrol in. AD CS specifies that a certificate template is enabled on an Enterprise CA by **adding the template’s name to the `certificatetemplates` field** of the AD object.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{% hint style="warning" %}
|
||||
AD CS defines enrolment rights - which **principals can request** a certificate – using two security descriptors: one on the **certificate template** AD object and another on the **Enterprise CA itself**.\
|
||||
|
|
@ -105,11 +113,11 @@ A client needs to be granted in both security descriptors in order to be able to
|
|||
|
||||
The **security descriptor** configured on the **Enterprise CA** defines these rights and is **viewable** in the Certificate Authority MMC snap-in `certsrv.msc` by right clicking on the CA → Properties → Security.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (7).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (7).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This ultimately ends up setting the Security registry value in the key **`HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<CA NAME>`** on the CA server. We have encountered several AD CS servers that grant low-privileged users remote access to this key via remote registry:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Low-privileged users can also **enumerate this via DCOM** using the `ICertAdminD2` COM interface’s `GetCASecurity` method. However, normal Windows clients need to install the Remote Server Administration Tools (RSAT) to use it since the COM interface and any COM objects that implement it are not present on Windows by default.
|
||||
|
||||
|
|
@ -121,7 +129,7 @@ Other requirements could be in place to control who can get a certificate.
|
|||
|
||||
**CA certificate manager approval** results in the certificate template setting the `CT_FLAG_PEND_ALL_REQUESTS` (0x2) bit on the AD object’s `msPKI-EnrollmentFlag` attribute. This puts all **certificate requests** based on the template into the **pending state** (visible in the “Pending Requests” section in `certsrv.msc`), which requires a certificate manager to **approve or deny** the request before the certificate is issued:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (13).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (13).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
#### Enrolment Agents, Authorized Signatures, and Application Policies
|
||||
|
||||
|
|
@ -147,12 +155,6 @@ On a Windows machine, users can request certificates using a GUI by launching `c
|
|||
|
||||
One can also use the built-in **`certreq.exe`** command or PowerShell’s **`Get-Certificate`** command for certificate enrolment.
|
||||
|
||||
## Subject Alternative Names
|
||||
|
||||
A **Subject Alternative Name** (SAN) is an X.509v3 extension. It allows **additional identities** to be bound to a **certificate**. For example, if a web server hosts **content for multiple domains**, **each** applicable **domain** could be **included** in the **SAN** so that the web server only needs a single HTTPS certificate.
|
||||
|
||||
By default, during certificate-based authentication, one way AD maps certificates to user accounts based on a UPN specified in the SAN. If an attacker can **specify an arbitrary SAN** when requesting a certificate that has an **EKU enabling client authentication**, and the CA creates and signs a certificate using the attacker supplied SAN, the **attacker can become any user in the domain**.
|
||||
|
||||
## Certificate Authentication
|
||||
|
||||
AD supports certificate authentication over **two protocols** by default: **Kerberos** and **Secure Channel** (Schannel).
|
||||
|
|
@ -173,7 +175,7 @@ The “NTAUTH certificate store” mentioned here refers to an AD object AD CS i
|
|||
|
||||
This means that when **AD CS creates a new CA** (or it renews CA certificates), it publishes the new certificate to the **`NTAuthCertificates`** object by adding the new certificate to the object’s `cacertificate` attribute:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (9).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (9).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
During certificate authentication, the DC can then verify that the authenticating certificate chains to a CA certificate defined by the **`NTAuthCertificates`** object. CA certificates in the **`NTAuthCertificates`** object must in turn chain to a root CA. The big takeaway here is the **`NTAuthCertificates`** object is the root of trust for certificate authentication in Active Directory!
|
||||
|
||||
|
|
@ -182,13 +184,13 @@ During certificate authentication, the DC can then verify that the authenticatin
|
|||
Schannel is the security support provider (SSP) Windows leverages when establishing TLS/SSL connections. Schannel supports **client authentication** (amongst many other capabilities), enabling a remote server to **verify the identity of the connecting user**. It accomplishes this using PKI, with certificates being the primary credential.\
|
||||
During the **TLS handshake**, the server **requests a certificate from the client** for authentication. The client, having previously been issued a client authentication certificate from a CA the server trusts, sends its certificate to the server. The **server then validates** the certificate is correct and grants the user access assuming everything is okay.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
When an account authenticates to AD using a certificate, the DC needs to somehow map the certificate credential to an AD account. **Schannel** first attempts to **map** the **credential** to a **user** account use Kerberos’s **S4U2Self** functionality. \
|
||||
If that is **unsuccessful**, it will follow the attempt to map the **certificate to a user** account using the certificate’s **SAN extension**, a combination of the **subject** and **issuer** fields, or solely from the issuer. By default, not many protocols in AD environments support AD authentication via Schannel out of the box. WinRM, RDP, and IIS all support client authentication using Schannel, but it **requires additional configuration**, and in some cases – like WinRM – does not integrate with Active Directory.\
|
||||
One protocol that does commonly work – assuming AD CS has been setup - is **LDAPS**. The cmdlet `Get-LdapCurrentUser` demonstrates how one can authenticate to LDAP using .NET libraries. The cmdlet performs an LDAP “Who am I?” extended operation to display the currently authenticating user:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (2).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## AD CS Enumeration
|
||||
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
# Certificate Theft
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Support HackTricks and get benefits!</strong></summary>
|
||||
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
|
||||
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
|
||||
Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
|
||||
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
|
||||
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
|
||||
|
||||
</details>
|
||||
|
||||
## What can I do with a certificate
|
||||
|
||||
Before checking how to steal the certificates here you have some info about how to find what the certificate is useful for:
|
||||
|
||||
```powershell
|
||||
# Powershell
|
||||
$CertPath = "C:\path\to\cert.pfx"
|
||||
$CertPass = "P@ssw0rd"
|
||||
$Cert = New-Object
|
||||
System.Security.Cryptography.X509Certificates.X509Certificate2 @($CertPath, $CertPass)
|
||||
$Cert.EnhancedKeyUsageList
|
||||
|
||||
# cmd
|
||||
certutil.exe -dump -v cert.pfx
|
||||
```
|
||||
|
||||
## Exporting Certificates Using the Crypto APIs – THEFT1
|
||||
|
||||
The easiest way to extract a user or machine certificate and private key is through an **interactive desktop session**. If the **private key** is **exportable**, one can simply right click the certificate in `certmgr.msc`, and go to `All Tasks → Export`… to export a password protected .pfx file. \
|
||||
One can accomplish this **programmatically** as well. Examples include PowerShell’s `ExportPfxCertificate` cmdlet or [TheWover’s CertStealer C# project](https://github.com/TheWover/CertStealer).
|
||||
|
||||
Underneath, these methods use the **Microsoft CryptoAPI** (CAPI) or more modern Cryptography API: Next Generation (CNG) to interact with the certificate store. These APIs perform various cryptographic services that needed for certificate storage and authentication (amongst other uses).
|
||||
|
||||
If the private key is non-exportable, CAPI and CNG will not allow extraction of non-exportable certificates. **Mimikatz’s** `crypto::capi` and `crypto::cng` commands can patch the CAPI and CNG to **allow exportation** of private keys. `crypto::capi` **patches** **CAPI** in the current process whereas `crypto::cng` requires **patching** **lsass.exe’s** memory.
|
||||
|
||||
## User Certificate Theft via DPAPI – THEFT2
|
||||
|
||||
More info about DPAPI in:
|
||||
|
||||
{% content-ref url="../../windows-local-privilege-escalation/dpapi-extracting-passwords.md" %}
|
||||
[dpapi-extracting-passwords.md](../../windows-local-privilege-escalation/dpapi-extracting-passwords.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
Windows **stores certificate private keys using DPAPI**. Microsoft breaks out the storage locations for user and machine private keys. When manually decrypting the encrypted DPAPI blobs, a developer needs to understand which cryptography API the OS used as the private key file structure differs between the two APIs. When using SharpDPAPI, it automatically accounts for these file format differences. 
|
||||
|
||||
Windows most **commonly stores user certificates** in the registry in the key `HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates`, though some personal certificates for users are **also** stored in `%APPDATA%\Microsoft\SystemCertificates\My\Certificates`. The associated user **private key locations** are primarily at `%APPDATA%\Microsoft\Crypto\RSA\User SID\` for **CAPI** keys and `%APPDATA%\Microsoft\Crypto\Keys\` for **CNG** keys.
|
||||
|
||||
To obtain a certificate and its associated private key, one needs to:
|
||||
|
||||
1. Identify w**hich certificate one wants to steal** from the user’s certificate store and extract the key store name.
|
||||
2. Find the **DPAPI masterkey** needed to decrypt the associated private key.
|
||||
3. Obtain the plaintext DPAPI masterkey and use it to **decrypt the private key**.
|
||||
|
||||
To **get the plaintext DPAPI masterkey**:
|
||||
|
||||
```bash
|
||||
# With mimikatz
|
||||
## Running in a process in the users context
|
||||
dpapi::masterkey /in:"C:\PATH\TO\KEY" /rpc
|
||||
|
||||
# with mimikatz
|
||||
## knowing the users password
|
||||
dpapi::masterkey /in:"C:\PATH\TO\KEY" /sid:accountSid /password:PASS
|
||||
```
|
||||
|
||||
To simplify masterkey file and private key file decryption, [**SharpDPAPI’s**](https://github.com/GhostPack/SharpDPAPI) `certificates` command can be used with the `/pvk`, `/mkfile`, `/password`, or `{GUID}:KEY` arguments to decrypt the private keys and associated certificates, outputting a `.pem` text file.
|
||||
|
||||
```bash
|
||||
SharpDPAPI.exe certificates /mkfile:C:\temp\mkeys.txt
|
||||
|
||||
# Transfor .pem to .pfx
|
||||
openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
|
||||
```
|
||||
|
||||
## Machine Certificate Theft via DPAPI – THEFT3
|
||||
|
||||
Windows stores machine certificates in the registry key `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates` and stores private keys in several different places depending on the account.\
|
||||
Although SharpDPAPI will search all these locations, the most interesting results tend to come from `%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys` (CAPI) and `%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\Keys` (CNG). These **private keys** are associated with the **machine certificate** store and Windows encrypts them with the **machine’s DPAPI master keys**.\
|
||||
One cannot decrypt these keys using the domain’s DPAPI backup key, but rather **must** use the **DPAPI\_SYSTEM LSA secret** on the system which is **accessible only by the SYSTEM user**. 
|
||||
|
||||
You can do this manually with **Mimikatz’** **`lsadump::secrets`** command and then use the extracted key to **decrypt machine masterkeys**. \
|
||||
You can also patch CAPI/CNG as before and use **Mimikatz’** `crypto::certificates /export /systemstore:LOCAL_MACHINE` command. \
|
||||
**SharpDPAPI’s** certificates command with the **`/machine`** flag (while elevated) will automatically **elevate** to **SYSTEM**, **dump** the **DPAPI\_SYSTEM** LSA secret, use this to **decrypt** and found machine DPAPI masterkeys, and use the key plaintexts as a lookup table to decrypt any machine certificate private keys.
|
||||
|
||||
## Finding Certificate Files – THEFT4
|
||||
|
||||
Sometimes **certificates are just in the filesystem**, like in file shares or in the Downloads folder.\
|
||||
The most common type of Windows-focused certificate files we have seen are **`.pfx`** and **`.p12`** files, with **`.pkcs12`** and ** `.pem` ** sometimes showing up but less often.\
|
||||
Other interesting certificate-related file extensions are: **`.key`** (_private key_), **`.crt/.cer`** (_just cert_), **`.csr`** (_Certificate Signing Request, it doesn't contain certs of priv keys_), **`.jks/.keystore/.keys`** (_Java Keystore. May contain certs + private keys used by Java applications_).
|
||||
|
||||
To find this files, just search for those extensions using powershell or the cmd.
|
||||
|
||||
If you find a **PKCS#12** certificate file and it is **password protected**, you can extract a hash using [pfx2john.py](https://fossies.org/dox/john-1.9.0-jumbo-1/pfx2john\_8py\_source.html) **crack** it using JohnTheRipper.
|
||||
|
||||
## NTLM Credential Theft via PKINIT – THEFT5
|
||||
|
||||
> In order to **support NTLM authentication** \[MS-NLMP] for applications connecting to network services that **do not support Kerberos** authentication, when PKCA is used, the KDC returns the **user’s NTLM** one-way function (OWF) in the privilege attribute certificate (PAC) **`PAC_CREDENTIAL_INFO`** buffer
|
||||
|
||||
So, if account authenticates and gets a **TGT through PKINIT**, there is a built-in “failsafe” that allows the current host to **obtain our NTLM hash from the TGT** to support legacy authentication. This involves **decrypting** a **`PAC_CREDENTIAL_DATA`** **structure** that is a Network Data Representation (NDR) serialized representation of the NTLM plaintext.
|
||||
|
||||
****[**Kekeo**](https://github.com/gentilkiwi/kekeo) can be used to ask for a TGT with this information an retrieve the users NTML
|
||||
|
||||
```bash
|
||||
tgt::pac /caname:thename-DC-CA /subject:harmj0y /castore:current_user /domain:domain.local
|
||||
```
|
||||
|
||||
Kekeo’s implementation will also work with smartcard-protected certs that are currently plugged in if you can [**recover the pin**](https://github.com/CCob/PinSwipe)**.** It will also be supported in [**Rubeus**](https://github.com/GhostPack/Rubeus).
|
||||
|
||||
## References
|
||||
|
||||
* All the info was taken from [https://www.specterops.io/assets/resources/Certified\_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified\_Pre-Owned.pdf)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Support HackTricks and get benefits!</strong></summary>
|
||||
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
|
||||
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
|
||||
Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
|
||||
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
|
||||
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
|
||||
|
||||
</details>
|
||||
Loading…
Reference in a new issue