Bloodhound is very useful for red teaming in the Active Directory environment and can easily identify attack paths which can be used for both lateral movement and privilege escalation. But from the blue team or system administrator point of view in large corporates, it can be difficult to use BloodHound easily.

The important problem with attack paths is the identification of the most dangerous attack paths from millions. Sometimes one relationship that we block (Group Membership, ACE, Session, etc.) can block access to Tier0 objects with eliminating thousands of attack paths.

In this blog post, we will discuss how to prioritize and mitigate attack paths in an Active Directory environment using Bloodhound and our new tool Kangal.

By applying the processes iteratively and systematically in your own environment, you can have a fairly secure Active Directory environment, both in terms of attack paths and privileged access. In this way, the maneuvers of attackers, especially in Ransomware cases, will be restricted as much as possible.

Kangal and Combined Attack Path Management

The Combined Attack Path method is a process to summarize and combine attack paths that target Tier0 objects in an Active Directory environment. In this way, it is possible to focus on the relationships that are the riskiest among the millions of attack paths and that can have the most impact when mitigated.

Kangal analyzes the data collected with Bloodhound to create a Combined Attack Paths graph and scores the groups created. According to these scores, dangerous relationships can be easily prioritized.

After we collect the data with Sharphound and upload this data to the Neo4j database via BloodHound, we can start our analysis.

When we run the Find Shortest Path to Domain Admins query with BloodHound, we get the following output. Although this output can be useful for the red team, it is not much suitable for blue team processes.

BloodHound Find Shortest Path to Domain Admins Query Result

The Shortest Paths to High Value Targets query gives a similar output, and it can be difficult to examine this output through the BloodHound interface in a large environment.

BloodHound Shortest Path to High Value Targets Query Result

Finally, the statistics produced by BloodHound for the test environment are as follows.

BloodHound Database Stats

Analysis Process

1. Identifying the Tier0 Objects

As a result of the Bloodhound enumeration, various objects (Domain Admins, Administrators, etc.) are marked as high value. But BloodHound does not mark

• members of these admin groups,
• OUs containing these admin objects,
• GPOs that affect them
• and some other privileged groups as high value.

1. High value objects should be listed and examined with the following Neo4j query. If there are different important /privileged objects in the corporate other than these objects, they should also be marked as high value. This operation can be performed from the BloodHound interface or via Neo4j.

Identifying high values objects and their labels (9 objects)

2. After the review and marking, all members of the high value groups should also be marked as high value with the following Neo4j query.

3. With the following Neo4j query, Container and OU objects that contains high value objects should be marked as high value in the same way.

4. With the following Neo4j query, Group Policy Objects linked to high value domain or OU objects should also be marked as high value.

5. Finally, with the Neo4j query below, objects marked as high value (i.e. Tier0) should be listed and reviewed again. If there are objects that should not be high value, the permissions of these objects should be revoked and the SharpHound enumeration should be repeated. After that, all steps above should be repeated.

Identifying high values objects and their labels after the queries(33 objects)

2. Creating a Combined Attack Path Tree

After marking the Tier0 objects, the Combined Attack Path tree can be created on Neo4j by running the Kangal. After installing the required packages, Kangal should be run with the following command with Neo4j username and password.

Starting Kangal through Powershell

When the operation is completed, the following Neo4j query can be run with the BloodHound interface and the combined attack paths can be seen.

Visualizing Combined Attack Path Tree with BloodHound

Thanks to the attack tree, the data that were difficult to analyze at first was grouped and made more concise. When the attack paths in this tree are examined, it can be easily seen that the paths to Tier0 are collected under some groups. As an example, when we decouple the connection between Tier0 and Group8, we can prevent all groups under Group8 from reaching Tier0 as well. Thus, with few operations, we can eliminate a huge risk.

Before starting to mitigate the attack paths, we can detect the risk scores of Tier objects with the following query.

As a result of this query, we can see the following values on the Table tab in the Neo4j.

Sum_member_count is very important for us within these values. This value indicates how many users in the Active Directory environment can access to the Tier0. For example, for Tier0, this value is 2583. This means that 2583 unprivileged Active Directory objects can compromise Tier0 objects. This value can also be obtained with the following query.

Querying sum_member_count of Tier0

3. Elimination of Attack Paths

After determining the risk score on Tier0 objects, the process of eliminating attack paths should be started by prioritizing them. We can use sum_member_count metric for prioritization. The following Neo4j query lists the 5 most risky groups (which have most members) related to Tier0.

Identifying most risky 5 groups which have relation on Tier0

The following Neo4j query can also be used to determine the members of these groups and what relations these members have over Tier0. We call the objects that are not members of Tier0 but have privileges on Tier0 as Stealth Admins.

Identifying risky objects and their relations on Tier0 objects

The output also shows that the Enterprise Read-Only Domain Controller group has GetChanges privilege on the domain object. This privilege is normal and default for Active Directory. Therefore, Enterprise Read-Only Domain Controller group should also be marked as highvalue. Objects identified as privileged like this group during the analysis process should be noted and marked as highvalue in the next iteration.

To analyze this output more easily, we can get a unique list of affected objects in the Tier0 group with the query below.

Identifying affected Tier0 objects

After the list is obtained, dangerous or improper privileges over Tier0 objects should be examined and mitigated step by step.

For example, when the Security tab of the fslab.local domain object is opened, the ACL values on this object can be seen. Unnecessary, broad, or suspicious entries should be removed or restricted. For example, in this interface, we can see that the group CO-blackgirl-admingroup has FullControl(GenericAll) privilege over the domain and all objects under the domain. This privilege is a very broad one and that should only exist for certain admin objects. Therefore, these and similar entries should be removed.

Dangerous access control entries on fslab.local domain object

In other case, three users with ExecuteDCOM privilege over the DC were identified. This privilege is due to the Distributed COM Users group membership. For this reason, users who do not need this privilege should be removed from this group.

Members of Distributed COM Users group

In our last example, we can see the ACL information on the BARBARA_CLINE object. The key point here is that the JO-teamojavi-admingroup group has FullControl(GenericAll) privilege on the BARBARA_CLINE not directly but because of inheritance. This ACE was actually applied to the FSR OU which the BARBARA_CLINE is a member. But it also affects the BARBARA because of ACL inheritance.

Interited Access Control Entries

Results

After these steps are completed and the dangerous relationships are cleared, the analysis process should be repeated from the first stage. Later, we started new SharpHound enumeration in test environment and obtained statistics below.

Database stats after analysis process

In addition, after all steps are done and the Combined Attack Path tree is created again, we can get a visual like below. It can be seen that the attack paths are reduced compared to the first tree.

Combined Attack Path Tree after analysis process

Also, in the second iteration, the sum_member_count value on the Tier0 object is reduced by half.

sum_member_count of Tier0 object after analysis

Risky groups and their sum_member_count values after analysis

BloodHound, Active Directory ortamına yönelik kırmızı takım çalışmaları için oldukça faydalı ve hem yatayda yayılma hem de yetki yükseltme için kullanılabilecek saldırını yollarını kolayca tespit edebilen bir araçtır. Fakat büyük Active Directory altyapılarda mavi takım veya sistem yöneticisi açısından bakıldığında BloodHound uygulamasını direkt olarak kullanmak zorlaşabilmektedir.

Saldırı yolları ile ilgili en önemli sorun bazen milyonlara varan saldırı yolu arasından öncelikli olarak hangisinin seçilmesi ve giderilmesi gerektiğinin tespitidir. Bazen engellediğimiz bir ilişki (Group Üyeliği, ACE, Oturum vb) binlerce saldırı yolunun Tier0 objelere erişimini engelleyebilmektedir.

Bu blog yazımızda Bloodhound ve ekibimiz tarafından geliştirilen Kangal isimli aracı kullanarak, Active Directory ortamındaki saldırı yollarını nasıl önceliklendireceğimize ve nasıl gidereceğimize dair bir analiz gerçekleştireceğiz.

Bu analizdeki işlemleri iteratif ve sistematik bir şekilde kendi ortamınızda uygulayarak süreç sonunda hem saldırı yolları hem de yetkilendirme açısından oldukça güvenli bir Active Directory ortamına sahip olabilirsiniz. Bu sayede de saldırganların özellikle Ransomware vakalarındaki manevraları olabildiğince kısıtlanacaktır.

Kangal ve Combined Attack Paths Yöntemi

Combined Attack Paths olarak adlandırdığımız yöntem aslında Active Directory ortamında Tier0 olarak sınıflandırılan objelere yönelik saldırı yollarının birleştirilerek özet ve hedef odaklı bir hale getirilmesidir. Bu sayede milyonlarca saldırı yolu arasında en riskli ve giderildiğinde en fazla etkiyi oluşturabilecek olan saldırı yollarına/ilişkilere odaklanılabilmektedir.

Kangal ismini verdiğimiz Python betiği Bloodhound ile toplanan veri üzerinde analiz yaparak Combined Attack Paths grafı oluşturmakta ve graftaki grupları skorlamaktadır. Bu skorlara göre de ilişkiler kolaylıkla önceliklendirilebilmektedir.

Sharphound ile Active Directory ortamımızdaki veriyi elde ettikten ve bu veriyi BloodHound aracılığı ile Neo4j veritabanına yükledikten sonra analizimize başlayabiliriz.

BloodHound ile Find Shortest Path to Domain Admins sorgusunu çalıştırdığımızda aşağıdaki gibi bir çıktı elde etmekteyiz. Bu çıktı kırmızı takım tarafından kullanılabilir olsa da mavi takım tarafından kullanılabilirliği oldukça zordur.

BloodHound Find Shortest Path to Domain Admins Sorgusu

Shortest Path to High Value Targets sorgusu da benzer bir çıktı vermektedir ve bu çıktıyı BloodHound arayüzü üzerinden incelenmesi büyük ortamlarda zor olabilmektedir.

BloodHound Shortest Path to High Value Targets Sorgusu

Son olarak kullandığımız test ortamına ait BloodHound tarafından üretilen istatistikler de aşağıdaki gibidir.

BloodHound Veritabanı İstatistikleri

Analiz Süreci

1. Tier0 Objelerin Belirlenmesi

Bloodhound taraması sonucunda çeşitli objeler (Domain Admins, Administrators vb) highvalue olarak işaretlenmektedir. Fakat BloodHound bu objelerin üyelerini, bu objeleri içeren OU ve etkileyen GPO’ları ayrıca çeşitli grupları yetkisiz olarak işaretlemektedir. Bu nedenle öncelikle aşağıdaki adımlar gerçekleştirilmelidir.

1. Aşağıdaki Neo4j sorgusu ile highvalue objeler listelenmeli ve incelenmelidir. Eğer bu objeler dışında kurum özelinde önemli/yetkili farklı objeler bulunuyorsa onlar da highvalue olarak işaretlenmelidir. Bu işlem BloodHound arayüzünden veya Neo4j üzerinden gerçekleştirilebilir.

BloodHound tarafından işaretlenmiş high value objelerin ve obje tiplerinin listelenmesi (9 obje)

2. İnceleme ve işaretleme aşaması tamamlandıktan sonra aşağıdaki Neo4j sorgusu ile highvalue grupların tüm üyeleri de highvalue olarak işaretlenmelidir.

3. Aşağıdaki Neo4j sorgusu ile de highvalue objeleri içerisinde barındıran Container ve OU objeleri aynı şekilde highvalue olarak işaretlenmelidir.

4. Aşağıdaki Neo4j sorgusu ile highvalue domain veya OU objelerine linklenmiş Group Policy Objeleri de highvalue olarak işaretlenmelidir.

5. Son olarak aşağıdaki Neo4j sorgusu ile highvalue (yani Tier0) olarak işaretlenmiş objeler tekrar listelenmeli ve tekrar gözden geçirilmelidir. Eğer highvalue olarak işaretlenmemesi gereken objeler tespit edilirse, Active Directory ortamından bu objenin yetkileri devre dışı bırakılmalı ve SharpHound taraması tekrarlanmalıdır. Tarama sonucunda da birinci adımdan itibaren tüm adımlar tekrarlanmalıdır.

Komutlar çalıştırıldıktan sonra high value objelerin ve obje türlerinin listelenmesi (33 obje)

2. Combined Attack Path Ağacının Oluşturulması

Tier0 objeleri belirlendikten sonra Kangal aracı çalıştırılarak Neo4j üzerinde Combined Attack Path yapısı oluşturulabilmektedir. Kangal aracı gerekli paketler yüklendikten sonra aşağıdaki komutla Neo4j kullanıcı adı ve parola bilgileri ile çalıştırılmalıdır.

Kangal aracının komut satırı üzerinden çalıştırılması

Aracın çalışması tamamlandığında BloodHound arayüzüne aşağıdaki Neo4j sorgusu girilerek oluşan saldırı yolları görülebilmektedir.

BloodHound arayüzü ile Combined Attack Path ağacının görüntülenmesi

Oluşan ağaç sayesinde ilk başta incelenmesi zor olan veri gruplanarak daha özet bir hale getirilmiş oldu. Bu ağaçtaki saldırı yolları incelendiğinde Tier0’a gelen yolların bazı gruplar altında toplandıkları da kolayca görülebilmekte. Bu ağaç yapısında örnek olarak Tier0 ile Group8 arasındaki bağlantıyı kestiğimizde Group8 altındaki tüm grupların da Tier0’ya ulaşmasını engelleyeceğiz. Bu sayede birkaç işlemle aslında çok büyük bir riski ortadan kaldırmış olacağız.

Saldırı yollarını gidermeye başlamadan önce aşağıdaki sorgu ile Neo4j üzerinde Tier objelerinin risk skorları tespit edilebilmektedir.

Bu sorgu sonucunda Neo4j veritabanındaki Table sekmesinde aşağıdaki değerler görülecektir.

Bu değerler içerisinde sum_member_count bizim için oldukça önemlidir. Bu değer, ilgili Tier’ın barındırdığı objelerin Active Directory ortamındaki kaç obje tarafından ele geçirilebileceğini göstermektedir. Örneğin Tier0 için bu değer 2583’tür. Bu da 2583 yetkisiz Active Directory objesinin Tier0 objelerini ele geçirebileceğini göstermektedir. Bu değer de aşağıdaki sorgu ile elde edilebilmektedir.

Tier0 objesi için sum_member_count değerinin görüntülenmesi

3. Saldırı Yollarının Giderilmesi

Tier0 objeleri üzerindeki risk değerini de tespit ettikten sonra önceliklendirme yaparak saldırı yollarının giderilmesi işlemine başlanmalıdır. Burada önceliklendirme işlemi yine sum_member_count değeri ile gerçekleştirilebilmektedir. Aşağıdaki Neo4j sorgusu ile Tier0 üzerinde yetkisi olan en riskli (en fazla üyeye sahip olan) 5 grup listelenebilmektedir.

Tier0 üzerindeki en riskli 5 grubun tespit edilmesi

Bu grupların üyelerini ve bu üyelerin Tier0 üzerinde hangi yetkilere sahip olduğunu tespit etmek için de aşağıdaki Neo4j sorgusu kullanılabilmektedir.

Tier0 üzerindeki en riskli objeleri ve bu objelerin yetkilerinin tespit edilmesi

Çıktıda ayrıca Enterprise Read-Only Domain Controller grubunun domain objesi üzerinde GetChanges yetkisine sahip olduğu görülmektedir. Bu yetki normal ve varsayılan bir yetkidir. Bu nedenle Enterprise Read-Only Domain Controller grubunun da highvalue olarak işaretlenmesi gerekmektedir. Analiz süreci boyunca bu şekilde yetkili olarak tespit edilen objeler not edilmeli ve bir sonraki iterasyonda highvalue olarak işaretlenmelidir.

Bu listeyi daha kolay analiz edebilmek adına aşağıdaki komutla etkilenen yetkili objelerin listesi elde edilebilmektedir.

Tier0 üyesi etkilenen objelerin listelenmesi

Yetkili objeler elde edildikten sonra bu objeler üzerindeki yetkiler incelenerek adım adım giderilmelidir.

Örnek olarak fslab.local domain objesinin Security sekmesine gidildiğinde bu obje üzerindeki ACL değerleri görülebilmektedir. Bu değerlerden gereksiz, geniş veya şüpheli olanlar kaldırılmalı veya kısıtlanmalıdır. Bu arayüzde örnek olarak CO-blackgirl-admingroup grubunun domain ve domain altındaki tüm objeler için FullControl(GenericAll) yetkisine sahip olduğu görülmektedir. Bu yetki sadece belirli admin objelerinde bulunması gereken çok geniş bir yetkidir. Bu nedenle bu ve benzer yetkiler kaldırılmalı ve kısıtlanmalıdır.

fslab.local domain objesi üzerindeki tehlikeli Access Control Entry değerlerinin görüntülenmesi

Bir diğer örnekte de DC üzerinde ExecuteDCOM yetkisi olan üç kullanıcı tespit edilmiştir. Bu yetki Distributed COM Users grubu ile aktarılmaktadır. Bu nedenle bu yetkiye ihtiyacı olmayan kullanıcılar bu gruptan çıkarılarak bu yetkilerin de önüne geçilmelidir.

Distributed COM Users grubu üyelerinin görüntülenmesi

Son örneğimizde de BARBARA_CLINE objesi üzerindeki ACL bilgileri görüntülenmektedir. Buradaki önemli nokta ise JO-teamojavi-admingroup grubunun BARBARA_CLINE objesi üzerinde kalıtımsal olarak FullControl(GenericAll) yetkisine sahip olmasıdır. Bu yetki aslında BARBARA_CLINE objesinin üyesi olduğu FSR isimli OU’ya uygulanmış fakat kalıtımsal olarak BARBARA kullanıcısını da etkilemiştir.

Kalıtımsal olarak aktarılan Access Control Entry değerlerinin görüntülenmesi

Sonuç

Bu işlemler tamamlandıktan ve zararlı/tehlikeli ilişkiler temizlendikten sonra ilk aşamadan itibaren analiz süreci tekrarlanmalıdır. İşlemler tamamlandıktan sonra tekrar SharpHound taraması gerçekleştirildiğinde aşağıdaki veritabanı istatistikleri elde edilmiştir.

Analiz sonrası veritabanı istatistiklerin görüntülenmesi

Ayrıca işlemler gerçekleştirilip tekrar Combined Attack Path ağacı oluşturulduğunda aşağıdaki gibi bir görsel elde edilmektedir. Yine ilk ağaçla karşılaştırıldığında saldırı yollarının azaldığı görülebilmektedir.

Analiz sonrası saldırı yollarının tekrar incelenmesi

Son olarak Tier0 objesi üzerindeki sum_member_count değeri incelendiğinde bu değerin de yarı yarıya düştüğü görülebilmektedir.

Analiz sonrası Tier0 grubuna ait sum_member_count değerinin görüntülenmesi

Analiz sonrası en riskli grupların listelenmesi

In this blog series, we will talk about the details of Kerberos protocol, delegation methods, attack vectors that can be used to exploit these methods, mitigation plans and detection rules against these attacks. In the first post of the series, we will analyze the details of the Kerberos Protocol.

The Kerberos authentication protocol was first developed by MIT and supported by many organizations. It was developed to provide encrypted and secure authentication on an insecure network without sharing a clear-text password. While encrypting the data on the network, the protocol uses the Shared Secret Key method.

By making various customizations in the Kerberos protocol, Microsoft uses this customized protocol by default in Windows Server 2000 and later. Kerberos is used in the Microsoft Active Directory environment to provide authentication during the access of objects (User, Computer) to resources (File Sharing, Remote Desktop Access, etc.).

There are 3 basic elements in the Kerberos protocol.

1. Key Distribution Center: KDC is the main service responsible for the Kerberos protocol. This service runs on Domain Controller servers. It contains information and password hashes of all client and service accounts in the Active Directory environment. These password hashes are used as the Shared Secret Key during the Kerberos protocol.

• • Authentication Service (AS): It is the module in the Key Distribution Center that is responsible for the authentication step. This module authenticates clients by checking information such as whether the client is in the Active Directory domain (Domain), whether the password it provides is correct.
  • Ticket Granting Service (TGS): It is the module that provides the creation, validation, and management of necessary tickets for authenticated clients.
  • KRBTGT: It is the user account that provides the administration of the Key Distribution Center service. This user’s password hash is used to encrypt some tickets.

2. Client: It is the object that initiates the authentication process to access the service. It can be a user account or a machine account. Each user and computer in the Active Directory environment has an account. User accounts are created with the username, while computer accounts are indicated by the machine name and $ sign. Computer accounts have also passwords like user accounts. These passwords are complex passwords that are automatically generated and changed every 30 days. The NT hash of these passwords functions similarly to the user password hashes in the Kerberos protocol.

3. Server: It is the service that the client wants to access at the end of the process. User, computer, MSA (Managed Service Account), GMSA (Group Managed Service Account) objects that manage these services are also called service accounts. Password hashes of service accounts are used to create and authenticate some tickets in the Kerberos authentication protocol.

Whether an object in the Active Directory environment is a service account is determined by the Service Principal Name (SPN) values. These names are unique within the same domain. The SPN value of each service is associated with the account that manages that service and is used during the Kerberos protocol. These SPN values are kept in the ServicePrincipalName attribute of the accounts to which they are assigned. These values can be seen with tools like Active Directory Users and Computers, ADExplorer or Powershell. SPN values can be in different formats as follows.

The SPN values in the Active Directory environment and the accounts that manage these values can be determined with the commands below.

Kerberos AS-REQ Packet

The first step of Kerberos authentication is authenticating the user on the KDC and obtaining the Ticket Granting Ticket (TGT). For this purpose, the client first sends the domain name, username, SPN value of KRBTGT and authentication data (Pre-Authentication Data, PA-DATA) which encrypted with the account’s NT hash to the Authentication Service (AS) module. In other words, in this package, the user, domain name and SPN are transmitted as clear text, and the authentication data is transmitted as encrypted.

AS, firstly reads the domain name and username in this packet from the client and obtains the password hash of this user from the NTDS.dit database and tries to decrypt the Pre-Authentication data with this hash. If this step fails, the password is incorrect and the required error message is sent to the client. If the KDC successfully decrypts the Pre-Authentication data, it checks the timestamp in this data. Authentication is successful if the timestamp is in a specific range. An error message is sent to the client if the timestamp is older than the specified range. This timestamp control prevents attacks (Packet Replay) like reusing packets captured over the network. This time interval is 5 minutes by default and can be managed with Kerberos Policy in Group Policy.

Kerberos AS-REQ Packet

When a successful AS-REQ request is examined with network analysis programs, It is possible to see encrypted data and which algorithm is used while encrypting the Pre-Authentication Data in section 1. In section 2, there is the username and domain information that makes the request, and in section 3, there is krbtgt username and domain information.

With the Powershell script below, accounts that have pre-authentication disabled can be detected.

Option that disables User’s Pre-Authentication Phase

AS-REQ Packet Capture of the User with Pre-Authentication Phase Disabled

When the AS-REQ request for a user with the disabled pre-authentication is examined, it can be seen that there is no Pre-Authentication Data in section 1.

Supported Encryption Types for the Client

When the error message is examined, the encryption algorithms that the client can use during the Kerberos protocol and some data (salt) that can be used for these algorithms can be seen in section 1. Algorithms that can be used in the Kerberos protocol can also be managed with Group Policy and settings to be made on the user object.

1.The attacker, who successfully performs a Man in the Middle, can intercept the victim’s AS-REQ request and perform an offline brute-force attack on the part encrypted with the user password hash in this package. If users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. Although this attack method is not very popular, it is called ASREQ-Roasting.

Kerberos AS-REP Packet

The AS module on the KDC sends the Ticket Granting Ticket (TGT) ticket and the Session Key to the client who authenticated with the AS-REQ request. The ticket and the key will be used as evidence in the later stages of the protocol. The AS encrypts a piece of TGT and Session Key data with krbtgt’s NT password hash. It encrypts another piece of Session Key data with the client’s password hash. In this way, the client will not be able to decrypt the part encrypted with the krbtgt password hash but will be able to decrypt the part encrypted with its password hash and use the Session Key value in the further stages.

As a result of this step, the user will have a valid TGT ticket for 10 hours by default. In the next 10 hours, the Kerberos protocol can be operated with the current TGT without the need for AS-REQ and AS-REP stages again. TGT expiration threshold can also be managed with the Group Policy.

Kerberos AS-REP Packet

When the AS-REP message is examined, the encrypted version of the TGT ticket and the algorithm used for encryption can be seen in part 1, and the encrypted part including the Session Key, which the user can decrypt, and the encryption algorithm can be seen in part 2.

1.Attackers can obtain the AS-REP packets of the accounts whose pre-authentication phase is disabled using only the name of the accounts and can perform an offline brute-force attack on the part encrypted with the NT password hash of the user in these packets. If users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. This attack method is called ASREP-Roasting.

2.Similar to the ASREP-Roasting attack, a brute-force attack can also be performed offline on the part encrypted with the KRBTGT password hash in the AS-REP message. Although the krbtgt password is defined in a complex way by default and a simple password cannot be defined for this account, it can be cracked in rare scenarios.

3. Even if the attackers intercept the victim’s AS-REP message, they will not be able to obtain the Session Key value and use the TGT because they do not know the password hash of the user. However, if the attackers obtain the TGT ticket from the memory of a server that they compromised, they can still use the TGT ticket even if he does not know the password summary of the user since he can also obtain the Session Key over the memory. With this method, the attacker can access all services that the user can access with this ticket until the ticket expires. This attack method is also called Pass the Ticket.

4. If the attackers can obtain the NT password hash of the krbtgt user, they can create the TGT ticket transmitted in the AS-REP message with very long expiry times for any existing or non-existing user in the domain. In this way, they can create TGT for authorized users and access any service in the domain environment. This attack method is also called Golden Ticket.

Kerberos TGS-REQ Packet

After obtaining the TGT ticket, the client must use this ticket to obtain the required service ticket for the service they want to access. For this purpose, the client sends the TGT ticket obtained in the previous step and the timestamp information encrypted with the Session Key obtained in the previous step to the KDC. KDC decrypts the TGT in the TGS-REQ package using the NT password hash of the krbtgt account and obtains the Session Key value. Then it checks whether the TGT has expired. With the obtained Session Key, it decrypts the other part that was encrypted and verifies the timestamp.

Kerberos TGS-REQ Packet

When the TGS-REQ request created to access the file sharing (CIFS) service on the DC server is examined with Wireshark, it can be seen in section 1 that the TGT ticket obtained in the previous step is sent to the KDC. The cipher data in the enc-part of this ticket is exactly the same as the data in the previous ticket. The data in section 2 consists of the timestamp and some data encrypted with Session Key. This authenticator data also includes checksum information to verify the package. In section 3, there is information about the service to be accessed. The service name is CIFS and the server name is DC.

Kerberos TGS-REP Packet

When the TGS-REQ request sent from the client is confirmed by the KDC, KDC sends the required service ticket and the second Session Key to the client to access the related service. It encrypts the service ticket and Session Key with the NT password hash of the user who manages that service and also encrypts the same Session Key with the previously obtained Session Key. In this way, the client will not be able to decode and read the service ticket. However, he will be able to obtain the second Session Key value by decrypting it with the Session Key transmitted to him before.

As a result of this stage, the user obtains an ST (Service Ticket) ticket valid for 10 hours by default, similar to the AS-REP stage. To access the same service in the next 10 hours, the current ST is sufficient without the need to repeat AS-REQ, AS-REP, TGS-REQ and TGS-REP steps. The ST expiration threshold can also be managed with the help of Group Policy.

Kerberos TGS-REP Packet

When the TGS-REP message is examined with the Wireshark, the encrypted ST (Service Ticket) ticket and the algorithm used for encryption can be seen in section number 1. In section number 2, encrypted second Session Key that the user can decrypt and the encryption algorithm can be seen.

1. Since the Kerberos protocol does not perform the authorization check, all users in the environment can make TGS-REQ requests for all services and obtain the relevant ST ticket for the service. In this way, attackers can take the necessary ST tickets for the services in the environment and perform an offline brute-force attack on the part encrypted with the password hash of the service user in the tickets. If the passwords of the service accounts are simple and the encryption algorithm is relatively weak, attackers can obtain the plain-text password. This attack method is called Kerberoasting.

2. The attacker, who successfully performs a Man in the Middle attack, can capture the TGS-REP message of the victim and perform an offline brute-force attack on the part encrypted with the password hash of the service user in this package. If service users’ passwords are simple and the encryption algorithm is relatively weak, attackers can access plain-text passwords. Although this hacking method is different, the result is the same as a Kerberoasting attack.

3. Even if attackers intercept the victim’s TGS_REP message, they will not be able to obtain the second Session Key value and will not be able to use the ST because they do not know the Session Key value. However, if the attackers dump the TGS ticket from the memory of a compromised server, they can still use the ST ticket even if they do not know the password hash of the user, since they can also obtain the Session Key over the memory. The attackers can access the relevant service in the ticket until this ticket expires. They can also access other services on the target server by changing the service name in the ticket. This attack method is called Pass the Ticket.

4. If the attackers can obtain the NT password hash of the service account, they can create the ST ticket transmitted in the TGS-REP message for any existing or non-existing user in the domain. In this way, they can create ST for authorized users and access the services managed by this service account. This attack method is also called Silver Ticket.

Kerberos AP-REQ Packet

When the clients obtained the required ST for the relevant service, they can access the service with the help of this ticket. The client sends the ST encrypted with the password hash of the service account and the timestamp encrypted with the second Session key value to the server where the service is running. The service decrypts the first piece as it is encrypted with its password hash and checks the information in it. In addition, using the Session Key value in this part, the service decrypts the second part and makes the necessary verifications. After this stage, the service will check whether the user is authorized to access the service and return the relevant response to the client.

Kerberos AP-REQ Packet

When the AP-REQ request is examined with Wireshark, it is seen that there is the ST ticket obtained in the TGS-REP stage in the first part. All data in enc-part is the same as the data received in the previous packet. In the second part, there is the verification data containing the timestamp encrypted with the second Session Key.

1. The attacker, who successfully performs a Man in the Middle attack, can capture the AP-REQ message of the victim and perform an offline brute-force attack on the part encrypted with the password hash of the service user in this packet. If service users’ passwords are simple and the encryption algorithm is relatively weak, attackers can obtain plaintext passwords. This attack is also the same as the Kerberoasting attack, although the hijacking method is different.

At this stage, the server returns to the client about the authentication and authorization result. This response includes the encrypted timestamp with the second Session Key, sequence number and other relevant data. This step is not mandatory to complete the Kerberos authentication.

Kerberos AP-REP Packet

When the AP-REP package is examined, the encrypted part and used encryption algorithm can be seen.

In this blog post, we talked about the Kerberos protocol steps and the attack methods that can be performed at each phase. In our next article, we will examine the Kerberos Protocol in detail and go about ticket types, PAC verification and Kerberos steps between domains and forests. In further stages, we will analyze the delegation methods, Kerberos steps during the use of delegation, and all Kerberos-related attack methods from the perspective of exploitation, prevention and detection.

• https://web.mit.edu/kerberos/
• https://datatracker.ietf.org/doc/html/rfc4120
• https://www.secureauth.com/blog/kerberos-delegation-spns-and-more/
• https://www.tarlogic.com/en/blog/how-kerberos-works/
• https://improsec.com/tech-blog/asreqroast-from-mitm-to-hash

Bu blog serimizde Kerberos protokolünü, delegation yöntemlerini, bu yöntemleri sömürmek için kullanılabilecek saldırı yöntemlerini, bu saldırıları gidermek için alınabilecek önlemleri ve saldırıları tespit için kullanılabilecek bazı kuralları paylaşacağız. Serinin ilk yazısında da öncelikle Kerberos protokol adımlarını detaylı olarak inceleyeceğiz.

Kerberos kimlik doğrulama protokolü ilk olarak MIT tarafından geliştirilmiş ve birçok organizasyon tarafından desteklenmiştir. Protokol kimlik doğrulamasının, güvensiz bir ağda, açık metin halinde parola paylaşmadan, şifreli ve güvenli bir şekilde sağlanması amacıyla geliştirilmiştir. Protokol ağ üzerindeki verileri şifrelerken de ön paylaşımlı gizli anahtar (Shared Secret Key) metodunu kullanmaktadır.

Microsoft, Kerberos protokolünde çeşitli özelleştirmeler yaparak Windows Server 2000 ve sonrasında varsayılan olarak bu özelleştirilmiş protokolü kullanmaktadır. Bu protokol Microsoft Active Directory ortamında objelerin (Kullanıcı, Bilgisayar) kaynaklara (Dosya Paylaşımı, Uzaktan Masaüstü Erişimi vb.) erişimi sırasında kimlik doğrulamasının sağlanması amacıyla kullanılmaktadır.

Kerberos protokolünde temel 3 öge bulunmaktadır.

1. Key Distribution Center: Kerberos protokolünün yönetimi sağlayan servistir. Bu servis Domain Controller sunucuları üzerinde çalışmaktadır. Active Directory ortamındaki tüm istemci ve servis hesaplarının bilgilerini ve parola özetlerini bünyesinde barındırmaktadır. Bu parola özetleri Kerberos protokolü sırasında şifreleme anahtarı (Shared Secret Key) olarak kullanılmaktadır.

• • Authentication Service (AS): Key Distribution Center içerisinde bulunan ve kimlik doğrulama adımından sorumlu olan modüldür. Bu modül istemcinin Active Directory etki alanında (Domain) bulunup bulunmadığını, sağladığı parolanın doğru olup olmadığı gibi bilgileri kontrol ederek kimlik doğrulama işlemini sağlamaktadır.
  • Ticket Granting Service (TGS): Kimliği doğrulanan istemciler için gerekli biletlerin oluşturulmasını, doğrulanmasını ve yönetimi sağlayan modüldür.
  • KRBTGT: Key Distribution Center servisinin yönetimini sağlayan kullanıcı hesabıdır. Bu kullanıcının parola özeti bazı biletlerin şifrelenmesi için kullanılmaktadır.

2. İstemci (Client): Servise erişmek için kimlik doğrulama sürecini başlatan objedir. Bir kullanıcı hesabı veya makine hesabı olabilir. Active Directory ortamındaki her kullanıcının ve bilgisayarın bir hesabı bulunmaktadır. Kullanıcı hesapları kullanıcı adı ile oluşurken, bilgisayar hesapları ise makine adı ve $ işareti ile belirtilmektedir. Bilgisayar hesaplarının da kullanıcı hesapları gibi parolası bulunmaktadır. Bu parolalar otomatize bir şekilde oluşturulan ve 30 günde bir değiştirilen karmaşık parolalardır. Bu parolaların NT parola özeti (hash), Kerberos protokolünde kullanıcı parola özetlerine benzer bir şekilde işlev görmektedirler.

3. Hizmet alınacak olan servis (Server): İstemcinin süreç sonunda erişmek istediği servistir. Bu servisleri yöneten kullanıcı, bilgisayar, MSA (Managed Service Account), GMSA (Group Managed Service Account) objeleri de servis hesabı (Service Account) olarak adlandırılmaktadır. Servis hesaplarının parola özetleri Kerberos kimlik doğrulama protokolündeki bazı biletlerin oluşturulması ve doğrulanması için kullanılmaktadır.

Active Directory ortamındaki bir objenin servis hesabı olup olmadığı Service Principal Name (SPN) değerleri ile belirlenmektedir. Bu isimler aynı etki alanı içerisinde benzersiz şekilde yapılandırılmaktadır. Her servise ait SPN değeri o servisi yöneten hesapla ilişkilendirilerek Kerberos protokolü sırasında kullanılmaktadır. Bu SPN değerleri atandıkları hesapların ServicePrincipalName değerinde (attribute) tutulmaktadır. Bu değerler Active Directory Users and Computers, ADExplorer veya Powershell ile görülebilmektedir. SPN değerleri aşağıdaki gibi farklı formatlarda olabilmektedir.

Active Directory ortamındaki SPN değerleri ve bu değerleri yöneten hesaplar aşağıdaki komutlar ile tespit edilebilmektedir.

Kerberos AS-REQ Paket İçeriği

Kerberos kimlik doğrulamasının ilk adımı kullanıcının KDC üzerinde kimliğinin doğrulanması ve Ticket Granting Ticket (TGT) adı verilen biletin alınmasıdır. Bu amaçla istemci öncelikle Authentication Service (AS) modülüne, bulunduğu domain adını, kullanıcı adını, KRBTGT’ye ait SPN değerini ve hesabının NT parola özeti ile şifrelenmiş kimlik doğrulama verisini (Pre Authentication Data, PA-DATA) göndermektedir. Yani bu pakette kullanıcı, domain adı ve SPN açık metin olarak, kimlik doğrulama verisi ise şifrelenmiş olarak iletilmektedir.

AS öncelikle istemciden gelen bu paketteki domain adını ve kullanıcı adını okuyarak NTDS.dit veri tabanından bu kullanıcıya ait parola özetini elde eder ve bu parola özeti ile Pre Authentication verisinin şifresini çözmeye çalışır. Eğer bu aşamada başarısız olunursa parola hatalıdır ve istemciye gerekli hata mesajı gönderilir. Eğer KDC Pre Authentication verisini başarıyla deşifre (decrypt) ederse bu veri içerisindeki zaman damgasını kontrol eder. Zaman damgası de belirli bir aralık içerisindeyse kimlik doğrulama başarılı olmuş olur. Eğer zaman damgası belirlenen aralıktan eskiyse istemciye hata mesajı gönderilir. Bu zaman damgası kontrolü ağ üzerinden yakalanan paketlerin tekrar kullanılmasıyla gerçekleştirilen saldırıları (Packet Replay) önlemektedir. Bu zaman aralığı varsayılan olarak 5 dakikadır ve Group Policy içerisindeki Kerberos Policy ile yönetilebilmektedir.

Kerberos AS-REQ Paket İçeriği

Başarılı bir AS-REP isteği, paket analiz programlarıyla, incelendiğinde 1 numaralı kısımda Pre-Authentication Data verisinin hangi algoritma kullanılarak şifrelendiği ve şifrelenmiş veri görülebilmektedir. 2 numaralı kısımda isteği yapan kullanıcı adı ve bulunduğu domain bilgisi, 3 numaralı kısımda da krbtgt kullanıcı adı ve domain bilgisi bulunmaktadır.

Aşağıdaki Powershell betiği ile pre-authentication aşaması devre dışı bırakılan hesaplar tespit edilebilmektedir.

Kullanıcının Pre-Authentication Aşamasının Devre Dışı Bırakılması

Pre-Authentication Aşaması Devre Dışı Bırakılan Kullanıcının AS-REQ Paket İçeriği

Pre-authentication aşaması devre dışı bırakılan bir kullanıcı için AS-REQ isteği incelendiğinde 1 numaralı kısımda Pre-Authentication Data verisinin bulunmadığı görülebilmektedir.

İstemci için Kullanılabilecek Şifreleme Algoritmalarının İletilmesi

Hata mesajı incelendiğinde 1 numaralı kısımda kullanıcının Kerberos protokolü sırasında kullanabileceği şifreleme algoritmaları ve bu algoritmalar için kullanılabilecek bazı veriler (Salt) görülebilmektedir. Kerberos protokolünde kullanılacak algoritmalar da Group Policy ve kullanıcı objesi üzerinde yapılacak ayarlar ile yönetilebilmektedir.

1. Başarılı bir şekilde araya girme saldırısı (Man in the Middle) gerçekleştiren saldırgan, kurbanın AS-REQ isteğini ele geçirebilir ve bu paket içerisindeki kullanıcı parola özeti ile şifrelenen kısma offline olarak brute-force saldırısı gerçekleştirebilir. Eğer kullanıcıların parolaları basit ve şifreleme algoritması da görece zayıf ise saldırganlar plain-text parolaya ulaşabilirler. Bu saldırı yöntemi çok popüler olmasa da ASREQ-Roasting olarak adlandırılmaktadır.

Kerberos AS-REP Paket İçeriği

KDC üzerindeki AS modülü, AS-REQ isteği ile kimliği doğrulanan istemciye, protokolün ileriki aşamalarında kanıt olarak kullanılacak olan Ticket Granting Ticket (TGT) biletini ve Session Key adı verilen anahtar bilgisini gönderir. Fakat TGT ve Session Key verisinden oluşan bir parçayı krbtgt’nin NT parola özeti ile şifreler. Session Key verisini içeren diğer bir parçayı da istemcinin parola özeti ile şifreler. Bu sayede istemci krbtgt parola özeti ile şifrelenen parçayı deşifre edemeyecek, kendi parola özeti ile şifrelenen parçayı ise deşifre ederek Session Key değerini elde ederek ileriki aşamalarda kullanabilecektir.

Bu aşama sonucunda kullanıcı varsayılan olarak 10 saat için geçerli bir TGT bileti elde etmiş olur. İleriki 10 saat içerisinde de bir daha AS-REQ ve AS-REP aşamalarına ihtiyaç olmadan halihazırdaki TGT ile Kerberos protokolü işletilebilmektedir. Bu 10 saatlik süre de Group Policy ile yönetilebilmektedir.

Kerberos AS-REP Paket İçeriği

AS-REP mesajı incelendiğinde 1 numaralı kısımda TGT biletinin şifrelenmiş hali, şifreleme için kullanılan algoritma, 2 numaralı kısımda da kullanıcının deşifre edebileceği Session Key’i de içeren şifreli kısım ve şifreleme algoritması görülebilmektedir.

1. Saldırganlar pre-authenication aşaması devre dışı bırakılmış hesapların AS-REP paketini sadece hesapların ismini kullanarak elde edebilir ve bu paketteki kullanıcının NT parola özeti ile şifrelenmiş kısma offline olarak brute-force saldırısı gerçekleştirebilirler. Eğer kullanıcıların parolaları basit ve şifreleme algoritması görece zayıf ise saldırganlar plain-text parolaya ulaşabilirler. Bu saldırı yöntemi ASREP-Roasting olarak adlandırılmaktadır.

2. ASREP-Roasting saldırısına benzer bir şekilde AS-REP mesajı içerisinde KRBTGT parola özeti ile şifrelenmiş kısım üzerinde de offline olarak brute-force saldırısı gerçekleştirilebilir. Krbtgt parolasının varsayılan olarak karmaşık bir şekilde tanımlanmasına ve bu hesap için istense bile basit parola tanımlanamamasına karşın nadir senaryolarda kırılabilmektedir.

3. Bir saldırgan araya girme saldırısı yaparak kurbanın AS-REP mesajını ele geçirse bile kullanıcının parola özetini bilmediği için Session Key değerini elde edemeyecek ve TGT’yi kullanamayacaktır. Fakat eğer saldırgan TGT biletini, ele geçirdiği bir sunucunun belleği (memory) üzerinden elde ederse yine bellek üzerinden Session Key’i de elde edebileceği için kullanıcının parola özetini bilmese dahi TGT biletini kullanabilmektedir. Bu yöntemle saldırgan bilet süresi dolana kadar (expire) bu biletle kullanıcının erişebildiği tüm servislere erişebilmektedir. Bu saldırı yöntemine de Pass the Ticket adı verilmektedir.

4. Bir saldırgan krbtgt kullanıcısının NT parola özetini ele geçirebilirse AS-REP mesajı içerisinde iletilen TGT biletini domainde var olan veya olmayan herhangi bir kullanıcı için çok uzun expire süreleri ile oluşturabilmektedir. Bu sayede de yetkili kullanıcılar için TGT oluşturabilmekte ve domain ortamındaki istediği servise erişebilmektedir. Bu saldırı yöntemine de Golden Ticket adı verilmektedir.

Kerberos TGS-REQ Paket İçeriği

İstemcinin, TGT biletini aldıktan sonra bu bileti kullanarak erişmek istediği servis için gerekli servis biletini alması gerekmektedir. Bu amaçla istemci KDC’ye bir önceki adımda elde ettiği TGT biletini ve yine bir önceki adımda elde ettiği Session Key ile şifrelenmiş zaman damgası bilgisini göndermektedir. KDC TGS-REQ paketi içerisindeki TGT’yi krbtgt hesabının NT parola özetini kullanarak deşifre eder ve Session Key değerini elde eder. Ardından TGT’nin son kullanma tarihinin geçip geçmediğini kontrol eder. Elde ettiği Session Key ile de şifrelenmiş olan diğer kısmı deşifre eder ve zaman damgasını doğrular.

Kerberos TGS-REQ Paket İçeriği

DC sunucusu üzerindeki dosya paylaşımı (CIFS) servisine erişmek için oluşturulan TGS-REQ isteği Wireshark ile incelendiğinde 1 numaralı kısımda bir önceki adımda elde edilen TGT biletinin KDC’ye gönderildiği görülebilmektedir. Bu biletin enc-part içerisindeki cipher verisi bir önceki biletteki verinin tıpa tıp aynısıdır. 2 numaralı kısımdaki veri ise zaman damgasının ve birtakım farklı verilerin Session Key ile şifrelenmesinden oluşmaktadır. Bu authenticator verisi içerisinde ayrıca paketin doğrulanmasını sağlamak için checksum bilgisi de bulunmaktadır. 3 numaralı kısımda ise erişilmek istenen servise ait bilgiler bulunmaktadır. Servis ismi CIFS, servisin çalıştığı sunucu adı ise DC’dir.

Kerberos TGS-REP Paket İçeriği

İstemciden gelen TGS-REQ isteğini doğrulayan KDC, istemciye servise erişmek için gerekli servis biletini ve ikinci Session Key değerini göndermektedir. Fakat servis biletini ve Session Key değerini o servisi yöneten (o servisin SPN değerine sahip olan) kullanıcının NT parola özeti ile, ayrıca yine aynı Session Key değerini bir önceki istekte elde ettiği birinci Session Key değeri ile şifreler. Bu sayede istemci servis biletini deşifre edemeyecek ve okuyamayacaktır. Fakat ikinci Session Key değerini daha önce kendisine iletilen Session Key değeri ile deşifre ederek elde edebilecektir.

Bu aşama sonucunda kullanıcı AS-REP aşamasına benzer şekilde varsayılan olarak 10 saat için geçerli bir ST (Service Ticket) bileti elde etmiş olur. İleriki 10 saat içerisinde de aynı servise erişmek için bir daha AS-REQ, AS-REP, TGS-REQ ve TGS-REP aşamalarına ihtiyaç olmadan halihazırdaki ST ile Kerberos protokolü işletilebilmektedir. Bu 10 saatlik süre de Group Policy ile yönetilebilmektedir.

Kerberos TGS-REP Paket İçeriği

TGS-REP mesajı Wireshark ile incelendiğinde 1 numaralı kısımda ST (Service Ticket) biletinin şifrelenmiş hali, şifreleme için kullanılan algoritma, 2 numaralı kısımda da kullanıcının deşifre edebileceği ikinci Session Key’i içeren kısım ve şifreleme algoritması görülebilmektedir.

1. Kerberos protokolü yetkilendirme (Authorization) kontrolü gerçekleştirmediğinden ortamdaki tüm kullanıcılar, tüm servisler için TGS-REQ isteği yapabilmekte ve servis için gerekli ST biletini elde edebilmektedirler. Saldırganlar da bu şekilde ortamdaki servisler için gerekli ST biletlerini alarak biletlerdeki servis kullanıcısının parola özeti ile şifrelenmiş kısma offline brute-force saldırısı gerçekleştirebilmektedirler. Eğer servis hesaplarının parolaları basit ve şifreleme algoritması da görece zayıf ise saldırganlar plain-text parolaya ulaşabilirler. Bu saldırı yöntemi Kerberoasting olarak adlandırılmaktadır.

2. Başarılı bir şekilde araya girme saldırısı (Man in the Middle) gerçekleştiren saldırgan kurbanın TGS-REP mesajını ele geçirebilir ve bu paket içerisindeki servis kullanıcısının parola özeti ile şifrelenmiş kısma offline olarak brute-force saldırısı gerçekleştirebilir. Eğer servis kullanıcıların parolaları basit ve şifreleme algoritması görece zayıf ise saldırganlar plain-text parolaya ulaşabilirler. Bu saldırı ele geçirme yöntemi farklı olsa da sonuç olarak Kerberoasting saldırısıyla aynıdır.

3. Bir saldırgan araya girme saldırısı yaparak kurbanın TGS_REP mesajını ele geçirse bile Session Key değerini bilmediği için ikinci Session Key değerini elde edemeyecek ve ST’yi kullanamayacaktır. Fakat eğer saldırgan TGS biletini, ele geçirdiği bir sunucunun belleği (memory) üzerinden elde ederse, yine bellek üzerinden Session Key’i de elde edebileceği için kullanıcının parola özetini bilmese dahi ST biletini kullanabilmektedir. Saldırgan bu bilet expire olana kadar bilet içerisindeki servise erişebilir. Ayrıca bilet içerisindeki servis ismini değiştirerek hedef sunucu üzerindeki diğer servislere de erişim sağlayabilir. Bu saldırı yöntemine de Pass the Ticket adı verilmektedir.

4. Bir saldırgan servis hesabının NT parola özetini ele geçirebilirse TGS-REP mesajı içerisinde iletilen ST biletini domainde var olan veya olmayan herhangi bir kullanıcı için oluşturabilmektedir. Bu sayede de yetkili kullanıcılar için ST oluşturabilmekte ve bu servis hesabının yönettiği servislere erişebilmektedir. Bu saldırı yöntemine de Silver Ticket adı verilmektedir.

Kerberos AP-REQ Paket İçeriği

İstemci, erişmek istediği servis için gerekli ST’yi de aldıktan sonra artık bu bileti kullanarak servise erişebilecektir. İstemci bu amaçla, servisin çalıştığı sunucuya servis hesabının parola özeti ile şifrelenmiş ST’yi ve ikinci Session key değeri ile şifrelenmiş zaman damgasını göndermektedir. Servis ilk parçayı kendi parola özeti ile şifrelendiğinden deşifre eder ve içerisindeki bilgileri kontrol eder. Ayrıca bu parça içerisindeki Session Key değerini kullanarak ikinci kısmı deşifre eder ve gerekli doğrulamaları yapar. Bu aşamadan sonra servis, kullanıcının servise erişim yetkisinin olup olmadığını kontrol ederek istemciye gerekli cevabı dönecektir.

Kerberos AP-REQ Paket İçeriği

AP-REQ isteği Wireshark ile incelendiğinde 1 numaralı kısımda TGS-REP aşamasında elde edilen ST biletinin bulunduğu görülmektedir. Enc-part içerisindeki tüm veri bir önceki pakette alınan verinin birebir aynısıdır. 2 numaralı kısımda ise ikinci Session Key ile şifrelenmiş zaman damgası içeren doğrulama verisi bulunmaktadır.

1. Başarılı bir şekilde araya girme saldırısı (Man in the Middle) gerçekleştiren saldırgan kurbanın AP-REQ mesajını ele geçirebilir ve bu paket içerisindeki servis kullanıcısının parola özeti ile şifrelenmiş kısma offline olarak brute-force saldırısı gerçekleştirebilir. Eğer servis kullanıcıların parolaları basit ve şifreleme algoritması görece zayıf ise saldırganlar plain-text parolaya ulaşabilirler. Bu saldırı da ele geçirme yöntemi farklı olsa da sonuç olarak Kerberoasting saldırısıyla aynıdır.

Bu aşamada sunucu istemciye kimlik doğrulama ve yetkilendirme sonucu hakkında geri bildirimde bulunur. Bu paket içerisinde ikinci Session Key ile şifrelenmiş zaman damgası, sekans numarası ve benzeri birtakım veriler bulunmaktadır. Bu adım Kerberos kimlik doğrulamasının tamamlanması için zorunlu değildir.

Kerberos AP-REP Paket İçeriği

AP-REP paketi incelendiğinde şifrelenmiş kısım ve kullanılan şifreleme algoritması görülebilmektedir.

Bu blog yazımızda Kerberos protokol adımlarını ve her adımda gerçekleştirilebilecek saldırı yöntemlerinden bahsettik. Bir sonraki yazımızda ise Kerberos Protokolünü biraz daha detaylı inceleyerek bilet türlerini, PAC doğrulamasını, domainler ve forestlar arası Kerberos adımlarına değineceğiz. İleriki aşamalarda da delegation yöntemlerini, delegation kullanımı sırasındaki Kerberos adımlarını ve Kerberos ile ilgili tüm saldırı yöntemlerini saldırı, önleme ve tespit perspektifiyle analiz edeceğiz.

• https://web.mit.edu/kerberos/
• https://datatracker.ietf.org/doc/html/rfc4120
• https://www.secureauth.com/blog/kerberos-delegation-spns-and-more/
• https://www.tarlogic.com/en/blog/how-kerberos-works/
• https://improsec.com/tech-blog/asreqroast-from-mitm-to-hash