What do you do?

I test web applications to understand if there's any flaws that an attacker could exploit to gain access to things they shouldn't.

What information are you given?

Generally speaking, you have white box, grey box, and black box tests.

Black box you’re given very little. A login and maybe a walk through of how to use the application. The idea being that you know nothing about the internal structure.

Then there’s white box where you essentially know everything. You’re given the code, you are told what the underlying infrastructure looks like, and there's open communication if you need more information.

Grey box is the middle bit. You get some information, but not all. I usually find those are code reviews. You get given the code, which is a lot of information, but you don't always see everything, and you don't always play with the actual application itself.

What would usually be done ?

Black box realistically. I do wish that it was more widely supported to supply code.

Why do you think that is the case?

I think there's two parts to it.

Sometimes clients don't understand what you might need from them or we’re not making that clear. Testers don't often have those conversations because it can be difficult for them get the test through.

The second part is it can also make clients feel a little uncomfortable. Clients often don't want to share code and are protective over it.

What do you think is the most effective?

For most clients, you just need to not be the lowest hanging fruit. A black box will get them everything that they need.

Favourite technique?

I love broken password reset requests. It’s a really easy to understand and it’s a really easy thing to miss if you’re a developer. You’re not always thinking about it, but there’s a great range of ways it can be broken.

An attacker can reset the password on an account and get access to it. I have seen examples where the only thing you need to reset the password is a link that contains the user’s email address.

What is something you rely on day to day?

I have a long list of notes that I refer back to and it has everything I need. A good example is my cross site scripting POCs. It’s a huge list of things for me to try. I know they work and I have seen get around certain filters.

How did you get into web app testing?

I started on service desk and then moved into a patching roll within the same company. From there, I joined a new company, that took me on with my background of vulnerability management, as a junior tester. I think that’s a very different path. A lot of web app testers start as developers.

I started with no web app knowledge apart from how to use the internet. Hack the box and that kind of thing. I did a lot of shadowing. And after about three months, I did a pen test. It was a lot of Googling things trying to figure out how things worked. From that I was learning on the job and was full-time testing.

Are there any misconceptions about web app testing?

People think you don’t have to have good people skills. You absolutely do. Not only are you trying to work with clients, you do talk to them. It’s not just emails and reports. Clients will ask you on calls why you didn’t find a vulnerability and ask for an explanation.

Do you have any difficult conversations?

You get those conversations where the test has been done last year and they didn't fix something, and you do test and don't find whatever it was. You get people who are like “why didn't you find it?”, “weren't you doing your job well enough?”

There are also people that refuse to accept when you've raised something. They might argue it’s not a real vulnerability because of X, Y, and Z. Usually they don't understand our perspective in that when we’re doing a pen test, especially black box testing, we don't know X, Y, and Z.

We've got the application in front of us and we report on what we see. A good example is “We have a WAF and we have these protections” but that doesn't change our report.

Do you think a WAF should be turned off for testing?

It's an interesting question because arguably their WAF is probably one of the biggest protections they have on their application. But WAF circumvention is a thing, and we don't have time on a pen test to sit there and try and work our way past a WAF to understand what is actually a vulnerability. So in my opinion, you should be through the WAF, because we are assessing the application, not how good your WAF is.

How does your role improve security?

You get a lot of people who think pen tests are just a checkbox exercise. And to some it is, but that’s not a bad thing. Occasionally you do find things that the client didn’t know about and genuinely are a huge problem and they need to get fixed.

I think the bigger reason it helps is because a lot of a lot of systems require a pen test. PCI DSS requires a pen test, trying to get certain accreditations requires a pen test. To pass, this essentially means not getting highs or critical findings.

Those requirements make sure web apps are not complete rubbish and don’t have glaring holes on them. And I think that’s the part that actually improves security.

┌──(insider@thread)-[~]
└─$ cat intro.txt

This week, the security world got front‑row seats to Microsoft’s clash with Nightmare Eclipse. This escalating dispute fuels broader questions about trust in the vulnerability reporting process and whether the shared responsibility model can withstand modern disclosure tensions. 

Collating insights from ex-hackers, vulnerability researchers and offensive security professionals, this post examines what this incident reveals about the state of vulnerability disclosure, whether the fallout was inevitable, and which lines may have been crossed. 

Nightmare Eclipse v Microsoft

Security researcher Nightmare Eclipse (Chaotic Eclipse) published several zero‑day Windows exploits on GitHub after claiming Microsoft ignored their vulnerability reports and deleted their MSRC account.

Microsoft still has chains in my hands, it’s been like this for years and I just can’t stay silent anymore. I hope I can release the documents soon.

Reference: Nightmare Eclipse blog post

The researcher was subsequently banned from GitHub (and GitLab) and has since threatened to release additional exploits on 14 July.

Mark this date July 14th, I will make sure your bones are shattered that day.

Microsoft Response:

Microsoft stated that it “firmly opposes” uncoordinated disclosure and warned that releasing proof‑of‑concept code for unpatched vulnerabilities was “never justifiable” have “real‑world consequences”.

The published vulnerabilities RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma have since been seen under active exploitation in the wild.

Bug Bounty and Vulnerability Disclosure

In 2025 Microsoft payed out $17M in bug bounties, the highest total bounty awarded in the program’s history.

Bug bounties are a valuable layer in a modern security program, providing a structured path for responsible disclosure, compensating researchers, and helping organisations identify issues before attackers do.

Bug bounties can be run through platforms like HackerOne or Bugcrowd, while some organisations handle vulnerability disclosure in‑house or outsource it to third‑parties.

AI and vulnerability disclosure

The availability of AI‑assisted vulnerability research is straining the disclosure model. AI‑driven scanning tools have flooded many bug bounties with low‑effort reports, prompting vendors to tighten scope, raise thresholds and reduced bounties.

Reports can outpace both the time and financial capacity of bug‑bounty programs. The trend is already visible in Apple’s bounty categories announced in October 2025, which represented a downgrade in compensation for macOS including TCC bypasses.

But dismissing low‑hanging fruit has drawbacks. Many time constrained researchers use proof of concept submissions to gauge how responsive a program is. Brushing these off not only discourages engagement, it also overlooks the risk of chained low‑severity exploits, where minor flaws can be combined into full compromise.

Bug bounties rely on mutual trust.

Disclosure programs can lean on tactics that erode trust with researchers, for example:

• Lowering bounties

• Poor engagement from vendors

• Drawn out disclosure processes

• Downgrading the impact of a vulnerability

• Retroactively updating bounty scope to exclude a disclosed vulnerability

These can signal that a vendor no longer values the findings, can’t address them, or isn’t willing to pay for it. Researchers may move on to other platforms, and in the worst case, it can push actors out of the responsible disclosure ecosystem.

“Ethical Hacking” Incentives

Many in the security industry call themselves “ethical hackers”, though any job that needs ethical in the title can feel uneasy. Few would be reassured by an “ethical doctor”.

More accurately, offensive security and vulnerability research operate at the intersection of legal constraints, contractual obligations, personal interpretations of the law, and their own moral compass.

Motivation plays a significant role in participation in bug bounty programs. Often there is a blend of incentives such as reputation, financial reward, developing skills or a genuine desire to improve security. But if every “ethical hacker” were driven purely by the latter, perhaps more would sit on vulnerabilities until vendors were ready?

The reality is more complex. Some researchers choose do not disclose, either for their own use (such as in red team engagements) or wait until the vulnerability has found its way into the public domain to reduce damage.

The case for public disclosure

Most security professionals would attest that security by obscurity is no security at all. Bug bounties exist precisely because disclosure pressure is often the only mechanism that forces improvements, particularly in sectors where security is treated as an afterthought.

Vendors like to pretend like responsible disclosure is a moral duty, but really it’s just a courtesy to the vendor, and one they take entirely for granted. The path of least resistance, when it comes to getting a bug fixed, is to just post it publicly. It forces the vendor’s hand, and requires no further effort on the researcher’s part.

Reference: Marcus Hutchins LinkedIn post

Examining Crossed Lines

What lines were crossed in Nightmare Eclipse?

The catalyst appears to be Microsoft deleting the researcher’s MSRC account. While the communications leading up to this are not public, this suggests that Microsoft was no longer willing to engage with the disclosure process.

There are assertions that the actor could have been a former employee. Inside knowledge should always come with additional ethical and contractual obligations.

There’s the escalation, publishing highly destructive zero‑days. Cyberattacks have caused real‑world harm, especially those that disrupt critical national infrastructure and healthcare services. While some may recognise negative disclosure experiences or empathise with the frustration, it drags an already fragile ecosystem into dangerous territory, with pressure mechanics that resemble double‑extortion ransomware.

Finally there’s the threats; of further public disclosures and of pursuing legal consequences, which represents a complete break down of mutual good faith on which a viable disclosure process relies.

Conclusion

The incident is still unfolding and raises important discussions around whether the bug bounty model is still fit for purpose. The sentiment is well summarised by the prophetic insights of dudetechitout from 2025.

Incident Response Consultant

I’ve learned over time to go with forgiveness over permission.

I think it really depends on the company that you are working for and how fast internal processes within a company are working. Cybersecuity operations side of things is about timely response. If your processes are slow, as long as you’re not breaking any laws and impacting massively, sometimes you might have to ask for forgiveness.

Give an example?

Say you need to review a draft report and the client really expects it because its time sensitive, and the people who are supposed to review are all on leave. You might just release it as a draft. Make sure it is caveated. If changes need to be made, you make it before you issue the final deliverable. But at least you give something to the client something to digest and prepare and a bit of an idea of what they can expect in the final report.

Why has that changed over time?

I think a lot of it was about confidence and understanding what you are doing, and the limitations. There are clear red lines that you can’t cross. As a consultancy, you can’t put the company at risk. If you release a report that is not appropriately caveated, and the client relies on information that is inaccurate, that increases the risk of liabilities.

Security Engineer

I think there is a balance here. I come from a position of technical development. I love building things. From that point of view, I find it a bit stifling when you have a great idea, but maybe the organisation's not ready for it. Maybe it needs to go through some levels of approval or maybe even if it is a good idea, they just don't think it's the right time.

Those kind of situations sort of give you a desire to be like, I'll just do it and seek approval later. But organisations have compliance and and change processes for a reason. You need to be careful about what you are deploying into your environment. If everyone was able to take a cowboy approach, go and build whatever they wanted, you could end up with vulnerabilities, shadow IT or holes in your defences that you weren't aware of.

It needs to be loose enough that you have that ability for creativity. You have that ability for people to come up with proposals that maybe a bit outside the box, maybe something you haven't thought of and they could really benefit the organisation. But also, there does need to be some level of oversight and management of the whole process.

Web App Tester

I'm going to say permission. I wouldn’t say that in most cases, but with pen testing, I think the risk of legal consequence is a little too high.

We are set a very strict scope, and we are told what we can and cannot do, and we are told what we have to ask about. If anything is even marginally outside of that or there is a chance that I could break something the client could get very upset and pursue legal consequence.

There are laws against hacking websites when you're not allowed, and these are laws can be enforced with jail time. So, you do not want to step outside those bounds.

What what steps do you take to make sure you're within the lines?

I am very particular about my scope. If I get a scope and the URL is even slightly different or there is a domain that's not included I will go and check.

What damage could you cause to an application?

You would be surprised what damage you can cause to an application. If there's a chance that it could cause harm or it could get somewhere that it's not supposed to, I just stop. It's usually things with SQL injection. SQL injection can get really weird, really quickly. You can find out perhaps information that you should really shouldn't have. Once I've found it, I will stop. I will email the client and ask if they want me to continue.

I do know of someone who sent off an automated Burp scan and deleted a back end database. That's not to say don't use Burp scan. It was a very badly implemented web app that never should have been pen tested. But it is an example of what can be done with something that you think is completely safe.

SIEM Engineer

I would say forgiveness. Either we have had a small incident and something had to be done and we just couldn’t wait for permission.

Isolating a few machines, just do it, rather than having something potentially spread. Take a calculated risk, if it is a core part of the business.

Subscribe now

┌──(insider@thread)-[~]
└─$ cat summary.txt
6 years experience

Incident response [IR] and security operations as a consultant.

When you’re doing forensics you are dealing in probabilities. There is the classic problem of you can’t ever be certain. 

What do you do?

Incident response and security operations as a consultant. Incident response is anything from planning, preparation and response to incidents. Security operations includes SOC [Security Operations Centre] transformation, operationalising the SOC and making it more efficient.

How do those relate to each other?

They are all on the defensive side. You need to have these teams communicate and collaborate constantly. If you don’t have one it would be hard to do the other.

How did you get into IR?

It was just by chance. I started as part of a detection engineering and threat hunting team that got merged into incident response.

It was probably the best way to get involved into incident response. Starting with threat hunting taught me to spot suspicious activity in a safer environment. But during incidents when the worst has already happened or is happening, the threshold for mistakes is lower.

What is a misconception about IR ?

Everyone thinks it’s this interesting James Bond style thing. It’s a lot less exciting, a lot of excel. You have huge amounts of data and you need to use it to reconstruct what an attacker did.

What do you find most rewarding?

The impact. You are responding to attacks that impact peoples’ day to day lives. I like the crisis and incident side of things.

There are incidents that can be categorised as breaches, where the attacker didn’t action on their objectives. For incidents that materialise and result in crisis scenarios, the business operations are impacted.

That means the business is no longer able to provide what they are providing, or public sector, they can’t deliver what they are supposed to deliver to citizens. Going to your doctor is something everyone can relate to. The doctor needs to use a system to give you medication, write your prescription and get your history up so they can properly investigate. Imagine if those systems are down.

How do you manage a crisis scenario?

That’s probably the most stressful situation for a client out there. There is huge pressure on you. It’s about constant communication, being honest, providing real updates and managing the expectations.

Everything is burning, everyone is calling you, they are trying to find out what’s happening. In a crisis situation you normally talk to the client three or four times a day in short updates just to discuss about progress, next steps, where we are, and what we found out. But also getting the download from the client on what they have been working on the latest developments.

What are some challenges of IR?

When you’re doing forensics you are dealing in probabilities. There is the classic problem of you can’t ever be certain really.

You need to be careful around probabilistic language. One that I learnt over time (painfully) is never use “there is no evidence of”. It’s always “We haven’t identified evidence of” because you can’t be certain there is no evidence, maybe you just missed it.

You said in forensics you are dealing in probabilities, what do you mean?

You can never have the confidence that your data is capturing everything that an attacker is doing. There are things that are not captured depending on the data you are relying on. So sometimes you need to make informed guesses or come up with hypotheses.

EDR / XDR [Endpoint Detection and Response / Extended Detection and Response] is designed to record as much data as possible that you will use during incidents or for detection. But if we’re analysing classic Windows artefacts, that data hasn’t really been designed to be a forensics log or a security log. It’s used by Windows for different functionality and we are just lucky enough to be able to use it for reconstructing what is happening on a system.

Can you give an example of what you mean by artefact reconstruction?

Probably the easiest example is prefetch. It’s included in Windows to preload the execution of binaries. The first time you are clicking on a binary, Windows will create this prefetch file and load some memory so that the next time you are executing it, it executes faster. That is quite useful for forensics, because it will record recent execution times for that specific process.

What are the limitations?

From experience something that is usually lacking from that data (like amcache shimcache, registry keys, and so on) is understanding how privilege escalation happened. What you can see is how the attacker moved laterally, some of the software that has been executed, the files that have been accessed on disk.

You might see the attacker using one account, and then connecting with an administrative account. So clearly there has been some privilege escalation there, but you can rarely get a glimpse into how.

Are there any specific tools you like to use?

I try not to stay attached to any tool at one time. They tend to change and evolve all the time. It’s more about feeling, staying excited for the field and the projects you are working on.

As an IR lead, how do you gain confidence in delegating analysis?

It’s about trusting your team. Trusting that they will come to you when they have questions or when they aren’t sure.

Encouraging them to do that and to ask as many questions as possible. I’d rather you ask me a hundred questions [at the start] than you not coming back to me with any update for two weeks, at which point it is probably too late.

Having a structured way of analysing things, like a list of artefacts that you as the response lead provide to people in advance. You are the main point of contact, you are scoping the incident. It applies to any kind of project, you are understanding what is needed and devising a plan of action that is then discussed and communicated to your team.

What changes are you are seeing in IR?

Full disk forensics is a lot less common that it used to be. I came into IR as the transition was being made from full disk forensics to collecting artefacts.

When analysing systems, you are relying on specific data sources that we call artefacts. Before cybersecurity tooling was a thing, you’d have to collect the whole disk, all your log sources would be extracted from there.

I remember the first time I had to do my first full disk forensic acquisition. I had to pick up about thirty laptops. Driving up to the client, getting chain of custody signed and completed. Putting laptops in evidence bags and making sure that the whole process is followed. That is the kind of thing you don’t want to mess up in any way.

You’ve mentioned collecting artefacts is more common, what do you think that drives that?

Nowadays, through the tooling and the fact that most servers are now hosted on cloud, the prevalence of SaaS [Software as a Service] etc. logs are just made available to you. All you need is a quick way to collect these.

What are the benefits of artefact collection?

From a consultants point of view, we have a duty to act in the interest of our clients. If that means collecting artefacts is possible rather than a full disk image, we should do that, so long as it doesn’t impact the accuracy of the data.

If I collect the data faster, that means I can focus more of my time on analysis. That means I can provide an update quicker to the client and maybe even the project will end up cheaper for the client.

If we are talking about endpoints, you can just use your XDR tool to just retrieve only the data sources that you need. That saves time, which is essential during incident response. It opens the avenue for automation, which is great. You don’t need to travel (to client site) as much. You just give the client the collector to run on their systems, and the data is back with you within hours.

This article was written following an open discussion. Responses capture the essence of the conversation, but may not be direct quotes and details are anonymised.