digip

I'd suggest getting patches from official sources, but that's just me.

This has been brought up. Currently our docs.kali.org only show how to do it to an extent, but is a bit out dated and not much help for windows users. For me, I just disabled UEFI, installed, updated, then rebooted and reenabled UEFI. Then i just choose which partition to boot from, and I'm good to go, with Windows still being the default OS it boots to if you don't choose the partition with F9 or F10(I forget but whatever your BIOS hotkey is for selecting drives, but that is for my Laptop and how I installed mine with just the ISO)

Your Windows 10 devices, is using UEFI, so you need to either disable in the bios to use Legacy settings for the install(which will work with EFI after fully installed and updated), or use something like Rufus to make a UEFI bootable USB drive for the install on a UEFI enabled computer. Kali supports UEFI 100% too, just the ISO files don't have the UEFI boot enabled, which is where tools like Rufus help. Basically use https://rufus.akeo.ie/ with your ISO to create the UEFI bootable thumbdrive, and you will be good to go.

How do you issue certs to each device, and what devices will inherently be able to support it in this manner. This being the age of TV's, game consoles and DVD players all being WPA2 compliant now, I think you would ultimately kill a huge trunk of the user base, if you suddenly go to a new standard, vs patching the existing model to keep legacy devices working.

WPA3 is not even a thing yet. There is no new standard, as far as I know, that supersedes WPA2 and WPA2 Enterprise.

For SSH, you would ideally SSH into the victim, not them into you, which would make you vulnerable to attack. You would also need to use a certificate and disable passwords for it to work, or use a different SSH tool to allow passing the passwords, since SSH itself, won't allow you to script the password prompt part. SSHpass I believe lets you script the login process and pass the password along, but again, you'd be giving the victim access to YOUR side if you do this. Using proxychains, you can then forward any tool over the SSH connection to scan the inside of the victim LAN, via the victim's machine, but I think you have your setup a bit ass backwards in what you are trying to do, since you seem to be wanting the victim to SSH into you, which I wouldn't suggest doing. Also, you would also need to configure SSH to listen for connections on the port you posted above, which seems you have metasploit listening on, not SSH, so SSH should fail completely anyway(even with SSHpass sending credentials) with what you have shown above, unless I missed something you left out. If meterpeter is listening for a connection, the other side needs to send what it expects, which is not SSH. You selected reverse TCP, so your victim needs to just send a normal reverse TCP session. There is an option to use SSL with the reverse sessions, so SSH isn't exactly needed either, if encryption was what you intended to use to hide the data going over the wire. If you had something like proxychains setup with dynamic forwarding and using certificates for the victim to SSH to you without the need for a password, it might be possible, but again, what you would be doing essentially, is letting the victim SSH into you, giving the victim side, complete access to your machine, which I assume is NOT what you intended. Think about what needs to be done. Often helps to draw out the topology and end points and everything in between. If you have a way for the victim to dial out and port forwarded on your end to the listener, you don't even need metasploit in the mix(but the msfvenom payload would need to not use meterpreter in this instance), and can use something like ncat, end to end which allows SSL(vs netscat, which does not do SSL). ncat comes with nmap, and if you can copy it onto the victim machine and execute it via any script like a simple bash script, so long as you can catch the reverse shell on your end via port forward or such, you should be good to go. You can then again use proxychains on your end to forward any scanning tools or such, directly over the ncat tunnel to scan the victim's LAN for other machines, pivot over the tunnel, etc. This is how I would probably try it, using ncat with SSL, but if you need metasploit, use reverse_https for SSL, and you would be better served with this, vs having them try to SSH into you. Keep it simple, and don't open your machine up to attack. https://github.com/rapid7/metasploit-framework/wiki/Meterpreter-Paranoid-Mode

What kind of confessions? Pentesters/pentest companies, generally sign an NDA, and can't talk about a pentest in detail. Maybe I don't understand the concept of what you're asking for though.

If it can be rooted to put other roms or such on it, it may be possible to put kali on it, but currently, only for select devices and chipsets since each devices has to be tested to work with drivers and such. I know they are working to make it easier to put on more android devices though, and more android phones, so it won't be limited to just the OnePlus and Nexus devices.

People should know, all VPN providers, are going to turn over and log your activity, if requested by law enforcement. If you choose to use a FREE VPN service, you may as well send me all your passwords. Will be safer with me, than using a free VPN. Use your head. If you're doing things you fear getting caught doing, you 1, probably shouldn't be using forums to announce it, and 2, VPN is more than likely not going to help you.

PHP is server side code, so the site would only see the rendered output, not the executable PHP. Rename to shell.txt. Will only work if the site is vulnerable to true RFI, as some only echo back what they see, including plain text of executable code and scripts. Google OWASP, RFI and LFI.

What is the IP address of the device running Android? Looks like it has a session, have you typed "sessions" and then "sessions -i 1" assuming only one session, the first being the android device. if "192.168.43.1" is the gateway's IP, you may have to port forward or put your computer running metasploit, in a DMZ, but so long as the Android device is over wifi on the same subnet, then you should be ok. It's possible the attack runs, but isn't 100% vulnerable to what you're trying to do though. You might want to also add a filter for bad characters like x00,x0d,x0a, etc, to the binary in msfvenom, just to be safe. Example: -b '\x00\xFF'

I'd have installed virtualbox by now if that is the case. It should work out of the box and is on our repo. No futzing with vmware, and it's free. Will do what you need.

uh, no..lol. the deb file is an archive, not a script. I asume once unarchived, there are inner files and a tarball with the install files and install script inside there(to be extracted), only need the script, if it has one. I just wanted to see what/if it shows for starting the services, which I think need to be patched to use systemd, which might be why things go wonky. Looking at the arch site, that seems to be the case from their notes stating to ignore the install error and patch for the services and network settings afterwards, but this is a lot of assumption on my part. Going to 14 might negate the issues on the 12.x.x branch, but then again, you might have to pay for that vs the student license for your version.

You might need to update to the re4son kernel. see here:

cat filenameofinstallscript then copy pasta to here and put in code brackets. I have a feeling it installed properly, but the service needs to be patched to start using systemd. try starting vmware itself, even without the virtual adapters. I forgot you are doing this with a deb file, not an install script out of an archive file. Hmm. Can deb containers be expanded? Maybe like: ar vx mypackagename.deb tar -xzvf data.tar.gz then look for the install script.

This may seem daft, but can you open and paste the install script here? What the startup script does for the services? Could be its borked because of systemd but actually installed properly and you have to use systemctl to start the services or configure them to use systemd? Also, I'm looking at https://wiki.archlinux.org/index.php/VMware which if I'm reading, kernel is only supported up to 4.8 with the Vmware 12.5 branch, as where maybe Workstation 14, would be a better install candidate, or you need to go to an older kernel, which is not advised. It seems they have a patches section too for the network stuff, so might be part of the issue, although ARCH != KALI, I assume similar "linux" issues would arise across linux distros to some extent with respect to kernel levels and such.

That is awesome!!

OMGWTFBBQ, GTFO I picture these 2 kids like: https://i.imgur.com/BmZ22Tq.gifv

Yeah, I would download from https://my.vmware.com/web/vmware/details?downloadGroup=WKST-1257-LX&productId=524&rPId=17068 but I don't have a current account to login and download from. I personally, will only install from their site though. I don't trust third party sites, although you could double check the hash against the VMware.com download page to be safe.

Where did you get your copy of this workstation DEB file? Directly on their site? I have Workstation 8 for windows but I bought that years ago and still use it, but I had to register to download and get it. Curious to try the install myself to see what/where it fails if anything.

try "lib32gcc-6-dev" which is what mine say, but you can look them up with "apt-cache search lib32gcc" which will list all of their full names. Use what you need/want to try. Actually, just listed mine, this is what I actually have installed: ii gcc 4:7.2.0-1d1 amd64 GNU C compiler ii gcc-5 5.4.1-4 amd64 GNU C compiler ii gcc-6 6.4.0-7 amd64 GNU C compiler ii gcc-6-multilib 6.4.0-7 amd64 GNU C compiler (multilib support) ii gcc-7 7.2.0-7 amd64 GNU C compiler ii gcc-7-multilib 7.2.0-7 amd64 GNU C compiler (multilib support) ii gcc-mingw-w64 6.3.0-14+19.3 all GNU C compiler for MinGW-w64 ii gcc-mingw-w64-i686 6.3.0-18+19.3+b3 amd64 GNU C compiler for MinGW-w64 targeting Win32 ii gcc-mingw-w64-x86-64 6.3.0-18+19.3+b3 amd64 GNU C compiler for MinGW-w64 targeting Win64 ii gcc-multilib 4:7.2.0-1d1 amd64 GNU C compiler (multilib files) ii linux-compiler-gcc-6-x86 4.12.13-1kali2 amd64 Compiler for Linux on x86 (meta-package)

Yeah, I don't know 100% it's required, if it's 64bit installer. It was just something to rule out.

It was a good SE attempt I guess. Albeit, failed attempt. I think had he known what admins do and things in place, the ruse would have been a bit more elaborate, but that could also have made it even more fishy, given a penetration test would more than likely be confidential. I had fun just sleuthing out his info though, which was pretty easy given his digital footprint.

Do a "dpkg -l | grep lib32gcc" to be sure. I've got 1, 6 and 7 installed from what mine shows.

I never even thought to try that, as I think I just apt-get installed them when I did it. I needed to compile an exploit for a 32bit only version of linux, and I needed to add the libs to make it happen, but this was like a year or 2 ago for a CTF I was doing and don't remember exactly what I did at the time, just know that I needed them to make it work. Was just wondering it that was causing the issue, if you were on say, the 32bit kali, but trying to compile 64bit program and missing the header files or such.