Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Hydra Brute Force Attack on IP camera system
We found a camera that was installed without anyones knowledge on a jobsite, we currently have the IP camera system in our possession and there is a username and password for the device.
I have discovered that the username is "root" however the password is what we are trying to get past to see who set this up, perhaps we can get an email address off of it or if it was streaming to a website and or a NAS device or something.
So I'm currently using Hydra for Ubuntu to brute force attack the password. It is not a Basic Authentication password, it is a digest authentication. I do have a password list and when I use Hydra it comes back with several passwords it thinks is it but not the correct one.
I have read that it is due to the web interface attack that its not getting rejected on certain passwords therefore its giving me false positives.
below is what I am currently asking hydra to do but perhaps I need to add in something else to this, let me know what you think.
hydra -l root -P pwlist.txt (ip address) http-get /
I have tried this command also with -e ns and -f triggers also changing the end to http-head but still getting false positives.
Does anybody have any idea as to how I can get around this?
I have discovered that the username is "root" however the password is what we are trying to get past to see who set this up, perhaps we can get an email address off of it or if it was streaming to a website and or a NAS device or something.
So I'm currently using Hydra for Ubuntu to brute force attack the password. It is not a Basic Authentication password, it is a digest authentication. I do have a password list and when I use Hydra it comes back with several passwords it thinks is it but not the correct one.
I have read that it is due to the web interface attack that its not getting rejected on certain passwords therefore its giving me false positives.
below is what I am currently asking hydra to do but perhaps I need to add in something else to this, let me know what you think.
hydra -l root -P pwlist.txt (ip address) http-get /
I have tried this command also with -e ns and -f triggers also changing the end to http-head but still getting false positives.
Does anybody have any idea as to how I can get around this?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
yes I have checked with the manufacturer on the default username and password, username is root but the password is not the default.
At he rate of 1000000 passwords/s (like 40GbE) you will get through with 4-letter passwords in a day.
Why dont you call in the police when some snoops on you?
Why dont you call in the police when some snoops on you?
really see no pt of brute forcing as it may backfire esp if there is account lockout, but apparently not shown in your case with those brief symptom (hopefully) so far. either it can be console into it w/o the web login that can be using other credential, otherwise has to hard reset but losing the trail. may be more worth to look at the traffic going into the IP camera instead of focusing on the camera...since it is "denied" from access.
There should not be any mean to recover the password, otherwise it means a backdoor account that the attacker may have used or the manufacturer has use for "other" purpose - they should advice any means for such emergency access instd, if they say none - no other better means to help in your tracing - just look at other intermediary log esp the firewall, WiFi AP connecting to camera etc.
There should not be any mean to recover the password, otherwise it means a backdoor account that the attacker may have used or the manufacturer has use for "other" purpose - they should advice any means for such emergency access instd, if they say none - no other better means to help in your tracing - just look at other intermediary log esp the firewall, WiFi AP connecting to camera etc.
I'm with btan on this ... Might be easier and quicker to hang the IP-camera on a separate switch (airgapped if necessary), put a port in monitor mode and hang a laptop/pc on it with Wireshark (or similar) installed on it and capture the traffic to see where it wants to go to, if anywhere ... If the traffic is not encrypted (https) it might give something ... Maybe.
Bruteforcing will take a long time if succesful at all ...
Another option is to check the make of the camera and search for zero-day exploits or other ways to bypass security.
But I'm also with geist on this as well, if someone's spying on you, why not call in the cops?
Bruteforcing will take a long time if succesful at all ...
Another option is to check the make of the camera and search for zero-day exploits or other ways to bypass security.
But I'm also with geist on this as well, if someone's spying on you, why not call in the cops?
to add, do check your internal servers and other camera installed as likely they may have been "touched" and review the access log - I doubt the intent is just one camera in the case of getting the data residing in the camera - esp if there is external storage plugged into it...contain the damage spread and potential breach as of now
Well after everything I've gone through I was able to snoop a little and started looking at browsing history and found that the camera was accessed on June 8th and it showed me what the original IP was, I then snooped for the IP on other peoples terminals in there internet history which one user popped up on. So I searched his computer for any passwords and found 15 of them. I went back to the camera and tried the first password for no luck but the second password worked.... Bummer part was the Camera was pretty much at factory defaults other than the password change.
Thanks for all your help everyone, but the rabbit hole continues and this case is closed, next time (hopefully there isn't a next time) the users know not to touch it if they find one.
Thanks for all your help everyone, but the rabbit hole continues and this case is closed, next time (hopefully there isn't a next time) the users know not to touch it if they find one.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial