[Hunting Unlimited 2010 Crack.rar Full
Abdul Soumphonphakdy
In this post we will be exploring the art of password hunting on a target Linux machine as a means to escalate privileges either horizontally or vertically. We will review various techniques to hunt for passwords, as well as some common locations they are stored. During our hunt, we will uncover credentials in scripts, config files, filenames, hashes and much more!
Along with passwords laying around on the system, there are quite a few places where we might find password hashes or files that are password protected and need to be cracked. For this reason, will be doing a lot of cracking in the post using both Hashcat and John the Ripper.
When you find ANY passwords on the system, whether it is during the initial exploitation phase or the post-exploitation phase, you MUST test that password everywhere you can! Also, test any password you find against ALL usernames you find as password re-use is a massive issue and is very common!
Both ways of searching for files with a specific string in their name will produce a lot of results, but if we take our time to review the output, we may find some JUICY files that have passwords inside.
Most often, we will be looking for config PHP files; however, there are many possible file types where we could find credentials including TXT files, bash scripts, other scripts, ZIP files, other compression filetypes (tar, gz, etc.), DB files, and many more.
There is no designated extension for password files generated with htpasswd. For this reason, we can find that the file generated with WebDav credentials can have ANY extension or even no extension at all. I have seen: *.password / *.dav / *.pwd to name a few.
Navigating to the hidden directory and using the ls -la command again, we can see there is a hidden file named .password; and inside, we find another password to add to our password file.
We should always be looking for non-standard directories in the root of the filesystem; however, there are two known hidden files / folders that exist in every users home directory and they are the .bash_history file and the .ssh folder. Well, the history file will be in every home directory, but the SSH folder will only exist if the user has an SSH key.
When we get a foothold on our target, one of the things we want to enumerate ae the number of users that have a home profiles on the system, and out of all the profiles we find, how many of their bash history files we can view.
The id_rsa file is a private key that can be used to login to SSH without knowing the users password, but only if no password was set when the key was created. This file is essentially the equivalent of a password, with regards to getting you into the system.
For most types of password protected files, John the Ripper has different tools that can be used to convert specific filetypes into a crackable format. These tools are all named xxx2john and the whole list can be found on our attacker machine using the following command:
When we run sudo -l, we are prompted for a password. Since password reuse is so common, we can test the password that the user set on their SSH secret key. If we get lucky, they reused their actual login password when they made their key.
You may have noticed that I did not get prompted for a password the second time I ran sudo. This is because by default, sudo will only prompt you for your password after five minutes of sudo inactivity. Each time you run sudo it resets the 5 minute timer and allows sudo to be used without entering the password again.
The first four databases are the default / built-in databases. Of those four, the one we are interested in is the mysql database. This is the database that contains the login credentials that gets us into MySQL itself.
Apart from the default databases, we should ALWAYS be interested in custom ones. Especially when the custom DB is related to a web application. If we find some password hashes in here, we may be able to crack them and use them to increase our access.
Starting with the mysql database, we can switch the database we are in using the use command and then view all tables with the show command. We are most interested in the user table in this database.
There are two hashes in here; however, the root hash is the hash for the password we used to get into MySQL. This is because the mysql database holds the info for the MySQL service. We can confirm this is the same password using the following command:
This command provides the hash value for any string you pass through it; and, we can see that the hash is the same for the root user as the password we used to login to MySQL. However, the second hash we found for the dev user is unique. We can copy this hash into a TXT file on our attacker machine and crack it using hashcat.
We should now have a file in our current directory called mysql.hash that we can pass into hashcat to crack this hash. After this step, we can use the following command to find the crack mode for this hash type:
Now that we have learned how to find and crack the mysql database hashes, now we will turn our attention to custom databases. More specifically, the web_app database we enumerated earlier.
We can take these hashes to our attacker machine, just like we did with the mysql database credentials we found, and then crack them using hashcat. However, these hashes are related to the web application, and the web application chooses the hashing algorithm to store passwords. At this point in time, we do not know what type of hashes these are.
After using the command hash-idenfier, the program starts and we can paste one of the hashes into the HASH: field and then it will try to determine what type of hash this is.
It is often that you will find base64 encoded strings ending with one or two equal signs. This is NOT always the case though. Therefor, when you find any interesting string that consists of mostly upper case and lower case letters, check if it is base64 encoded.
The /var/backups folder is where some automatic backups are stored, such as a backup of both the passwd and shadow file. However, the default backup files will have a restricted set of permissions just like the actual files do.
Since Unix SHA-512 hashes are pretty decent, this will take a few hours to try and run through all of the rockyou.txt file against both hashes. For this reason, we can use a shorter version of rockyou to speed things up. If we do not succeed, we can build up to a bigger wordlist.
For our final (manual) example, we will look at interesting file types that we may find during our enumeration and are worth closer inspection. This includes files like PDF, RAR, ZIP, 7z, and more. Oftentimes, these files are password protected.
We can see there are hints that this file belongs to the devops user, and we already saw that DeVeLoPeR712 is the same password that the user uses to login to the system.
LinPEAS is the ultimate post-exploitation enumeration tool because it provides a HUGE amount of information. After running it on the victim, we will see all of the same things we found with our manual enumeration, and more. However, it was important to show the manual steps before using tools so that we understand the output and what to look for.
After grabbing a copy of LinPEAS, we need to transfer a copy onto the victim. This can be done a number of ways, but for this example we will download it from a web-server that we setup on our attacker machine.
With our tool all ready to use, we can just use the command ./linpeash.sh and the script will execute. To find passwords, we need to scroll down to the Interesting Files section; and occasionally, the Software Information section.
Downloads from browsers are often used to initiate cyberattacks. Targeted attacks may use watering holes or spear-phishing messages with links, while commodity threats often originate from malicious ad campaigns or are downloaded by software bundlers. With this being one of the most common entry points for malware, you might be excited to know that Windows Defender Advanced Threat Protection (Windows Defender ATP) tracks the origin of most files that are downloaded by Microsoft Edge or Google Chrome, and that you could use this information on Advanced hunting to search for abnormal activities or pivot to related machines.
In most cases, FileOriginUrl and FileOriginIP are the URLs and IPs from which the file was downloaded, while FileOriginReferrerUrl is the URL that referred or linked to the download URL. This referrer URL is often the URL of a site page or a webmail page with a download link. Alternatively, this referrer URL might just be the previous link in a long chain of redirects used to proliferate malware.
It is, however, important to note that any program could set these fields in the Zone.Identifier alternate data stream, so the usage and actual meaning of values may vary. For example, during file extraction, many file compression apps use the path of the archive as the FileOriginReferrerUrl of the extracted files. As a result, this field will contain a local path instead of the expected web page URL.
In some cases, we could get the file origin information from other sources, but would still upload it to use the above columns. Specifically, in Windows Defender Antivirus events, the file origin details are received from the IOfficeAntiVirus API, which is used by browsers, Microsoft Office, file-sharing apps, and many other apps to request the enabled AV to scan downloaded files. In these events, FileOriginUrl is set with the URL from which the detected file was downloaded.
795a8134c1