Asha Javeed

Lead Ed­i­tor In­ves­ti­ga­tions

asha.javeed@guardian.co.tt

Prime Min­is­ter Dr Kei­th Row­ley’s iden­ti­fi­ca­tion card num­ber, his dri­ver’s per­mit num­ber and his pass­port num­ber have been found to be com­pro­mised in TSTT’s da­ta breach.

The Ex­cel doc­u­ment al­so has his birth date and a PO box ad­dress for him as Prime Min­is­ter.

Guardian Me­dia ob­tained a copy of the 6GB of da­ta from TSTT which was up­loaded to the dark web, fol­low­ing a cy­ber­at­tack on the com­pa­ny on Oc­to­ber 9, and was able to ver­i­fy this. The da­ta bun­dle in­cludes scans, a list of names and cre­den­tials.

Row­ley was asked to com­ment and was sent a copy of the in­for­ma­tion which Guardian Me­dia was able to source and ver­i­fy, but up to late yes­ter­day did not re­spond.

The Prime Min­is­ter is one of hun­dreds of cus­tomers whose da­ta has been post­ed on­line fol­low­ing the da­ta breach at the telecom­mu­ni­ca­tions com­pa­ny.

As of yes­ter­day, the da­ta—which con­tains 1.2 mil­lion names—had been down­loaded over 13,000 times from the dark web.

The da­ta has names, home ad­dress­es, email ad­dress­es, cell phone num­bers, birth cer­tifi­cates, pass­port num­bers, iden­ti­fi­ca­tion cards, re­ceipts, in­ter­nal emails, as well as cre­den­tials.

Yes­ter­day, Pub­lic Util­i­ties Min­is­ter Mar­vin Gon­za­les is­sued a press state­ment and man­dat­ed that the board of TSTT con­duct an in­de­pen­dent in­quiry in­to the cy­ber­at­tack at the com­pa­ny.

In the state­ment, Gon­za­les said he is deeply con­cerned about the re­cent cy­ber­at­tack giv­en TSTT’s im­por­tance on the coun­try’s telecom­mu­ni­ca­tions land­scape.

The min­is­ter said the grav­i­ty of the sit­u­a­tion war­rants a thor­ough and full-scale in­ves­ti­ga­tion to as­cer­tain the facts and cir­cum­stances that caused the breach, TSTT’s com­mu­ni­ca­tions re­gard­ing the mat­ter, and the ac­tions the or­gan­i­sa­tion is (and has been) tak­ing to re­duce the pos­si­bil­i­ty of fu­ture cy­ber in­cur­sions.

He said that TSTT has to make pub­lic the facts and find­ings, in so far as the de­tails do not com­pro­mise TSTT's cus­tomer con­fi­den­tial­i­ty or fur­ther put at risk the in­tegri­ty of its da­ta or dig­i­tal in­fra­struc­ture.

An­gus Smith, man­ag­er of T&T’s Cy­ber­se­cu­ri­ty In­ci­dent Re­sponse Team, yes­ter­day wel­comed the in­ves­ti­ga­tion, as, giv­en what’s in the pub­lic do­main, there is not enough to un­der­stand the threat to the coun­try.

He crit­i­cised TSTT’s han­dling of the in­ci­dent and not reach­ing out to their cus­tomers af­fect­ed by the in­ci­dent and lament­ed the lack of leg­is­la­tion to en­force T&T to force com­pa­nies to be trans­par­ent about da­ta breach­es.

For its part, TSTT chose not to fur­ther com­ment yon Sun­day on the min­is­ter’s call for an in­de­pen­dent in­ves­ti­ga­tion.

Last Sat­ur­day, the com­pa­ny said there was no com­pro­mise of cus­tomer da­ta but added that it had not cor­rob­o­rat­ed in­for­ma­tion in the pub­lic do­main pur­port­ed to be cus­tomer in­for­ma­tion.

On Fri­day, the com­pa­ny is­sued an­oth­er state­ment ad­mit­ting that 6GB, or less than one per cent of the petabytes of the com­pa­ny’s da­ta, was ac­cessed but that the ma­jor­i­ty of its cus­tomers’ da­ta was not ac­quired and no pass­words were com­pro­mised.

TSTT said it was de­ter­mined that some of the da­ta had been ac­cessed from a lega­cy sys­tem, which is no longer utilised but con­tains da­ta that is, in many in­stances, no longer valid.

What caused the breach?

Cy­ber­se­cu­ri­ty ex­perts were di­vid­ed on what caused the da­ta breach.

One, who chose to re­main anony­mous, be­lieves there was an in­ter­nal link to the job.

“The dark web isn’t like Google, where you search for what’s there. Un­less you know what to look for, you won’t find it. And they knew what to look for,” he said.

Cy­ber­se­cu­ri­ty con­sul­tant Alex Samm ob­served that un­like oth­er ran­som at­tacks, no ran­som count­down timer ex­ist­ed for TSTT and all the in­for­ma­tion was read­i­ly avail­able on Ran­somEXX’s page on the Dark Web.

“This is enough in­for­ma­tion for mass iden­ti­ty theft and fraud. What we haven’t seen so far, as of the writ­ing of this, are the cre­den­tials of clients that use TSTT’s sys­tems and plat­forms. How­ev­er, this does not mean that they are not present. We did, how­ev­er, see dumps of what seemed to be an OR­A­CLE data­base with cus­tomer in­for­ma­tion (full names, full ad­dress­es, con­tact num­bers, notes on ac­counts, ar­eas, and much more). The source code seems to be code for some of the in­ter­nal ap­pli­ca­tions of TSTT, in­clud­ing billing ap­pli­ca­tions, scripts that per­form au­to­mat­ed tasks, web page code and some cre­den­tials em­bed­ded in some doc­u­ments,” he told the Guardian Me­dia.

“For an or­gan­i­sa­tion as promi­nent as TSTT, stor­ing pass­words in plain­text in a text file. Not even en­crypt­ed or hashed. Ex­cel sheets with in­ter­nal ad­dress­es for crit­i­cal sys­tems and in­fra­struc­ture along with user­names and pass­words, in some cas­es even the old pass­words are list­ed,” he said.

“Un­til a full in­ves­ti­ga­tion is com­plet­ed, we can on­ly spec­u­late, us­ing his­tor­i­cal trends of the ran­somware gangs which, in this case, points to some­one re­ceiv­ing an email and open­ing it and its at­tach­ment. That’s the typ­i­cal route of the Ran­somEXX ran­somware. That doesn’t mean they don’t have oth­er means of gain­ing ac­cess. As men­tioned be­fore, it could be the gang ex­ploit­ing an as­set from TSTT that has known is­sues or it could be that it was an in­side job, where a po­ten­tial­ly dis­grun­tled em­ploy­ee was lever­aged by the gang to de­ploy the ran­somware,” he ex­plained.

Samm ob­served that T&T does not have any leg­is­la­tion in place for cy­ber­se­cu­ri­ty breach­es, pub­lic or pri­vate.

“Any­one re­mem­ber the ANSA hack a few years ago? We on­ly knew about this be­cause some­one leaked it on­line. If this wasn’t re­leased, we prob­a­bly would nev­er have heard of it. What about Dig­i­cel? The AG's Of­fice and Min­istry of Le­gal Af­fairs? No one is talk­ing about the breach at SWRHA, and all the oth­ers that we won’t ever hear about,” he said.

Da­ta pro­tec­tion

Man­ag­ing Di­rec­tor of Pri­va­cy Ad­vi­so­ry Ser­vices, Rishi Ma­haraj, said cus­tomers should be rea­son­ably con­cerned about the TSTT da­ta breach.

“While TSTT has stat­ed that no cus­tomer pass­words, cred­it card in­for­ma­tion, or oth­er high­ly sen­si­tive da­ta were ac­cessed, the breach did ex­pose per­son­al­ly iden­ti­fi­able in­for­ma­tion (PII) such as names, email ad­dress­es, home ad­dress­es, ID scans, and some cus­tomer ac­count in­for­ma­tion. This type of da­ta can be used for iden­ti­ty theft, phish­ing at­tacks, and oth­er ma­li­cious ac­tiv­i­ties. The fact that some of this da­ta came from a lega­cy sys­tem which might con­tain out­dat­ed or no longer valid in­for­ma­tion does not di­min­ish the risk en­tire­ly, as cy­ber­crim­i­nals can still use this da­ta ma­li­cious­ly,” he said.

He said from a da­ta pro­tec­tion per­spec­tive, there are sev­er­al con­sid­er­a­tions.

He not­ed:

• Time­li­ness of com­mu­ni­ca­tion: There was a sig­nif­i­cant de­lay be­tween the date of the breach (Oc­to­ber 9) and TSTT’s first pub­lic state­ment (Oc­to­ber 30). This 21-day gap, dur­ing which time cus­tomers were un­aware of po­ten­tial risks, is con­cern­ing. Prompt com­mu­ni­ca­tion is es­sen­tial, es­pe­cial­ly when per­son­al da­ta might be at risk.

• Ac­cu­ra­cy of in­for­ma­tion: Ini­tial state­ments from TSTT and the Pub­lic Util­i­ties Min­is­ter sug­gest­ed that cus­tomer da­ta was not com­pro­mised. How­ev­er, sub­se­quent rev­e­la­tions proved this to be in­ac­cu­rate. Such dis­crep­an­cies can erode pub­lic trust.

• Re­sponse to threats: The note from the De­fray777 name and shame web­site sug­gests that TSTT was warned about the con­se­quences of non-com­pli­ance be­fore the da­ta re­lease. If true, this rais­es ques­tions about TSTT’s de­ci­sion-mak­ing process and its pri­ori­ti­sa­tion of cus­tomer da­ta se­cu­ri­ty.

• Pub­lic per­cep­tion: The rev­e­la­tion by third-par­ty sources, such as The Dark Web In­former and oth­er me­dia out­lets, be­fore an of­fi­cial ac­knowl­edg­ment from TSTT, can fur­ther erode trust. It sug­gests that with­out ex­ter­nal pres­sure, the breach might not have been dis­closed in its en­tire­ty to the pub­lic.

“While TSTT has tak­en steps post-breach to ad­dress con­cerns and pro­tect its sys­tems, the de­lays in com­mu­ni­ca­tion, dis­crep­an­cies in state­ments, and the na­ture of the breach dis­clo­sure raise sig­nif­i­cant con­cerns. Cus­tomers should crit­i­cal­ly eval­u­ate their trust in TSTT based on the com­pa­ny’s ac­tions and the in­for­ma­tion pro­vid­ed. Trust is earned through con­sis­tent and trans­par­ent ac­tions, and TSTT will need to work dili­gent­ly to re­build that trust with its cus­tomer base,” he said.

For cus­tomers who have been breached he urged:

• Stay vig­i­lant: Be cau­tious of un­so­licit­ed com­mu­ni­ca­tions, es­pe­cial­ly those ask­ing for per­son­al or fi­nan­cial in­for­ma­tion. Cy­ber­crim­i­nals can use the breached da­ta for phish­ing at­tacks.

• Mon­i­tor ac­counts: Reg­u­lar­ly check bank and cred­it card state­ments for any unau­tho­rised trans­ac­tions. If you no­tice any­thing sus­pi­cious, re­port it im­me­di­ate­ly.

• Change pass­words: Even though TSTT stat­ed that no pass­words were breached, it’s a good prac­tice to change pass­words for ac­counts, es­pe­cial­ly if you use sim­i­lar pass­words across mul­ti­ple plat­forms.

• En­able two-fac­tor au­then­ti­ca­tion (2FA): Where pos­si­ble, en­able 2FA on your ac­counts to add an ex­tra lay­er of se­cu­ri­ty.

• Stay in­formed: Keep an eye on any fur­ther com­mu­ni­ca­tions from TSTT re­gard­ing the breach. They might pro­vide ad­di­tion­al in­for­ma­tion or rec­om­men­da­tions.

• Con­sid­er iden­ti­ty theft pro­tec­tion: Some ser­vices mon­i­tor var­i­ous data­bas­es and alert you if your per­son­al in­for­ma­tion is found in places it shouldn’t be.

• Be scep­ti­cal: If you re­ceive any com­mu­ni­ca­tion claim­ing to be from TSTT or any oth­er or­gan­i­sa­tion, ver­i­fy its au­then­tic­i­ty be­fore pro­vid­ing any in­for­ma­tion or tak­ing any ac­tion.