Cy­ber-at­tacks that tar­get data cen­tres tend to be pa­tient, ma­ture op­er­a­tions that em­pha­sise per­sis­tence and re­quire f ly­ing be­low the radar of se­cu­rity teams. Matt Walm­s­ley, EMEA direc­tor, Vec­tra high­lights the tech­niques that so­phis­ti­cated cy­ber at­tacker


Data cen­tres, and the wealth of informatio­n they con­tain, rep­re­sent a tan­ta­lis­ing prize for at­tack­ers. But un­less the at­tacker gets lucky and finds an In­ter­net-fac­ing vul­ner­a­bil­ity, di­rectly com­pro­mis­ing a data cen­tre takes a sig­nif­i­cant amount of ef­fort and plan­ning.

As a re­sult, cy­ber-at­tacks that tar­get data cen­tres tend to be pa­tient, ma­ture op­er­a­tions that em­pha­sise per­sis­tence and re­quire fly­ing be­low the radar of se­cu­rity teams. From our ex­pe­ri­ence, here are the six most crit­i­cal at­tack vec­tors and tech­niques that so­phis­ti­cated cy­ber at­tack­ers use against data cen­tres.


Ad­min­is­tra­tors have un­par­al­leled ac­cess to the data cen­tre and as a re­sult are nat­u­ral tar­gets for at­tack­ers. Ad­min­is­tra­tive pro­to­cols can give at­tack­ers back­door ac­cess into the data cen­tre with­out the need to di­rectly ex­ploit an ap­pli­ca­tion vul­ner­a­bil­ity. And by us­ing stan­dard ad­min tools such as SSH, Tel­net or RDP, at­tack­ers can eas­ily blend in with nor­mal ad­min traf­fic.


In ad­di­tion to the stan­dard paths utilised by ad­min­is­tra­tors, many data cen­tres rely on lo­cal au­then­ti­ca­tion op­tions, that can be used in an emer­gency, to ac­cess the hosts and work­loads they need to man­age. How­ever, these lo­cal au­then­ti­ca­tion op­tions are not logged, and the same lo­gin cre­den­tials are of­ten shared across hosts and work­loads for the sake

of sim­plic­ity. When at­tack­ers find the cre­den­tials by com­pro­mis­ing an ad­min­is­tra­tor, they can silently ac­cess the data cen­tre with­out fear of their ac­tiv­ity be­ing logged.


Lo­cal au­then­ti­ca­tion of­fers an ex­am­ple of a back­door that ad­min­is­tra­tors — and at­tack­ers — can use to gain ac­cess to a data cen­tre. How­ever, there are other ex­am­ples that take the same ap­proach and ex­tend it deeper into the hard­ware.

While the data cen­tre is syn­ony­mous with vir­tu­al­i­sa­tion, the vir­tu­alised en­vi­ron­ments and re­sources still need to run on phys­i­cal hard­ware. Vir­tual disks are ul­ti­mately de­pen­dent on phys­i­cal disks, and the phys­i­cal disks run in phys­i­cal servers. Phys­i­cal servers like­wise have their own man­age­ment planes de­signed for lights-out and out-of-band man­age­ment. The man­age­ment planes have their own man­age­ment pro­to­cols, power, pro­ces­sors, and mem­ory, which al­low ad­mins to mount disks and re-image servers even when the main server is powered off.

These ac­tions are of­ten per­formed via pro­to­cols such as the In­tel­li­gent Plat­form Man­age­ment In­ter­face (IPMI). While many hard­ware ven­dors have their own branded ver­sions of IPMI — such as Dell IDRAC or HPE In­te­grated Lights- Out (ILO) — they are all based on IPMI and per­form the same func­tions.

IPMI and its re­lated pro­to­cols have well-doc­u­mented se­cu­rity weak­nesses and are of­ten slow to re­ceive up­dates and fixes. Ad­di­tion­ally, there is cur­rently a wor­ry­ing 92,400 hosts’ IPMI in­ter­faces ex­posed to the in­ter­net. The com­bi­na­tion of IPMI vul­ner­a­bil­i­ties and its im­mense power make it a ma­jor at­tack vec­tor for bad ac­tors that are try­ing to sub­vert the se­cu­rity of the data cen­tre.


Un­for­tu­nately, hard­ware prob­lems in the data cen­tre don’t end with IPMI. Ad­vanced at­tack­ers, in­clud­ing na­tion­states, in­creas­ingly tar­get phys­i­cal servers, routers, switches, and even fire­walls. At a fun­da­men­tal level the at­tack­ers use rootk­its that sit be­low the level of the op­er­at­ing sys­tem, mak­ing them ex­tremely dif­fi­cult to de­tect us­ing tra­di­tional meth­ods.

These tech­niques al­low at­tack­ers to in­fect the very de­vices that are trusted and charged with pro­tect­ing the net­work, and then use those de­vices to launch at­tacks deeper into the net­work.


The ul­ti­mate goal of most at­tacks is to steal data. De­pend­ing on their needs and skill level, at­tack­ers can use a va­ri­ety of ap­proaches to smug­gle data out of the data cen­tre. The most ob­vi­ous ap­proach in­volves mov­ing data in bulk out of the data cen­tre, ei­ther di­rectly to the In­ter­net or to an in­ter­me­di­ate stag­ing area in the cam­pus net­work.

Sub­tle at­tack­ers may at­tempt to stay low-and-slow by pa­tiently ex­fil­trat­ing data at rates that are less likely to be no­ticed or arouse sus­pi­cion. Ef­forts can also be made to ob­scure data ex­fil­tra­tion in hid­den tun­nels within nor­mally al­lowed traf­fic, such as HTTP, HTTPS or DNS traf­fic.


Data cen­tres are unique to their own or­gan­i­sa­tions and vary based on ap­pli­ca­tions and how users in­ter­act with them. The most com­mon type of data cen­tre to­day is the pri­vate en­ter­prise data cen­tre. At­tacks against these data cen­tres are typ­i­cally ex­ten­sions of at­tacks against the larger en­ter­prise.

For ex­am­ple, at­tack­ers may have ini­tially com­pro­mised an em­ployee lap­top via a phish­ing email or so­cial en­gi­neer­ing. Next, at­tack­ers typ­i­cally look to es­tab­lish per­sis­tence within the net­work by spread­ing from the ini­tial vic­tim to other hosts or de­vices. To con­trol the on­go­ing at­tack, at­tack­ers will plant back­doors or hid­den tun­nels to com­mu­ni­cate back and forth from in­side the net­work. Over time, at­tack­ers will map out the in­ter­nal net­work, iden­tify valu­able re­sources, and com­pro­mise de­vices and user cre­den­tials along the way.

The most cov­eted stolen as­set for an at­tacker is ad­min­is­tra­tor cre­den­tials be­cause they en­sure near au­ton­omy in­side the vic­tim’s net­work. Ad­min­is­tra­tor cre­den­tials are par­tic­u­larly es­sen­tial for data cen­tre at­tacks, since ad­min­is­tra­tors are of­ten the only in­di­vid­u­als who can ac­cess data en masse.

The key point is that an at­tack is typ­i­cally at a ma­ture stage by the time it reaches a pri­vate data cen­tre. The hid­den com­mand-and-con­trol traf­fic, the re­con­nais­sance, the lat­eral move­ment and the com­pro­mise of user and ad­min cre­den­tials are all pre­req­ui­sites that lead up to the in­tru­sion into the data cen­tre.

While most data cen­tre se­cu­rity has fo­cused on pro­tect­ing the vir­tu­alised lay­ers of the data cen­tre and mi­cro-seg­men­ta­tion, real-world at­tack­ers are in­creas­ingly sub­vert­ing the phys­i­cal in­fra­struc­ture that the data cen­tre de­pends on.

The use of ad­vanced at­tacker de­tec­tion mod­els that ex­pose hid­den at­tacks against ap­pli­ca­tion, data and vir­tu­al­i­sa­tion lay­ers in the data cen­tre, as well as the un­der­ly­ing phys­i­cal in­fra­struc­ture, will en­able se­cu­rity teams to ad­dress crit­i­cal vul­ner­a­bil­i­ties at ev­ery layer of the vir­tu­alised data cen­tre, even when at­tack­ers use le­git­i­mate ser­vices and pro­to­cols for their il­le­git­i­mate ac­tions.

Matt Walm­s­ley, head of EMEA Mar­ket­ing - Vec­tra.

Newspapers in English

Newspapers from UAE

© PressReader. All rights reserved.