Many modern websites employ an automatic issuance and renewal of TLS certificates. For enterprises, there are DigiCert services. For everyone else, there are free services such as Let’s Encrypt and ZeroSSL.
There is a flaw in a way that deployment of TLS certificates might be set up. It allows anyone to discover all domain names used by the same server. Sometimes, even when there is no HTTPS there!
In this article, I describe a new technique for discovering domain names. Afterward, I show how to use it in threat intelligence, penetration testing, and bug bounty.
From time to time in certain situations one needs to have a possibility to view a customer’s user screen to make some proofed screenshots or to get access to an open GUI application window which contains secrets for lateral movement while the legitimate user is connected via RDP and you don’t want to kick them out of the session.
There is a number of third-party software such as VNC, radmin, TeamViewer, etc. on the market to achieve it, but it involves additional actions such as binary delivery, its installation and so on. Moreover, these actions are too noisy and leave a lot of garbage on a remote host.
Luckily, Windows-based systems have an awesome built-in feature (as part of Remote Desktop Protocol) that is unfairly ignored or forgotten. It is called Remote Desktop Services Shadowing.
Service principal names (SPNs) are records in an Active Directory (AD) database that show which services are registered to which accounts:
If an account has an SPN or multiple SPNs, you can request a service ticket to one of these SPNs via Kerberos, and since a part of the service ticket will be encrypted with the key derived from the account’s password, you will be able to brute force this password offline. This is how Kerberoasting works.
There is a way to perform the Kerberoasting attack without knowing SPNs of the target services. I’ll show how it could be done, how it works, and when it could be useful.
During external penetration testing, I often see MS Exchange on the perimeter:
Exchange is basically a mail server that supports a bunch of Microsoft protocols. It’s usually located on subdomains named autodiscover, mx, owa or mail, and it can also be detected by existing /owa/, /ews/, /ecp/, /oab/, /autodiscover/, /Microsoft-Server-ActiveSync/, /rpc/, /powershell/ endpoints on the web server.
The knowledge about how to attack Exchange is crucial for every penetration testing team. If you found yourself choosing between a non-used website on a shared hosting and a MS Exchange, only the latter could guide you inside.
In this article, I’ll cover all the available techniques for attacking MS Exchange web interfaces and introduce a new technique and a new tool to connect to MS Exchange from the Internet and extract arbitrary Active Directory records, which are also known as LDAP records.