Petya-like wormable mal­ware

Kuwait Times - - TECHNOLOGY - By Rick Hol­land, VP Strat­egy at Dig­i­tal Shad­ows

Late on 27 June, the New York Times re­ported that a num­ber of Ukrainian banks and Ukren­ergo, the Ukrainian state power dis­trib­u­tor, had been af­fected by uniden­ti­fied mal­ware which caused sig­nif­i­cant op­er­a­tional dis­rup­tion. Mul­ti­ple se­cu­rity ven­dors and in­de­pen­dent re­searchers sub­se­quently iden­ti­fied the mal­ware as a wormable ran­somware vari­ant with func­tional and tech­ni­cal sim­i­lar­i­ties to Petya.

Based on these sim­i­lar­i­ties and con­tin­u­ing con­fu­sion, the mal­ware has been dubbed Nyetya, Petna, ExPetr, and NotPetya, among oth­ers. It has been linked with a large num­ber of in­fec­tions, a sig­nif­i­cant pro­por­tion of which (around 60% ac­cord­ing to statis­tics pub­lished by Kasper­sky) af­fected ma­chines in Ukraine, though at the time of writ­ing the over­all num­ber of in­fec­tions is not known.

How NotPetya Works

On 27 June, a so­cial me­dia ac­count used by the Na­tional Po­lice of Ukraine Cy­ber po­lice Depart­ment, sug­gested that the re­ported in­fec­tions originated from a com­pro­mised soft­ware up­date de­liv­ered to users through MeDoc, a Ukrainian ac­count­ing soft­ware provider. While MeDoc has de­nied this, Mi­crosoft has con­firmed that a small num­ber of in­fec­tions were the re­sult of mal­ware be­ing de­liv­ered to ma­chines by the MeDoc’s soft­ware up­date process. Once the mal­ware was in­stalled, in­tra-net­work prop­a­ga­tion func­tions en­abled it to rapidly spread be­tween net­worked ma­chines over the fol­low­ing vec­tors:

Eter­nalBlue and Eter­nalRo­mance ex­ploits: Eter­nalBlue and Eter­nalRo­mance are ex­ploits for SMB re­mote code ex­e­cu­tion vul­ner­a­bil­i­ties (CVE-2017-0144 and CVE-2017-0145) leaked by the Shadow Bro­kers in April These ex­ploits were re­port­edly used to prop­a­gate be­tween net­worked ma­chines run­ning SMB. Patches for these vul­ner­a­bil­i­ties were re­leased by Mi­crosoft in March (MS17010) and in May.

PsExec: The ran­somware used a tool sim­i­lar to Mimikatz to har­vest user cre­den­tials. These cre­den­tials were then passed to an older ver­sion of the PSExec Win­dows tool which was dropped by the mal­ware. This tool then at­tempted to use Pow­erShell re­mote func­tion­al­ity to copy it­self onto a tar­get ma­chine and be­gin ex­e­cu­tion. Win­dows Man­age­ment In­stru­men­ta­tion (WMI): The mal­ware also enu­mer­ated Win­dows net­work shares with WMI and at­tempted to launch a copy of it­self on any dis­cov­ered net­work shares.

Once in­stalled, the mal­ware func­tioned sim­i­larly to Petya, check­ing for the avail­abil­ity of Ad­min­is­tra­tor priv­i­leges by us­ing the Win­dows API Ad­just To­ken Priv­i­leges func­tion. If this was suc­cess­ful, the mal­ware would over­write the in­fected ma­chine’s Master Boot record (MBR), ren­der­ing it un­bootable. If this was not pos­si­ble, AES-128 keys were used to en­crypt each in­di­vid­ual file, with the AES keys sub­se­quently be­ing en­crypted us­ing an RSA-2048 pub­lic key. To ob­tain the pri­vate RSA key nec­es­sary to re­cover the AES keys, vic­tims were in­structed to trans­fer $300 USD in Bit­coin to a spec­i­fied Bit­coin ID and send their wal­let ID and vic­tim ID num­ber in an email to a spec­i­fied ad­dress.

While the mal­ware’s func­tion­al­ity has re­port­edly made it highly ef­fec­tive at prop­a­gat­ing to ma­chines within a lo­cal net­work, it has been re­ported as hav­ing no func­tion for spread­ing out­side of these lo­cal net­works. It was there­fore as­sessed as likely to be much more ef­fec­tive for con­duct­ing tar­geted at­tacks than wCry (AKA Wan­naCry). In the case of NotPetya, it is highly likely that the ran­som pay­ment method was never in­tended to re­sult in rev­enue for at­tack­ers or the re­cov­ery of vic­tim data. Al­though the email ser­vice provider with which the ac­count was reg­is­tered has pub­licly an­nounced that this ac­count has been dis­abled, it has sub­se­quently been re­ported that Rick Hol­land vic­tim ID num­bers were pseudo randomly gen­er­ated rather than be­ing de­rived from the RSA key used for AES key en­cryp­tion.

This in­di­cates that it would not be pos­si­ble for the threat ac­tors to pro­vide vic­tims with the cor­rect de­cryp­tion key, even if a vic­tim had paid the ran­som and suc­ceeded in mak­ing con­tact. Fur­ther­more, Matt Suiche has re­ported that, un­like Petya, which en­crypts an in­fected ma­chine’s MBR in a re­versible man­ner, this mal­ware re­port­edly ir­re­versibly over­wrote 24 sec­tor blocks of the MBR sec­tion of an in­fected ma­chine’s disk, ren­der­ing it per­ma­nently in­op­er­a­ble.

With mone­tary gain as a mo­ti­va­tion out the pic­ture, the most likely mo­ti­va­tion left for NotPeyta’s be­hav­ior is de­struc­tive ma­li­cious in­tent. Ma­li­cious in­tent is not syn­ony­mous with any sin­gle ‘class’ of threat ac­tor, hack­tivists ‘do it for the lulz”; na­tion state ac­tors con­duct ma­li­cious cy­ber-at­tacks to ful­fill geostrate­gic ob­jec­tives. With this in mind, NotPeyta does demon­strate an ad­vanced un­der­stand­ing of how to mount a wide spread hard hit­ting cy­ber-at­tack, and to cap­i­tal­ize on this at­tack with max­i­mum me­dia ex­po­sure.

Clues lie in the geopo­lit­i­cal con­text and the ini­tial tar­get ge­og­ra­phy of the mal­ware. Kasper­sky Labs have claimed a 60/30 per­cent split (to­tal num­ber of in­fec­tions un­known) be­tween Ukraine and Rus­sia. Ad­di­tion­ally, the ini­tial at­tack oc­curred dur­ing the Ukrainian hol­i­day cel­e­brat­ing in­de­pen­dence from Rus­sia. If one sub­scribes to the the­ory that Rus­sian state or af­fil­i­ated ac­tors are re­spon­si­ble, this had the tac­ti­cal ef­fect of de­lay­ing a co­her­ent re­sponse from Ukrainian de­fend­ers and strate­gi­cally pun­ish­ing Ukraine for its in­de­pen­dence from Rus­sia. Al­though these facts are in­ter­est­ing and they do sug­gest that the mal­ware was ac­tively aimed at the Ukrainian econ­omy - they are cir­cum­stan­tial and do not con­clu­sively link the in­ci­dent to any par­tic­u­lar na­tion state. At­tri­bu­tion is and will con­tinue to be a chal­lenge.

The tech­nol­ogy be­hind this at­tack is well within the range of many hack­tivists and cy­ber crim­i­nals, and so these de­tails have less di­ag­nos­tic value when con­sid­er­ing the ‘who’. Al­though spec­u­la­tive, there are other fac­tors to con­sider: the sup­ply chain com­pro­mise, ef­forts at ob­fus­ca­tion (hid­ing the wiper as ran­somware), the ge­og­ra­phy that the mal­ware was de­ployed in, and the tim­ing of the de­ploy­ment with Ukrainian na­tional hol­i­days. This points to­wards an at­tacker with po­lit­i­cal mo­ti­va­tions be­hind the at­tack. It seems that the ac­tor be­hind the NotPetya vari­ant was po­lit­i­cally mo­ti­vated with an ex­cep­tional ap­petite to con­duct cy­ber-at­tacks against spe­cific or­ga­ni­za­tions within the Ukraine tar­get ge­og­ra­phy.

So where does this in­ci­dent leave the longer-term as­sess­ment of the im­pli­ca­tions of NotPetya? Pre­pare for stray bul­lets. Many or­ga­ni­za­tions were im­pacted by the NotPeyta cam­paign. The in­ter­con­nec­tiv­ity of mod­ern sys­tems and the ubiq­uity of ap­pli­ca­tions mean that en­ter­prises could find them­selves the vic­tims of at­tacks not specif­i­cally tar­get­ing their or­ga­ni­za­tions.

The bar for cy­ber-at­tacks keeps get­ting lower. The avail­abil­ity of leaked tools from the NSA and Hack­ingTeam, cou­pled with ‘how to’ man­u­als, means that threat ac­tors will have ac­cess to pow­er­ful tools that they can it­er­ate from and lever­age to ag­gres­sively ac­com­plish their goals. Sadly, cy­ber­at­tacks of this na­ture are not un­com­mon and so busi­nesses, gov­ern­ments and of course con­sumers need to take steps to pro­tect them­selves against ran­somware at­tacks.

The “ba­sics” aren’t easy, but they should not be for­got­ten. Both NotPetya and the ear­lier Wan­naCry ex­ploited ba­sic and known se­cu­rity vul­ner­a­bil­i­ties, so seg­ment­ing net­works and ap­ply­ing ba­sic patch­ing cy­cles will go a long way to mit­i­gat­ing threats such as this. This will go a long way in mit­i­gat­ing the ‘stray bul­let’ fac­tor out­lined above. Think about the soft fac­tors. De­fense is not just about tech­ni­cal in­di­ca­tors and warn­ing any­more, ‘soft’ fac­tors such as mo­ti­va­tion and geostrate­gic is­sues are now not just ‘nice to haves’ but are in­creas­ingly crit­i­cal in the re­sponse to mal­ware like NotPetya.

Plan to fail

No amount of good se­cu­rity will entirely re­move the risk posed by cy­ber­at­tacks so it is crit­i­cal to backup crit­i­cal data and sys­tems on a reg­u­lar ba­sis and en­sure cri­sis man­age­ment and com­pre­hen­sive data re­cov­ery plans are in place and prac­ticed. Ex­tor­tion and de­struc­tive mal­ware re­sponse should be in your in­ci­dent re­sponse play­books. If you aren’t al­ready do­ing so, think about the dig­i­tal risks as­so­ci­ated with your sup­ply chain. Sure, not all sup­pli­ers are at­tack vec­tors for tar­geted at­tacks, but many sup­pli­ers do not have the ma­ture lev­els of se­cu­rity. Re­gard­less of the al­leged cul­pa­bil­ity of MEDoc, the de­ploy­ment mech­a­nism does high­light the at­ten­tion that we all need to start pay­ing to sup­ply chain com­pro­mise.

De­fense in depth

Dig­i­tal Shad­ows ad­vo­cate us­ing a ‘de­fense in depth’ strat­egy guided by four main prin­ci­ples: Con­fig­ur­ing host­based fire­walls and us­ing IP-white list­ing mea­sures, seg­ment­ing net­works and re­strict­ing work­sta­tion-to-work­sta­tion com­mu­ni­ca­tion, ap­ply­ing patches and disabling un­needed legacy fea­tures, and re­strict­ing ac­cess to im­por­tant data to only those who are re­quired to have it. Wan­naCry and NotPeyta is a sign of things to come, and you can ex­pect at­tack­ers will im­prove their fu­ture cam­paigns.

Newspapers in English

Newspapers from Kuwait

© PressReader. All rights reserved.