Updated my GitHub to include a new script and added a link to my GitHub page on the sidebar of this blog. The script in question is the fetchDomino which is an utility that allows you to dump all Domino Lotus user’s password hashes. This script was created to replace Domino Raptor which did not work for me during testing of Lotus Domino 8.5
In a few words, this script can be used when we get access to the the Domino’s names.nsf file. Some servers may have this file completely exposed to the Internet, others instead would require authentication thus a brute-force attack or another attack vector may be required to get in. Once you have access to names.nsf, fetchDomino will come very handy as it will collect all user’s hashes in the database for you. Then use JTR dumbo patch with the “lotus5” format to crack these hashes.
If you are looking for a guide in how to hack Lotus Domino, refer to the document below:
This post is the second part of the Hacking .NET Applications serie. The first part can be found at the following URL:
In this second part I am going to show how to extract, analyse and tweak the .NET application.
Until recent times, I was only aware of a single way to extract code from the .NET application, that is by using a (now) commercial tool called .NET Reflector. This tool is still awesome and allows you to retrieve the application source code. However, re-compilation of the code cannot be done, if you are wondering If that was possible!
For a work engagement, I had to study how to hack .NET application. I am glad i had to do this. No really worth to say it; this post will go through some of the techniques I have learn from this experience.
I found two approaches of hacking .NET applications. The first one is by using a debugger and retrieve as many information as I could and possibly utilise the power of the debugger to perform changes to the run-time code.
The second is to disassemble the application to retrieve IL code, study the application and potentially hard-code changes on the IL that will be re-assembled into a new hacked version of the application.
I’ve seen several web applications implementing the user session ID (or token) in a custom HTTP header parameters thus avoiding to store the session ID in cookies. Additionally, some public web platforms save the same kind of token to track their user analytics. For instance, recently I notice that this mechanism was utilised by the New Relic REST API platform which is storing the user ID in a HTTP parameter called X-NewRelic-ID.
During testing of an application, I have found both a cross-site scripting and the session ID sent as HTTP header parameter . My goal was to steal the user’s session ID, which was sent to the application as X-Auth-Token in a custom HTTP header parameter.
This post contains a collection of instructions useful for pentesting an Android app I found on the Internet. Basically, It is my Android cheatsheet and it’s here so that it will be easily accessible in the future from me or anyone else that has to assess Android devices and apps.