kafre02

you're welcome If you want any help editing your posts I'm more than glad to help you, since I'm going through right now the whole path. Love your content

You're laking the whole intro, which is pretty informative in my opninion This term introduces several protocols commonly used across networks: HTTP FTP POP3 SMTP IMAP These protocols form the foundation of how you browse the web, transfer files, and send and receive email. Understanding how they work at a low level is essential for anyone pursuing a career in cybersecurity, whether in penetration testing, network defense, or security engineering. Each protocol task is designed to show what happens beneath the surface, which is usually hidden by a GUI (Graphical User Interface). You will “talk” using the above protocols with a simple Telnet client to understand what your GUI client is doing under the hood. The purpose is not to memorise the protocol commands but rather to observe the protocol while it is working. Why Learn These Protocols Today? You might wonder why you are studying protocols that are decades old. There are several important reasons. First, these protocols are still in use. While most public-facing services now use encrypted versions (HTTPS, SFTP, IMAPS), the underlying protocol mechanisms remain the same. The commands you send over HTTP are the same HTTP commands, wrapped in TLS encryption. Second, you will encounter plaintext protocols during penetration tests and security assessments. Legacy systems, internal networks, IoT devices, and misconfigured services often still use unencrypted protocols. Recognising and exploiting these weaknesses is a core penetration-testing skill. Third, understanding the protocol helps you understand the attacks. When you know how SMTP works, you understand why email spoofing is possible. When you understand HTTP, web application vulnerabilities make more sense. This foundational knowledge makes you a better security professional. This room also discusses some of the insecurities inherent in these protocols. In particular, the focus is on passwords sent in cleartext. When credentials are transmitted without encryption, anyone with access to the network traffic can capture them. This was acceptable when these protocols were designed for trusted academic networks, but it is a serious vulnerability on modern networks. In the following room, Protocols and Services 2, you will explore how these protocols can be secured using TLS encryption, and examine attacks such as sniffing, man-in-the-middle, and password attacks in more detail. Prerequisites This room assumes a working understanding of TCP/IP, ports, and the client-server model. You should also be comfortable with the Linux terminal. If you need a refresher on any of these topics, complete the following first:

Whole "Ping" section in MD // The name ping comes from the sound of a sonar pulse. You send out a signal and listen for the echo to come back. In networking, the ping command does the same thing. It sends a small test packet to a remote host and waits for a reply. This simple exchange tells you whether the target is reachable over the network and whether it is online and responding. How Ping Works Ping uses the ICMP protocol (Internet Control Message Protocol). It sends an ICMP Echo Request packet (type 8). If the target receives the packet and is permitted to answer, it sends back an ICMP Echo Reply (type 0). This exchange is very lightweight and fast, which is why ping became the standard first check before spending time on more detailed scanning. Basic Usage On Linux and macOS, use the -c flag to specify the number of packets to send. bash ping -c 5 MACHINE_IP You can also ping a hostname, in which case DNS resolution happens first. bash ping -c 5 https[:]//tryhackme[.]com/ On Windows, the equivalent flag is -n. cmd ping -n 5 MACHINE_IP If you omit the count on Linux, ping runs indefinitely. Press Ctrl+C to stop it. You can force a specific IP version using the -4 and -6 flags. This is useful in dual-stack environments where a hostname resolves to both IPv4 and IPv6 addresses. On some systems, ping6 is available as a standalone command for IPv6. bash ping -4 -c 5 MACHINE_IP ping -6 -c 5 MACHINE_IPV6 Interpreting the Output: Successful Ping The following example shows a target that is alive and allows ICMP. bash user@AttackBox$ ping -c 5 MACHINE_IP PING MACHINE_IP (MACHINE_IP) 56(84) bytes of data. 64 bytes from MACHINE_IP: icmp_seq=1 ttl=64 time=4.812 ms 64 bytes from MACHINE_IP: icmp_seq=2 ttl=64 time=4.278 ms 64 bytes from MACHINE_IP: icmp_seq=3 ttl=64 time=4.941 ms 64 bytes from MACHINE_IP: icmp_seq=4 ttl=64 time=4.503 ms 64 bytes from MACHINE_IP: icmp_seq=5 ttl=64 time=4.845 ms --- MACHINE_IP ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4098ms rtt min/avg/max/mdev = 4.078/4.504/4.941/0.?? ms The target answered all five requests, confirming it is online and reachable. The 0% packet loss confirms a clean network path. The round trip time of approximately 0.5 ms is very low, indicating the target is likely on the same local network. The TTL (Time To Live) field deserves particular attention. Although “Time” appears in the name, TTL actually represents the maximum number of routers (hops) a packet can pass through before being dropped. Each router along the path decrements the TTL by one. The initial TTL value is set by the operating system, which makes it a useful indicator for OS fingerprinting. Linux typically uses a starting TTL of 64, while Windows typically uses 128. However, intermediate routers decrement this value before it reaches you. A TTL of 58 in response is likely indicative of a Linux system: it is six hops away, not a different operating system. Interpreting the Output: No Reply bash user@AttackBox$ ping -c 5 MACHINE_IP PING MACHINE_IP (MACHINE_IP) 56(84) bytes of data. From ATTACKBOX_IP icmp_seq=1 Destination Host Unreachable From ATTACKBOX_IP icmp_seq=2 Destination Host Unreachable From ATTACKBOX_IP icmp_seq=3 Destination Host Unreachable From ATTACKBOX_IP icmp_seq=4 Destination Host Unreachable From ATTACKBOX_IP icmp_seq=5 Destination Host Unreachable --- MACHINE_IP ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4098ms There are several common reasons for receiving no reply. The lab machine may be powered off, crashed, or still booting. A router or firewall along the path may be blocking ICMP requests. The target may be behind NAT that drops ICMP. Windows Firewall blocks ping by default on most versions. Corporate firewalls, cloud providers such as AWS, Azure, and GCP, and modem WAFs and DNS frequently block ICMP completely. Your network or machine may also be blocking outgoing ICMP. Quick Reference Result Most likely meaning Next step Fast replies, low or no packet loss Target is online and allows ICMP Proceed to port scanning “Destination Host Unreachable” Target is down or no route exists Check if the machine is powered on 100% packet loss with no error message ICMP is filtered or blocked Try TCP/UDP host discovery with Nmap High latency or packet loss Network congestion, long distance, or filtering Investigate the path with traceroute // Result Most likely meaning Next step Fast replies, low or no packet loss Target is online and allows ICMP Proceed to port scanning “Destination Host Unreachable” Target is down or no route exists Check if the machine is powered on 100% packet loss with no error message ICMP is filtered or blocked Try TCP/UDP host discovery with Nmap High latency or packet loss Network congestion, long distance, or filtering Investigate the path with traceroute

In the room, under subsection "Web browser" part "Transport-Level Basics" some info has been added: "Transport-Level Basics Browsers connect to TCP port 80 by default for plain HTTP, though this is now rare because almost all sites automatically redirect to HTTPS. TCP port 443 is the standard for HTTPS and is used by nearly all websites today. Many modern sites also support HTTP/3, which uses the QUIC protocol. QUIC is a transport protocol originally developed by Google that combines the functions of TCP and TLS into a single protocol running over UDP port 443. The result is faster and more reliable connections than traditional TCP+TLS. You can identify HTTP/3 traffic in the browser’s Network tab, where the protocol column displays h3. You can access services on standard ports by specifying them explicitly in the URL. For example, navigating to: https[:]//target[.]com:8443/ or: http[:]//192[.]168[.]1[.]100:8080/ will cause the browser to attempt a connection on that port. If a web server is listening, the page will load."

There's been an update, right at the end of DNSDumpster subsection "Certificate Transparency (CT) Logs The most effective passive subdomain discovery method today is Certificate Transparency logs, accessible through crt[dot]sh. Certificate Transparency is a public logging framework (mandatory since approximately 2015) that records every SSL/TLS certificate issued by participating Certificate Authorities. Each certificate contains a Subject Alternative Name (SAN) field listing the domains and subdomains it covers. By searching these logs, you can discover subdomains without sending any traffic to the target. To use crt[dot]sh, visit their site and search for %.[t]ryhackme[.]com. The % wildcard matches any subdomain. The results will list every certificate issued for subdomains of tryhackme[dot]com, often revealing 10 to 100 times more subdomains than DNSDumpster alone. crt[dot]sh is fully passive, operates in real time, and has no rate limits for basic use. Other passive subdomain discovery options include SecurityTrails (free limited searches) and command-line tools like Subfinder, which aggregate multiple passive sources. Defender perspective: Organisations monitor CT logs and subdomain lists to catch dangling DNS records (which carry subdomain takeover risk) or unauthorised subdomains."