Paul Arends
Samenvatting
Cisco heeft al lange tijd beveiligingsdiensten geleverd voor evenementen van derden zoals de Black Hat en RSA-conferenties, evenals de Super Bowl en de Olympische Spelen. Deze diensten worden geleverd in de vorm van producten (Cisco Security Cloud-mogelijkheden, waaronder Umbrella, XDR, Malware Analytics, enz., plus Splunk Enterprise Security); en vaardige Security Operations Centre (SOC) analisten, die de infrastructuur bouwen en bedienen en bedreigingen opsporen, zowel van binnen als buiten de netwerken van het evenement.
Voor de tweede keer bij Cisco Live APJC werd het team ingeschakeld om de Cisco Live Melbourne 2024-conferentie te ondersteunen. Dit rapport dient als een samenvatting van het ontwerp, de implementatie en de werking van het netwerk, evenals enkele interessante bevindingen van vier dagen dreigingsjacht op het netwerk.
SOC Review
Het Cisco Live Security Operations Centre (SOC) heeft als taak om ervoor te zorgen dat toegang tot evenementendiensten veilig wordt geleverd. Om dit doel te bereiken, is het nodig om meerdere producten te monitoren en te communiceren om de benodigde gegevens te verkrijgen.
Het ontvangen van gegevens in verschillende vormen van het netwerk en apparaten stelt het SOC in staat om die gegevens te cureren om beter te kunnen onderscheiden wat er daadwerkelijk in de omgeving gebeurt. We hebben samengevatte informatie nodig om triage te starten, maar ook de mogelijkheid om forensisch onderzoek te doen in bepaalde gevallen.
Om de omvang van de operatie die Cisco Live APJC is beter te begrijpen, bekijk de volgende statistieken voor de 4 dagen van de conferentie:
DNS Totaal aantal vragen: 48.123.933
DNS-vragen gedempt: 4.750
Geclassificeerde toepassingen: 11.614
Risicovolle toepassingen: 300+
Binnentotaal verkeer: 320TB
Gecodeerd verkeer: 206TB
Verkeer naar buiten: 314TB
Binnen unieke hosts: 4355
Buiten unieke hosts: 58349
Bedrijfsrisicogebieden
Cisco Live-evenementomgeving:
Evenement Wi-Fi – Delegatentoegang, Personeelstoegang
Cisco TV – Belangrijke uitzendservices
NOC/SOC-operaties – Kritieke beheerdiensten
World of Solutions – Demonstratiezone
Registratie – Beheer van evenementtoegang en beveiligingspassen
Voorbereiding
“De juiste tool voor de juiste taak”
Het inrichten van de omgeving vond plaats in de week voor het evenement, maar vereiste maanden van voorbereiding. Dit omvatte de logistiek van personeelsbezetting, vloerindeling, cloudservice-opbouw, verzending van apparatuur, marketingafstemming en toerregistratie, escalatieproces met het NOC-personeel, en het opnemen van lessen uit eerdere evenementen. Niet te vergeten de dienstroosters en evenementpassen.
Personeelsbezetting
We boden veertien uur dekking in 2 ploegen, met “ogen op het scherm” van 8 uur tot 18 uur.
Er waren minstens vier stations bemand met primaire focus op TRIAGE, SANDBOX, EVENTING en SIEM/Forensica.
Alle medewerkers rouleerden door deze stoelen, met aanvullend personeel dat dreigingsjachttaken uitvoerde en automatiseringen creëerde.
Senior analisten en stagiairs deelden ervaring en kennis als ruilkaarten. We hebben allemaal van elkaar geleerd en de prettige ondersteunende omgeving bleef behouden. De omgeving diende niet alleen om de deelnemers te beschermen, maar stelde ons ook in staat om de platforms te testen en in gebruik te laten zien, feedback te verzamelen om aan de ontwikkelaars te geven en tegelijkertijd onze analistische vaardigheden te verbeteren.
Senior analistenChristian Clasen, Justin Murphy, Aditya Raghavan, Adam Kilgore, Tony Iacobelli, Jessica Oppenheimer
Stagiair analistenCam Dunn, Milin Mistry, Ricky Mok, Zoltan Karczag, Alex Chan
SOC LeidersShaun Coulter, Aditya Sankar, Ryan MacLennan
NOC LeidersFreddy Bello, Andy Phillips
SOC TOURS
Tijdens het evenement hebben we veertien SOC-tours gegeven die in totaal door 140 mensen werden bijgewoond. De tourtalk was bedoeld om het doel van het SOC op dat evenement te definiëren, hoe we werken, en enkele interessante verhalen te vertellen over wat we hadden gevonden.
Het SOC-personeel rouleerde door het geven van deze gesprekken en interessante vondsten tijdens de conferentie.
De rest van deze blog is een geschreven versie van die SOC-tourtalks, te beginnen met de opbouw en werking, de componenten en onze analistenverhalen. Veel plezier!
Opbouw en werking
We opereren een triage-tier om een samenvattend beeld te bieden met behulp van Cisco XDR en diepere forensica met Splunk Enterprise Security. Deze aanpak stelt ons in staat om snel het risico en de omvang van een incident te begrijpen, en de gegevens dieper te onderzoeken voor gevallen met een hogere complexiteit.
Met deze aanpak voert XDR effectief de taak uit om gegevens te verzamelen en in context te plaatsen, evenals het verstrekken van het juiste playbook om met het incident om te gaan zoals het er op dat moment uitziet. In de Cisco Live SOC versnelt dit het werk van Tier 1 triage.
SOC Architectuur
Cisco XDR en Splunk ES zijn geïntegreerd en ontvangen relevante gegevens van alle conferentie-infrastructuur. Specifiek zijn de volgende producten ingezet om relevante gegevens te verstrekken:
On-premise:
(De bovenstaande platforms zijn individueel beschikbaar of verpakt in Cisco Security Suites, raadpleeg de volgende links voor meer details)
De onderstaande diagram illustreert hoe de producten logisch met elkaar zijn verbonden.
Kijkend naar de afbeelding hierboven zien we de conferentienetwerkgegevens binnenkomen in het datacenter (DC) van het Network Operations Center aan de linkerkant. Het SOC krijgt de conferentiegegevens via een Nexus Data Broker.
Aan de rechterkant van het NOC DC hebben we onze cloudgebaseerde producten. Onder het NOC DC is er een groene doos met de SOC-analisten erin. Dit is niet alleen waar we zitten, maar ook waar we verbinding maken met onze interne bronnen met behulp van Secure Access. We gebruikten de Secure Access Resource Connector om verbinding te maken met interne bronnen zoals het Firewall Management Center (FMC) en Secure Network Analytics (SNA). Dit wordt verder verkend in het volgende gedeelte van de blog.
Onderaan rechts hebben we Secure Client geïnstalleerd op Windows-machines rond de conferentie om NVM- en EDR-gegevens naar XDR en Secure Endpoint te sturen. Tot slot hebben we alle producten in de oranje gestippelde doos die gegevens naar XDR sturen, samen met feeds van externe bedreigingsinformatie.
Binnen het NOC DC-gebied hebben we de Nexus Data Broker SPAN, die die feed levert aan een fysieke Secure Firewall Threat Defense (FTD) appliance. De FTD wordt beheerd met een virtueel Firewall Management Center (FMC) en is niet geconfigureerd om enig beveiligingsbeleid af te dwingen. Hieronder volgt een overzicht van wat geconfigureerd was:
Netwerkanalysebeleid
Beveiliging boven connectiviteit IPS-beleid
Bestandbeleid inclusief AMP File Reputation
Logging aan het begin en einde van verbindingen
Integratie met Umbrella voor DNS
Secure Malware Analytics voor nieuw waargenomen bestanden en URL’s
Security Analytics en Logging (SAL) integratie voor het doorsturen van gebeurtenissen naar SNA en vervolgens naar XDR en naar Splunk ES.
Hieronder volgt een diepere analyse van elk component.
Cisco Secure Access
Justin Murphy
Cisco Secure Access (CSA) is het Secure Services Edge-platform van Cisco. In de SOC zijn we voornamelijk geïnteresseerd in de mogelijkheid om toegang te bieden tot applicaties van overal naar overal.
Daartoe werd Cisco Secure Access geconfigureerd om toegang te bieden tot de on-premises platforms. Namelijk: de Splunk forwarders, de SNA, de FTD en de Telemetry Brokers.
De afbeeldingen tonen de geconfigureerde bronnen die werden benaderd met CSA, met redundante connectorgroepen of hoofd einden, en de statistieken van de toegangen tot elk van de bronnen.
Cisco Secure Network Analytics
Cisco Secure Network Analytics (voorheen bekend als Stealthwatch Enterprise) biedt volledig zicht over het conferentienetwerk en maakt gebruik van geavanceerde analyses om bedreigingen in realtime te detecteren en erop te reageren. Deze bedreigingen omvatten commando- en controleaanvallen, gedistribueerde denial-of-service (DDoS) aanvallen, onbekende malware en interne bedreigingen.
Secure Network Analytics is geïntegreerd met Cisco XDR, kritieke en belangrijke beveiligingsalarmen worden verzonden vanuit de Security Services Exchange en geanalyseerd door het huidige platform om onderzoeken te ondersteunen. Deze alarmen worden omgezet in incidenten, compleet met details zoals waarnemingen, observaties en indicatoren op basis van de alarmmetadata.
Tijdens een onderzoek levert Secure Network Analytics voor elk geldig IP-adres aangevraagd:
Een lijst met bijbehorende beveiligingsgebeurtenissen van de afgelopen 30 dagen, de meest recente 100 beveiligingsgebeurtenissen, en gebeurtenissen waarbij het IP-adres betrokken was als bron of bestemming.
Naast standaardvelden in NetFlow/IPFIX-records bevat de Secure Network Analytics FlowSensor ook aanvullende metadata van deep packet inspection (DPI) voor nauwkeurige identificatie van toepassingen op laag 7, netwerk- en serverresponstijdmeters, evenals beperkte pakketpayload-informatie (inclusief maximaal 256 bytes aan HTTP- en HTTPS-verzoekpaden), die wordt gebruikt zoals vereist voor forensisch onderzoek.
Cisco XDR
Cisco XDR is een op de cloud gebaseerde oplossing die is ontworpen om beveiligingsactiviteiten te vereenvoudigen en beveiligingsteams in staat te stellen geavanceerde bedreigingen te detecteren, prioriteren en erop te reageren. In de Cisco Live SOC wordt XDR gebruikt als triageplatform. XDR ontvangt telemetrie van alle integraties en voert een gebeurtenisaggregatie en correlatie uit om een incidentenbundel te produceren. Dit is een andere benadering dan een SIEM, aangezien het zoeken, risicoanalyse en verzameling van voldoende gegevens om het risico te bepalen een out-of-the-box operatie is. Men zou kunnen zeggen dat het meer een plug-and-play benadering is. Aanpassing is mogelijk, maar niet in die mate als ons Splunk-platform toelaat. We gebruiken XDR voor triage en Splunk ES voor escalatie. Dit werkt buitengewoon goed en we kunnen stagiairs snel opleiden om operationeel te zijn, terwijl senior analisten zich kunnen concentreren op proces- en automatiseringsverbeteringen en escalaties. Dit is “het juiste gereedschap voor de klus” in actie.
Voor de Cisco Live APJC 2024 SOC werd een aangepast dashboard in het Control Center gebouwd om de bevindingen van de verschillende geïntegreerde oplossingen te benadrukken.
Hieronder volgen de plug-and-play-integraties die zijn geconfigureerd in XDR:
Splunk
Onze Splunk-stack bestond uit Splunk Cloud en Splunk Attack Analyzer. Splunk Cloud had Splunk Enterprise Security (ES) en de Cisco Security Cloud-apps geïnstalleerd. Aangezien onze beveiligingstools on-premises apparaten omvatten zoals het Firewall Management Center en de Secure Network Analytics Manager, moesten we in staat zijn om de gegevens van on-premises naar de cloud te krijgen. De oplossing was om een UCS M3-server op te zetten die we ter plaatse hadden. Zodra we de server online hadden, implementeerden we een kleine Ubuntu virtuele machine en installeerden Splunk erop.
De Cisco Security Cloud-app, die is gepubliceerd in de Splunk base app store, is een enkele app om gegevens van Cisco Security-tools in Splunk te krijgen. De app is modulair, dus individuele producten kunnen geconfigureerd worden om gegevens in te nemen in Splunk, waaronder Secure Malware Analytics, Firewall, Secure Network Analytics, Cisco XDR en meer. De app bevat een vooraf geconfigureerd dashboard voor elk product en gezondheidsmonitoring van de app om te zien hoeveel gegevens worden ingenomen. Wanneer gegevens worden ingenomen, transformeert de app de gegevens naar een Common Information Model (CIM), wat het universele schema van Splunk is voor het indexeren van gegevens. Dit stelt ons in staat visualisaties te maken over meerdere gegevenssets of te zoeken naar een enkel veld over meerdere telemetrietypes.
Met de Cisco Security Cloud-app geconfigureerd om gegevens van onze verschillende bronnen in te nemen, installeerden we vervolgens de universele forwarder-app om verbinding te maken met de Splunk-cloudimplementatie. De universele forwarder was uiterst prestatief en kon gigabytes aan gegevens naar Splunk-cloud doorsturen zonder ooit meer dan 30% CPU te overschrijden of een redelijke vertragings van inname. Dit stelde ons als SOC-analisten in staat om gegevens te doorzoeken in Splunk Cloud, waar we ook Enterprise Security hadden geïnstalleerd. Incidenten van XDR werden automatisch ingevuld als notities in Splunk ES.
Secure Firewall Threat Defense
De Cisco Secure Firewall (CSF) implementatie bij Cisco Live Melbourne is een IDS-implementatie die een TAP ontvangt van de bestaande netwerk- en beveiligingsinfrastructuur die wordt gebruikt door de conferentie. CSF fungeert als het verkeersinnamepunt voor de andere beveiligingstools die onze SOC gebruikt, waardevolle gegevens verzamelt en logs en gebeurtenissen genereert die worden gebruikt om producten zoals Cisco Splunk en Cisco XDR te informeren. CSF haalde ook bestanden rechtstreeks uit onversleutelde sessies, die werden ingediend bij Secure Malware Analytics voor sandbox-analyse.
Werken in passieve IDS-modus heeft zichtbaarheidsnadelen, aangezien we de mogelijkheid verliezen om TLS Server Identity te gebruiken om aanvullende informatie van HTTPS-verbindingen op te halen, en algemene decryptie van tafel is. De firewall biedt echter nog steeds kernwaarschuwingsmogelijkheden, en de tientallen gegevenspunten die worden vastgelegd voor elke verbinding bleken cruciaal in veel onderzoeken, vooral in de ‘Verkeer zeven met Secure Firewall’ en ‘Malware-oproepen vanaf de beursvloer’ secties.
Vanuit een geolocatieperspectief toonden de deelnemers van Cisco Live een sterke voorkeur voor verbindingen terug naar de VS, die alle andere verbestemmelingen overtroffen.
Het thuisland Australië liet ook een sterke vertegenwoordiging zien met twaalf miljoen verbindingen. Geen enkel ander land haalde een miljoen verbindingen, maar de rest van de lijst toonde een voorspelbare voorkeur voor regionale en wereldwijde technologiehotspots. De voorspelbaarheid van de geolocatievoorkeuren van de deelnemers stelde ons in staat om een nauwere blik te werpen op zeldzamere inkomende en uitgaande geolocatieverbindingen, wat ons hielp bij het uitbreiden van meerdere onderzoeken terwijl we zochten naar aanvullende activiteit na het vinden van een gebeurtenis. Natuurlijk kunnen geolocatiegegevens voor kwaadaardige activiteiten worden vervalst met behulp van Tor, VPN of een gecompromitteerde host in een ander land, maar verkeer dat past bij verwachte geolocatiepatronen wordt nog steeds onderworpen aan handtekening-, heuristische en sandbox-analyse. Geolocatie blijft een van de vele kenmerken die aanvalspatronen kunnen onthullen.
Applicatiegegevens zijn een ander gebied dat we op een breed niveau monitoren, naast individuele waarschuwingen voor kwaadaardige domeinen. We blijven plaintext-aanvallen en plaintext-informatielekken zien op elk evenement, maar de frequentie hiervan is geleidelijk afgenomen. Tijdens Cisco Live Melbourne 2024 zagen we een voorkeur van 15:1 voor HTTPS boven HTTP. HTTP/3 blijft ook aan populariteit winnen.
Ook het gebruik van DNS over HTTPS om DNS-verzoeken te maskeren is het vermelden waard. Hoewel het overgrote deel van de DNS-verzoeken plaintext blijft, blijft het gebruik van DNS over HTTPS toenemen. Uiteindelijk verwachten we dat plaintext DNS-verzoeken worden overschaduwd door versleutelde DNS-protocollen, net zoals HTTP vandaag wordt overschaduwd door HTTPS.
Automatiseringen
Op het gebied van automatisering hebben we drie nieuwe automatiseringsworkflows geïntroduceerd om het dreigingsonderzoek voor onze analisten te versnellen. Credits aan Ivan Berlinson, onze collega uit Frankrijk, voor de eerste twee workflows in XDR-automatisering met Secure Malware Analytics, en Adi Sankar voor de workflow met Umbrella.
1. Kwaadaardige monsters ingediend in Secure Malware Analytics
We willen het aantal dashboards waar onze analisten mee te maken krijgen verminderen. Dus, voor monsters die zijn ingediend bij Secure Malware Analytics en veroordeeld als kwaadaardig (dreigingsscore > 90) en gezien in de Cisco Live-omgeving, zou deze automatiseringsworkflow automatisch een incident creëren in XDR en een Webex-bericht sturen naar het Incidenten-kanaal.
2. Niet-kwaadaardige monsters van veelvoorkomende documentindelingen
Op soortgelijke wijze zien we typisch enkele content in platte tekst die wordt verzonden op dergelijke evenementen. Elk document met veelvoorkomende bestandstypen dat is ingediend bij Secure Malware Analytics en een niet-kwaadaardig oordeel heeft (dreigingsscore < 85), gezien in de Cisco Live-omgeving en van de volgende typen, heeft meestal content in platte tekst. Dit is de moeite waard voor een onderzoek voor onze analisten om te identificeren of er per ongeluk kritieke informatie wordt gelekt.
3. Incidenten creëren vanuit Umbrella Security Events
Elk DNS Security Event in Umbrella voor bepaalde categorieën van interesse zou aan de analist worden voorgelegd als een incident per categorie. Dit toont een voorbeeld van een geautomatiseerd incident voor de Malware-categorie. Een beperking die we tegenkwamen in de Cisco Live SOC was het gebrek aan integratie van de Umbrella Virtual Appliance (VA), wat resulteerde in een blinde vlek in onze zichtbaarheid van client-side IP’s. Met enige kennis van de werking van Umbrella konden analisten kwaadaardige of verdachte DNS-query’s toeschrijven aan client IP-adressen op de openbare Wi-Fi, ondanks het ontbreken van VAs.
Umbrella is een recursieve DNS-oplosser die gebruik maakt van de kracht van de wereldwijde DNS om beveiliging en acceptabel gebruik af te dwingen. De openbare IP-adressen die worden gebruikt op de conferentie zijn geregistreerd bij een Umbrella-organisatie, zodat DNS-query’s kunnen worden toegeschreven en behandeld volgens de juiste beleidsregels. Vanwege NAT worden alle IPv4-query’s toegeschreven aan het openbare adres dat alle deelnemers bedient. In een optimale Umbrella-implementatie zouden interne recursieve resolvers (VAs) worden geïnstalleerd en deze zouden interne IPv4-toewijzing bieden. Helaas boden de interne resolvers die op de conferentie werden gebruikt deze functionaliteit niet, dus gaven Umbrella-alerts alleen openbare IP-adrestoewijzing.
De voor de hand liggende oplossing hiervoor zou zijn om de logs van de interne recursieve resolver in te voeren in onze SIEM- en SOAR-infrastructuur. Dit was gepland en werd actief aan gewerkt, maar was niet direct beschikbaar in de vroegste delen van de conferentie. Dus hoe overbrug je deze kloof en zorg je ervoor dat de meest specifieke informatie beschikbaar is voor deze gebeurtenissen? Het antwoord is eenvoudig als je weet hoe Umbrella werkt.
Met deze informatie zijn er twee strategieën om de Umbrella DNS-gebeurtenissen te correleren met Firewall-gebeurtenissen. Door de Firewall-verbindingen te filteren op het bestemmings-IP-adres dat is geassocieerd met Umbrella Malware-blokkades (146.112.61[.]107), kunnen we eventuele verbindingen vinden die de cliënt vervolgens heeft gemaakt na het oplossen van het kwaadaardige domein. Als de verbinding wordt geprobeerd via HTTP of HTTPS, kunnen we waarschijnlijk de hostnaam zien in de HOST-header of Server Name Indication (SNI) extensieveld. Dit komt omdat de client nog steeds denkt dat hij verbinding maakt met de bedoelde malwareserver, en niet met Umbrella.
Voor niet-webverkeer kunnen we eenvoudig de tijdstempel in de Umbrella-gebeurtenis correleren met de IP-verbinding in de firewall-gebeurtenissen om met vertrouwen te bepalen dat het specifieke interne cliënt-IP-adres de bron was van de kwaadaardige of verdachte DNS-query. Van daaruit kan geolocatie-informatie van de draadloze infrastructuur ons helpen bij het opsporen van apparaten en personen wanneer de inhoud van de waarschuwing dit rechtvaardigt. Onderzoek van het incident bevestigde dat de NOC een poortscan heeft geïnitieerd vanaf een intern IP-adres naar de WAN-link.
Een andere Cisco Live positief.
Verdachte gebruikersagent op
Christian Clasen, Zoltan Karczag, Cam Dunn, Ricky Mok.
Meerdere incidenten gezien in XDR van verdachte gebruikersagent voor verschillende IP-adressen in het interne IP-adresbereik van het Cisco Live-evenement.
Het onderzoek toont aan dat dit te wijten is aan een (waarschijnlijk Android) applicatie met een slechte implementatie van de OkHTTP-clientbibliotheek. De ontwikkelaars van de app stellen of roepen de “project.version” variabele niet goed op in hun app.
Het is zeer waarschijnlijk iets dat draait op dit e-commerce platform.
De serverzijde implementeert Octopus.
Onderzoek via Secure Malware Analytics toont het volgende:
Via XDR Investigate:
We hebben de prioriteit in Network Analytics verlaagd voor de verdachte gebruikersagent om het aantal waarschuwingen in XDR voor de gedetecteerde valide onschuldige gebruikersagenten te verminderen.
Verder verfijning kan worden uitgevoerd door de specifiek waargenomen gebruikersagent te blokkeren/filteren.
Verdachte phishing domein.
Adam Kilgore, Zoltan Karczag, Tony Iacobelli.
Cisco XDR waarschuwde voor een mogelijk phishingdomein dat werd waargenomen door een host op het netwerk.
De SOC gebruikte Splunk Attack Analyzer om te communiceren en de website op een veilige manier te analyseren, de analyse resulteerde in een “404 pagina niet gevonden” site toen de URL werd beoordeeld.
Door verder onderzoek konden we valideren dat het top-level domein en het bijbehorende openbare IP-adres eigendom waren van “knowbe4”, een beveiligingsbedrijf dat gespecialiseerd is in phishing-simulatie en training.
Op basis hiervan hebben we potentiële Cisco Live-deelnemers geïdentificeerd die zojuist hun phishingbeoordeling van hun organisatie hebben gefaald.
Verkeer filteren met Secure Firewall.
Adam Kilgore.
Veel moderne analytische werkzaamheden worden aangestuurd door automatisering, en terecht – het Melbourne SOC heeft enorm geprofiteerd van de geavanceerde correlatie die wordt geboden door de Cisco Splunk en Cisco XDR platforms. De enorme hoeveelheid data die wordt waargenomen en verzameld door Cisco Secure Firewall is essentieel om deze geavanceerde analytische platforms te voeden. Bovendien is de data op zichzelf ook waardevol, en ik ben persoonlijk een voorstander van het controleren van datasets op het onverwachte.
We kunnen onverwacht verkeer controleren door aannames te testen. Een aanname die we zouden kunnen maken is dat verkeer op poort 443 HTTPS zal zijn. Secure Firewall biedt de logboekregistratie, applicatie-detectie en zoeknauwkeurigheid om te verifiëren, met behulp van een zoekopdracht zoals de onderstaande:
Als de query niets oplevert, hebben we onze hypothese bewezen – al het verkeer op poort 443 in onze logs is HTTPS. Maar als de query logs oplevert, hebben we mogelijk iets interessants om nader te onderzoeken, en in ieder geval iets dat we willen begrijpen. Voor Melbourne Cisco Live gaf onze zoekopdracht enkele logs terug:
We kunnen zien dat er HTTP-verkeer loopt over poort 443. Dat is niet verwacht, dus het is de moeite waard om er wat dieper op in te gaan om te zien waarom dit gebeurt en of er een beveiligingsprobleem is. Aangezien het verkeer het HTTP-protocol is, kunnen we het URL-veld in de logs controleren.
De URL’s hierboven geven een bestemmings-IP en poort 443 aan, maar sommige voegen ook een pad toe. Met name “./env.” Als dit verkeerd is geconfigureerd, kan het “./env” pad op een server gevoelige informatie onthullen die kan leiden tot het compromitteren van de server en dienen als een ingangspunt voor een serieuzere aanval. Door een grote subset van verwacht verkeer te verkleinen (HTTPS over poort 443) hebben we een veel kleinere subset van onverwacht verkeer geïsoleerd (HTTP over poort 443) dat ook een hoog concentratie van kwaadaardige activiteit heeft.
Er zijn twee dingen die we met deze data kunnen doen: (1) zoeken naar andere kwaadaardige activiteiten van dezelfde actoren, en (2) bevestigen of de “./env” verzoeken met succes gevoelige informatie van de servers hebben opgehaald. Voor (1) is een eenvoudige methode om te zoeken naar andere activiteiten van dezelfde IP-adressen, maar dit is beperkt omdat een aanvaller zijn IP-adres kan wijzigen met behulp van Tor, een VPN of een gecompromitteerde host die fungeert als een jumpserver van waaruit aanvallen worden gelanceerd. Echter, zelfs als de aanvaller zijn IP-adres verandert, kunnen we soms nog steeds een aanval koppelen aan een individuele acteur door een unieke of semi-unieke identifier te verzamelen van een bekende aanval (zoals een gebruikersagent) en vervolgens te controleren of dezelfde identifier voorkomt in verkeer van andere IP-adressen. Voor (2) kunnen we eenvoudig bepalen of de aanval succesvol was door te kijken naar de pakketten in de serverrespons, maar deze zullen niet beschikbaar zijn tenzij we een pakketopname uitvoerden toen de aanval plaatsvond, of als we een datameer hebben dat de verbinding heeft vastgelegd.
Als we niet de luxe hebben van een pakketopname, kunnen we nog steeds bepalen of de aanval succesvol was door de firewall logs te gebruiken. Als we onze firewall log zoekopdracht uitbreiden om de kolommen met pakketten en bytes op te nemen, kunnen we nog meer te weten komen over de aanval en welke data werd geretourneerd.
Met behulp van de pakketvelden kunnen we zien dat de meeste verbindingen zeven Initiator-pakketten hebben. Voor HTTP zullen de pakketten van het initiator-IP-adres een SYN zijn voor het eerste pakket, een SYN/ACK voor het tweede pakket, en vervolgens een GET-verzoek in het derde pakket. Dit derde pakket is de URL die we zien in de bovenstaande logs, die probeert de “env” data op te halen in sommige van de verzoeken. Op dezelfde manier kunnen we in de kolom met Responder-pakketten een ACK verwachten voor het eerste pakket, en vervolgens een reactie op het GET-verzoek dat wat voor informatie dan ook teruggeeft in het tweede pakket. Onze zorg is dat de informatie die wordt geretourneerd voor de “env” verzoeken verschilt van de gegevens die worden geretourneerd van het niet-kwaadaardige GET-verzoek aan de server, en of die respons gevoelige informatie bevat. Kunnen we bepalen of dit gebeurt alleen op basis van de logs? Dat kunnen we, door naar de bytes te kijken. Voor alle verzoeken hierboven zien we dat de reactie bestaat uit vijf pakketten, en dat de Responder Bytes altijd 346 bytes zijn. Dit vertelt ons dat de server dezelfde respons retourneert voor elk van de verzoeken, of iets zeer vergelijkbaars, voor elk van de verzoeken in de logs, waarvan sommige proberen toegang te krijgen tot “env” en sommige niet. Als de server wel servergegevens zou retourneren voor het verzoek naar “./env”, zouden we een variatie in de Responder Bytes verwachten.
Onbeveiligde Transmissies
Jessica Oppenheimer
Bij elk evenement is het gebruikelijk om documenten te zien met zakelijke gegevens, financiële gegevens of persoonlijk identificeerbare informatie. Indien mogelijk, sporen we de personen op die getroffen zijn door de onbedoelde openbaarmaking via het netwerk en helpen hen om hun communicatie te beveiligen. Vaak gaat het om een onbeveiligd e-mailprotocol of open netwerkverbinding, zoals http via poort 80 in plaats van https.
Een conferentie is een geweldige plek voor veilig netwerken. We zagen dat er een cv werd geopend en geactiveerd in Secure Malware Analytics. Uit onderzoek bleek dat de server de gegevens niet over een versleutelde verbinding verzond.
In een ander geval werden zakelijke gegevens onversleuteld verzonden, opnieuw via een webverbinding over http.
Zoek naar het beveiligde verbindingspictogram in uw browser en controleer uw e-mailinstellingen om ervoor te zorgen dat POP3 of IMAP niet per ongeluk zijn geselecteerd.
We hebben ook de Glovebox-functie in Secure Malware Analytics gebruikt om websites te onderzoeken waar conferentiedeelnemers verbinding mee probeerden te maken, zoals dit in beslag genomen domein door de wetshandhaving.
We konden het gedrag van websites verkennen (zoals het neerzetten van kwaadaardige JavaScript-bestanden) zonder dat onze analisten besmet raakten.
Daarnaast kunnen de analisten de Runtime Video bekijken om de gebruikerservaring te begrijpen.
Umbrella DNS-verzoek in de categorie Malware
Adam Kilgore, Zoltan Karczag, Ricky Mok
XDR-automatisering via Umbrella-verbinding Geïdentificeerd aantal kwaadaardige domeinen waarmee een intern host op het IPv6-netwerk sinds 11 november 2024 verbinding heeft gemaakt. Het waargenomen gedrag blijft actief op 12 november 2024.
Bewijsmateriaal vastgelegd op XDR dat de kwaadaardige domeinen en hashwaarden vermeldt.
Verdachte oproepen vanaf de beursvloer
Adam Kilgore en Christian Clasen
We hebben enkele DNS-verzoeken opgepikt naar een domein dat eerder in verband werd gebracht met een Iraanse APT en meerdere soorten malware.
Een DNS-verzoek is slechts één IoC in een onderzoek. Bij een volledige implementatie in een bedrijf zouden we willen uitzoeken welke toepassing het verzoek heeft gedaan, wanneer deze is geïnstalleerd, en of er een legitiem voorbeeld van gebruikersactiviteit is dat het DNS-verzoek kan verklaren en bevestigen dat het niet gerelateerd is aan malware. Aangezien we geen middelen hebben voor eindpuntbeveiliging voor gast-WiFi-verbindingen, en gezien de mogelijke ernst, besloten we te kijken of we het eindgebruikersapparaat konden identificeren en hen op de hoogte konden stellen van het mogelijke compromis.
Echter, ons gebrek aan eindpuntcontrole maakt identificatie ook moeilijk. De gast-WiFi-verbinding wordt gratis verstrekt, zonder individuele aanmeldingsgegevens of MFA te vereisen. Waar we normaal gesproken terug zouden kunnen vallen op authenticatielogs van services zoals Active Directory en ISE, moesten we in het Melbourne SOC het IP koppelen aan een identiteit puur op basis van netwerkactiviteit. Is dat mogelijk? In dit geval was het mogelijk met behulp van logs van Secure Firewall.
We vertrouwen veel op de beveiliging van applicaties en cloudservices. Hoewel de versleuteling van deze services meestal goed geconfigureerd is, kunnen ze nog steeds behoorlijk wat identificerende informatie delen in dezelfde versleutelde sessies. In het bovenstaande voorbeeld onthulden zowel een organisatie-app als een organisatie-SharePoint-instantie een specifieke leverancier. En hoewel we het hier niet hebben gezien, zullen andere applicaties zoals Slack ook de kamer onthullen waarmee een gebruiker verbinding maakt in een versleutelde sessie. Is dat een probleem? Ja en nee. De inhoud van de verbindingen is versleuteld en beveiligd, maar iemand met verkeerssniffende mogelijkheden (zoals wij via onze TAP in het SOC) kan nog steeds die beveiligde verbinding gebruiken om verkeer terug te koppelen naar een organisatie, een individu of een uitvoerende rol. Een kwaadwillende acteur zou dan de geïdentificeerde organisatie, groep of leidinggevende kunnen targeten via hun nu bekende IP. Of in ons geval kunnen we de gegevenspunten van de mogelijke malware-oproep, de bedrijfsapplicatie en de bedrijfs-SharePoint gebruiken om iemand op de hoogte te stellen dat hun apparaat mogelijk gecompromitteerd is.
Dus, we hebben nu een IP en een leveranciersnaam. Tijd om de beursvloer op te gaan. We vonden de stand van de leverancier en vroegen hen te bevestigen of een van hun apparaten het IP had dat het DNS-verzoek had gedaan – een ipconfig bevestigde dat ze dat deden, wat niet verwonderlijk was gezien de verbindingen met de SharePoint en bedrijfsapp. We hebben hen op de hoogte gebracht van de DNS-verzoeken die het onderzoek startten en aanbevolen dat ze het apparaat en de bijbehorende accounts behandelen als mogelijk gecompromitteerd.
Speciale dank
Dankbetuigingen Dank aan het Cisco/Splunk SOC-team:
Senior Analisten Christian Clasen, Justin Murphy, Aditya Raghavan, Adam Kilgore, Tony Iacobelli, Jessica Oppenheimer
Stagiaire Analisten Cam Dunn, Milin Mistry, Ricky Mok, Zoltan Karczag, Alex Chan
SOC Leiders Shaun Coulter, Aditya Sankar, Ryan MacLennan
NOC Leiders Freddy Bello, Andy Phillips, Darren Nirens
Cisco Marketing Vanessa Carlson!! Lauren Frederick, Trish Stallone
Ook aan onze SOC-partners voor de licenties
Integraties van derden APIVoid AlienVault OTX Cyber Crime Tracker Google Safe Browsing IBM X-Force Exchange Pulse Dive Recorded Future Shodan Virus Total Alpha Mountain Threat Intelligence
We horen graag wat je ervan vindt. Stel een vraag, plaats een opmerking en blijf verbonden met Cisco Secure op sociale media!
Cisco Security Social Channels
Instagram Facebook Twitter LinkedIn
Deel: Niet uitvinden. Schrijf niet in een andere taal. Praat niet over de auteur van de inhoud. Focus op de inhoud, niet op andere pagina’s, zoals privacybeleid, cookiebeleid of andere. Wees grondig bij het herschrijven: minstens 300 woorden. Vertaal ook geen merken, producten of bedrijfsnamen.
BRON
