digip

Unless its a linux driver on the disk, more than likely, it's an NDIS wrapper, and only work for connectivity, and not injection/monitor mode, but without having one to test, i can't say. Good it works from desktop versions, i had a feeling after you mentioned Pi, it's an ARM driver issue, which is not uncommon. Not everything is ported 100% because of the support and testing done by people who have those cards and build the arm branch. Re4son is just a community member, but he's already contributed a lot to the Pi side of the project with his driver updates and kernel testing. Hopefully they get rolled into the main side at some point.

Installing Vmware workstation inside a VM just to test is fine, it can be done for sure. I just meant it wasn't a good solution for practical use and might pose other issues in setup, if you don't have the resources for it. As for bug, I don't know, maybe you will stumble on to something, like the kernel version you mentioned for source header files vs what the latest had to offer, that could be part of it. As far as I know, it's already installed, at least, on my VM of Kali it was and I didn't have to install it. Mine has 4.x, 5, 6 ,and 7. One thing to ask, and I've had this issue before too. Are you using the AMD64 version, or i386? If using the AMD64 bit version, you will(if VMware is not 64bit version) also need to install the 32-bit libraries to compile against. And if on the i386/32-bit with PAE, you may need to do the opposite and move to the AMD64 version, if the program is 64bit, and installed on a 32-bit installation. If this is ARM/Pi version, then I don't think it would install at all, and you probably wouldn't have made it this far, but just asking in case this wasn't taken into consideration. I would think it would throw some other kind of message to indicate this though. I think it's: apt-get install lib32gcc-#### where ### is for the version you need(use apt-cache search lib32gcc)if you need the 32-bit libs, but just throwing that out there if that is the case. I woudl think Vmware workstation would be 64bit based though, so probably not required, but doesn't hurt to have them even if they don't fix the issue.

By the way, does this look like a pentester, or some kids? https://twitter.com/jonbush1234 Where the profile pick for "Clarence" comes from. https://twitter.com/jonbush1234/status/914948133163061249 looks like maybe Mr "Clarence" needs help learning how to use his new rubber ducky. @Clarence will the real slim shady please stand up - https://www.twitch.tv/videos/173897157 After some digging, looks like he is 15yrs old, born in 2002. How long before a thread lock? I think he's suffered enough...

I can't tell you how many things teachers used to confiscate from us growing up, from radios and walk-mans, to pen knives and such(today you'd probably be arrested for a small pen knife, but we all had them as kids when i was growing up), teachers never thought twice about confiscating stuff and tossing it in their drawer.They kept them locked up, you got it back at the end of the year. I don't think they have a right to search your cell or other devices, and even legally, you would probably need a warrant, but they can certainly take it and hold it till parents come get it or better yet, turn it over to police depending on what was done.

Ok. Who is "we"? Because "you" the pentester, aren't the one who secures the network(generally), you're the one who breaks and tests the network, then make recommendations on what to fix to the IT and Security team for the organization. If you are running iboss, and not "they" are running iboss, these are 2 different things. Who's in charge of the network? Are you the IT person who is implementing the network setup, part of the NOC/SOC, etc? What difference does it matter how it happened? Will recreating it change anything? Sure, helps when patching, but if there is a hole, find the hole, patch the hole. You're the "pentester", hired to find weaknesses in the system. If "we" set this up, then "we" should double check and test our setup. I'd bet money, there are probably multiple ways around this firewall restriction, so knowing how the student did it, is only one of them. If you are in fact the person in charge of the network, vs some outside contractor hired to break into and test the network, then you should have intimate knowledge of the firewall, the network topology, client and server machines, their setup configurations, permissions on the network, shares, etc, and where to start filtering and checking things, applying DNS and proxy filtering, vlans, etc. While it should be trivial in most cases with tunneling or VPN's to bypass most of this stuff on the firewall, if the kid is abusing the network, you DO NOT LET THE KID BACK ON THE NETWORK, and revoke their privileges. If any abuse of a network, even if not explicitly listed in student agreement/policy for "bypassing the firewall" as a rule, should surely have something that states privilege access granted, but not a right, and abuse of, can be taken away. As school staff for the IT team, even if just one person, you should have intimate knowledge of your perimeter and the network setup, and if you don't, there are probably way more pressing issues to fix, vs one kid bypassing the firewall. What is the network sign-in policy, how do they get access to the network, are they proxied natively so they can't access DNS and outside sites, what prevents anyone from plugging into the network with BYOD, rouge AP's, etc. Either this network is wide open, or you're not telling us the whole story, or as others said, total BS. This doesn't pass the smell test, and most pentesters, won't discuss client info on an open forum, as they probably have an NDA in most cases. Not saying it's 100% fabricated lie, sure, many schools have clueless network admins who are often at the mercy of the students, or just school staff/teachers/office personnel left to set this up, but if they can hire a "pen tester", they can surely hire a network admin and some IT people who know what is up with their network. You are either in over your head or should just come out and state you're trying to bypass the IBoss firewall.

If this is specific to the Pi, you may need to update to the re4son kernel, for driver support on the card you're using, or, the card is not compatible for injection and monitor mode to begin with, which is not so much the Pi and Kali, but the card's support. Raspberry's have different drivers though, and some work, some need to be updated, or in some instances, a different kernel depending on the wifi card. This might fix your issues - https://whitedome.com.au/re4son/re4son-kernel/ But I'm going to think that the Pi, didn't have drivers for that card specifically, where the desktop variants might. Only testing will tell. Also make sure the card, if supposed to work on Kali, works on the other versions of Kali(non Pi /non-arm based). If it does, then seems they need the drivers ported to the Pi and ARM branches, which hopefully Re4son's Pi kernel will fix for you, but not sure if that is one of the cards he has tested. He is working on a bunch of new wifi cards for the Pi though. Can ping him on twitter to ask if he's tested your specific card -https://twitter.com/Re4sonKernel

If you find that there is a bug, pass it on to bugs.kali.org I don't have a copy of workstation to install for linux, and my Kali, is in a VM already, so won't be of much help, since this should be something you test on bare metal and not a VM within a VM "inception". I'll see if I can get the free VMware player on my laptop which has a full install of Kali, just need to set some time aside to play with it maybe later this week. If you're trying to setup a home lab, worse case scenario, use "virtualbox" inside Kali, it's on our repo, so should install easy peasy, although I personally like Workstation better, just my experience from the windows side of things.

If trying a bind to a port already in use on the victim machine, it will fail, since that port as you mentioned, has apache running on it. You need to bind to a port not in use. It's generally easier, to use a reverse shell, so that the victim calls to you and passes the shell back to you on the port YOU listen on, vs a port the VICTIM listens on. If you ran netstat locally, you are only seeing your ports, not the victim. you'd have to run netstat on the victim machine to see what ports it is using and which you could bind to, which again, using a reverse shell, helps alleviate this so long as you listen locally, on a port not in use already.

It should of already been installed, but did you also make sure to run the command above he gave for the Linux headers? I have a feeling something is being missed here, or not supplying what it wants in the install script. Once figured out what that is, should go without a hitch.

For which changelog? updatedb locate changelog.Debian | grep gcc

Um, don't remove gcc. Just use the WHOLE path to the version you want to run against, ie: /usr/bin/gcc-5 somecode.c I also wouldn't change the default hard links. you can probably edit the install script to point to the correct GCC version it wants, or, just edit it so it accepts the newer version, if it's just doing a check for the specific version, which might be hard coded in the install script. making sure it gets the libraries it wants should make it work though.

You can check with "dpkg -l | grep gcc| grep compiler" which will show gcc, gcc-5, gcc-6 and gcc-7, etc Sounds like the GCC version it wants in Vmware is hard coded for a specific path/version? I could be wrong, but pointing it to the correct path(s) might be the fix. Make sure it's fully updated too, then reboot and try again. apt update, apt upgrade, apt dist-upgrade, reboot, then try again with the install. If you need GCC-5, it should already be installed as well though, see the grep command above, you should have all of them installed already, so something in the install script might be pointing to the wrong place.

What version of Kali are you running and is VMware for the specific version you are running? Example, if you're on an ARM device, this is more than likely not going to work unless for the i386/AMD64 versions. Not having the proper linux headers could also cause it, as Bob123 pointed out. Not sure a GCC version makes a difference unless libraries it needed were deprecated/removed and not in the latest, which the older should fix if that is the case.

Either you're on the wrong channel, or monitor mode is not working 100% with your card. Try: "airmon-ng check" (make sure card is plugged in first, doesn't have to be enabled) If anything shows, then run "airmon-ng check kill" then the check again, and if nothing, then airmon-ng start wlan0(or whatever your card is listed as). Then check that it is actually working with monitor mode: iwconfig wlan0mon (notice how the name changed after it started in monitor mode, it's no longer wlan0, but is now wlan0mon) The name is dependent on your card and driver setup, but above is more or less example you can use, just change the card ID Then airodump-ng wlan0mon -c ## --bssid ##.##.##.##.##.## or --essid APnamehere which is easier to remember for the name of the AP

https://www.krackattacks.com/

WPA2 is bypassed with MITM attack against Linux and Android devices.

Change the attack from bind, to a reverse shell. See if that helps.

Can you post all the commands on how you started and capture everything? Might help. Make sure when the card is started in monitor mode, airmon-ng -check shows nothing in the way. Also, airodump-ng, set it to a specific channel with -c # where # is the channel of your AP. If you don't, it will hop all channels and never work properly. After a deauth is run, wait a bit, airodump will show it captured the handshake at the top of the screen. If it doesn't, then it didn't see a handshake, meaning no one connected to it after the deauth, but need to make sure clients were on first, then deauth, then when they reconnect, you should see the handshake. Even when it says it captures it, do it a few times. It can also sometimes show false positives. Then in aircrack, you should get a good file to work with.

Post the entire command you used to create the payload(s) run on the target devices, and the commands you used in msfconsole for the listener. Will be easier to spot the problem.

I haven't used this(and don't know how good it is), but something like this might be more what you want - http://www.disk-editor.org/ Hex editors generally are only for files, where a disk utility program that can read raw sectors of the disk and edit them, are probably more what you want, which, show things in hex as well. Linux probably has a ton of utilities for this and maybe even some out of the box with base linux installs(I don't know), but that's waters I've not been in before.

The songs are on our official Vimeo page https://vimeo.com/150495755 https://vimeo.com/115074667

Its foreign language encoding coming through, possibly with fancy quotes in it. you see this sometimes with chinese and russian characters in an email, mostly on windows outlook type email programs and it's not encoded properly to show the unicode characters or ansii characters as intended due to the encoding and special characters in the email. more than likely just a pure spam bot though. view the header and trace the IP, what country of origin was the email from? It's also possible it was trying to run some sort of code for specific vulnerable clients and by pass spam filtering rules at the same time. This might help - https://dmorgan.info/posts/encoded-word-syntax/ Decoded, looks like a thank you email. Thank_you!Walgreen

Saw this and thought of this thread.

Does it get a session successfully? Type "Sessions" and what is listed, then "sessions -i #" where # is the number for the session(if there is one). If there is none, the exploit was not successful. Also, sometimes they can be successful, but a CMD prompt can be disabled on the system(but assuming these are your test machines, they shouldn't be unless you've set them up that way with group policy / gpedit.msc). Also, when making the payload, make sure to use x64 version for meterpeter for 64bit machines, and you exclude bad characters like x00, x0a,x0d, etc

Meterpreter is for windows. If on linux or MAC, the shell is just like as if you were local to the console on the device itself, other than what level of user you are, either root, or lower priv level> If you created the reverse shell as root, then you have full control of the machine, so not any further to go from there aside from whatever your reason was for using the shell. If lower priv shell, then you could work out flaws and see if you can manage to attain a root shell or elevate to root in some manner, but if you don't have a reason from using the shell, consider it just an exercise in using the tools. It may be useful at some point in your life/career later on.