Implementing a Remote Access Trojan Infrastructure

Scriptie ingediend tot het behalen van de graad van PROFESSIONELE BACHELOR IN DE ELEKTRONICA-ICT

Implementing a Remote Access Trojan Infrastructure Elvira Poiters Departement Wetenschappen en Techniek Opleiding Elektronica-ICT Academiejaar 2014-2015

Interne promotor: Tim Dams Externe promotor: Dieter Vandenbroeck & Peter Van Overschelde

Versie: 12 juni 2015

Dankwoord

Allereerst bedank ik EY, en in het bijzonder Dieter Vandenbroeck, om mij de kans te geven stage te lopen in ’one of the big four’. EY is een impressionant bedrijf en een grote speler; de ervaring die ik hier heb mogen opdoen is ongetwijfeld een voordeel naar komende jaren toe. Tim Dams mag ik ook niet vergeten te vermelden. As far as promoters go, is Tim wat mij betreft de beste keuze. Hij stond steeds klaar met advies en hulp. Bovendien is hij begaan met zijn studenten en kunnen wij op hem rekenen. Hij heeft in de loop der jaren menig crisis bezworen en peptalks gehouden. Tim, bedankt. Enkel andere namen die ik wil vermelden zijn Jens Pelgrims, Virginie Mathieu, Dorien Raspoet, en Peter Van Overschelde; nieuwe collega’s en vrienden die mijn stage beduidend aangenamer hebben gemaakt, zij het door hun sympathie, humor, honeybadgers, of cake. In meer huiselijke sfeer wil ik tot slot Bram De Haes bedanken. Voor de aanmoediging die hij heeft gegeven, de ondersteuning op moeilijkere momenten en de lof bij overwinningen. De mogelijkheid om deze opleiding te starten heb ik aan hem te danken. Last but not least, verdient Ward Gubbi een uitzonderlijke vermelding. Niet alleen is hij een geweldige vriend, maar zonder diens hulp was ik nooit tot hier geraakt. Antwerpen, 12 juni 2015 Elvira Poiters

i

Abstract EY (Ernst & Young) is ’one of the big four’ in België, één van de grote multinationals. Een bedrijf, van oorsprong audit gericht, dat zich ontwikkelt op verschillende vlakken. ”Advisory” is één van de vier grote takken. Het is in deze tak dat de afdeling ”ITRA”zich bevindt, welk staat voor ”Information Technology and Risk Advisory”. Een onderdeel hiervan is ”Information Security”, dewelke zich toespitst op de beveiliging van digitale informatie. Dit houdt in dat er ook actieve pentesting wordt gedaan om een assessment te kunnen opstellen van het beveiligingsniveau van de infrastructuur of applicatie van een klant. De huidige bachelorproef is ontwikkelt in deze context. In het kader van EY’s security pentesting mogelijkheden, is er nood aan een C&C-server om een reeds bestaande Remote Access Trojan (RAT) te implementeren. De RAT-payload wordt geleverd aan het doelsysteem via social engineering technieken zoals het lost usb ploy, phising, of een andere creatieve input. Het doel van deze trojan is om de aanvaller (EY) toegang te verlenen tot een doelsysteem en op deze manier informatie kan ontfutselen. Om de communicatie met de RAT te onderhouden en de gevonden informatie te verwerken is er nood aan een gestructureerde serverside applicatie. D Deze applicatie werd in dit project gerealiseerd in PHP gekoppeld met een MySQL database. De communicatie tussen server en zombie verloopt via HTTP-requests, met de data in parameters binnen een form. Buiten het verwerken van input vanuit de ge¨ınfecteerde systemen, geeft de applicatie ook controle aan de gebruiker. Deze kan de gegevens opvragen van alle ’zombies’, samen met welke commando’s reeds zijn uitgevoerd en uiteraard de resultaten hiervan. Eveneens belangrijk is uiteraard dat de gebruiker ook nieuwe commando’s kan sturen naar de doelsystemen. Dit kan zowel naar allemaal tegelijk, of de gebruiker kan een keuze maken. Het project is goed verlopen en er kunnen positieve resultaten worden aangetoond. De doelstellingen zijn behaald en de gewenste functionaliteit is aanwezig. Twee aspecten die echter onbreken zijn de encryptie van de communicatie, en de beveiliging tegen SQL-injectie. Keywords : IT, Security Pentesting, Social Engineering, C&C

ii

Inhoudsopgave

Dankwoord

i

Abstract

ii

1 Inleiding 1.1 Onderwerp . . . . . . 1.1.1 Situering . . . 1.1.2 Doelstellingen 1.2 Relevantie binnen EY

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

1 2 2 3 3

2 Bespreking C&C Server 2.1 Botnets . . . . . . . . . . . . 2.2 Componenten . . . . . . . . 2.2.1 Database . . . . . . . 2.2.2 Model-View-Controller 2.3 Ontwikkeling . . . . . . . . . 2.3.1 Tools . . . . . . . . . 2.3.2 Opbouw . . . . . . . 2.3.3 Functionaliteit . . . . 2.3.4 Viewstate . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

4 4 4 4 6 8 8 8 11 15

3 Resultaten 3.1 Visuele Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Application Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Problematiek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16 20 23

4 Conclusie 4.1 Algemeen Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Beperkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 En Verder? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24 24 24 25

. . . .

. . . .

. . . .

iii

INHOUDSOPGAVE A Social Engineering Toolkit A.1 Promotiemateriaal - Placemat & Flyer . . . . . . . . . . . . . . . . . . . . .

iv 26 27

Lijst van figuren

2.1 2.2 2.3 2.4

Relationeel database diagram . . . Model-View-Controller . . . . . . . Interactie Diagram . . . . . . . . . Verbinding tussen zombie en server

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5 7 9 12

3.1 3.2 3.3 3.4

De overzichtspagina De resultatenpagina De resultatenpagina Application flow . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

17 18 19 20

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

v

Hoofdstuk

1

Inleiding Een van de vele services die EY aanbiedt is ”Advisory”. Deze tak bevat een breed scala aan consultancy gerichte diensten. Een subservice binnen deze afdeling is ”ITRA”(Information Technologie and Risk Advisory). Binnen ITRA vinden we dan ook de IT-gerelateerde consultancy terug. De werknemers in deze subservice houden zich bezig met het testen en controleren van de cyberbeveiliging in externe bedrijven. Dit kan o.a. bestaan uit het nakijken van broncode, pentesting, social engineering attacks, zero-day exploits monitoren, en alle andere mogelijk gradaties en varianten. Het is binnen deze context dat de huidige bachelorproef plaatsvind. In dit hoofdstuk komt als eerste het onderwerp van de bachelorproef aan bod. Er wordt uitgelegd wat de precieze doelstellingen zijn en kort vermeld in hoeverre deze zijn behaald. Verder wordt kort de inhoud geschetst van het stageonderwerp. Tot slot wordt toegelicht op welke manier de bachelorproef een bijdrage kan betekenen voor EY. In het tweede hoofdstuk wordt er dan dieper ingegaan op het werkproces. Er wordt besproken welke technieken aan bod zijn gekomen om het eindresultaat te bereiken. Ook de minder succesvolle onderdelen zullen worden toegelicht, inclusief eventuele problemen en hun oplossingen. Verder wordt de architectuur van de applicatie besproken en de algemene werking globaal toegelicht. Het derde hoofdstuk bevat de bekomen resultaten. Dit deel zal hoofdzakelijk bestaan uit de visuele aspecten van de applicatie. Voort zal de werking van de applicatie in detail worden besproken. Het laatste hoofdstuk beschrijft de algemene conclusie van de bachelorproef. Hierin worden de behaalde resultaten vergeleken met de vooropgestelde doelstellingen. Eventuele toekomstige projecten waarbij de applicatie van toepassing is kunnen toegelicht worden. Als afsluiter worden mogelijke verbeterpunten of uitbreidingsmogelijkheden in kaart gebracht.

1

HOOFDSTUK 1. INLEIDING

1.1

2

Onderwerp

Om te starten is het nodig te vermelden dat het onderwerp van deze bachelorproef twee weken na aanvang van de stage is veranderd. De oorspronkelijke doelstellingen uit het projectplan zijn dan ook niet meer van toepassing. Deze eerste opdracht omvatte het uitbouwen van een Social Engineering Toolkit en deze in de vorm van een webapplicatie gieten. In week twee kwam er echter een voorstel voor een ander onderwerp van een collega. Dit voorstel betrof het schrijven van een C&C serverapplicatie. De argumentatie was dit meer nut zou hebben binnen de organisatie dan de social engineering toolkit. Bovendien bleek dat de psycho-sociale aspecten van social engineering bitter weinig onderzocht zijn. Digitale bronnen zoals wetenschappelijke tijdschriften of simpel google academic leverde weinig tot geen resultaten op. Ik heb ook kennissen binnen de psychologische academische wereld gecontacteerd, maar ook dat bracht geen soelaas. Indien dit een stage zou zijn in het kader van een psychologisch gerelateerde opleiding was het ongetwijfeld heel interessant geweest om hierover een verkennend onderzoek op te stellen. Helaas is dit niet het geval. Er is dan ook besloten om het stageonderwerp te veranderen. Er is echter een klein onderdeel van de oorspronkelijke opdracht behouden geweest. Meer informatie hierover en bijhorende resultaten zijn terug te vinden achteraan in appendix A (zie A).

1.1.1

Situering

Zoals reeds eerder gezegd ontstaat dit project in het kader van een Red Team pentesting aanval. Een veel voorkomende opstelling is het gebruik van social engineering technieken in combinatie met meer technische methodes om een aanval op te starten. Een bekend social engineering methode is het lost USB-scenario. Aansluitend bij dit type aanval is er nood aan een C&C serverstructuur. Het Lost USB Scenario Een goede social engineer maakt gebruik van typische menselijke zwakheden. Nieuwsgierigheid is daar een goed voorbeeld van. De lost USB methode maakt hier handig gebruik van door USB-sticks ”verloren”te leggen in ruimtes waar werknemers van het doelbedrijf makkelijk komen. Doeltreffende ruimtes hiervoor zijn de lobby, het restaurant, en bij uitstek de parking; deze laatste is immers vaak publiekelijk toegankelijk, wat de taak van de social engineer vergemakkelijkt. Op de achtergelaten USB-sticks staat dan een (verborgen) malware programma. Liefst worden de USB’s nog gelabeld met iets dat de nieuwsgierigheid prikkelt zoals bijvoorbeeld ”Salarissen 2015”. Het idee is dat een argeloze werknemer verleid wordt om de USB mee te nemen en in te pluggen in zijn of haar workstation. Op dat moment schiet de

HOOFDSTUK 1. INLEIDING

3

malware in actie en lanceert zijn payload. Deze paylaod (takenpakket) zal vaak bestaan uit het verzamelen van informatie en dit doorsturen naar de server. Ook via andere social engineering methodes zoals phising kan dezelfde malware worden toegepast uiteraard. Command & Control Server Een Command & Control server heeft als kerntaak het aansturen en beheren van verscheidende ”ge¨ınfecteerde”doelsystemen (zombies). Deze doelsystemen worden ge¨ınfecteerd met een malware programma (de RAT) en communiceren daarna met deze C&C server. De malware vermeld in voorgaande paragraaf is reeds aanwezig binnen de EY security toolkit. Wat echter nog ontbrak was een georganiseerde manier om binnenkomende informatie te verwerken. Hiervoor wordt dan de C&C applicatie geschreven. Door gebruikers een interface te geven om de zombies te beheren en informatie op te vragen faciliteert het project zowel de gebruiksvriendelijkheid van de malware tool, als ook de mogelijke functionaliteiten. Peter, de directe stagementor, werkt parallel mee aan het project. Hij maakt gaandeweg ook aanpassingen aan de malware zodat mijn serverfunctionaliteit compatibel blijft met de payload.

1.1.2

Doelstellingen

Onderstaande opsomming geeft weer wat de doelstellingen zijn voor dit project. ◦ De ge¨ınfecteerde zombie kan zich registreren. ◦ De gebruiker kan een commando sturen naar de geselecteerde zombie(s). ◦ De teruggestuurde resultaten kunnen worden weggeschreven naar de database. ◦ De gebruiker kan een overzicht opvragen per zombie en per commando. Een belangrijk punt om in gedachten te houden bij dit project is dat de communicatie tussen zombie en server zo onopvallend mogelijk moet verlopen. Zodra de malware gedetecteerd wordt door het doelsysteem is de opzet van de aanval natuurlijk verloren gegaan.

1.2

Relevantie binnen EY

Dit project kan zeker een bijdrage leveren voor het pentesting team van EY. Het is een handige aanvulling op een bestaande techniek en bovendien kan het in verscheidene situaties ingezet worden. De applicatie is ook verder uitbreidbaar indien gewenst en kan worden aangepast naar toekomstige projecten toe.

Hoofdstuk

2

Bespreking C&C Server 2.1

Botnets

Een botnet heeft traditiegetrouw een negatieve connotatie met illegale activiteiten [1]. Een botnet bestaat uit verschillende hosts die doorgaans niet bewust zijn van het feit dat ze deel uitmaken van een botnet. Een botnet wordt beheerd door een persoon genaamd ”herder”via een Command & Control server. Deze kan gecentraliseerd of gedistribueerd zijn. Traditioneel verloopt de communicatie van botnets via IRC (Internet Chat Relay) maar dit hoeft niet altijd zo te zijn, zoals verder zal worden aangetoond. Een botnet kan voor allerhande doelen worden ingezet, zoals de herder het wil. Typische toepassingen zijn spammen en DOS-aanvallen.

2.2

Componenten

Voor dit stage project is er gebruik gemaakt van twee grote componenten. Enerzijds de PHP scripts die de webinterface vormen en de achterliggende functionaliteit en anderzijds de database waarin alle informatie wordt opgeslagen.

2.2.1

Database

Er wordt in deze applicatie gewerkt met een MySQL database. Dit is opensourcesoftware en daarom geschikt voor een stage project. Bovendien is MySQL snel, met toch lage hardware vereisten. Voorts is dit een van de bekendste databases en heeft daardoor een ruime ondersteuning vanuit de gemeenschap. MySQL is ook een heel flexibel platform, geschikt voor zowel Windows als Linux. Deze relationele database is ook al aan bod gekomen tijdens de 4

HOOFDSTUK 2. BESPREKING C&C SERVER

5

opleiding; de materie was dus al vertrouwd. Bovendien is de drempel laag; het is makkelijk te hanteren software met een duidelijke grafische interface. Tot slot biedt MySQL ook drivers en connectors voor een waaier aan applicaties, inclusief PHP. Relationeel Database Diagram In onderstaand diagram is de database structuur terug te vinden.

Figuur 2.1: Relationeel database diagram Clients De tabel ’Clients’ bevat alle info per geregistreerde zombie. Dit is de eerste tabel die opvult wanneer de applicatie zal worden gestart. Wanneer een nieuwe zombie zich aanmeldt stuurt deze een parameter mee met het merendeel van de info. ◦ Intern IP-adres ◦ Een unieke serialnummer


6

◦ Username ◦ Hostname ◦ Is de gebruiker een admin? Ja/nee ◦ De Windows versie en patches ◦ Locatie Het extern IP-adres kan worden afgeleid uit de request zelf. De status wordt bij een succesvolle registratie automatisch ingesteld op ”registered”. De kolom ” Timestamp”duidt aan wanneer de zombie geregistreerd werd (gegenereerd door MySQL). Results Wanneer een commando wordt uitgestuurd naar een of meerdere zombies wordt dit geregistreerd in de tabel ”results”. Per zombie die dan het commando zal ontvangen wordt er een rij aangemaakt. Onderstaande zaken worden opgeslagen. ◦ De serialnummer van de zombie ◦ Het commando zelf vb. ipconfig /all ◦ Het type commando. Dit is in de vorm 0x00 en laat de malware weten wat voor soort commando het moet uitvoeren. ◦ De beschrijving van het commando (optioneel) ◦ De status wordt verandert in ”waiting”. ◦ Hier geeft de timestamp aan wanneer het commando is uitgestuurd. De kolom ”results”wordt aangevuld wanneer een zombie het resultaat terugstuurt van het ontvangen commando. Commands Deze tabel is voorlopig nog niet in gebruik. De bedoeling is dat hier prefab commando’s zullen in worden gezet waaruit de gebruiker dan een keuze kan maken. Extra hierbij is de naam die aan het commando gegeven kan worden. Bijvoorbeeld ”portscan” of ”IP configuratie”. Wanneer de gebruiker in de webinterface de mogelijk commando’s opvraagt kunnen deze dan overzichtelijk worden weergegeven door middel van een duidelijke, descriptieve naam.

2.2.2

Model-View-Controller

Voor het coördineren van de PHP scripts is gewerkt met het MVC model. Dit is een gestructureerde aanpak waarbij de drie componenten - Model, View, Controller - netjes gescheiden blijven. Ik heb specifiek voor een dergelijke methode gekozen om te vermijden dat uiteindelijk alle code in één pagina wordt gegoten en zo een onoverzichtelijke cluster creëert.


7

Figuur 2.2: Model-View-Controller Bovenstaande afbeelding geeft goed weer hoe de huidige applicatie gebruik maakt van een MVC structuur. Elke actie begint met een HTTP request, ge¨ınitieerd door ofwel user-input in de browser ofwel door de zombie. De controller verwerkt deze input en bepaalt welke actie dient te worden uitgevoerd. Het geeft de benodigde parameters door aan het model. Het model bevat alle functionaliteit en correspondentie met de database. Hierin zijn dus alle database statements zoals ”select”, ¨ınsert”, e.a. terug te vinden. Het model is zich niet bewust van de controller en kent de view niet. Dit onderdeel connect slechts met de database en geeft de gevonden resultaten terug aan de controller. De resultaten worden dan door de controller doorgegeven aan de correcte view. De controller kent de view dus wel. Indien er meerdere views zijn is het de controller’s taak om de juiste view te laden. De view is dan uiteindelijk de HTML pagina die getoond word in de browser of een HTTP response terugstuurt naar de zombie. De view bevat geen functionaliteit, enkele pure HTML layout. De view is zich niet bewust van de controller noch van het model.


2.3 2.3.1

8

Ontwikkeling Tools

Er is gebruik gemaakt van het EasyPHP framework. Dit bevatte de MySQL software, een Apache server, en PHP ondersteuning. Het was dus een ideaal startpakket. Verder heeft ook Burpsuite zijn nut bewezen. Dit programma heeft uitstekende netwerk security features dewelke heel handig zijn voor het bekijken van o.a. HTTP traffic. Door Burpsuite te laten werken als proxy-server kunnen alle browser requests en responses worden geanalyseerd, wat fouten opsporen makkelijker maakt. Ook handig is de mogelijkheid om een HTTP request te simuleren. Op die manier kan de payload functionaliteit worden gesimuleerd in kleinere stappen. Verder is er eveneens een base64 encoder-decoder inbegrepen.

2.3.2

Opbouw

Voorbereiding De eerste stap was het researchen van botnets en C&C server applicaties. Er is gezocht naar algemene werking, de technische aspecten, en de typische functionaliteit. Om de scope van de opdracht in kaart te brengen is er een interactiediagram opgesteld. Dit moest de nodige functionaliteit weergeven, alsook de layout van de applicatie. Belangrijk hierbij was aangeven welke parameters verwacht werden bij elke feature. In figuur 2.3. is dit diagram te zien. Dit geeft dus een ruwe schets weer van welke functies in welk deel van de applicatie verwacht werden. Dit was slechts een eerste idee aan het begin van het project en geeft dus niet alles volledig weer. De ”ClientControl”kant is bijvoorbeeld veel uitgebreider. De dashboard functionaliteit is dan wel betrekkelijk volledig.


9

Figuur 2.3: Interactie Diagram Er is besloten de applicatie in PHP te schrijven. Dit staat voor Hypertext Preprocessor en is een serverside scripttaal. De taal is ontwikkeld met het oogpunt op het creëren van dynamische webapplicaties. Database Connectie Een tweede stap was het ontwerpen en aanmaken van de database. Aangezien de applicatie geen extensieve structuur vereist was dit snel afgerond. Voor de connectie met de database te maken waren twee methodes beschikbaar om uit te kiezen : MySQLi extension PHP Data Objects (PDO)

MySQLi extension was de oudere methode. PDO is een recentere techniek. Deze nieuwe methode biedt twee belangrijke voordelen. [3] Ten eerste is er de database driver compatibiliteit waarmee de PDO manier scoort. Momenteel ondersteunt PDO twaalf verschillende drivers waarmee verbinding met verschillende database types mogelijk is, waaronder uiteraard MySQL. Echter ook Cubrid, IBM, Oracle, MS SQL Server, Firebird, Informix, ODBC, PostgreSQL, SQLite, en 4D. Dit in tegenstelling tot de


10

MySQLi extension, welk enkel geschikt is voor mySQL. Een gevolg hiervan is dat een applicatie met PDO veel flexiber is. Indien er ooit gemigreerd wordt naar een ander database type moet enkel de connectie string worden aangepast en eventueel enkele query-methoden. Indien gebruik wordt gemaakt van de MySQLi extension moet elk stukje code volledig worden herschreven. Het gebruik van named parameters is een tweede grote voordeel. Dit maakt het veel eenvoudiger om parameters te binden in een query. Onderstaan is een codesnippet dat de connectie met de database toont. 1 s e t A t t r i b u t e (PDO : : ATTR ERRMODE, PDO : : ERRMODE EXCEPTION ) ; 9 $ pageData−>c o n t e n t =”
We ’ r e c o n n e c t e d !
” ; 10 } c a t c h ( E x c e p t i o n $ e ) { 11 $ pageData−>c o n t e n t=”
C o n n e c t i o n f a i l e d b e c a u s e :
$ e ” ; 12 }

Listing 2.1: Connectie met database via PDO Zoals gezien kan worden draait de database voorlopig lokaal. Bij default staan foutmeldingen uitgeschakeld. Op lijn 8 worden deze manueel aangezet en getoond. MVC Layout De applicatie is opgesplitst in twee onderdelen, die beide onafhankelijk met de database communiceren. Enerzijds is er het dashboard: hier kan de gebruiker de zombies aansturen en bekijken. Dit is het werkelijke Command&Control gedeelte. Anderzijds is er ook de toegangspagina voor de zombies zelf. Dit is een neppe, nietszeggende pagina dewelke enkel dient als front om de zombie toegang te verlenen tot de database. Voor het dashboard gedeelte worden er volgende PHP pagina’s gebruikt : View

page.php : Dit is de backbone van alle andere HTML pagina’s. Dit bevat enkel het HTML skelet. home html.php : De welkomstpagina. instructies worden getoond.

Hier kan een welkomstboodschap of

navigation html.php : De navigatiebalk en banner worden op elke pagina opnieuw getoond. zombieControl html.php : Op deze pagina kan de gebruiker een overzicht opvragen van alle geregistreerde zombies. Deze gegevens worden eerst algemeen getoond.


11

Door op een zombie te klikken kunnen dan de details worden weergegeven. Per zombie kunnen ook alle commando’s worden opgevraagd die reeds zijn uitgevoerd door desbetreffende zombie. resultOverview html.php : Wanneer er op een commando wordt geklikt, verschijnt deze pagina. Hierop ziet men een overzicht van het commando, de eigenschappen, en uiteraard het resultaat. sendCommand html.php : Tot slot moeten er ook nieuwe commando’s gestuurd kunnen worden. Dit kan zowel naar allemaal tegelijkertijd, of enkel naar geselecteerde zombies.

Controller De zombieController.php pagina verwerkt alle gebruikers input en geeft de correcte View terug om weer te geven. Model Het zombieModel.php bevat een klasse ”Zombie”waarvan de constructor de connectie met de database maakt. Verder bevat deze alle functionaliteit in verband met database query’s. Het front gedeelte volgt dezelfde layout maar de Views zijn hier veel beperkter. Dit is tenslotte maar een fa¸cade om alerte netwerk administrators te omzeilen. View

page.php Search html.php : Dit is de valse pagina. De zombies bezoeken deze pagina en verzenden hier de viewstate parameter met data of halen een nieuwe commando op. Om geen argwaan te tonen is hierop een eenvoudige zoekbar te zien, met de melding dat de gewenste zoekterm niet gevonden is. Dit is geëncapsuleerd in een form. Dit om de argwaan van een netwerkadmin niet te wekken wanneer hij of zij een viewstate ziet staan in de html van de pagina.

Controller De frontController.php heeft een gelijkaardige functie als in het voorgaande gedeelte; het regelt alle input van de zombie en geeft hierop response, weergegeven via de viewstate paramater. Model Ook frontModel.php heeft eenzelfde functie, namelijk het bewaren van alle nodige functionaliteit.

2.3.3

Functionaliteit

De doelwitten van een aanval zijn doorgaans, om niet te zeggen altijd, computers van werknemers binnen een groot bedrijf. Het is dan ook te verwachten dat deze computers zich in een beveiligd netwerk bevinden. Een firewall of proxy beveiliging is dan ook geen verrassing. Om detectie te vermijden gebruikt de payload dan ook normale HTTP-requests. Dit type verkeer is zeer gebruikelijk en zal geen argwaan wekken.


12

Verder wordt er gebruik gemaakt van de legitieme ’viewstate’ parameter. Dit is een HTTP parameter die de informatie uit de HTML tag ’form’ bevat, standaard geëncodeerd in base64. Door de informatie gelijkaardig te encoderen en in deze parameter te plaatsen, wordt detectie van onze activiteiten iets moeilijker gemaakt.

Figuur 2.4: Verbinding tussen zombie en server De werking van de applicatie begint bij een PC die ge¨ınfecteerd word door de payload, geleverd via USB of een phising attack. Zodra de payload ge¨ınstalleerd is op deze PC, wordt deze aangeduid als een ”zombie”. De zombie start eerst met het verzamelen van bepaalde gegevens van het gastsysteem o.a. hostname en systeem info. Er word eveneens een unieke serialnummer samengesteld en opgeslagen als cookie. Deze informatie wordt gebundeld in een vast formaat, geëncodeerd met base64, en geplaatst in voorgenoemde ’viewstate’ parameter. Er wordt ook nog gebruik gemaakt van een tweede parameter namelijk de ’viewstategenerator’. Deze parameter geeft aan of de zombie een nieuw commando komt aanvragen of een resultaat komt terugbrengen. Van dit alles wordt een POST-request gemaakt. Daarna maakt de zombie verbinding met de valse pagina van de server, en post hierop de informatie. De algemene flow van de communicatie tussen zombie en server gaat als volgt : Hieronder worden de verschillende functionaliteiten verder in detail besproken.


13

Algorithm 1 Application Flow 1: check VIEWSTATE 2: $ COOKIE = serialnummer 3: if serialnummer staat niet in tabel ’clients’ then 4: zombie registreren 5: else if serialnummer staat in tabel ’clients’ then 6: check VIEWSTATEGENERATOR 7: if VIEWSTATEGENERATOR = 0 then 8: return nieuw commando 9: insert commando in VIEWSTATE parameter 10: else VIEWSTATE is result 11: insert result in database 12: end if 13: end if Registratie Wanneer de server een Viewstate ontdekt, decodeert het eerst terug de data. Deze data is een string met verschillende parameters erin. Een voorbeeld hiervan is : 192.168.0.1|EURW@user1|BE2052806W1|NO|Windows 6.1 Build 7601 Revision 65536|C://.../payload.exe Deze data moet eerst opgesplitst worden zoals te zien is in tabel 2.1. Dit is de opsplitsing die de database verwacht. Intern IP Hostname Username Admin 192.168.0.1 EURW@user1 BE2052806W1 NO

Systeminfo Windows 6.1 Build 7601 Revision 65536

Path to location C://.../payload.exe

Tabel 2.1: Voorbeeld VIEWSTATE De server kent het formaat van deze data en kan deze opsplitsen in overeenstemming met de verschillende kolommen in de databasetabel ’clients’. Deze splitsing gebeurd door de explode() functie, gebaseerd op het ’|’ karakter. Via de PHP globale functies ’$ COOKIE’ en ’$ SERVER[’REMOTE ADDR’]’ kunnen respectievelijk de serialnummer en het extern IP adres van de zombie worden gevonden. Al deze gegevens samen creëren dan een nieuwe rij in de database tabel ’clients’. Dit is de registratie van de zombie.


14

Commando sturen Invoer De gebruiker kan op het dashboard een nieuw commando invoeren. Hierbij is er een een inputvenster voorzien voor zowel het type als het commando zelf. Het type maakt duidelijk aan de payload hoe het commando verwerkt moeten worden. De verschillende types die initieel beschikbaar zijn worden hieronder op gelijst. – 0x00 : Gebruik het Diagnostisch Process om het commando uit te voeren. – 0x01 : Gebruik Powershell om het commando uit te voeren. – 0x02 : Vraag een bestand op. – 0x03 : Download een bestand van een externe URL. – 0x04 : Download een bestand van een externe URL en voer het meteen uit. – 0x10 : Zoek achter credentials. – 0x99 : Verander runtime instellingen. Deze types worden gedefinieerd aan de payload zijde. De reden voor de hiaat tussen de opeenvolging is om voldoende plaats te laten voor potentieel toekomstige aanvullingen. In het inputvenster voor het commando zelf komt dan het werkelijk commando te staan. Een voorbeeld hiervan is ¨ıpconfig /all”. De gebruiker kan eveneens kiezen om het commando naar alle geregistreerde zombies te sturen (via de knop ”Send To All”) of naar enkele geselecteerde zombies (via de knop ”Send To Selected”). Bij deze laatste optie moet er wel uit het lijstje met beschikbare zombies minstens één ervan worden aangeduid. Nadat op één van beide knoppen is geklikt, wordt het commando weggeschreven naar de database. De server zoekt in de tabel ’clients’ naar de geselecteerde zombies op basis van hun serialnummer. In het geval dat het commando naar allemaal moet worden gestuurd, haalt de applicatie dus alle serialnummers op. Per nummer wordt er dan een nieuwe rij aangemaakt in de tabel ’results’ waar het nieuwe commando wordt opgeslagen. In de kolom ’status’ komt automatisch ”waiting”te staan. Dit geeft aan dat het commando nog moet worden uitgevoerd. Uitlezen Wanneer een zombie verbinding maakt met de server en de viewstategeneratorparameter staat op nul, wilt dit zeggen dat er een nieuw commando kan uitgevoerd worden. Zodra de server deze connectie opmerkt gaat het in de database opzoek naar commando’s met de status ”waiting ”. De uitgevoerde query haalt het eerste resultaat op en plaatst het nieuwe commando in de viewstate-parameter. Het commando ID dat hierbij hoort wordt toegewezen aan de viewstategenerator-parameter. Dit is nodig om op een later punt het juiste resultaat aan een uitgevoerd commando te kunnen koppelen. De twee parameters worden opnieuw verborgen in een form-tag in de HTML.


15

Resultaat verwerken Uiteraard is heel de aanval pas nuttig als er ook resultaten te zien zijn. Nadat de payload het nodige werk heeft verricht, gebruikt het opnieuw de POST-methode om de verzamelde informatie weer te geven. De informatie wordt ook nu gecommuniceerd via de viewstate. Deze keer vindt de server de gebruikte serialnummer wel terug in de database. Bovendien heeft de viewstategenerator-parameter de waarde van het command-ID dat is uitgevoerd. Op die manier weet de applicatie waar de inhoud van de viewstate moet worden opgeslagen. Tijdens het opslaan van nieuwe informatie wordt de status verandert naar ”command complete”. De volgende keer dat de zombie een nieuw commando komt opvragen, weet de server dat dit commando niet meer moet worden gegeven. Beheer Tot slot is het nodig dat de gebruiker toegang heeft tot de resultaten van de applicatie. Er kan een overzicht worden opgevraagd van alle zombies die geregistreerd staan. Per entree kunnen dan alle details worden bekeken. Bovendien kan per zombie worden nagekeken welke commando’s deze reeds heeft uitgevoerd en welke nog in de wachtrij staan. Uiteraard kunnen ook de resultaten van een afgerond commando worden bekeken.

2.3.4

Viewstate

Hoewel de term ”Viewstate” al enkele malen vermeld is, verdient deze mogelijks toch zijn eigen paragraaf. De Viewstate is een belangrijke parameter in deze applicatie omdat het juist dit onderdeel is dat de malware activiteit verbergt. De Viewstate is een parameter behorend tot de .aspx extensie en dus tot het .NET framework. Hierbij wordt de viewstate van een pagina standaard opgeslagen in een verborgen veld van een form genaamd VIEWSTATE. Dit veld kan enorm groot worden en is altijd geëncodeerd met base64. [4] Door deze omstandigheden te imiteren in deze applicatie proberen we een netwerkadmin wijs te maken dat onze communicatie ”legit” is. Wanneer de applicatie gebruikt zal worden door EY, zal er dan ook voor gezorgd worden dat de extensie van de pagina waarnaar de malware verbindt, getoond wordt als ”.aspx”.

Hoofdstuk

3

Resultaten 3.1

Visuele Resultaten

Aangezien de meest tastbare resultaten van dit project vervat zijn in een webinterface volgen hier enkele screenshots om de applicatie te illustreren. Zoals eerder gezegd kan de welkom pagina eventueel instructies bevatten over de werking van de server. Eveneens mogelijk is om hier statistieken weer te geven in verband met de server activiteiten. Dit is echter nog niet verder uitgewerkt (en hier dus ook niet getoond).

16

HOOFDSTUK 3. RESULTATEN

17

Figuur 3.1: De overzichtspagina Er wordt op deze pagina een tabel gegenereerd met enkele eigenschappen van elke zombie, namelijk het IP-adres (zowel intern als extern), de hostname, en het tijdstip waarop de zombie geregistreerd is. In dit voorbeeld is er slechts één zombie verbonden (de test PC). De details blijven leeg totdat er een zombie is aangeduid (zoals in dit geval). Zodra de tweede tabel met alle gegevens is gevuld, kan er op de onderste knop worden geklikt.


18

Figuur 3.2: De resultatenpagina Via dit interface kan de gebruiker nieuwe commando’s doorsturen naar de zombie(s). De bovenste dropdown input bepaalt welk type commando er gestuurd zal worden. Als default instelling staat het type CMD-command aangeduid. In het tweede kader dient het commando zelf dan worden ingevoerd. Als voorbeeld staat er “ipconfig /all”. Dit kader wordt bij het verzenden van het formulier nagekeken op input. M.a.w. dit is geen optionele invoer. Het derde tekstvak is echter wel optioneel. Hierin kan de gebruiker een korte beschrijving meegeven van het commando, als geheugensteun voor zichzelf op een later tijdstip. Tot slot kan er gekozen worden welke zombies het commando moeten ontvangen. Ofwel is dit allemaal, ofwel kan er aan de rechterkant van de pagina een selectie worden gemaakt.


19

Figuur 3.3: De resultatenpagina Hier ziet men een overzicht van de commando’s die naar een zombie zijn gestuurd. In dit geval heeft de eenzaam verbonden zombie reeds twee commando’s gekregen. Het eerste is al uitgevoerd en heeft dan ook als status ”command complete”. Het tweede wacht nog om uitgevoerd te worden, zoals ook ge¨ındiceerd door de status. Door op ”View result”te klikken kan de uitvoer van het commando bekeken worden. Als het uiteindelijke resultaat dan wordt getoond is er de mogelijkheid om dit te downloaden en lokaal op te slaan.


3.2

20

Application Flow

Om de werking van de applicatie beter te begrijpen is hieronder een flowchart toegevoegd. Figuur 3.4. geeft de communicatie weer tussen server en zombie. Met andere woorden, het toont wat er achter de schermen van de valse fa¸cade pagina gebeurd. De afbeelding geeft dus de cyclus weer die de het serverscript volgt, beginnend bij het identificeren van een viewstate parameter.

Figuur 3.4: Application flow


21

Bij een nieuwe HTTP-request, wordt er als eerste de viewstate gecheckt. Om dit te kunnen doen moet deze eerst gedecodeerd worden (base64). Bij communcatie tussen server en zombie wordt een unieke serialnummer verborgen in de cookie van een HTTP-request. Via de global variable ”$ Cookie”kan deze nummer geëxtraheerd worden. Deze serialnummer is een unieke identificatiemethode voor de host waarop de malware draait. 1
Listing 3.1: Stap 1 - Viewstate & Cookie De volgende stap is om de desbetreffende nummer op te zoeken in de database. Indien de nummer niet wordt teruggevonden, weet de server dat deze nummer geregistreerd moet worden. 1 s p l i t D a t a ( $ d a t a ) ; 5 6 $status = ” registered ” ; 7 $ zombie−>i n s e r t D B ( $ s p l i t t e d D a t a , $ I P e x t , $ s e r i a l N R , $ s t a t u s ) ; 8 $ p a r a m e t e r s = ’ ’ ; 9 } 10 11 ?>

Listing 3.2: Stap 2 - Registratie In bovenstaand stuk code wordt eerst het IP adres van de zombie uit de request gehaald. Vervolgens wordt de ontvangen data opgesplitst. Dit kan omdat de informatie om te registreren steeds hetzelfde stramien volgt (zie 2.1). Eens de data is opgesplitst kan deze in de database worden geüpload. De variabele ”parameters”vertelt aan de zombie dat er momenteel niets meer te doen valt.


22

Indien het serialnummer wel wordt teruggevonden in de database, wilt dit zeggen dat de zombie reeds geregistreerd is. Op dat moment moet er gekeken worden naar de informatie bevat in de tweede parameter: de viewstategenerator. 1 giveNewCommand ( $ s e r i a l N R ) ; 11 $ commandID = ” ” ; 12 13 i f ( $newCommand == ’ 0 xFF ’ ) { 14 $ temp = ’ 0 xFF ’ ; 15 } 16 else { 17 $ temp = $newCommand [ ’ command type ’ ] . ’#’ . $newCommand [ ’ command txt ’ ] ; 18 $ commandID = $newCommand [ ’ r e s u l t i d ’ ] ; 19 } 20 21 $newCommand = base64 encode ( $ temp ) ; 22 $ p a r a m e t e r s = ’ 23 ’ ; 24 } 25 } 26 ?>

Listing 3.3: Stap 3 - Commando opvragen Wanneer de viewstategenerator een 0 geeft, wilt dit zeggen dat de zombie komt kijken of er een nieuw commando beschikbaar is. Er gebeurd dan een nieuwe opzoeking in de database. Indien de gebruiker ondertussen een commando heeft ingevoerd kan dit worden opgehaald. Het commando type en het commando zelf worden dan gecombineerd tot een geheel, geëncodeerd, en vervolgens wederom in de variabele ”parameters”geplaatst. De viewstategenerator krijgt nu de waarde van de command ID uit de database. Zo kan de malware na het uitvoeren van dit nieuwe commando, de juiste resultaten bij het bijhorende command ID plaatsen.


23

Stap 4 toont wat er gebeurt indien de viewstategenerator iets anders dan 0 is. Dit wilt zeggen dat er resultaten van een vorig commando worden teruggebracht. Deze nieuwe informatie wordt dan geüpload naar de database en de viewstategenerator wordt gereset naar 0. De viewstate parameter geeft hier opnieuw aan dat er geen actie meer moet worden ondernomen (voorlopig). 1
$ zombie−>i n s e r t R e s u l t ( $ data , $ s e r i a l N R , $ z o m b i e A c t i o n ) ; $ p a r a m e t e r s = ’ ’ ;

5 6 7 ?>

}

Listing 3.4: Stap 4 - Resultaat opslaan Deze stappen herhalen zich zolang de malware in werking is.

3.3

Problematiek

Over het algemeen is het project vlot verlopen, zonder grote obstakels. Er is wel veel opzoekwerk verricht omtrent code syntax en kleine debug problemen. Eén van de grotere issues die hierbij zijn voorgevallen is bijvoorbeeld het gebruik van backslashes in de registratie data. Deze backslashes veroorzaakten een foutmelding in MySQL en konden dus niet worden verwerkt.De oplossing hiervoor was het toevoegen van een ge¨ıntegreerde PHP functie namelijk addslahes(). Een ander probleem zat in de eerste versie van de applicatie. Deze was niet mooi gesplitst in frontend en backend. Wanneer er gekeken werd naar de frontend, kon men in de achterliggende code ook stukken terugvinden van de backend. Dit is uiteraard niet ideaal aangezien er zo duidelijk te zien is wat de werkelijke bedoeling is van de verbinding met de pagina. Dit probleem is op een simpele manier verholpen door de applicatie te splitsen in twee volledig aparte applicaties. Deze werken beide dus op hun beurt onafhankelijk van elkaar met de database.

Hoofdstuk

4

Conclusie 4.1

Algemeen Besluit

Wanneer gekeken wordt naar de vooropgestelde doelstellingen (zie 1.1.1) kunnen we concluderen dat het project succesvol is afgerond. De behaalde doelstellingen staan ter herhaling hieronder. ◦ De ge¨ınfecteerde zombie kan registreren. ◦ De gebruiker kan een commando sturen naar de geselecteerde zombie(s). ◦ De teruggestuurde resultaten kunnen worden weggeschreven naar de database. ◦ De gebruiker kan een overzicht opvragen per zombie en per commando. Als extra feature kunnen de resultaten ook gedownload worden om lokaal op te slaan. Om de acties van de malware low-profile te houden is er gebruik gemaakt van HTTP-requests als communicatiekanaal. Bovendien zorgt het gebruik van de viewstate-parameter voor discrete bij het verzenden van de data. Tot slot is de tweeledigheid van de applicatie een troef; de malware verbindt naar een onschuldig ogende pagina, waardoor het werkelijk doel verborgen blijft. De applicatie is zeker bruikbaar binnen de context van het EY red team, mits enige verdere aanpassingen.

4.2

Beperkingen

Er zijn uiteraard ook enkele aspecten die beter hadden kunnen zijn. Zo is er bijvoorbeeld geen check op de input van een nieuw commando. Dit wil zeggen dat als de gebruiker een typefout 24

HOOFDSTUK 4. CONCLUSIE

25

maakt of een ongeldig commando indient, hier geen controle op is. Dit foutief commando wordt volgens de procedure weggeschreven naar de database en aangeboden aan de desbetreffende zombie. Dit zorgt onder meer voor onnodige opvulling in de database. Bovendien wilt dit eveneens zeggen dat er extra overhead gecreëerd word in de communicatie tussen server en zombie. Het foutief commando uit de database wordt immers ook doorgegeven aan de malware, en deze gaat dat op zijn beurt proberen uitvoeren. Dus er wordt tweemaal een HTTP-request gestuurd (het foute commando en de terugkerende foutmelding) die niets opleveren. Aangezien de malware in de praktijk pas om de twintig minuten (of mogelijk langer) een nieuw commando komt opvragen is dit een verspilling van resources.

4.3

En Verder?

Twee belangrijke zaken die ik graag had willen implementeren maar die zijn overgeschoten. De applicatie is niet ontwikkeld met het oogpunt op veiligheid. Het is dus zeer vatbaar voor SQL-injectie. Hoewel de applicatie enkel intern gebruikt zal worden, zou het idealiter toch beter beveiligd moeten zijn. De communicatie tussen zombie en server is niet geëncrypteerd. Het is weliswaar base64 geëncodeerd om het in overeenstemming te brengen met de viewstate kenmerken. Dit is uiteraard echter simpel te decoderen. Als de communicatie onderschept zou worden, kan de malware dan ook zeer gemakkelijk als schadelijk worden ge¨ıdentificeerd. Met encryptie wel ge¨ımplementeerd zou niemand iets wijzer zijn.

Bijlage

A

Social Engineering Toolkit De originele stageopdracht omvatte een literatuurstudie rond social engineering met als doel een social engineering toolkit op te stellen. Hierin kwamen enkele aspecten aan bod : Succesverhalen Enkele recente ’cautionary tales’ omtrent succesvolle social engineering aanvallen; deze zijn bedoeld om potentiële klanten over de streep te trekken en EY in dienst te nemen. Methoden Er bestaan verschillende categorieën van social engineering zoals information gathering, phising, vishing, en impersonatie. Elk van deze categorieën bevat verscheidene methodes om een aanval uit te voeren. De bedoeling was om hier een overzicht van te maken met voor- en nadelen van elk type. Scenario Door verschillende methodes te bundelen kan een toolkit worden gecreërd. Een scenario specificeert de methodes geschikt voor een bepaalde situatie en werkt deze uit met voorbeelden en richtlijnen. Bijvoorbeeld een scenario om een badge-only area binnen te geraken zal andere richtlijnen hanteren dan een lost-usb scenario. Training Om het nieuwe medewerkers makkelijker te maken zich in te werken in het materiaal, werd er ook een gedeelte educatieve informatie voorzien. Hierin komt de meer theoretische grondlaag van social engineering: methodologie, fasen, ethische bedenkingen,... Psycho-sociale concepten Het idee hierbij was om vanuit een psycho-sociaal standpunt social engineering te bekijken. Zowel de slachtoffers komen aan bod : waarom lopen mensen in de val, welke type personen zijn een gemakkelijk doelwit, voor welke technieken zijn mensen het meest ontvankelijk; alsook de social engineers zelf : wat maakt een goede social engineer, welke persoonlijkheidseigenschappen dragen hier bij toe, en zijn deze eigenschappen aan te leren. Deze onderwerpen worden uitgeschreven en gebundeld. Het technisch luik dat hierbij is voorgesteld behelst het migreren van de informatie naar een database, met als interface een PHP

26

BIJLAGE A. SOCIAL ENGINEERING TOOLKIT

27

webapplicatie. Deze webapplicatie dient dan zowel als handleiding voor nieuwe medewerkers en als naslagwerk ter voorbereiding of uitvoering van projecten. De gebruiker moet niet alleen documenten kunnen raadplegen, maar ook nieuwe content kunnen uploaden. Deze opdracht is, zoals eerder vermeld (zie 1.1), niet volledig doorgegaan. Enerzijds omdat er een nieuw voorstel van een EY medewerker kwam en anderzijds omdat er weinig informatie te vinden was omtrent psycho-sociale aspecten van social engineering.

A.1

Promotiemateriaal - Placemat & Flyer

De uiteindelijke opdracht in verband met social engineering is neergekomen op het schrijven van een flyer en een placemat. Beide zullen gebruikt worden in toekomstige campagnes en zijn gelijkaardig van inhoud, de flyer is enkel iets beknopter. Inhoudelijk bevat dit materiaal argumentatie om de (potentiële) klant te overtuigen van het belang van social engineering preventie. Er worden enkele waarschuwende verhalen aangehaald, alsook de methodologie en aanpak van EY uitgelegd. Het eindresultaat hiervan is samengesteld uit reeds aanwezig materiaal binnen EY en aanvullingen uit andere bronnen zoals Kevin Mitnick’s [5] en zoekmachines van de AP hogeschool en Thomas More hogeschool. Zowel de flyer als de placemat zijn hieronder terug te vinden.

BIJLAGE A. SOCIAL ENGINEERING TOOLKIT

28

Tools of the Trade

Objectives of this service presentation ► ► ►

►

Present EY’s Social Engineering service Reflect on how this services will benefit you Allow you to dive into what we have to offer, and tailor this to your specific needs ►

The next big security breach is already present Even the most secure business can not fully cover the weakest link in their defenses: their employees. No matter how many firewalls and authentication methods you put up, it only takes one employee to get tricked into breaking protocol.

►

►

►

►

By snooping around on social media and the web in general, data can be found to serve as a starting point. For example, names of employees. Information found can also be applied to spear phishing : a phishing attack specifically tailored to an individual.

►



Information can also be gathered on site. By surveying the building, we can learn routines of employees, discover unguarded entrance, or check out the local smokers habitat. Another popular approach is dumpster diving. Companies who might throw out old templates, correspondence, or invoices, create a very easily exploited vulnerability.

►



Baiting involves an triggering an employee’s curiosity or offering a reward, and tricking them in executing an action. A good example of this is the lost USB scenario. This is a ploy that really exploits human nature. The idea is to leave several usb sticks, loaded with a malicious payload, scattered around the compound. All it takes is one curious George to insert the usb in his or her workstation to infect a whole network.

►



Physical intrusion requires the social engineer to gain physical access in the building. This can be done by attempting to obtain a badge, or trying to sneak a peak when an employee enters an access code. A very common but simple technique is tailgating; most people will be kind enough to hold the door for you.

►

►

►

“It is in people’s nature to help you, and even more so for helpdesk staff, receptionists or client-facing personnel. A social engineer uses this natural instinct against you, and often you do not even realize you have been compromised.”

Another example tells us how a major bank was conned by a malicious social engineer. The attacker found a signature of the CEO online and simply mailed transfer requests to the bank. The bank employee was tricked by the forged signature and approved the transfers, resulting in a 2.1 million dollar loss.

Marijke Vinck, Manager at EY

Protection against social engineering 

In today's information era, it is important to ensure your IT assets are protected as they often are vital components for supporting your core business. EY helps you by offering several services to help identify security threats and issues which may affect your IT environment.



We have multiple tools and techniques to engage in a social engineering attack. This means our services can be tailored to your specific needs. That scalability allows us to create a personalized approach, making sure our clients receive exactly what they require.



By not only raising awareness amongst your employees but also actively exposing them to simulated threats, you can arm them with the required knowledge to repel an actual (future) attack and thus guarantying the integrity and confidentiality of your data.



Our red team has the necessary experience and skills to implement a thorough review of your security measures and specifically the human factor. By exposing possible vulnerabilities in time, you can prevent unauthorized individuals from accessing your assets and wrecking havoc.

EY has insightful knowledge on advanced social engineering attacks, exploiting human weakness, and current attacks in the field. Our professionals execute attack and vulnerability tests that expose security flaws (partially) caused by employees. Significant track record in these domains globally and in Belgium confirms the benefits of our multi-disciplinary approach supported by a network of talented professionals

EY Framework

►

The confident CEO : By simple information gathering on social media, a hired red team discovered the CEO’s affiliation with cancer fundraisers and research. Posing as an organizer of such a fundraiser, the red team tester asked for donations and lured him by offering gift certificates to his favorite restaurant and sports game. The CEO agreed to open a PDF through mail with further information. And just like that, a top level entry point was made into his company.

In a recent engagement, the EY red team managed to obtain access to a workstation and a server hosted in the datacenter. This was accomplished by using a combination of different methods such as phishing and applying a rogue device. If this would have been executed by a hostile individual, the damage could be substantial.

Vishing is similar to phishing but is done over the phone. A talented social engineer might need nothing more than a phone call to illicit confidential information from unsuspecting employees. A typical approach here is to act as a customer service representative.

►

Information gathering can include two different types; both are aimed at obtaining knowledge to facilitate a social engineering attack

Stefano Ciminelli, Executive Director at EY

Cautionary Tales

►



Malicious attackers know this as well, resulting in 66% of cyber security attacks that target confidential information incorporating social engineering tools.

“Despite the significant amount of money spent in IT security controls by organizations, social engineering still works like a charm and it’s one of the preferred attack vectors in target attack. To address the issue you need to make your employees security aware and consider them an essential part of your information security framework.”

EY knows the industry

Phishing is one of the most widespread type of attacks. No e-mailaccount has been spared of this phenomena, also knows as “spam”. However, on a more sophisticated level this may pose a very real threat. EY has a framework at its disposal, intended to create realistic phishing mails or websites.

►

A structured approach is key to a successful battle-plan. That is why our consultants maintain a 7-step methodology as guideline in all our engagements. The first step is to create an assessment plan in collaboration with you. De core task in this phase is to establish the scope of the project and to decide which type of attack will be executed. In the research phase we focus on information gathering. We scourge social media, the company website, and any other source we can find for information. This information is often seen as trivial but may be the underlying reason for a successful attack. A more active approach is reserved for the next phase. During reconnaissance our team goes dumpster diving, wardriving, attempts portscans, telephones with your employees, or merely surveys your building. Armed with sufficient knowledge, the actual attack can commence. First order of business is trying to establish a foothold. This could include tagging along with an employee, obtaining a badge, viewing the door access code, or plugging a USB in an unguarded outlet. Once physical access is obtained, we can advance our attack by desktop snooping, installing malware, or gaining entry to a secure area like the server room. During the takeover we try to obtain certain trophies (flags), proving the attack was successful. The last step we take is to clean up after ourselves. We close any backdoors or liabilities and notify you of our findings.

A Global Service Every client has a dedicated contact person to onboard into our Social Engineering services. We always work with people in your own region and environment, as these individuals will understand you best. The service is executed centrally in one of our EMEIA Advanced Security Centers and is subject to EY’s strict quality assurance principles. $22,9 bn revenue | 150 countries | 167,000 professionals Americas EMEIA (Europe, Middle East, India and Africa) Asia-Pacific

Japan

Social Engineering Toolkit The next big security breach is already present in your business Even the most secure business can not fully cover the weakest link in their defenses: their employees. No matter how many firewalls and authentication methods you put up, it only takes one employee to get tricked into breaking protocol. Malicious attackers know this as well, resulting in 66% of cyber security attacks that target confidential information incorporating social engineering tools.

It’s easier than you think Is your social media secure? If not, the information on there can be enough to launch a successful spear-phishing attack. So goes the story of a confident CEO, hiring a team to steal his secrets. Some quick and easy research on social media gave the attacker enough personal information to launch a spear-phishing attack. Believing the e-mail to be personal, the CEO fell for it.

The EY Framework We, as a Red Team attacker, work with a structured approach as seen on the right. This 7-step methodology serves as the backbone for several different type of attacks. Phising and vishing are common tactics used by social engineers. They try to elicit confidential information from your employees either by e-mail or telephone respectively. Spear-phishing takes it to the next level by targeting a specific victim and tailoring the attack to the individual. This can be accomplished by gathering sufficient information, especially on social media. These attacks are highly successful. Information can also be gathered on site. By surveying the building, we can learn routines of employees, discover unguarded entrance, or check out the local smokers habitat. An easy method to gain physical access to the building is tailgating: most people will be kind enough to hold the door for you. Impersonation is also a valuable technique. A widely used impersonation is that of IT-guy; this is a good cover story to gain entry to IT-related areas or to ask for employee’s login information. Another popular approach is dumpster diving. Companies who might throw out old templates, correspondence, or invoices, create a very easily exploited vulnerability.

Becoming aware of social engineering attacks By raising awareness and training your employees on best practices, you can protect both them and your confidential data from falling victim to the persuasive techniques of a talented social engineer. Protecting your IT assets is critical to ensure the integrity of your data and the continuity of the business. Our EY Red Team can help assess your defenses against these specific attacks and assist in implementing improvements. We offer a wide range of services such as, but not limited to, Incident Response, Vulnerability Watch, and Information Security Transformation.

Your Belgian Contacts Stefano Ciminelli FSO ITRA Director +32 473 88 24 47 [email protected]

Marijke Vinck FSO ITRA Senior Consultant +32 499 34 95 53 [email protected]

Bibliografie

[1] Rik Ferguson. The history of the botnet – part I. http://countermeasures.trendmicro.eu/ the-history-of-the-botnet-part-i/, 2010. 4 [2] Thomas Blom Hansen and Jason Lengstorf. PHP for Absolute Beginners. Apress, 2014. [3] Dejan Marjanovic. Pdo vs. mysqli: Which should you use? http://code.tutsplus.com/ tutorials/pdo-vs-mysqli-which-should-you-use--net-24059, 2012. 9 [4] Scott Mitchell. Understanding asp.net view state. https://msdn.microsoft.com/en-us/ library/ms972976.aspx/, 2004. 15 [5] Kevin D. Mitnick and William L. Simon. The Art of Deception. John Wiley and Sons Inc, 2003. 27 [6] Brian Proffitt. How to build a botnet in 15 minutes. http://readwrite.com/2013/07/31/ how-to-build-a-botnet-in-15-minutes/, 2013.

30

Implementing a Remote Access Trojan Infrastructure

Recommend Documents

We ’ r e c o n n e c t e d !

C o n n e c t i o n f a i l e d b e c a u s e :