Active Members
  • Content count

  • Joined

  • Last visited

  • Days Won



About digip

  • Rank
    -we're all just neophytes-

Contact Methods

  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location

Recent Profile Visitors

70,888 profile views
  1. I didn't know there was a daily limit for new users. I knew they put limits on show many posts before you can edit and post links generally, but I see a lot of that has changed over the years. I'm not a forum admin, so I don't see any of that side of things, but mrprotocol or seb would probably know.
  2. Pi would make a decent Kali box as an attacker, but you're not going to run a bunch of VM's for CTF on them. Builds on a Pi specifically as a victim machine sure, but I don't see them being used as hosts for CTF VM's
  3. What I miss? limit for what now?
  4. Many devices have more than one login, and different admin panels for each. My IP camera had two logins, one for administering and setting passwords, and the other for viewing and forwarding to FTP or Email. They both logged in with admin, but you can or on mine, could change the name for the lower priv one to whatever you wanted from the real admin one. The password, and the ports are what were different. I haven't used that camera since I lived in our apartment few years ago, and it's packed away somewhere, but I imagine your's works similarly. I'd try scanning the device for open ports, and trying the admin and other password, on other open ports, see if you get a different web panel login from the desktop, or explore the other login you already use, to see what the admin panel options are and if they show other login creds, like FTP setup that previous owner might have used for their servers to upload images to or the web somewhere. That first line above, might be to control the DVR capabilities over a web page panel or for offloading video to another server, or a DVR device's creds to record directly from the camera's stream.
  5. QEMU is fine, if you can run it on the school machine, you should be able to make a new VM and install Kali via QEMU, but ideally, the VMware would be my first choice, even over VBox. Vmware player only lets you run one machine at a time though, vs something like Vmware Workstation, where you can run multiples at the same time. Workstation is what I use at home so I can run multiple VM's at the same time when I practice in my own lab. You could always try booting off a live disc of Kali and attack other lab machines over the network, which give you more of a real world feel for using it though. Hooking up a monitor to something like a laptop with a broken screen, you should see the bios on the external screen, just hit the keyboard shortcut for the second monitor or projector(if connected via VGA) which should do the same thing. Kali in a VM will be fine on a 4gb machine, so long as you aren't running lots of multiple VM's together. a CTF VM along with Kali running at the same time, should be fine, but I'd use the student laptop from school while live booted into Kali, and then on the spare machine, setup some VM's with CTFs to attack from vulnhub or such. The Kali tablet, I'd say save your money till you learn to use Kali. Also, you need specific tablet hardware that supports it, using Kali NetHunter on them. You could go your own route and build kali to run on any supported tablet based hardware, but with Kali NetHunter, you at least get images built for specifically tested hardware on those Android based devices. Don't just buy a tablet without knowing what is supported first.
  6. Off topic, just wondering if your first name is Quinn? Just curious, as that is my oldest daughters name, and also one of her nicknames is Quinnifer.
  7. The Breakthrough series documents various things, with that episode specifically about information security stuff and the people they had on.
  8. You should be able to get the keyboard working in uBuntu with the links above, but more than likely, not going to get it to work in kali without USB keyboard and mouse, or bluetooth, as there are no Kali patches for the kernel to use the SP4's on-screen keyboard. I even searched the kali forums, found no one that had working on-screen keyboard. If you google, you'll see people stating to use USB or bluetooth. If there were a relevant working kali version, it would more than likely be easily found and talked about. What I have seen is people saying you can use VMware on the Surface pro, but you;d have to test that yourself. You'd then have to use a USB wifi card since VMware can't use the wifi natively on systems, only physical ethernet bridged connections from the host side.
  9. 1, are we supposed to spoon feed you? 2, how hard did you look? I haven't a device to test, but literally top of google for this stuff came up https://www.reddit.com/r/SurfaceLinux/comments/4feh9c/surface_pro_4_runs_kali_linux/ https://community.spiceworks.com/how_to/66948-uefi-kali-linux-live-usb-on-surface-pro You'll need to compile a kernel drivers specifically for this apparently, so stock kali won't work for on-screen keyboard without modified kernel and drivers. best bet is USB keyboard and mouse or bluetooth. AS far as I know, the ubuntu kernel is not going to work for kali, and you would most likely break a lot of the tools in the process. I don't know of any patched kali kernel at this time. That said you could put ubuntu on it with https://launchpad.net/~tigerite/+archive/ubuntu/kernel apparently. You'd then have to put the tools you want on it.
  10. You're probably not going to be able to prove anything, as if this was a sophisticated attack, it could have run from memory and be gone on reboot. No way to prove that really other than catching them in the act. What they did to get in would also be hard to prove other than having osmeone pentest the box itself, ie: actively hack you. If you have certain services enabled, this could let anyone in, and if you have weak credentials for anything, even easier. SMB would probably be where they got in, but that is just a guess since it's a business machine, it more than likely has file sharing services in use and unpatched files. The recent wannacry attack for example is one that could go undetected other than the fact it is ransom-ware, but the attacks used relied on more recent 0-days that many had not patched against, all of which could have been done without your knowledge. At the end of the day, you're pretty much shit out of luck other than catching them in the act, or them slipping up and leaving something forensically on the system, for which you said 2 groups have already checked against. Even the way it sounds from what you describe, it seems unreasonable you aren't the culprit, but we have no way to prove for or against you. If this was truly hacked, and used your skype to talk up business stuff, then possibly targeted by someone in the company like a co-worker. You should logon to the skype website(not your client) and see if they show any info for IP addresses logged into the account, although I'm not sure if they log them or have a setting for that. It's possible they guessed your password(s) and used the accounts that way as well, since skype is not limited to only the desktop or mobile clients, you don't need a client to use skype, only access to the skype site and the login details.
  11. The %temp% is a windows temp folder that is read in from the systems defined path for the temp folder. You could change this to any directory. If typing a user-name and password is too much to login to ftp, use an ftp client the stores the settings for you and don't use the command line, or, script it. However, know that ftp is a protocol that no matter what, using command line or client, will send all your data in the clear, ie: plain text passwords over the wire and can be sniffed easily. Using something like SCP or SFTP would be a better way to go and avoid plain FTP at all costs if logging into a server remotely, but the service has to setup to enable it. If you don't care about logging into ftp, there is also wget, which you'd have to install on windows, but is already installed on most llinux systems. Works much the same way as the powershell command. wget http://somesite.com/file -O filename.xxx where -O means output and filename.xxx is the file to save it to. You can add a whole path too, just put it in quotes like "c:\user\name\desktop\soem folder on desktop\file.xxx"
  12. Your iDevice probably has a certificate it uses to do some sort of handshake, but you'd probably have to root the device and sniff the process/network to see what is happening, and it most likely won't be sent in the clear(although it could be just a token). Two people I think of when phones are in question, Georgia Wiedman, and Kyle Osborn aka Kos. They might have stuff out there with answers, but I'd in general just google.
  13. Instead of hacking their system, maybe take the time to learn about it, if it is bluetooth, ask someone at the school. Brush up on your SE skills, talk to the system people that run the PA system, learn about it, and if it is bluetooth, ask them of you can test something, such as connecting to it. Then show them if you find a flaw. This whole "how do I hack my school" isn't so much black hat or white hat. Its how and what you do. If you act maliciously as in "I want to hack my school" without purpose, ie: malicious intent, then no, we don't condone that, but surely can't stop you. But if it's "I want to know how this system works and what I can do with it, can I test this theory xyz" and you're working with someone from staff or the school, then it's a different situation. As I say a lot, learning is not a crime. What you do may be, and that is on you. How you go about it, makes the world of difference. Tinkering and curiosity is how we learn. Just be responsible, and in all situations, cover your bases, because if some ass hat at school turns around and does it maliciously after you show them how it's done, you're the one going to get in trouble if you aren't going through the right channels and being up front about it. Hopefully they encourage you to learn about it in the process, vs getting yourself into trouble.
  14. You're not still booted off a live disc right? Here is what I have in mine for latest kali 2017.1 - cat /etc/apt/sources.list # # deb cdrom:[Debian GNU/Linux 2016.1 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 20160120-18:14]/ kali-rolling contrib main non-free #deb cdrom:[Debian GNU/Linux 2016.1 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 20160120-18:14]/ kali-rolling contrib main non-free #deb http://http.kali.org/kali kali-rolling main non-free contrib deb http://http.kali.org/kali kali-rolling main non-free contrib # deb-src http://http.kali.org/kali kali-rolling main non-free contrib Only really need the "deb http://http.kali.org/kali kali-rolling main non-free contrib" line uncommented Set yours the same, and then do apt-get update && apt-get upgrade && apt-get apt-get dist-upgrade Then you should be all set. run updatedb afterwards or reboot too. Once done run "uname -a; cat /etc/*ele* /etc/issue" You should then be on 2017.1, which is the latest. Linux kali 4.9.0-kali4-amd64 #1 SMP Debian 4.9.25-1kali1 (2017-05-04) x86_64 GNU/Linux DISTRIB_ID=Kali DISTRIB_RELEASE=kali-rolling DISTRIB_CODENAME=kali-rolling DISTRIB_DESCRIPTION="Kali GNU/Linux Rolling" PRETTY_NAME="Kali GNU/Linux Rolling" NAME="Kali GNU/Linux" ID=kali VERSION="2017.1" VERSION_ID="2017.1" ID_LIKE=debian ANSI_COLOR="1;31" HOME_URL="http://www.kali.org/" SUPPORT_URL="http://forums.kali.org/" BUG_REPORT_URL="http://bugs.kali.org/" Kali GNU/Linux Rolling \n \l