Common Attack Scenarios on Corporate Networks: Analyzing Hacker Strategies

Breaching the Perimeter

To breach the external perimeter, an attacker must gain access to a node that is also connected to the internal network and be able to execute arbitrary code on it. The vulnerabilities that most commonly lead to this can be categorized into six main types:

• Weaknesses in account and password management
• Web application vulnerabilities
• Flaws in traffic filtering
• Shortcomings in vulnerability and update management
• Poor user awareness regarding information security
• Improper configuration and access control issues

In certain penetration tests, each of these points allowed us to achieve our goal without using other attacks. Sometimes, to breach the perimeter, we combined the listed methods, which only increased the complexity of the attack rather than preventing infiltration.

Scenario 1: Credential Brute Forcing

Management and Remote Access Interfaces

Remote access protocols simplify the work of a system administrator by allowing them to manage devices from afar. Common tools include Telnet, RSH, SSH, and remote connection protocols like RDP. Administrators often use publicly available software such as Radmin, Ammyy Admin, and similar tools. This can enable external attackers to carry out credential brute-force attacks.

This type of attack doesn’t require any special knowledge or skills: in most cases, all you need is a laptop, a credential-cracking program like Hydra, and a dictionary, all of which can be easily found online.

An attack can be hindered by filtering IP addresses. In such cases, the attacker will likely look for alternative methods. For instance, they might compromise other nodes in the network and attempt to launch the attack from these compromised nodes rather than their own address. There are also other techniques to bypass filtering.

It’s not uncommon to find default credentials like root:root, root:toor, admin:admin, and test:test being used for SSH and Telnet. In some cases, you can even gain access with maximum privileges without needing to enter a password at all.

Remote Desktop Protocol (RDP) access typically involves using local or domain user accounts. Common examples include Administrator:P@ssw0rd, Administrator:123456, Administrator:Qwerty123, and a guest account named Guest with no password.

Protection Recommendations. For SSH, use private key authentication. Overall, we recommend configuring the firewall to restrict access to nodes via remote management protocols: allow connections only from the internal network and limit access to a small number of administrators. Additionally, implement a strict password policy to prevent the use of simple or dictionary passwords. If remote resource administration is necessary, we advise using a VPN.

Administration Interfaces of Web Servers and Databases

There are other services that, if accessed by an external intruder, could provide full control over a node. These include databases and web servers.

While SSH and Telnet typically require you to manually set a password from the outset, databases and web servers often come with default passwords. In practice, not all administrators change these passwords, and many opt for equally simple combinations when they do.

Examples of the most common credentials discovered during our penetration tests include:

• Databases — sa:sa, sa:P@ssw0rd, oracle:oracle, postgres:postgres, mysql:mysql, mysql:root, various combinations with an empty password;
• for Tomcat servers — tomcat:tomcat, tomcat:admin.

The Tomcat Web Application Manager allows files in the form of an archive with a .war extension to be uploaded. An attacker can upload not just a web application, but also a web-based command-line interpreter, gaining the ability to execute OS commands.

Access to the database also opens up a wide range of possibilities, including the ability to execute commands on the server with database system privileges. This might be sufficient to launch attacks on other nodes in the network.

For example, older versions of MS SQL Server were installed on the operating system by default with NT AUTHORITY\SYSTEM privileges, which are the highest in Windows. An attacker who managed to compromise the database account would instantly gain full control over the server.

In the current versions of MS SQL Server, this shortcoming has been addressed, and the database system privileges are restricted by default — NT SERVICE\\MSSQLSERVER. However, even these measures often do not provide an adequate level of protection.

Another potential attack vector involves exploiting vulnerabilities in the operating system. During one of our penetration tests, we discovered that the user NT SERVICE\\MSSQLSERVER has the SeImpersonatePrivilege, which allows it to use a impersonation token to assume the privileges of any other available user (for instance, by using the Mimikatz tool).

Protection Recommendations. Administrators should closely monitor the level of privileges used by various systems and users, and whenever possible, assign the least amount of access necessary.

We recommend implementing a strict password policy and restricting access to databases and web server administration interfaces from the internet. Allow connections only from a limited number of computers within the local network.

If remote access for web server administration is necessary, we recommend restricting the IP addresses that can connect, allowing access only from administrative computers.

Scenario 2: Exploiting Web Vulnerabilities

To execute operating system commands, it often isn’t necessary to crack login credentials for management interfaces. Vulnerabilities in web applications deployed within a company’s network frequently provide this capability. If a web application serves as a public resource (such as an official website, online store, or news portal), it means it is accessible from the internet. This, in turn, opens up numerous opportunities for attacks.

Some of the most dangerous vulnerabilities in web applications include arbitrary file uploads, SQL injection, and remote code execution. Exploiting these vulnerabilities can lead to a complete server compromise.

Here’s an example of a simple attack strategy that we often model during penetration tests. Most public web applications allow user registration, and these users generally have a personal dashboard feature for uploading content like photos, videos, documents, presentations, and more. Typically, the application checks the type of files being uploaded against a blacklist of prohibited extensions. However, these checks are often ineffective. In such cases, an attacker can upload a command-line web interpreter by simply changing the file extension. This could allow the attacker to execute OS commands with the web application’s privileges, and if these privileges are excessive, it could lead to full control over the resource.

Even if the server has effective file upload validation in place, the system’s configuration itself must also be taken into account. The following example illustrates how an administrator’s mistake can enable an attacker to compromise a resource.

The application under examination implemented a check that prohibited the upload of files with the PHP extension. We discovered a vulnerable combination of software and operating system on the server that allowed this restriction to be bypassed. Specifically, in the CMS Bitrix configuration, there was no limit set for uploading files with the extension .pht in the /upload/.htaccess file. This file format is executed as PHP on Debian and Ubuntu operating systems. Consequently, the server’s misconfiguration allowed the upload of a web-based command-line interpreter, circumventing the established restrictions.

Another common type of attack on web applications is through SQL injection. While it is not a very complex technique, it is far from trivial. The screenshot demonstrates an example of executing the ID command by injecting SQL statements in combination with exploiting a local file inclusion vulnerability.

To exploit such vulnerabilities, an attacker must know how to bypass file upload filtering on the server and be able to write SQL queries. However, these skills may not be necessary if there are no file upload restrictions at all.

Security Recommendations. In addition to enforcing a strict password policy, it’s advisable to implement whitelisting for files uploaded to the server. To protect against application code vulnerabilities (such as SQL injection and command execution), implement filtering of user-submitted data at the application code level. Additionally, consider using a web application firewall (WAF).

Scenario 3: Exploiting Known Vulnerabilities

Exploiting Vulnerable Protocols

Another example of exploiting traffic filtering vulnerabilities is an attack on the Java Debug Wire Protocol (JDWP), a component of the Java Platform Debug Architecture (JPDA). This protocol lacks authentication and encryption, which external attackers can exploit if the JDWP interface is accessible from the internet. An attacker can use a publicly available exploit for executing OS commands. Additionally, services using JDWP often have the highest privileges, allowing an external attacker to gain full control over the server in a single step. Below is an example of a successful attack using a publicly available exploit.

When simulating an attack on a server, we uploaded an exec.pl file with a backconnect script. We then changed the permissions to allow execution of this file. As a result, running the script provided an interactive shell, enabling the execution of OS commands to further the attack.

Recommendations for Protection. This example illustrates that a perimeter can be breached even when using complex passwords and regularly updating software. Debug interfaces should not be accessible from external networks.

Attacks on Vulnerable Software

According to our statistics, using outdated software versions is one of the most common security flaws. Generally, during penetration tests, exploiting software vulnerabilities that allow remote code execution is not conducted because such attacks (e.g., those targeting buffer overflow) can cause system denial of service. For an attacker, this is not only not an obstacle, but it can also be their primary objective. Here are some common examples of outdated versions of various systems and their vulnerabilities:

• Windows Server 2003 Service Pack 1 and Service Pack 2 (CVE-2012-0002).
• Nginx 1.3.11 (CVE-2013-2028).
• PHP 5.3.8, 5.3.28, 5.5.1, and many other versions (CVE-2014-3515, CVE-2011-3379, CVE-2013-6420).
• ProFTPD FTP Server 1.3.3a (CVE-2011-4130, CVE-2010-4221).
• OpenSSH Server 4.3 (CVE-2006-5051, CVE-2006-5052).
• Even Windows XP with a known vulnerability (CVE-2008-4250) can still be encountered today.

Exploiting such vulnerabilities often requires the attacker to have specific knowledge and skills, such as developing custom exploits. However, there are also publicly available and commercial exploits that can be used “out of the box” or adapted with minimal modifications to suit specific conditions.

In several projects, we demonstrated the exploitation of the critically dangerous Heartbleed vulnerability (CVE-2014-0160). If a service supports SSL connections or if a *nix-based operating system on the node uses a vulnerable version of the OpenSSL library, it will allow reading sections of the server process memory (in this example, a web server). Such memory sections may contain critically important data in plain text: user credentials, user sessions, access keys, and more. As a result of the attack and analysis of memory sections, a user’s password was obtained, among other things.

Protection Recommendations. To prevent such attacks, we recommend regularly updating your software and installing security updates for the operating system. Additionally, it is advisable not to disclose the versions of the systems in use—specifically, the version of the web server, which might be indicated in standard error messages or HTTP responses.

Scenario 4: Social Engineering

Social engineering is one of the most common methods of targeted attacks. It involves exploiting employees’ lack of experience in security matters. An attacker might extract access data by engaging in phone conversations or personal correspondence.

Let’s consider an example of social engineering in a phone conversation with an employee of a bank, whose staff awareness we needed to evaluate. The employee was chosen for the conversation based on the results of an initial phishing email campaign. This person was one of the recipients who not only clicked on the link in the email but also engaged in correspondence with an expert from Positive Technologies, mistaking them for an administrator of their corporate network.

Our expert posed as an administrator and offered to fix a broken link in an email newsletter. The phone conversation lasted about four minutes, which was enough time to achieve the goal—obtaining the user credentials for accessing the employee’s workstation and domain resources.

Our interviewee easily revealed not only information about the software being used but also their password, and even requested not to change it, as it was “convenient” (meaning simple). A potential intruder could not only gain access to the workstation and domain resources as this user but could also be confident that the employee would not change their password for a long time.

Naturally, not everyone is so trusting, and with this approach, there is a high risk that an employee might suspect foul play and contact the security team. As a result, attackers often employ more sophisticated social engineering techniques that require specialized training.

For example, to use phishing tactics, an attacker must register their own domain and create a fake login form. They need to make the phishing page closely resemble the design of the legitimate page that the employee is accustomed to seeing. The attacker also devises methods to identify the software versions used by the employee and then exploits any vulnerabilities in that software.

If an attacker aims to infect a workstation with a trojan, they need to identify the security systems used by the company, which requires additional reconnaissance. This significantly complicates the attack. However, as our penetration tests and real incident investigations have shown, social engineering attacks can be successfully executed in most modern organizations. In recent years, these types of attacks have become the initial step for cybercriminals in infiltrating the corporate networks of banks, government, and industrial organizations.

Below is an example of a phishing email used by Positive Technologies during several penetration tests in 2016. This email utilizes a domain that looks similar to a legitimate one. An attentive employee could easily spot the suspicious sender address. However, in practice, not all employees notice the discrepancy. Additionally, an attacker might spoof the sender’s address to match that of a real employee to avoid arousing suspicion. Opening the attached file and attempting to extract the archive as part of the penetration test merely resulted in sending information about the user and their software to the address specified in the phishing email. In a real attack scenario, however, the victim’s computer could be immediately infected with malware.

During an incident investigation, we uncovered a similar case involving a bank network breach using malicious software. The malware was distributed via email in an archive file, with phishing emails being sent from addresses belonging to employees of a partner bank that the victims had already communicated with. The addresses were spoofed by attackers who had previously conducted reconnaissance and studied the email communication patterns of the employees. It’s likely that the partner bank was also targeted in these attacks.

Protection Recommendations. Employees themselves can identify some attacks executed through social engineering methods. Vigilance is crucial here: always verify the sender’s address, avoid clicking on suspicious links, and do not open email attachments unless you are sure of their safety. Additionally, under no circumstances should you share your login credentials with anyone, including administrators and security personnel.

There are more sophisticated attack methods that are harder to detect. For instance, emails might appear to come from a trusted source. To protect against these threats, we recommend using antivirus solutions capable of scanning email attachments before they are opened by employees. Some antivirus programs allow you to place suspicious files in a sandbox to safely analyze their contents. We also recommend regularly conducting training sessions for employees to enhance their awareness of potential threats and subsequently evaluating the effectiveness of these sessions through tests, both internal and with external experts.

Scenario 5: Open Data

This method is not an attack by itself; however, experts at Positive Technologies often use it as a successful means to breach the perimeter, at least as a first step in carrying out other attacks.

Examining web application pages often reveals a wealth of valuable information that is publicly accessible: user accounts, software and server versions, addresses of critical systems, equipment configuration files, and in some cases, even the source code of web applications. Any external attacker can gain access to resources and upload arbitrary files without launching attacks on the system if they identify an account, such as for accessing a resource via the SSH protocol, connecting to a database management system (DBMS), or using the web application’s admin interface.

A domain account may also be found in open access. During one of the penetration tests, this allowed us to gain access to a wireless network, which provided a pathway to the domain controllers in the local area network. In another project, such an account opened the door to numerous corporate resources of the company accessible from the internet, particularly to the Jira system (the development of this attack vector is described in scenario 6).

The following example demonstrates how an attacker can exploit an application’s source code. In this instance, .svn directory files were found to be publicly accessible on the network perimeter. An external intruder could use tools like dvcs-ripper and Subversion to obtain the source code.

External penetration testing simulates the actions of a malicious actor conducting attacks without any additional knowledge of the target system (using the black-box method). However, if an attacker obtains the source code of a web application, they can perform an analysis using the white-box method, meaning they have complete information about the application. Code analysis can be conducted both manually and using widely available automated tools. This approach uncovers the maximum possible number of vulnerabilities and prepares exploits for attack.

Upon analyzing the files, we discovered that one of them contains the administrator account for the web application in plain text. Additionally, vulnerabilities were found that allow files to be read and uploaded to the server, providing the opportunity to gain full control over the resource, as demonstrated in previously described scenarios.

Protection Recommendations. System administrators should monitor the data disclosed on web pages and ensure effective access segregation to files and directories on servers accessible from external networks.

Scenario 6: Escaping the Sandbox

Typically, an organization’s network perimeter hosts public services—web applications accessible via HTTP and HTTPS protocols. However, some companies also place corporate resources, email services (OWA), portals, and other systems on the perimeter.

Let’s consider an attack scenario that began with obtaining a domain account in plain text from a publicly accessible page of a web application. As a result, this allowed access to a wide range of corporate resources on the network perimeter (see scenario 5).

Among such resources was the Jira system, which, when accessed by an external attacker, can reveal a list of all domain users. During our penetration test, we extracted this list and cracked the password of one of the domain users. The password was “P@ssw0rd”—one of the most common in corporate networks. In theory, this account could have been compromised directly by using this password to try different usernames until a successful login was achieved. This method is typically used in penetration testing to avoid account lockouts when trying to gain access to domain accounts. Although it wasn’t part of the attack scenario described here, it underscores the importance of paying attention to password policies and securely managing credentials.

We used the compromised account to access another of the company’s corporate resources available on the network perimeter, specifically the Citrix system.

Companies widely use Citrix for virtualization and remote access to applications, computer desktops, and servers from any device. With access to such a system, a user should not have the ability to exit virtualization and execute OS commands directly on the server where Citrix is installed. However, there are sandbox escape methods that malicious actors often exploit.

When running Internet Explorer in Citrix, an attacker can exploit the built-in file opening function. If there is no strict access control to files and directories set on the server, this browser function can grant access to the file system, including the OS installation directory. The attacker would then only need to launch the cmd.exe file to execute arbitrary commands. A similar attack vector can also be implemented using other software that includes a file opening function.

Protection Recommendations. We demonstrated how a vulnerability can be exploited due to inadequate access control to OS functions and files. An attacker could use applications to gain access to any files on the server. This represents a significant oversight in the resource’s administration.

To prevent such attacks, reconsider the placement of corporate resources on the network perimeter. If this is unavoidable, implement a strict password policy and enforce rigorous access controls to directories and operating system files. This ensures that users of systems like Citrix cannot access the server’s file system. They should not have execution rights or access to the OS installation directory. Access should be restricted following the principle of least privilege. Additionally, for running software on a Citrix system, it is recommended to use the secure TLS protocol with a check for the presence of a root certificate on the client side.

Gaining Control Over Corporate Information Systems

Attacks on internal network resources are generally carried out by two types of intruders: internal ones, who have access to a network port within the organization’s premises, and external ones, who have successfully breached the network perimeter. The model of an internal intruder can vary depending on the network segment from which the attack vector is developed, as well as the initial privilege level of the attacker.

If internet-based attacks don’t require additional network authentication (because the attacker has already gained a certain level of privileges on a compromised server within a specific network segment), then an insider must somehow gain logical access to the local network and privileges on one of the internal resources—unless, of course, the attacker is an employee who already holds such privileges.

The difficulty in advancing attacks from an insider largely depends on the network configuration and the network equipment. This includes segmentation, filtering of network protocols, and the network’s protection settings against unauthorized device connections. Unfortunately, not all organizations provide a reliable level of security at the network level.

Corporate systems are typically built on Active Directory domains. These systems are convenient and allow centralized management of even large, distributed network infrastructures. However, mistakes by administrators and regular users can make AD vulnerable. Experience shows that the most common weak spots are weak passwords and inadequate protection of privileged domain accounts.

The most straightforward and common network attack scenario involving Active Directory is a combination of two basic actions by an insider threat: obtaining local administrator privileges on a network node and running hacking tools on the compromised resource to acquire user accounts.

An attacker can exploit a local administrator account to obtain plaintext passwords. This vulnerability arises from weaknesses in the implementation of single sign-on (SSO) in all Windows systems that support this mechanism. The vulnerability exists because the Windows subsystems wdigest, kerberos, and tspkg store user passwords using reversible encoding in the operating system’s memory. Special tools, such as Mimikatz or WCE, are available to conduct such attacks and can be found publicly.

By sequentially repeating these steps across several nodes in a local area network, an intruder can reach the resource where the domain administrator’s account is active, obtaining access to it in an unencrypted form.

The two scenarios described below only differ in the method used to gain local administrator privileges in the first step. In total, we will examine seven of the most common attack scenarios. An eighth scenario could involve the exploitation of known software and operating system vulnerabilities, but these cases are less interesting from an exploitation technique standpoint (such as using a publicly available exploit, as shown in the image below). We will not address those in this article.

Scenario 1: Cracking Domain Account Passwords

In most corporate networks, password policies are configured for domain accounts, but they are often not effective. These policies frequently allow the use of common dictionary-based combinations. For instance, the password P@ssw0rd formally meets the required length and complexity criteria, but it is featured in most lists of popular passwords and is likely one of the first that an attacker would try. Dictionaries can also be used to guess more complex combinations.

Administrators often set limits on the number of incorrect password attempts, followed by locking the account. However, an intruder can attempt to guess one (or two) passwords for an entire list of logins—if they have information about them. Obtaining such data is not difficult: an internal perpetrator (an employee of the organization) can make a query to the domain controller or analyze the email client’s address book; an external intruder might study open sources on the internet (such as company publications, presentations, or contact information from the official website) or exploit vulnerabilities in data protection on the organization’s external resources.

Additionally, by understanding the method used to create logins, an attacker can develop a dictionary for guessing. Most often, the pattern is straightforward: the first letter of the first name and the last name of the employee (for example, DOMAIN\\AIvanov), initials and last name (DOMAIN\\APIvanov), and other variations based on the employee’s full name.

Such accounts often have local administrator rights on a computer or server. This allows an attacker to connect remotely (for example, via RDP) and run hacking software.

In these cases, the main obstacle for an attacker is usually the antivirus software, but it often isn’t configured effectively enough to withstand attacks. In our experience, this issue has appeared in nearly every project: either the antivirus doesn’t block the execution of hacking tools, or local administrator privileges allow for the antivirus to be disabled or for hacking tools to be added to the exclusion list.

Even if an antivirus program blocks the utility and the attacker cannot bypass this block, there are other options available for carrying out an attack. The attacker can simply run the utility from any publicly available online resource or create a memory dump of the lsass.exe process (using tools like procdump) and execute Mimikatz on their own computer. Additionally, there is a PowerShell version of this utility that is not detected by antivirus systems as malicious software.

By executing such an attack, the intruder gains access to the credentials of all users who have authenticated on the operating system. This may include local administrators of other computers as well as privileged domain accounts. This attack vector is used to gain full control over the domain.

Recommendations for Protection. In nearly every penetration test we’ve conducted, we’ve successfully completed this scenario. You can minimize the risk by enforcing a strict password policy for all domain users and limiting the privileges of local users on workstations and servers within the domain. For privileged accounts, we recommend using two-factor authentication. It’s important to note that two-factor authentication is also susceptible to attacks (see scenario 5).

Scenario 2: Attacks on Network and Data Link Layer Protocols

If obtaining credentials is unsuccessful or if the attacker cannot access the domain’s user IDs, the next step is to analyze the protocols used within the network. Specifically, they might execute man-in-the-middle attacks to intercept traffic, such as implementing an ARP Poisoning attack, or target protocols like NBNS and LLMNR to capture user IDs and password hashes.

During penetration tests, ARP attacks are conducted only with the client’s consent, as they are typically against such demonstrations due to the high risk of disrupting the network. Moreover, ARP Poisoning attacks are well-known, so let’s focus on attacks on other protocols.

Man-in-the-middle attacks can intercept Challenge-Response values for domain users. These intercepted values can be used to crack the user’s password, even without direct access to the system.

The NetBIOS Name Service (NBNS) and Link Local Multicast Name Resolution (LLMNR) protocols are used to obtain a node’s IP address when there is no record on DNS servers, or when these servers are unavailable for various reasons. Without protection for these protocols, LLMNR Spoofing and NBNS Spoofing attacks become possible.

An attacker on the same network segment as the targeted node can intercept NBNS and LLMNR broadcast traffic and spoof the address of the node where the targeted device is attempting to authenticate. If the attack is successful, the attacker could intercept and modify traffic within the network segment, as well as capture user authentication data to gain access to other nodes on the network.

Once an attacker obtains user identifiers and password hashes, they can attempt to crack the passwords by analyzing the hash values. Additionally, the attacker can use the user logins to escalate the attack as described in scenario 1.

The final stage of the attack (if credential guessing is successful) is similar to scenario 1 — connecting to nodes where the obtained account has local administrator privileges, and then running specialized hacking tools.

Protection Recommendations. If the mentioned protocols are not necessary, they should be disabled. If they are needed, implement preventive security measures—such as isolating systems that use one of these protocols into separate network segments. The methods for protecting against ARP Poisoning attacks are well-known: utilize static ARP entries on gateways, apply intrusion detection features (such as the arpspoof preprocessor in the Snort system), or tools like arpwatch. Additionally, use the Dynamic ARP Inspection feature on Cisco switches and other similar options.

Scenario 3: SMB Relay Attack

If a network utilizes NBNS and LLMNR protocols, it not only makes it possible for attackers to intercept users’ password hashes, but also enables the well-known SMB Relay attack. This method allows an attacker to capture authentication data transmitted between nodes during the NTLM Challenge-Response exchange.

The principle of the attack is simple: the attacker listens to network traffic and waits for one node to initiate a connection to another node. As soon as such a request is detected, the attacker performs a “man-in-the-middle” attack (for example, LLMNR Spoofing). They intercept the authentication request from the initiating node and pass it to the target server. This server responds with a request to encrypt a message using its hash, which is then redirected back to the node that requested the connection. Subsequently, this encrypted message is redirected. Because the message is encrypted with the correct hash, the target server will grant the attacker authentication access. The attacker authenticates on the server while sending a connection error response to the node that requested authentication. The attacker can carry out this type of attack even against the same resource that sends the connection request.

This attack has been known for a long time, and back in 2008, Microsoft released security bulletin MS08-068 along with a corresponding patch for Windows. On a patched system, an attacker cannot carry out the attack on the same computer if they initiate the connection. However, the ability to use SMB Relay to attack other nodes within the domain remains if those nodes do not implement SMB packet signing, known as SMB Signing.

To demonstrate the simplicity of implementing this attack, let’s consider an example from one of our penetration tests. While analyzing network traffic, we discovered that one computer periodically requests the address of another node and then sends an HTTP request using a domain account. Using the Responder utility, we successfully attacked the targeted network node by sending a connection request from the node that initially initiated the request.

On the compromised server, it was possible to execute commands with the privileges of the user whose authentication data was intercepted through an SMB Relay attack (in our case, the privileges were at the highest level). As a result, complete control over the server was gained.

The likelihood of such an attack is high. Large network infrastructures often employ automated systems for resource inventory, updates installation, backups, and other tasks. These systems connect to domain resources on a daily basis and could be exploited by attackers for malicious activities.

Protection Recommendations. To safeguard against attacks, it is essential to implement SMB packet signing on all network nodes and disable the NBNS and LLMNR protocols. Additionally, make sure to regularly install the latest security updates for the operating system.

Scenario 4: Reading Process Memory

To advance an attack within a local network, an attacker might leverage privileges obtained in the initial stages of the attack (such as in scenarios 1, 2, or 3), or they might already have elevated privileges if the attacker is a malicious employee. For instance, an attacker with local administrator privileges on a node can save a memory dump of the OS processes. Generally, the privileges of the user under whose name the processes were launched are sufficient.

Scenario 1 provides an example of how a dump of the LSASS process can be used, and here we will examine another application of this attack.

To securely store passwords, many administrators use specialized utilities. In this case, we conducted an attack that allowed us to obtain the access key to the files of the PINs program. These files contained passwords for many of the targeted organization’s critical systems. The images below demonstrate how a memory dump of the process PINs.exe was obtained using the publicly available utility procdump, and how the password a************1 was found within the dump.

As a result of the attack, the intruder gains access to a list of passwords and can use them to connect to critical systems.

Protection Recommendations. To carry out an attack, a perpetrator requires a certain level of privileges. If a process is run with local administrator rights, limiting the privileges of OS users can help protect against this. However, the attacker can still read the memory of processes running under such accounts (as demonstrated in the given example). Therefore, to protect yourself, it is crucial to first prevent unauthorized access to the OS. This requires strict password policies, regular software updates, and protection against account brute-forcing.

Scenario 5: Group Policies

This attack scenario is gradually losing popularity but still occurs. It involves situations where administrators use group policy files to change passwords for local administrator accounts.

Domain privileged users often create policies on the domain controller (in the sysvol directory) and include credentials in the group policy file, which is insecure. The password is encoded using an AES key; however, the encryption key is publicly available and published on the MSDN website. Consequently, an attacker with domain user privileges could acquire local administrator credentials for multiple network nodes.

Here is how password decryption works.

• dDPhfo*******************************ICtL64 — encrypted password. Equals signs are added to the right making its length a multiple of four.
• This string is decoded from its Base64 representation.
• The resulting string is decrypted using the AES algorithm with a key available from Microsoft.
• The recovered password is c******m.

For an attacker to carry out an attack using this scenario, they need access to group policy files. Such privileges might be held by domain users, or they can be acquired through the attack scenarios described in scenarios 1 and 2.

Protection Recommendations. The mechanism of changing local administrator passwords is commonly used in corporate networks, as it allows for password updates without requiring the administrator to connect to each individual node. In this context, it is advisable either to completely avoid this approach or to implement such policies only for a limited period, during which the passwords are changed, and to remove the policies immediately after the operation is completed. It’s important to consider the risks associated with network node compromise.

Scenario 6: Kerberos Golden Ticket

We’ve decided to highlight this attack as a separate scenario due to its extremely dangerous nature, although it requires initially obtaining a certain level of privileges. The attack is based on generating a Kerberos access ticket for a user using the NTLM hash of the krbtgt service account. This is possible due to specific characteristics of the Kerberos protocol architecture and Windows operating systems.

The Kerberos protocol is based on a ticket system, which provides access tickets to resources within the domain infrastructure. An intruder can create a golden ticket to obtain access at any privilege level and, consequently, can access domain resources with maximum privileges.

The attack is feasible only if the attacker possesses the NTLM hash of the krbtgt password, which can be obtained if the attacker has access to a current backup of Active Directory or has domain privileges that allow them to create such a backup (such as a domain administrator). If the attack is successful, it will be extremely difficult to detect the subsequent actions of the intruder using Kerberos authentication, and changing the passwords of accounts for which access tickets were generated does not offer protection.

Protection Recommendations. In the event of a successful system compromise, the progression of an attack can be prevented only by changing the password of the krbtgt user. This action is associated with restarting services that use domain authentication. However, it’s important to note that changing the krbtgt password alone does not eliminate the possibility of an attacker reacquiring the NTLM hash of the krbtgt password if they still retain their initial privileges.

To prevent such attacks, we recommend securing privileged accounts (specifically those that enable Active Directory backups), including the use of two-factor authentication, and ensuring the protection of directory service backups. Additionally, it’s crucial to protect workstations and servers from attacks using tools that capture credentials in plain text, such as Mimikatz.

Scenario 7: Pass the Hash and Pass the Ticket – Attacking Two-Factor Authentication

In the example above, we recommended using two-factor authentication to protect privileged accounts of critical systems, such as domain controllers. However, this does not mean that two-factor authentication alone completely safeguards against attacks. Rather, it is one of the necessary steps in building a comprehensive protection strategy for a corporate network. The following scenario demonstrates vulnerabilities in the two-factor authentication mechanism in Windows.

You can log into Windows using either a username and password or a smart card. The administrator can configure the system to require a smart card exclusively for access to the OS or to allow the user to choose their preferred method.

The principle of two-factor authentication means that a user must not only know something (like a PIN or password) but also possess something (in this case, a smart card with an installed certificate). Only by presenting the smart card with the correct certificate and entering the correct PIN can the user gain access to the operating system.

When a domain account is configured to require smart card authentication, the account is assigned a specific NT hash. This hash is generated randomly and remains unchanged during all subsequent connections to domain resources. During each authentication, the domain controller sends this hash to the node the user is connecting to.

The vulnerability lies in the fact that an attacker can obtain this NT hash and use it for authentication via the pass-the-hash method. In this scenario, the attacker no longer needs to possess the smart card or know its PIN, thus compromising the two-factor authentication principle. Additionally, given that the hash is constant, the attacker gains the ability to repeatedly target domain resources with the privileges of the compromised account at any time.

To obtain an NT hash, an attacker can use the results from running the Mimikatz utility on network nodes as part of attack scenarios 1, 2, or 3.

The above image shows the execution of Mimikatz on one of the nodes, and the next image demonstrates the result of a successful pass-the-hash authentication using the obtained user’s hash. This user was part of the server administrators group and had smart card authentication configured.

In addition to extracting the NT hash and the user’s password, an attacker can also obtain the smart card’s PIN code in plain text.

Essentially, if an attacker can run the Mimikatz utility on one of the nodes (either directly in the OS or using any suitable security bypass methods), they gain the ability to compromise privileged domain user accounts—even when two-factor authentication is in place. Windows authentication mechanisms are designed in such a way that even if the attacker cannot obtain an administrator account, they can still acquire an NT hash (generated by the domain controller when using a smart card) or a Kerberos ticket. While the NT hash remains unchanged, doesn’t expire, and can be used on any network node (including the domain controller), the Kerberos ticket is only issued for access to that particular node for ten hours and can be renewed for a week. Both of these can be exploited by an attacker to bypass two-factor authentication via pass-the-hash and pass-the-ticket attacks.

Protection Recommendations. Windows 10 includes a feature called Remote Credential Guard, designed to secure user accounts during remote access to resources. In our research, we have yet to encounter Windows 10 in corporate networks, indicating that studying its security will be a task for the near future. The implementation of Remote Credential Guard should significantly enhance protection against pass-the-hash attacks.

Conclusion

The attack scenarios listed are just a portion of the techniques used in penetration testing. Some attacks on corporate networks are much more complex to execute, but they are based on the principles described here.

Our report aims to draw the attention of system administrators, cybersecurity team members, and their managers to the fact that attacks on their resources are quite predictable. Each of the scenarios described is based on exploiting the most common vulnerabilities, which can be mitigated by reconfiguring systems or using other methods that require minimal financial investment.

Here are the basic principles we recommend following:

• Implement a strict password policy;
• Protect privileged accounts;
• Increase employee awareness on information security matters;
• Avoid storing sensitive information in plain text;
• Limit the number of network service interfaces available on the perimeter;
• Secure or disable unused data link layer or network layer protocols;
• Segment the network and minimize user and service privileges;
• Regularly update software and apply OS security patches;
• Conduct regular penetration testing and vulnerability analysis of perimeter web applications.

It’s important to remember that the difficulty of compromising resources heavily depends on whether the approach to security is comprehensive. Expensive security measures can become useless if users and administrators rely on dictionary passwords. We’ve encountered numerous cases where a single user’s dictionary password allowed an attack to escalate to full control over the entire corporate network infrastructure. Once an attacker gains local administrator privileges on a workstation or server, they can advance the attack, even with antivirus software in place. Only with a comprehensive security strategy can the investment in costly security measures truly be justified.