Networkforensic
Threat hunting
Bluetooth loging and Backdoors
11 Oktober 2025 - Blog Post # 877
Bluetooth
I mange år har der været fokus omkring USB enheder og man skal passe
på med hvad man tillader der bliver stukket i ens PC'er. De fleste
EDR værktøjer og OS's har i dag implementeret lognings muligheder så
man kan se eller blokere for USB enheder man ikke vil tillade. De
fleste PC'er, Mac og Linux maskiner kommer i dag på hardware producenter med indbygget Bluetooth.
I forbindelse med en hændelse og fundet af en USB dongle et
sted hvor den ikke burde blive fundet eller nok ville hvor det er et
ret
unormalt sted at finde den slags liggende på gulvet, samt jeg
samtidigt selv havde lidt udfordringer med et Bose Bluetooh headset
i Windows 11 blev jeg ret
inspireret i Bluetooth logning på Windows systemer og via netværks
trafik... For hvor meget kan man egenteligt se via logning og
netværkstrafik og hvad ville jeg lige kunne bruge Bluetooth til ?
Efter en rum tid's søgninger i Windows log systemet blev jeg hurtigt
klar over at der faktisk ikke findes ret meget til at kigge efter
Bluetooth logs.
Mobile Hotspots via Bluetooth
Efter lidt kiggen rundt på Internettet efter interresante ting jeg
kunne bruge for at få lavet Sysmon logning på til Bluetooth, faldt jeg
over Mobile Hotspots via Bluetooth. Det kan opsættes ved at man laver en ICSharing
og ikke via normal Wireless som det fleste nok ville gøre, men at
opsætte det via Bluetooth.
Man deler sin Internet forbindelse via
Bluetooth med andre og her er det altså hele forbindelse der bliver
delt. Allerede her begyndet min tanker at få meget
frit spil, for hvad kan jeg mon bruge det til ?
Mobile hotspot opsat via Bluetooth
Deling giver adgang
Når man deler sin Internet forbindelse med andre, så kan andre jo
benytte den forbindelse man nu har og i mit tilfælde opsatte jeg
det, så
det vil svare til at min PC sad på det indterne corp netværk. Her
tog jeg så en PC "unden" forbindelse til internettet. og forbandt
den med det oprettet Mobile Hotspot, der sad på det indterne netværk. Man tror fejlagtigt
at data strøm til og fra ville være ret langsom, men det er altså
ikke helt tilfældet. Det køre ganske fint.
Bypass EDR og AV værktøjer så let som ingenting
Ved at jeg kan forbinde en "fremmede test pc" direkte ind på det
indterne netværk eller det som mange kalder for corp netnærket, så
får man altså ret mange problemer meget hurtigt. For lige at nævne
et par stykker. Fuld bypass af Anti-virus, EDR værktøjer. For den
fremmede maskine er der ikke kontrol med, men den får fuld adgang
ind med alle de værktøjer der nu engang ligger på denne.
(Pen-tester's burde elske dette hvis ICSharing er tilladt). Fra den
fremmede maskine og fordi alt ryger igennem en maskine på det
trusted netværk, så er det temmelig sikkert at denne
kan bypasse mange typer indterne firewall regler og i et hvist
omfang bypasse IDS systemer mm.
For at gøre det lidt mere sjovt tilføjede jeg et 5G modem på min
"fremmede test pc" hvilket nu betød at jeg kunne kontrollere
min pc fra Internettet via TeamViewer med GUI adgang. Man kunne også
nøjes med en simpel SSH adgang, hvilket jeg også fik testet og som
også virker fint..
Udfordring er at man ikke meget via et SIEM, Windows logs, EDR
værktøjer eller IDS systemer får meget at gå efter. Jeg har ikke i
min tid som analytikker kunne mindes at det er noget jeg har jagtet.
Alt bliver gemt bag en maskine der er tilladt, som ikke giver EDR
alerts, ingen AV alerts og som kan holde al sin trafik bag en
trustet maskine.
Jeg testede en simuleret Jumphost som fik opsat et Mobile hotspot
via Bluetooth. Da der ikke fantes Bluetooth på denne tilføjede jeg
en Bluetooth dogle som ikke krævede et ekstra setup af drivers. Her
ville den kunne blive fundet via USB logning. Når det køre er jeg jo
kommet på og kunne forbinde mig til systemer som kun tillader trafik
specifikt fra Jumphosten og derved bypasse indterne firewall regler
mm.
Derudover kræver det ikke admin rettigheder at opsætte ICSharing via
Bluetooth. Det kræver dog man godkender en paring med kode imellem 2
enheder. Om opsætningen det kan gøres med en
Flipper Zero
eller
Rubber Ducky tænker jeg burde kunne lade sig gøre og er da også
noget jeg lige skal prøve.
BLE Hero
Kan nævne at jeg selv i forbindelse med denne test gjorde stor brug
af
BLE Hero på en IPhone til at scanne efter Bluetooth signaler.
Her er det også muligt at få en ide om hvem der skaber meget
Bluettoth radio trafik og muligt også hvem der snakker meget med
hvem.
Wireshark Capture
Før jeg overhovedet kunne begynde at kigge efter IOC'er jeg kunne
benytte til Sysmon detection måtte jeg klargøre Wireshark så jeg
kunne se Bluetooth trafik der gik til hosten med ICSharing opsat.
Det var faktisk den eneste måde jeg lige kunne benytte. Ellers hvis
man bare går til en capture via lan interfacet (Wireless) så ser man
faktisk kun det er ens host med de almindelige IP adresser der laver
forbindelser til alt muligt på det indterne corp netværk. Man ser
ikke det kommer ind via Bluetooth..
Man skal muligvis benytte
USBpcap drivers, såfremt man tester på noget
Bluetooth over en USB dongle.
Mitigeringer
Der er flere måder man kan mitigere denne trussel væk på.
- Disable Bluetooth i BIOS (Primært servers) - Husk man bare kan
tilføje en Bluetoorh USB Dongle på en system derved vil det ikke
have hjulpet at disable Bluetoorh i BIOS.
- Set GPO'er - Tillad ikke ICSharing - "Prohibit access to Control
Panel and PC Settings"
- Disable alle Bluetooth service på systemer. Vil kræve admin adgang
at få disse aktive igen
- Forhindre USB installationer af nye Bluetooth enheder. Her skal
man benytte USB Calsses.
- Tjek server rum og andet for uønsket Bluetooth signaler og
undersøg hvis noget giver signal hists
- Forhindre fysisk adgang til især servers og andre kritiske
systemer.
- Kig aktivt efter logs i SIEM der hvor der bliver benytte ICSharing
og hvor der installeres USB enehder.
Sysmon Detection
Alle detections herunder er kun nogen man finder i den
publiceret Sysmon config fil. Her
skal man søge efter Rule names i sit SIEM system.
Men man har virkelig brug for detections, der kan holde øje med hvad
der sker i registreringsdatabasen og muligheden for at skrive sine
egene detections og Sysmon er jo "gratis"
- technique_id=T1052,technique_name=Limit Hardware Installation -
USB
- technique_id=T1052,technique_name=Limit Hardware Installation -
USBSTOR
- technique_id=T1011.001,technique_name=Exfiltration Over Bluetooth
- Paired devices MAC Address - Watch Servers
- technique_id=T1011.001,technique_name=Exfiltration Over Bluetooth
- Paired Bluetooth devices MAC addresses - Local and remote MAC
address
- technique_id=T1016,technique_name=Network Configuration Discovery
- IPv4
Windows Event log detection
System - Event ID 8 - The remote adapter (xx:xx:xx:xx:xx:xx)
successfully paired with the local adapter
SIEM
Man har brug for at kunne lave alerting via et SIEM system som
Elastic eller Splunk. Med Sysmon har man nu en rigtig god chance
for at finde Mobile Hotspots på systemer. En god ide er at lave
"Count" på paired devices via BTHUSB
Network IDS Detection
Her vil det kun trigger såfremt at hosten sender trafik igennem den
delte Mobile Hotspot hvis det går igennem ens IDS System. Det kommer
virkelig an på hvordan man bruger sit IDS/IPS og hvilke regler man
benytter sig af.
Ellers vil det meste sikkert
ligne almindelig trafik som bliver foretaget af en host. Skulle
hosten trigger, vil det kræve at man kan finde delte Mobile Hotspots
på hosten og her kan netværks trafikken virke som sprængbræt
til en undersøgelse af en given host.
Et eksempel kunne være at man syntes det er en god ide at bruge en
Linux / Mac host i et rent MS miljø. AL trafik fra den fremmede test
maskine vil rende igennem en Windows host. Når en Windows host
begynder at snakke som en Linux eller en Mac så vil det naturligt
rejse lidt mistanke.
Note
Derudover så jeg at Windows 11 typisk benytter følgende IP range til
oprettelse af en lokal DHCP server og IP adresser til hosts som
forbinder sig over Bluetooth. Der kan være andre ip ranges, men det
er et godt sted at starte.
192.168.138.0/24
Opsumering
Tillader man ICSharing, bør man få slået dette fra alle
steder. Det kan være en farlig ting har have kørende på sine
systemer.
Det er også mange forudsætninger jeg ikke rigtig tager højde
for her. Eks kræver det en bruger adgang til et system for at
tilføje et Mobile Hotspot. Det kræver paring af koder for at tilføje
en anden til ens PAN. Men er der brugeradgang er det ingen hindring.
Skal man på en Jumphost som her var lidt et tænkt eksempel, er der typisk flere udfordringer såfremt man
har foretaget hardning på disse. Det er nok ikke muigt uden man
kan blive opdaget på mange måder. Man skal også være i nærhenden af
et system eller have adgang til server rum mm. Dog benytter mange
slet ikke sikret serverrum eller sætter serverudstyr i ulåste rack
skabe. Det er især en udfordring hos mange mindre virksomheder.
Så uanset hvad vil det i et eller andet omfang kræve adgang til
lokationer, eller at man kan fange en laptop uden for sin lokation
på en kaffebar eller ligende og få placeret en config af Bluetooth.
Man kan være forhindret af USB blokeringer, forhindret driver
installationer som typisk kræver admin rettigheder.
Næsten alle laptops systemer i dag har indbygget Bluetooth og typisk
bliver disse meget benyttet og sjældent slået fra, det sammenholdt
med at mange brugerer sjældent tænker over aktivt Bluetooth så er
det lidt en farlig kombi. Testede et almindeligt kontormiljø og
fandt 173 aktive Bluetooth enheder på få sekunder, så det vil være
svært at lige at finde en enhed der ikke burde være der.
Desuden kan der på mange systemer i dag installeres eSIM og
forskellige SIM Cards med modems der kan hjælpe en angriber med at
få placeret bagdøren i et miljø så der kommer fin fjern adgang til
systemerne.
Jeg kan selv finde mange senarier hvor denne form for adgang, bare ville
være gud at have kørende og det her behøver slet ikke ligge på en
Jumphost. Det var bare for eksemplets skyld. Der kan være rigtig
mange anvendelses muligehder som jeg ikke engang kan forestille mig.
Men er man "Pen-Tester" og sidder og skal teste en infrastruktur og
bøvler med blokeret værktøjer og ICSharing er tilladet, så er det
her
drømme vejen ind...
NTLM auditing enhancements
25 August 2025 - Blog Post # 876
Windows 11 24H2 og Server 2025 NTLM
enhanced loging
I den seneste opdatering til Windows 11 24H2 har Microsoft tilføjet
en ny form for NTLM enhanced logning.
Det er sket i forbindelse med udfasning af protokoller
som NTLMv2, NTML og LAN Manager.
Det har de gjort så IT-Teams kan finde systemer der benytter sig af
gamle protokoller, men det giver samtidigt IT-Sikkerheds teams
muligheden for virkelig at følge med i de sikkerheds relateret
afspekter i brugen af disse legasy protokoller og som er protokoller der
typisk bliver misbrugt på mange måder og man bør undgå. Den
giver desuden et fint overblik over hvilke applikationer man har, som
stadig gør brug af de gamle protokoller og hjælper derved med at få
identificeret gamle applikationer der trænger til en udfasning.
Wireshark
Jeg har selv lavet Wireshark profiler, kun for at man kan forstå hvad
der sker i protokollen når det bruges sammen med SMB. Det er
faktisk den meste komplekse protokol der findes i dag og er den når
man kigger på standarden også den der fylder mest. Men Microsoft
jagter nu dens endeligt... og så vidt jeg husker rigtig så bliver
det hele erstattet med QUICK protokollen. Det må siges at være et
kæmpe skridt i den rigtig retning.
Man kan læse mere om hele frigivelsen hos
Microsoft her
Logning og implementering.
For at lave hele opsætning rigtig i Windows kan man med fordel
benytte
denne reg fil på alle ens klienter:
Ikke servers. Der skal man selv lige tilføje "domain-wide logging"
til reg filen da det typisk skal ligge på DC / servers. Dog er denne enabled som default og regfilen
tilsikre bare at logningen blier sat til enabled. Den sætter også en række andre nødvendige ting,
for at lave den rigtige log opsamling på Windows som typisk ikke er
enabled som default.
Dog er det nok bare at sætte følgende GPO til enabled.
Til Winlogbeat skal følgende tilføjes i winlogbeat.yml:
- name:
Microsoft-Windows-NTLM/Operational
Nye event ID numre
De nye event ID numre man skal indsamle og kigge på er følgende:
For klienter:
4020 (Information), 4021 (Warning)
4014 - Attempt to get credential key by
call package blocked by Credential Guard.
4001 Blocked NTLM request outbound 4001 (Warning)
8001 NTLM client blocked audit: Audit outgoing NTLM authentication
traffic that would be blocked. (Alert)
For Server/ DC:
4032 (Information), 4033 (Warning)
4114 (Information), 4031 (Warning)
GPO'er
Det gør også at man kan opsætte mere sikre Group Policys omkring
hvilke systemer man må tilgå med disse protokoller.
Sørg for at DENY alt outbound.
Tilføj dine undtagelser. Husk at ligger en DNS navne på en
undtaget ip skal man tilføje DNS navnet alligevel.
Note:
I forbindelse med test af det her, stødte jeg på et lidt underligt
problem der gav en del timer for at få det til at virke efter
hensigten. Så inden man lige tilføjer det her, bør man lige
kigge på denne fra
Microsoft som er relateret til Credential Guard som gav mig
rigtig meget bøvl på en maskine jeg endte med at måtte reinstallere
på ny. Så vær opmærksom på at Credential Guard kan drille.
Det hjalp iøvrigt ikke noget at slå Credential Guard fra. Man vil
desuden også se at der kun kommer Event ID 4014
level "Error"
"Attempt to get credential key by call package blocked by
Credential Guard.
Måske det er hensigten, pt ved jeg det ikke.
Eksempler på fejl man bør kigge efter kan være følgende, TIME ude af sync,
DNS navne/ host navne mismatch, Eller en der drillede mig en del var
"Restrict NTLM: Add remote server exceptions for NTLM
authentication" hvor der kun var tilføjet IP adresser / IP ranges og
hvor jeg manglede at tilføje DNS navnet. Men alle var ting jeg fik
gennemgået og verificeret i forbindelse med Enhanced NTLM logning.
En ting man også skal huske på er at NTLM generalt kan benyttes
imellem mange former for protokoller og ikke kun til SMB og RDP.
For at lære en del om protokoller og fejlkoder i NTLM kan jeg
anbefale dette link til
Windows Protocols
Hardened UNC Paths
En sidste ting jeg kan anbefale når der er tale om AD, er brugen af
Hardened UNC Paths. Dette virker ikke på standalone systemer.
Jeg kan klart anbefale man gør brug af det.
Sysmon
Da en angriber der opnår admin rettigheder kan ændre i registry, har
jeg tilføjet detection af forsøg på tampering af disse.
IIS logning med Sysmon og Windows ETW
28 Juli 2025 - Blog Post # 875
SharePoint Exploits
Har på opfordring gennemgået hvad der skal til for at få opsat
Windows logning fra IIS Web-servers sammen med Sysmon
logning samt at få det sendt til et SIEM. Dette skal ses i relation
til de seneste SharePoint Exploits der er i omløb og som bliver
udnyttet aktivt.
Man skulle tro at de fleste som benytter on-prem SharePoint kun gør det
fra til virksomheds servers.
Men udfordringen er at flere også har udviklere der tester
SharePoint og endnu flere der lige har brug for en lokal web-server
til anden test formål. Dette bliver typisk kørt fra deres egene
maskiner eller udvikler systemer. Man vil narturligvis være sikker på at
logning fra disse systemer også bliver opsat med logning.
En hacker
der allerede er kommet ind kan udnytte test systemer, da der ofte ikke er samme fokus/kontrol
sikkerhhed i disse. Vi har igennem tiden set et utal af test
systemer blive udnyttet på forskellig vis og hvor angriberne i høj
grad udnytte denne type systemer.
Der har de
senetse par uger været meget fokus på SharePoint og de exploits
der aktivt bliver udnyttet.
CVE-2025-53770,
CVE-2025-53771,
CVE-2025-49704, og
CVE-2025-49706. Igennem mit job har jeg selv set hvordan fokus
på disse bare er tiltaget kraftigt. Scanninger og tiltagende forsøg
på exploit må siges at være i kraftig vækst.
Der er en stor udfordring at mange slet ikke har opsat korrekt
logning således at efterfølgende Shells og bagdøre kan blive
opdaget. Jeg vil her gennemgå noget målrettet logning i forhold til
logning på en IIS web-server som typisk er overset, man kan gøre
brug af.
Microsoft anbefaler yderligere logning bliver opsat i relation
til netop SharePoint exploits.
Windows IIS Logning.
På sin IIS server skal man have fokus på at logning er slået til.
IIS serveren kan logge på 2 måder. Endten igennem ETW eller til
logfiler og dem begge samtidigt. Jeg benytter i dette tilfælde dem
begge. Det kommer lidt an på på hvad de skal bruges til og hvilket
system der skal gøre brug af disse logs.
Internet Information Servicee IIS Manager
På sin IIS manager kan man endten gøre det, så alle web-sites på en
IIS server bliver opsat ens eller pr web-site. Jeg vælger altid at
gøre det generalt for alle. Normalt ville jeg opsætte et disk drive
kun til logfiler. Det her dog kun for at vise hvor man lige opsætter
sin log så den bliver aktiv.
Vælg localhost i din ISS manager - Vælg Logging
Vælg Log Event Destination - Both log file and ETW event. Log gerne
til et sepperat diskdrive. Sørg for at rettigheder til dette bliver
meget begrænset. På meget travle systemer vill jeg opsætte kun
logfiler og opsamle disse med
Filebeat fra Elastic.
Opsæt logning i selve Windows
For at opsætte
den nødvendige logning skal man aktivere IIS logs så de bliver aktive i
Windows Event Viewer, for de er det default ikke aktive. Til dette
formål har jeg oprettet en reg fil der med fordel kan benyttes. Dette
kræver genstart af systemet. Logs bliver nu sendt til Windows Event
Viewer og til logfiler. De 2 der som min er brug for er
configuration Operational og logs. Operational giver os alle
ændringer der sker i en ISS server af konfigurationer og logs er
alle der der tilgår de web-sites der måtte ligge på web-serveren.
Begge er helt centrale og vigtige logs at indsamle fra ISS
web-servers.
Event ID 6200 fra ISS-Logging, viser eks alle der besøger ens web-site. Loggen her
bliver opsamlet med Winlogbeat fra ETW og sendt til Elastic med
Winlogbeat.
Event ID 29 viser hvilke ændringer der bliver lavet i en ISS
Web-server.
Der er brug for 2 ændringer.
(Reg fil
pakket i zip)
Microsoft-IIS-Configuration/Operational
Microsoft-IIS-Logging/Logs
Winlogbeat
Da jeg benytter Elastic har jeg brug for at tilføje disse to linjer
til min winlogbeat.yml. Dette er en af config filerne til
Winlogbeat Det sørger for at logfiler nu bliver indsamlet med
Winlogbeat fra Windows ETW og sendt til Elastic.
Under Winlogbeat specific options -> winlogbeat.event_logs: tilføj
disse 2 linjer.
- name:
Microsoft-IIS-Configuration/Operational
- name: Microsoft-IIS-Logging/Logs
Genstart Winlogbeat service
Sysmon opsætning.
Jeg går ud fra at man allerede benytter Sysmon. Fra config 100 er
der målrettet overvågning af w3wp.exe. Hent seneste config 100 og
opdater sysmon config.
Denne kan hentes herfra hvor jeg har tilføjet overvågning af
w3wp.exe til Event_ID 1 og 7. Dette giver mulighed for at se
process start, samt DLL loading hvor w3wp.exe benyttes til at loade
eks dll filer mm som kunne være bagdøre på ens ISS server. Dette kan i høj grad også spotte når
SharePoint exploites og en dll fil som er en bagdør / Shell osv.
Følgende detections er tilføjet til min sysmon config fil.
technique_id=T1505.004,technique_name=Server Software Component -
IIS Components w3wp.exe.
Vær opmærksom på følgende. Test maskiner og test web-servers
skal have opsat sin logning korrekt samt have Sysmon installeret med
en fungerende Winlogbeat.
DNS4EU
07 Juli 2025 - Blog Post # 874
DNS4EU et
projekt jeg varmt kan anbefale
Mange benytter i dag Google DNS, Cloudflare DNS, Quad9 osv... Men
det her projekt hvor data bliver i EU er mere min kop te end man
sender alt afsted til eks verdens største marketings firma.
Tracking
Noget der eks har fået mig til at koge lidt længe er eks Googles og
andres brug af DNS ECS.
Det betyder meget kort at man kan sende sin indterne IP adresser afsted til
google som giver den videre til en eventuel angriber. Det betyder
også at hvis en attacker opretter sin egen NS service og benytter
DNS ECS så får en attacker også ens indterne IP adresse. Så kan de
jo rigtigt holde øje med deres attacks og hvem de rammer. Det har
virkelig fået mit hovede til at koge i lang tid. For ting som
Phishing kampanger mm er fuldt supporteret med brugen af DNS ECS. Så
selvom DNS ECS skulle være en hastigheds optmerings ting, så har det
altså også nogen privacy bekymringer.
GDPR, Malware test
Om DNS4EU er DNS ECS
understøttet, ved jeg faktisk ikke pt. Dog har jeg testet en hel del kendte malware domæner, der alle
lader til at blive blokeret. Malware domæner er noget jeg ser
igennem mit daglige job hele tiden, Så det må siges at være de nyeste
jeg render på, som jeg så kan teste imod. Her er jeg slet ikke
utilfreds. Desuden er det hele underlagt GDPR, så alt bliver inden
for EU, hvilket er meget fint.
Svartider og opsætning
Jeg har fået meget hurtige svar tider på min DNS, hvilket jeg er
meget tilfreds med, Sammenlagt har jeg måtte bruge ca 30 min på
omlægnig fra Google DNS til DNS4EU det er vel og mærket på 2
forskellige netværk. Det skyldes nok også at jeg i forvejen har en
stram politik omkring DNS i mit eget miljø. Så det er faktisk kun 3
steder det skulle skiftes ip adresser, som er på to SPLITDNS
løsninger fra
Nxfilter og en enkelt firewall fra
PfSense der
skal bruge sin egen eksterne DNS ip.
Consortium
Det er bestemt heller ikke ukendte der er med i dette projekt som
bla tæller
F-Secure,
Whalebone, CZ.NIC,
med flere.
Her er jeg heller ikke utilfreds med dem der indgår i dette. Som
allesammen er stærke inden for deres områder.
Protective resolution with ad-blocking
Lige nu tester jeg selv "Protective resolution with ad-blocking"
løsningen som er deres public løsning, der er forskellige man kan
benytte hos dem. Sågar en Unfiltered public løsning. Men der er også
løsninger til bla, Governments, Telcos, og CERT, CSIRT og NCSC
teams. Til CERT teams er denne indbefatte Threat intelligence.
Det super fede er at de understøtter direkte
DNS over HTTPS,
DNS over TLS som passer direkte ind i NxFilter. På den måde kan man
styre at alle ens DNS opslag bliver krypteret ud imod deres løsning.
Der findes forskellige løsninger på DNS4EU hjemmeside man kan gøre
brug af.
https://www.joindns4.eu/for-public
Så de oplysning man bare skal brug til den public løsning jeg tester
er følgende som også passer direkte ind i Nxfilter.
IP address
IPv6
DNS over HTTPS
DNS over TLS
86.54.11.13
2a13:1001::86:54:11:13
https://noads.joindns4.eu/dns-query
noads.joindns4.eu
86.54.11.213
2a13:1001::86:54:11:213
CVE-2025-24054 - NTLM exploit
12 April 2025 - Blog Post # 873
CVE-2025-24054 - NTLM Hash Disclosure Spoofing Vulnerability
Dette misbruges aktivt på flere forskellige måder via e-mail. Det er
som URL's i mail til en fil fra eks et SMB share eller som vedhæftet
filer i mail endten pakket i ZIP eller som upakket filer. Den sidste
er rigtig slem fordi modtageren bare behøver at klikke en gang på
filen og så er stor risiko for at det kan gå meget galt.
Check point research har et rigtig godt write på de ondsindet
kampanger, jag kan anbefale man læser igennem.
Mail-test
Jeg har testet en del mail systemer, og ALLE sammen tillader default
filer med extension
.library-ms. Jeg anbefaler kraftigt at denne extension typer
bliver droppet på alle mail-systemer.
Eksempel fra O365
Yderligere anbefalinger
Benyt outboud firewall regler der dropper al outboud SMB trafik til
ikke "trusted" IP adresser eller domæner.
Patch
Sørg for at få patches alle systemer med CVE-2025-24054, da denne
kan få stor Impact.
GPO blokeringer
Man kan via GPO i AD tilføje restrektioner på outbound SMB ntlmv2
valideringer.
"Network Security: Restrict NTLM: Outgouing NTLM traffic to remote
servers" og sæt denne til endten "Audit all" eller "Deny all"
Benyttes "Deny all" kan dette styres yderligere, således at man får
trusted IP adresser hvortil ntlmv2 valideringer vil virker. Man vil
med dette tiltag sikre fremadrettet angreb der forsøger denne form
angreb.
"Network security: Restrict NTLM: Add remote server exceptions for
NTLM authentication".
Sysmon
I min frigivet sysmon config kan man kigge efter følgende 2 events
der fint afsløre misbrug af
library-ms.
Her kan man finde de oprettet filer med
library-ms. extensions og man kan se hvis der benyttes eks
web-mail og en bruger klikker på filen og denne bliver hentet ned
til systemet.
Event ID 11
technique_id=TA0008,technique_name=Lateral Movement - Windows
Library Description File Created
Event ID 15
technique_id=T1553.005,technique_name=Mark of the Web Bypass files
Sysmon config 84 er krævet.
Signed Binary Proxy Execution - JetBrains
1 April 2025 - Blog Post # 872
Python IDE
Er faldet over en ny
ukendt LOLBIN der via JetBrains kan bruges i forbindelse med
"Signed Binary Proxy Execution" og udnøttes af Russian Hackers i
forbindelse med
SilentPrism og DarkWisp. Det sker bl.a via signeret MSI og MSC
filer.
Gruppen
Water Gamayun APT (Russisk APT aktør) står bag disse angreb. I
denne forbindelse benytter de en ny LOLBIN fra JetBrains install dir
til deploy af bl.a
SilentPrism. Dette sker igennem
CVE-2025-26633
Kigger man på LOLBIN filerne fra
JetBrains så var det rimelig hurtig at oprette Sysmon detection
ti disse. Dette ligger nu i Sysmon config 81.
Dog er disse filer helt legale filer som det ofte er med LOLBIN
filer
Happy hunting.....
Mirai exploit angreb med spoofet IP adresser
15 Februar 2025 - Blog Post # 871
Mirai Botnet
Mirai er et
efterhånden velkendt botnet. Det går
typisk efter IOT enheder der kommer med defaulte passwords fra de
forskellige producenter. Det udviklende sig til konstante scanninger
af Internettet til de i dag exploiter dårlige ubeskyttet enheder
rundt om på Internettet. Det bruges ofte i forbindelse med de
største DDOS angreb man ser på Internettet. De er desuden kendt for
at være "gode" til virkelig at udnytte hvad et Botnet rent fakstik
kan gøre af uønsket ting imod virksomheder, regeringer og meget
meget mere.
Mirai Varianter
Netop fordi mange hackere så hvor stor en succes dette Mirai havde
med at oprette / udvide sit botnet kun ved at logge ind på IOT
enheder, og derved gøre dem til en del af sit botnet, blev der
hurtigt set
flere varianter af Mirai.
GEO blokeringer
Sådan som Internettet efterhånden har udviklet sig, hvor scanninger,
bruteforce angreb, exploit angreb mm. i dag er den angrebs type, vi
ser mest af i dag på Internettet, så er det også noget alle i dag
bliver udsat for. Derfor begyndte mange at tilføje
GEO blokeringer på firewalls for kun at tillade eks. Danske IP
adresser i at kunne tilgå de servises man har åben imod Internettet
for at begrænse de mange angreb. Det kunne være adgang for de
ansatte til en mail-server, til virksomhedens hjemmeside eller eks
for dem der skal arbejde hjemmefra og som tilgår virksomheden via
VPN løsninger. Der kan være mange eksempler.
Angriberen
Det betyder jo at dem der ønsker at angribe en service, nu er
tvunget til eks at komme fra eks. Danske IP adresser eller bare fra
IP adresser som et GEO filter der er opsat, ikke dækker. GEO
blokeringer giver derfor hurtigt mening i mange tilfælde og fjerner
meget støj. Det er typisk en udfordring at spoofe netop TCP pakker
på den danske del af Internettet, mange ISP'er er heldigvis kommet
med og det er blevet generalt svært i dag at spoofe via TCP på det
meste af Internettet.
Men UDP protokollen kan typisk benyttes og er MEGET nem at spoofe,
det ved næsten alle hackere og IT-Sikkerheds folk i dag. Det er
netop derfor at vi bl.a. ser DDOS angreb virker så godt som det gør,
da dette typisk er UDP basseret trafik og impact er næsten altid
stor.
Men det gælder for GEO blokering, at man kan beskytte sin IP adresse
ved at sige at UDP pakker kun kan komme fra danske IP adresser.
Eller kan man....
Angreb imod UDP basseret service
Der
findes mange service typer åbne i dag som beror på netop UDP.
Det kan være DNS, SNMP, Ike, NTP og meget mere. Mange bruger eks
Internet Key Exchange (IKE) som
en del af deres VPN løsninge og som er UDP basseret. Den ligger
typisk på UDP port 500. Men hvad nu hvis en angriber spoofer en
danske IP adresse som afsender af data pakken, så vil ens GEO
blokering jo ikke virke, da GEO blokerings filteret tror at data
pakken kommer fra en dansk IP adresse.
Spoofet angreb imod Ike
I julen 2024 så jeg netop angreb imod Zyxel enheder hvor afsender IP
adressen var 1.1.1.1 og 8.8.8.8. Disse angreb ser jeg stadig
forekomme i dag. Man tror med det samme der er tale om DNS, hvilket
bestemt ikke er tilfældet, når man kigger ned i data pakkerne.
Krav til angreb
I alle de tilfælde hvor et exploit kan passe ned i 1 data pakke som
er UDP basseret og kan sendes imod mål fra "trusted" spoofed IP
adresser og hvor der sker en back connect til yderligere payloads
fra samme data pakke, så vil meget beskyttelse som GEO blokering
have ringe effekt. Det her er super nyttigt for at angriber. En
angriber behøver ikke afsløre sin afsender IP adresse og risikere at
den del bliver taget ned og der kan angribes uden om GEO blokering.
Zyxel angrebet
Tilbage i Maj 2023 blev netop Zyxel angrebet med en 0-day exploit
der var målrettet Ike port 500. Mange røg ned på den konto, herunder
kritisk infrastruktur i Danmark. Netop dette angreb opfylder de krav
til at et angreb med spoofet IP adresser og at angrebet passer ned i
1 data pakke, det er netop det vi ser nu.
I de nuværende angreb kommer data pakkerne med spoofet IP adresser
fra Google og Cloudflare DNS tjenester som rigtig mange benytter.
Men det kunne meget vel være eks TDC's velkendte DNS tjeneste og
derved danske IP adresser. Det ville betyder at eks. en angriber
ikke længere behøver at tage GEO blokering i betragtning, så længe
at det er et angreb kan være i 1 data pakke via UDP og hvor
backconnect kan ligge i samme data pakke som det var tilfældet med
Zyxel.
Jeg ved ikke hvor mange angrebs typer der i dag opfylder disse krav.
Jeg ved kun, at jeg ser denne metodik netop nu og jeg ser også, at
selvom det er 1.1.1.1 og 8.8.8.8, så blæser de her data pakker
direkte ind til deres mål og rammer hver gang. Jeg vil tror det er
dårligt opsatte GEO filters, eller slet ingen. Yderligere ved jeg at
data pakkerne ikke indeholder det samme data som vi så tilbage ved
angrebet der skete i maj 2023. Der kan derfor være tale om nye
exploit forsøg rettet imod Zyxel produkter. Jeg har dog ikke set
nogen vellykket angreb pt med denne angrebs type og de nye data
pakker. Jeg kan derfor heller ikke afgøre hvilke produkter de pt går
efter.
Selve angrebet - Det jeg ved
- Det startede i Julen 2024 og sker stadig
- Det er spoofet IP adresser fra 1.1.1.1 eller 8.8.8.8.
- Det går imod Ike UDP port 500.
- Det er Mirai botnettet der sender disse pakker.
- BackConnect går tilbage til en indisk IP adresse på
203[.]192[.]219[.]62:444
- Den indiske IP adresse er kinesisk sproget.
Anbefaling
Det bedste er også at omfatte GEP blokering på UDP. Bruge dette
meget kritisk og kun tillade hvem der må forbinde sig til en åben
UDP service. Det er eks ikke normalt at Google eller Cloudflaer
sender data pakker til ens Ike vpn service, eller TDC's DNS servers
for den sag skyld.
Mange tror også man ikke må forhinder Microsoft eller Apple IP
adresser. Det er også lidt en skrøne. Man skal blokere for dem der
angriber også selv det kommer fra en Microsoft IP adresse eller
Apple. Mange ved eks ikke at Microsoft i dag hoster en af verdens
største scannings leverandører. Hvorfor så ikke blokere på de IP
adresser de kommer fra.
Man børe tjekke egne systemer for adgang til følgende IP adresse.
203[.]192[.]219[.]62:444
Man kan også benytte IPS systemer og droppe de angreb der er
kendskab til netop nu.
Bekymring
Desuden er jeg lidt bekymeret for hvor meget denne angrebs metodik
finder indpas, da dette kan få store konsekvenser i forhold til hvor
velkykket angreb imod en UDP baseret serivce kan blive. En angriber
kan få meget stor success rate og derved et højere impact på
Internettet. Vi kan kun håbe dette ikke bliver tilfældet.
Detection
Jeg har allerede publiceret generiske IDS detections til at opdage
en del af metodikken. Men den kan meget vel ændre sig hurtigt,
såfremt der bliver fundet på nye metodikker.
Happy hunting.....
LOLBAS - ie4uinit.exe - TA4557/FIN6
15 December 2024 - Blog Post # 870
LOLBAS - ie4uinit.exe
Jeg har længe skrevet om brugen af LOLBAS metodikker, men
der er første gang jeg selv ser misbrug af
LOLBAS ie4uinit.exe i mere målrettet malware kampanger.
The DFIR Report har netop beskrevet brugen af netop ie4uinit.exe
i målrettet malware kampanger til bla. at installerer Cobalt Strike.
Netop LOLBAS metodikker er noget jeg er særlig opmærksom på, da det
er metodikker der er virkelig nemme at udnytte og som typisk ikke
giver nogen alerts ret mange steder. Denne metodik er helt tilbage
fra 2018, men bliver stadig brugt her i 2024, som noget der åbenbart
bare stadig virker. Det har hele tiden været muligt
at opdage denne metodik med min Sysmon Config fil, dog har jeg gjort
det lidt mere synligt at se at netop når denne metodik bruges med
målrettet alerts.
Fil kopieringer
Netop fordi man er nød til at lave en
kopi af ie4uinit.exe og køre denne uden for sit normale omåde
som er system32 eller sysWOW64, gør at metodikken er nem at lave
detection til.
TA4557/FIN6
Dette er en kendt gruppe der udføre mange forskellige
former for attacks. Det gør dem bestemt værd at holde øje med. Den
angriber typisk via e-mail og
FIN6 har en historik der går tilbage til ca 2019.
Der er målrettet detection fra Sysmon Config 68
Happy hunting.....
Blog posts
Alt hvad jeg har skrevet om igennem 2025