Networkforensic

IDS rule frigivet
Ret præcise IDS rules, der kan spotte alle kampanger fra nu og tilbage i tiden.

Log4j - SNORT IDS detection update

 27 December 2021  - Blog Post # 808

Obfuscation
Log4J CVE-2021-44228 er virkelig noget der går lidt hurtigt i udformninger af attacks. Mange IDS rules kan kun se når der er tale om klar tekst protokoller i selve angrebet. Her trigger de færreste IDS rules når det sker over https. Dog er det noget andet når der er tale om backconnect. Her kan man finde mange ting man kan trigger på.

NCCGroup
De har frigivet en del pcaps med rigtig mange typer attacks. Det har bevirket at jeg har lavet et samlet opdatering af alle de IDS rules jeg selv lavede i starten, da Log4J først blev kendt. Jeg har tilføjet en par stykker og fjernet en del af de gamle, så nu er der 11 IDS rules der dækker hvad der er set derude indtil nu.

IDS Rule frigivet
Log4J - 11 IDS rules. Der kan muligvis være falske positiver, men er ikke pt stødt på nogen. I så flad vil jeg meget gerne høre om det, såfremt det skulle være tilfældet.

Happy hunting og godt nytår.

Log4j - SMTP port

 20 December 2021  - Blog Post # 807

Obfuscation
Log4J CVE-2021-44228 tager hurtigt mange former. Det seneste jeg har set er brugen af obfuscation. Yderligerer ser jeg det nu også benyttet imod SMTP port 25.


Wireshark filter
tcp contains 24:7b:24:7b:3a:3a:2d:6a:7d:6e:64:69:3a

IDS Rule frigivet
Kigger efter den obfuscation der er benyttet. 

Angreb fra et IOT BotNet

 16 December 2021  - Blog Post # 806

BotNet
Lidt skift af taktik. Det er lidt sjovt at se hvordan de prøver at ændre taktik. Meget forsigtigt med et enkelt angreb igennem Iraq. De udvikler med det her eller det bruges af ham der laver botnettet. Et windows tool til brug for wine.

IDS rule opdateret, samt en ny JA3.
Toolet lækker oplysninger ho ho ho.......

JA3 Hash:
455bd65d382d4741f0e48654f27cbe80
 

Angreb fra et IOT BotNet

 10 December 2021  - Blog Post # 805

BotNet angriber
Faldt over en række logs der viser forskellige typer angreb. Password attacks, API jason token attacks og almindelige port scanninger mm.

Angreb
Angreb sker typisk hen imod bl.a. krypteret mailport TCP 465. Typisk ser man kun 1 login forsøg men typisk 3-5 IP adresser der angriber inden for 1-2 minutter efter hianden. Så det er meget "Low and slow" attacks jeg ser, men konstante.

Valideringer
Jeg startede med at opsamle godt 800+ IP'er der ifølge loggen angriber netop mail-test.dk domænet, men på en helt forkert server i virkeligheden. Alle IP'er der har deltaget i angreb, har jeg nmap scannet på en kort række porte. Alle IP adresse har typisk porte 22 SSH åben som er den største synder. Her skal man lige være vågen overfor at jeg "kun" har fundet 800+ IP adresser. Det skyldes at jeg benytter en stor række at GEO blokerings filters, så der er rigtige mange lande, der slet ikke kommer ind i loggen. Så tallet kan i virkeligheden være meget højere.

Systemer er et meget bredt spektrum af IOT udstyr. Som eks herunder (Der findes meget mere)

På rigtig mange af disse der især Dropbear-Ssh i sårbare versioner. Dropbear-Ssh er bla også kendt for i en omskrevet version at målrette energi sektoren, hvor det er BlackEnergy APT gruppen der står bag. Yderligere er CryptoSink malwaren også kendt for at misbruge Dropbear-Ssh. Der findes sikkert flere i rækken. Dropbear-Ssh er dog værd at nævne, fordi det findes i så mange sårbare versioner derude, at det er meget skræmmende. Kan godt forstå at APT/ Crime grupper hopper på dem, når de er lige til at vade ind i.

Et billede af en IOT type af device der deltager i attacks. Denne type billeder har jeg mange af.



Næsten alt dette udstyr har kritiske sårbarheder, default bruger information opsat, der aldrig er skiftet. gamle firmware versioner. Faktisk alt det som rigtig mange IT-Sikkerheds folk advare imod at man gør.

Fælles for dem alle at de indgår i det samme IOT BotNet, da de alle sammen udører det samme angreb imod samme mål. Herunder ses en lille eksempel på et attacks, det kunne også være direkte imod andre brugere, hvor der så ville stå noget med "wrong password"

Eksempel på et attack.


Det ukendte
Jeg er ret overbevist om det er relateret til FritzFrog IOT Botnettet og kan også have relationer til BotenaGo
Det er fordi jeg har set beskrivelser fra begge BotNET med de IOC'er omkring åbne porte, være en del af den valideret IP'liste som jeg har set angribe. JA3 hash passer så på begge BotNET. Men i bund og grund tror jeg det er det samme. Dog anbefaler jeg man kigger på FritzFrog, da det matcher bedst.

Identificering
JA3 Hash der er 100% unik. Det er ikke noget der er set tidligere. JA3 er heller ikke publiceret nogen steder på Internettet som værende noget kendt. JA3 er klart at gå efter da den både kan finde inficeret udstyr samt IP adresser der angriber.

JA3 løsninger anbefalet.
Har man ikke netværks løsninger idag implementeret i sin infrastruktur der kan identificere angreb via JA3 hashing, så har man i mine øjne et gabende hul i sin overvågning. Så den mulighed er klart noget jeg anbefaler man har.

Anbefaling.
Man skal ikke etferlade SSH åben til hele internettet. Slå det fra hvis det ikke bruges. Rigtig meget af det udstyr jeg har set som for det meste er IOT udstyr har default SSH stående åben. Meget SSH køre med gamle versioner helt tilbage fra 2013.

Udfordringen
Det er lagt fra det hele er småt IOT udstyr. Der er også store firewalls blandt fra især en kendt producent. Disse er især kritiske da de i princippet kan give FULD adgang til en hel virksomhed. Den store udfordring med meget af det her udstyr, er at meget af det jo står i private hjem, hvor der ikke er nogen med de rette kompetancer til at få det sat rigtigt op og firmware opdateret. Det bliver også svært for noget rent faktisk at opdage at udstyret er kompromitteret. Det er svært at stoppe et BotNet som dette, uden man totalt overtager hele BotNettet og slår det ned.

Det ville også være fint såfremt IOT udstyr ikke bliver slogt med porte åbne fra WAN siden. Det er så dårlig praksis, og producenter der gør det, burde man måske overveje, om de overhovet har de rigtige kompetancer til at tænke sikkerhed fra starten af.

JA3 Hash
JA3: f17ca639ecdcaa65b4521c49e3515ef9

IP liste med valideret attackers. - (List updated 20-12-2021 - 1840 IP's of IOT attacking bots)
Alle ip adresser i denne liste er valideret som være attackers. Det er typisk IOT udstyr af mange forskellige slags.
Filnavn: RAW-IP-LIST-IOT-BOTNET.zip
SHA1: 95325e453bf44d15e97523b7f749a66ec608e185

PCAP file with an attack
Filnavn: IOT-Attack.zip
SHA1: 0c8b31996bba6c5668292ad111fbedf55199040f

IDS rule frigivet
Denne IDS rule kigger kun på angreb via PORT 465 imod ens netværk. Typisk vil det også kræve at der står et mail-system og modtager disse. Denne vil IKKE fange noget såfremt man selv har inficeret udstyr. Her vil det kræve JA3 HASH. Eller man kan optage noget trafik fra en inficeret hos der deltager i angrebet og sende denne til mig. Så vil jeg med glæde lave en IDS rule der finder inficeret udstyr.

HPE Integrated Lights-Out 4 (iLO 4)

 21 Oktober 2021  - Blog Post # 804

iLO    
iLO er velkendt. Det er bygget til remote management i server systemer fra HP. Så man kan eks starte en sever der er slukket. Det er basalt set en ekstra server i serveren, der er forbundet via netværk. Det giver mange muligheder i sig selv. Eks en remote shell direkte til hardwaren på serveren, eller muligheder for at mounte forskellige medietyper som ISO filer, DVD drev, loade forskellige image typer osv. Alt i alt et MEGET kraftfuldt værktøj.

Forskellige producenter af hardware har typisk deres egen løsninger og der er mange forskellige af dem. Jeg har selv her tidligere omtalt eks vPRO. Det er meget brugbare tools, såfremt man håndtere dem rigtigt.

Management netværk
Det er ikke uden grund at producenterne typisk anbefaler at remote management af hardware typisk kun er anbefalet fra et oprettet netværk UDEN internet forbindelser. Man skal derfor ikke forbinde sit remote management netværk med resten af virksomheden heller ikke til jumphosts. Det vil typipsk kræve at man har en fysisk klient der er placeret et sted i virksomheden og fra denne kan man tilgå netværket der giver adgang til al hardwaren. (Ikke noget remote hen til management klienten. Ja det betyder man skal være fysisk tilstede for at foretage management af hardware i eks et serverrum.




Jeg har hørt mange undskyldinger for at man gerne vil kunne tilgå det fra internettet via jumphost. Men den går ikke... det skal være et lukket netværk der er sepperat oprettet med egne switches osv. Det er ikke nok med VLAN's på samme netværk der benytter samme switches som alt muligt andet. Det er NO GO.  Gør man det alligevel skal man nok overveje hvilken jobtitle man har, for der bør ikke stå noget med IT-Sikkerhed i den.

Scanning efter iLO
Man kan foretage scanninger efter iLO i sit eget netværk for at identificere ubeskyttet iLO adgange med eks nmap

Patchninger og sårbarheds scanninger
iLO skal scannes og patches ligesom alt andet udstyr. Men jeg ser desværre typisk at mange helt overset denne type adgange i deres egne netværk. Der findes typisk slet ikke nogen processer for håndteringer af disse eller noget ansvar der er tildelt. Det kører i mange tilfælde i sin helt egen uovervåget verden. Man skal heller ikke tror at at bare fordi man benytte forskellige cloud servises så er man beskyttet. Jeg har også set cloud producenter der kommer til at forbinde til forkerte netværk når patch kablerne sættes i switches. 

Ransomware og iLO
Det er bestemt ikke noget nyt med ransomware og krypteret diske på hele hardware systemer. Derfor bør nok være endnu mere efter det.

"Indicators"
Jeg har her frigivet lidt Indicators på at identificere iLO der kan være ubeskytte eller placeret forkert. De er lavet på en default opsat iLO 4. Jeg vil tro de også passer på andre versioner. (Siger samtidigt tak for lån af hardware jeg fik lov til at teste på)
 
DHCP server logs
ILOCZ1723015T\x00 - Søg efter hvor ILO indgår i hostnavnet. Typisk default navne for ILO.

Kibana
certificate_common_name: ILO*
uri.keyword:"/html/IRC.exe.manifest"

Agent Server respons: 303 See Other
Server: HPE-iLO-Server/

JA3S - Security Onion
HPE-iLO-Server/1.30 (Server) HTTPS
JA3S: 8863a99fb3623e273eec49e5e7037422

HASSH - Security Onion
SSH-2.0-mpSSH_0.2.1 (server)
HASSH:0df9d9433854fd68eb358a41df3335ae

Port scanninger (namp)
namp -p 22,80,443,17988,17990 -T4 -A -v <ip range>

Syslog Messages (Tilføjet: 27-10-2021)
Made for iLO 4 - Firmware Version 2.78
Syslog.txt

IDS rules frigivet
De trigger uden falkse positiver. Dog har jeg ikke fremstillet noget til Virtual Media porten. Den lånte hardware var desværre uden licens. Det er krævet for at kunne benytte denne funktion. Dog afventer jeg en system med iLO 5 og hvor licenser er i orden. Mere herom til den tid.

Vær opmærksom at porte skal være sat rigtigt i forhold hvor du gerne vil identificere iLO.  I IDS reglen. NF - HPE-iLO - Remote Console activated - sid:5027803; er det især vigtigt. Her skal man benytte port nummeret som en del af IDS reglen. Ellers vi den sikkert sprøjte mange falske positiver ud. Her skal man bare omplacere porten i IDS reglen.

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.