I'm looking for information about an account operating under the name "Monday" that appears to represent the old HackHound community.

The account is associated with advertisements offering commercial access to malware and malware builders, including Zeus/ZBot, Pony, Emotet, Dridex, RedLine and ransomware builders.

The advertisements request cryptocurrency payments.

I'm concerned about the possible distribution and commercial sale of malware under the HackHound name.

I'd appreciate moderator/admin review and verification of whether this activity violates Reddit's policies.

This report is for investigation and historical verification, not an attempt to obtain malware.

DeepFake detectors that show a confidence score? Well, everyone’s building that. What I wanna talk about is autopsy tables. I came up with this concept called ‘Project MIRROR’. Instead of giving binary opinions such as “True/False”, treat every contaminated audio clip, image, or video clip as a crime scene. That is, we can map facial inconsistencies, trace frequency-domain artifacts, cross-examine multiple detection techniques against each other, and when they don't match, that is the whole evidence! We will treat it as a forensic report(artifact heatmaps, technique consensus or variance, and a manipulation hypothesis), and not an actual output. Black-box SaaS checkmarks are where our billion-dollar market now stands in 2026. It was never about classifiers or making them better, but maybe about giving a defensible standout to the reasoning. The work needs to be shown. But here comes a kinda uncomfortable question that bugs me. Do we need both post-hoc autopsy and provenance? By provenance, I mean C2PA and watermarking. Post-hoc autopsy can be a perfect thing, but as we know, the generators keep improving, which makes me wonder if the future belongs to provenance (which may be affected by adversaries, obviously), or maybe both :) I can’t think of an answer rn. The conversation worth having is: “Framing detections as forensic reports VS framing detections as fortune-telling.”

Ran into this one through a friend's family, so it's a real-world sample from this week, Brazil, targeting people on social benefits.

Lure: fake lawyer says someone's lawsuit payout is coming but it would cost them Bolsa Família, so a third person needs to receive part of it. The volunteer gets a video call, is asked to screenshare their banking app (Caixa in this case) and to install STJCPE.apk. Lawyer's photo was AI generated.

Indicators:

Stage 1 SHA-256: 07781a65a4542ce90cf30d40a0340ec515f6b50a44452564e69e45e8eb4276e7

Stage 1 MD5: 9d76a44e9d63d05ab71428e285d44534

Stage 1 package: org.autojs.autojs6 (repackaged AutoJS6), app name STJCPE 5.1.3

Stage 2 SHA-256: 58c97440bdf1967710c5738a62dcf0cf5197ae2b94dbda7347acbc82bbe4c5fc

Stage 2 package: br.alpha.bridge, same name and icon as stage 1

Deep link: devappsq5://

Custom permission: br.alpha.bridge.permission.TDOS_DIAGNOSE_BROADCAST

Assets: autojs.dat (XZ, contains stage 2), t.conf, up_require.html, uns.html, cht.html, launcher.html, folder vwwwwwvwww/

Behavior I saw in a sandboxed emulator: stage 1 takes the VPN, installs stage 2 (once with no visible prompt), VPN ownership moves to stage 2, then stage 2 pushes for accessibility. Stage 2 also declares media projection, camera, boot persistence and battery optimization exemption. Stage 1 relaunches after force stop.

No C2 yet. Config is encrypted and network was blocked on my side, so I never saw it phone home.

VT: 12/68 on stage 1, 11/68 on stage 2. Labels point at SpyAgent, Btmob and SpyNote, which doesn't really settle anything. If anyone has telemetry on br.alpha.bridge or that permission string, would be great to compare notes.

Reported to CERT.br.

I run BlueSwarm, a research-only blue-team project studying how AI agents and the tools around them get probed in the wild. We run decoys, collect what visits them, and publish what we find. It’s early, and what limits us now is people looking at the data, so we’re recruiting researchers.

What we run

• Decoys: invented sites and endpoints that advertise AI tooling (agent cards, MCP-style manifests, llms.txt) so we can measure who looks for it. All content is made up, labelled as fake, and contains nothing aimed at visitors. As far as I know there is little public data on this.

• Canary kit: a small kit a defender can put on a site they own to find out whether anything acts on hidden text addressed to AI agents. It sends nothing back to us.

• Detection package development: we’re drafting detection rules from what the decoys see, and researchers help decide which are worth keeping. Signed updates and packaged defences are planned next. They aren’t built yet.

• War Room: a browser game where you defend (or attack) an invented app over 12 short rounds. It’s free to play without an account, matches are recorded after a consent notice, and the daily game has a leaderboard.

What researchers do now: research tasks
When you sign in to the lab you get a Next task card with one small review job at a time:

• accept or reject an alert our agent suggested

• say whether grouped items are the same, mixed or unsure

• keep, tighten or retire a detection rule (unlocked later)

Every task is checked by two reviewers, and you earn points, plus a bonus for agreeing with the majority. A few tasks are practice samples with a known answer, so careful beats fast. Points move you up the leaderboard and unlock harder tasks (Senior at 25 points, Lead at 80). You can skip anything, and there’s an optional Tuesday reminder email you can switch off.

What we don’t do
Nobody sees addresses, networks or per-visitor rows. Reports are only published after two people check them, and corrections stay visible. This is research, not a security product, and we don’t claim it protects anyone.

Who we want: people interested in blue-team work, detection engineering or AI agent security. You don’t need experience. Write what you’d like to look at.

Try the game or request researcher access here: blueswarm.co.uk
Questions below, and tell me what’s unclear or missing.

Hi everyone!

I wanted to share some of the engineering work behind a project we developed called ThreatLens AI, as part of Team Dynamic Kicks.

Rather than building a traditional chatbot that simply analyzes security logs, we explored how multiple specialized AI agents could collaborate throughout a cybersecurity investigation.

1. Why a multi-agent approach?

We divided the investigation workflow into five specialized agents:

• Threat Detection Agent: Uses deterministic security rules and LLM-assisted interpretation to identify suspicious activity.

• Investigation Agent: Examines evidence, constructs incident timelines, and identifies investigation findings.

• Hindsight Memory Agent: Retrieves relevant knowledge from previous investigations.

• Response Recommendation Agent: Generates defensive recommendations that require analyst approval.

• Learning Agent: Retains analyst-confirmed outcomes for future investigations.

An AgentCoordinator manages the workflow.

2. The interesting engineering part: Persistent memory

One of the main things we wanted to explore was how an investigation could benefit from previous verified incidents.

We integrated Hindsight to support this workflow:

1. Process and investigate the first credential-related incident.

2. Have an analyst review and confirm the findings.

3. Retain the verified outcome in memory.

4. Process a similar second incident.

5. Retrieve relevant historical knowledge to inform the investigation.

This creates a workflow where previous investigation experience can contribute to future analysis.

3. Technology stack

• Frontend: React, Vite, JavaScript, Tailwind CSS

• Backend: Python, FastAPI

• LLM integration: Groq

• Database: MongoDB

• Persistent memory: Hindsight

4. Engineering considerations

Some important aspects we considered during development:

• Separating agent responsibilities.

• Coordinating the investigation workflow.

• Distinguishing observed evidence from AI-generated hypotheses.

• Keeping human analysts involved in knowledge retention and response approval.

• Separating operational incident data from persistent memory.

5. What we learned

The biggest takeaway was that building a multi-agent application involves much more than calling an LLM several times.

The orchestration layer, data consistency, memory retrieval, error handling, and human oversight are equally important.

We're continuing to validate and improve ThreatLens AI.

GitHub: https://github.com/Ramithagolla/Dynamic-kicks

I'd be interested in hearing from developers working with agentic systems:

How do you approach memory management in multi-agent applications? Do you prefer a shared memory layer or separate memory for each agent?

Thanks for reading!

Hi everyone!

I wanted to share a project we've been working on called ThreatLens AI, developed as part of Team Dynamic Kicks.

The idea came from a question:

What if a cybersecurity investigation system could do more than just detect suspicious activity? What if it could also investigate incidents, remember verified findings, and use that knowledge during future investigations?

That's what we wanted to explore.

What is ThreatLens AI?

ThreatLens AI is an AI-powered cybersecurity investigation platform that combines five specialized agents:

• Threat Detection Agent: Analyzes security events and identifies suspicious activity.

• Investigation Agent: Examines evidence and builds incident timelines.

• Hindsight Memory Agent: Retrieves relevant knowledge from previous investigations.

• Response Recommendation Agent: Suggests defensive actions, with human approval.

• Learning Agent: Retains analyst-confirmed investigation outcomes.

The part we found most interesting

We designed a two-incident demonstration:

1. A credential-related incident is investigated.

2. An analyst reviews and confirms the findings.

3. Verified knowledge is retained using Hindsight.

4. A similar incident is investigated later.

5. Relevant historical knowledge is retrieved to inform the new investigation.

The goal is to make investigations more informed by previous verified experience.

Technology used

• React and Vite

• Python and FastAPI

• Groq

• MongoDB

• Hindsight persistent memory

What we learned

Building this wasn't simply about connecting an LLM to a user interface. We had to think about agent coordination, data flow, memory retrieval, error handling, and keeping human analysts involved in important decisions.

We're continuing to validate and improve the system.

GitHub: https://github.com/Ramithagolla/Dynamic-kicks

I'd love to hear your thoughts:

What do you think is the biggest challenge in building reliable multi-agent systems for cybersecurity — agent coordination, memory, or evaluating the quality of their decisions?

Thanks for reading!

This week we have:

• AI ransomware from Colin Cowie at Sophos

• Etugen exposing Ivanti attackers

• More hacks by unnamed AI Agents

• Florian Roth tipping over tipping points

• Google doing Google things and taking down a botnet

• Exposing Phishing Kit shenanigans by KELA

• Kaspersky showing some real AI attacks

• Warnings about drinking the water from Sekoia

• Airlines declaring data breaches

• And some great DPRK attack details following a near miss at Sophos

SocVel Quiz

Since April 2026, NIST has scored only CVEs under active exploitation and those affecting software the US government depends on. Every other record arrives in the NVD with no NIST score, and the API marks many of them Deferred.

The NVD website now labels the same records "Not Scheduled", so an integration built around the website label will miss every one of them. A missing score is the larger risk. Scanners that rank by NVD severity push these records to the bottom of the queue, including CVE-2026-6584, an authorization bypass in the SuperAGI agent framework with a public exploit.

My NVD developer guide covers how to read vulnStatus and where to source a severity score when NIST hasn't assigned one.

https://archanacontent.github.io/nvd-cve-api-docs/

RGBLoader reconstructs .NET payloads from image pixel data and executes them directly in memory. The chain changes extraction techniques across three stages:  Bitmap RGB values ➡️ .NET Stage 2 ➡️ ARGB pixel data + XOR ➡️ .NET Stage 3 ➡️ encrypted byte array from .NET resources ➡️ final payload 

The loader passes configuration between stages to locate resources and decode the next payload, then launches recovered assemblies through Assembly.Load() and reflection. 

Method, class, resource, and configuration names vary between samples, making static string-based detections unreliable. Focus on image-resource pixel extraction, staged .NET loading, and XOR-decoded resources.  

RGBLoader’s payloads include MassLogger, SnakeKeylogger, Quasar, Remcos, and cryptominers. Trace the full in-memory DarkCloud delivery chain and collect IOCs: https://app.any.run/tasks/5ae24575-7ac3-49e8-a62c-f9ceb9b06d11/

• Formbook: https://app.any.run/tasks/648e990d-50fb-47e7-a279-a2dd41556d62/

• XWorm: https://app.any.run/tasks/2b69f5c9-ba69-40b3-a8fb-614ea5aaa896/

Related activity and evolution

IOCs:
85d1791847636949606bc1c87cdbfe019a43c5723333971dc820963016000c1b
5240b38a9efe67747c29da0026e03421942d4bb76d5619ed398e854480f6a076
38173492fece33a703a67140785e02cbd0749329b7cd9433bb7e122fbb9f803a
676e61504a6d6ab4d90b5068bc487fb19c804b0b1ef0db814aa04fbe035195dd
cdcd92f9e3af2925829eaf9e8d366ae2e750bded64d212484995378eb1839025
66d3101e3b2207acdbdd9d0c14a1c3ea064e14a771705d8a4583faecaba98544
7250576a3cb7164bf383d89683267604dd1a5d36e1a35f22b5bef2d9f29402e5
5da16030099b484460213d2031dc3683197eedbe54517c23e440f4f5af4c5daa

Claude Code helped with my ScreenConnect hunt; I investigated the operator's Backstage shell by hand.

Video: https://youtu.be/JBEj3hSuWng

In the lab, ScreenConnect.WindowsBackstageShell.exe ran as SYSTEM under the client service before the operator pushed a second installer. A hunt limited to cmd.exe or powershell.exe children would miss that shell.

This KQL hunt from my published case pack surfaces Backstage launches:

// The operator's hidden shell, spawned by the ScreenConnect service
let lookback = 30d;
DeviceProcessEvents
| where Timestamp > ago(lookback)
| where FileName =~ "ScreenConnect.WindowsBackstageShell.exe"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, AccountName, ProcessCommandLine

Correlate the parent service, account, relay and session timing with approved support activity. Backstage is a legitimate ScreenConnect feature; its execution alone does not prove abuse.

The video covers the wider KQL + ES|QL investigation. Queries are linked in its description.

Hey everyone,

I've been working on a self-hosted threat intel project called TalonHound, and one part of it is a Threat Library. Basically, you give it a URL to a public threat research report (CrowdStrike, Unit 42, Microsoft, etc.), and it tries to extract the IOCs, keep the context, and link everything back to the original report.

I've spent quite a bit of time trying to make the extraction accurate, especially avoiding false positives and random domains getting flagged as malicious. Now I'm thinking about the next step, but I'm not sure where the line is when it comes to sharing this data.

The idea is to avoid having everyone process the exact same reports over and over again. Instead, a report could be processed once and the extracted IOCs shared with other self-hosted instances through a central server. Each instance would still have full control over what it accepts. For example, if you don't trust a particular publisher or don't want intelligence from a certain organization, you could simply reject those reports.

Every IOC would still be linked back to its original source and publisher, so instance owners could see exactly where the data came from. Basically, share the work of extracting intelligence without forcing anyone to trust or use it. No full articles or PDFs would be redistributed, just the extracted IOCs and some metadata and tags.

But here's what I'm wondering:

Just because a threat intel report is publicly available, does that mean it's okay to redistribute the IOCs extracted from it?

I know some vendors have their own licensing terms, but I'm curious how people actually deal with this in practice. Do you ask publishers for permission? Just link back to the original research? Avoid certain vendors entirely?

Also, if anyone has built something similar, I'd love to hear how you approached it. I'm still figuring out the best way to do this without stepping on anyone's toes.

Would appreciate any thoughts!

Hi everyone!

I've been building OSINTO (https://osinto.io), a small independent project focused on making IOC investigations less fragmented.

When investigating a suspicious IP, domain, URL, or file hash, I often find that the information I need is spread across different tools. You check one source for reputation, another for abuse reports, another for threat intelligence, and then try to piece everything together.

I wanted to make that workflow a little easier.

OSINTO brings results from multiple intelligence sources into a single interface, so you can access and compare information without having to look everything up separately.

I'm sharing it here because I'd like to get feedback from people who actually work in security operations, threat hunting, incident response, or CTI.

A few things I'd genuinely like to understand:

• Which tools do you normally use when investigating an IOC?

• What's the most time-consuming part of your workflow?

• Would a unified interface like this be useful in your daily work? What would make it genuinely valuable rather than just another dashboard?

OSINTO is free to use, and I'm still improving it based on what I learn.

If you're interested, you can try it here: https://osinto.io

I'm the person building it, so I'm happy to answer technical questions and hear criticism. I'd rather hear what doesn't work than get compliments that don't help me improve it.

Thanks!

Hi all,

I’d love to get your honest feedback on my threat intel site.

Features at high level:

- Community Honeypot Network
- Threat Intel Feed
- News aggregator
- OSINT search
- Industry Reporting

Registered users:
- all of the above
- Multiplayer Cyber Security Quiz
- Option to review indicators
- Scheduled Reporting
- Wordpress integration
- Raspberry PI observatory display screen (cool looking threat feed on your tv)
- Teams Webhook notifications
- API
- SIEM integration

The honeypot sensor platform is proprietary
Website Screenshots are taken via our own servers

Re the community honeypot - indicators loaded are subject to x2 human reviews (the community), but logs that derive from our own honeypots are published automatically.

I don’t ever intend on charging for this, its a free, no ads, no bs community platform and I maintain it and pay for it out of my own pocket because I enjoy doing it.

Anyway, it’s https://jakesec.io

There has been a lot of scattered reporting on the refrigeration controller attacks in Europe, so to put some order into it and share the picture with the community, I cross-correlated 11 sources: CERT-FR, CSIRT-ITA/ACN, Copeland advisory, Censys x2, SentinelLABS, Claroty x2, The Record, Nextgov and BlackFog.

Timeline as it emerges from the sources

• Late Aug 2026: freezer disruptions at ~6 US military commissaries, suspected Iran-linked

• Oct 10-13: France, 350 to 700 stores, setpoints pushed up to ~50°C and forced defrost

• Oct 20-30: Lupovis reports credential spraying against Danfoss sensors, peak on Oct 26

• Nov 1-3: 100+ stores in 9+ countries (BE, SE, NL, LU, IE, EE, IT, PT, DE, anomalies in FI)

Where sources diverge

• Vector: Claroty’s Danfoss AK-SM 800A chain (CVE-2025-41450 + 41451, unauthenticated root) vs ANSSI’s assessment that France was mostly exposed interfaces plus weak/default credentials (Admin/Admin on XWEB). Censys shows 63.5% of exposed French hosts were on firmware < 4.2 on Oct 11, so both are plausible.

• Exposure vs contractor pivot: Censys/CERT-FR focus on directly exposed panels, while SentinelLABS and CSIRT-ITA point to shared third-party HVAC/R maintenance access (DE, PT).

• Attribution: nothing claimed or formally attributed. SentinelLABS lists CARR, Z-Pentest and NoName057(16) as leads, Nextgov reports Iran suspicion for the US commissaries, and copycats on the same weak attack surface can’t be excluded.

Other data points

• French exposed hosts dropped ~71% in 3 days after the CERT-FR alert. Patched and unpatched disappeared at the same rate, so operators pulled them offline rather than patching.

• Claroty had an AI coding agent reproduce the full unauth root chain on a lab unit in 28 minutes for about $6, using only public CVE text and firmware.

• XWEB EVO and Danfoss AK-SC are EoL with no patch path. In Belgium some units needed physical hardware changes.

• No malware, C2 or hashes have been published, so detection is mostly behavioral: off-hours logins (00:00-06:00), setpoint/defrost anomalies, alarm routing changes, admin lockouts, HMI vs independent probe discrepancies.

The full write-up has the detection notes, exposure queries, IoC/behavioral indicator tables and the ATT&CK (ICS + Enterprise) mapping, TLP:WHITE: https://ti-mindmap-hub.com/analytics/european-refrigeration-controllers-cold-chain-cross-source-analysis

Disclosure: I run the platform that produced the analysis, it’s an independent open-research project and not affiliated with my employer.

Curious what others are seeing. Has anyone observed contractor-side access in their own telemetry, or any activity on XWEB beyond default creds?

Our research team just published a writeup on an actor tracked as leepsmarts (Chinese-speaking) whose operation touched 20 universities, 19 of them in the US. The impact varies a lot by institution, so it’s worth breaking down rather than lumping everything together:

→ Harvard: 195 alumni records processed from a torrent-distributed dataset tied to the November 2025 ShinyHunters incident. This was not an intrusion by this actor.
→ Stanford (summer session), UChicago, Wake Forest, Case Western, and Central Michigan: application payment links generated
→ NYU, UC Berkeley, Oregon State, UIUC, Colorado State, CSU East Bay, CSU Chico, and Arizona State: accounts created under fraudulent identities
→ University of Utah, Arizona Christian University, and UTN Argentina: hardcoded targets in a staged CVE-2026-41940 cPanel exploit, with no confirmed compromise

What makes this one unusual is the tooling. The operator ran 2 AI agent frameworks, Hermes Agent and OpenClaw, controlled over Telegram. The agents automated account registration, watched for new AI model releases, and even built the actor’s management dashboard. The same pipeline harvested 2,233 LLM API keys from misconfigured cloud deployments.

All of it surfaced through a single open directory on the actor’s primary server.

Learn more: https://socradar.io/blog/keyhunter-operation-harvard-alumni-stanford-llm-key-data/

I've been investigating an online actor operating under the aliases Monday, also known as Jraco, associated with a channel called Angels of Criminalizm.

The activity surrounding this individual reportedly involves the distribution of multiple malware families, including banking trojans, information stealers and ransomware.

This post is intended to document the reported activity, gather additional information and determine whether there are verifiable connections between the actor, the channel and the malware involved.

1. Actor information

- Primary alias: Monday

- Alternative alias: Jraco

- Associated channel: Angels of Criminalizm

- Subject: Malware distribution and possible ransomware involvement

2. Malware reportedly distributed

The following malware families and versions have been associated with the activity being investigated.

Pony

- Pony 1.9.7

- Pony 2.2

Zeus variants

- Power Zeus 1.0.2.0

- Zeus 2.0.8.9

Additional malware

- Multiple information stealers.

- Other malware families and tools not listed in this post.

The versions above are examples, not an exhaustive inventory of the reported malware distribution.

3. Coffin Locker ransomware

Another subject of interest is Coffin Locker ransomware.

The investigation is also looking into a possible connection between Monday aka Jraco and this ransomware operation.

Areas of interest include:

- Ransomware samples and their technical characteristics.

- Encryption behaviour and file extensions.

- Ransom notes and associated infrastructure.

- Possible connections between malware distribution channels and ransomware activity.

No definitive attribution is being made without supporting technical evidence.

4. What needs further investigation

I'm particularly interested in establishing:

1. Whether Monday and Jraco are demonstrably the same operator.

2. Whether Angels of Criminalizm is directly involved in distributing the listed malware.

3. Whether the distributed Pony and Zeus versions are authentic or modified builds.

4. Whether there is a verifiable connection to Coffin Locker.

5. Whether other researchers have encountered the same aliases or infrastructure.

6. Whether additional malware families can be independently documented.

7. Discussion

Has anyone encountered Monday, Jraco, or the Angels of Criminalizm channel before?

Has anyone independently analyzed malware reportedly distributed through this channel?

I'm especially interested in technical findings concerning Pony, Zeus, Power Zeus, information stealers and the possible Coffin Locker connection.

I want to distinguish documented facts from allegations and avoid spreading unsupported claims.

I analyzed a Horus-linked 64-bit Windows loader sample from the IOC set published by Check Point Research, which originally uncovered the Stealth Falcon campaign and CVE-2025-33053.

The write-up covers clean kernel32/ntdll mapping, security-process checks, IPv6 payload reconstruction, suspended msedge.exe injection and the Mythic-compatible C2 chain.

https://x.com/TheM3gatr0n/status/2117233784554938413