/dev/null
- Overig
cpprestsdk verkeer naar 169.254.169.254
05-08-2023, 13:22 door Anoniem, 37 reacties
We hebben op het werk een groot aantal machines met Windows 10 en 11, en bij het debuggen van iets anders kwam ik er onlangs achter dat iedere machine eens per uur een connectie probeert te maken met IP adres 169.254.169.254
Dit is een "bekend adres" voor in cloud server omgevingen, waar dan een configuratie server draait die de individuele instances van hun persoonlijke configuratie voorziet. Maar dit is geen cloud omgeving, het zijn gewoon PC's.
Omdat er veel machines zijn geeft dit een behoorlijke hoeveelheid ARP verkeer (de machines gaan er vanuit dat het een lokaal adres is). En dat is op een wireless netwerk een behoorlijke belasting. Dus daar wil ik graag vanaf.
Als ik een machine op het netwerk zet met dit adres en een webserver, dan zie ik dat de betreffende machines inderdaad die verwachte functie uitvoeren voor dat adres:
"GET /metadata/instance/compute/vmId?api-version=2020-06-01&format=text HTTP/1.1" 404 494 "-" "cpprestsdk/2.10.18"
"GET /latest/dynamic/instance-identity/document HTTP/1.1" 404 493 "-" "cpprestsdk/2.10.18"
Het is hier gedocumenteerd:
https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service
Ik ben niet de eerste die hier achter komt:
https://learn.microsoft.com/en-us/answers/questions/1182841/high-number-of-arp-queries-directed-to-169-254-169
Nu vraag ik me af: hoe kom ik er achter welk programma dit veroorzaakt en hoe krijg ik dit stil.
Ik verdenk zelf Office 365 omdat er in de Office16 directory een file cpprestsdk.dll staat, maar ik kan tot nu toe nergens de bovenstaande strings uit de URL's vinden.
Het neerzetten van een machine die antwoordt op de ARP's scheelt al wel behoorlijk, maar het blijft vreemd dat in een standalone PC omgeving die cloud hosting functionaliteit actief is.
Iemand eerder dit wel eens bij de hand gehad en toevallig wat meer details gevonden? Die meneer in bovenstaande URL heeft het kennelijk ook niet kunnen vinden.
(kom er niet mee, zoals de 1e replyer in dat topic, dat dit aangeeft dat er iets fout gaat met DHCP en dat de machine daarom zo'n adres krijgt. dat is NIET wat er aan de hand is, de machines hebben een goed adres. ze roepen dat rare adres aan.)
Dit is een "bekend adres" voor in cloud server omgevingen, waar dan een configuratie server draait die de individuele instances van hun persoonlijke configuratie voorziet. Maar dit is geen cloud omgeving, het zijn gewoon PC's.
Omdat er veel machines zijn geeft dit een behoorlijke hoeveelheid ARP verkeer (de machines gaan er vanuit dat het een lokaal adres is). En dat is op een wireless netwerk een behoorlijke belasting. Dus daar wil ik graag vanaf.
Als ik een machine op het netwerk zet met dit adres en een webserver, dan zie ik dat de betreffende machines inderdaad die verwachte functie uitvoeren voor dat adres:
"GET /metadata/instance/compute/vmId?api-version=2020-06-01&format=text HTTP/1.1" 404 494 "-" "cpprestsdk/2.10.18"
"GET /latest/dynamic/instance-identity/document HTTP/1.1" 404 493 "-" "cpprestsdk/2.10.18"
Het is hier gedocumenteerd:
https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service
Ik ben niet de eerste die hier achter komt:
https://learn.microsoft.com/en-us/answers/questions/1182841/high-number-of-arp-queries-directed-to-169-254-169
Nu vraag ik me af: hoe kom ik er achter welk programma dit veroorzaakt en hoe krijg ik dit stil.
Ik verdenk zelf Office 365 omdat er in de Office16 directory een file cpprestsdk.dll staat, maar ik kan tot nu toe nergens de bovenstaande strings uit de URL's vinden.
Het neerzetten van een machine die antwoordt op de ARP's scheelt al wel behoorlijk, maar het blijft vreemd dat in een standalone PC omgeving die cloud hosting functionaliteit actief is.
Iemand eerder dit wel eens bij de hand gehad en toevallig wat meer details gevonden? Die meneer in bovenstaande URL heeft het kennelijk ook niet kunnen vinden.
(kom er niet mee, zoals de 1e replyer in dat topic, dat dit aangeeft dat er iets fout gaat met DHCP en dat de machine daarom zo'n adres krijgt. dat is NIET wat er aan de hand is, de machines hebben een goed adres. ze roepen dat rare adres aan.)
Reacties (37)
06-08-2023, 01:15 door
Erik van Straten
Vreemd. Uit https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service:
Uit https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows#sample-1-tracking-vm-running-on-azure:
Het lijkt dus om software te gaan die "denkt" een VM te zijn en aan "de baas" vraagt wat hun ID is. Verder googlen leverde bar weinig op, vaak een indicatie dat dit geen gangbaar fenomeen is.
Ik heb op mijn Windows 10 notebook gezocht (gebruik makend van Total Commander) naar /metadata/instance en vond in de map "C:\Program Files\Windows Defender Advanced Threat Protection\" matches in 2 files:
MsSense.dll - enkele (Unicode) strings omtreeks de vindplaats:
SenseImdsCollector.exe (IMDS staat voor (Azure) "Instance Metadata Service"):
Onder C:\Windows\ vond ik alleen kopiën van bovenstaande files (onder de WinSxS\ submap).
Hopelijk heb ik dit hartstikke fout, maar als jullie zelf niet bewust virtualisatie op de betreffende PC's gebruiken, zou ik niet uitsluiten dat het zou om malware zou kunnen gaan die van virtualisatie gebruik maakt (voorbeeld https://www.zdnet.com/article/ransomware-cyber-criminals-are-using-virtual-machines-to-hide-attacks-from-being-detected/). In elk geval iets om in je achterhoofd te houden.
Hoewel de Windows firewall niet expliciet ARP als protocol ondersteunt, kon ik ARP-requests wel voorkómen door al het uitgaande verkeer (protocol: all) naar 169.254.169.254 te blokkeren ("curl http://169.254.169.254" meldt, met die rule, binnen enkele ms "Couldn't connect to server" en Wireshark laat geen ARP requests meer zien voor 169.254.169.254).
Affijn, wellicht heb je iets aan deze info. Laat je het ons weten als je de oorzaak gevonden hebt?
Communication between the VM and IMDS never leaves the host.
Uit https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows#sample-1-tracking-vm-running-on-azure:
Invoke-RestMethod -Headers @{"Metadata"="true"} -Method GET -NoProxy -Uri "http://169.254.169.254/metadata/instance/compute/vmId?api-version=2017-08-01&format=text"
En de curl variant:curl -H Metadata:true --noproxy "*" "http://169.254.169.254/metadata/instance/compute/vmId?api-version=2017-08-01&format=text"
Het lijkt dus om software te gaan die "denkt" een VM te zijn en aan "de baas" vraagt wat hun ID is. Verder googlen leverde bar weinig op, vaak een indicatie dat dit geen gangbaar fenomeen is.
Ik heb op mijn Windows 10 notebook gezocht (gebruik makend van Total Commander) naar /metadata/instance en vond in de map "C:\Program Files\Windows Defender Advanced Threat Protection\" matches in 2 files:
MsSense.dll - enkele (Unicode) strings omtreeks de vindplaats:
Firmware State
KB Item State
KB Index State
Isolation State
Azure Vm Metadata State
http://169.254.169.254
/metadata/instance/compute/vmId?api-version=2020-06-01&format=text
/metadata/instance/compute/resourceId?api-version=2020-06-01&format=text
/metadata/instance/compute/subscriptionId?api-version=2020-06-01&format=text
AllowWindowsDefenderApplicationGuard
ROOT\CIMV2\MDM\DMMAP
SELECT * FROM MDM_WindowsDefenderApplicationGuard_Settings01
SELECT * FROM MDM_WindowsDefenderApplicationGuard
KB Item State
KB Index State
Isolation State
Azure Vm Metadata State
http://169.254.169.254
/metadata/instance/compute/vmId?api-version=2020-06-01&format=text
/metadata/instance/compute/resourceId?api-version=2020-06-01&format=text
/metadata/instance/compute/subscriptionId?api-version=2020-06-01&format=text
AllowWindowsDefenderApplicationGuard
ROOT\CIMV2\MDM\DMMAP
SELECT * FROM MDM_WindowsDefenderApplicationGuard_Settings01
SELECT * FROM MDM_WindowsDefenderApplicationGuard
SenseImdsCollector.exe (IMDS staat voor (Azure) "Instance Metadata Service"):
kernel32.dll
SleepConditionVariableCS
WakeAllConditionVariable
null
http://169.254.169.254
/metadata/instance/compute/vmId?api-version=2020-06-01&format=text
/metadata/instance/compute/resourceId?api-version=2020-06-01&format=text
/metadata/instance/compute/subscriptionId?api-version=2020-06-01&format=text
Age
Unknown exception
SleepConditionVariableCS
WakeAllConditionVariable
null
http://169.254.169.254
/metadata/instance/compute/vmId?api-version=2020-06-01&format=text
/metadata/instance/compute/resourceId?api-version=2020-06-01&format=text
/metadata/instance/compute/subscriptionId?api-version=2020-06-01&format=text
Age
Unknown exception
Onder C:\Windows\ vond ik alleen kopiën van bovenstaande files (onder de WinSxS\ submap).
Hopelijk heb ik dit hartstikke fout, maar als jullie zelf niet bewust virtualisatie op de betreffende PC's gebruiken, zou ik niet uitsluiten dat het zou om malware zou kunnen gaan die van virtualisatie gebruik maakt (voorbeeld https://www.zdnet.com/article/ransomware-cyber-criminals-are-using-virtual-machines-to-hide-attacks-from-being-detected/). In elk geval iets om in je achterhoofd te houden.
Hoewel de Windows firewall niet expliciet ARP als protocol ondersteunt, kon ik ARP-requests wel voorkómen door al het uitgaande verkeer (protocol: all) naar 169.254.169.254 te blokkeren ("curl http://169.254.169.254" meldt, met die rule, binnen enkele ms "Couldn't connect to server" en Wireshark laat geen ARP requests meer zien voor 169.254.169.254).
Affijn, wellicht heb je iets aan deze info. Laat je het ons weten als je de oorzaak gevonden hebt?
Ok dat is interessant... bedankt voor het meekijken! Ik had gezocht met "findstr" en die vindt deze strings daar niet. Kennelijk weer een half-werkend tool. Zal inderdaad wel komen doordat de strings als 16-bit characters in de file staan. "findstr" vindt wel bepaalde strings, maar niet die URL.
Gezien het feit dat je daar precies die (antieke) api-version ziet staan die ik ook in de queries zie zal dit wel de schuldige zijn.
(deze feature hebben we ook actief staan dus wellicht dat die eens per uur die check doet, misschien om te kijken of er wellicht dergelijke malware actief is)
Ik ga er morgen weer naar kijken, maar ik denk niet dat het malware is, hooguit malware in de zin dat er bewust een of andere applicatie geinstalleerd is die dit doet: ik had even het idee dat het alleen Dell machines waren die dit deden en HP machines niet, maar dat moet ik nog hard maken en de VMware VM die ik gebruik om van huis uit te testen doet het ook. Als het alleen machines van 1 merk zijn dan zou het nog iets als de "Dell peripheral manager" of "Dell update assistant" kunnen zijn. Ik noem dat malware maar anderen kennelijk niet.
Kwa negatief effect op het netwerk is het wel voldoende om ergens een fake reply op die ARP te geven, dan stoppen de ARP's weer voor een tijd. Dat ie dan de betreffende server niet kan connecten dat boeit niet zo, dat is unicast verkeer.
Maar ik ga ook (morgen) eens in de config van die Windows Defender duiken, wellicht kan het daar uitgezet worden.
Gezien het feit dat je daar precies die (antieke) api-version ziet staan die ik ook in de queries zie zal dit wel de schuldige zijn.
(deze feature hebben we ook actief staan dus wellicht dat die eens per uur die check doet, misschien om te kijken of er wellicht dergelijke malware actief is)
Ik ga er morgen weer naar kijken, maar ik denk niet dat het malware is, hooguit malware in de zin dat er bewust een of andere applicatie geinstalleerd is die dit doet: ik had even het idee dat het alleen Dell machines waren die dit deden en HP machines niet, maar dat moet ik nog hard maken en de VMware VM die ik gebruik om van huis uit te testen doet het ook. Als het alleen machines van 1 merk zijn dan zou het nog iets als de "Dell peripheral manager" of "Dell update assistant" kunnen zijn. Ik noem dat malware maar anderen kennelijk niet.
Kwa negatief effect op het netwerk is het wel voldoende om ergens een fake reply op die ARP te geven, dan stoppen de ARP's weer voor een tijd. Dat ie dan de betreffende server niet kan connecten dat boeit niet zo, dat is unicast verkeer.
Maar ik ga ook (morgen) eens in de config van die Windows Defender duiken, wellicht kan het daar uitgezet worden.
Jouw windows 11 device communiceert via verschillende uniek te identificeren wijzen met Interwebz.
bijv,. via een unieke MS host ID.
Je vraaag werd hier al eens beantwoord:
https://stackoverflow.com/questions/42314029/whats-special-about-169-254-169-254-ip-address-for-aws
Het is namelijk bedoeld om je device te syncen via de Amazon Time Sync Service.
Ook de Brave Zoekmachine bijvoorbeeld wordt hiermee gesynchroniseerd via Amazon.
Je doet niets, echt helemaal niets online, zonder dat het op de een of andere manier zal worden gecommuniceerd.
Hou dat vanaf nu goed voor logen, het geldt ook voor vrij onschuldige zaken als bovengenoemd.
luntrus
bijv,. via een unieke MS host ID.
Je vraaag werd hier al eens beantwoord:
https://stackoverflow.com/questions/42314029/whats-special-about-169-254-169-254-ip-address-for-aws
Het is namelijk bedoeld om je device te syncen via de Amazon Time Sync Service.
Ook de Brave Zoekmachine bijvoorbeeld wordt hiermee gesynchroniseerd via Amazon.
Je doet niets, echt helemaal niets online, zonder dat het op de een of andere manier zal worden gecommuniceerd.
Hou dat vanaf nu goed voor logen, het geldt ook voor vrij onschuldige zaken als bovengenoemd.
luntrus
@ OP en erik van straten,
Maar hier via VT niets te vinden, anders dan metadata-smaak (flavor) = google.
Zie ook: https://www.shodan.io/search?query=http%3A%2F%2F169.254.169.254%2F
en daar -> latest-metadata/index-defaultpage
luntrus
Maar hier via VT niets te vinden, anders dan metadata-smaak (flavor) = google.
Joe Sandbox Analysis:
Verdict: UNKNOWN
Score: 0/100
Classification: unknown0.win@3/11@0/1
Hosts: 169.254.169.254
HTML Report: https://www.joesandbox.com/analysis/199464/0/html
PDF Report: https://www.joesandbox.com/analysis/199464/0/pdf
Executive Report: https://www.joesandbox.com/analysis/199464/0/executive
Incident Report: https://www.joesandbox.com/analysis/199464/0/irxml
IOCs: https://www.joesandbox.com/analysis/199464?idtype=analysisid
Verdict: UNKNOWN
Score: 0/100
Classification: unknown0.win@3/11@0/1
Hosts: 169.254.169.254
HTML Report: https://www.joesandbox.com/analysis/199464/0/html
PDF Report: https://www.joesandbox.com/analysis/199464/0/pdf
Executive Report: https://www.joesandbox.com/analysis/199464/0/executive
Incident Report: https://www.joesandbox.com/analysis/199464/0/irxml
IOCs: https://www.joesandbox.com/analysis/199464?idtype=analysisid
Zie ook: https://www.shodan.io/search?query=http%3A%2F%2F169.254.169.254%2F
en daar -> latest-metadata/index-defaultpage
luntrus
Door Anoniem: Nu vraag ik me af: hoe kom ik er achter welk programma dit veroorzaakt en hoe krijg ik dit stil.
Ik verdenk zelf Office 365 omdat er in de Office16 directory een file cpprestsdk.dll staat, maar ik kan tot nu toe nergens de bovenstaande strings uit de URL's vinden.
cpprestsdk heeft een beschrijvende naam: CPP REST SDK, het is (of hoort bij) een software development kit voor C++ voor REST. REST staat voor https://en.wikipedia.org/wiki/Representational_state_transfer[1], en dat is een moeilijke term voor een conventie om applicaties via HTTP(S) met een server te laten communiceren. Dat klopt met dat Erik een aanroep van iets dat Invoke-RestMethod heet citeerde. Je maakt niet helemaal duidelijk hoe breed je gezocht hebt, maar in cpprestsdk zelf zal je geen strings aantreffen die de aanroeper ervan aanlevert.Ik verdenk zelf Office 365 omdat er in de Office16 directory een file cpprestsdk.dll staat, maar ik kan tot nu toe nergens de bovenstaande strings uit de URL's vinden.
Een paar gedachten:
• Om die requests te doen moet de software die het doet zijn opgestart. Een machine vanwaar je weet dat het gebeurt zou dus dit gedrag pas moeten vertonen *nadat* Office is gestart, als het in Office zit. Daar moeten experimenten mee op te zetten zijn.
• Een botte bijlmethode kan zijn om bewust cpprestsdk.dll weg te gooien (of zo lang te renamen) en te kijken of er iets crasht en of het de ARP-requests doet verdwijnen van die machine. Soms is iets bewust kapot maken een uitstekende manier om informatie boven water te krijgen.
[1] https://en.wikipedia.org/wiki/Representational_state_transfer
Zou Erik in dit geval gelijk hebben, dan werd het sample verspreid door gecompromitteerde discord accounts.
Kan binnenkomen via het scannen van een onbetrouwbare QR of link, via uitvoerbare code?
Benieuwd wie gelijk krijgt en op welke wijze.
Kan binnenkomen via het scannen van een onbetrouwbare QR of link, via uitvoerbare code?
Benieuwd wie gelijk krijgt en op welke wijze.
Door Anoniem: Jouw windows 11 device communiceert via verschillende uniek te identificeren wijzen met Interwebz.
bijv,. via een unieke MS host ID.
Je vraaag werd hier al eens beantwoord:
https://stackoverflow.com/questions/42314029/whats-special-about-169-254-169-254-ip-address-for-aws
Het is namelijk bedoeld om je device te syncen via de Amazon Time Sync Service.
Ook de Brave Zoekmachine bijvoorbeeld wordt hiermee gesynchroniseerd via Amazon.
Je doet niets, echt helemaal niets online, zonder dat het op de een of andere manier zal worden gecommuniceerd.
Hou dat vanaf nu goed voor logen, het geldt ook voor vrij onschuldige zaken als bovengenoemd.
luntrus
bijv,. via een unieke MS host ID.
Je vraaag werd hier al eens beantwoord:
https://stackoverflow.com/questions/42314029/whats-special-about-169-254-169-254-ip-address-for-aws
Het is namelijk bedoeld om je device te syncen via de Amazon Time Sync Service.
Ook de Brave Zoekmachine bijvoorbeeld wordt hiermee gesynchroniseerd via Amazon.
Je doet niets, echt helemaal niets online, zonder dat het op de een of andere manier zal worden gecommuniceerd.
Hou dat vanaf nu goed voor logen, het geldt ook voor vrij onschuldige zaken als bovengenoemd.
luntrus
Sorry hoor maar ik dacht dat ik al aangegeven had dat het geen cloud server is en dat ik weet waar dat adres in cloud omgevingen voor gebruikt wordt. Dit adres heeft ook NIETS met "Interwebz" (jouw terminologie) te maken, het is een niet-routeerbaar adres wat alleen op het lokale netwerk kan communiceren, daarom doet de PC ook ARP requests ervoor.
Gelukkig kwam Erik met een veel beter antwoord.
“Nu vraag ik me af: hoe kom ik er achter welk programma dit veroorzaakt ”
Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
Windows bronmonitor zou ook kunnen.
Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
Windows bronmonitor zou ook kunnen.
Door Anoniem:
Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
Ja daarom is dat geen oplossing. Die PC's maken 1 keer per uur een korte connectie en dan kun je dat dus niet zien.Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
(zeker niet tussen de vele connecties die PC's toch al hebben)
Dat is hetzelfde probleem als "het moet een van de draaiende programma's zijn". Ja er draaien wel 100 programma's op een Windows 10/11 PC. Daar kom je er niet mee.
Met GlassWire (of variant) zou het achterhalen wel moeten lukken.
Of als het een oudere versie van windows is met Zone Alert.
Op een Mac zou je het met Little Snitch doen.
Of als het een oudere versie van windows is met Zone Alert.
Op een Mac zou je het met Little Snitch doen.
Door Anoniem: “Nu vraag ik me af: hoe kom ik er achter welk programma dit veroorzaakt ”
Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
Windows bronmonitor zou ook kunnen.
Ik zou eerder met procmon dit doen, icm een filter naar het IP address.Met “netstat” op de commandline moet dat lukken.
Maar dan moet je wel precies op het moment van connectie aan het kijken zijn.
Windows bronmonitor zou ook kunnen.
Door Erik van Straten:
[knip goed zoekwerk]
Hoewel de Windows firewall niet expliciet ARP als protocol ondersteunt, kon ik ARP-requests wel voorkómen door al het uitgaande verkeer (protocol: all) naar 169.254.169.254 te blokkeren ("curl http://169.254.169.254" meldt, met die rule, binnen enkele ms "Couldn't connect to server" en Wireshark laat geen ARP requests meer zien voor 169.254.169.254).
[knip goed zoekwerk]
Hoewel de Windows firewall niet expliciet ARP als protocol ondersteunt, kon ik ARP-requests wel voorkómen door al het uitgaande verkeer (protocol: all) naar 169.254.169.254 te blokkeren ("curl http://169.254.169.254" meldt, met die rule, binnen enkele ms "Couldn't connect to server" en Wireshark laat geen ARP requests meer zien voor 169.254.169.254).
Dat is redelijk te verwachten - ARP resolutie wordt door de IP stack gedaan wanneer een pakket 'verzendklaar' gemaakt wordt en er (nog) geen ARP entry bekend is .
De firewall functie zit vroeg genoeg in de IP stack dat het zover niet komt , en dus ook geen ARP poging.
Ik neem aan dat Windows ook kan null-routen ? (statische route voor een IP adres naar Null device ) .
Daarmee zal dan het verkeer (en ARP query) ook te onderdrukken zijn.
Ah - na wat google werk - zo te zien kent Windows het concept 'statische route naar /dev/null' niet .
Voor TS : is er in de windows route tabel dan iets te zien van 169.254 ?
Affijn, wellicht heb je iets aan deze info. Laat je het ons weten als je de oorzaak gevonden hebt?
https://manjusullad.wordpress.com/2020/12/12/azure-imds/
Zegt iets over het doel van die service .
Voor TS : zijn de images dan evt van Azure naar on-premise gekopieerd ?
En dit blog is misschien ook nuttig, voor de vraag welke programma's de query doen
https://in.security/2023/01/03/imds-hardening/
Door Anoniem: Dat is hetzelfde probleem als "het moet een van de draaiende programma's zijn". Ja er draaien wel 100 programma's op een Windows 10/11 PC. Daar kom je er niet mee.
Je kan wel degelijk het nodige. Neem een machine waarvan je weet dat die ARP-verkeer produceert, start die op, maar log niet in. Als die dan ook ARP-verkeer blijkt te produceren weet je dat het in programma's zit die actief zijn buiten een gebruikerssessie, gebeurt het alleen na een inlog dan gaat het om programma's die gestart worden binnen een gebruikerssessie.Je sprak zelf al het vermoeden uit dat het om Office gaat. Dat vermoeden kan je heel specifiek toetsen door Office niet op te starten (of alles wat ertoe behoort af te sluiten) en te kijken wat er dan gebeurt.
Ook verdenk je een specifieke dll, omdat de naam ervan in de logs verschijnt van de webserver waarmee je al getest hebt. Met dit programma kan je kennelijk zichtbaar maken in welke processen een dll geladen is:
https://learn.microsoft.com/en-us/sysinternals/downloads/listdlls
Als dat inderdaad werkt kan je op basis daarvan gericht processen afsluiten en kijken of daarmee ook het ARP-verkeer opdroogt.
Door Anoniem:
Je sprak zelf al het vermoeden uit dat het om Office gaat. Dat vermoeden kan je heel specifiek toetsen door Office niet op te starten (of alles wat ertoe behoort af te sluiten) en te kijken wat er dan gebeurt.
Door Anoniem: Dat is hetzelfde probleem als "het moet een van de draaiende programma's zijn". Ja er draaien wel 100 programma's op een Windows 10/11 PC. Daar kom je er niet mee.
Je kan wel degelijk het nodige. Neem een machine waarvan je weet dat die ARP-verkeer produceert, start die op, maar log niet in. Als die dan ook ARP-verkeer blijkt te produceren weet je dat het in programma's zit die actief zijn buiten een gebruikerssessie, gebeurt het alleen na een inlog dan gaat het om programma's die gestart worden binnen een gebruikerssessie.Je sprak zelf al het vermoeden uit dat het om Office gaat. Dat vermoeden kan je heel specifiek toetsen door Office niet op te starten (of alles wat ertoe behoort af te sluiten) en te kijken wat er dan gebeurt.
Nou zo werkt dat echt niet meer hoor! 10 jaar geleden misschien. Als je software op je machine hebt dan worden er allerlei services (zowel continue draaiende als one-shot) gestart als je de machine opstart, soms meteen, soms na een minuutje, soms om de zoveel tijd.
Zelfs als je Office 365 helemaal nooit opstart dan draaien er nog services voor, bijvoorbeeld voor het ophalen en installeren van updates.
Dus op die manier kom je er niet uit.
Bovendien denk ik inmiddels dat de kans groter is dat het die Windows Defender Advanced Threat Protection service is.
Ook verdenk je een specifieke dll, omdat de naam ervan in de logs verschijnt van de webserver waarmee je al getest hebt. Met dit programma kan je kennelijk zichtbaar maken in welke processen een dll geladen is:
https://learn.microsoft.com/en-us/sysinternals/downloads/listdlls
Als dat inderdaad werkt kan je op basis daarvan gericht processen afsluiten en kijken of daarmee ook het ARP-verkeer opdroogt.
https://learn.microsoft.com/en-us/sysinternals/downloads/listdlls
Als dat inderdaad werkt kan je op basis daarvan gericht processen afsluiten en kijken of daarmee ook het ARP-verkeer opdroogt.
Wat ik niet vermeld had is dat dit allemaal centraal gemanagede en dichtgetimmerde machines zijn, waarop het niet zo zondermeer mogelijk is om extra software te installeren of te draaien.
Ik kan zelf wel als een lokale administrator inloggen, maar de gemiddelde gebruiker niet. Ik ga zometeen nog wel op een testmachine e.e.a. proberen, maar het grootste deel van de acties moet ik "van buitenaf" doen.
07-08-2023, 12:29 door
Erik van Straten
Door Anoniem: Voor TS : is er in de windows route tabel dan iets te zien van 169.254 ?
Ik heb mijn W10 redelijk dichtgetimmerd. Wellicht daardoor zie ik, in tegenstelling tot in https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/, geen route voor 169.254.*.*. Maar dat maakt niks uit, zonder firewall rule gaat mijn W10 er gewoon (kennelijk hardcoded) vanuit dat 169.254.*.* lokaal is (doet ARP-requests voor zo'n IP-adres i.p.v. pakketjes naar de default gateway te sturen). Een "route add" voor 169.254.169.254 naar het IP-adres van mijn PC maakte ook niks uit. Ook een statische ARP-entry aanmaken voor 169.254.169.254 lukte niet; alleen de "firewall oplossing" werkte.Door Anoniem: En dit blog is misschien ook nuttig, voor de vraag welke programma's de query doen
https://in.security/2023/01/03/imds-hardening/
Interessant, dank!https://in.security/2023/01/03/imds-hardening/
Off topic: in https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service werd ook 168.63.129.16 genoemd, met link naar https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16, waar mijn haren van overeind gingen staan: Microsoft marketing belooft "zero trust" maar de praktijk is heel anders. Ik overwoog afgelopen weekend een rant over MS te schrijven, maar kwam er niet aan toe. Overigens krijg ik geen antwoord op http://168.63.129.16/?comp=versions, maar effectief is dat irrelevant.
On topic, aan de vele andere reageerders: het is interessanter om te weten waarom de "cpprestsdk" requests (via http) de PC's van de TS verlaten, dan welk programma dat precies (al dan niet door iets anders getriggerd) veroorzaken. Een firewall rule op elke host toevoegen helpt tegen "de herrie", maar is natuurlijk symptoombestrijding.
Door Erik van Straten:
Ik heb mijn W10 redelijk dichtgetimmerd. Wellicht daardoor zie ik, in tegenstelling tot in https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/, geen route voor 169.254.*.*. Maar dat maakt niks uit, zonder firewall rule gaat mijn W10 er gewoon (kennelijk hardcoded) vanuit dat 169.254.*.* lokaal is (doet ARP-requests voor zo'n IP-adres i.p.v. pakketjes naar de default gateway te sturen). Een "route add" voor 169.254.169.254 naar het IP-adres van mijn PC maakte ook niks uit. Ook een statische ARP-entry aanmaken voor 169.254.169.254 lukte niet; alleen de "firewall oplossing" werkte.
Ik heb mijn W10 redelijk dichtgetimmerd. Wellicht daardoor zie ik, in tegenstelling tot in https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/, geen route voor 169.254.*.*. Maar dat maakt niks uit, zonder firewall rule gaat mijn W10 er gewoon (kennelijk hardcoded) vanuit dat 169.254.*.* lokaal is (doet ARP-requests voor zo'n IP-adres i.p.v. pakketjes naar de default gateway te sturen). Een "route add" voor 169.254.169.254 naar het IP-adres van mijn PC maakte ook niks uit. Ook een statische ARP-entry aanmaken voor 169.254.169.254 lukte niet; alleen de "firewall oplossing" werkte.
Inderdaad, er staat hier op de computers ook geen route voor 169.254.169.254 maar toch doen ze die ARP requests.
Dus dat werkt kennelijk "buiten alles om".
Ik heb nog vanalles onderzocht maar niks kunnen vinden, dus heb ik nu die "fake ARP reply" maar geformaliseerd door
dat op de router te regelen. De PC's hebben nu een ARP entry voor 169.254.169.254 met MAC adres van de router, en
als ze proberen naar dat adres te gaan krijgen ze "network unreachable" terug.
Ik zie nergens meldingen van problemen maar het ARP verkeer is nu dus enorm afgenomen en dat was eigenlijk vooral
waar het me om te doen was.
Systemen zijn te complex geworden om precies te (blijven) begrijpen wat ze doen en waarom. Dat de commerciele
afdeling van bedrijven als Microsoft voortdurend de naam van producten verandert zonder dat de technische afdeling
dat volgt, helpt ook niet natuurlijk. Dat maakt zoeken naar issues met productnamen nog lastiger.
Door Anoniem:
Inderdaad, er staat hier op de computers ook geen route voor 169.254.169.254 maar toch doen ze die ARP requests.
Dus dat werkt kennelijk "buiten alles om".
Ik heb nog vanalles onderzocht maar niks kunnen vinden, dus heb ik nu die "fake ARP reply" maar geformaliseerd door
dat op de router te regelen. De PC's hebben nu een ARP entry voor 169.254.169.254 met MAC adres van de router, en
als ze proberen naar dat adres te gaan krijgen ze "network unreachable" terug.
Ik zie nergens meldingen van problemen maar het ARP verkeer is nu dus enorm afgenomen en dat was eigenlijk vooral
waar het me om te doen was.
Door Erik van Straten:
Ik heb mijn W10 redelijk dichtgetimmerd. Wellicht daardoor zie ik, in tegenstelling tot in https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/, geen route voor 169.254.*.*. Maar dat maakt niks uit, zonder firewall rule gaat mijn W10 er gewoon (kennelijk hardcoded) vanuit dat 169.254.*.* lokaal is (doet ARP-requests voor zo'n IP-adres i.p.v. pakketjes naar de default gateway te sturen). Een "route add" voor 169.254.169.254 naar het IP-adres van mijn PC maakte ook niks uit. Ook een statische ARP-entry aanmaken voor 169.254.169.254 lukte niet; alleen de "firewall oplossing" werkte.
Ik heb mijn W10 redelijk dichtgetimmerd. Wellicht daardoor zie ik, in tegenstelling tot in https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/, geen route voor 169.254.*.*. Maar dat maakt niks uit, zonder firewall rule gaat mijn W10 er gewoon (kennelijk hardcoded) vanuit dat 169.254.*.* lokaal is (doet ARP-requests voor zo'n IP-adres i.p.v. pakketjes naar de default gateway te sturen). Een "route add" voor 169.254.169.254 naar het IP-adres van mijn PC maakte ook niks uit. Ook een statische ARP-entry aanmaken voor 169.254.169.254 lukte niet; alleen de "firewall oplossing" werkte.
Inderdaad, er staat hier op de computers ook geen route voor 169.254.169.254 maar toch doen ze die ARP requests.
Dus dat werkt kennelijk "buiten alles om".
Ik heb nog vanalles onderzocht maar niks kunnen vinden, dus heb ik nu die "fake ARP reply" maar geformaliseerd door
dat op de router te regelen. De PC's hebben nu een ARP entry voor 169.254.169.254 met MAC adres van de router, en
als ze proberen naar dat adres te gaan krijgen ze "network unreachable" terug.
Ik zie nergens meldingen van problemen maar het ARP verkeer is nu dus enorm afgenomen en dat was eigenlijk vooral
waar het me om te doen was.
Dat zal werken.
Misschien interessant om te kijken met welk IP de PCs nu naar dat fake arp adres connecten ; Ook een verzonnen 169.254 , of hun 'echte' unicast adres.
Ben je nog nieuwsgierig genoeg , dan zou je die connectie pogingen kunnen loggen op (/naast) de router, herleiden naar de PCs, en zien of er iets gemeenschappelijks is van degenen die het wel en degenen die het (evt) niet doen . (versie, master image , software pakketten etc).
Systemen zijn te complex geworden om precies te (blijven) begrijpen wat ze doen en waarom. Dat de commerciele
afdeling van bedrijven als Microsoft voortdurend de naam van producten verandert zonder dat de technische afdeling
dat volgt, helpt ook niet natuurlijk. Dat maakt zoeken naar issues met productnamen nog lastiger.
Uit de links die ik postte (7 aug 10:06) leid ik af dat het ook geen Microsoft programma hoeft te zijn dat die query doet.
Blijkbaar is een mogelijke usecase software die qua licentie verwacht/eist dat ze alleen op een Azure image draaien.
In elk geval hoeft het dus geen systeem/microsoft service of applicatie te zijn die zo'n query doet.
Voor mij is dit onderwerp boven en voorbij, maar toch uit nieuwsgierigheid even "anders" gezocht, met dank aan Gisteren, 14:42 door Anoniem over productnaam veranderingen:
Ik begon met dit:
site:microsoft.com CPP REST SDK, 169.254.169.254
Vanaf daar doorgezocht naar:
site:learn.microsoft.com PowerBi Embedded Capacity(eg. update SKU)
Alwaar ik deze handleiding vond:
https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-sample-for-customers?tabs=net-core
Ik begon met dit:
site:microsoft.com CPP REST SDK, 169.254.169.254
Vanaf daar doorgezocht naar:
site:learn.microsoft.com PowerBi Embedded Capacity(eg. update SKU)
Alwaar ik deze handleiding vond:
https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-sample-for-customers?tabs=net-core
Door Anoniem:
Misschien interessant om te kijken met welk IP de PCs nu naar dat fake arp adres connecten ; Ook een verzonnen 169.254 , of hun 'echte' unicast adres.
Dat wist ik al: ze gebruiken hun eigen 192.168 adres om te connecten naar dat 169.254 adres.Misschien interessant om te kijken met welk IP de PCs nu naar dat fake arp adres connecten ; Ook een verzonnen 169.254 , of hun 'echte' unicast adres.
Dat is wel vreemd maar het werkt. Kennelijk hardcoded route die je niet ziet met "route print". Wat vreemd is want in die output staan ook zat routes die je normaal niet in een route tabel ziet (voor het eigen adres, en voor multicast).
Ben je nog nieuwsgierig genoeg , dan zou je die connectie pogingen kunnen loggen op (/naast) de router, herleiden naar de PCs, en zien of er iets gemeenschappelijks is van degenen die het wel en degenen die het (evt) niet doen . (versie, master image , software pakketten etc).
Het komt van "al onze PC's". Die zijn allemaal geinstalleerd van een schoon Windows image van Microsoft en vervolgens geadopteerd door een INTUNE omgeving waarin meer software geinstalleerd wordt (Office 365 enzo) en policies en andere settings gedaan worden.
Uit de links die ik postte (7 aug 10:06) leid ik af dat het ook geen Microsoft programma hoeft te zijn dat die query doet.
Blijkbaar is een mogelijke usecase software die qua licentie verwacht/eist dat ze alleen op een Azure image draaien.
In elk geval hoeft het dus geen systeem/microsoft service of applicatie te zijn die zo'n query doet.
Laat een ding duidelijk zijn: deze systemen hebben NIETS met Azure van doen.
Door Anoniem:
Dat is wel vreemd maar het werkt. Kennelijk hardcoded route die je niet ziet met "route print". Wat vreemd is want in die output staan ook zat routes die je normaal niet in een route tabel ziet (voor het eigen adres, en voor multicast).
Door Anoniem:
Misschien interessant om te kijken met welk IP de PCs nu naar dat fake arp adres connecten ; Ook een verzonnen 169.254 , of hun 'echte' unicast adres.
Dat wist ik al: ze gebruiken hun eigen 192.168 adres om te connecten naar dat 169.254 adres.Misschien interessant om te kijken met welk IP de PCs nu naar dat fake arp adres connecten ; Ook een verzonnen 169.254 , of hun 'echte' unicast adres.
Dat is wel vreemd maar het werkt. Kennelijk hardcoded route die je niet ziet met "route print". Wat vreemd is want in die output staan ook zat routes die je normaal niet in een route tabel ziet (voor het eigen adres, en voor multicast).
Ok. Netwerktechnisch best raar, een connectie naar een lokaal (niet via gateway) IP met als source iets dat buiten het subnet valt .
Het kan - blijkbaar - , en als je het zou moeten bouwen waarschijnlijk door een route naar 169.254.0.0/16 direct naar het ethernet device te zetten .
En dan is hier de route ook weer hardcoded of verstopt in de output .
Ben je nog nieuwsgierig genoeg , dan zou je die connectie pogingen kunnen loggen op (/naast) de router, herleiden naar de PCs, en zien of er iets gemeenschappelijks is van degenen die het wel en degenen die het (evt) niet doen . (versie, master image , software pakketten etc).
Het komt van "al onze PC's". Die zijn allemaal geinstalleerd van een schoon Windows image van Microsoft en vervolgens geadopteerd door een INTUNE omgeving waarin meer software geinstalleerd wordt (Office 365 enzo) en policies en andere settings gedaan worden.
Uit de links die ik postte (7 aug 10:06) leid ik af dat het ook geen Microsoft programma hoeft te zijn dat die query doet.
Blijkbaar is een mogelijke usecase software die qua licentie verwacht/eist dat ze alleen op een Azure image draaien.
In elk geval hoeft het dus geen systeem/microsoft service of applicatie te zijn die zo'n query doet.
Laat een ding duidelijk zijn: deze systemen hebben NIETS met Azure van doen.
Dat protocol is blijkbaar bedacht/gebruikt/standaard aanwezig in/op/voor Azure images .
Dan wordt de vraag, waarom is het aangezet/aangebleven op je lokale installaties .
Systemen gebouwd met een van Azure afkomstig image leek me een mooie theorie om dat te verklaren.
Door Anoniem: Voor mij is dit onderwerp boven en voorbij, maar toch uit nieuwsgierigheid even "anders" gezocht, met dank aan Gisteren, 14:42 door Anoniem over productnaam veranderingen
Waar ik met name op doelde was dat we een programma gevonden hadden in de directory "C:\Program Files\Windows Defender Advanced Threat Protection" (dwz Erik had dit gevonden en ik kan dat bevestigen) terwijl "Windows Defender Advanced Threat Protection" al in 2021 de naam "Microsoft Defender for Endpoint" gekregen heeft.
Maar dat schaar ik onder de noemer "verkoperstaal" want anders had het wel in de map "C:\Program Files\Microsoft Defender for Endpoint" gestaan. Net zoals Windows 11 eigenlijk gewoon versie 10.0.22621 is.
Echter dit soort idioterie maakt het wel lastiger om te googlen naar issues rondom dit programma.
08-08-2023, 11:40 door
Erik van Straten
Dank aan de TS voor het blijven reageren in deze draad!
@TS: mocht je vertrouwelijk over dit onderwerp van gedachten willen wisselen, mijn e-mailadres is te vinden in https://www.security.nl/profile?alias=Erik+van+Straten. Net zoals veel van de sans.edu mensen ben ook ik een "got packets?" type die dol is op netwerkverkeer-gerelateerde anomalies/puzzels (en op devices zoeken naar de oorzaak natuurlijk). Als het niet te ver reizen is en je het op prijs zou stellen, wil ik evt. ook wel eens (kostenloos) langskomen - ter lering ende vermaeck :-)
Affijn, leerzaam draadje weer dit!
@TS: mocht je vertrouwelijk over dit onderwerp van gedachten willen wisselen, mijn e-mailadres is te vinden in https://www.security.nl/profile?alias=Erik+van+Straten. Net zoals veel van de sans.edu mensen ben ook ik een "got packets?" type die dol is op netwerkverkeer-gerelateerde anomalies/puzzels (en op devices zoeken naar de oorzaak natuurlijk). Als het niet te ver reizen is en je het op prijs zou stellen, wil ik evt. ook wel eens (kostenloos) langskomen - ter lering ende vermaeck :-)
Affijn, leerzaam draadje weer dit!
Door Anoniem: Ok. Netwerktechnisch best raar, een connectie naar een lokaal (niet via gateway) IP met als source iets dat buiten het subnet valt .
Nee, dat wordt APIPA (Automatic Private IP Addressing) genoemd en bestond al voordat "de cloud" het ging ge-(mis-)bruiken.Als bijv. een server al een "regulier" RFC1918 IP-adres van DHCP gekregen heeft (of sowieso een fixed adres heeft), en DHCP valt uit, dan kunnen daarna opgestarte PC's mogelijk toch met die server communiceren. Of dat dan allemaal nog heel betrouwbaar, zinvol en veilig is, is een andere discussie (persoonlijk vind ik het waardeloos).
Aanvulling 12:07: meer info in https://learn.microsoft.com/en-us/windows-server/troubleshoot/how-to-use-automatic-tcpip-addressing-without-a-dh. En dat het "oud" is, blijkt wel uit:
You can also determine whether your computer is using APIPA by using the Winipcfg tool in Windows Millennium Edition, Windows 98, or Windows 98 Second Edition: [...]
Door Erik van Straten:
Als bijv. een server al een "regulier" RFC1918 IP-adres van DHCP gekregen heeft (of sowieso een fixed adres heeft), en DHCP valt uit, dan kunnen daarna opgestarte PC's mogelijk toch met die server communiceren. Of dat dan allemaal nog heel betrouwbaar, zinvol en veilig is, is een andere discussie (persoonlijk vind ik het waardeloos).
Door Anoniem: Ok. Netwerktechnisch best raar, een connectie naar een lokaal (niet via gateway) IP met als source iets dat buiten het subnet valt .
Nee, dat wordt APIPA (Automatic Private IP Addressing) genoemd en bestond al voordat "de cloud" het ging ge-(mis-)bruiken.Als bijv. een server al een "regulier" RFC1918 IP-adres van DHCP gekregen heeft (of sowieso een fixed adres heeft), en DHCP valt uit, dan kunnen daarna opgestarte PC's mogelijk toch met die server communiceren. Of dat dan allemaal nog heel betrouwbaar, zinvol en veilig is, is een andere discussie (persoonlijk vind ik het waardeloos).
Je begrijpt niet wat ik als raar omschrijf .
auto-assigned IP is niks (of niet veel) raars aan.
Maak het een ander probleem :
Subnet 192.168.30.0/24 .
Jouw IP : 192.168.30.33
gateway : 192.168.30.254
Op het "subnet" (netwerk segment/broadcast domain/vlan) zit ook een device 172.16.30.254 .
En laat nu je IP stack direct (dus met arp query voor 172.16.30.254) 172.16.30.254 connecten met source IP 192.168.30.33 .
_dat_ is best onverwacht , puur met de netwerk pet op waarin je verwacht dat je communiceert met iets dat binnen je IP subnet valt, of _via_ een gateway die ook binnen je subnet valt .
Ik had eerder verwacht dat de connectie met 169.254.169.254 gemaakt zou zijn vanaf een 'eigen' 169.254.x.y adres van de PC .
Door Anoniem:
...
Het komt van "al onze PC's". Die zijn allemaal geinstalleerd van een schoon Windows image van Microsoft en vervolgens geadopteerd door een INTUNE omgeving waarin meer software geinstalleerd wordt (Office 365 enzo) en policies en andere settings gedaan worden.
...
Laat een ding duidelijk zijn: deze systemen hebben NIETS met Azure van doen.
...
Dat protocol is blijkbaar bedacht/gebruikt/standaard aanwezig in/op/voor Azure images .
Dan wordt de vraag, waarom is het aangezet/aangebleven op je lokale installaties .
Systemen gebouwd met een van Azure afkomstig image leek me een mooie theorie om dat te verklaren.
Computers die via Intune beheert worden maken ook contact met Azure volgens mij, want in Azure (of Entry zoals MS het tegenwoordig noemt) staan de rechten ingesteld die de gebruiker en de machine hebben, in de webinterface is Intune onderdeel van Azure AD/Entry....
Het komt van "al onze PC's". Die zijn allemaal geinstalleerd van een schoon Windows image van Microsoft en vervolgens geadopteerd door een INTUNE omgeving waarin meer software geinstalleerd wordt (Office 365 enzo) en policies en andere settings gedaan worden.
...
Laat een ding duidelijk zijn: deze systemen hebben NIETS met Azure van doen.
...
Dat protocol is blijkbaar bedacht/gebruikt/standaard aanwezig in/op/voor Azure images .
Dan wordt de vraag, waarom is het aangezet/aangebleven op je lokale installaties .
Systemen gebouwd met een van Azure afkomstig image leek me een mooie theorie om dat te verklaren.
Zaken die in de achtergrond aflopen (tenminste als hierboven geschetst niet voor iedereen).
Je ziet het ook niet in de event viewer.
Is dit nu ook juist niet een aspect, dat een van de zaken weergeeft, die eindgebruikers parten speelt "in de cloud"?
Wat ik daarmee bedoel is - er gebeurt steeds meer aan de andere kant van een device-schermpje.
Zaken, waar de eindgebruikers moeite mee zouden kunnen hebben, als ze er weet van hadden.
(tracken en monitoren voor profijt). Of interpreteer ik het nu helemaal verkeerd?
Je ziet het ook niet in de event viewer.
Is dit nu ook juist niet een aspect, dat een van de zaken weergeeft, die eindgebruikers parten speelt "in de cloud"?
Wat ik daarmee bedoel is - er gebeurt steeds meer aan de andere kant van een device-schermpje.
Zaken, waar de eindgebruikers moeite mee zouden kunnen hebben, als ze er weet van hadden.
(tracken en monitoren voor profijt). Of interpreteer ik het nu helemaal verkeerd?
Door wallum:
Computers die via Intune beheert worden maken ook contact met Azure volgens mij, want in Azure (of Entry zoals MS het tegenwoordig noemt) staan de rechten ingesteld die de gebruiker en de machine hebben, in de webinterface is Intune onderdeel van Azure AD/Entry.
Ja uiteraard dat wel. Maar dit gaat niet over contact met Azure servers "over internet", maar over het gebruik van de Azure Instance Metadata Service via adres 169.254.169.254.Computers die via Intune beheert worden maken ook contact met Azure volgens mij, want in Azure (of Entry zoals MS het tegenwoordig noemt) staan de rechten ingesteld die de gebruiker en de machine hebben, in de webinterface is Intune onderdeel van Azure AD/Entry.
Dat zou een standalone PC niet moeten doen, alleen een virtuele machine in de Azure cloud kan daar iets mee.
(en ook in andere cloud omgevingen zoals AWS wordt die zelfde methode gebruikt)
08-08-2023, 14:12 door
Erik van Straten
Door Anoniem: Je begrijpt niet wat ik als raar omschrijf .
Jawel hoor. Het enige dat m.i. "raar" is, is dat ook in het deel van de gevallen dat Windows in de output van route print géén route voor 169.254.*.* laat zien, zo'n route wel degelijk blijkt te bestaan (d.w.z. "treat as local").Dat "raar" tussen aanhalingstekens, want Microsoft houdt zich vaker niet aan gangbare standaarden (waardoor je je soms suf zoekt).
08-08-2023, 14:57 door
Erik van Straten
Door Anoniem: Maar dit gaat niet over contact met Azure servers "over internet", maar over het gebruik van de Azure Instance Metadata Service via adres 169.254.169.254.
Dat zou een standalone PC niet moeten doen, alleen een virtuele machine in de Azure cloud kan daar iets mee.
Sterker, zoals ik in mijn eerste reactie aanhaalde:Dat zou een standalone PC niet moeten doen, alleen een virtuele machine in de Azure cloud kan daar iets mee.
Communication between the VM and IMDS never leaves the host.
Als ik het goed begrijp is de bedoeling iets als volgt:
LAN/WiFi • 169.254.169.254
^ •
| • 10.1.2.3 • • 10.2.3.4
| • • •
| • .—————————————•————•—————————————.
| • | Host • • |
| • | • +———[VNIC][VM1] |
+—————[NIC] [IMDS] • | |
| | [VNIC]—————+———[VNIC][VM2] |
| | | |
| | virtueel netw. +———[VNIC][VM3] |
| | binnen host |
| '————————————————————————————————'
v
^ •
| • 10.1.2.3 • • 10.2.3.4
| • • •
| • .—————————————•————•—————————————.
| • | Host • • |
| • | • +———[VNIC][VM1] |
+—————[NIC] [IMDS] • | |
| | [VNIC]—————+———[VNIC][VM2] |
| | | |
| | virtueel netw. +———[VNIC][VM3] |
| | binnen host |
| '————————————————————————————————'
v
Oftewel, je hoort geen (ARPs voor) 169.254.169.254 op je LAN/WiFi te zien.
Nog sterker: als ik Microsoft goed begrijp zouden lokale VM's die, via een VPN, met een IMDS server in Azure willen communiceren, daar adres 168.63.129.16 voor moeten gebruiken. Dus als TS (onbedoeld) iets met Azure zou doen, zou ik eerder 168.63.129.16 op zijn/haar LAN verwachten dan 169.254.169.254.
09-08-2023, 10:46 door
Erik van Straten
Ter aanvulling op mijn laatste post: mocht iets in jouw netwerk verbinding willen maken met 168.63.129.16, dan zie je natuurlijk geen ARP-request voor dat IP-adres, maar hooguit voor jouw internet router (default gateway) - want 168.63.129.16 is een publiek IP-adres.
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren, en bij voorkeur om ergens een alarm te laten afgaan als verkeer naar dat IP-adres wordt geblokkeerd (vooral als notebooks e.d. ook buiten "het pand" worden gebruikt).
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren, en bij voorkeur om ergens een alarm te laten afgaan als verkeer naar dat IP-adres wordt geblokkeerd (vooral als notebooks e.d. ook buiten "het pand" worden gebruikt).
Door Erik van Straten:
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Wat wel handig is, is dat we alle internet connecties loggen met netflow. Daardoor kan ik zien dat er niet met dat adres wordt gecommuniceerd, in het afgelopen half jaar...Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
09-08-2023, 13:04 door
Erik van Straten
Door Anoniem:
Sorry, ik had duidelijker moeten maken dat mijn laatste posts voor elke geïnteresseerde zijn bedoeld, niet persé alleen voor de TS.Door Erik van Straten:
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Wat wel handig is, is dat we alle internet connecties loggen met netflow. Daardoor kan ik zien dat er niet met dat adres wordt gecommuniceerd, in het afgelopen half jaar...Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Maar prima dat je (vermoedelijk de TS) logt met netflow en e.e.a. hebt nagekeken!
Aan alle geïnteresseerden: denk goed na voordat je adviezen (zoals in [1]) om alle verkeer vanaf 168.63.129.16 in firewalls toe te staan, klakkeloos overneemt, bijvoorbeeld om "Azure Load Balancer health probes" ([2]) door te laten. Als iemand "upstream" zich voor kan doen als 168.63.129.16, heb je de deur daar dan mogelijk wagenwijd voor opengezet ([3]).
Dit is precies wat ik eerder bedoelde met -nog steeds- niet implementeren van zero trust. Als één VM gecompromitteerd raakt, zijn er standaard veel mogelijkheden voor "lateral movement".
Bij 169.254.*.* adressen is dat risico zo mogelijk nog groter. Immers, elke fysieke of virtuele computer kan, by default en mogelijk onopgemerkt (omdat je zo'n adres niet verwacht), "losgaan" met zo'n adres in jouw LAN.
[1] https://microsoft.github.io/AzureTipsAndTricks/blog/tip242.html
[2] https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview?WT.mc_id=docs-azuredevtips-azureappsdev
[3] https://www.abuseipdb.com/check/168.63.129.16
Door Anoniem:
Door Erik van Straten:
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Wat wel handig is, is dat we alle internet connecties loggen met netflow. Daardoor kan ik zien dat er niet met dat adres wordt gecommuniceerd, in het afgelopen half jaar...Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Dat bedoelde ik dus met "anders" zoeken. Is dat netflow mogelijk de oorzaak van het verkeer?
Interessant: https://journeyofthegeek.com/2019/11/14/dns-in-microsoft-azure-part-1/
Ja ook over dit adres van learn.microsoft.com
Ja ook over dit adres van learn.microsoft.com
Door Anoniem:
Dat bedoelde ik dus met "anders" zoeken. Is dat netflow mogelijk de oorzaak van het verkeer?
Door Anoniem:
Door Erik van Straten:
Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Wat wel handig is, is dat we alle internet connecties loggen met netflow. Daardoor kan ik zien dat er niet met dat adres wordt gecommuniceerd, in het afgelopen half jaar...Het is wellicht een goed idee om alle uitgaande verkeer naar 168.63.129.16 in je internet router te blokkeren
Dat bedoelde ik dus met "anders" zoeken. Is dat netflow mogelijk de oorzaak van het verkeer?
Als je niet weet wat netflow is, waarom zoek je dat niet op, in plaats van onzinnige speculaties te gaan zitten doen ?
Netflow analyzer - software voor bewaking van het netwerkverkeer voor diepgaande verkeersanalyse
NetFlow Analyzer biedt compleet inzicht in het bandbreedtegebruik, verkeer, applicatieprestaties, apparatuur, interfaces, IP's, draadloos netwerk, WAN-links, SSID's en toegangspunten. NetFlow Analyzer ondersteunt ook verschillende Cisco-technologieën, zoals NBAR, CBQoS, AVC en IP SLA. En is er ook als mobiele applicatie.
luntrus
NetFlow Analyzer biedt compleet inzicht in het bandbreedtegebruik, verkeer, applicatieprestaties, apparatuur, interfaces, IP's, draadloos netwerk, WAN-links, SSID's en toegangspunten. NetFlow Analyzer ondersteunt ook verschillende Cisco-technologieën, zoals NBAR, CBQoS, AVC en IP SLA. En is er ook als mobiele applicatie.
luntrus
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
