The following are the steps to follow, when encountered by a web application in a Capture The Flag event. These steps are compiled from my experience in CTF and will be an ongoing project.


Spider:

One can use BurpSuite or Owasp-Zap for spidering web application. In burp, intercepted packet can be passed to the spider for automated spidering. For web applications integrated with login facility though, manual spidering through burp is advised to avoid spider from stepping on logout link.


Files Of Interest:

The following files are often seen in CTF, to be very useful to look into.

  • robot.txt
  • .htaccess
  • sitemap.xml
  • config.php
  • readme
  • Backup files


Page Source:

Analyze the source of whole web application (at least what you find relevant for the challenge). Look for comments, hidden tag or disabled tag, javascript obfuscations etc.


Stegnography:

If any images, videos or files are found on web app. Download them and check for interesting stegnos. We can use the following tools to help us find hidden content in files.

Images (binwalk, exiftool, stegsolve)

videos (TrueCrypt)


Directory Busting:

CTF challenges do not endorse brute-forcing the server but sometimes you may need to do some common directory lookups. For this you can use dirb, wfuzz or just burpsuite. In some challenges, you will have to make your own dictionary from challenge website content to bruteforce its directories, in this case cewl is your best friend.


Vulnerability Scanning:

Run a scan using nikto or nessus, you never know when you find something interesting.


WebDAV Methods:

WebDAV gives us numerous facilities that can be used to manipulate files on the web server. Given the nature of the functionality, if these are accessible by low-privileged users, they may provide an effective avenue for attacking an application. Here are some methods to look for:
- PUT uploads the attached file to the specified location.
- DELETE deletes the specified resource.
- COPY copies the specified resource to the location given in the Destination header.
- MOVE moves the specified resource to the location given in the Destination header.
- SEARCH searches a directory path for resources.
- PROPFIND retrieves information about the specified resource, such as author, size, and content type.
You can use the OPTIONS method to list the HTTP methods that are permitted in a particular directory or just use devtest tool to make things easier.


Request & Response:

Intercept all requests to the server. Try to change the relevant http header tags or request params and see how web app responds.


LFI/RFI:

Look for query string or post params (ie page=,url=,lang= etc), which might be including other files into the webpage. If LFI exists and PHP version >= 5.0.0 then try to use php resource to disclose the server side code.

php://filter/convert.base64-encode/resource="argument"

If LFI/RFI exists and PHP version >= 5.2.0 with allow_url_include ON. Try data stream method to execute shell on the server

  • create php shell payload
  • base64 encode
  • url encode 
index.php?file=data://text/plain;base64,"encoded shell"

Bypassing added suffix .php for RFI

  • To be added

Bypassing added suffix .php for RFI

  • make web server on your machine
  • create two php script first to download webshell when executed and second the webshell itself
  • To make apache treat php code as plain text (so when doing RFI from target, code doesn’t get executed on your host) do as described below
  • goto “/etc/apache2/mods-enabled/php5.conf”
  • comment the following lines 
#<FilesMatch ".+\.ph(p[345]?|t|tml)$">
#    setHandler application/x-httpd-php
#</FilesMatch>


File Upload:

When file uploads are given always check the following

Find if server is using a black-list or white-list. On both protection try

  • “file.php" or "file.php."
  • “file.php.jpg”
  • “file.php%00.jpg”

In case of content-type filter use intercepting proxy.

In case of file-type recognizer try to use

  • Magic Number of accepted files
  • Insert your code in comment section of the metadata
  • use file modifier (ie image re-sizer) to produce malicious code itself when receiving special input

Vulnerable Framework:

Check if web application is using a framework then if it has any existing vulnerabilities.

  • use searchsploit or exploit-db

SQL Injection:

When it seems like a sql injection, one can use sqlmap to make things easier but without proper use it may not detect even an existing sql injection.

sqlmap --url=http://192.168.0.100:1337/index.php --method POST --data 'username=test&password=test&Submit=Login' --not-string='Username or Password is invalid' --dbms=MySQL --batch --dbs

Never forget to do user enumeration, may find interesting things.