========================================
Click the Above Photo to View the Answers — — |
========================================

1. Scenario
2. Learning Objectives
3. Understanding Concept
4. Pre-Requisites
5. Challenge Tasks — Answers
6. Video Poc1 —https://youtu.be/1W8pJ6v5C04
7. Video Poc2 — https://youtu.be/OdKrRKAvnSg

McSkidy is unable to authenticate to her server! It seems that McGreedy has struck again and changed the password! We know it’s him since Log McBlue confirmed in the logs that there were authentication attempts from his laptop. Online brute-force attacks don’t seem to be working, so it’s time to get creative. We know that the server has a network file share, so if we can trick McGreedy, perhaps we can get him to disclose the new password to us. Let’s get to work!

• The basics of network file shares
• Understanding NTLM authentication
• How NTLM authentication coercion attacks work
• How Responder works for authentication coercion attacks
• Forcing authentication coercion using lnk files

Sharing Is Caring

We tend to think of computers as isolated devices. This may be true to an extent, but the real power of computing comes into play when we connect to networks. This is where we can start to share resources in order to achieve some pretty awesome things. In corporate environments, networks and network-based resources are used frequently. For example, in a network there’s no need for every user to have their own printer. Instead, the organisation can buy a couple of large printers that all employees can share. This not only saves costs but allows administrators to manage these systems more easily and centrally.

Another example of this is file shares. Instead of each employee having local copies of files and needing to perform crazy version control when sharing files with other employees via old-school methods like flash drives, the organisation can deploy a network file share. Since the files are stored in a central location, it’s easy to access them and ensure everyone has the latest version to hand. Administrators can also add security to file shares to ensure that only authenticated users can access them. Additionally, access controls can be applied to ensure employees can only access specific folders and files based on their job role.

However, it’s these same file shares that can land an organisation in hot water with red teamers. Usually, any employee has the ability to create a new network file share. Security controls are not often applied to these shares, allowing any authenticated user to access their contents. This can cause two issues:

• If a threat actor gains read access, they can look to exfiltrate sensitive information. In file shares of large organisations, you can often find interesting things just lying around, such as credentials or sensitive customer documents.
• If the threat actor gains write access, they could alter information stored in the share, potentially overwriting critical files or staging other attacks (as we’ll see in this task).

Before we can perform any of these types of attacks, we first need to understand how authentication works for network file shares.

NTLM Authentication

In the Day 11 task, we learned about Active Directory (AD) and Kerberos authentication. File shares are often used on servers and workstations connected to an AD domain. This allows AD to take care of access management for the file share. Once connected, it’s not only local users on the host who will have access to the file share; all AD users with permissions will have access, too. Similar to what we saw on Day 11, Kerberos authentication can be used to access these file shares. However, we’ll be focusing on the other popular authentication protocol: NetNTLM or NTLM authentication.

Before we dive into NTLM authentication, we should first talk about the Server Message Block protocol. The SMB protocol allows clients (like workstations) to communicate with a server (like a file share). In networks that use Microsoft AD, SMB governs everything from inter-network file-sharing to remote administration. Even the “out of paper” alert your computer receives when you try to print a document is the work of the SMB protocol. However, the security of earlier versions of the SMB protocol was deemed insufficient. Several vulnerabilities and exploits were discovered that could be leveraged to recover credentials or even gain code execution on devices. Although some of these vulnerabilities were resolved in newer versions of the protocol, legacy systems don’t support them, so organisations rarely enforce their use.

NetNTLM, often referred to as Windows Authentication or just NTLM Authentication, allows the application to play the role of a middleman between the client and AD. NetNTLM is a very popular authentication protocol in Windows and is used for various different services, including SMB and RDP. It is used in AD environments as it allows servers (such as network file shares) to pass the buck to AD for authentication.

Responding to the Race

There are usually lots of authentication requests and challenges flying around on the network. A popular tool that can be used to intercept them is Responder. Responder allows us to perform man-in-the-middle attacks by poisoning the responses during NetNTLM authentication, tricking the client into talking to you instead of the actual server they want to connect to.

On a real LAN, Responder will attempt to poison any Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Web Proxy Auto-Discovery (WPAD) requests that are detected. On large Windows networks, these protocols allow hosts to perform their own local DNS resolution for all hosts on the same local network. Rather than overburdening network resources such as the DNS servers, first, hosts can attempt to determine if the host they are looking for is on the same local network by sending out LLMNR requests and seeing if any hosts respond. The NBT-NS is the precursor protocol to LLMNR, and WPAD requests are made to try to find a proxy for future HTTP(s) connections.

Since these protocols rely on requests broadcasted on the local network, our rogue device running Responder would receive them too. They would usually just be dropped since they were not meant for our host. However, Responder will actively listen to the requests and send poisoned responses telling the requesting host that our IP is associated with the requested hostname. By poisoning these requests, Responder attempts to force the client to connect to our AttackBox. In the same line, it starts to host several servers such as SMB, HTTP, SQL, and others to capture these requests and force authentication.

If you want to dive a bit deeper into using Responder for these poisoning attacks, have a look at the Breaching Active Directory room.

This was an incredibly popular red teaming technique to perform when it was possible to gain access to an office belonging to the target corporation. Simply plugging in a rogue network device and listening with Responder for a couple of hours would often yield several challenges that could then be cracked offline or relayed. Then, the pandemic hit and all of a sudden, being in the office was no longer cool. Most employees connected from home using a VPN. While this was great for remote working, it meant intercepting NetNTLM challenges was no longer really viable. Users connecting via VPN (which, in most cases, isn’t considered part of the local network) made it borderline impossible to intercept and poison LLMNR requests in a timely manner using Responder.

Now, we have to get a lot more creative. Cue a little something called coercion!

Unconventional Coercion

If we can’t just listen to and poison requests, we just have to create our own! This brings a new attack vector into the spotlight: coercion. Instead of waiting for requests, we coerce a system or service to authenticate us, allowing us to receive the challenge. Once we get this challenge, based on certain conditions, we can aim to perform two main attacks:

• If the password of the account coerced to authenticate is weak, we could crack the corresponding NetNTLM challenge offline using tools such as Hashcat or John the Ripper.
• If the server or service’s security configuration is insufficient, we could attempt to relay the challenge in order to impersonate the authenticating account.

Two incredibly popular versions of coerced authentication are PrintSpooler and PetitPotam.

PrintSpooler is an attack that coerces the Print Spooler service on Windows hosts to authenticate to a host of your choosing. PetitPotam is similar but leverages a different issue to coerce authentication. In these cases, it’s the machine account (the actual server or computer) that performs the authentication. Normally, machine account passwords are random and change every 30 days, so there isn’t really a good way for us to crack the challenge. However, often, we can relay this authentication attempt. By coercing a very privileged server, such as a domain controller, and then relaying the authentication attempt, an attacker could compromise not just a single server but all of AD!

1. Start the TryHackMe’s VPN or Start AttackBox
2. Open Split Screen and Click View in Full Screen if Needed

1. What is the name of the AD authentication protocol that makes use of tickets?

Ans: Kerberos

2. What is the name of the AD authentication protocol that makes use of the NTLM hash?

Ans: NetNTLM

3. What is the name of the tool that can intercept these authentication challenges?

Ans: Responder

4. What is the password that McGreedy set for the Administrator account?

Ams: GreedyGrabber1@

5. What is the value of the flag that is placed on the Administrator’s desktop?

======================================================
Ans: Use your Skills and try to find this flag,

If you are unable to do so,

use the video below to find the answer
=======================================================