Hackers claim to hack Resecurity, firm says it was a honeypot

[Gandalf_The_Grey]

Content source

https://www.bleepingcomputer.com/news/security/hackers-claim-resecurity-hack-firm-says-it-was-a-honeypot/

Threat actors associated with the "Scattered Lapsus$ Hunters" (SLH) claim to have breached the systems of cybersecurity firm Resecurity and stolen internal data, while Resecurity says the attackers only accessed a deliberately deployed honeypot containing fake information used to monitor their activity.

Today, threat actors published screenshots on Telegram of the alleged breach, claiming they stole employee data, internal communications, threat intelligence reports, and client information.

"We would like to announce that we have gained full access to REsecurity systems," the group wrote on Telegram, claiming to have stolen "all internal chats and logs", "full employee data", "threat intel related reports", and a "complete client list with details."

Resecurity disputes the threat actor's claims, stating that the allegedly breached systems are not part of its legitimate production infrastructure but were instead a honeypot designed to attract and monitor the threat actors.

"Nice damage control Resecurity. More information coming soon!," reads a post on Telegram.

Hackers claim to hack Resecurity, firm says it was a honeypot

The ShinyHunters hacking group claims it breached the systems of cybersecurity firm Resecurity and stole internal data, while Resecurity says the attackers only accessed a deliberately deployed honeypot containing fake information used to monitor their activity.

www.bleepingcomputer.com

 

[Bot]

Hackers claim to hack Resecurity, firm says it was a honeypot

The ShinyHunters hacking group claims it breached the systems of cybersecurity firm Resecurity and stole internal data, while Resecurity says the attackers only accessed a deliberately deployed honeypot containing fake information used to monitor their activity.

www.bleepingcomputer.com

This kind of “we breached X” vs “it was a honeypot” dispute is common, and the only safe stance (without independent verification) is to treat both claims as unproven until corroborated by evidence.

How to assess the credibility (without speculating)
Attackers often mix truth + exaggeration to gain attention, pressure the victim, or boost reputation. A “honeypot” explanation can also be true, but it still needs supporting details. Useful indicators to look for in follow-up reporting or official statements include:

• Proof quality: Are the screenshots just generic chat/log views, or do they contain verifiable details (timestamps, internal hostnames/domains, file paths, unique documents) that match known Resecurity infrastructure?
• Data type consistency: Do the leaked samples (if any are published) look like real operational data, or do they contain obvious placeholders, “dummy” names, repeated patterns, unrealistic client lists, etc.?
• Scope clarity: “Full access” is vague. Real breaches usually come with specifics (which system, what access method, what data stores).
• Third-party confirmation: Customers/partners reporting suspicious activity, credential abuse, phishing referencing insider info, or external telemetry that aligns with the claim.
• Victim response artifacts: If it truly was a honeypot, sometimes the company will share high-level indicators (TTPs/IOCs) from the interaction—without exposing sensitive internals.

Why a honeypot claim can still matter
Even if the accessed environment was intentionally deployed, it doesn’t automatically prove the attackers had zero access elsewhere. It does, however, mean the “screenshots” could be entirely from a controlled decoy and not representative of production systems. Without independent verification, it’s not possible to conclude either way from screenshots alone.

Practical takeaways for readers/customers
If you’re a customer, partner, or anyone who has communicated with the company, the low-risk steps are the same regardless of who’s right:

• Be cautious of targeted phishing that references “breach” details (even fake “proof” can be used as social engineering).
• If you have accounts tied to the vendor portal/support, rotate passwords and ensure MFA is enabled where possible.
• Monitor for credential-stuffing attempts and unusual login alerts.
• Wait for direct customer notifications or an official incident statement before treating any “client list” or “employee data” claims as confirmed.
• Avoid downloading “leaked data samples” from Telegram/forums; those are a common malware delivery path.

Discussion value-add
If the group publishes additional “proof,” it’s worth focusing the thread on verifiable technical indicators (metadata, consistency checks, confirmation by affected parties) rather than the attacker’s narrative. Until then, the most accurate characterization is: an attacker claim with a victim denial (honeypot explanation), not independently confirmed.

 

[ForgottenSeer 123960]

Authoritative Framework Mapping (NIST, SANS, MITRE)

Remediation steps mapped to industry standards.

NIST SP 800-61 (Incident Response)

The handling of this incident aligns with the NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2/3), specifically in the Detection & Analysis phase.

Deception as Detection (NIST Section 3.2.3)

NIST recognizes that standard logging often misses sophisticated actors. Resecurity’s use of a "honeypot" containing "synthetic data" aligns with the NIST recommendation to use Precursors and Indicators to validate threats before they hit production.

Application

By analyzing the "188,000 requests" (Indicator) against a non-production dataset (Precursor), the firm could confirm the attack without risking real PII.

Containment Strategy (NIST Section 3.3.1)

The decision to let the attackers complete their "exfiltration" of fake data allows for full TTP capture without interruption, a standard containment strategy for non-production environments.

SANS Institute Guidelines

The remediation steps provided correspond to specific SANS controls for defense-in-depth and deception.

SANS "Security through Deception" (Whitepaper)

SANS advocates for "Honey Pots and Honey Nets" to increase the "signal-to-noise" ratio.

Relevance

The "breach" was actually a high-fidelity signal because "no legitimate user" should ever access those synthetic records.

SANS Critical AI Security Guidelines

The attackers used "synthetic" or AI-generated profiles (fake buyers).

Defense

SANS recommends "Identity Verification" that cannot be spoofed by AI (e.g., video challenge-response), which effectively counters the SLH "vishing" (voice phishing) tactics noted in threat reports.

MITRE ATT&CK Mapping (Scattered Lapsus$ Hunters)

Based on the threat intelligence for this specific group (as detailed by Unit 42 and Picus Security), our defense strategy targets these specific MITRE TTPs.

TTP ID: T1566.004
Tactic: Phishing: Spearphishing Voice
Observed Behavior: Attackers "pretended to be buyers" to socially engineer staff.
Remediation Framework: NIST SP 800-53 (AT-2): Security Awareness Training (specifically for vishing).

TTP ID: T1090.002
Tactic: Proxy: External Proxy
Observed Behavior: Used "residential proxy IP addresses" to hide origin.
Remediation Framework: SANS CIS Control 12: Network Infrastructure Management (Geo-velocity blocks).

TTP ID: T1078
Tactic: Valid Accounts
Observed Behavior: Attempted to use stolen/socially engineered credentials.
Remediation Framework: NIST SP 800-63B: Digital Identity Guidelines (Phishing-resistant MFA).

Summary of Sources

NIST SP 800-61 Rev. 2
Computer Security Incident Handling Guide

SANS Institute "Honeypots"
Security through Deception

MITRE ATT&CK Techniques T1566 (Phishing) and T1090 (Proxy)

Palo Alto Unit 42 / Picus Security
Threat profiles for "Scattered Lapsus$ Hunters"

 

[ForgottenSeer 114717]

Authoritative Framework Mapping (NIST, SANS, MITRE)

Remediation steps mapped to industry standards.

NIST SP 800-61 (Incident Response)

The handling of this incident aligns with the NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2/3), specifically in the Detection & Analysis phase.

Deception as Detection (NIST Section 3.2.3)

NIST recognizes that standard logging often misses sophisticated actors. Resecurity’s use of a "honeypot" containing "synthetic data" aligns with the NIST recommendation to use Precursors and Indicators to validate threats before they hit production.


NIST SP 800-61 Rev. 2
Computer Security Incident Handling Guide

The gold standard for Incident Response and Handling.

It goes with "Security is not software. It is a process."

Security is processes and not software. It's the software, combined with the user(s), that caused the problems in the first place.