← Back Published on

Scanning for legacy systems

I stated off by scanning a company server network to detect the presence of hosts and determine their OS versions.

After my scan, I will use Metasploit Framework to refine the OS determinations.

Lastly, I research to determine the end-of-support timeframe for each identified OS.


                                                             Lets begin.

I ran an initial scan using nmap.  Scanning my network. Otherwise known as a ping sweep notice the /24 subnet.

The -sn option of nmap disables port scanning, It only performs the default host discovery function using a ping sweep by sending ICMP echo-request to each IP address in the targeted subnet.

I then went into scanning all the hosts found within my subnet and extracted the information into a file.

By default, nmap only scans the top 1000 commonly used ports

The -F option limits nmap to scan only the top 100 commonly used ports. This option is preferred when you don't know what you are specifically looking for, but you also don't want to waste a lot of time while timeouts expire for each closed port.

-The -sV option is known as a version scan in nmap. But it is also known as banner grabbing, service identification, and enumeration. It is a collection of queries to elicit a response from the expected default service on commonly used ports.

Many hosts were scanned as you can see by the syntax command, So i only included pictures from 1 snapshot.

I then went into a scan using metaspolit to confirm my findings on my nmap reaults. Using the auxiliary/scanner/smb/smb_version module.


A simple type of scanner built into msfconsole (metsapolit)


I did this for each of my hosts on that subnet and this is my final result.

We now have completed an initial scan using nmap with a confirmation and detailed scan using metaspolit.

How could we tell if these are Legacy systems? For this exercise, I did it the long and complex way with online research. 

If I was running in an enterprise environment of working as a security admin. I would have tools that could and will do this for me. Such as vulnerability scanners, alert systems, so on and so on…

For web research, we can use many tools. For windows, I simpy did a quick web search and was able to see the specs.

The link to the Windows end of life page is here: https://en.wikipedia.org/wiki/...

the 10.1.16.2 host running Windows Server 2016. This server being hosted is still good! Its end of support is 2027-01-12



As you can see, we have found a Legacy system. With the end of support being 2020-1-14. This is our host of 101.16.9 on out network (windows 7)

Now, lets search our linux distros
https://en.wikipedia.org/wiki/... 

I did the same type if research as our windows hosts for each host, and found that 10.1.6.14 is indeed a legacy system as well. As the OS version running on 10.1.16.14 is Linux 2.6.9-2.6.33

I did this for all of the hosts. A very lengthy process indeed.
For my debian hosts i used: https://en.wikipedia.org/wiki/... 

This is my updated lists of EOS

Like i stated before, this is for an exercise, in the production environment this would be used using a tool or even set for automatic scans and alert systems.

There are sometimes justifiable business reasons to continue using an EOL/EOSL system. These could include the cost to replace a system is to high or no other OS is compatible with a core business application.

However, steps must be taken to balance business needs with security best practices.

Since no new updates or patches will be forthcoming from the original vendor of the EOL/EOSL systems, additional layers of protection need to be applied.

This could include network segmentation isolation, physical isolation, stricter access control and authentication policies, more detailed logging and monitoring, as well as application-layer firewall ingress and egress filtering.