Forensic Blogs

An aggregator for digital forensics blogs

by

Automated Network Scanning + Final Experience

With our time here and finals week approaching fast, we are working to tie up all loose ends. Our final report is now complete, and we’ve done as much as we can with our scanner. The script scans the network, prints out some information, and sends it to an email address. We only got around to collecting the ports and services hosted on the network. If we had more time, we would have added more features, like OS detection or complete automation. As it is, we only managed to get the basics complete in time.

 

This is due to both a lack of time, and the many obstacles encountered throughout the course and scan of our project. If we had started with more experience, we would have been able to finish much more than we did. We spent a good amount of time figuring out how to actually use the tools instead of working on the project itself. In the end, we were unable to do as much as the other teams. Naturally, we are now much more experienced than we were at the start. Our work here at the LCDI has taught us a lot, and it has been a very positive experience for both of us.

 

Moving forwards, our primary goal is to wrap up last-minute objectives. First among these will be editing our final report once the Tech Writers have reviewed it for more time. This will more than likely take up our final shifts. Once we’ve completed this task, we will be all but done with our project.

The post Automated Network Scanning + Final Experience appeared first on The Leahy Center for Digital Investigation.

by

Automated Network Scanning % Success Over Error

Network Scanning Wrap Up Now That We’re Done

Welcome to the final installment of the Automated Network Scanning % team’s official blog. Our project is now over. The final tweaks are being made to our script, our scans are all shut down, and our team is beginning to finish their internship hours. A lot has happened since our last blog. We spent the majority of November running our scanner against different targets. The results we received from these scans were helpful in deciding what changes to make to our script. Despite our progress made on the scanner, there are a few things we could have done to make it better, if time permitted.

Testing Our Scanner

To test our scanner, our team used a combination of our VM, Pi, Pi network, and LCDI network. We began by targeting our Pi network that we made last month. First by running our scan on the VM. Then we believed that the superior power of the VM would make the scan run faster. Once we confirmed this, we would use our Pi scanner on the network. Our first scan was a smashing success. We used our VM to scan our pi network and it found all the servers we installed on the Pis. Now that we knew our script worked, we scaled up by testing our scan against the LCDI network.

The LCDI network scan performed without any errors. Our only issue was that it took too long. We made some improvements to the script that we believed would speed it up and then reran our test. This time the script worked much faster. This gave us much more confidence in our script, so we moved onto scanning off of our pi. As predicted, this scan was slower than the previous, but not beyond the realm of useable.

Error again

At this stage we decided to make another improvement to our scanner. We wanted to make our Pi run the script for the scan on boot. This meant that as the Pi was turning on ,it would automatically run our scanner. This process turned out to be more difficult than we thought, but eventually we got it working. In the meantime, we ran two more scans of the LCDI network that also worked. After these tests, the team felt comfortable to say our scanner worked without error.

Test results

The results that our scanner got were exactly what we were hoping to get. The first scan of the Pi network finished in 19.05 seconds. The scan found our ssh server, our http server, and both of the ports needed for our file server. We reran this scan to confirm our results and found that indeed our script worked. We then moved on to scanning the LCDI network. Our first scan of the LCDI network took 4 hours 25 minutes and 48 seconds. After adding our improvements, the scan only took 2 hours 28 minutes and 48 seconds. The three scans we did from the Pi averaged out to taking 3 hours 58 minutes and 48 seconds. This met our goal of being under four hours for a scan.

The picture above is a screenshot of the results from our third scan. The host IP’s and MAC addresses have been removed for security purposes. Using our scan results, we were able to identify multiple things about the LCDI network. The first thing we saw was the locations of both of the LCDI subnet’s. We also found a few IP’s that are up but not running any services.

What else could be done

The team is very happy with the work we have done here at the LCDI, but if we had some more time there are a few things that we would have improved. First, we would attempt to make the scanner faster. We met our goal of being under four hours, but we could still do better. We have some ideas of how to do this, like splitting the IP’s up into smaller groups and scanning these groups. Another improvement we would’ve liked to make was automatically identifying aspects of a targeted network. We could have coded in a function into our script that automatically identified subnets based off of our scan results. We also could have a function that identified IP’s that are up but not running any services, and give reasons as to why this is happening.

However, over all, our project was completed successfully.

The post Automated Network Scanning % Success Over Error appeared first on The Leahy Center for Digital Investigation.

by

Network Scanning + Update 2

Introduction

As November comes to a close, we are nearing the end of our project. With the script complete, all we have left to do is finish up a final report and a few more scans. Due to some yet to be solved bug in our code, the script fails when run from the physical Pi. As a temporary workaround, we’ve been scanning solely from our virtual machine, or VM. Our team is doing their best to solve this problem before the end of the week.

Problem Solving

Due to time restrictions, we were unable to automate our script. However, this is not really a setback, as all we have to do is manually start the scanner. So while this is not desirable, it is in no way a catastrophe. Of course, if we had more time, our team would have found a way to automate our script, and add other features. The ability to utilize WiFi, while not necessary, would make our scanner much more convenient to use. A cleaner looking output would have also been a nice touch. Most of the features we would have added are superficial, and only serve to add convenience.

As for the bug in our script, we so far have no idea what is causing it. The scanner starts correctly and runs for a couple of hours before shutting down. There is no output on the console and no printed report. This has happened to well over five scans. Since we’ve encountered this issue, we have been unable to get a scan to run properly on the physical Pi. However, the script runs perfectly on the VM so we’ve been using that for scans instead. Other than trying to solve this, most of our time and energy is going towards our final report.

Conclusion

We have spent most of November in the home stretch of this project. From completing our script to working on the final report, we are wrapping up rather nicely. We did encounter an issue with running our script on the Pi which set us back, but we’ve managed despite the issue. While we are attempting to fix it, we will not be at a complete loss in this project if our attempts are unsuccessful.

The post Network Scanning + Update 2 appeared first on The Leahy Center for Digital Investigation.