From the Dark Web data to domain controller access

From the Dark Web data to domain controller access

In previous articles, we have discussed what the dark web is and what data we can find there. Now we look at what could be a real attacker’s next steps based on the obtained organization’s data. Data that is sold on the dark web mostly comes from attacks on organizations where ransomware was used and the organization has been rejected to pay “ransom”. This resulted in disclosing the data that can get into attackers’ hands who know how to exploit them.

1. How an attack typically begins?

In most cases, the initial attack vector is a phishing or targeted spear-phishing campaign. However, many attackers achieved the initial penetration through purchased login data, such as access to workstations via RDP or to VPN using an obtained certificate and login data. If this option has failed, an attacker still has an opportunity to attack outdated or vulnerable versions of software components, operating systems, etc. Moreover, files about the companies often contain a detailed overview of the systems located not only in the internal network.

As an example, we can mention actively exploited vulnerability located in SSL VPN FortiGate (CVE-2018-13379) or Pulse Connect Secure (CVE-2019-11510). The first, Path Traversal / Arbitrary File Read¹ vulnerability allows an attacker without login to download FortiOS system files using special HTTP requests. By obtaining the file “sslvpn_websession”, the attacker has access to the login data with the passwords stored in plain text format.

2. How an attacker proceeds ?

In this phase, we assume that the attacker managed to successfully penetrate into a network or a system, from which he continues spreading, we are talking about lateral movement across the infrastructure. Based on attacker’s motivation, it can be assumed that he will attempt to take over as many systems as possible, including the domain controller, to gain sensitive data, infrastructure details, and finally to encrypt these systems to convince the organization to pay ransom.

In case, that operating system running on machines is Windows, attacker can use POC Exploit for the vulnerability “PrintNightmare” tracked as CVE-2021-1675 published only a few days ago. A user account with standard privileges can execute malicious code on a remote server where Windows Print Spooler service is running. This service is started by default. Moreover, the vulnerability does not apply only to workstations where Windows is running, but also to Windows Server, i. e. domain controllers are also vulnerable.

In case, that systems are fully updated and Windows Print Spooler service is turned off, attacker can try enumerate Active Directory environment, users, groups, equipment, intra-forest and inter-forest trusts or other useful information for creating a functional attack vector. For such enumeration attackers often use PowerShell and built-in commands in module “Active Directory module for Windows PowerShell”.

A few useful commands:

• Domain controller enumeration: Get-ADDomainController

• Domain workstation enumeration: Get-ADComputer -Filter * -Properties *

• AppLocker policy enumeration: Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections

• Forest trust enumeration: Get-ADTrust -Filter *, Get-ADTrust -Identity <domain name>

Of course, the attacker does not use only manual enumeration but also automated using tools such as BloodHound². The attacker can access the domain controller with just one acquired user account, if this environment is poorly configured or the user has higher privileges as needed. BloodHound uses graph theory to detect hidden relationships and attack paths in Active Directory.

Useful commands to obtain data for analysis using BloodHound:

In case that data collection via SharpHound is initiated using the switch stealth, the results are considerably limited because SharpHound limits the number of systems it will access to.

SharpHound.exe --CollectionMethod Session --Stealth 

The switch CollectionMethod marks those systems that will be targeted. More options are: Default, All, DCOnly, ComputerOnly, Session, LoggedOn, GPOLocalGroup, LocalAdmin, LocalGroup, RDP, DCOM, Group, Trusts, LoggedOn, ACL, ObjectProps and PSRemote.

When using Session, it is also recommended to use the switch loop, if data collection is not initiated using the Stealth switch. Network scanning with a focus on user sessions will mostly allow us to get only something between 5 and 15 percent of current sessions. Therefore, this switch ensures that the collection runs in loop while we can also determine duration of the data collection using the LoopDuration switch.

PowerShell variant exists in addition to the executable file

Import-Module .\SharpHound.ps1  
Invoke-BloodHound -CollectionMethod all -Stealth 

In case that data collection in Active Directory takes place on a system that is not connected to the domain, such collection can be achieved within two steps. The first, configuring the system’s DNS server to route to the IP address of the domain controller in the targeted domain. The second step is launch of the command line (cmd.exe) as a domain user via runas.

Example

runas /netonly /user:TEST.LOCAL\John cmd.exe  
SharpHound.exe -d TEST.local 

After the data collection has been successfully performed, the attacker uses BloodHound capabilities to analyze and reveal bad configurations. As we can see in the figure below, the pre-built options of the tool are very extensive. In addition to these options, we can make our own queries by clicking on the Raw Query option at the bottom of the tool’s GUI.

The information about the imported database is shown in the figure below. The database contains 509 sessions, 501 users, 508 groups, 501 computers within 1 domain TEST.LOCAL.

In this point, the attacker has most of the essential information about the domain to start with running the queries and move to the following stage of his attack.

In the figure below, we can see the result of the query “Find Principals with DCSync Rights”. However, let’s start with some details about what are the DCSync rights and what is the DCSync attack. In fact, DCSync is harmful replication of directory services. Replication of the Active Directory is a process when changes made on one domain controller synchronize with all the other domain controllers. Attackers with the necessary privileges may initiate a replication request that allows them to load data stored in Active Directory, including passwords (hashes). These privileges are “Replicating Directory Changes” and “Replicating Directory Changes All” and we can find them in BloodHound as GetChanges and GetChangesAll.

Sufficient privileges are needed to perform this attack. Typically only administrators, domain administrators, enterprise administrators or members of the Replicator group have them. That is why attackers need more time to perform this attack, but there are still other options they can utilize in a shorter period of time.

[email protected] is a member of DOMAIN CONTROLLERS and ENTERPRISE DOMAIN CONTROLLERS, while having privileges GetChanges and GetChangesAll.

Attackers encounter another possible attack during enumeration of the Active Directory environment when they will again focus on privileges, namely unconstrained delegation³. Delegation is an Active Directory function that allows a user or a computer to impersonate another account. Unconstrained delegation can be enabled by domain administrators and users granted with SeenAbleDelegationPrivilege, and that by checking the “Trust This Computer for delegation to any service (Kerberos Only)” in the Delegation tab in Active Directory Users and Computers (ADUC).

There are already several attacks connected to unconstrained delegation. In one of the most famous scenarios, an attacker will gain access to a computer with lower privileges in the first step, and then pull all tickets from the computer via Mimikatz using the command “sekurlsa::tickets /export”, while at least one of them contains administrator or domain administrator privileges. How is it possible? In case a computer has allowed unconstrained delegation and a domain administrator access to this computer, e. g., via CIFS (Common Internet File System) to a shared folder, the TGT ticket will remain in memory. This TGT ticket can be then very easily obtained and exploited for obtaining privileged access.

3. Persistence

Once an attacker controls multiple systems and gained higher privileges, he needs to develop persistence. This will allow him to slower exfiltrate data and increase his chances to keep access to the victim’s infrastructure. There are several ways to develop persistence that mainly depend on options available to the attacker. This means, e. g., a scale of infrastructure he occupies, how long he needs access, what protection is deployed and more.

Golden Ticket - this ticket allows an attacker in Active Directory to gain unlimited access. This approach is based on the password (hash) of the user krbtgt. Once the attacker gains control over the domain Key Distribution Service account (krbtgt) and has an NTLM hash representation of krbtgt’s password, he can create the golden ticket.

Prerequisites for creating a TGT ticket

• Domain name

• SID

• NTLM password (hash) of domain KRBTGT account

Commands for creating the ticket via Mimikatz

Command execution on DC

Invoke-Mimikatz -Command ‘”lsadump::lsa /patch”’ -Computername target-dc 

Command execution on any workstation

Invoke-Mimikatz -Command ‘”Kerberos::golden /User:user_name /domain:domain_name /sid:sid_value /krbtgt:hash /id:id_value /groups:group_number /ptt”’ 

Other options to develop persistence by attackers are:

• Permitting RDP protocol - this gives an option to the attacker to access the computer from anywhere if the computer is accessible from the internet.

• Scheduled task / Harmful service – e. g., to add a user into the administrator group

• Shadow credentials - If an attacker compromised an account that has delegated rights to a user account, we can easily reset his password or we can set the SPN or deactivate Kerberos Pre-authentication to be less noisy. To do this, it is necessary to have an account with delegated rights to modify the msDS-KeyCredentiaLink attribute for the user or machine account, to apply for its TGT.

• Fake domain controller account - an attacker creates a “fake” machine account of a domain controller in AD and then adjusts the value of userAccountControl to 8192 to make Active Directory think it is a legitimate domain controller. Accounts with DS-Install-Replica in the domain root object can add this value to the machine account.

Conclusion

Summary of events

It all started with searching for data on the dark web, especially organizations that have been victims of hacking attacks in the recent or distant past. At this point, the attacker gained an overview of their infrastructure, the way they were compromised and began to choose a target. The first intrusion occurred through purchased access to VPN and workstations, while other intrusions could occur through the use of public exploits on deployed vulnerable versions of VPN hubs or through a spear-phishing campaign.

Once the attacker gained access to the network, he began to escalate his privileges. He was then able to take advantage of current vulnerabilities such as: PrintNightmare, PetitPotam or SeriousSAM (HiveNightmare) and the publicly available Proof of Concept exploits. He could also use Active Directory environment configuration errors to escalate privileges, including: the same passwords across systems (the ability to use a Pass the Hash attack), service accounts with weak passwords, open network drives, legacy or obsolete systems, and more.

The attacker then maintained access to the network and devices through various persistence options. At this stage, he extended his approach to other devices using lateral movement techniques. Finally, the data from the organization was exfiltrated and all stations to which the attacker had access were encrypted.