I recently published a security research post on the myAudi connected vehicle platform. I found that anyone with a VIN can access a sensitive informations about car and ownership
I think the topic is useful beyond Audi itself, because many vendors now rely on these “connected vehicle” platforms and mobile apps, often with very similar architectures and assumptions

Across all major ShinyHunters campaigns (AT&T/Snowflake, Salesforce, Canvas/Instructure), only one event has both a publicly stated payment amount and a known approximate settlement date: the May 2024 AT&T payment of ~5.7 BTC (~$370K), confirmed by Wired but never published with a transaction hash. I use that as the analytical anchor for an end-to-end on-chain analysis using only free public data.

Pipeline (5 stages):

1. BigQuery bulk filter on amount and time window → 500 candidates.
2. Recipient profiling via Blockstream Esplora (lifetime tx count, spend shape).
3. Sender-side cluster analysis using common-input ownership; looking for broker-aggregation patterns.
4. Depth-12 concurrent forward trace, top-K=4 fan-out.
5. Terminal attribution via OKLink, BitInfoCharts, WalletExplorer.

Result:

A single highest-fit candidate: 5.71997804 BTC paid 2024-05-17 22:04 UTC to a fresh recipient, spent in 6 min, laundered through a 6-cycle automated peel chain, terminating at an exchange deposit cluster. Funding side shows broker-aggregation fingerprint (4× 1.147 BTC peels in a 90-min window pre-payout). Upstream hub addresses appear reused across multiple victims of the same laundering service, active through 2025. Paper closes with the legal pathway from chain endpoint to indictment and a scoped compliance-request template.

Limitations (explicit in §5):

Ranking under a scoring scheme, not positive ID. No off-chain ground truth. Documented OKLink vs. Arkham label conflict on the dominant terminal, resolved via behavioural audit. No formal null-distribution analysis yet. Score weights are author judgements.

Asking for:

1. Technical feedback / methodology critique.

2. arXiv cs.CR endorsement — endorsement code: ZQXBSQ

   github.com/tr4m0ryp/shinyhunters-gotta-catch-em-all/blob/main/Gotta_Catch_Em_All_ShinyHunters.pdf

Tooling and dataset released for reuse

The traditional vulnerability disclosure timeline relies on a fundamental assumption: exploit development and vulnerability discovery take time. Over the last 12 months the integration of LLMs into offensive tooling has demonstrably broken this assumption.
I recently published a technical write-up arguing that the 90-day disclosure window is effectively dead backed by three specific observations from recent incidents:

1. Automated Diff Analysis (30-minute n-days) : The safety net between a patch release and an in-the-wild exploit is gone. Taking a recent React security patch (CVE-2026-23870), I used an LLM to analyze the diff, identify the vulnerable path, and write a working DoS PoC in roughly 30 minutes. The human reverse-engineering bottleneck has been bypassed.
2. Vulnerability Convergence : I recently reported a critical P0 to a vendor and was told I was the 11th reporter in 6 weeks. LLM assisted scanners are causing independent researchers to converge on the same bugs simultaneously. An embargo no longer contains the vulnerability; it simply provides a head start to whichever threat actor also found it.
3. The Linux Kernel (Copy Fail & Dirty Frag) : The recent kernel exploits highlight this perfectly. Copy Fail (CVE-2026-31431) went from an automated AI scan to a public PoC to nation state weaponization in days. Shortly after the embargo for Dirty Frag (CVE-2026-43284 / CVE-2026-43500) was broken in hours because an unrelated third party independently discovered the same bug class using similar tooling.

The defense cannot operate on monthly cycles when the offense is operating in hours. The focus needs to shift to real-time, PR-level AI scanning to match the pace.
can read the full technical breakdown and case studies on my blog:https://blog.himanshuanand.com/2026/05/the-90-day-disclosure-policy-is-dead/

I am curious if the researchers here are experiencing similar convergence rates or if you view this as a temporary anomaly while legacy codebases are scanned with new tools.

I built a realistic enterprise security architecture guide covering SPOFs, insider threats, and budget implementation

I recently investigated an individual operating through Odysee and Telegram who is selling a malicious Android RAT known as EagleSpy V6.0, which appears to be a rebranded version of CraxsRAT.

During the investigation:

\- I was financially scammed after payment

\- The seller blocked communication afterward

\- The malware infrastructure was analyzed in detail

Technical analysis confirmed:

\- Banking phishing overlays

\- Crypto wallet credential theft

\- Telegram bot exfiltration

\- Remote shell execution

\- Keylogging

\- Camera/microphone access

\- GPS tracking

\- Ransomware components

\- DEX packers for AV evasion

\- Hidden update/backdoor mechanisms

The repository also contained evidence of real victim infrastructure and compromised device information.

The malware appears capable of targeting not only victims, but potentially even buyers/operators through embedded update systems and hidden control mechanisms.

Relevant reports have already been submitted to platform abuse teams.

Odysee channel involved:

https://odysee.com/@justicerat:e

Telegram:

@JustIcedevs

This post is intended purely as a cybersecurity awareness warning to help prevent additional victims.

If moderators require technical validation or indicators of compromise, I can provide structured analysis details privately.

CVE-2026-31432, CVE-2026-31433, and others