Networkforensic

Password Attacks - IOT BotNet

 14 Oktober 2023  - Blog Post # 857

IOT-BotNet
Siden 10 December 2021 - Blog Post # 805 har jeg skrevet om det samme BotNet der hele tiden foretager password attacks imod systemer. Dette er fra hacket IOT-Enheder rundt om i verden. Det unikke har hele tiden været at det har man kunne identificer med samme unikke JA3 hash. For et stykke tid siden bemærker jeg at der nu opstår JA3 clash på nogen Symantec domæner.




Dette skyldes at Symantec ny benytter en certifikat der er oprettet 1 September 2023 i deres certificate chain.
Dette er oprettet imod domænet colossus-clt[.]symantec[.]com som peger på en googel IP 35.190.72.88. Det betyder at der nu er JA3 Clash på den ellers unikke JA3 hash.

Certifikat Serie nummer:
0edd7e5b43d0ecff40607aff60c7ca64

Enten har Symantech en finger med i spillet her eller også er det begyndt at jagte samme IOT-BotNET. Ikke destro mindre, har jeg tilrettet IDS regler til både SNORT og Suricata således at falske positiver ikke opstår. Yderligere er der sket en ændring i angrebsmønsteret, da jeg nu ser at den kendte JA3 hash altid angriber på samme tid som 2 nye identificeret JA3 Hashes der igen er meget unikke. Angreb sker altid samtidigt og med "Low and Slow" som skifter IP adresse meget hurtigt. Valideringer af IP-Adresser er forholdsvis stadig nem, da man kan validerre porte mm på hver enket ip adresse der angriber, eller ty til honypot og andre former for logs, eller så simpelt som at benytte Virustotal imod hver enkelt ip. Generalt er det altid det samme møsnster der går igen.

De fleste opdager ikke denne type angreb, da det kræver grundig gennemgang af logs fra systemer med åbne servise imod Internettet. Resultatet set fra angriberens side er at de for det meste får lov til at foretage mange password gæt uden at blive opdaget.

IOC'er - Pt kendte Hashes fra samme angreb.
f17ca639ecdcaa65b4521c49e3515ef9
d6828e30ab66774a91a96ae93be4ae4c
166378e4eba1fdb7097714802fb4ef94

Certifikat Serie nummer: (Skal Excludes)
0edd7e5b43d0ecff40607aff60c7ca64

Suricata rules er opdateret
"BIMP-BotNet rules"

Happy hunting... 

MQTT -  Message Queuing Telemetry Transport

 10 September 2023  - Blog Post # 856

MQTT - Command and Control
MQTT er en protocol som benyttes mere og mere af forskellige IOT enheder. Det bruges ofte i forbindelse med kontrol af mange forskellige hardware dimser.Det kan eks være græsslåmaskiner som de små robotplæneklipperer vi kender fra eks private haver, eller centralanlæg i bygninger. Det kan også være kraftvarme værker  og meget meget mere.



C&C
Det også set i forbindelse med APT-Mustang Panda som benytter dette til C&C. Det er nok et protokol man skal have lidt mere fokus på, og især at få trafikken sikret og allerhelst pakket ind i noget VPN og fjernet åbne service porte der har direkte adgang til Internettet.



Sårbarheder
Antallet af sårbarheder der er rettet imod netop MQTT lader også til at stige en del. Jeg kender til 79 forskellige former for harware der er berørt af en eller anden form for sårbarhed. Typisk RCE til DDOS / DOS. Router udstyr, Firewall udstyr mm. er allerede berørt af dette. Der er sågar muligheder for at injecte pakker i packet streams, eller injecte pakker på krypteret MQTT. Så implementeringer og speks af protokollen vil jeg ikke just kalde for noget der er gennemprøvet eller færdigt. Ikke destro mindre ser vi det efterhånden brugt hver dag. Dog er det mest benyttet version lige nu 3.1.x.  Jeg er endnu ikke stødt på nogen version 5.x derude. Jeg ville nok anbefale at virksomheder allerede nu begynder at kigge på udstyr der bruger protokollen og allerede nu sikre dette med eks VPN tunnels, Krypteret brug osv...

Analyse af protokollen
Analyse af protokollen må også siges at have været en af de mere besværlige protokoller at foretage analyse på, da der kun finde meget begrænset information på denne derude. Dog er den meget interesseant, da den er meget overset, men bruges i stigende grad. Den største opgave har også været at få samlet nok information om attack metodikker imod denne. IDS signaturer til MQTT findes slet ikke derude. Det var ikke nogen nem opgave at finde pcaps med attacks imod MQTT frem.Det i høj grad krævet packet crafting. Har da også måtte ty til lidt hjælp igennem mit netværk hos IEEE.

Noget man skal være vågen overfor er at man typisk vil se en "fleet" af dimser kontrolleret via eks mobil telefoner. Det kan gøre det lidt mere besværligt at kontollere i en virksomhed for selvom dimsen er kontrolleret via en mobil telefon så er dimsen stadig opsat på det indterne netværk.

Hvem ville nogen sinde opdage at ens plæneklipper / robotstøvsuger deltager i et ondsindet Botnet :-) Ikke destro mindre kan jeg ikke gennemskue alle de steder nogen kunne finde på at bruge denne protokol og det kommer også an på hvor man opsætter IOT enheder med MQTT implementeret. Som beskrevet er det alverdens steder og derfor bør man selv lige undersøge hvor meget man har kørende på sit net.

Jeg har desuden frigivet en Wireshark profile, der kan hjælpe en del med analyse af MQTT.
https://networkforensic.dk/Tools/default.html

IDS rule frigivet / Identificering
For at man kan identificere om man overhovedet benytter MQTT på sit netværk , har jeg frigivet nogen forskellige IDS sigs. De kan bla finde Mustang Panda C&C brugen af MQTT ukypteret (Bør man især ikke benytte) Eller bruteforce attacks imod brokers, kan jeg også finde.

Typisk porte brugt er TCP 1883 og for krypteret brug, er det TCP 8883

Happy hunting... 

Password attacks fra IOT-BotNet 

 01 Juli 2023  - Blog Post # 855

Passwords attacks
I 2022 Blog Post # 816 skrev jeg om et IOT-Botnet der foretager distribueret password attacks. Disse stammer fra mange forskellige komprimiteret IOT enheder fra hele verden (Også Danmark) Det er stadig en ting der bliver foretaget imod bla. mail systemer. Dengang breskrev jeg en JA3 Hash. Denne er stadig den samme og ikke noget man ser andre steder.  Jeg frigav også Snort IDS signaturer til at opdage dette. Disse har dog en begrænset effekt såfremt man ikke sidder inline med sit IDS system, da det typisk vil køre i Alert mode og ikke i Drop mode. Dog kan man eks bruge content og porte mm til eks Zyxell firewall IDS engine.



Man kan forhinder disse angreb med eks GeoIP filteres hvis man ser dette, og er forholdvis nemt at begrænse i omfang, men der vil stadig være lande man sikkert ikke kan få dækket, grundet forskellige nødvendigheder for at tillade trafik fra nogen lande.

Frigivet liste med IP-adresser der angriber
Jeg frigiver desuden en liste over 917 IP adresser jeg over et stykke tid har set angribe. Alle er en eller anden form for komprimiteret IOT-enhed. Download liste Den danske IP adresse kan man tjekke på Virustotal her

Frigivet et Suricata IDS rule set.
Jeg har nu frigivet et Suricata IDS ruleset jeg fremover kommer til at bygge videre på, således at IDS regler der passer på Suricata og den syntax der benyttes der.  Det giver bla også muligeder for at starte med at blokerer på JA3 hashes, da Suricata kan dette. Det er perfekt hvis man sidder i inline mode.



Netgate
Benytter man eks Netgate firewall med Suricata installeret er det lige til at smide dette ind i sine coustom.rules og herefter sætte IDS regler i Drop mode. 

Enable JA3 på Netgate
Man skal dog lige sikre sig at JA3 er sat som enabled. Gøres på følgende måde i Netgate.
Wan App Parseres -> TLS App-Layer Parser Settings -> JA3/JA3S Fingerprint (Suricata will generate JA3/JA3S fingerprint from client hello. Default is Not Checked, which disables fingerprinting unless required by the rules.)

IDS rule frigivet
Der ligger en frigivet IDS rule som passer på det IOT-botnet der foretager password attacks med tilhørende unikke JA3

Trojan Formbook

 28 Juni 2023  - Blog Post # 854

Trojan Formbook
Velkendt Trojan med masser af genkendelse. Dog køre der hver dag nye kampanger. På baggrund af Brand's kampange fra Malware-Traffic som publicerer information om nye kampanger hver dag for tiden, har jeg på baggrund af disse lavet generisk IDS genkendelse der med en flowbit rule som genkender alle kampanger.




IDS regler frigivet
Pt ingen kendte falske positiver.

Zyxel sårbarheder og exploit

 29 Maj 2023  - Blog Post # 853

Zyxel CVE-2023-28771
Hen over den sidste uges tid er Zyxel sårbarheder blevet udnyttet meget hårdt. Mange er på denne konto røget grundet upatchet firmware, på for åbne systemer der ikke er opsat efter best pratice, (Kommer jeg lige tilbage til) som i virkeligheden er en default "fejl" konfiguration i servicegrupper, som Zyxel faktisk laver. POC er allerede frigivet

Er man ikke patchet (firmware opdateret) allerede nu, eller bruger sikre opsætninger, så har man helt sikkert allerede en hacket firewall.



CVE numre: Man skal bruge V4.73(AAKZ.2)C0 - 2023/05/24
CVE-2023-33009
CVE-2023-33010

V4.73(AAKZ.1)C0 - 2023/04/17
CVE-2022-38547
CVE-2023-22913
CVE-2023-22914
CVE-2023-22915
CVE-2023-22918
CVE-2023-27990
CVE-2023-27991
CVE-2023-28771

Stor kritik herfra til Zyxel
Ved ikke hvorfor Zyxel syntes det er en god ide, at alle deres firewalls altid kommer med default adgang til Web-interfacet på outside WAN siden (Hele verden). Her er der også ting som ike, gre og et par andre ting og det er defalut adgang til for hele verden. Det ligger som standard i deres servicegrupper hvor man skal ind og fjerne det. Her burde det være noget der skulle tilvælges og ikke fravælges. Troede efterhånden at ingen gjorde det her mere. MEN det har betydet at Zyxel rent faktisk selv har gjort så RIGTIG mange af deres kunder er blevet hacket.

Generalle anbefalinger.
Noget jeg altid har været modstander af er TLS/VPN adgange, såfremt det giver angang til et web-interface hvor brugerne skal logge ind. Netop i Zyxel er det tilfældet. Her bør man kun bruge VPN klienter og ikke have noget stående åbent med mindre det er opsat i "point to point" til noget man virkelig stoler på. Man kan også bruge L2TP over IPSec, med certifikater på. Så behøver man ikke VPN klienter men kan bruge Iphone, Windows osv.

Mange har også den opfattelse af at disse adgange altid skal stå åben for hele verden. Vil man have det her så, opsæt VPN adgange så det kun bliver eks DK ip adresser der kan logge ind, eller det bedste er altid "point to point"

I mine øjne er det simpelthen dårligt admin adrbejde af værste skuffe, når det er åbent til hele verden og især web-interface til en firewall som står åbent. Få dem fjernet....... DET SKAL IKKE STÅ ÅBENT.

En anden general ting jeg tit støder på, er åbne adgang til eks firewalls fra alle lokale ip adresser på LAN siden. Det er heller ikke noget der skal være åbent. Her skal man lave IP firewall regler der kun tillader adgang fra bestemte admin IP adresser. Alle fra alle LAN's skal ikke have adgang, det vil kun gå galt.

En sidste ting er Wireless. Man skal idag ikke kun have 1 wireless LAN som mange stadig gør. Mange Zyxell firewall kommer med 2 Wireless LAN's (2 radioer) man kan opsætte. I dag skal man min have 3 forskelllige Wireless LAN's  -> Wi-Fi, guest Wi-Fi, og et IoT network. Set evnt NSA Releases Best Practices For Securing Your Home Network Så bare kom igang her også, for det gælder også for store og små virksomheder. Og bruger man Zyxell USGW så bør man hente sig et par wireless bokse mere.

Automatisk firmware opdateringer
Alle Zyxel firewalls undersøtter, at man kan sætte den til automatisk at opdaterer sin firmware. Brug det. Mange gør ikke og giver konsulent huse penge for at patche. Det er ikke nødvendigt. Zyxel firewall kan gøre det selv og det virker. Desuden får man jævnligt rebooet sit udstyr som også er med til at beskytte imod mange former for malware, der eks kun køre i memory. Set evnt NSA Releases Best Practices For Securing Your Home Network

Download:
CSI_BEST_PRACTICES_FOR_SECURING_YOUR_HOME_NETWORK.PDF

Er Zyxel Zywall en dårlig firewall ?
Nej basalt set ikke. Men sørg for de her grundregler bare altid er på plads. Zyxel er lige så gode som alle de andre til at få patchet deres ting. Brugerne er det store problem og lidt dårlige defaulte servicegrupper i Zyxel Zywall's. Dårligt admin arbejde kan generalt gøre det bedste systeme til en dårlige ting.

IDS regler frigivet
Jeg har for første gang frigivet en bunke af 6 forskellige IDS regler, der faktisk spotter hele kæden af events der er set derude indtil nu. Det er omskrevet IDS regler fra åbne kilder, så det hele bare passer ned i SNORT og virker.

Lige nu ser jeg faktisk scaninger efter sårbarheden på UDP port 500. Det kører lystingt og kommer fra manage forskellige ip adresser........Men ingen danske ip adresser ser jeg scanne.

PikaBot Malware

 27 Maj 2023  - Blog Post # 853

PikaBOT malware
En ny trussel man skal begynde at være lidt vågen overfor er PikaBot. Det bliver brugt flittigt og man skal nok være en smule vågen her. Jeg har analyceret 3 forskellige kampanger og har fundet en fin metode til at identificere når PikaBot henter payloads som eks Cobalt Strike. Den benytter faktisk en teknik der gør det ret svært for eks SNORT at validere det 100% sikkert via mere generiske teknikker. Det er dog lykkedes, men denne gang må jeg tilstå at jeg ikke syntes det er den bedste IDS regel jeg har lavet, men det er simpelt hen fordi at prce ikke lige opfører sig som jeg kunne tænke mig i SNORT. Her er Suricata faktisk langt bedre end SNORT (Sagde jeg lige det)...SNORT 3 der er det ret nemt.



Man kan læse lidt mere om PikaBot her

IDS Rule Frigivet
Der kan være falske positiver. Dog er det en Flow_Bit rule, hvilket typisk altid gør IDS rules langt mindre udsat for falske positiver. Det er også den måde jeg altid selv foretrækker at skrive IDS regler på.

Happy hunting...

Sysmon

 21 Maj 2023  - Blog Post # 851

Sysmon
I forbindelse med jeg bruger rigtig meget tid på Sysmon, har jeg efterhåden fået lavet en omfattende Sysmon config fil. Det er lavet på mine egne erfaringer og udforming efter "best pratice" samt gode ideer fra andre. Config filen bygger især på malware test, virkelige senarier og hvor man typisk kan fange malware / hacker stuff på Windows systemer. Desuden er der brugt lang tid på at optimere denne således at man ikke bare opsamler ting fra systemer man typpisk ikke rigtig kan bruge til noget.  For et almindeligt systemer vil støje helt vildt med logs hvis man ikke tuner sin config fil og bare indsamler blindt.

Config filen har sneget sig op på 2025 linjer config kode. Det betyder dog ikke at det alt sammen, er noget der indsamles, da der er lige så meget kendt, der bliver filtreret fra, såles at man spare på logs der sendes til et SIEM system for det koster i mange tilfælde også rigtig mange penge bare at sende det hele til eks Splunk. Derfor er det hele tiden en afvejning at sørge for at man kun indsamler det mest nødvendige, som er brugbart.

Nogen piver lidt over det "store" config fil, MEN det sløver ikke systemer ned og det man får er meget brugbart. Filen kan bruges direkte til at sende logs til eks Security Onion, Elastic med Winlogbeat eller til Splunk med Splunk Universal Forwarder. Config filen er især nyttig når man har med lokale test systemer, hvor man tester malware for at indsamle IOC'er til andre systemer. Her kan man hele tiden finde malware spor på systemer der benytter denne config fil. Alle disse små spor bliver typisk til Alerts i et SIEM system.

Sysmon er ikke EDR
En Sysmon installation må ikke ses som en fuld afløser for et fuldt EDR systeme, men derimod som et rigtig godt suplement til logopsamlinger fra endpoints der bruger Windows Systemer. En måde man kan blande det her på, er med en fuld log-implementering med Windows Event-logs. Sammen med fuldt implementeret IDS system, så får man noget rigtig kraftfuldt, til en meget billig penge, som giver rigtig god overvågning af systemer. Noget man mangler er typisk en måde hvorpå man kan tilgå systemer for at hive filer ud til undersøgelse, men det kan faktisk løses på mange simple måder man heller ikke skal betale penge for.

Udfordringen
Det der er udfordringen er at lære at skrive IOC'er der blander netværks trafik IDS systemer med log-opsamling, så det rent faktisk giver mening at kigge på som analytikker. Men det er efterhånden også noget jeg selv føler at have knækket koden til rigtig godt faktisk. Her er det vigtig hvilke event id'er man benytter sig af når man kigger efter IOS'er på systemer mm. Hertil bruger jeg både Splunk og Elastic,hvor man kan man lave rigtig fede ting så overvågning giver mening og Alerting kan løses på rigtig fede måder i Security Onion, Splunk og Elastic.

Config filen.
Hver eneste linje kode i config filen er testet, bla op imod Atomic-RED og der fanger den alle test senarier. Desuden er det testet op imod nye attack metodikker der ikke findes test for andre steder, samt en stor portion imod APT attack metodikker, der flyver den også meget fint med. MITRE beskrevet metodikker løser den også rigtig fint.

Hvad er så downside.
Alle log systemer kan jo blive slået ihjel, men man kan også se hvis det er tilfældet, "de fleste gange". Jeg er stødt på malware af en helt speciel karekter, hvor man virkelig skal være målrettet med sin config fil, det gælder malware som AV heller ikke fanger alligevel, og her bliver IDS / Zeek systemet din ven.

Man skal bruge en del tid på at lave meningsfulde "søgninger" til sit SIEM system. Fokuser ikke på hvad AV typisk fanger men typiske metodikker, Især MITRE er godt at fokuserer på her. Til sidst ender man med et log opsamlingssystem system, der bliver utroligt kraftfuldt, med meningsfulde Alerts som analytikker rent faktisk gidder kigge på og ikke hele tiden bare validere falske positiver, som er den største dræber for analytikkerer..

Træning.
Dog vil jeg sige, at det kræver meget tid at uddanne nye folk til at lære de rigtig mange attack metodikker der findes, for man skal træne sine øjne til at spotte om alerts er valide, og skal man virkelig vide hvordan disse ser ud fra den virkelige verden, så her bliver beskrivelser af alerts direkte i SIEM system virkelig vigtige, og disse skal altid indeholde eks "Nest Stepp" som en alalytikker skal foretage sig.  Selvom jeg allerede har skrevet rigtig rigtig mange, så kan jeg ikke engang selv huske dem alle jeg selv har lavet...

Powergrids , Windmill farms and Seacabels

 21 Marts 2023  - Blog Post # 850

Kritisk infrastruktur
Normalt ville jeg holde mig til emner omkring networkforensic teknikker og malware og mere i den retning. Men der er lige nogen ting ting der "undre" mig meget.

I forbindelse med at "Russerne" og sikkert også andre har stor interresse i vindmølle placeringer, kabler på havbunden osv osv... så er der lige et par ting jeg nok lige her vil henlede opmærksomheden på.

Den russiske interresse kan have mange vinkler, det kunne eks være hvor spræng-ladninger mm skulle placeres således at man kan tage denne type infrastruktur meget nemt ud af drift, hvis det var det de ville. Så derfor undre det  mig meget, at man gør al denne type information meget nem tilgængelig på internettet, så alle kan se hvor ligger og er placeret og forbundet med hianden.

Da jeg selv var soldat i sin tid lærte vi at kapasiteter, antal mm ikke var noget man måtte sige noget om og er en strafbar handling såfremt man gør det. Nu snakker vi om hvad vi betegner som kritisk infrastruktur, som jo er flere ting bla Internet søkabler, energi kabler (Powergrid), Gas rør ledninger mm. Derfor virker det hamrende uklogt at alle bare kan slå den information op. Man kunne vel i det mindste sørge for at denne type information er beskyttet således at det kun er dem der virkelig har brug for dette kan få denne information. Eks noget MItID login (Er klar over det kun er DK der bruger MItID) Men noget i den retning for validering af brugerne.

Buran - Første kendte Internet espionage program
Det her minder mig helt vildt meget om det første kendte Internet espionage program som omhandlede Buran fra 1981 Dette beskrev jeg kort "30 December 2018 - Blog Post # 709" Det er helt vildt underligt at myndigheder ikke lære bare en lille smule af fortiden her... for der kan drages mange paralleller her.

Vi bliver nød til at passe bedre på denne information, da det nemt kan slå rigtig meget ud i et samfund, bare kig på Ukraine. Denne type kritisk infrastruktur vil næsten altid være noget af det første man ønsker at slå ud i tilfælde af krig, derfor mener jeg vi i langt højere grad skal værne bedre om denne type information.

Desuden undre det mig også at vi i vores samfund har så forbandet travlt med at centralisere al power. Det er bare et enkelt knald, så er store dele af et samfund taget ud. Hvis man nu byggede sin power forsyning op omkring decentralicering helt ned på husstands niveau, så hvert hus fremstiller sin egen power, så ville et samfund være meget svært at tage ud af spillet. Det ville kræve nye byggelove således at alle husstande kan være selvforsynende med power. Derfor undre det mig endnu mere at vores politikkere syntes det er en fed ide at placere et kæmpe central vindmølle farm lige ved Bornholm, således at Russerne kan nøjes med at sejle ud i en "robåd" og sprænge vindløller... Ville det måske ikke være en god ide at placere denne lidt mere i ly af sjælland, fyn, Jylland ???

Mon ikke det snart er på tide man beskytter denne information lidt bedre end vi gør i dag. Det er ikke alt der behøver at være offenteligt tilgængeligt på Internettet som eks Buran var det !!!

Vindmølle farme i DK. (Europa)
https://map.4coffshore.com/offshorewind/



Powergrids i Danmark (Europa)
https://www.entsoe.eu/data/map/



Internet søkabler (Hele verden) - Beklager den dårlige billede kvalitet
Submarine Cable Map

Redline Stealer / Net.TCP Port Sharing protocol

 3 Marts 2023  - Blog Post # 849

Net.TCP Port Sharing protocol
Dette er en protokol opfundet af Microsoft for bla at løse unfordring med at der kun kan være 1 service forbundet til en port. Det bruges primært på IIS web servers. Men trafikken når man kigger på den er helt anderledes end alt muligt andet, da det jo er en anden (ikke ny protokol). Typisk ser man trafikken gå fra High ports til High ports. Det må siges at være lidt den "perfekte" service man kan enable på en ISS for at knytte malware til samme porte på web-serveren som de legale kørende ting man ellers kunne forvente. Det gør også man skal være vågen overfor at flere "programmer" kan køre på samme porte, herunder malware og især ved forensic af en web-server.

RedLine
Ved et tilfælde finder jeg en ET IDS trigger på RedLine fra 2021. Men denne trigger kiggede ikke efter Redline men net.tcp Port Sharing delen. Den person fra ET der har lavet denne IDS trigge har åbenbart ikke vist, at dette var net.tcp port sharing. For der blev ikke kigget efter selve malware delen.  Der blev kigget efter content:"net.tcp|3a 2f 2f|"; som er lige netop net.tcp port sharing. Det man nok lige skal være vågen overfor i det malware sample jeg henviser til, er det faktum at det er "High ports" til "high ports" hvilket kan indikere at firwall config måske ikke er tunet optimalt. Men net.tcp kan laves til at køre på alle porte. Det er også første gang jeg rent faktisk ser malware der udnøtter net.tcp og så er det fra 2021. Det er så også uklart for mig om dette kan have været tilfældet helt tilbage til 2018.

Data X-fil
Det er første gang jeg rent faktisk ser data X-fil hen over net.tcp port sharing. Det er rent faktisk kun 1 henvisning og hvis man kan huske Solarwinds hacket fra 2019 så blev denne Exploit forklaret i 2018 hvilket er lidt bemærkelsesværdigt i sig selv. Lige nu virker data X-fil der bruger net.tcp ports sharing rent faktisk er 100% undetected. Det er ikke krypteret med kører "In the open" (klar txt) selvom net.tcp understøtter kryptering.

Microsoft net.tcp port sharing
Der er lidt mere information om net.tcp her
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/net-tcp-port-sharing?source=recommendations

https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/net-tcp-port-sharing

Wireshark
Man skulle tro at Wireshark kunne forstå trafikken, men der er ikke noget protokol genkendelse i Wireshark og mit bedste bud  til denne del er dette display filter -> tcp contains "net.tcp://"

Caploader fra Netresec
Caploader kan finde Redline Stealer.


Malware sample
Fra ET IDS reglen er der en ref til RedLine malwaren  MD5: 6b5c7d46224b4d7c38ec620c817867ad
ET SID  2043233 Men igen så kigger denne efter net.tcp og ikke efter selve Redline Inforstealer.

MalwareBazaar
https://bazaar.abuse.ch/sample/29c5edac63fee5c99aa2307b2b16bfb5123a51d3c9dfef6bfb1342e18a20d641/

Any Run
https://app.any.run/tasks/503d74e7-9d60-4def-8605-3906e72509e3/

EDR
Der kan laves en hel del detection der holder øje med servicen lokalt på web-servers og hosts herunder forbindelser fra servicen. Det er klart anbefalet man lige for undersøget om ens EDR holder øje med dette.

IDS Rule frigivet
Jeg har frigivet en IDS sig der kigger efter net.tcp port sharing protokollen, da den jo er interesseant i forhold til IP, porte, domæner og filer osv..

Opdateret 05-03-2023
Har fået tjekke flere forskellige RedLine Stealer kampanger igennem, hvor der bliver benyttet net.tcp. Jeg kan nu identificeret når det er net.tcp og Redline der bruger net.tcp.

Happy hunting...

GoDaddy

 25 Januar 2023  - Blog Post # 848

GoDaddy
Igennem de sidste 3 år har GoDaddy været hacket. GoDaddy er ikke hvem som helst når man snakker Certifikater til det brede Internet. Alle har Trusted GoDaddy certifikater i deres browsers, på Windows, Linux, Mac, Android, Iphone mm. Med en kundebase på 20.9 millioner kunder, må det siges at være en stor del. Hvis man husker tilbage til hele sagen omkring Diginotar så må jeg sige jeg syntes at GoDaddy bør lide samme skæbne som Diginotar. De blev lukket ned at myndigheder for mindre end det GoDaddy viser her.

Certifikat udbyderer
Generalt set SKAL sikkerheden bare vare i yderste top når vi snakker om sikkerhed i denne type virksomhed, som sælger "trust" til Internettet via Certifikater. I gennem 3 år har hackerne stjålet source code og regiregeret kunder til yderligere malware sites mm. Det er helt helt uhøt at man kan have tillid til GoDaddy på nogen måde.

Med hackers indefor i over 3 år vil jeg godt skrive under på at det ikke er til at kortlægge hvor meget og hvad de har lavet, heller ikke med de bedste forensic muligheder, så vil det kun lige det sidste år hvis man er heldig at kunne finde lidt. Hos GoDaddy er 28.000 brugere blevet bedt om at skifte passwords fordi hackerne har været ind på brugernes konti og skaffet sig adgang til kundernes data som eks privat keys. Det har afledt en lang række efterfølgende hacks på kunde systemer verden over.  Jeg tror i virkeligheden at mange slet ikke forstår omganget i det her og hvad der er muligt med eks adgange og private keys.

Statement fra GoDaddy
De er kommet med verden kortes statement, hvor de bare siger "undskyld" Jeg siger også undskyld, men hele deres biks burde blive lukket omgående og al trust til nogen former for Certifikter burde blive fjernet, fra alle systemer.

SNIPS
The November 2021 incident led to a data breach affecting 1.2 million Managed WordPress customers after attackers breached GoDaddy's WordPress hosting environment using a compromised password.

Last year, scammers used hundreds of compromised GoDaddy accounts to create 15,000 subdomains, some of them attempting to impersonate popular websites, to redirect potential victims to spam pages that were pushing snake oil products.

Yderligere har brugerne fået stjålet private keys osv osv...... Listen fortsætter bare..

Anbefaling
Bruger ,man certifikater fra dem, skift dem ud til nye fra anden udbyder. Bruger man andre servisec fra dem, skift til andet. Fjern trust trust hvis det er muligt i browseres mm. De har desværre Root trust i browseres.
 

Googleaddservice

 23 Januar 2023  - Blog Post # 847

Googleaddservice
Mens mange retter blikket imod Ukraine og kigger på hvad der sker der, så skal man ikke kun rette site fokus den vej, for så bliver man godt nok fanget. Der er mange kræfter der gerne vil ha man kun kigger den vej, men det skal man nok ikke lade sig snyde af. Lige nu bliver opmærksomheden taget af Killnet og Sudan der DDOS'er danske virksomheder, men de gør slet ikke samme skade som det her kan gøre.

Rettet fokus imod googleaddservice
Jeg har siden slutning af sidste år kigget meget på Googleaddservice og alle de malware kampanger der ruller ud igennem netop googleaddservice. Det er som om "alle" de største malware familer pludelig "kun" kommer ud igennem googleaddservice det mere gængs infection chains syntes jeg er aftaget. Det er bemærkelsesværdigt at der er sket et så stort skift på de mange familier på så kort tid. Det kan bestemt godt være relateret til Ukraine.

Det sker igennem falske reklamer med malware der typisk leder til falske sider med kendt software som mange benytter også kaldet Drive-by-download. Der forekommer ved ganske almindelig google søgninger, hvis man tilfældigvis lige søger på noget software som som er målrettet af hackerne.

Målrettet software misbrugt
Jeg har samlet en lille liste af det software jeg selv har set der leder til malware via fake adds fra googleaddservice. Listen er bestemt ikke udelukkende kun til dette.

Den bedste beskyttelse lige nu og min klare anbefaling
Den bedste er helt at undgå google adds reklmaer i sin browser. Blokering af domænet er det nok bedste man lige nu kan gøre. Især gælder dette for virksomheder. jeg kan desuden anbefale at virksomheder begynder at deploye add blockers til virksomhedens maskiner. For et DNS filter på en primeter er slet ikke dækkende i dag. Der er for mange smutveje uden om, især fordi de fleste slet ikke choker outbound DNS.

Bloker følgende domæne
www[.]googleadservices[.]com

En meget kortfattet liste af malware domæner. Bemærk at der er mange hundrede domæner.
microsofteamsus[.]top
amydecke[.]online
anydeskcloud[.]tech
yes2food[.]com
cpu-id[.]top
wvv-llbreofflce[.]top
obsqroject[.]com
llbroofice[.]com
archiver-7zip[.]software
adobereaders[.]co
bravebrowsers[.]cc
sraelifrenchbulldogs[.]com/teamviewer
dogotungtam[.]com/teamviewer

Websocket

 08 Januar 2023  - Blog Post # 846

Websocket
Websocket er det man kan kalde den "pålidlige" version af HTTP. HTTP er en upålidlig protokol bygget oven på TCP der så gør den pålidlig. Den store forskel er nok at man kun behøver at åbne 1 session, man så kan holde gående meget længe frem for en http forbindelse der meget ofte så skal igennem 3-way handshake og skal åbne nye sessioner. Der er klart store foreskelle imellem de 2, men mere om det kan du læse om her

Encoding er ikke kryptering
Dog en særlig ting gør sig gældende i websockets er "Masked" det består af en Masking-key og maked payload.
Det er helt simpelt for at forhindre ting som eks proxyes i at snoope på trafikken. Endnu mere vigtig er det at trafikken ikke er krypteret med "MASKED" kun encoded. Bla Fiddler kan decode websockets. Wireshark kan ikke gøre det.




Data X-fil / C2 trafik
Det er klart at foretrække websocket frem for alm http såfremt man skal lave data-x-fil hvis man skal vælge imellem de 2, da websockets har det med at gå mere ubemærket igennem et netværk, da det ikke støjer særlig meget.
Derfor skal man som defender også holde et skarpt øje med websocket trafik i ens netværk.

MIn erfaring siger mig, at det ikke er noget der er mest af, dog vil man støde på det, og det er meget hurtigt at validere om det er skadelig trafik eller ej. Man skal være opmærksom på at websockets også virker hen over HTTPS.

Trojan Rhadamanthys
Netop Trojan Rhadamanthys benytter sig af websockets, noget man ikke ser hver dag. Derfor har jeg lavet en IDS rule der netop kigger efter websockets og selvfølgelig og til at identificere Trojan Rhadamanthys malware. Der findes bla også PurpleFox botnet der benytter sig af websockets og mange mange flere.

IDS Rule frigivet
Websocket og Trojan Rhadamanthys. 

Velkommen til 2023

 01 Januar 2023  - Blog Post # 845

Har været på en del år
I 2005 startede jeg med at skrive aktivt og publicerer en masse ting jeg fandt interesseant i forhold til IT-Sikkerheds relateret emner, dengang var det på et gammelt domæne og sidenhen netcowboy.dk og nu er jeg igang med 7 år herinde, så samlet set har jeg brugt 22 år og er igang med 23 år. 

Jeg må sige at der er sket meget igennem 23 år på IT-Sikkerheds området, det er helt vildt. De kommende år bliver sikkert med lige så mange udfordringer og spændende ting, noget der sikkert aldrig vil aftage.

Ny start
Jeg starter 2023 med at skifte til nyt job og vil fremadrettet arbejde for EnergiCERT. Det er inden for områder jeg er vandt til at arbejde i og med meget spændende opgaver. Noget jeg ser rigtig meget frem til og som vil passe bedre til mig fremadrettet både arbejdsmæssigt og på især det private område.

Jeg har altid elsket at arbejde i en CERT funktion som analytikker der dækker store områder af den danske infrastruktur. Det at bidrage til øget sikkerhed er noget der altid har været mig nært.

Så 2023 bliver sikkert et år med mange nye ting og nye mennesker jeg skal møde og lære at kende. En del af dem kender jeg dog i forvejen. Men jeg glæder mig.

Pænt farvel
2022 er jo også et år hvor jeg har takket af med TDC og hvor jeg faktisk har været glad for at være, og til alle dem i TDC kan jeg kun komme med et kæmpe varmt tak for tiden og pænt farvel.