The source record, not a headline
Incidents are built on the leak, log, listing, or leak-blog page collected for your domains. We do not summarise someone else's news.
In production for SOCs and MSSPs
The dark web, already written
The dark web, already written
as an incident.
Sentinel is the threat-intelligence desk your board thinks you already have. We take commercial darknet collections — leaks, infostealer logs, forum listings, leak blogs — and write what a senior analyst would: what is confirmed, what is theatre, and what to do before the next buyer or the next journalist. In-house SOCs run one queue. MSSPs run the whole book from one operator desk.
40+
Organisations already on Sentinel
MSSP
Native multi-tenant operator mode
SOC
Tickets to close, not a dark-web search box
Live
In production with in-house teams and providers
Why Sentinel
Search products create investigators. We create decisions.
Dark-web platforms are indexes for people who already know what to query. Sentinel is the incident that lands when your domain appears — ready for the SOC, the SIEM, and the customer on the other side of an MSSP.
An incident the SOC can own
Confirmed versus claimed, a recommended action, structured fields. Your team closes a ticket. They do not learn a new search UI.
Judgement at the speed of the collection
The expensive part of dark-web work is sitting on the dump. Sentinel writes the first-pass incident as soon as the record exists.
Enterprise SOC and MSSP, same platform
Customer logins see one organisation. Operator logins see the book of business. That is how Sentinel is modelled — not a checkbox on a slide.
Outcomes
What changed after the incident existed
Representative engagements from the current customer base. Names withheld. The work is the same class as the sample cards below.
Same afternoon
Industrial OEM · DACH
Exclusive VPN access listed. The session was dead before an affiliate converted it.
An initial-access broker posted Fortinet SSL-VPN into a manufacturing tenant, with OWA crops as proof. Sentinel wrote it as critical, not as a forum mention. The SOC killed SSL-VPN sessions and rotated the path the same afternoon. No encryption event followed.
14 accounts contained
Regional bank · Nordics
Infostealer logs named the bank's OWA. Resets landed before the fraud window.
A cluster of logs showed mail. and vpn. hosts for the bank in public previews. Sentinel did not treat that as a $15 classified ad. Fourteen identities were reset and sessions revoked in the same shift. No successful wire left the core.
Ahead of the press
Hospital group · UK
Leak-blog countdown with two real proof files. Legal had language before the first call.
A ransomware affiliate listed the group with a 48-hour clock and downloadable samples that matched internal paths. Volume claims were marked unproven; the theft of the samples was not. IR, legal, and comms worked from the incident card — not from a screenshot in a chat.
22 tenants, one desk
MSSP · multi-country
One operator queue. Twenty-two customer portals. No cross-tenant bleed.
A provider replaced a shared spreadsheet of dark-web 'hits' with Sentinel MSSP mode: operators generate and review across the book; each customer sees only its incidents, domains, and closing notes. Onboarding a twenty-third tenant did not require a new product.
1,100 cards pulled
Payments processor · EU
BIN-matched dump. Issuer notified while the cards were still useful to fraud.
An underground dump carried PANs in the processor's BIN range. Sentinel opened payment-card incidents with last-four and expiry, not a raw dump in email. The issuer pulled 1,100 cards the same day. The fraud desk did not find out from a customer complaint.
MSSP mode
One operator desk. A portal for every customer you protect.
Sentinel is already running in MSSP tenancy: operators see the full book of business; each customer login sees only its domains, incidents, and closing notes. You do not export a CSV and hope nobody pastes the wrong tenant. You generate, review, and deliver per customer — from the same product the in-house SOCs use.
- Operator access across every tenant you run
- Customer access that cannot see another organisation
- Incidents, ingest, and closing notes scoped to the tenant
- The same analyst-grade write-up, at MSSP scale
Coverage
The exposures a serious SOC already tracks
Credentials, infostealers, dark-web mentions, domain exposure, payment cards — each one a severity, a judgement, and a record the SIEM can file.
Domain exposure scoring
A current picture of how visible each monitored domain is on the dark web — not a port scan, and not a one-off report.
Credential exposure
Corporate identities in dumps and combolists, triaged so the SOC resets what is live and ignores what is noise.
Infostealer intelligence
Which employee, which URL, which session — written as an incident, not left as a raw log for someone to interpret at 2 a.m.
Dark-web collection
Forums, shops, leak blogs, and authenticated chatter naming your brand, people, and infrastructure. Coverage the search vendors sell. Judgement they do not.
Payment card exposure
BIN-matched cards from underground dumps, flagged while they are still useful to a fraud desk.
SOC and SIEM delivery
A portal the security team can operate, and structured JSONL the stack can file. Same incident. Two doors.
How it works
Collection in. Decision out.
01
We collect against your domains
Leak, infostealer, mention, risk, and payment-card records from commercial darknet collections — the corpus a senior analyst would search if they had the time.
02
We write the incident
Severity, what is confirmed, what is only claimed, and the action. The model does the first-pass analyst work the moment the record lands.
03
Your SOC — or every tenant you run — acts
In-house teams work a single queue. MSSPs work one operator desk across customers, each tenant seeing only its own incidents.
What the SOC sees
Incidents written the way an analyst would
The same card your team opens in the portal: what is confirmed, what is only claimed, and the next step — not a search hit.
Initial access broker
Exclusive Fortinet SSL-VPN access to acme.co listed on XSS Forum
An initial-access broker is selling what they call exclusive, currently working VPN access into acme.co — not a stolen infostealer log, and not a public password dump. What we can confirm from the post (2026-08-28, XSS Forum / exploit.in-class board): - Seller: QuietLedger (handle only; no reliable attribution beyond this alias) - Offer: exclusive corporate access, Fortinet SSL-VPN, claimed valid at time of post - Asking price: $8,500, escrow, “no resale” - Proof posted in-thread: cropped screenshot of Outlook Web at mail.acme.co showing the Acme directory pane (~1,200 visible mailboxes in the crop), and a second crop of a FortiClient “VPN connected” toast with hostname vpn.acme.co - They advertise MFA as “already passed” — that language usually means a stolen cookie or an already-authenticated session, not a password they typed in the post What this is not: - Not proof the session is still live as of this incident - Not proof QuietLedger is inside the network beyond the VPN edge - Not a ransomware leak-blog post. There is no countdown and no stolen file listing Assessment: listings of this shape are how ransomware affiliates buy a foothold. Exclusive + live-session language is a same-week IR problem, not a “monitor the thread” problem. Treat the Fortinet edge and any session advertised against vpn.acme.co as hostile until hunting says otherwise.
Recommended action Open incident response now. Assume a stolen or brokered Fortinet session: kill SSL-VPN sessions, rotate the advertised access path, hunt FortiGate/auth logs around the listing window for QuietLedger’s claimed geography (they wrote “EU corp, 1.2k seats”), and block re-auth from unknown devices. Do not wait to “buy the access to verify.”
- Forum
- XSS Forum
- Actor
- QuietLedger
- Access type
- Fortinet SSL-VPN (claimed exclusive)
- Asking price
- $8,500
- MFA claim
- Session already passed
- First seen
- 2026-08-28
- Proof in thread
- OWA at mail.acme.co; FortiClient connected to vpn.acme.co
- Judgement
- Confirmed listing + branding in screenshots. Session liveness unproven. Ransomware follow-on is the default next step for this market.
Ransomware leak blog
Acme listed on the RedScribe leak blog with a 48-hour countdown
A ransomware affiliate has published a victim page for Acme on the RedScribe data-leak blog. This is not a forum rumor and not an access-for-sale post. It is a public pressure page: branding, a countdown, and sample files meant to force a call. What we can confirm from the blog post (first seen 2026-08-30 14:11 UTC): - Victim title: “Acme — manufacturing, ~1,200 seats” - Countdown: 48 hours to “full publication” - Claimed haul: 420 GB, “finance, HR, CAD” - Two proof files are actually downloadable from the blog, not just screenshots - File 1: a 3-page PDF whose footer and letterhead match public Acme investor materials, plus an internal path in the metadata: \\files.acme.co\Finance\FY26\board_pack_draft.pdf - File 2: a CSV header crop showing columns EmployeeID, CostCenter, IBAN — 40 rows visible, names redacted in our copy; the hostname in the document properties is finance-ws07.acme.co - Onion blog URL and a Telegram mirror with the same countdown clock (clocks match) What this is not: - Not proof they still have a live foothold inside the network - Not proof the remaining 420 GB exists — leak blogs routinely inflate volume - Not a negotiation channel you should use. The “contact us” form on the blog is theirs Assessment: the two files are real Acme artefacts, so treat data theft as confirmed even if the volume claim is theatre. Countdown pages are extortion, not disclosure. The operational question is whether RedScribe is still in the estate; the legal/comms question is what those two files already prove to a journalist.
Recommended action Stand up IR and legal on this ticket, not a monitor-the-thread task. Assume the two proof files are stolen: preserve them, do not download the rest of the blog archive onto a production box. Hunt for the affiliate’s access path (the IAB listing for vpn.acme.co is the working hypothesis). Prepare external language that admits sample documents were published, not “420 GB.” Do not reply on the blog or Telegram mirror.
- Leak blog
- RedScribe
- Countdown
- 48 hours
- Claimed volume
- 420 GB (unproven)
- Proof files
- 2 (board PDF, HR CSV crop)
- First seen
- 2026-08-30 14:11 UTC
- Mirrors
- Onion blog + Telegram
- Internal traces in proof
- files.acme.co\Finance\… ; finance-ws07.acme.co
- Judgement
- Confirmed theft of at least the two samples. Full archive and live access unproven. Extortion clock is real; volume number is probably not.
About
Threat intelligence as a practice, now as a platform
Sentinel started as hands-on TI: take the dark-web record, decide what it means for the customer, write the incident. That is still the product. The queue of people sitting on dumps is not. Forty-plus organisations — including MSSPs — already run it in production.
You keep a portal for the security team. You keep structured output for the SIEM. An API for the same stream is next.
- Built on the actual leak and infostealer records, not summaries
- Portal of prioritised incidents your customers can operate
- MSSP tenancy in the product, not as a custom build
Get started
Request a briefing
Tell us the domains you protect — as an in-house SOC or as an MSSP. We will show what the collection already holds, the incidents Sentinel writes from it, and how tenancy works for your book of business.