Kali Linux comes with a number of web path brute force utilities and when using these tools, you will find that one will work better over another when pointing at Server A versus Server B.  That could be any number of reasons including defense mechanisms which is why I’d suggest changing the user agent -- something I wrote about for Nikto.

These tools are pretty simple as long as you have the correct syntax.  That is -- until they don’t work which happens.  In those moments, you start bouncing around between this tool, that tool, and another tool expecting a better outcome.  In pentesting, there are a lot of tools and techniques to learn and the web brute force utilities are simple enough that we don’t spend time figuring out what they do behind the scenes.  That said, if you take a moment and look at it from the server side, you might see why the scan is failing. 

Read more: Understanding Web Path Scanners

AWS Lightsail makes it (too) easy to fire up a new server, install an application, and let it loose on the Internet.  You have to learn somewhere and that's as good as any place but let's do a little housecleaning on the default apache2.conf file.  

If we scan our stock apache server, we get some errors:

+ Server leaks inodes via ETags, header found with file /, fields: 0xb3
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type

Read more: Nikto Apache Findings

Penetration testers come from all walks of life but there are two obvious sources which I see most often -- IT and development.  Each come with advantages but eventually we'll need to fill in the gaps with the knowledge of the other.  My background is in IT and my skills in system and network administration run deep.  I'm filling in the software development gaps though.

If you're starting out in penetration testing and you're like me, first you'll need to learn how to read code and get to a point where you understand what you're reading.  It takes time but eventually, you'll see patterns and you'll recognize functions, variables, and other common syntax.  You might not be able to write code from scratch at this point but you be able to understand what's going on.  Once you get to this level, pick a language and rewrite what you see.

Read more: Rewriting Exploits: Webmin Arbitrary File Disclosure

In my last post, I talked about a mail tracking service which uses essentially the same technique that an anti-phishing service would use.  You embed a hosted object on a server and when the message is opened, the object will render.  When the object is rendered some function on the other side is looking for that callback. 

The setup --

We need a single white pixel hosted on a webserver with a valid SSL certificate.  With Let’s Encrypt, we can add a free SSL certificate to any server.  You could try it without the SSL certificate but I think the call out to HTTP would cause a problem.  I haven’t gone through the steps of testing this without HTTP, it was more of an exercise of how quickly as easily this could be to setup something functional.

Read more: Anatomy of a Mail Tracker

There have been plenty of articles written on Responder.py and LLMNR / NBT attacks.  A quick recap:  Essentially, computers are asking for resources, the requests are being intercepted (and poisoned), and NTLMv2 hashes are captured.

If you haven’t played with Responder.py on a network with a few dozen computers, it’s pretty amazing.  It seems to work best in the morning when people are starting up their machines.  But even then, it takes a few hours to capture some hashes.  I’ve never run it with the goal of capturing every hash but I would bet if that was your goal, it could take at least a day to get every hash.

Read more: Defending Against Responder.py

I have a vendor that uses a service, mailtrack.io, which embeds a single white pixel into email messages for tracking purposes.  When the message is opened, unbeknownst to you, your mail client will render the white pixel and then I assume mailtrack.io informs the sender that the message was read.   Pretty simple actually and clever.  But I’m watching outbound traffic and I saw the outbound connection to mailtrack.io.  When I opened the source of the email, I noticed the line calling the hosted pixel which clued me into what was happening.

Read more: Blocking Email Trackers