Exploit tips

From Grayhat cheatsheets
Jump to navigationJump to search

Some useful tips concerning different types of exploits and exploitation techniques:


Metasploit tips[edit | edit source]

  • In metasploit, using "set VERBOSE true" can give us extra information on why an exploit is failing. Also, if the exploit admits proxies, we may send it through a proxy and capture it with burp. In Burp, we can go to proxy -> options -> add one and redirect to the host and port of the target the exploit that we launch against our proxy. Ippsec uses this in Hackthebox's Artctic.
  • Always check if the exploit we are launching from metasploit has a staged payload or a non staed one, and if one fails, try the other.
  • Important tip for metasploit: if a reverse shell payload doesn't work, don't think the exploit is not going to work. Sometimes bind shells work better than reverse shells. If one fails, try other payloads.

Webapp exploits tips[edit | edit source]

General tips[edit | edit source]

  • If some web application is installed on the victim, don't discard looking on google for things like "vulnhub walkthrough webapp name". There are may people writing the solutions to vulnerable practice boxes, and these types of webapps are common, so it is a good way of finding a step by step solution to compromising a certain vulnerability. Sometimes exploits are cryptic, and it can be useful to see someone else using it instead of wasting time fixing it or understanding complicated usage or options.
  • If a file upload service (maybe once we are logged in some webapp) checks for filetypes, it can block our uploads when we attempt to upload something like a php shell. It may be checking the "magic bytes". These are the first few bytes of a file. We can try to create a file of the type expected by the webapp, for example jpg images, and then append our shell. With the command "file" in the linux terminal we can check the type of file after these changes, to see if it still is detected as the expected type by the webapp. Then, if all goes well, we will be able to bypass the upload filter and hopefully be able to execute the shell.
  • There can be several open source programs, webapps, CMS, etc, with the same name. Don't rush when using exploits, at least in not for very well known programs. It can be easy to discard candidate exploits if we look in the source code of the exploit for certain files it attacks, etc, and then check in the source code of the application (for example in github) if those files actually exist. If not, then the exploit probably corresponds to another application and is not going to work for us.
  • If a website responds very slowly to our normal requests but an exploit apparently works very fast and finishes, we can be sure that there is something wrong with the exploit, and we need to debug it. It happens in Hackthebox's Arctic.
  • If a php app accepts GET requests with parameters, add a single quote as these parameters. It may raise errors which we can leverage to do SQL injection. Happens in Vulnhub's IMF.
  • If an exploit sends something to a php script of a webapp, and in the exploit code somehow a URL is created, to be sent to the target, we can try to enter that same URL in the browser, because it may produce useful output in the browser that we couldn't see on the terminal if we just launch the exploit. It happens in Vulnhub's com80, in the mantis app, where we can enumerate users in the browser but not with the exploit directly.
  • First of all, discard the obvious stuff. If we arrive at a website with some kind of "non custom" application, that is, something that already exists on github or some other such place, and has beed installed, don't waste time trying to reinvent the wheel, and look for exploits for that webapp or service. It can help to look at the bottom of the page, or in the source code, to look for things like "powered by wordpress", or the icon that appears in the browser tab, for example in the case of drupal websites, we immediately see what technology powers the website and can look on google for exploits or exploitation vectors for that particular version.
  • For open source CMS, login pages of common webapps, etc, always look in the documentation or in google for the default login credentials. Not always are they changed, and in that case we are in. Or even if not, we can brute force passwords with the default user, and vice versa.
  • If a webshell is unable to upload files to a compromised server, try to find one that uploads with multipart/form-data. Useful for Coldfusion.
  • If there is some installed web service, or webapp, it doesn't necessarily mean that is fully functional, and known exploits for that version may not work because some functionality has been disabled, or is installed in a non default path, and we must modify what path the exploit is launched against.
  • If we find some website with some command execution capabilities, that executes commands passed by GET requests, after the ? in the URL we can attempt to get some long command, like a python reverse shell single command (like those of pentest monkey), copy it in the hackbar, and convert the whole command to urlencode. Then, paste the result in the argument in the URL, and maybe it will be interpreted as a single command, giving us the shell.
  • The common.txt wordlist for dirb has proven sometimes more useful than the bigger wordlists that come with dirbuster, don't forget about it.
  • If we cannot locate a clear entry point in a webapp, go page by page, paying attention to the structure of the URLs (for maybe some insertion point), or look at the source code. This happens in Vulnhub's Zico.
  • Sometimes there are more than one webserver on a machine, running on different ports, one of them often in a non conventional HTTP port number. One of them might work whereas the other doesn't. Usually the first one we find in this case with simple nmap scans (typically in port 80) is the useless webserver. This happens in Vulnhub's Rickdiculously Easy.
  • Always check manually for the robots.txt file in web servers, even if Nikto doesn't seem to find it. There are cases where Nikto doesn't locate this file, but it is there.
  • If we should have cookies because we have started a session on some webapp, but cookie manager doesn't have any, send the login through Burp and look at the HTTP response by the web server, the cookie will be there.
  • When we login in some webapp to a restricted area, run again directory brute forcers, now we will be able to find new directories impossible to finde before the login. This happens in Vulnhub's IMF.
  • Many times, when we browse the IP of a host in a web browser, and we arrive to Apache's default page, we need to browse an actual URL instead. If we know which one it is, we can make the correspondance of IP and URL inserting them in a new line in /etc/hosts, separated by a blank space, or pass the request through Burp, and change the IP with the URL. This may happen because virtual hosting is used, but the default Apache welcome page wasn't removed when we browse the IP.
  • In robots.txt, "user agent *" means "every", but if a specific user agent is used, we may try to change it, sometimes we can access things we couldn't otherwise, by doing this. So if in robots.txt user agent has a specific value, spoof that value in your future requests. There are also firefox plugins to modify or add headers to every request.
  • If you are trying to get a reverse shell with netcat from a webapp which can execute single commands and it is not working, try changing the ports employed. In Vulnhub's Rickdiculously Easy, only port 4444 could be used to get a reverse shell. Other usual port that works in these cases is 443. Try these two first.


  • Short term cookie never gets stored in the browser, long term cookie does. Secure cookie only gets sent by an encrypted channel.
  • httponly: flag that can be activated on a cookie, which prevents access to it from javascript. Prevents against XSS.
  • NAT (private addresses behind a router) is only effective against direct attacks, but not against indirect attacks like XSS.


  • If Url encoding (%XX for unsafe characters) is used, it is indicated in the HTTP header, the content type encoding html indicates that html encoding is used. Other methods for encoding are unicode encoding (UTF-7, 8, 16, 32).


  • PHP executes not only .php files, also .php3, an old format. Sometimes it can be useful to upload files with this extension, in case something is filtering files by extension, and .php files are blocked.
  • Same Origin Permission, SOP, avoids that some domains or subdomains can interact among themselves.


  • IDS and IPS defend at network and transport level, look at tcp and udp headers from incoming and outgoing packets, look at protocol compliance, for every syn packet they do a state model. They prevent agains DOS.
  • Deep packet inspection, looks at data and headers, looking for spam, viruses, protocol noncompliance, keywords, etc. Can sometimes be bypassed with compression, encoding, encryption, or tunneling. The problem with compression or encryption is that then packets need to be preprocessed after arrival. IPS is like IDS + a firewall, it also can block packages. They can be installed on a computer belonging to the network, or in a server dedicated to that function alone.
  • Web Application Firewall (WAF): Appliance, server plugin or filter that applies rules to http conversations. Protects against XSS and SQL injection. WAFs operate in the application layer, while IDS work typically in the network layer usually. To bypass it we need to find a way to get a reverse shell.

SQL injection[edit | edit source]

  • In login pages, first of all, insert come quotes combinations in the different text fields, we may be lucky and get indications that SQL injection is possible, and don't need to waste time in other things. It happens in Hackthebox's Cartographer challenge. Always try the attacks that will take less time to check in the first place, and leave brute force as a last resort, or launch it in parallel, meanwhile you will be trying other manual attacks.
  • The SQL UNION instruction combines the results of two selects, with the same number of columns, with the same type of data, and the same order.

SELECT xxx FROM table1 UNION SELECT 1,2,3... creates a dummy table and if any of these new elements appears somewhere on the table, we can substitute it in the query to ask the table for data, with things like @@version, @@datadir, database() o user(). With LIMIT we limit the number of results.

  • The most common way to identify if we can try SQL injection is try break the sql syntax by introducing quote symobols, like ' or " and get an error. From there, work your way up to complete the injection.

With the SQL instruction: order by, we can get to find the number of columns, by increasing the order by parameter, until we get an error. Then, the previous number was the number of columns. We can read a file with SQL injection with SELECT xxx LOAD_INFILE We can write a file with SELECT INTO OUTFILE/DUMPFILE

  • Types of SQL injection:

-error based (easy) -union based (gives more data) -blind (difficult) Tools for SQLi: mieliekoek.pl, wpoison, sqlmap...

  • In SQL, the information_schema table has all the information about how the database is, permissions, users, etc


XSS[edit | edit source]

  • XSS is mostly useful for stealing cookies, but can be used for defacing and clickjacking (a trainsparent layer is laid on top of the actual website, with forms, etc, and we get the user's input). For example, in a signup fomr we may write: fake_name" onmouseover=evil_script

People will not see the onmouseover part, but it may execute if not sanitized, when people hover their cursor over our name. It can be used, for example, by trolling on a forum, so that admins click on our name to say us something, and then the evil part executes and we may steal admin credentials.

RFI & LFI[edit | edit source]

  • When we are trying RFI but have problems having the server find our local file, do in another terminal "tail -f /var/log/apache2/access.log", or better still, use the Python simple HTTP server. With both options you will see in real time the incoming requests into your own server, and you will be able to troubleshoot the errors by looking at how the requests are coming. It is better to use Python Simple HTTP server because it doesn't interpret php tags, so it will be easier to upload our php shells (with apache they would be run by our machine when requested from the victim, and we would need to do things like echo each line).






Wordpress[edit | edit source]

  • Very important for wordpress websites: in wp-login.php, if we haven't been able to find users with wp-scan, we can still do brute force attacks, by trying many different users for the same password. The important point is that in Wordpress error messages are different if the user exists or if it doesn't, regardless of whether the password is correct or not. With this we can enumerate users, and then do the usual password brute force for the ones we have found that exist.
  • In the Wordpress file wp-config.php there are passwords of the MySQL database, with which we should be able to access through wp-login or phpmyadmin. In Vulnhub's Zico, even the same password can be used to access through SSH.
  • Wordpress stores uploaded files in wp-content/uploads/year/month/file

Login tips[edit | edit source]

  • If there is an SSH port open, try first obvious combinations, like root/root, or username/username. Also, do a little brute force in likely users.

Public (non Metasploit) exploits[edit | edit source]

  • If a C exploit fails to compile, look inside the source code to see if there are single and double quotes, maybe all should be set to double quotes.
  • If a system has the "Samba" implementation of the SMB protocol (that is, it is a linux host), we can look for exploits for Samba directly, it can be more effective than regular SMB enumeration or exploits.
  • If we modify a public exploit that performs buffer overflow, we should pad our shellcode with NOPS so that it is as long as the original shellcode.
  • Run a couple of times Nmap vulnerability scripts, maybe there are timeouts and the result may not always be equal.

Shells[edit | edit source]

  • Example of a bind shell that can be used if a target has the "bad" version of netcat insalled, which doesn't have the -e option to send commands. It was useful in c3po of practical pentest labs.

mkfifo /tmp/mypipe2

cat /tmp/mypipe2|/bin/bash 2>&1|nc -l 6000 >/tmp/mypipe2