Subscribe now

What happened

Multiple weaponized proof-of-concept exploit repositories on GitHub were found delivering a Python-based remote access trojan named ChocoPoC. The campaign appears designed to target cybersecurity researchers, vulnerability testers, penetration testers, and others who download and run exploit code from public repositories.

ChocoPoC stands out because the malware is not embedded directly inside the exploit file. Instead, the attackers add malicious Python packages to the proof-of-concept repository’s dependency list. When a victim clones one of the malicious repositories, a trojanized package named frint is automatically fetched and installed. During installation, frint pulls another malicious dependency named skytext, which contains a compiled native Python extension.

When the proof-of-concept exploit runs, the extension executes automatically and decrypts additional embedded Python code. That code triggers a downloader that retrieves the final ChocoPoC payload from a Mapbox dataset.

The ChocoPoC remote access trojan can execute arbitrary shell commands and Python code, upload files and directories, collect browser passwords, cookies, autofill data, and browsing history, search for text, markdown, and database files, gather shell history, collect network configuration, and enumerate running processes. Mapbox datasets are also abused for data exfiltration, though larger file uploads are handled separately through an HTTP server.

Sekoia identified at least seven GitHub proof-of-concept repositories distributing ChocoPoC. The repositories hosted exploits for FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN, and Joomla SP Page Builder vulnerabilities.

The malicious skytext package was downloaded 2,400 times, mostly on Linux-based systems. Downloads increased after the disclosure of a popular vulnerability, suggesting the attackers used trending security issues to lure researchers into testing malicious PoC repositories.

Before using frint and skytext, the campaign used two other packages, slogsec and logcrypt.cryptography, with similar source code and the same ChocoPoC payload. Sekoia said the campaign appears to rely on compromised accounts to publish malicious PyPI packages and proof-of-concept repositories. Researchers found email addresses tied to GitHub committers linked to earlier PoC trojanizing activity, with some credentials appearing in leak databases and one login likely originating from an infostealer compromise.

Who is affected

Cybersecurity researchers, penetration testers, vulnerability analysts, red teams, and low-skilled hackers who downloaded and ran the malicious proof-of-concept repositories may be affected.

The risk is especially relevant to Linux-based systems, which accounted for most skytext downloads.

Organizations may also be affected if researchers tested the malicious PoCs on workstations containing browser credentials, shell history, API keys, internal documentation, databases, source code, or access to security tooling.

Security teams should pay attention if staff downloaded PoCs for FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Check Point VPN, or Joomla SP Page Builder vulnerabilities from untrusted GitHub repositories.

Why CISOs should care

This campaign highlights a persistent risk in security research workflows: defenders often run untrusted exploit code while investigating new vulnerabilities. Attackers can exploit that habit by publishing trojanized proof-of-concepts around trending vulnerabilities.

For CISOs, the dependency-based delivery method is especially important. The exploit code itself may appear clean, while the malicious behavior lives in a package dependency that looks harmless during review. That makes manual inspection harder if teams only examine the main PoC file.

The targeting of researchers also creates enterprise risk. Security teams often use privileged workstations, browser sessions, internal tools, VPN access, and vulnerability management systems. A compromised researcher machine can expose credentials, internal notes, exploit testing environments, and access paths into the organization.

The use of compromised accounts to publish malicious packages and repositories also reinforces that reputation alone is not enough. A GitHub or PyPI account may look legitimate while being controlled by an attacker.

3 practical actions

1. Run proof-of-concepts only in isolated environments: Researchers should execute unverified exploit code in disposable virtual machines, containers, or lab systems without access to production credentials, browser sessions, SSH keys, or internal repositories.

2. Review dependencies, not only exploit files: ChocoPoC was delivered through malicious Python packages added to PoC dependency lists. Security teams should inspect requirements files, package installation scripts, native extensions, dependency chains, and network activity before running public exploit code.

3. Monitor researcher workstations for unusual behavior: ChocoPoC can execute commands, steal browser data, collect shell history, and upload files. Defenders should watch for suspicious Python package installs, unexpected Mapbox dataset access, outbound HTTP uploads, unusual shell activity, and credential access from research systems.

Also on the news today:

• Medtronic Notifies Customers Impacted by ShinyHunters Data Breach

• Kubota Says Hackers Had Month-Long Access to Network Systems

• FortiBleed Credential Theft Campaign Linked to Lynx Ransomware

Subscribe now

Subscribe now

What happened

Kubota North America Corporation disclosed that hackers had access to some of its network systems for more than a month earlier this year. The company’s investigation found that the threat actor accessed certain systems between March 16 and April 20. During that period, the attacker accessed files containing personal information belonging to employees and their dependents.

Kubota is part of the Japanese industrial manufacturer known for agricultural and construction equipment. Its North American division includes facilities that produce tractors, mowers, and utility vehicles. The potentially exposed information includes full names, Social Security numbers, dates of birth, taxpayer IDs, driver’s license or other government ID numbers, direct deposit bank account information, corporate payment card information, and benefits enrollment and limited claims data. Some of the exposed information may also belong to employee dependents. Kubota said the exact data types vary by person.

The company began sending personalized notification letters by email on June 30, informing affected individuals about the specific information exposed in their case. Kubota is offering Kroll identity protection services to help affected individuals respond to the risk. The company advised recipients to monitor healthcare-related statements and bank accounts and to report suspicious activity to authorities. Kubota said it implemented additional security measures to help prevent similar incidents.

At the time of reporting, no ransomware or data extortion group had claimed responsibility for the attack. Kubota did not mention any operational or business disruption tied to the incident.

Who is affected

Kubota North America employees and their dependents are affected if their information was included in the files accessed by the attacker. The potentially exposed information may include names, Social Security numbers, dates of birth, taxpayer IDs, government ID numbers, bank account information, corporate payment card information, benefits enrollment data, and limited claims information. Because dependent data may also be involved, affected households could face broader identity theft, healthcare fraud, tax fraud, payroll fraud, and financial account risk.

Why CISOs should care

This incident shows how employee and dependent data can become a major breach exposure even when customer-facing operations are not publicly reported as disrupted.

For CISOs, the month-long access window is especially important. Attackers had access to some Kubota network systems from March 16 to April 20, giving them time to locate sensitive HR, benefits, payroll, and dependent information.

The exposed data categories also increase the risk of downstream fraud. Direct deposit bank account information, Social Security numbers, government IDs, taxpayer IDs, and benefits information can support identity theft, payroll diversion, tax fraud, and healthcare-related scams.

The lack of a ransomware or extortion claim does not reduce the need for full incident response. Data theft incidents without public ransomware branding can still involve stolen information that may later be sold, used for fraud, or leveraged in targeted social engineering.

3 practical actions

1. Review access to HR, payroll, and benefits data: Kubota said files containing employee and dependent information were accessed. CISOs should enforce least privilege, strong logging, and segmentation around systems storing payroll, tax, benefits, and dependent records.

2. Prepare identity protection and fraud guidance for employees: The exposed data includes Social Security numbers, government IDs, bank account information, and benefits data. Organizations should provide clear instructions for credit monitoring, bank account review, healthcare statement monitoring, and suspicious activity reporting.

3. Investigate long-dwell network access thoroughly: The attacker accessed systems for more than a month. Security teams should review authentication logs, file access records, lateral movement, persistence mechanisms, data staging, and outbound transfers before closing the incident.

Also on the news today:

• Medtronic Notifies Customers Impacted by ShinyHunters Data Breach

• FortiBleed Credential Theft Campaign Linked to Lynx Ransomware

• ChocoPoC Malware Targets Researchers Through Trojanized PoC Exploits

Subscribe now

Subscribe now

What happened

The FortiBleed credential theft campaign has been linked to the INC and Lynx ransomware operations, suggesting that stolen Fortinet credentials may have been intended to support future network intrusions. The campaign first drew attention after a server containing credentials stolen from more than 73,000 Fortinet devices was found exposed online. Researchers found FortiGate configuration files, harvested credentials, password-cracking infrastructure, and systems used for credential-stuffing attacks.

Follow-up research from SOCRadar found that the operation used a custom packet-sniffing tool called FortiGate Sniffer on compromised FortiGate firewalls. The tool allowed attackers to intercept VPN credentials and other authentication data directly from network traffic passing through the devices. SOCRadar later identified a Windows server tied to FortiBleed infrastructure. During analysis of that server, researchers found evidence that the threat actor had accessed negotiation panels for both the Lynx and INC ransomware groups.

Screenshots shared showed browser sessions accessing ransomware administration panels containing victim chats used during negotiations. SOCRadar said this provides direct evidence that an individual with access to FortiBleed infrastructure was also involved with the ransomware groups’ negotiation platforms.

The company also said it identified more than 200 additional operational servers beyond those originally tied to the campaign. Researchers found victim information harvested during FortiBleed that overlapped with organizations later listed on the INC ransomware leak site.

SOCRadar also said the operation appears to involve roughly 20 members with defined roles. The campaign was also larger than initially understood. Researchers said FortiBleed targeted more than 430,000 FortiGate firewalls worldwide and deployed traffic sniffers on approximately 19,000 devices.

After affected organizations were notified, the number of compromised devices reportedly fell to around 11,000. Researchers also identified roughly 500 servers used by the operation. SOCRadar believes the attackers may have exploited a previously undisclosed Nextcloud zero-day vulnerability to expand access after initial compromise, though technical details have not yet been released. The researchers also found persistent backdoor accounts using the username adminin on compromised systems and said they are continuing efforts to recover ransomware decryption keys.

Who is affected

Organizations using FortiGate firewalls may be affected, especially those whose devices were compromised during the FortiBleed campaign or whose credentials were included in the exposed data. The campaign targeted more than 430,000 FortiGate firewalls and reportedly deployed sniffers on about 19,000 devices. Around 11,000 compromised devices remained after victim notification efforts reduced the count.

Organizations whose Fortinet VPN credentials, configuration files, or authentication data were captured may face risk beyond the firewall itself. Stolen credentials can support VPN access, lateral movement, credential stuffing, ransomware staging, and intrusion into downstream systems. Organizations later appearing on the INC ransomware leak site may also be affected if their data overlapped with information harvested during FortiBleed.

Why CISOs should care

This development changes FortiBleed from a large credential theft campaign into a possible ransomware enablement operation. The connection to INC and Lynx negotiation panels suggests the stolen Fortinet access may have been used, sold, or prepared for follow-on extortion activity.

For CISOs, the key issue is that compromised firewalls can become credential collection points. A FortiGate compromise is not only a perimeter device issue. If attackers deployed sniffers, they may have captured VPN credentials, authentication data, configuration details, and other information moving through the device.

The scale also matters. Targeting more than 430,000 FortiGate firewalls and deploying sniffers to roughly 19,000 devices shows how quickly edge infrastructure compromise can become a mass credential operation.

The reported backdoor account named adminin is especially important for incident response. Even if organizations patched or changed passwords, persistent accounts may allow attackers to retain access if not identified and removed.

3 practical actions

1. Treat FortiBleed exposure as a ransomware precursor: SOCRadar linked FortiBleed infrastructure to INC and Lynx ransomware negotiation panels. CISOs should assume stolen Fortinet credentials may be used for intrusion, extortion, or brokered access, and should escalate response beyond routine password resets.

2. Hunt for FortiGate Sniffer and persistent accounts: The campaign used custom sniffers and researchers found backdoor accounts using the username adminin. Security teams should review FortiGate configurations, local accounts, SSH access, diagnostic activity, unexpected processes, and configuration changes.

3. Rotate credentials that passed through compromised firewalls: Because the campaign captured authentication traffic, organizations should rotate Fortinet VPN credentials, administrator accounts, domain credentials, service accounts, and any credentials reused across exposed systems.

Also on the news today:

• Medtronic Notifies Customers Impacted by ShinyHunters Data Breach

• Kubota Says Hackers Had Month-Long Access to Network Systems

• ChocoPoC Malware Targets Researchers Through Trojanized PoC Exploits

Subscribe now

Subscribe now

What happened

Medical device company Medtronic is notifying affected customers after a data breach exposed personal information to an unauthorized third party. Medtronic previously confirmed that hackers compromised certain corporate IT systems. The ShinyHunters data extortion group claimed responsibility for the attack and alleged that it had obtained 9 million Medtronic records containing personally identifiable information and internal corporate data.

Medtronic said it became aware of unusual activity on certain corporate IT systems on April 15, 2026. The company launched an investigation with support from third-party cybersecurity experts to determine the scope and impact of the incident. The investigation found that an unauthorized actor accessed certain Medtronic corporate IT systems between April 13 and April 19, 2026. The potentially exposed information may include full names, contact information, dates of birth, Social Security numbers, and health-related information.

ShinyHunters listed Medtronic on its dark web extortion portal on April 18 and threatened to publish the allegedly stolen data if a ransom was not paid by April 21. The Medtronic entry was later removed from the group’s listing. Medtronic said the stolen data was not exposed online. The company also said all Medtronic devices remain safe to use and were not affected by the cybersecurity incident. Affected individuals are being offered 24 months of credit monitoring and identity theft protection services.

Who is affected

Medtronic customers whose information was included in the compromised corporate systems may be affected. The potentially exposed information may include full names, contact information, dates of birth, Social Security numbers, and health-related information. The breach does not affect Medtronic’s medical devices, which the company said remain safe to use. Customers receiving notifications should treat the incident as a personal data and identity risk event, especially because Social Security numbers and health-related information may be involved.

Why CISOs should care

This incident highlights the sensitive nature of healthcare and medical device company data. Even when connected medical devices are not affected, corporate IT systems can still hold customer information that creates identity theft, fraud, phishing, and social engineering risk.

For CISOs, the ShinyHunters involvement is also important. Data extortion groups often use public leak threats to pressure victims, creating reputational, legal, and customer trust challenges even before stolen data is verified or published.

The short access window is another key point. Medtronic said the unauthorized actor accessed certain systems between April 13 and April 19, and the company became aware of unusual activity on April 15. Security teams need strong visibility into corporate environments so they can determine what was accessed, what was exfiltrated, and whether customer notification is required.

The assurance that medical devices were not affected also reinforces the need for clear incident scoping. Healthcare technology companies must be able to distinguish corporate IT compromise from product or device security impact quickly and credibly.

3 practical actions

1. Separate corporate IT breach response from product safety assessment: Medtronic said its devices remain safe to use and were not affected. Healthcare technology CISOs should maintain incident response processes that quickly determine whether an event affects corporate systems, customer data, connected products, or patient safety.

2. Prepare customer notification for health-related data exposure: The potentially exposed data includes Social Security numbers and health-related information. Security teams should prepare clear notifications, identity protection support, fraud guidance, and call center scripts for affected customers.

3. Monitor for extortion-driven data leak claims: ShinyHunters listed Medtronic on its dark web portal before the entry was later removed. Organizations should monitor extortion sites, validate attacker claims through forensics, and coordinate legal, communications, and customer response teams before public data exposure occurs.

Also on the news today:

• FortiBleed Credential Theft Campaign Linked to Lynx Ransomware

• Kubota Says Hackers Had Month-Long Access to Network Systems

• ChocoPoC Malware Targets Researchers Through Trojanized PoC Exploits

Subscribe now