Scanning faults

I'm sure many know that scanning a network is only valid for so long. Many even understand the idea that you must leverage attacks in relative time to the results from scanning.

I bring these problems up because it seems few people discuss automating attacks and scans together. You get "lets automate this attack by using tools like metasploit" or "lets use nmap to scan the network" or occasionally "lets use nmap scripts or metasploit's db_nmap." But none of these solve the functional problem of incorporating the two unless you want to build your own nmap script. Thats the key point here: one time use scan and exploit python scripts by themselves suck, one time use scripts for nmap for a highly specialized cve sucks by itself. Surely there is a way to handle this better!

Well there are tools out there to help with this, but when it comes down to it, if it doesn't work the way you want it all the time, you will end up scripting your own anyway.

Nmap inside python, metasploit, whatever: its just a wrapper get over yourselves with you api shit.

Lets take a step back here:

Why do we need more automation and less artisan or design? Well, we don't. Companies do. Corporate nonsense wants you to run known tests first and foremost before exploring on your own. Going through pentesting training via sandbox environments, i find myself having to withhold from exploring because we know its known footholds then leverage until escalated. Every time. Going through some of this, i find myself building scripts to do trial scans before this. Making use of nmap and metasploit, and sometimes scapy, without the use of autopwn shit. why not autopwn? limitations, unable to track its own activities, etc... Example: If we know a version of ssh is available for collecting usernames from the system, yet the version is compiled to run on a different version than the os its expecting, autopwn will scan leaving just enough traces, but still fail. There is arguments of if this could be recoded and surely it could, but for the sake of moving forward without fucking up their project: what should we do? In this particular case, there is a python script that does partial connections to test then runs it and that's pretty sweet. But we need to accommodate a lot to be able to do this.

Why does timing matter much, just run more cycles? Well, no. On a network, almost any network, the state of the network is dynamic. hosts go up or down, hosts update or refresh kernel libraries, these things can and do happen all the time. For both corporate and criminal world, if you haven't seen this event where you get stage one, the service drops connection now its suddenly  a new version, then you have to restart, i would say lurk more. it happens more often than credit is given especially with docker, vagrant, and similar being available for home use. iot autoupdates, oh yeah that's a thing now too. lol

When looking to criminal hacking, we see many more scripts designed for this functionality and many often leverage proxies or web portals to manage and decentralize the issue. Several have custom scanners compare to nmap's detection then dumps results per host per port before moving on. This works splendidly for keeping the scanning times and the exploit times close enough to work. Fast scanning, rapid exploit? may end up noisy af. But proper slow scanning with rapid understanding of the results before entirely completed seems to work best.

So solutions? More than just bitching to be bitching?
  • nmap scripts are a valid start as the engine is readily available. My luck comes in from writing to file every detection as it comes in. Huge pain in the ass, still setup python script to read and parse as it comes in.
  • scripting metasploit: getting details from db_nmap isnt nearly as nice as actually running nmap, but the basics are there for version and os detection, apparently the preference on tutorials seems to be using nmap for port scanning aux scanners for everything else. Still, output waits until complete unless you want to read from file as new line comes in. automate inside msf? nope. just nope. aux or nmap or anything else, might as well make a bash script to start monitoring script, then have it start your scans. you handler script may want to leverage more nmap scripts or more modules or other scripts (searchsploit + data as needed). 
  • stop relying on 10 or 20 + yr old sw to scan for you. I personally like this one. With unified and open source detection databases, there is absolutely no reason to continue using the same 2 or 3 programs shy of personal convenience. Even if you gotta use packet forging tools like scapy, ostinato, wire edit, whatever.

Spending the effort to integrate semi-real time responses to the scans being performed may be a resolution between getting root and getting caught. If you treat the exploitability factor of any running system as a timing attack for the process running (such as docker spin up, run, shut down methodology) then new or valued exploitability factors come into play.

Years ago there was a talk that was largely ignored on this subject due to it seeming infeasible to automate exploit pathways that wont take time to determine. Now we have thousands of people dumping scripts trying to give "select option" runs of metasploit to try to solve this issue while I believe the issue relies far more heavily on the scanning capabilities to function with your fully or partially staged exploit chains.


No comments:

Post a Comment

New wordpress site. yes, seriously

 So, I made myself a little wordpress site over (http://hello.0daz.io/see-also/). It's running on docker, with goreplay setup to propaga...