Networkforensic

Threat hunting

QUIC - Follow-up

 17 Oktober 2021  - Blog Post # 803

QUIC - Malware relationer.
Efter at have overvåget og kigget trafik igennem der benytter QUIC og kigget på mange af de domæner og IP-adresser samt lande de er relateret til. Så er der her en jeg lige vil gøre lidt opmærksom på, som kaster rigtig meget røg af sig. Men folk jo selv dømme hvordan det kan hænge sammen, for i virkeligheden er det lidt uvist hvordan det hele hænger sammen endnu.

Russiske domæner
Ved at kigge på vk[.]com og vk[.]me som er relateret til Russiske IP adresser, dukker der mange relationer op til malware der er målrettet Android og Windows. Det er taget ud fra ren QUIC trafik. De nævente domæner har endnu flere domæner der er relateret til en række subdomæner som eksemplet herunder.


Via alm HTTPS Eller ?
Der ser på overfladen ud til at alle relationer er relateret til HTTPS forbindelser. Men her skal man nok ikke lade sig snyde. For INGEN ved reaelt hvad vi ikke kan se, som køre over QUIC forbindelserne. Mange forbindelser jeg har set til disse subdomæner er ren QUIC, men krypteret så der ikke er nogen mulighed for at se hvad de reaelt gemmer disse. De tools som er her VirusTotal kender ikke til QUIC protokollen. Så det er ikke bedre end det er. Men der er plads til lidt mere malware og trafik analyse. Måske der dukker et billede op på et tidspunkt. MEN indtil da ville jeg nok være lidt forsigtig ved at tillade de omtalte domæner. Det skal også siges at vejen frem er malware analyser af de samples der er relateret til hvad vi ved kan stamme fra QUIC trafik.

Blokeringer af domæner
Jaaaa...igen skal man ikke lade sig snyde. For husk på at en QUIC forbindelser ikke behøver at starte forfra med DNS opslag osv. Den kan sagtens køre fint viderer, når den kommer ind på en nyt netværk med chashed informationer som unikke Connections ID's. Så vil der ikke komme nye DNS opsalg, hvor man derved kan breake en forbindelse og det gør at et  DNS filter kan vise sig at være et meget svagt forsvar.

 

QUIC - Quick UDP Internet Connection

 1 Oktober 2021  - Blog Post # 802

QUIC
Rigtig mange ved ikke hvad QUIC er i det daglig brug, men de fleste bruger det hver dag. I 2018 belyste jeg QUIC en smule. QUIC er en opfundet ny protokol (fra 2012) og endeligt frigivet her i 2021 i version 1 udviklet af Google. Man vil også opdage at en udokumenteret version 1.1 allerede kan spottest i netværks trafik.

Det slår sig lidt op på at være en meget optimeret måde hvorpå der kan oprettet internet forbindelser. Det er den bestemt også må man sige og er egenteligt smukt arbejde der løser en del udfordringer.

En forsigtigt estimat er at alle virksomheder i dag, ligger på en forbrug hvor 20-30% af deres internet trafik er QUIC. Mange ved det dog ikke, fordi de udstyr de har stående og som bla skal håndtere deres sikkerhed slet ikke kan fortolke QUIC og derved forstå hvad der sker i denne trafik. Den skaber flere sikkerhedsmæssige bekymringer end den lige nu løser. Men set som en alm forbruger en god sikkerhed (såfremt trafikken ikke er ondsindet i sig selv)

Marketing
Som jeg ser QUIC, er det yderst flot design. Men min bekymring omkring at, det vil kunne få hvad mange kender som "super cookies" til totalt at blegne. Godt nok kan mange li Google og de ting de laver, men man skal huske på hvordan Google tjener de fleste penge, som er på at tracke brugerne. Det må man sige at QUIC bestemt også er meget egnet til, da der ligger unikke Connections ID's i pakkerne. Det kan desuden ske hen over flere forskellige netværk, hvor forbindelsen i virkeligheden bare kan fortsættet uden den behøver at starte forfra, som man kender det i dag med alm TCP handshakes osv. Kigger man også på den på denne måde, er det en fantastisk protokol til at målrette annoncer med, da man hele tiden ved hvem brugeren er uanset hvordan de bevæger sig rundt.

Det betyder at er en forbindelse oprettet til eks youtube eller ond-domæne, så behøver man ikke at se hele oprettelsen igen der ligger forud, for at QUIC går i gang på det nye netværk. Så er det bare QUIC der fortsætter på chashed information. Det betyder at eks en inficeret maskine, der er inficeret uden for det "sikre net", realt bare kan fortsætte sin krypteret trafik, som en blind medløber i trafik strømmen uden dem der sidder på netværket kan se hvad der sker andet en en forbindelse imellem 2 IP adresser.

Inspection
Foretager man det som mange kender som HTTPS scanning eller TLS-Offload med forskellige typer middelboxes, hvor man i dag fifler med med public certifikatet og installerede proxy certifikater på klienter, så bemærk lige noget endnu mere vigtigt her, at certifikater ser man ikke mere, da de kun udveksles fuldt krypteret. Så i princippet er alle de løsninger af middelboxes som en del virksomheder allerede har 100% virkningsløse imod QUIC.

Billede viser min Wireshark profil igang med QUIC

Merlin C2 Framework
I forbindelse med QUIC og udnyttelse af denne protokol, er der lavet et C2 Framework "Merlin" hvor Command And Control kan bygge på QUIC. Derved vil ting som x-fil af stjålet date kunne gå fuldstændig under radar på stort set samtlige netværks overvågnings enheder, unden en eneste mulighed for at opdage at dette sker. Dette framework virker allerede i Kali. Bestemt værd at kigge på såfremt man er pen-tester.


Hvordan kan man finde QUIC
For at finde QUIC i en netværk hvor udstyr slet ikke forstår QUIC, kan man faktisk kun kigge efter pakker der bliver sendt på UDP dst port 443. Jeg testede på en ældre version af Security Onion. Eneste mulighed var at kigge efter de beskrevet pakker på UDP.  Kan derfor godt anbefale at benytte den nyeste version 2.x af Security Onion og få installeret de nødvendige QUIC scripts.

Browsers og test af understøttelse
De fleste browseres i dag kan forstå QUIC og er enabled som standard. Man skal typisk ændre default setting for at disable QUIC. Især Chrome og Firefox har default fuld understøttelse.

Man kan desuden teste web-sites (web-servers) for understøttelse at de forskellige versioner der har været fra første test versioner frem til i dag, via dette test site. https://http3check.net - Lidt overrasket blev jeg da selv da jeg opdagede min egen web-udbyder rent faktisk understøtter QUIC.



Hvordan kan man stoppe brugen af QUIC
I længden vil jeg ikke mene at man bør stoppe brugen af QUIC. Udviklingen af og brugen af QUIC er der simpelhen for mange fordele i. Dog vil jeg mene at det pt ville være det fornuftige at gøre, såfremt man ikke har nogen systemer der kan fortolke QUIC på nogen måder. Jeg kender faktisk kun til 2 producenter der kan. 1 i DK og 1 i US.

Løsningen skal nok findes i de løsninger der kan køre Zeek. RIGTIG meget netværks udstyr som de fleste bruger i dag, bruger ikke Zeek, eller har noget andet indbygget der kan fortolke QUIC. Dog skal der tilføjes lidt scripts før Zeek kan se og fortolke QUIC og de informationer man kan få ud af det. Så bare at have Zeek betyder ikke man default så fortolker QUIC.

At stoppe QUIC i et netværk er simplet. Drop UDP pakker på port 443. Der kun QUIC jeg kender til der ligger der og hvad der ellers er endten fejlkonfigureret eller Trojan trafik) Så man kan roligt gøre det efter min mening og jeg gør det selv. Dog skal man huske at browsers også skal ændres såfremt de ikke er dækket af ens eget netværksudstyr typisk laptops og udstyr der bevæger sig ind og ud af et netværk.

Hvad er der tilbage
Der er lidt metadata som eks 2 ip adresser der snakker med hianden, så kan der laves Bit udregninger der siger lidt om hvor meget data der flyver igennem forbindelsen. Lidt hvor man kan afgøre on det så er en ondsindet IP. Måske lidt MAC adresser i nogen sjældende tilfælde. Men typisk giver MAC adressen kun identifikation om de 2 enheder der sidst rørte forbindelsen som en Switch eller firewalls som er sjældent brugbart til noget stort.

Måske i fremtiden
Source Connection ID's og Destination Connection ID's i QUIC EITF data pakken. Kunne man tror er valide i en del tilfælde, men de kan skifte midt i en forbindelse og så stadig være en del af den samme forbindelse. Her kan man også lave IDS regler der vil trigger, men jeg ved endu ikke hvor lang tid de typipsk lever og om det ville give noget der kan arbejdes med i længden, tror det kommer lidt an på selve implementeringen. Typisk ville de kun kunne blive benyttet hvis man er Google eller den der ejer serveren der levere content. Lige nu er de fleste bare helt blinde.

SANS Whitepaper fra 2020
SANS har lavet en god test af QUIC som er fra 2020. Jeg vil anbefale man læser den igennem, for det er helt sikkert tid til at skifte netværk overvågnings udstyr ud med noget der kan fortolke QUIC.
QUIC & The Dead: Which of the Most Common IDS/IPS Tools Can Best Identify QUIC Traffic

QUIC- A Quick Study
Udgivet fra Santa Clara University skrevet af Puneet Kumar Denne er også fra 2020 og giver en lidt anden vinkel end SANS. Men informationen er god.

The TCP killer
Chris Greer har på Sharkfest 2021 lavet en youtube video jeg desuden kan anbefale man ser igennem.
Bemærk lige hans kommentar om at Microsoft planlægger at omlægge SMB trafik til QUIC. Den er der faktisk allerede en del hold i. Desuden ved jeg at mange IoT producenter arbejder på at implementerer QUIC da der er store fordele i dette for dem også.

QUIC Standarden
Man kan læse mere om selve standarden her - https://datatracker.ietf.org/doc/rfc9000/

Wireshark profil
Jeg har frigivet en Wireshark profil der er lavet til at analysere QUIC, man med fordel kan benytte i sin egen Wireshark for at komme hurtigt i gang.

IDS rule frigivet
Kigger på versions nummeret i protokollen. Det er tæt på det eneste der validt kan detectes for. Der findes ikke nogen parser som eks i Wireshark der kan kigge efter domæne / server navne osv i SNORT eller Suricata. Parseren i Wireshark virker også lidt underlig ind imellem, hvor jeg ikke helt kan genneskue hvad der foregår.

Rule ID sid:5003062 - (Disabled som default i mit IDS Rule set) Jeg ville nok selv enable denne IDS rule, kun for at foretage en valid søgning efter antallet af oprettet forbindelser til domæner. Det kan derved countes og giver et overblik over hvor meget der er af QUIC trafik.

alert udp $HOME_NET 1024: -> $EXTERNAL_NET 443 (msg:"NF - QUIC version 1 - Detected"; content:"|00 00 00 01|"; offset:35; depth:45; reference:url,networkforensic.dk; classtype:unknown; metadata:01102021; sid:5003062; rev:1;)

Quic happy hunting.....

 

Remcos-RAT

 26 September 2021  - Blog Post # 801

Remcos-RAT
Tilbage i September 2019 skrev jeg om Remcos-RAT som jeg dengang syntes var en rigtig "godt lavet" RAT. Det syntes jeg stadig, dog er den lige blevet et hak bedre. Der er stort set ikke meget tilbage i tafikken hvorpå denne kan identificeres på andet end et par unormale porte med TLS Client Helo i. Bliver denne brugt henover de normal TLS port ville denne stort set være "umulig" at finde. Det sample jeg lige har undersøgt at Remcos er brugt i et målrettet angreb hvor payloads indeholder exploits med bla Microsoft Office Memory Corruption mm.

IDS Rule Frigivet
Denne finder faktisk kun TLS Client Helo på de "unormale" porte. Dog skal man lige være vågen for der er ikke noget certifikat at finde i trakikken. Jeg vil tro denne IDS rule kan give falske positiver, men bør være meget begrænset i omfang. Derfor bør man holde øje med de IDS rules der trigger imod den pågældende host da der typisk er andet at finde samtidigt.

 

Trojan Squirrelwaffle Loader

 25 September 2021  - Blog Post # 800

Squirrelwaffle Loader
Squirrelwaffle loader er åbenbart det der har overtaget den "gamle" Qakbot Botnet infrastruktur. Så vi skal nok vænne os til at se mere til Squirrelwaffle. Den 13 September 2021 gik det løs med distribution af Cobolt Strike med hjælp fra Squirrelwaffle loader. Det køre lige nu som mails med links fra en dokument fil, der pakker en vbs fil ud som henter "forskellige" payloads. Lige nu er det Cobolt strike.

C2 domæner
Der findes masser af domæner med C2 der allerede er blokeret. Det her er bare et udsnit af dem der findes. Men man kan med fordel blokere for disse.

centralfloridaasphalt[.]com
kmslogistik[.]com
chaturanga[.]groopy[.]com
mercyfoundationcio[.]org
shoeclearanceoutlet[.]co[.]uk
spiritofprespa[.]com
jhehosting[.]com
key4net[.]com
lead[.]jhinfotech[.]co
voip[.]voipcallhub[.]com
voipcallhub[.]com
bartek-lenart[.]pl
lenartsa[.]webd[.]pro
amjsys[.]com
novamarketing[.]com[.]pk
ems[.]prodigygroupindia[.]com
hrms[.]prodigygroupindia[.]com

SRP Rule
Det er nok tid til at tilføje følgende sti til sine SRP rules. Det breaker alle kampanger der er set indtil nu.
Tilføj "vbs" til "Designated file type Properties"
Tilføj %PROGRAMDATA%\ til Path Rules som disallowed

Kendte triggers på stribe
Det er ikke fordi man slet ikke kan opdage de her kampanger med de default triggers der allerede findes og dem jeg selv har lavet bliver da også triggert på stribe.







IDS Rule Frigivet
Lidt sjovt, at jeg denne gang skulle lave en IDS rule, på det der faktisk ikke lige er synligt i en Wireshark forensic analyse af trafikken. Men den fanger alle de kampanger der er set indtil nu og finder C2 trafikken med det samme også fra alle de ikke kendte domæner. Ingen kendte falske positiver.

 

Security.txt

 15 September 2021  - Blog Post # 799

Security.txt
Igennem mange år hvor jeg har arbejdet med IT-Sikkerhed, kan jeg simpelhen ikke længer huske hvor mange gange jeg har opgivet på få kontakt med forskellige virksomheder, fordi jeg har fundet sårbarheder, malware, de har været hacket osv osv. Jeg har opgivet at få kontakt og nogen gange efterfølgende set i medier at de netop er blevet hacket, det er lidt en aha oplevelse må man sige. Her må man bare trække på skulderen og og tænke på hvordan det kunne have set ud for dem, hvis der bare lige var lidt kontakt information til de rigtige personer.

Virksomheder
Mange virksomheder opgiver simpelthen ikke nogen information eller vej ind til at få den nødvendige kontakt. Som jeg ser det, har dette altid været et STORT problem. Efter man så fjernede de få muligheder man havede med GDPR lovgivning, som man i nogen tilfælde kunne fnde eks via DK-Hostmaster, så blev det bare endnu værre.

ietf.org - RFC draft
Det nye tiltag jeg har set for nylig under IEFT vil jeg meget gerne støtte op omkring, da det gør det muligt rent faktisk at advare andre under en sæt regler der er deffineret i RFC standarden. Det handler især omkring hvordan man kan opsætte de nødvendige informationer så det bliver muligt at få kontakt til virksomheder. Der er sågar oprettet online framework der kan støtte den enkelte virksomhed i at få gjort det rigtigt fra starten.

Jeg har selv oprettet en security.txt fil her under mit eget web-site, man kan bruge som inspiration til sin egen virksomhed. Her har jeg også lænt mig lidt op af hvad andre allerede har gjort på området. Jeg ved der er et par fodfejl i det jeg har gjort i forhold til standarden. Det er lige nu helt med vilje, men det virker. Jeg har sågar valgt at publicere et link under contact som kan benyttes. Det behøver ikke være så hemmeligt for min skyld.

Opfordring
Det er min helt klare opfordring at virksomheder bør opsætter disse. Hvem vil ikke gerne blive advaret i tide. Det er stort set gratis. Jeg køber virkelig ind på dette og kan anbefale andre at gøre det samme.

Jeg vil også gerne lige takke Kristian Bodeholt for at gøre mig opmærksom på dette framework.

 

Udløbet certifikater "Kerio" eller GFI Software

 23 August 2021  - Blog Post # 798

Kerio idag GFI Software
Vi lever altså i nogen tider hvor man efterhånden er blevet dygtige til at holde øje med om et Certifikat er udløbet.
Det kan man dog ikke sige om Kerio efter de for en del tid siden blev købt af GFI Software

Udløbet certifikater.
Jeg har i efterhånden en del tid prøvet at gøre dem opmærksomme på at deres certifikater er udløbet helt tilbage i til 28 januar 2021. Jeg har udfyldt en del support sager til dem, og ingen ting sker der.

Det er typisk sådan at hvis man først udadtil viser at man ikke helt har styr på det og det ligner lidt en roddebutik, så plejer det at afspejle at det faktisk er mere slemt på indersiden af et netværk, derfor skal man bla også vise at man ikke benytter udløbet certifikater osv osv..og slet ikke hvis man påstår man er en sikkerheds virksomhed, det gir altså slet ikke noget plus i bogen heller ikke selvom man er ved at udfase en produkt.

Det har ikke været super godt for de gamle Kerio produkter at de er kommet ind under GFI software. MEN jeg er ret overbevist om at de er ved at gå "software døden" lidt i møde. jeg vil nok ikke anbefale nogen at kaste penge efter kerio produkter mere. Det virker lidt som om det bare er ved at vride citroen for de sidste dråber.


 

rclone detection with Sysmon

 17 August 2021  - Blog Post # 797

rclone
rclone er gået hen og blevet en ting som en del ransomware bla benytter til at foretage x-fil af data til cloud providers. Mere information her - https://research.nccgroup.com/2021/05/27/detecting-rclone-an-effective-tool-for-exfiltration/ Man bør holde øje med hvor i ens infrastruktur rclone benyttes.

Lagt ind i Sysmon config fil
For at bedre kunne opdage når rclone bliver installeret (oprettet) er dette nu lagt ind i min sysmonconfig.xml fil.
Det vil blive opdaget via Security Onion i Kibana som technique_id=T1020,technique_name=rclone



‘PrintNightmare’ - CVE-2021-1675

 4 Juli 2021  - Blog Post # 796

Sårbarhed i print spooler servicen
Ja endnu en sårbarhed i en Microsoft Service. Netop print spooler servicen har der igennem tiden været flere kritisk sårbarheder til. Derfor helt tilbage fra Windows XP tiden har det været god skik ikke at starte denne service som default på andet end print servers. NEJ en AD controller skal ikke være print server. Klienter skal heller ikke agere print servers. Heller ikke selvom Microsoft syntes det er en god ide at service er startet som default.

Fiks fra Microsoft bliver frigivet 12 Juli 2021 til dette.
Man skal ikke gå i panik over denne selvom rigtig mange gerne ser man gør. Hvem kan ikke leve uden en ny printer bliver installeret før den 13 Juli 2021 (7 dage fra nu)

Skift rettigheder på følgende C:\Windows\System32\spool\drivers (med alle subfolders) "Deny modify" Fjerne også system rettigheder. Det forhindre også den POC der er i omløb slet ikke vil virke.

Det der allerede er installeret vil stadig virke med denne simple mitigering: Selvom nogen siger det er en dårlig ide så virker det rigtig fint at ændre rettigheder på folderen og det kan gøres indtil et pacth er kommet. Inden du patcher skal du selvfølgelig huske at ændre rettigheder tilbage igen.

Det er jo ikke sådan at alle printere holder op med at virke og husk driveren er installeret på print serveren. Endnu mere vigtigt er at et print job bliver sendt til følgende sti på en print server - C:\Windows\System32\spool\PRINTERS (Hvis det er Windows) og det er ikke den der er ændret rettigheder på. Så print virker stadigvæk. Min overbevisning siger mig at 99.99% af forretningen virker indtil en patch er kommet. Og du kan nu sove roligt de næste 7 dage. Husk det er en mitigering ikke en permanent fiks.

Nogen påstår det er den vildete sårbarhed i 17 år.
Til det kan jeg kun sige sikken en gang vås. Jeg kan uden problemer finde hunderedvis i samme kategori bare fra 2020. Noget bliver ikke mere sårbart end CVSS v3.0 Rating10.0. En sårbarhed kan være kritisk på mange måder. Giver den system rettigehder, så er den lige så slem som alle de andre med CVSS 10.0. Kan den bruges af orme osv så er det jo skidt. Igennem 2020 har der være flere sårbarheder der kan bruges af orme. Så det gør ikke denne her til noget mere spicelt end alt det andet der har været.

Lige netop print spooler. Der skal man i 99.9% af alle tilfælde have adgang til der hvor der er en print server eller som nogen uheldige elementer har gjort det og installeret print serveren på en AD controller. Det er typisk på et LAN.

Jeg kan virkelig anbefale at bruge Linux (Ubuntu) som print servers, såfremt man har brug for print servers.

Til mange vil det nok være en god ide at få kigget generalt på print spooler servicen i et Microsoft setup. Få den nu kun aktiv der hvor den skal bruges (på print servers) og Linux Ubuntu servers virker fint som print servers. Vi ved jo det er en service på Microsoft der har været i target mange gange før, så hvorfor ikke bruge en Linux kasse når nu servicen alligevel skal være tilgængelig for mange. Så kan man også spare den licens.

Følgende GPO kan bruges
Allow Print spoolers to accept client connections - set to disabled

Yderligere kan man nøjes med at disable Print Spooler servicen
Print Spooler - startup type = disabled

Security Onion med Sysmon
Bruger man Security onion eller bare Sysmon og opsamler disse til en ELK med winlogbeat, kan jeg anbefale følgende:

I min frigivet Sysmon config er den nu tilpasset så man ser alle filer der bliver oprettet i C:\Windows\System32\spool\drivers og underforlders.

Følgende søge strenge kan benyttes til at finde oprettet filer i denne folder:
Elk søgning: target_filename: "c:\\Windows\\System32\\spool\\drivers\\*"

Evt kig efter rulename:
Bruger man ikke det at ændre rettigheder og i stedet vil holde øje med hvor mange filer der bliver oprettet i en instastruktur i drivers folderen med sysmon. Så vil man nok blive lidt forbavset over hvor lidt der sker dernede.
event_data.RuleName: "File created in Print Drivers folder"

Til sysmon config:
<RuleGroup name="" groupRelation="or">
<!-- Event ID 11 == FileCreate. -->
<FileCreate onmatch="include">
<TargetFilename name="File created in Print Drivers folder" condition="begin with">C:\Windows\System32\spool\drivers</TargetFilename>

 

Security.ipip.net - Endnu en uautoriseret scanner

 14 Maj 2021  - Blog Post # 795

Uautoriseret scanner
Security.ipip.net er blot en mere på listen over nogen der mener, de har ret til at footprinte hele internettet, inklusiv de sårbarheder som de så kan finde. Man ved ikke hvad data går til. For mig er dette altid kun en target liste og ligger i kategorien "Recon"

Det er lidt underholde at se hvad de mener de har RET til. (Ping / Traceroute Mainly) Hvad betyder Mainly i denne sammenhæng ? Jeg kan så bekræfte at det er det langt fra. Jeg kan finde dem på rigtig meget andet end det.

Deres IP adresser.
Jeg har brugt lidt tid på lige at lede lidt mere efter dem. De benytter primært linode IP ranges. Man kan for nemhedens skyld bare blokke hele linode. Men jeg har frigivet den konkrete IP liste her, så man selv kan lave Firewall rules mm.

IDS Rule frigivet
Jeg har firigivet IDS rules således man selv kan få et overblik over hvor meget man bliver scannet af dem.

 

Emotet takedown lader til at virke

 26 April Februar 2021  - Blog Post # 794

Nedtagning af Emotet virker
Skrev i blogpost 790 om Emotet nedtagningen som er foretaget af Europol Cyber Defence. Det lader til at Europol Cyber Defence har gjort et fint stykke arbejde. Den sidste del, hvor Emotet ville afinstallere sig selv d 25 April 2021 lader til at virke. Der er ifølge Any.Run's meget fine tracker system ikke set nye sampels efter 25 April.

Vi siger tak herfra til Europol Cyber Defence
Nogen fik ret og andre gjorde ikke og så er der dem der har fjernet deres blogopslag hvor de "hakker" lidt på Europol Cyber Defence og påstår det ikke vil virke. Har de mon fjernet deres opslag fordi de er flove ?
 

 

Elendige dårlige phishing scammers

 09 April Februar 2021  - Blog Post # 793

Forsøg på misbrug i forbindelse med Corona, pas, e-boks, Nemid og Postnord osv.
Hvor dårlig kan man blive til phishing kampanger ? Det er helt vildt så dårligt udført det her er.
Stoppede en phishing mail, der vil se ud som den kom fra e-boks, men oplysninger viser postnord og payload skal hentes på billingpostnord[.]com. Det er en stor rodebutik, men det matcher med de mange andre daglige kampanger der er målrettet danskere for tiden med PostNord tema. 

Postnord phishing kampanger imod alle
Igennem det seneste lange stykke tid har jeg dagligt set phishing mails sendt imod danske virksomheder og private og lige netop PostNord temaet er ret omfattende misbrugt. Men jeg ser også mange ligheder imellem fejl der i disse kampanger og hvor den "person" der sidder og opfinder de domæner der benyttes i disse kampanger, simpelthen er så dårllig til at finde på nye navne at ligheden imellem 90% af dem er i samme udformning.

Lige netop denne kampange har samme karakteristika som jeg har set tidligerer. Det er jo helt vildt skrald at benytte tema fra tidligere eller kommende postnord kampanger til at forsøge at misbruge bruge e-boks. Hvem vil lige uploade billeder af sit PAS til nogen som helst.

Opfordring til NC3 (Politiet)
Jeg vil rigtigt gerne komme med en venlig opfordring til NC3 (Politiet)  til at begynde at lave noget efterforskning denne gang. For en gang skyld på noget der kan beskytte mange danskerer og virksomheder, da der rent faktisk er noget at gå efter i de mange phishing mails med postnord tema. De sammen benytter iøvrigt Nemid tema også.

Jeg er ret overbevist om at det er den/de samme personer, der står bag de fleste af disse kampanger. Det vil være med til at få lukket ned for de mange daglige angreb, vi ser imod danskerer og danske virksomheder.

Opfordring til Postnord
Noget andet jeg har bemærket i forbindelse med Postnord, er at når man snakker med folk eller bare selv bestiller en vare hvor Postnord skal leverer pakken, så vil man endten samtidigt eller inden for minutter/timer efter bestillingen også modtage den første phishing mail med Postnord tema. Det kunne være værd for postnord på den observation lige at få gennemgået egne servers, for jeg er ret overbevist om at "nogen" følger med i hvornår der sendes valide mails ud. Det er ikke et tilfælde, der er for meget røg. 

Anbefaling til beskyttelse imod disse Phishing mails
Vær opmærksom på at postnord kun sender mail fra følgelde mail adresser de har selv beskrevet her.
Samme type information bør andre statslige institutioner oplyse om. Det kan hjælpe i kampen imod Phishing.

Whitelist følgende afsenderer:
noreply@postnord.dk
noreply@postdanmark.dk

Blacklist følgende afsendere eller replay to
noreply@postnord.com
no-reply@postnord.com

OBS - Nogen virksomheder bruger følgende URL når de sender besked til brugerne med et tracking nummer. Dette kan findes i content i mailbody. I disse tilfælde er mailen typisk valid. Til dem der sender mails ud fra deres web-shop burde droppe det. Man er nød til at lave undtagelser på anden vis her. Kommer lidt an på hvilket system man benytter til SPAM håndtering.

https://tracking.postnord.com*

Yderligere kan man tilføje følgende SPAM regler til SPAM håndteringen i content.
Søg efter content i mailbody. Sørg for at whitelist filteret på de valide afsender adresser kommer før content regler.

https://*postnord.blogspot.com/
https://*postnord.com/
https://*postnord*.com/
https://postnord*.com/
https://www.*.com/.postNord.dk/
https://postnord*.online/

Happy Hunting.......
 

 

Binaryedge ninja

20 Februar 2021  - Blog Post # 792

Binaryedge
Bare endnu et
skod firma der syntes de skal scanne internettet. Jeg kan kun anbefale at man går imod denne type virksomhed og lige tænker over sin egen dobbeltmoral, inden man syntes man vil tilkøbe data fra nogen der skider højt og flot på andres sikkerhed og leverer "attack" data til andre. Jeg ser mange der køber data fra denne type data brokers inklusiv de danske myndigheder.

Research
Jeg går meget ind for research af sikkerhed. MEN det skal gøres på den rigtige måde, hvis det skal gøres ellers er man ikke bedre end ondsindet hackers og meget andet skrammel, der er med til at gøre Internettet til et usikkert sted at være. HUSK når data bliver indsamlet, så kan det i høj grad også bruges ondsindet eller til egen fordel på mange måder.

Der er en udbredt misopfattelse herunder hos danske CSIS om man bare kan bruge de data der er indsamlet på den mindre pæne måde. Man skal tænke over hvilket indtryk omkring moral og etik man vil sprede udadtil når man bruger data. Herunder hvordan en IT-Sikkerheds virksomhed skal fremstå. Det CSIS præsentere er nok en dårlig moral på nogen områder.

Man fremstår IKKE moralsk og etisk rigtig, ved at ride med på bølger i medier mm for at kunne lave ambulance artikler om hvor usikre andre er, bare for at kunne lave et mersalg. Det er den genralle ting man ser mange virksomheder der har noget med IT-Sikkerhed gøre. Jeg har også selv været på den vogn og er blevet klogerer.

Man sætter man sig selv i bås og jeg er ret overbevist om at moral og etik især fra IT-Sikkerhds virksomheder står højt på manges liste når de vil vælge hvem der skal lave sikkerhed for dem. Som Peter Kruse siger, så har det været alm praksis i mere end 10 år. MEN det gør det ikke mere rigtigt. Fordi alle køre over for rødt lys er det bare ikke rigtigt at følge med ? Lagt fra. Nu nævner han selv SHODAN og lige netop dem har jeg skrevet mange artikler om, og hvad risikoen er ved at lade sig scanne blidt af dem. For de er netop i høj grad med til at gøre Internettet et usikkert sted at være.

Til de sikkerheds folk der arbejder i en type af virkksomhed der måske har en lidt dårlig moral, her skal man selv tænke over om den moral som virksomheden præsenterer, er en man gerne selv vil have siddende på sit CV, såfremt man vil ud og gøre karriere senere hen. For det spiller en stor rolle.

Husk research er fantastik, men gør ikke andre andre usikre eller bring dem i en situation hvor det kan gå helt galt for dem. Gør det ansvarsfuldt så dem der bliver usikre i forbindelse med din research, altid har en chance for at bringe ting i orden. Vil du scanne hele internettet efter det du har fundet, så gør det selv. Men giv andre en mulighed for at vide hvem det er der scanner. Lige så snart du bruger andres data og platforme, så er der rent faktisk andre der følger med i hvad du leder efter. Så kan dine fund rent faktisk misbruges af andre med mindre pæne hensigter.

Husk din research skal være med til at hjælpe andre.....Arbejder du set sted hvor det ikke er tilfældet, så tænk over den moral og etik du selv vil være sat i forbindelse med. For dem der skal ansætte dig senere, vil kigge på hvor du kommer fra.

 

TOR-Browser v10.x

13 Februar 2021  - Blog Post # 791

TOR-Browser
På opfordring har jeg opdateret IDS rules til at finde klienter der benytter sig af TOR-Browsers. De gamle IDS rules jeg har (nu disabled) virkede kun imod 8.x versioner, men er blevet for gamle. Det er også lang tid siden jeg har brugt mere end 2 timer på at få fremstille en IDS rule der virker. Der er stor forskel på om noget virker på en windows installeret SNORT eller om det er til Security Onion. Mine IDS rules skal helst virke begge steder. Det var lidt en udfordring denne gang. Men det virker nu......
 

Security Onion - JA3
I forhold til TOR-Browsers, så har det hele tiden virket med detection på JA3 Hash'en alene. Denne er ikke skiftet i TOR i årevis. Derfor har jeg ikke haft den store fokus på at få dette til at virke i SNORT. Dette dashboard har været tilgængeligt også i årevis fra mit download Security Onion Tool site. Det virker stadig på stort set alle versioner af TOR også den nyeste version.
 

IDS rule frigivet
Jeg har frigivet den nyest IDS rule til at finde Tor-browseres der køre 10.x. De gamle IDS rules omkring TOR er nu disabled i IDS sættet. Den kan muligvis give falske positiver, i så fald høre jeg gerne om det og gerne med en tilsendt pcap fil, ellers er det svært at tilrette. Jeg ved der kan være et problem med nogle spicelle certifikater fra Google, men det er heldigvis meget få. Men jeg har endu ikke kunne finde et certifikat der giver denne falske positiv.

 

Emotet takedown - Virker det ?

8 Februar 2021  - Blog Post # 790

Emotet takedown - Virker det
I forbindelse med
Emotet takedown er der "nogen" derude der siger det ikke vil have nogen effekt. Har de nu også ret i hvad de påstår ? 

Nye samples
Der triller stadig nye sampels ind hver dag på Emotet. Men dette kan sagtens være rester at en automatiseret infrastruktur, der stadig står og sender kampanger ud. Men umiddelbart kan man jo godt give dem ret i at det ikke har den ønskede effekt. Men tænker man tilbage SQL Slammer fra 2003, så dukkker den også stadig op derude ind imellem. Jeg vil næste tro at det bliver det samme med Emotet, da der sikkert er mange inficeret hosts derude.

Hvordan ser det overordnet ud
Kigger man på de forskellige watches der findes på internettet, der holder øje med de forskellige malware kampanger. Så ser alle sammen næsten ens ud. Det har en stor indvirkning på Emotet, som næsten droppede til ingenting sammenlignet med tidligere. Men nu ser desværre en lille stigning igen, så måske de får ret alligevel.

Følger med
Over den næste lange tid vil jeg da også holde et våget øje med Emotet, for det er noget jeg selv har brugt meget tid på at overvåge og lave detection for samt tømt enkelte af deres dropsites. Den store dato bliver 25 April 2021 som er der hvor myndigheder har sat Emotet til at afinstallere sig selv. Efter denne dato bliver det især vigtigt at holde øje med det. Jeg håber det forsvinder for der er så meget andet at holde øje med derude.

Dog er det mig helt uforståligt at man har meldt denne dato ud. Det virker næsten som om man har givet nogen en chance for at rykke sig til ny infrastruktur. De burde bare have holdt dette hemmeligt.

 

JARM fingerprinting Cobolt Strike servers

 23 January 2021  - Blog Post # 789

JARM
Salesforce har frigivet en metode til at fingerprinte TLS servers de kalder for JARM. Dette gør det muligt meget præcist at fingerprinte eks malicious servers som kunne være Command and Control Servers. Det er virkelig "top of the art" i jagten på at identificere skidte ting på internetet når man først har fået færten af dem. Det minder på overfladen lidt om JA3 som Salesforce også kom med. JA3 er passiv og JARM er dog aktiv scanning. Jeg 100% sikkert overbevist om  at netværks relateret sikkerheds løsninger der i dag ikke kan JA3 eller JA3S skal man slet ikke spilde sin tid eller penge på.

Cobolt Strike
Cobolt Strike er et ret avanceret pentest tool. Det koster kassen, men bruges af rigtig mange sikkerheds virksomheder der fortager pen-test. Dog er der over den seneste tid set et meget stort skifte i at dette også bruges af kriminelle grupper til Ransomware attacks, BotNets, og ikke mindste i det seneste "Solarwinds attack"  hvor man tog noget der minder om en Ferrie af et stykke malware i udførelse og metodik for til sidst at lave det om til en klovnebil hvor man brugte Cobolt Strike i sidste ende som final payload.

Cobolt strike for fun and profit
Tek har frigivet en rigtig fin blog post hvor han gennemgår hunting efter Cobolt Strike server med JARM. Det er super flot arbejdet i jagten på alle dem der benytter Cobolt Strike server infrastruktur. Det er den type arbejde man burde se mere af derude fra sikkerheds folk. Der er også en kommentar fra Cobolt Strike om dette tool og hvad de syntes.

Alt efter hvordan man ser på dette, så er det helt klart i min optik at man altid kan vende sig til endpointet for at se hvad der sker og hvem der lavede en forbindelse til en JARM identificere hash. Det er helt klart min holdning at man i 99.9% af alle tilfælde altid vil finde noget der ikke burde ske. Så nej JARM er ikke 100% sikker alene, man skal kunne validere hvad der sker på endpoints samtidigt, så gir det altid 100% mening.

Der er frigivet en liste med hvad der allerede nu er identificeret som Cobolt Strike Beacons. Jeg har lave en liste med IP adresser virksomheder kan smide direkte ind i en deny drop liste. Det anbefaler jeg nok man får gjort. DOG er jeg ret overbevist om det sikkert ikke er alle Cobolt Strike Beacons der er blevet identificeret, men det er et stort skridt på vejen...Håber dog på vi snart ser JARM i nmap hvilket kunne være en rigtig god ting.

Cobolt strike for fun and profit
Tek har frigivet en rigtig fin blog post hvor han gennemgår hunting efter Cobolt Strike server med JARM. Det er super flot arbejdet i jagten på alle dem der benytter Cobolt Strike server infrastruktur. Det er den type arbejde man burde se mere af derude fra sikkerheds folk. Der er også en kommentar fra Cobolt Strike om dette tool og hvad de syntes.

Alt efter hvordan man ser på dette, så er det helt klart i min optik at man altid kan vende sig til endpointet for at se hvad der sker og hvem der lavede en forbindelse til en JARM identificere hash. Det er helt klart min holdning at man i 99.9% af alle tilfælde altid vil finde noget der ikke burde ske. Så nej JARM er ikke 100% sikker alene, man skal kunne validere hvad der sker på endpoints samtidigt, så gir det altid 100% mening.

Der er frigivet en liste med hvad der allerede nu er identificeret som Cobolt Strike Beacons. Jeg har lave en liste med IP adresser virksomheder kan smide direkte ind i en deny drop liste. Det anbefaler jeg nok man får gjort. DOG er jeg ret overbevist om det sikkert ikke er alle Cobolt Strike Beacons der er blevet identificeret, men det er et stort skridt på vejen...Håber dog på vi snart ser JARM i nmap hvilket kunne være en rigtig god ting.

 

Nugget Phantom

10 January 2021  - Blog Post # 788

Nugget Phantom
Faldt over noget Nugget Phantom malware, der lige nu er i gang i stor stil via malware kampanger. Det er nok en god ide at være vågen overfor dette malware, da noget har kastet deres kærlighed på det.  Det bliver lige nu spredt med PurpleFOX EK. De forskellige malware sanbox løsninger derude er fyldt med det . Eks
Any run har en del liggende.

Nugget Phantom larmer en del på inficeret maskiner, da det starter eks port scanninger på port 445 efter EternalBlue. Nugget Phantom er et ægte modularized malware toolkit.

IDS detection
Har frigivet generic IDS rules der også burde kunne fange nuværende og kommende kampanger. Det siger jeg ud fra at have analyseret en del kampanger og kun lave IDS rules på det der plejer at skifte. Det kan jo godt skifte alligevel, men har ikke gjort det siden 2016.

 

Update my SMB profile for Wireshark

02 January 2021  - Blog Post # 787

SMB profiles
SMB profilen bringer mange af de ting til live i Wireshark som man normal skal bruge meget tid på at lede efter. Ved at filters allerede er lavet spare man derved meget tid i sin analyse. SMB er nok en af de mest kompliceret protokoller når man snakker analyse i Wireshark. Denne hjælper tit mig en hel del.
 


Kan hentest herfra

Blog posts

Alt hvad jeg har skrevet om igennem 2021