During our internal penetration tests, we regularly compromise Active Directory without using any passwords. This is possible thanks to an iconic attack: Pass-the-Hash (PtH).
This technique allows an attacker to authenticate on a Windows system by directly reusing a user’s password hash, rather than the password itself.
Social engineering, especially phishing in all its forms (emails, text messages, phone calls, QR codes, etc.), remains one of the main attack vectors.
In many attack scenarios, social engineering is a preferred lever for gaining initial access: moving from the position of an external attacker to that of an attacker with a foothold within an organisation’s IT system.
Active Directory (AD) is a directory service developed by Microsoft.
It is used by most companies to manage identities, user accounts, machines, security policies, and access rights to resources and services.
After presenting the operating principles of Active Directory Certificate Services (AD CS) in a previous article, it is now time to address a more offensive dimension: exploiting vulnerabilities related to this infrastructure.
In 2021, the SpecterOps team published a series of attack scenarios grouped under the name ESC (Enterprise Subordinate CA abuses) techniques.
According to the RFC 2616 standard, the ‘Host’ header is mandatory in an HTTP request. It indicates the host and, if applicable, the port of the requested resource, as in a URL.
In practical terms, this header allows the server to correctly redirect the request to the right site, particularly when several domain names share the same IP address. The value of the Host header generally corresponds to the domain name in the URL.
Pentesting a GCP (Google Cloud Platform) infrastructure and the web applications deployed on it is a key step in identifying vulnerabilities and strengthening resilience against attacks.
This article presents the methodology adopted during a GCP infrastructure penetration test, the main types of tests performed, and some concrete examples.
A simple line break seems harmless when thinking about a web application. However, if poorly managed, it can open the door to serious attacks.
This is precisely the case with CRLF injections, an often underestimated vulnerability that involves inserting end-of-line control characters into requests or responses.
Deserialisation vulnerabilities are often difficult to exploit. In most cases, you need access to the source code to identify the available classes or libraries used. This allows you to choose a suitable gadget chain or build a new one.
However, access to the source code is not always possible. It generally requires high privileges or the prior exploitation of another vulnerability.
As part of our internal penetration tests, we regularly encounter AD CS (Active Directory Certificate Services) infrastructures deployed on corporate networks.
This component always catches our attention, as inadequate configuration can quickly pave the way for total compromise of the Active Directory domain.
In the development cycle of a web application, security should never be relegated to the background.
It must be considered at every stage: from the design phase, when choosing the architecture, throughout development, but also after deployment, through continuous testing.
