Two major South Korean churches have suffered extensive intrusions that exposed records associated with more than one million congregants, along with donation, payroll, employee and administrative information. The attacks followed different entry paths but converged on a common weakness: loosely controlled connections between public-facing applications, databases, internal services and cloud storage.

OASIS researchers reconstructed the activity from tools, stolen files and operator reports recovered from an attacker-controlled server. Their findings point to multi-stage intrusions involving application compromise, credential recovery, lateral movement and off-site staging rather than a single malware family. Because datasets can overlap, the precise number of unique people affected has not been independently confirmed.

A web shell opened the first environment

At the first church, attackers gained a foothold through a web shell placed in an enterprise resource planning system. They reverse engineered ERP application components, decrypted database settings and obtained administrator access to Microsoft SQL Server. The attackers then used the database server’s xp_cmdshell capability to execute operating-system commands and move into linked systems.

From there, access expanded into membership, accounting, physical-access, library, chat and mail databases. The operators bypassed a database-monitoring control, recovered a MariaDB root password and found hardcoded network-attached storage credentials in backup-related configuration. The chain shows how one exposed application can become a bridge to several otherwise separate repositories.

The recovered collection contained approximately 960,000 congregant records updated during the previous two years, including names and South Korean resident registration numbers. It also included about 330,000 donation entries, 68,000 document-creation records, more than 14,000 chat messages and 6,874 login accounts. Investigators identified 47.3 GB across 13,939 files in a compromised MinIO bucket used for staging.

Leaked credentials and IDOR drove the second attack

The second church was reached through previously leaked credentials and authorization weaknesses in groupware and membership services. Insecure direct object reference flaws occur when an application accepts a record identifier supplied by a user but does not confirm that the user is permitted to view or change that record.

Using a valid member session, the attackers could access other users’ plaintext PINs and reset an account with manager-level privileges. They obtained roughly 89,000 congregant records, 383 employee records, 286 human-resources entries, 96 employee photographs and internal approval documents. Researchers also found exposed college-ministry APIs and cloud storage that allowed unrestricted reading and writing.

These details underline why valid credentials cannot substitute for authorization. Every request for a record must be checked against the current user’s privileges, even after authentication succeeds. Password-reset functions require especially strong safeguards because they can turn limited access into account takeover.

Connected systems multiplied the damage

In the first environment, the attack progressed from an internet-facing ERP component to database administration, operating-system execution, backup storage and cloud staging. In the second, a combination of exposed credentials and missing object-level checks crossed groupware, membership, SAP and storage services. Hardcoded secrets and excessive service privileges allowed the operators to keep moving after the initial compromise.

Religious and community organizations can hold a uniquely sensitive mix of identity, family, donation and communication data. Criminals could use that material for identity fraud, tailored phishing, extortion or scams that exploit trust within a congregation.

Containment and prevention steps

• Remove unauthorized web shells and preserve forensic copies before rebuilding affected application servers.
• Rotate database, NAS, cloud and application credentials; revoke tokens and invalidate active sessions.
• Disable xp_cmdshell where it is not operationally necessary and constrain linked-server privileges.
• Review ERP, SQL Server, NAS and cloud logs for unusual exports, bulk downloads and unexpected external connections.
• Test every sensitive API for object-level authorization and strengthen privileged password-reset workflows.
• Eliminate secrets from source code, configuration backups and publicly reachable storage.

Organizations should also alert affected people with clear guidance about targeted fraud and credential reuse. The broader lesson is architectural: segmentation, least privilege and enforced authorization can stop an initial application breach from becoming an organization-wide data loss event.