Zombie Scans

 I had to find and use a zombie machine in this lab as the machines on the 10.50.96.0/24 subnet were protected from the public internet with a firewall which meant all ports returned a filtered state. I was able to find open ports on machines on the 10.50.97.0/24 subnet, however, and one of these allowed me to perform idle scans in order to enumerate the machines @ 10.50.96.0/24.


I first of all performed fast nmap scans in order to find live hosts on the entire netblock of 10.50.96.0/23. I did not use ICMP requests for this task as most firewalls and / or IDS drop ICMP requests from outside their own network. I therefore started with a half-open SYN scan:




I used the --open flag on this scan as I had lots of filtered ports come through and I wanted to focus in on the hosts with open ports.


Next, I performed a UDP scan of the ports on which common UDP services listen. I used the --open flag and the -V for version scans as once again I wanted to focus in on the hosts with open ports. One problem with UDP scans is that most ports return as open|filtered because it is rare for a UDP packet to be received in response to a UDP packet being sent. This is normal considering how UDP works. Tne -sUV flag includes a version scan which in turn helps nmap to better distinguish between open|filtered and truly open states. I set the --version-intensity to 0 as I wanted this scan to be fast as it was really only intended to find live hosts with at least some UDP ports open.




I did perform an SCTP scan using the -sY flag, but all the ports came back as either filtered or closed.


My next step was to combine all the IP addresses of live hosts with open TCP or UDP ports into a .txt file which could then be fed to further nmap scans. I used /open/ in the grep as this made sure that I grepped ports in the open state rather than the open|filtered state.




These initial scans did not take long and found nine live hosts. These IP addresses matched the ones found in the solution to the lab. The difference is that I used SYN and UDP scans rather than ICMP scans.


Next, I decided to filter the DNS servers into one .txt file. For this lab, further enumeration of DNS was not required, but I thought it would be good to find the DNS servers, anyway.




I now needed to enumerate the services and their versions listening on the open ports along with potential Operating Systems. I decided to use the nmap -A scan for this, but realised it would take hours if I ran it against all ports -p- This is of course best practice but for this lab I didn't feel it was necessary so I left the scan at the default top 1000 ports.




This scan gave me useful results regarding services and versions, but I wasn't fully convinced by its work enumerating the Operating Systems so I tried a different technique. I could of course have tried banner grabbing using Burpsuite or establishing connections with Netcat, but I wanted to use a different nmap scan:




The --osscan-guess flag used in combination with the -O and -v flags helped return better results (Microsoft Windows XP Service Pack 3 with 95% confidence on the example above).


I then ran a full UDP scan and found further open ports. In the example below, we can only see one of the machines. Other hosts scanned had ports 123 (NTP) and 137 (NetBIOS) open and listening.




It was now time to try to find an idle machine on the 10.50.97.0/24 subnet so I fired up hping3. I tried 10.50.97.10 first of all as it seemed the most likely machine to be idle (the others had services running which would tend to suggest more usage on the network). 10.50.97.10 was a good first choice as its IP fragmentation ID was only increasing by 1.




This is important as with an idle scan we need to be able to know if the zombie machine is sending a RST packet to the target machine in response to the unexpected SYN/ACK sent to it by the target machine if the port we are testing is open. This would happen because the zombie machine does not send the original SYN packet and therefore does not expect a SYN/ACK packet - this triggers the RST response which in turn increments the zombie's IPID by 1. We then send a SYN/ACK packet to the zombie to trigger a RST packet to be sent to our attacking machine. If we see that the IPID has increased by 2 instead of 1, we can deduce that the targeted port on the victim machine is open. This would not work if the zombie machine were active on the network and sending lots of packets of data as the IPID would be increasing in an unpredictable way.


I did check two other machines on the 10.50.97.0/24 network just to make sure that I was right in thinking they would be busy and therefore unsuitable for use in an idle scan. This was indeed the case, as can be seen from the increases in their IPIDs:





With a suitable zombie machine located, I launched an idle scan against the machines in the 10.50.96.0/24 subnet. I only checked those machines in my targets.txt file and I only checked common ports which would be used on an internal network. By doing this, I did find ports which were open to machines inside the network but blocked by a firewall to machines outside the network!


I needed to specify the open port of 135 to use on the zombie machine as well as the port I was targeting on the victim machine. Here is an example of an open port (135) where the IPID starts to increase by 2 rather than 1:





I did try a port which I was fairly certain would be closed (2231) just to make sure that the expected behaviour of having no increase in the IPID would be observed for closed ports. This did prove to be so:





I did try the nmap idle scan -iL but found it to be problematic and return false negatives. This was interesting, as it proved to me that sometimes a more manual approach (in this case using hping3 to monitor the IPIDs myself) is more effective than a more automated approach.







Popular posts from this blog

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

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

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