On any IIS server where you get a 302 you can try stripping the Host header and using HTTP/1.0 and inside the response the Location header could point you to the internal IP address:
You can upload .config files and use them to execute code. One way to do it is appending the code at the end of the file inside an HTML comment: [Download example here](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Upload%20Insecure%20Files/Configuration%20IIS%20web.config/web.config)
More information and techniques to exploit this vulnerability [here](https://soroush.secproject.com/blog/2014/07/upload-a-web-config-file-for-fun-profit/)
As summary, there are several web.config files inside the folders of the application with references to "**assemblyIdentity**" files and "**namespaces**". With this information it's possible to know **where are executables located** and download them.
From the **downloaded Dlls** it's also possible to find **new namespaces** where you should try to access and get the web.config file in order to find new namespaces and assemblyIdentity.
Also, the files **connectionstrings.config** and **global.asax** may contain interesting information.
As any .Net application, MVC applications have a **web.config** file, where "**assemblyIdentity**" XML tags identifies every binary file the application uses.
In the previous output you can references to several "**assemblyIdentity**". These are files that may be located inside the /bin folder. For example: **/bin/WebGrease.dll.**
In addition, .Net MVC applications are structured to define **other web.config files**, having the aim to include any declaration for specific namespaces for each set of viewpages, relieving developers to declare “@using” namespaces in every file.
From a very previous response, the declaration of a **custom namespace** \(since other namespaces are defaults\) suggests that a DLL called "**WebApplication1**" is present in the /bin directory.
Let's suppose that the previous DLL is importing a namespace called **WebApplication1.Areas.Minded.** an attacker can infer that other web.config files are present in the application, in guessable/default paths as **/area-name/Views/**, containing specific configurations that may refer to other DLL files present in the /bin folder.
Note how in the previous output you can see a new namespace called: **WebApplication1.AdditionalFeatures** which indicates that there is another Dll in the /bin folder called **WebApplication1.AdditionalFeatures.dll**
It means that the server **didn't receive the correct domain name** inside the Host header.
In order to access the web page you could take a look to the served **SSL Certificate** and maybe you can find the domain/subdomain name in there. If it isn't there you may need to **brute force VHosts** until you find the correct one.
### Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure
You can try to **enumerate folders and files** inside every discovered folder \(even if it's requiring Basic Authentication\) using this **technique**.
The main limitation of this technique if the server is vulnerable is that **it can only find up to the first 6 letters of the name of each file/folder and the first 3 letters of the extension** of the files.
You can use [https://github.com/irsdl/IIS-ShortName-Scanner](https://github.com/irsdl/IIS-ShortName-Scanner) to test for this vulnerability:`java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/`
Original research: [https://soroush.secproject.com/downloadable/microsoft\_iis\_tilde\_character\_vulnerability\_feature.pdf](https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf)
You can also use **metasploit**: `use scanner/http/iis_shortname_scanner`
### Basic Authentication bypass
**Bypass** a Baisc authentication \(**IIS 7.5**\) trying to access: `/admin:$i30:$INDEX_ALLOCATION/admin.php` or `/admin::$INDEX_ALLOCATION/admin.php`
You can try to **mix** this **vulnerability** and the last one to find new **folders** and **bypass** the authentication.
ASP.NET include a debugging mode and its file is called `trace.axd`.
It keeps a very detailed log of all requests made to an application over a period of time.
This information includes remote client IP's, session IDs, all request and response cookies, physical paths, source code information, and potentially even usernames and passwords.
* **`decryptionIV`** \(string\): hex-encoded initialization vector \(defaults to a vector of zeros\).
* **`decryptionKey`** \(string\): hex-encoded key to use for decryption.
However, some people will use the **default values** of these parameters and will use as **cookie the email of the user**. Therefore, if you can find a web using the **same platform** that is using the ASPXAUTH cookie and you **create a user with the email of the user you want to impersonate** on the server under attack, you may be able to us**e the cookie from the second server in the first one** and impersonate the user.
This attacked worked in this [**writeup**](https://infosecwriteups.com/how-i-hacked-facebook-part-two-ffab96d57b19).
