-
Different Drupal versions have different architectures and different features. If an exploit is based on Drupal's core components, it can be used for older versions as well. Other module- and plugin-based exploits may not work in the case of different Drupal versions.
-
It is a good practice to install Drupal locally to test an exploit. If we are successful in exploiting Drupal locally, then we can use the same exploit on a remote Drupal site.
-
Sometimes, there's a Web Application Firewall (WAF) placed in front of the web application, meaning that an exploit doesn't run successfully. In that case, we can either obfuscate or encode the payload used in the exploit and bypass WAF protection.
-
If we have access to the Drupal administrator account, we can enable the PHP filters' module and configure the permissions for it. Once the permissions are set, we can write a web shell on the site. We can even upload a web shell by exploiting arbitrary file upload vulnerabilities (this works on some versions of Drupal).
-
While performing file and directory enumeration, if we come across a .swp file, we can use this to our advantage. A SWP (pronounced swap) file is a state file that stores the changes that have happened in a file. Sometimes, administrators edit the Drupal configuration file (settings.php), meaning that a .swp file is created. If we can access the settings.php.swp file, we can get our hands on globally set variables such as database usernames and passwords, which can be used for further exploitation.