Beget Loses Accreditation as .RU and .РФ Domain Registrar After Cyberattack
After suffering a cyberattack in the early hours of November 2, Russian hosting provider Beget has encountered an additional setback: its accreditation as a domain registrar has been temporarily suspended.
The Coordination Center for .RU and .РФ domains announced that Beget is no longer permitted to register new addresses in the .RU and .РФ zones. The provider is also barred from accepting domain transfers from other registrars. The same restrictions apply to the .SU zone managed by RosNIIROS.
Beget is required to maintain support for all domains registered prior to the suspension. The company stated that the measures are technical responses outlined in incident response regulations. Expiration dates for domains have been extended in coordination with the Coordination Center and RosNIIROS, ensuring that users will not lose domains due to inability to renew during the restriction period.
The "Domains" section in the control panel has been partially restored, but full functionality for .RU, .РФ, and .SU zones will be reinstated only after accreditation is renewed. A recovery plan has been agreed upon, although no specific date for full restoration has been provided.
The accreditation suspension follows the compromise in which attackers obtained access to the management contour and executed wiping scripts, disrupting operations across the provider's infrastructure.
Related articles
Beget Rebuilds Cloud Infrastructure After Destructive Cyberattack Wipes VPS Backups
Beget suffered a severe cyberattack that allowed threat actors to access the management layer of its entire cloud architecture and execute wiping scripts. The incident destroyed cloud infrastructure and left backup copies of VPS files available to only half of the affected users. Internal systems were also hit, breaking links between customer accounts and services, forcing the provider to reconstruct ownership records. Hosting services have recovered more than 60 percent, while full cloud restoration timelines remain unknown. The attack disrupted BelkaCar’s car-sharing application, which relied on Beget for backend connectivity and has since migrated to another provider.
Fukuoka Prefecture Exposes Personal Data of 183 Corporate Officers Due to Website File Misconfiguration
Fukuoka Prefecture has confirmed that personal information belonging to 183 corporate officers from 24 organizations was left publicly accessible on its official website. The exposure occurred within files related to the Fukuoka Prefecture Easy-to-Work Care Workplace Certification System. The files were uploaded by a contracted vendor between August 21 and September 17, 2026, with incorrect permissions that allowed online editing and saving instead of read-only access. The issue remained undetected until an applicant inquired about download procedures. Upon discovery, the prefecture instructed the vendor to remove the files and contacted all 24 affected corporations by telephone to provide explanations and apologies. The incident highlights risks associated with improper configuration of application files containing sensitive personal data on government websites.
New Container, Old Code: Web Shell Persists Three Months in 1C-Bitrix Environment
Two 1C-Bitrix sites shared a web shell named WebShellOrb after an attacker exploited multiple vulnerabilities in a custom appeal application. The initial compromise went undetected because Nginx logs were retained for only one month, leading responders to conclude that no scanning activity remained visible. After agents showed no malicious code, administrators restarted the container without addressing the underlying issues in the shared filesystem and source code. The attacker regained access weeks later by reusing JWT tokens generated with a hardcoded secret and by exploiting SQL injection flaws that allowed password hash extraction. Shared system user accounts and a common filesystem volume enabled the shell to propagate between sites and survive container recreation. The incident highlighted that redeploying containers and rotating passwords failed to eliminate persistence rooted in unpatched code and misconfigured authentication logic.
How to Check If Your Passwords Have Leaked Online Using Have I Been Pwned
The article explains the common ways passwords end up exposed through site breaches, password reuse, or device infostealers. It details how to use the Have I Been Pwned service to check email addresses against known data leaks and the separate Pwned Passwords tool to verify if a password itself has appeared in dumps. Readers learn that absence from the database does not guarantee safety and that results must be interpreted by examining exactly which data fields were exposed. Practical steps include replacing reused passwords starting with email and financial accounts, enabling MFA or passkeys, terminating old sessions, and scanning devices for malware. The guide also recommends adopting a password manager and staying alert to login notifications. Overall it stresses that regular checks combined with unique credentials and multi-factor authentication form the most effective defense against credential stuffing and account takeovers.