Scanning Lab


In this lab, I needed to scan the 10.50.96.0/23 netblock to find all the live hosts and then enumerate which operating systems and services were running on them. The above picture shows that there were two subnets.

I started by using nmap to scan the netblock using ICMP ping and timestamp packets. I then scanned again using nmap's half-open SYN scan. Next, I scanned the most common UDP ports.




Next, I scanned the netblock again using port 53 as the source as well as the destination port. This is because sometimes machines are set up to only allow data coming from specific ports. This means that sometimes DNS requests will only be accepted from port 53. Using this method, I discovered one more host @ 10.50.97.25


My next job was to compile a concise list of live hosts based on the previous scans. I noticed as I was doing this that the hosts on the 10.50.96.0/24 subnet did not respond to the TCP packets, though they had responded to the ICMP traffic.


I then broke the next part of the enumeration into two main parts. I first of all scanned all the ports for a machine and saved the open port numbers as a variable and then into a .txt document. I then did a full service scan along with running OS discovery and default scripts for each open port on the machine. In this way, the process of service enumeration was faster than running the aggressive scans against every port. I noticed that the machines on the 10.50.96.0/24 subnet did not return any ports as being open when scanned in this way. This reinforced what I had discovered earlier and suggested that they were behind a firewall.




In order to attempt to scan the machines on the 10.50.96.0/24 subnet, I used hping3 to try to find a zombie machine in the 10.50.97.0/24 subnet.

I found that the machine @ 10.50.97.10 was not active on the network. This was easy to tell as the IPID number for each packet only increased by 1 whereas on the other machines I tested it increased by more than 1




Now that I had found a zombie machine, I was able to spoof its IP address and send packets to machines on the 10.50.96.0/24 subnet then observe the IPIDs on the packets of data I was receiving back from packets I was sending to the zombie machine. For some ports on some machines, the IPID only increased by 1 each time, which let me know that the remote machine on the 10.50.96.0/24 subnet was either closed or filtered as it had not sent a SYN / ACK packet back to the zombie machine in response to the spoofed packets. On some ports on some machines, the IPIDs increased by more than 1. This allowed me to deduce that those ports were open to connections from the zombie machine because it was likely to be sending RST packets of data in reply to the SYN / ACK packets which the targeted 10.50.96.0/24 machine was sending to it. This happens because the zombie machine is not expecting a SYN / ACK packet as it did not send a SYN packet - my attacking machine did but by spoofing the zombie machine's IP address.





To finish this lab, I wrote up a brief summary of my findings along with a document which listed clearly all that had been ascertained during the scanning.




Popular posts from this blog

Hacking Year of the Owl (thm)

Image
NOTE: I am currently migrating my writeups and cybersecurity notes to  my github This writeup can be found in a new and shiny form at puzz00 year of the owl writeup  --- The Year of the Owl is a machine by MuirlandOracle on tryhackme   We start by using nmap to scan the TCP ports. The results show us that this appears to be a windows machine because we see netbios on port 139, SMB on 445 and winrm on its default port of 5985. We take a closer look but don't find much of interest. Since SMB is running, we can try a null session attack, but this does not work. We cannot connect using rpcclient without valid creds, either. Web app enumeration does not reveal anything of interest, so I have not included it in this post. We need to find another way to enumerate usernames and potential passwords. We can try common UDP ports using nmap. The results come back in the open|filtered state which is not very useful. We do not know if the ports are open or if the UDP datagrams are bei...
Read more

Hacking Reset (thm)

Image
  NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to  my github - my reset writeup can be found here     Reset is a fun active directory based box on thm   We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.    Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authentica...
Read more

Simple CTF (tryhackme)

Image
  I started with a quick SYN scan of all ports on the target machine. The -T4 flag speeds up the scan from the default -T3 and the -p- flag specifies all ports to be scanned. As can be seen from the results, ports 21, 80 and 2222 had services listening on them. It was now time to take a closer look at those three ports, so I used the -A flag with nmap to find out more. The anonymous login allowed using FTP on port 21 seemed interesting, so I connected to it in passive mode using the username anonymous and no password ftp -p 10.10.179.144 The connection was successful, but I could not get any listing of the directories or files using ls so I turned my attention to port 80 by navigating to the home page in my browser. I was greeted with a default Apache "It Works!" page. I then checked the robots.txt file and fired up a directory buster. I used gobuster as it is fast, but dirb, dirbuster or a home-grown one would also do. The /simple directory stood out as interesting, so I na...
Read more