kafre02

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."