DataBreaches.net seems to live the only site willing to report on certain breaches in Thailand these days. first it was the jade of Country group Securities (CGSEC) by hackers calling themselves ALTDOS. And now this week, this site reported a second onslaught by the same threat actors that involved MONO Next public Company. as previously reported, when asked for a response to the attack on MONO, the companion sent a statement. That statement seems to make irritated the threat actors who provided DataBreaches.net with a statement responding to it and more data as proof. Based on the new information provided to DataBreaches.net, it appears that MONO, which is one of a number of Jasmine International PLC subsidiaries, was not their initial target. ALTDOS attacked MONO when negotiations with Jasmine following an round on another subsidiary, 3BB, failed to produce payment. 3BB was attacked in November. 3BB is a fixed broadband service provider with millions of customers. ALTDOS claims that they eventually acquired 8 billion records with user information (name, address, date of birth, ID card number, mobile number, email address, username, password, etc.) and other corporate records. As proof of claim, ALTDOS provided DataBreaches.net with screenshots but also files with customer data, including one spreadsheet with 10,000 customer records. ALTDOS began negotiations on December 18, 2020. They claim that when Jasmine would not pay their $500,000 demand after the 3BB breach, they hacked into 12 of MONO’s data servers and stole hundreds of gigabytes of databases. Their hope was to “force their management into a proper negotiation with ALTDOS.” management replied on december 26, asking for more time, they claim. But after that, ALTDOS didn’t hear from the representative again, and so on New Year’s day, ALTDOS breached 3BB’s Wifi Hotspot servers and stole over 2.8 million user records. A file with more than 83,000 records was provided to DataBreaches.net as proof. following the onslaught on the Wifi Hotspot servers, management sent a new spokesperson to scratch or restart negotiations with them. “Their management proposed to pay us 1/3 of the demanded total and engage ALTDOS as their surety consultant over the next 2 years with 2/3 of the balance amount,” an ALTDOS interpreter claims, adding that ALTDOS refused their proposal and negotiated an 8-week installment project for payment. The negotiations began to fail when a few senior executives reportedly refused to agree to the installment defrayal plan. On January 7, ALTDOS leaked some MONO data. It might experience stayed at that leak level, exclude that Mono issued their press discharge and the statement angered the threat actors. They wrote to DataBreaches.net: ALTDOS is seriously insulted by their management statement which appear to undermine our expertise, and so here are the facts: ALTDOS did not rip some of their employee records. We stole all of their employee records. The stolen information contains more than just name and age. The HR databases contain everything related to each employee, including their father, mother, brother, sister, education, previous employment, salary sum and a lot more. as partial proof, they sent DataBreaches.net data from a MONO Human Resources. There were more than 2,900 records with numerous populated fields: There were so many fields in the hr file that it took three screenshots to capture all the fields. ALTDOS indicated that sql databases were beingness converted to .csv format. Redacted by DataBreaches.net. ALTDOS also provided DataBreaches.net with an employee resume file from MONO that had numerous personal and sensitive data fields and almost 20,000 records. DataBreaches.net is merely listing all the fields: But the pressure free trying to downplay the sum of employee data stolen was not ALTDOS’s only protest to the firm’s press outlet (which was quoted in the update to this post). They continued responding to the firm’s claims: ALTDOS did not steal some of their online customer information. We stole more than 8 million of their user’s sensitive information. The stolen corporate financial records are not those publicly available records. ALTDOS stole financial records ranging from bank account details, bank transfer, payment transaction records to their clients’ defrayal history. Eg, ALTDOS knows their exact charges for different advertisers at different time intervals of the day for various 30 seconds time slots on their tv channels from 2014 to 2020. We even know the balance in each of their bank accounts in different banks on different days throughout the 6 years. Their argument says that they have a surety system in place. Well, ALTDOS stole wads of their data for almost 2 months without red flags. There isn’t even a firewall installed to keep simple attacks. There was more to their statement but readers probably already get the kernel of it all. One specific criticism by ALTDOS was a bit surprising: The fact is ALTDOS warned them via email every time before our attacks, mentioning the time or the target of attack, yet ALTDOS manages to transgress in each attacks. There is no more preventative management. Jasmine’s communication person was sent inquiries to trace up on their first press vent and then a back enquiry about ALTDOS’s updated claims, but no reception has been received to either inquiry by time of this publication. Jasmine and CGSEC both appear to have been somewhat successful in Thailand in terms of getting intelligence outlets not to account on their respective attacks, but they relieve may experience to expose it all because notification following a breach is covered by Thailand’s data protection law. Linklaters cites the relevant supply of law this way: note of breach laws If there is a breach of personal data, the controller must notify the office of the committee without postponement and within 72 hours of identifying the breach, unless it poses no risks to the rights and freedom of an individual. If the breach poses a high risk to the rights and freedom of an individual, the controller shall notify such breach to the individual without postponement together with remedial guidelines. A processor must inform the relevant controller if there is a data breach. It is not known to DataBreaches.net whether 3BB […]
