TGViewer
Channel Public Channel
Blue Team Alerts

Blue Team Alerts

@blueteamalerts

Bringing the latest Blue Team news and information fresh to your Telegram inbox! 🔮

Red Teamer? Checkout @redteamalerts
Subscribers
15.5K
Photos
0
Videos
0
Links
22.2K
Recent Posts 20 shown
Post #22313 39
Post #22311 148
Decision steering against an agent-security classifier: false alarms from forged and legitimate review notes
We tested whether text claiming an earlier security approval can change an agent-security classifier’s verdict. I’m part of the Patronus team behind the tested model, Wolf Defender Jev.The relevant threat boundary is the content returned by a tool or retrieval system. It can contain a forged approval, a fake security-review block or an instruction aimed at the classifier itself. A detector’s verdict is not evidence that the claimed approval or source is authentic.Our fixed-family probe used 500 held-out decisions and 760 synthetic manipulation texts, with 15 claim families in English and German, before and after the content, plus neutral controls of the same length. The 70,620 decisions include repeated variants of those cases.At a p=0.5 threshold, none of the originally detected indirect tool-output injections flipped to benign under the worst tested claim family. Risky agent actions reached 0.7% flips and direct attacks with context 0.6%. Single-sentence attacks were weaker: label redefinition gave 9.8%, against 3.4% for neutral added text.These are conditional flip rates, not overall miss rates or a guarantee against adaptive attackers.The false-alarm direction is operationally relevant. Benign documents with a note claiming “benign” were flagged in 25.3% of cases. An “attack” note produced 43.8%. Quoted attack examples in course material were flagged in 38.3%. Those are constructed probe-group results, not measured rates on a company’s document corpus.That creates a problem for teams ingesting review annotations, security reports and training material. The classifier may treat commentary about a verdict as instructions to an AI reviewer. A forged approval can fail to suppress an alarm, while a genuine review note still produces one.The integration implication is to keep authenticated review status and permissions outside attacker-controlled document text. Content classification, provenance verification and tool authorization are separate signals. The model supplies only the first kind of signal; it does not authenticate a security team or verify a signature.We published both the bypass and false-alarm results, including the limitations: probe description and result JSON. Both are publicly accessible without a signup.For an operational evaluation, I’d include legitimate review notes and quoted attack documentation as benign controls, and measure induced alarms alongside evasion. Otherwise the test can reward a detector for becoming suspicious of everything.

Discuss on Reddit: https://ift.tt/UIkYSPC
@blueteamalerts
huggingface.co patronus-studio/wolf-defender-jev · Hugging Face We’re on a journey to advance and democratize artificial intelligence through open source and open science.
Post #22310 143
What role should user behavior analytics and insider risk signals play in DLP?
My company recently had a data breach scare and now we're trying to find a solution to reduce Insider threats and departing employee data theft. Our static DLP rules seem to miss a lot of these situations and we are now reassessing what our user behavior analytics signals should be. Does anyone have any tips for using insider risk signals to up our data security?

Discuss on Reddit: https://ift.tt/luiaV4z
@blueteamalerts
Reddit From the blueteamsec community on Reddit Explore this post and more from the blueteamsec community
Post #22308 171
Hayabusa-Bulk-Runner: run Hayabusa across a whole folder of per-host KAPE collections and get one cross-host triage view
Built this in my free time and figured this crowd might get some use out of it, or at least tell me what I've got wrong.Hayabusa, by Yamato Security, is excellent on a single host. You point it at a directory of event logs and get fast Sigma-based detections with an HTML summary. The snag for me is what an engagement actually looks like: a folder of KAPE collections, one per host, some loose and some as VHD/VHDX. I end up mounting each image, running Hayabusa on each host one at a time, then stitching the results together by hand.Hayabusa-Bulk-Runner does that part. Point it at a folder with one entry per host and it mounts each image and runs Hayabusa on every host, then rolls the lot into a single cross-host triage dashboard showing which hosts are worst and which rules fired where, alongside the per-host reports and timelines. It is not a detection engine and not a replacement. Every detection is still Hayabusa's. It just does the batching and the triage view on top.Evidence handling, since it matters here: it only ever reads the evidence. Disk images are never mounted directly. It creates a read-only differencing child over the image and mounts that, and it hashes the source before and after to show it was untouched.Upfront: I built it with Claude Code, partly to see how far I could get on something I'd actually use. So treat it like any tool you didn't write yourself. The code is there to read, it has a Pester suite and CI across PowerShell 5.1 and 7, and I've run it against KAPE output, but verify results before you lean on it for casework. It's early and will have rough edges. MIT licensed. Hayabusa is AGPL and called as a separate program, I don't bundle it or its rules, you bring your own.Repo: https://github.com/rorywag/Hayabusa-Bulk-Runner
Hayabusa: https://github.com/Yamato-Security/hayabusaHappy to take bug reports, feature ideas, or a straight "this is wrong because". That's mostly why I'm posting.

Discuss on Reddit: https://ift.tt/LMEnj1Q
@blueteamalerts
GitHub GitHub - rorywag/Hayabusa-Bulk-Runner: Bulk-run Hayabusa across a folder of KAPE collections, one run per host, with per-host reports… Bulk-run Hayabusa across a folder of KAPE collections, one run per host, with per-host reports and a cross-host triage dashboard - rorywag/Hayabusa-Bulk-Runner
Post #22301 220
Observed fake Claude Code ad / DLL sideloading chain with blockchain C2 (EtherHiding) - IOCs included
We came across a malware sample pushed through a paid search/ad impersonating Claude Code. I reversed it over the past day. Putting the detection content first so if you're not interested in the analysis.Quick summary: a renamed, legitimately signed JetBrains binary sideloads a malicious libcef.dll, the real payload is a .NET exe hidden inside icudtl.dat, it pulls its C2 from a smart contract on BNB Smart Chain (EtherHiding), and it escalates to SYSTEM by abusing the Steam Client Service.The payload is hosted on Google Cloud Storage, but the delivery URL carries a Microsoft Advertising click ID, so the ad was most likely served through Microsoft/Bing Ads.Domains/infra to block or hunt for:
hxxps://storage[.]googleapis[.]com/claudeapi/claude[.]html?msclkid=a5ca8dd81bbc1cea0dcee714b86f8877BSC contract 0xc1907d7be91f95903ad66d775c397302e7dd9228eth_call selector 0x6d4ce63c to: bsc-dataseed[.]binance[.]org bsc-dataseed1[.]defibit[.]io bsc-dataseed1[.]ninicoin[.]io
Those RPC nodes are legitimate public infrastructure. Consider alerting on eth_call from noncrypto processes rather than hardblocking if you need it.Files/paths to look for:
Claude.exe + libcef.dll + icudtl.dat together, outside a JetBrains install%LOCALAPPDATA%\Cache-<8hex>\ (u.exe / u.dll / u.bin, x\ subfolder)%TEMP%\w<8hex>\ (launcher.exe + libcef.dll + icudtl.dat + signed.vdf + run.vdf)%APPDATA%\Roaming\LocalCache\
Mutexes:
Global\WinCacheSyncGlobal\WinCacheSyncE
Process/behavior to look for:
Claude.exe (jcef_helper.exe) or launcher.exe spawned by steamservice.exepowershell.exe ... Add-MpPreference -ExclusionPath ...writes under HKLM\Software\Valve\Steam\Apps\431960\drop of signed.vdf / run.vdfoutbound eth_call JSON-RPC from a non-crypto processscheduled task CacheMaintenanceTask
Hashes we observed. Note the Claude.exe hash is a legitimate signed JetBrains file, so label it or you'll alert on real IntelliJ users
Claude.exe (legit JetBrains jcef_helper.exe, renamed)SHA256: 84292c4128ae5baca4115d3f5049b9fee990d281cc8da6c7a57ea837cda7d239libcef.dll (malicious loader)SHA256: a48c0099a304d4e74ba03e3d593684b841592912852aafb563d9726e815a9e3dicudtl.dat (ICU data + encrypted payload)SHA256: 01ffce3ba619135750e1b8cfed6ab1b74b9d64b1c3f8eb30618f09dc7733b978job.exe (decrypted .NET payload)SHA256: 711b3f407d1f80ad7002dea228f62f4e1b04e4c8e58de5771d4a97c8e15dcca5
Full analysis below for anyone who wants the detail.Initial download came from a Google Cloud Storage bucket:
hxxps://storage[.]googleapis[.]com/claudeapi/claude[.]html?msclkid=a5ca8dd81bbc1cea0dcee714b86f8877
The download is a bundle of three files that must sit together:
Claude.exelibcef.dllicudtl.dat
Claude.exe is not Claude. It's a legitimate JetBrains-signed JCEF helper, just renamed:
OriginalFilename: jcef_helper.exeVersion: 137.0.17.1107Signer: JetBrains s.r.o.
It imports libcef.dll from its own folder, so the malicious libcef.dll runs under a valid signature. The fake DLL is unsigned, inflated to ~47 MB (probably to beat AV/sandbox size limits), has a mismatched 2023 timestamp, and imports mscoree.dll, which suggests it hosts the .NET runtime. I did not reverse the native loader itself.The real payload is hidden in icudtl.dat. It's genuine ICU 72 data with ~31 KB appended after the last table entry. The blob decrypts with a 32-byte repeating XOR key into a .NET exe:
XOR key: 0ee17baf699b1f1540c4f157fcbf2373fe73ee2e1cb48dd4ce81fd2192fe58afResult: job.exe (.NET assembly)
I decompiled job.exe. This is where all the behavior lives.On startup it disables TLS cert validation, sets its working dir, and computes a victim ID:
Working dir: %LOCALAPPDATA%\Cache-<id>Victim ID: first 4 bytes of SHA256(MachineName + UserName), hex
Two mutexes pick which branch runs:
Global\WinCacheSync (normal instance)Global\WinCacheSyncE (elevated instance)
For C2 it uses EtherHiding, so there's no domain to block. It sends an eth_call to public BNB Smart Chain nodes, reads the bytes the contract returns, hex-decodes…
  • 🔥 1
Post #22299 253
Post #22298 269
How do you keep track of certificates and cryptographic keys across your environment?
I’m curious how other blue teams handle certificate and cryptographic key management in practice.With servers, cloud services, internal applications, and different teams managing their own infrastructure, it seems easy for certificates or keys to get overlooked. Expired certificates are one problem, but knowing where keys are stored, who has access to them, and whether they're being rotated properly seems just as important.Do you rely on existing security tools and internal scripts, or have you found dedicated management platforms worth the effort?For those who have improved this process, what made the biggest difference? Better visibility, automated alerts, access controls, regular audits, or something else?Would appreciate hearing what has worked for your team and what hasn't been worth the effort.

Discuss on Reddit: https://ift.tt/9hNLCBZ
@blueteamalerts
Reddit From the blueteamsec community on Reddit Explore this post and more from the blueteamsec community
Post #22297 298
Older posts →

About this channel

How can I read @blueteamalerts without a Telegram account?
TGViewer shows the public web preview Telegram publishes for Blue Team Alerts: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does Blue Team Alerts have?
Blue Team Alerts (@blueteamalerts) has 15.5K subscribers on Telegram, refreshed roughly every 30 minutes.
Does Blue Team Alerts know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →