The investigative team at the Ministry of Science and ICT released its findings on the Tving breach on the 3rd. Over three days, from May 29 to 31, a hacker penetrated both the development and production systems one after another using a single developer access key and stole information on 39.54 million accounts. (Graphic = Solnews AI-image use)
The Ministry of Science and ICT announced the results of the joint public-private investigation team’s probe into the Tving incident on the 3rd. The team reconstructed the hacker’s path in five stages by forensically analyzing nine developer devices and cross-checking security equipment, databases (DB), and system access logs. In the process, there were multiple moments when the attack could have been stopped, even more than the hacker’s own methods.
◆ The trigger was a CPU 100% alert
The incident came to light not through hack detection, but through server overload. At 6 p.m. on May 30, the workload on Tving’s DB server suddenly surged, pushing CPU usage to 100%. An anomaly alert sounded, and Tving blocked the task.
As it investigated the cause, Tving realized that an unauthorized party had entered an internal server and queried user information. It reported the incident to the Korea Internet & Security Agency (KISA) on June 1, and the ministry launched an on-site investigation the next day, forming a joint public-private task force on June 3. Looking back, the investigation team found that the hacker had already been inside the company’s internal systems the day before the alert went off.
◆ Stage 1: Entering the development storage with a stolen key
On May 29 at 2:42 p.m., the hacker entered Tving’s development environment carrying one developer access key.
Put simply, the development environment is a collaborative space where source code is stored and edited by multiple developers. In building terms, it is like a drafting room filled with blueprints. Each developer needs an issued access key to enter. The hacker had already stolen that key in advance.
Once inside, the hacker took everything from 361 accessible development projects, totaling 30.35 gigabytes. At first, only 14 projects were taken, but the second attack swept up all of them. The projects contained core technologies that powered Tving, including personalized content recommendation and search algorithms, membership management and authentication systems, payment management, and paid-service operations.
This exposed the first problem: Tving had given every developer access to all projects. The principle is to open only the minimum necessary for one’s job, but at Tving, one developer’s key was enough to view all 361 projects. For the hacker, one key was effectively a master key.
◆ Stage 2: 43 “master keys” embedded in the source code
Searching through the source code he had taken, the hacker found an even larger prize: access keys for entering the production environment, where the service actually runs. The production environment refers to the space where cloud services such as AWS are used to rent servers; it is not the drafting room but the actual building.
The task force counted 43 production access keys inside the 361 projects. Forty-one were written directly in the source code (hard-coded), and three were stored in plain text in program configuration values without encryption. In other words, keys were left inside the code for convenience instead of being moved to a separate vault. It was like leaving the house key under a flowerpot by the front door and then having the entire pot stolen.
Tving was not unaware of the hard-coding issue. In a 2024 penetration test, it had already been pointed out that access keys were exposed in the source code. But the problem was not fixed. The task force concluded that if the key-management system had been properly organized, access to the development environment could have been blocked and the production environment would not have been breached.
◆ Stage 3: Reaching the production system and obtaining the DB password
At 3:15 p.m. on May 29, just 33 minutes after entering the development environment, the hacker stepped into the production environment.
He examined the permissions of the 43 keys one by one and searched for a route to extract information. The task force confirmed that two of the 43 keys were actually used in the attack. One could be used to process and analyze large volumes of data and access cloud storage, while the other could create new virtual servers. Both were stored on a developer laptop.
As the hacker explored the production environment, a critical piece of information fell into his hands: the administrator account ID and password for accessing the database containing user information had been saved in plain text without encryption.
◆ Stage 4: The first attempt was caught by the alert
At 9:22 a.m. on May 30, the hacker planted attack tools for data exfiltration in cloud storage. He had created 20 scripts of his own. He then connected to the database linked to the storage and began pulling user information.
The massive queries caused the DB server’s workload to spike, driving CPU usage to 100% at 6 p.m. The alert sounded, and Tving cut off the task. The first attempt was stopped there after the hacker tried to pull large amounts of data all at once and overloaded the server.
The problem was that Tving did not recognize the alert as a hack. According to the task force, Tving was only monitoring simple indicators such as CPU load and did not have a system to detect abnormal behavior in real time by watching network and data flows. It also lacked access-control policies that allowed only approved IPs or required multi-factor authentication (MFA). It could see that the server was sick, but not who had made it that way or why.
◆ Stage 5: Quietly again… 24GB with CPU at 10%
The hacker did not retreat. On Sunday evening, May 31, at 7 p.m., he returned with a changed method.
He used the second key he had secured earlier, the one that could create virtual servers. Inside the production environment, he set up his own virtual server and used it as the exfiltration channel. After moving the user information in the DB onto that server in bulk (24 gigabytes), he sent it to an external server. When the job was done, he deleted the virtual server and erased the traces. It took three hours and 20 minutes, from 7 p.m. to 10:20 p.m.
This time, no alert sounded. The task force found that CPU usage at the time stayed below 10%. It judged that, having experienced the previous day’s alert, the hacker deliberately kept the server load low and leaked the data slowly. The hacker had figured out the limits of the defense system and crawled under them. The information was transferred to an external server.
◆ The first key: how was it stolen? Unresolved
What remained unresolved was the starting point of the five-stage attack: how the developer access key was stolen in the first place.
The task force investigated several scenarios in detail. It checked the developer’s company and personal email accounts for phishing messages, performed forensics on nine developer devices (eight laptops and one desktop PC) to look for malware, examined whether malicious code had been inserted into the software development and deployment process (a supply-chain attack), whether employees had shared access keys without authorization, and whether the VPN equipment had been compromised through a vulnerability. None of these were confirmed.
The reason is lack of evidence. Tving’s VPN access logs were kept for only six days, because the log-management policy was not properly applied to newly introduced equipment. Development-environment access logs were retained for 90 days, but if the key had been stolen earlier than that, traces would already have disappeared. No one knows how long the hacker had possessed the key.
Forensics revealed something else: on the devices of eight developers, 37 development-environment access keys and 52 production-environment access keys were stored without encryption. There were also signs that keys had been exchanged through internal messenger services. The task force pointed out that there was no management procedure for issuing, using, changing, revoking, or regularly checking keys.
◆ What was leaked
The scale of the leak reached 39.54 million accounts: 22.06 million active accounts that could log in, 8.5 million dormant accounts that had not accessed the service for over a year, 8.87 million accounts retained under the law after cancellation, and 110,000 test accounts.
There was overlap because one person could create multiple accounts, and one user had as many as 13 accounts. By signup method, social sign-up via Naver, Kakao, Apple, and others accounted for the largest share at 22.47 million accounts, followed by 8.63 million CJ ONE integrated members and 7.26 million Tving direct signups.
The leaked data covered 20 items across 70 types, including ID, name, date of birth, gender, mobile phone number, email address, personal identification information (CI), profile name, payment history, and partner service information. CI is a unique value used to identify a person instead of a resident registration number, created when making paid payments or verifying age.
Among the 19.04 million accounts with CI leaked, 13.24 million after deduplication, an average of 11 data items were leaked. Among the 20.4 million accounts without CI, an average of five data items were leaked. Many of the CI-free accounts contained inaccurate data, such as names entered as numbers or incorrectly entered email addresses.
Encryption status determined the damage. Member passwords were encrypted with a one-way method that cannot be reversed, so hackers cannot crack them. Refund account numbers and profile lock codes were also leaked in encrypted form. By contrast, the last digits of mobile phone numbers and the local part of email addresses had been encrypted, but the encryption keys that could unlock them were leaked at the same time. The task force regarded this as equivalent to plain-text leakage. A lock was attached, but the key was hung right next to it.
So far, no cases of abuse of the leaked information or dark-web trading have been identified. However, the task force said phone numbers and email addresses could be used for smishing or voice phishing, or traded on the dark web, and strengthened real-time monitoring. The Personal Information Protection Commission will separately announce the exact scale of personal data leakage.
◆ Why it could not be stopped: 4 people, 14 hours, ignored warnings
The task force said the root cause lay more in people and systems than in technology.
Tving has 265 employees, including 149 developers. The number of dedicated information-security staff, excluding outsourced personnel, was around four. That works out to one security staff member for every 37 developers. The task force said that with that level of staffing, it would be difficult to simultaneously handle 24/7 security monitoring, vulnerability inspections, and anomaly detection.
The crisis response was also slow. An anomaly occurred at 6 p.m. on May 30, but it was not shared with the information-security team and the chief information security officer (CISO), who should have been in charge of coordinating the response to the breach, until about 14 hours later, at 10:10 a.m. on May 31. In the meantime, the hacker was preparing the second attack. The task force said interdepartmental communication and collaboration were inadequate.
Basic security checks, such as anti-virus installation on work PCs and keeping software updated, were also neglected. These were part of Tving’s own internal security policy.
◆ Reporting was delayed too: fines and changing laws
Legal violations were also confirmed. The Network Act requires reporting within 24 hours of recognizing a breach. Tving reported that it recognized the incident at 3:09 p.m. on May 31, but the task force determined that recognition actually occurred at 10:10 a.m. that same day, when the situation was shared with the information security team. The actual report was filed at 3:08 p.m. on June 1, exceeding the 24-hour limit. This is subject to a fine of up to 30 million won.
The ministry will require Tving to submit an implementation plan for recurrence prevention in September and will inspect whether it is being carried out from October through December, starting in January next year. If insufficient, it will issue a corrective order.
The system is changing too. An amended Personal Information Protection Act, effective September 11, will allow punitive fines of up to 10% of total sales for repeated or large-scale leaks caused by intent or gross negligence.
An amended Network Act, effective October 1, will require major companies to expand security personnel and budgets, and will allow the government to begin investigations even before a company reports if it secures signs of hacking. Failure to faithfully implement recurrence-prevention measures will also trigger enforcement fines.
◆ Tving’s apology and compensation
Tving CEO Choi Joo-hee held a briefing the same day, saying, “I sincerely apologize for causing great concern and anxiety to our customers,” and added, “We will humbly accept the investigation results and carry out corrective measures and recurrence-prevention measures to the end.”
Compensation includes one year of hacking and phishing insurance, up to 3 million won per person, 5,000 Tving points, an upgrade to a premium viewing environment, or a choice of discount coupons for Wave or CGV. If users apply from the 7th to the 30th, the benefits will be applied starting on the 6th of next month. Tving also pledged to increase information-security investment to four times the level of the previous five years by 2030, raising its security spending from 3 billion won this year to around 12 billion won, and to triple its security workforce within five years.
◆ Five lessons other companies should note
The Tving incident was not technically novel. Read in reverse, the task force’s criticism becomes a set of preventive measures.
Access keys must be kept outside the code. The key should be stored in a separate vault (a secret-management tool), and the code should only contain the process for opening that vault. Keys should be changed regularly, and logs should show who used them and when.
Permissions should be granted only as needed. If one developer can see every project, then one key becomes a master key. If access is divided by project and role, damage stays contained even if one area is breached.
Monitoring should focus on flows, not just load. CPU usage alone will miss attackers when they slow down. Along with systems that detect unusual mass queries, unfamiliar IP access, and newly created virtual servers, companies should raise the threshold with approved IPs and multi-factor authentication.
Logs should be kept for longer. Six days of access records are not enough to find the cause of an incident. Investigation and prevention both begin with logs.
Warnings must be fixed to count as warnings. If Tving had fixed the vulnerabilities identified in the 2024 penetration test, the incident might have looked very different. A system is needed to manage the discovery and remediation of vulnerabilities as one package.
◆ What users should do now
Although passwords were leaked in a form that cannot be decrypted, names, phone numbers, email addresses, and dates of birth were exposed together. That is enough for scammers to send highly tailored messages. Do not click links in texts or emails claiming to offer “Tving compensation application” or “account security checks”; compensation applications should be made directly through the Tving app or official website.
If you used the same password for Tving and other services, it is safer to change it. Turning on identity-theft prevention services with your telecom provider and financial institutions can also help block attempts at opening accounts or taking out loans using the leaked information.