u/allexj

Hi everyone,

I need advice on how to get YesWeHack staff to intervene or review a ticket, as I don't see a "Request Mediation" button on the report interface.

The Situation:

• My Report: I submitted a Critical bug (CVSS 9.6) regarding an iOS/Android app. The vendor accepted it, paid a bounty (though underpaid by ~60% based on their own matrix), and explicitly wrote: "We will apply for a CVE on your behalf and list your name as the reporter." After the payout, they completely ghosted my follow-up messages.
• The Suspicion: A few days ago, a public CVE dropped for the exact same app. The CVE was "Reserved" just 3 days before the vendor promised me the credits in writing.
• The Dilemma: The public CVE credits Cisco Talos and the technical description is different from what I reported (it talks about unencrypted legacy APIs, whereas I reported a TLS chain validation flaw). However, given the identical timeline and app, I strongly suspect they might be related, or affecting the same component.

Since the vendor is ignoring my comments, I want YesWeHack to step in so I can get clear answers on whether this CVE is connected to my findings, and why the payout matrix wasn't respected.

My Question:

What is the best way to open a support ticket or call for mediation with YesWeHack staff when a vendor ghosts you? Has anyone experienced something similar?

Thanks!

Take a look, for example, at the section "3 ways AI hallucinations are impacting cybersecurity": https://thehackernews.com/2026/05/how-ai-hallucinations-are-creating-real.html?m=1#3-ways-ai-hallucinations-are-impacting-cybersecurity

It feels verbose without saying much of value.

Using reliable services that usually (I know they are not perfect) get detection right, such as "gptzero.me", it turns out that it was indeed written by AI.

Where will we end up if even articles discussing the risks of AI are written by AI?

We need to introduce some regulations and require that a specific pattern or signature be included in some way within the text, images or videos generated, so that we can determine whether or not the content is of human origin. Is there a study or discussion underway somewhere in a law firm or research centre looking into this?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

I have a technical question about how Microsoft Defender for Endpoint (MDE) and Windows Sandbox interact at the network level.

The scenario: Host PC with MDE and Network Protection enabled. Host alerts are regularly forwarded to a SIEM/SOAR. I open Windows Sandbox on the host PC and, from inside the isolated environment, I try to browse a known malicious site (e.g., phishing or C2).

The question: Considering I'm using the Sandbox, does the host's Network Protection still manage to intercept the request, block it, and trigger the alert to the SIEM? Or does the Sandbox isolation "hide" the traffic from the host's Defender, preventing the alert from triggering?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Please if there is a way, tell me