Tag Archives: metasploit

Posts

Cisco Meraki security is kind of a joke…

Leave a comment

Recently I wanted to test Meraki’s ‘Threat Protection’ system and see if it was really up to snuff. First, I setup an up to date Windows 10 virtual machine where I disabled the anti-virus on this system.  In this environment there isn’t any SSL inspection being done by Meraki and to my understanding, Cisco really doesn’t advocate using SSL inspection through Meraki. In my opinion, you are already at kind of a disadvantage with the lack of SSL inspection because most threats that need to be seriously considered will use encryption for evasion. Metasploit’s meterpreter payload has supported SSL and encryption for years. Plus you can setup legit certs for free if needed.

With that being said, I thought I would throw a softball at Meraki and see if it would do some sort of detection via HTTP. I tried downloading the benign eicar test file over HTTP and Meraki blocked it:

However, if you download the same file over HTTPS, Meraki does not block it (no surprise there).  I then decided to step my game up and generate a payload using msfvenom and host it on a python3 http server ( python3 -m http.server ):

I was able to download the payload using powershell on the victim VM:

I was then able to run the payload on the victim system and have a session:

Meraki did not detect the payload or the session.. and here’s the the virustotal report for this payload:

https://www.virustotal.com/gui/file/f7f301b9bb52a23efb1c6e5ee4f2bb6adeebda2882a60c9f98ca582100b78908/detection

This payload was not made in really any special way… it’s a pretty standard payload that I believe ALL IDS/IPS systems should be able to detect or block. However, I will give credit where credit is due. Later on I did receive an alert that this payload had slipped through:

Additionally, this Meraki configuration does not have Cisco’s Umbrella integrated yet. Would Umbrella have blocked it? I honestly don’t know but what I’m willing to test it.

I would like to add that a majority of events that I’ve seen under Security Center have been false positives. There is already enough noise in terms of information pertaining to networks. Meraki generating this just adds more unnecessary noise and can hamper investigations in my humble opinion.

I’m still thoroughly disappointed with this discovery because people are paying Cisco a lot of money for a false sense of security. Meraki should have blocked this threat right away. In the end of the day, I believe having well trained employees and thorough AV/EDR systems on endpoints is what matters most.

#Update 12/24/2021

I have setup the Umbrella client on the victim VM. Meraki blocked the known helpme.exe file, however if you simply use the shikata_ga_nai encoder to make a new file called helpme2.exe, this payload slipped through Meraki and Umbrella.

Here is the virustotal.com report for the file:

https://www.virustotal.com/gui/file/19cf577ac24452bfb715f421a6bdabadd0f2d043f60cbbf600e44e34dc14738f

I feel like I can confidentially say that Meraki/Umbrella security are a joke.

Posts

To have a ‘hacker’ phone or not… that is the question

1 Comment

Mr. Robot - Pwnphone

Can I recommend from my experience for any average Joe, security specialist, or even computer enthusiast to have a rooted, custom kernel, Nethunter Android based phone as their primary cell phone to rely on? Honestly no, unless you have the time, resources, and expertise to troubleshoot issues with the device. Don’t get me wrong, it is awesome to have a device that fits in your pocket that when setup right, can do nmap vulnerability scans, arp poisoning, run the Social Engineering Toolkit and a plethora of other tools/actions. But you have to remember, projects like Nethunter, which are great for what they are, are community driven and fixes/issues may have to be resolved by the end user themselves.

If you’re going to venture down this path, feel free to but take some things into consideration. If this is going to be your primary phone, in the event of an emergency, can you count on it to not freeze or reboot when you need it? This is not to say that vanilla/stock phones won’t let you down but usually the vanilla/stock phones have more support and tend to be more stable. So with a security suite like Nethunter, which is not a ROM but is meant to run on top of a stock Android OS with a custom kernel, in my humble opinion you’re only adding complexity to the device and more chances to have an unstable device.

Another question you have to ask yourself would include, do you trust all these tools/pieces of software on your primary phone that you may use for banking and private matters? By rooting your phone and installing the likes of Nethunter, you are potentially turning your phone into a more advanced spying tool that could be used against you. (Also take note that rooting your phone just makes it less secure.) Just think of this, if an adversary can get onto a server through whatever exploitative means and they discovered a Kali chroot environment, how much more potential damage could they do? Now imagine this ‘server’ is your phone that you constantly keep on and charged and with you at nearly all times.

This is to not say that I advocate against ‘hacker’ phones or turning phones into offensive security devices. My point is that there’s a lot to take into consideration.  If you want a stable phone to do your regular smart phone related matters on, I recommend something stock with little to no mods and if you want a ‘hacker’ phone, I recommend getting a second phone that you do not heavily rely on. 

Now if we could run virtual machines on our phones with security hardened hardware passthrough options… that would make things interesting. (Interesting discussion here .)

Code, Posts

Sewing Patches in the Veil AV Evasion Framework

Leave a comment

I have to admit that I am a little bit weary about the gaining popularity of Veil. AV evasion is really a game of cat and mouse, between the anti-virus companies and the individuals who are trying to evade detection. In this article we will be taking the role of the ‘mouse’ per se by working with this framework. We will first fix a bug in the framework and I will also show you how to use this framework in an ARM Kali chroot environment where wine is not readily available.

First, let us fix Veil because without this fix, Veil’s use under a Linux environment is diminished greatly. To get the Veil framework, you can either do:

git clone https://github.com/ChrisTruncer/Veil veil

Or

sudo apt-get install veil #If you have the right repositories or are using Kali Linux


To get the newest bleeding edge version, you’ll want to use the git method. However, if you use this method you will need to run the setup.sh script under the setup directory. This will handle the installing of the necessary dependencies. If you’re running an ARM Kali chroot environment on an Android based device, you will want to use ‘git’ because if you attempt to use apt-get to install veil, it will bomb out and give you an error message that wine is unavailable.

Upon my first use of Veil, I followed this post from the SANS Penetration Testing website closely. One issue I ran into was in the ‘How would you like to create your payload executable?‘ stage. The default method ‘Pyinstaller’ method did not seem to be creating an executable  in the veil/output/compiled/ directory, but it would create a source file in the source directory (which is still useful, more on this later).

I knew the framework relied on wine and a wine installed version of python to generate payloads under a Linux environment but wasn’t sure where to look for where this took place in Veil’s code. I started greping for wine in the Veil python modules and soon discovered this interesting piece of code that appeared to be the source of the problem.

Line 84 of the supportfiles.py file which is in the veil/modules/common/ directory contains this line of code:

os.system(‘wine ‘ + os.path.expanduser(‘~/.wine/drive_c/Python27/python.exe’) + ‘ ‘ + os.path.expanduser(‘~/pyinstaller-2.0/pyinstaller.py’) + ‘ –noconsole –onefile ‘ + payloadFile )

Due to the fixed path of ‘~/pyinstaller-2.0/pyinstaller.py’ for Veil to work with this current code, one must have this directory structure and files in their home directory. If you’re using Kali Linux, change this piece of code to ‘/usr/share/pyinstaller/pyinstaller.py’ and Veil will now create portable windows executables.

Before I discovered the source of this bug and simple fix for it, I took the harder route and attempted to create the portable executables under wine following these requirements (from https://github.com/ChrisTruncer/Veil/blob/master/README.md ) :

Windows

  1. Python (tested with x86 – http://www.python.org/download/releases/2.7/)
  2. Py2Exe (http://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/)
  3. PyCrypto (http://www.voidspace.org.uk/python/modules.shtml)

I soon learned there were issues with py2exe working under wine. py2exe under wine creates invalid windows portable executables. (http://stackoverflow.com/questions/12170373/python-to-windows-executable-under-wine). I was then stuck with the Py2Exe method that relies on having a Windows machine readily available.

Veil Mobile Scenario

This then brings me back to the mobile scenario. To the best of my knowledge at the moment (and correct me if I’m wrong) you can’t install wine under an ARM Kali Linux chroot environment. So if you want to create payloads using Veil on your Android device, you will have to first obtain Veil via git. Secondly, there is no need to fix the code like I posted. You can leave the code as is.

You can now create python source files using either pyinstaller or py2exe under Veil. If you use the pyinstaller method, you will have to copy the files to a Linux machine that has necessarily dependencies for Veil and you can simply create an executable doing something like this:

wine ~/.wine/drive_c/Python27/python.exe /usr/share/pyinstaller/pyinstaller.py meterpreterpayload.py

Or you can use the py2exe method and copy the files to a Windows machine and compile your executable that way.

Other issues with Veil

One minor annoyance with Veil, is that I’ve noticed the portable executables are kind of hefty in size. If you create a payload using the pyinstaller method, the executable is about 2.4 megs and if you create one using the py2exe method under windows, the executable is over  5 megs. This is quite large in comparison to using msfpayload/msfencode or msfvenom, which creates payloads that are typically less than 100 kilobytes.

I would also like to see Veil being able to bind the obfuscated payload to non malicious executable like putty, however all in all I’m very impressed with this framework and hope the developers like Chris Truncer keep up the good work.