Hacker TLDR;

• Blind XSS techniques: NahamSec shares some nuggets of wisdom ranging from his own custom infrastructure setup, involving a XSS Hunter JS payload and PHP payload parser. Alongside this, he covers a .htaccess configuration which allows him to catch all required information needed to hunt down the XSS. Not only that, his methodology he uses when hunting BXSS is also covered. Dive into the expertise he shares to up your blind XSS game.

• A 40k bounty, not a bad bug right? NahamSec bridges the gap between web and desktop application hacking, with a write up covering a seemingly innocent HTML injection which resulted in RCE (Meta refresh -> attacker site -> RCE || \ -> UNC Path -> Leak password hashes via NTLM Auth)

• XSS Testing methodology: It’s no secret NahamSec is on top of his game when it comes to XSS. Explore his insights into his approach and the testing methodology he’s refined over the years for XSS.

• Tips NahamSec used for his recent Bounty Success: NahamSec’s massive success in bug bounty and content creation was no stroke of luck. Delve into the priceless insights he provides for fellow critical thinkers.

Desktop Application Hacking

NahamSec made a natural progression into desktop application hacking during a live hacking event, but what does desktop hacking entail? When we’re talking Desktop applications, think Slack, Teams, or Discord being installed locally.

Desktop applications are unique in the sense that they often rely on web-based technologies for communications but also have access to the operating system, and operating system related APIs.

The merge of these two ecosystems, from a hacking perspective, this results in a unique threat model where the lines can sometimes cross over, especially when it comes to exploitation.

NahamSec’s experience with web hacking led to him finding numerous HTML injections but additional controls (namely CSP) on the core web app that the desktop application communicated with resulted in some vulnerable, but unexploitable behaviour. This was equally as true with desktop behaviour where potentially exploitable gadgets (gadgets = behaviour) were identified, but we’ll get into the details below.

Context is key

HTML injection by itself won’t be getting any high or crits, but when combined with knowledge of both browser and desktop application behaviour, it can lead to impact. Let’s break down the exploit NahamSec used:

• A HTML injection in the application

• Use the HTML injection along with a meta tag payload to refresh the page and redirect the user

• Use \\\\ instead of // in the payload to bypass validation on / characters

• \\\\ gets normalised to // when rendered by the browser, resulting in the payload being functional and executed

• Combine this with desktop application fundamentals, including protocols such as SMB, can allow you to craft exploits which can lead to RCE due to the way file descriptors are interpreted by the operating system and the behaviour of the protocols associated with them.

  • An example being, if you browse to something starting with smb:// or a double back slash \\\\ the desktop app essentially hands this type of connection over to the operating system. When this happens with SMB in Windows, not only are the hashes for the current account sent to the specified location, it also allows for certain file types to be interpreted and sometimes executed

This resulted in a 40k bounty. As we said, pushing yourself to learn new areas of hacking pays, right?

Recon, Methodology and Testing

Recon Tips

NahamSec is a renowned recon artist, this became common knowledge from his previous streams on Twitch and Youtube. This guy's not just about showing off his skills, though – he drops some seriously cool lessons learned from his time in the recon game. So, if you're into the world of recon, you gotta check out what NahamSec's laying out:

• Automate the boring stuff. Make a cronjob, setup alerts on Discord or Slack and move on or learn other things.

• You make money from finding good bugs, not just recon. The point of recon is to find more things to hack.

• Find your strength, there is no wrong or right here. Being strong in certain aspects of hacking isn’t a weakness, it helps refine your specific approach to a target.

• Don’t be scared to transition into new areas of hacking. Pivoting into new areas leads to growth and results which translate into both bounties and personal growth.

We’ve done the recon.. now what?

When it comes to hacking for NahamSec, a key part is pattern recognition for specific vulnerabilities or specific behaviours on a given target, and then exploiting the sh*t out of it. His approach can be broken down into the following:

• Identifying a pattern or behaviour for a specific vulnerability - take XSS, input being reflected for example

• Fuzz fields with characters and payloads specific to that vulnerability category - such as quotes and basic HTML entities as a polyglot and see how the application reacts

  • Note: A polyglot in this context is a payload which is crafted to be interpreted in numerous contexts - 0xSobky breaks down JavaScript based XSS polyglots here

• Examine and focus on the filtering in place - what was filtered, what was modified or transformed, did any tags break out of the context, what didn’t?

• Using this context gained from the prior steps, craft a payload to improve impact. This is driven by the target itself, the functionality the target offers and so on

When it comes to spending time on a program NahamSec also follows a general rule of thumb:

• Select a program that will pay enough, are interesting enough to hack on, or are companies that he’s hacked on before

• Day 1: First 4 hours of understanding the application, observing behaviour application behaviour

• Day 2: Extend attack surface, start looking for bugs

• Day 3: Find bugs or give up

Bounty Success - Q3 and Q4

NahamSec saw massive success in Q3 and Q4 - the journey on the success came from figuring out what worked on an individual level, for him. This didn’t come as easy as some people might think, over a years worth of hard work starting in November 2022 and coming to fruition in Q3 2023. His stats from H1 can be seen below:

How did this success happen and how did he figure out what worked for him? Some tips include:

• Breaking down goals with a diary: What the goal is, what the plan for the week is, and how to go after it

• Collaborating with new hackers on things he wouldn’t usually collaborate on or with

• Finding the balance in schedules to cater for both content creation and bug bounty

• Identifying areas of on a specific company no one else was hacking on

• Spending time to understand the taxonomy of the company - what they would consider as a high/crit, what they care about, and so on

What NahamSec Does Differently with XSS

XSS is a pretty freaking versatile bug - it's great in chains and there are many different types. One of the bugs NahamSec has been pounding on lately is blind XSS. Here are some of the great tips he dropped on the pod regarding BXSS and why he looks for it.

What is it?

Blind XSS is similar to stored XSS with the main difference being where it’s executed - instead of it executing on the front application you see, it happens on a backend app where a companies team sees it.

Where to hunt for it?

Think of what a company would want to collect on you. When you register to something, you might register your name, email address, credit card info, maybe even browser information. Other information that could be used to trace you, or your device and browser. This is all information that might end up on a backend somewhere that is later used by engineers for example.

A natural part of hunting for blind XSS however is not knowing if or when the payload will execute.

How do we get the payload to execute?

It's important to think about how your payload will be perceived on the backend - are we injecting into input fields? textareas? HTML context? Attribute context? Then we need to craft our polyglots/payloads specifically for that context.

Then, we need to get the company's employees to trigger the payload. Identify what would make an employee visit our profile in the admin portal. How can we trigger logs? How can we trigger alerts?

An easy way to get someone to look at the account is to get the account banned or generate large amounts of traffic to make the account standout, ie report the account for example.

Tracking Blind XSS Execution

This is a freaking good one.

Ben mentioned that he uses a modified version of XSSHunter for his payloads which is better fitted to his workflow. This is broken down into an own domain only used for blind XSS, which hosts XSSHunters JavaScript payload without the XSSHunters backend. This payload hooks into a PHP backend Ben made himself which is responsible for tracking the payload. The PHP backend was written by none other than ChatGPT.

Then, he uses a .htaccess file to redirect all paths to the PHP file which triggers the callback. By using this system, he can easily notate in the path of the callback where the input was created from. For example, he might use https://domain.com/TARGET-UpdateProfile-FirstName as the src of a script tag in his payload.

Genius.

Using Blind XSS to Your Advantage

When a blind XSS fires, a typical payload used is to capture the users DOM. What this means is you can essentially see the page they are currently on which gives you a massive advantage as a hunter.

You can gain info from this such as what technologies they use, the context of where your payload triggered, how they store data, application templates etc. This can be useful and drive future testing for the target.

Blind XSS and CSP

An area of discussion on the pod was whether Blind XSS payloads should be modified to accommodate CSP. Ben was pretty clear that he didn't think it was a big issue as many apps on the backend wont have CSP in place as that's not a part of the threat model for an internal application.

Justin, however, mentioned that it might be a good idea to use different types of HTML elements may trigger on the background such as an img tag or style or font callbacks.

I personally agree with Ben on this one - I don’t think its worth the extra effort, but to each their own!

Going the Extra Mile in Bug Bounty

Going the extra mile in bug bounty plays a big part in NahamSec’s bug bounty journey. Going to extra mile often translates into buying premium versions of products, going through ID verifications, customising your instance and so on. He even details times of having to send physical letters to the company to unlock additional features (no auth bypasses there unfortunately). All jokes aside, this is often a step a lot of hackers stop at, but going through additional processes and onboarding can lead to a massive attack surface being unlocked on the target.

NahamSec clearly is a veteran in the bug bounty world - this episode was littered with nuggets of advice. Be sure to check out his Youtube channel for additional tips, tricks and breakdowns!

As always, keep hacking!