22
ICMP-Datenströme in der Netzwerkaufzeichnung
Infos: Siehe auch den folgenden Beitrag als Ergänzung dazu
Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
Hallo,
kann einer die folgenden TCP/IP-Datenströme per ICMP-Protokoll deuten?
Dies ist heute um die Mittagszeit in der Netzwerkaufzeichnung aufgetaucht, während des Abrufs von Spam-Nachrichten.
Alle Index-Abschnitte weisen die folgenden Eigenschaften auf:
• Protokoll: ICMP
• Prozess-ID: unbekannt
• Dienstname: unbekannt
• Ferne MAC-Adresse: 40-f3-08-18-68-be
Index 13
Fernadresse: 162.19.58.158
E..0Z=@.q..#..+
..:..3...P."....p. .'......P....E..0ZF@.q.....+
..:..3...P."....p. .'......P....E..0ZO@.q.....+
..:..3...P."....p. .'......P....
Index 14
Fernadresse: 162.19.58.157
E..0Z@@.q..!..+
..:..4..........p. .j......P....E..0ZI@.q.....+
..:..4..........p. .j......P....E..0ZR@.q.....+
..:..4..........p. .j......P....
Index 15
Fernadresse: 162.19.58.156
E..0ZC@.q.....+
..:..7....}.....p. .8......P....E..0ZJ@.q.....+
..:..7....}.....p. .8......P....E..0ZS@.q.....+
..:..7....}.....p. .8......P....
Index 16
Fernadresse: 162.19.58.160
E..0ZB@.q.....+
..:..6.....A....p. ........P....E..0ZH@.q.....+
..:..6.....A....p. ........P....E..0ZQ@.q..
..+
..:..6.....A....p. ........P....
Index 17
Fernadresse: 162.19.58.159
E..0ZA@.q.....+
..:..5...\K.....p. .. .....P....E..0ZG@.q.....+
..:..5...\K.....p. .. .....P....E..0ZP@.q.....+
..:..5...\K.....p. .. .....P....
Index 18
Fernadresse: 162.19.58.161
E..0ZD@.q.....+
..:..8...C~.....p. ........P....E..0ZK@.q.....+
..:..8...C~.....p. ........P....E..0ZT@.q.. ..+
..:..8...C~.....p. ........P....Während dieser Aufzeichnung trat eine ungewöhnlich lange Verzögerung auf, von etwa 30 ... 60 Sekunden, weswegen ich hier gezielt auf diesen Datenströmungsabschnitt fokussiere.
(Im Index davor wurde durch den Dienst "domain" eine Domäne aufgelöst, jedoch ohne weitere Datenströme. Nähere Angaben dann bei Bedarf.)
Vielen Dank für den Versuch
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5019727283
Url: https://administrator.de/contentid/5019727283
Ausgedruckt am: 25.11.2024 um 02:11 Uhr
22 Kommentare
Neuester Kommentar
Was sollen "TCP-Datenströme per ICMP-Protokoll" sein?
Details wird man mit den Daten nicht beantworten können. ICMP kann alles sein, von Ping zu Port unreachable, zu Network unreachable, zu Administratively prohibited, zu Packet too big...
Das, was wir da sehen, ist leider für jedweden Zweck unbrauchbar, sorry. Wo kommt sowas her?
Wenn, dann müsste man ein ordentliches PCAP haben (z.B. von Wireshark), zumindest aber keine ASCII-Representation sondern HEX, um die ICMP-Codes zu sehen.
PCAP ist aber das bevorzugte Mittel, denn da kannst du in Wireshark die Flows filtern und siehst genau, welches Paket welches andere ausgelöst hat.
Details wird man mit den Daten nicht beantworten können. ICMP kann alles sein, von Ping zu Port unreachable, zu Network unreachable, zu Administratively prohibited, zu Packet too big...
Das, was wir da sehen, ist leider für jedweden Zweck unbrauchbar, sorry. Wo kommt sowas her?
Wenn, dann müsste man ein ordentliches PCAP haben (z.B. von Wireshark), zumindest aber keine ASCII-Representation sondern HEX, um die ICMP-Codes zu sehen.
PCAP ist aber das bevorzugte Mittel, denn da kannst du in Wireshark die Flows filtern und siehst genau, welches Paket welches andere ausgelöst hat.
1
Hallo,
im ICMP-Protokoll gibt es ein buffer-overflow-error. Erkennbar wird ein Angriff aber nur auf einem detailierteren Level:
Sans "Packet Tueday"
mfg
im ICMP-Protokoll gibt es ein buffer-overflow-error. Erkennbar wird ein Angriff aber nur auf einem detailierteren Level:
Sans "Packet Tueday"
mfg
Zitat von @Fennek11:
im ICMP-Protokoll gibt es ein buffer-overflow-error. Erkennbar wird ein Angriff aber nur auf einem detailierteren Level:
im ICMP-Protokoll gibt es ein buffer-overflow-error. Erkennbar wird ein Angriff aber nur auf einem detailierteren Level:
a) Dieses Problem ist kein Problem im "ICMP-Protokoll" sondern tritt auf, wenn du vor einem FreeBSD-System sitzt, dort mit dem Ping-Befehl aktiv etwas anpingst und die Gegenstelle dir böse Antworten liefert. Das Problem liegt im Programm "ping".
b) Es wird kein Schadcode ausgeführt, ist also realistisch betrachtet kein lohnender Angriff.
Aus den Daten, die der TO liefert, kann man aber nichtmal erkennen, von wo überhaupt die ICMP-Nachricht kam, geschweige denn, wodurch sie ausgelöst wurde oder was drin steht.
sorry wegen "TCP-Datenströme per ICMP-Protokoll", da beim Export über TCP/IP-Datenströme exportieren die Rede ist.
HEX-Dump ist natürlich dabei, jedoch habe ich dies übersichtshalber hier erstmals weggelassen.
Es geht über Npcap.
HEX-Dump ist natürlich dabei, jedoch habe ich dies übersichtshalber hier erstmals weggelassen.
Es geht über Npcap.
Hast du das als Datei irgendwo liegen? Dann kannst du das in Wireshark werfen und genauer sehen, was da passiert. Wäre die einfachste Lösung, notfalls kannst du gerne auch Screenshots davon hier teilen.
Aus den Daten, die der TO liefert, kann man aber nichtmal erkennen, von wo überhaupt die ICMP-Nachricht kam, geschweige denn, wodurch sie ausgelöst wurde oder was drin steht.
Schade eigentlich, aber mehr Daten werden speziell in diesem Fall nicht geliefert, weswegen ich besonders skeptisch geworden war. Bei anderen Prozesse wird der vollständige Pfad oder zumindest die Prozess-ID angezeigt, jedoch in diesem Fall hier gar nichts.
Zitat von @LordGurke:
Hast du das als Datei irgendwo liegen? Dann kannst du das in Wireshark werfen und genauer sehen, was da passiert. Wäre die einfachste Lösung, notfalls kannst du gerne auch Screenshots davon hier teilen.
Hast du das als Datei irgendwo liegen? Dann kannst du das in Wireshark werfen und genauer sehen, was da passiert. Wäre die einfachste Lösung, notfalls kannst du gerne auch Screenshots davon hier teilen.
Ach, ich habe es leider nur als HTML exportiert, jedoch die Aufzeichnung mittlerweile neu-gestartet, weil es den RAM belastet. Davor hatte ich es in HEX angeschaut, aber wie gesagt, rechts wurde mir absolut dasselbe im Klartext wie oben angezeigt. Mehr Daten gab es (vermutlich) nicht.
Ich kann höchstens den HTML-Bericht als Datei irgendwie hochladen, weil ihn hier als Text einzufügen wegen Formatierungsverlust zu durcheinander wird.
Der MAC-Adresse nach zu urteilen steht da keine besonders ausgefeilte Firewall? Die gehört zu "Murata Manufacturing", ein Semiconductor für verschiedene Chips, die dann in allen möglichen (eher preisgünstigen) Geräten verbaut werden.
Die IP 162.19.58.158 liegt bei OVH (nicht ganz unbekannt für Spamversand) und reagiert mit "ICMP administratively prohibited" darauf, wenn man an Ports anklopft, die durch die Firewall auf dem System gefiltert sind.
Die Vermutung liegt nahe, dass aus der Spam-Mail ein Bild nachgeladen werden sollte um zu gucken, ob jemand diese Mails liest. Dazu wurde Kontakt mit einer URL auf dieser IP-Adresse aufgenommen, da war aus irgendeinem Grund aber noch dieser Port gefiltert und so kam es zur "ICMP administratively prohibited"-Nachricht.
Die IP 162.19.58.158 liegt bei OVH (nicht ganz unbekannt für Spamversand) und reagiert mit "ICMP administratively prohibited" darauf, wenn man an Ports anklopft, die durch die Firewall auf dem System gefiltert sind.
Die Vermutung liegt nahe, dass aus der Spam-Mail ein Bild nachgeladen werden sollte um zu gucken, ob jemand diese Mails liest. Dazu wurde Kontakt mit einer URL auf dieser IP-Adresse aufgenommen, da war aus irgendeinem Grund aber noch dieser Port gefiltert und so kam es zur "ICMP administratively prohibited"-Nachricht.
1
ich hab's! Gerade dasselbe erneut aufgetreten!
Auch hier wurde erstmals die Domäne i.ibb.co aufgelöst und danach ähnlich wie oben.
Genau ab diesem Moment wurde der Rechner wieder lahm gelegt. Oben habe ich es erstmals nicht erwähnt, da es Zufall sein könnte. Der Windows Explorer funktioniert dann ca. 5 Min. lang nicht mehr und alles reagiert dann sehr träge, jedoch ohne CPU-Auslastung. Das ist auf jeden Fall nicht normal und dies kommt sonst wie gar nicht vor, zumindest nicht auf diesem Rechner (da es sicherheitsmäßig nach dem aktuellen Wissen soweit es gelingt stets gepflegt wird).
Anbei diesmal alles als Hex (bloß die Nummerierung beachten - ist absteigend!):
Auch hier wurde erstmals die Domäne i.ibb.co aufgelöst und danach ähnlich wie oben.
Genau ab diesem Moment wurde der Rechner wieder lahm gelegt. Oben habe ich es erstmals nicht erwähnt, da es Zufall sein könnte. Der Windows Explorer funktioniert dann ca. 5 Min. lang nicht mehr und alles reagiert dann sehr träge, jedoch ohne CPU-Auslastung. Das ist auf jeden Fall nicht normal und dies kommt sonst wie gar nicht vor, zumindest nicht auf diesem Rechner (da es sicherheitsmäßig nach dem aktuellen Wissen soweit es gelingt stets gepflegt wird).
Anbei diesmal alles als Hex (bloß die Nummerierung beachten - ist absteigend!):
==================================================
Index : 130
Protokoll : ICMP
Fernadresse : 162.19.58.160
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 1 {0 ; 1}
Datengröße : 48 Byte {0 ; 48}
Gesamtgröße : 152 Byte {0 ; 152}
Datendurchsatz : 2.9 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:56:258
Zeit des letzten Pakets: 19.12.2022 15:26:56:258
Dauer : 00:00:00.000
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 BE 40 00 71 06 2D A1 C0 A8 2B 0D E..0.¾@. q.-¡À¨+.
00000010 A2 13 3A A0 FE BA 01 BD A6 98 B7 74 00 00 00 00 ¢.: þº.½ ¦˜·t....
00000020 70 02 20 00 E8 93 00 00 02 04 05 50 01 01 04 02 p. .è“.. ...P....
==================================================
Index : 129
Protokoll : ICMP
Fernadresse : 162.19.58.161
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 2 {0 ; 2}
Datengröße : 96 Byte {0 ; 96}
Gesamtgröße : 228 Byte {0 ; 228}
Datendurchsatz : 0.0 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:56:258
Zeit des letzten Pakets: 19.12.2022 15:27:23:168
Dauer : 00:00:26.910
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 BD 40 00 71 06 2D A1 C0 A8 2B 0D E..0.½@. q.-¡À¨+.
00000010 A2 13 3A A1 FE B9 01 BD 0D 2F A1 EE 00 00 00 00 ¢.:¡þ¹.½ ./¡î....
00000020 70 02 20 00 97 83 00 00 02 04 05 50 01 01 04 02 p. .—ƒ.. ...P....
00000030 45 00 00 30 13 E8 40 00 71 06 2D 76 C0 A8 2B 0D E..0.è@. q.-vÀ¨+.
00000040 A2 13 3A A1 FE B9 01 BD 0D 2F A1 EE 00 00 00 00 ¢.:¡þ¹.½ ./¡î....
00000050 70 02 20 00 97 83 00 00 02 04 05 50 01 01 04 02 p. .—ƒ.. ...P....
==================================================
Index : 128
Protokoll : ICMP
Fernadresse : 162.19.58.157
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 3 {0 ; 3}
Datengröße : 144 Byte {0 ; 144}
Gesamtgröße : 304 Byte {0 ; 304}
Datendurchsatz : 0.0 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:56:258
Zeit des letzten Pakets: 19.12.2022 15:27:05:278
Dauer : 00:00:09.020
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 BA 40 00 71 06 2D A8 C0 A8 2B 0D E..0.º@. q.-¨À¨+.
00000010 A2 13 3A 9D FE B6 01 BD 5E 1F 7C 7F 00 00 00 00 ¢.:þ¶.½ ^.|....
00000020 70 02 20 00 6C 09 00 00 02 04 05 50 01 01 04 02 p. .l... ...P....
00000030 45 00 00 30 13 CB 40 00 71 06 2D 97 C0 A8 2B 0D E..0.Ë@. q.-—À¨+.
00000040 A2 13 3A 9D FE B6 01 BD 5E 1F 7C 7F 00 00 00 00 ¢.:þ¶.½ ^.|....
00000050 70 02 20 00 6C 09 00 00 02 04 05 50 01 01 04 02 p. .l... ...P....
00000060 45 00 00 30 13 CE 40 00 71 06 2D 94 C0 A8 2B 0D E..0.Î@. q.-”À¨+.
00000070 A2 13 3A 9D FE B6 01 BD 5E 1F 7C 7F 00 00 00 00 ¢.:þ¶.½ ^.|....
00000080 70 02 20 00 6C 09 00 00 02 04 05 50 01 01 04 02 p. .l... ...P....
==================================================
Index : 127
Protokoll : ICMP
Fernadresse : 162.19.58.156
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 1 {0 ; 1}
Datengröße : 48 Byte {0 ; 48}
Gesamtgröße : 152 Byte {0 ; 152}
Datendurchsatz :
Aufzeichnungszeit : 19.12.2022 15:26:56:258
Zeit des letzten Pakets: 19.12.2022 15:26:56:258
Dauer : 00:00:00.000
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 BB 40 00 71 06 2D A8 C0 A8 2B 0D E..0.»@. q.-¨À¨+.
00000010 A2 13 3A 9C FE B7 01 BD 5C AC C4 C9 00 00 00 00 ¢.:œþ·.½ \¬ÄÉ....
00000020 70 02 20 00 25 32 00 00 02 04 05 50 01 01 04 02 p. .%2.. ...P....
==================================================
Index : 126
Protokoll : ICMP
Fernadresse : 162.19.58.158
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 2 {0 ; 2}
Datengröße : 96 Byte {0 ; 96}
Gesamtgröße : 228 Byte {0 ; 228}
Datendurchsatz : 0.0 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:56:258
Zeit des letzten Pakets: 19.12.2022 15:27:23:168
Dauer : 00:00:26.910
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 BC 40 00 71 06 2D A5 C0 A8 2B 0D E..0.¼@. q.-¥À¨+.
00000010 A2 13 3A 9E FE B8 01 BD 78 8B 17 84 00 00 00 00 ¢.:žþ¸.½ x‹.„....
00000020 70 02 20 00 B6 95 00 00 02 04 05 50 01 01 04 02 p. .¶•.. ...P....
00000030 45 00 00 30 13 E6 40 00 71 06 2D 7B C0 A8 2B 0D E..0.æ@. q.-{À¨+.
00000040 A2 13 3A 9E FE B8 01 BD 78 8B 17 84 00 00 00 00 ¢.:žþ¸.½ x‹.„....
00000050 70 02 20 00 B6 95 00 00 02 04 05 50 01 01 04 02 p. .¶•.. ...P....
==================================================
Index : 125
Protokoll : ICMP
Fernadresse : 162.19.58.159
Lokalanschluss :
Fernanschluss :
Fernhost :
Dienstname :
Pakete : 3 {0 ; 3}
Datengröße : 144 Byte {0 ; 144}
Gesamtgröße : 304 Byte {0 ; 304}
Datendurchsatz : 0.0 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:55:228
Zeit des letzten Pakets: 19.12.2022 15:27:04:388
Dauer : 00:00:09.160
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 45 00 00 30 13 B9 40 00 71 06 2D A7 C0 A8 2B 0D E..0.¹@. q.-§À¨+.
00000010 A2 13 3A 9F FE B5 01 BD 15 D8 C5 1F 00 00 00 00 ¢.:Ÿþµ.½ .ØÅ.....
00000020 70 02 20 00 6B AF 00 00 02 04 05 50 01 01 04 02 p. .k¯.. ...P....
00000030 45 00 00 30 13 BF 40 00 71 06 2D A1 C0 A8 2B 0D E..0.¿@. q.-¡À¨+.
00000040 A2 13 3A 9F FE B5 01 BD 15 D8 C5 1F 00 00 00 00 ¢.:Ÿþµ.½ .ØÅ.....
00000050 70 02 20 00 6B AF 00 00 02 04 05 50 01 01 04 02 p. .k¯.. ...P....
00000060 45 00 00 30 13 CD 40 00 71 06 2D 93 C0 A8 2B 0D E..0.Í@. q.-“À¨+.
00000070 A2 13 3A 9F FE B5 01 BD 15 D8 C5 1F 00 00 00 00 ¢.:Ÿþµ.½ .ØÅ.....
00000080 70 02 20 00 6B AF 00 00 02 04 05 50 01 01 04 02 p. .k¯.. ...P....
==================================================
Index : 124
Protokoll : UDP
Fernadresse : 192.168.43.1
Lokalanschluss : 50184
Fernanschluss : 53
Fernhost :
Dienstname : domain
Pakete : 2 {1 ; 1}
Datengröße : 148 Byte {26 ; 122}
Gesamtgröße : 258 Byte {54 ; 204}
Datendurchsatz : 0.7 KB/s
Aufzeichnungszeit : 19.12.2022 15:26:54:978
Zeit des letzten Pakets: 19.12.2022 15:26:55:188
Dauer : 00:00:00.210
Prozess-ID :
Prozessdateiname :
Heimatland Fern-IP:
Heimatland Lokal-IP:
Lokaladresse : 192.168.43.13
Lokalhost :
Prozessnutzer :
Ferne MAC-Adresse : 40-f3-08-18-68-be
Lokale MAC-Adresse: gelöscht
==================================================
00000000 11 B6 01 00 00 01 00 00 00 00 00 00 01 69 03 69 .¶...... .....i.i
00000010 62 62 02 63 6F 00 00 01 00 01 bb.co... ..
00000000 11 B6 81 80 00 01 00 06 00 00 00 00 01 69 03 69 .¶€.... .....i.i
00000010 62 62 02 63 6F 00 00 01 00 01 C0 0C 00 01 00 01 bb.co... ..À.....
00000020 00 00 0D 6B 00 04 A2 13 3A 9F C0 0C 00 01 00 01 ...k..¢. :ŸÀ.....
00000030 00 00 0D 6B 00 04 A2 13 3A 9D C0 0C 00 01 00 01 ...k..¢. :À.....
00000040 00 00 0D 6B 00 04 A2 13 3A 9C C0 0C 00 01 00 01 ...k..¢. :œÀ.....
00000050 00 00 0D 6B 00 04 A2 13 3A 9E C0 0C 00 01 00 01 ...k..¢. :žÀ.....
00000060 00 00 0D 6B 00 04 A2 13 3A A1 C0 0C 00 01 00 01 ...k..¢. :¡À.....
00000070 00 00 0D 6B 00 04 A2 13 3A A0 ...k..¢. : Zitat von @LordGurke:
Der MAC-Adresse nach zu urteilen steht da keine besonders ausgefeilte Firewall? Die gehört zu "Murata Manufacturing", ein Semiconductor für verschiedene Chips, die dann in allen möglichen (eher preisgünstigen) Geräten verbaut werden.
Die IP 162.19.58.158 liegt bei OVH (nicht ganz unbekannt für Spamversand) und reagiert mit "ICMP administratively prohibited" darauf, wenn man an Ports anklopft, die durch die Firewall auf dem System gefiltert sind.
Die Vermutung liegt nahe, dass aus der Spam-Mail ein Bild nachgeladen werden sollte um zu gucken, ob jemand diese Mails liest. Dazu wurde Kontakt mit einer URL auf dieser IP-Adresse aufgenommen, da war aus irgendeinem Grund aber noch dieser Port gefiltert und so kam es zur "ICMP administratively prohibited"-Nachricht.
Der MAC-Adresse nach zu urteilen steht da keine besonders ausgefeilte Firewall? Die gehört zu "Murata Manufacturing", ein Semiconductor für verschiedene Chips, die dann in allen möglichen (eher preisgünstigen) Geräten verbaut werden.
Die IP 162.19.58.158 liegt bei OVH (nicht ganz unbekannt für Spamversand) und reagiert mit "ICMP administratively prohibited" darauf, wenn man an Ports anklopft, die durch die Firewall auf dem System gefiltert sind.
Die Vermutung liegt nahe, dass aus der Spam-Mail ein Bild nachgeladen werden sollte um zu gucken, ob jemand diese Mails liest. Dazu wurde Kontakt mit einer URL auf dieser IP-Adresse aufgenommen, da war aus irgendeinem Grund aber noch dieser Port gefiltert und so kam es zur "ICMP administratively prohibited"-Nachricht.
Bingo! So ist es und ich freue mich sehr über diese Bestätigung. Das Nachladen von Bildern ist in diesem Outlook-Client global für alle E-Mails gesperrt.
Jedes Mal, wenn ich auf so eine seltsame Nachricht umschalte (nicht alle, sondern nur solche, welche ein Bild nachlädt, wie du oben schiebst) einsteht eine Verzögerung in Outlook mit globalen Auswirkungen im gesamten Windows System.
Und so sieht der Quelltext so einer problematischen SPAM-Nachricht dann aus:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="format-detection" content="telephone=no">
<meta name="format-detection" content="date=no">
<meta name="format-detection" content="address=no">
<meta name="format-detection" content="email=no">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>Media Markt 1000€ Gutschein + Samsung Galaxy S21 5G</title>
<style type="text/css">
body {Margin:0 auto; padding:0;}
img {max-width:100%;}
table {border-spacing:0!important; border:none; cellpadding:0px; }
td {cellpadding:0px; border-spacing:0px;}
tr {cellpadding:0px; border-spacing:0px;}
/* Client-specific Styles */
#outlook a{padding:0;} /* Force Outlook to provide a "view in browser" message */
.ReadMsgBody{width:100%;} .ExternalClass{width:100%;} /* Force Hotmail to display emails at full width */
.ExternalClass, .ExternalClass p, .ExternalClass span, .ExternalClass font, .ExternalClass td, .ExternalClass div {line-height: 100%;} /* Force Hotmail to display normal line spacing */
body, table, td, a{-webkit-text-size-adjust:100%; -ms-text-size-adjust:100%;} /* Prevent WebKit and Windows mobile changing default text sizes */
table, td{mso-table-lspace:0pt; mso-table-rspace:0pt;} /* Remove spacing between tables in Outlook 2007 and up */
img{-ms-interpolation-mode:bicubic;} /* Allow smoother rendering of resized image in Internet Explorer */
</style>
</head>
<body bgcolor="#f2f2f2">
<!-- GK: container -->
<table width="100%" border="0" cellpadding="0" cellspacing="0" id="wrappertable" style="table-layout: fixed;">
<tr>
<td align="center" valign="top">
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td width="600" align="center" valign="top" style="background-color: #ffffff; box-shadow: 11px 11px 49px 0px rgba(0, 0, 0, 0.5); ">
<!-- GK: image-->
<table width="100%" cellpadding="0" cellspacing="0" border="0" style="background-color: #ffffff; padding:0px 0px 10px 0px;">
<tr>
<td valign="middle" style=" line-height:1px;"></td>
</tr>
<tr>
<td align="center" valign="top" style="padding: 0 0px;">
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td width="600" align="center" valign="middle">
<a href="http://0xD2106584/cl/184486_md/1/11179/1833/300/63015" style="outline:0;" target="_blank"><img src="//i.ibb.co/HGWD4VP/newsletter-title-img.jpg" style="width: 100%; max-width: 100%;" border="0" alt=""></a>
</td>
</tr>
</table>
</td>
</tr>
</table>
<!-- GK: / image-->
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 20px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
<!--GK: text-->
<table width="100%" cellpadding="0" cellspacing="0" border="0" style="background-color: #ffffff; ">
<tr>
<td valign="middle" style="font-family:Arial, Helvetica, sans-serif; font-size:18px; font-weight:normal; line-height:24px; letter-spacing:0px; color:#414141; padding-left:10px; padding-right:10px; min-height:20px; mso-line-height-rule: exactly; padding: 0px 25px; ">
Pass gut auf_!<br>
<br>
Es gibt <strong>200 Mediamarkt-Gutscheine im Wert von 1000 Euro</strong>inklusive einem <strong> Samsung Galaxy S21 5G</strong>, doch niemand wird dir davon erzählen.<br>
<br>
Um einen dieser <strong>Gutscheine inklusive Samsung Galaxy</strong> zu gewinnen, musst du nur hier deine Daten bestätigen: <br>
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 10px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
<!-- GK: Button-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" valign="top" style="padding: 0 20px;"><table cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 5px; line-height: 0px;"></td>
</tr>
<tr>
<td width="360" align="center" valign="top"><table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td width="360" height="40" align="center" valign="middle" style="background-color: #000000; padding: 6px 12px;"><a style="display: block; text-decoration: none; font-family: 'Arial', verdana, sans-serif; font-size: 18px; mso-line-height-rule: exactly; line-height: 32px;font-weight: bold; text-transform: uppercase; color: #ffffff;" href="http://0xD2106584/cl/184486_md/1/11179/1833/300/63015" target="_blank"> Bestätigen ›</a></td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table>
<!-- GK: / Button-->
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 10px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 10px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
<strong>Deine Vorteile:</strong><br>
1. Die Bestätigung geht schnell, einfach und ist kostenlos <br>
2. Wir senden dir das Samsung Galaxy komplett kostenlos zu <br>
3. Der Gutschein ist direkt online einlösbar <br>
4. ...und anwendbar auf alle Produkte bei Mediamarkt <br>
<br>
Also, beeile dich!
<br>
Irina,<br>
Technischer Kundensupport
<br>
<br>
</td>
</tr>
</table>
<!--GK: / text-->
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 10px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
<!--GK: / spacer-->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding-top: 10px; line-height: 0px;"></td>
</tr>
</table>
<!--GK: / spacer-->
</td>
</tr>
</table></td>
</tr>
</table>
<!-- GK: container -->
</body>
</html>
<br><br><img alt="" src="http://0xD2106584/op/184486_md/1/11179/1833/300/63015" width="1px" height="1px" style="visibility:hidden">
aus der ganzen Sache habe ich jedoch gar kein Verständnis hierfür, dass Outlook trotz expliziter Deaktivierung zum automatischen Nachladen von Bildern dennoch die in HTML-Nachrichten eingebetteten Domänen auslöst. Also das ist absolut nicht verständlich. Es sind immer wieder Domänen, wie zupimages.net, i.goopics.net, i.imgur.com, optracc.com ..., welche auch von vielen anderen Webdiensten benutzt werden, sodass deren Deaktivierung in der HOSTS-Datei (bzw. in der Firewall) unter Umständen zu Überraschungen beim Surfen führen würde. Ich kann es dennoch erstmals damit beginnen und dann schauen wir mal ... Es sei denn ihr habt da elegantere Ideen, womit erstmals eher versucht werden sollte.
Wegen optracc.com ist zwar klar
Allerdings wegen Webdienste, welche allgemein für Bilder benutzt werden, bringen solche Sperrungen früher oder später auch Umstände mit sich. Mir scheint z. B. die Domäne i.goopics.net auf Anhieb von Google zu sein als Webdienst zum Hochladen und Veröffentlichen von Dateien allgemein für jeden, hab jedoch nicht weiter recherchiert, weil es primär nicht darum geht eine Webseite (gefährlich oder nicht gefährlich) zu blockieren, sondern vor allem darum die Schwäche in Outlook zu finden, warum überhaupt solche Domänen unerlaubt aufgelöst werden.
Für paar Tipps wäre ich euch sehr dankbar.
Wegen optracc.com ist zwar klar
Safe Web-Bericht für: optracc.com:443
https://safeweb.norton.com/report/show_mobile?name=optracc.com
Bedrohungsbericht
Dies ist eine bekannte gefährliche Webseite. Es wird dringend empfohlen, diese Seite nicht aufzurufen.
https://safeweb.norton.com/report/show_mobile?name=optracc.com
Bedrohungsbericht
Dies ist eine bekannte gefährliche Webseite. Es wird dringend empfohlen, diese Seite nicht aufzurufen.
Allerdings wegen Webdienste, welche allgemein für Bilder benutzt werden, bringen solche Sperrungen früher oder später auch Umstände mit sich. Mir scheint z. B. die Domäne i.goopics.net auf Anhieb von Google zu sein als Webdienst zum Hochladen und Veröffentlichen von Dateien allgemein für jeden, hab jedoch nicht weiter recherchiert, weil es primär nicht darum geht eine Webseite (gefährlich oder nicht gefährlich) zu blockieren, sondern vor allem darum die Schwäche in Outlook zu finden, warum überhaupt solche Domänen unerlaubt aufgelöst werden.
Für paar Tipps wäre ich euch sehr dankbar.
Irgendwie werde ich aus den Ausgaben nicht schlau. Woran erkennt man da üblicherweise, was ausgehender und was eingehender Traffic ist?
Kannst du das erneut provozieren, diesmal aber in eine PCAP-Datei aufzeichnen und das in Wireshark gießen? Oder gleich direkt mit Wireshark aufzeichnen?
Es könnte auch sein, dass die ICMP-Pakete von dir kommen, *WEIL* das System nicht reagiert und der Gegenstelle einer offenen TCP-Verbindungen von dir Nachrichten geschickt werden, dass du gerade nicht mehr mit ihr reden kannst.
Kannst du das erneut provozieren, diesmal aber in eine PCAP-Datei aufzeichnen und das in Wireshark gießen? Oder gleich direkt mit Wireshark aufzeichnen?
Es könnte auch sein, dass die ICMP-Pakete von dir kommen, *WEIL* das System nicht reagiert und der Gegenstelle einer offenen TCP-Verbindungen von dir Nachrichten geschickt werden, dass du gerade nicht mehr mit ihr reden kannst.
1Zitat von @LordGurke:
Irgendwie werde ich aus den Ausgaben nicht schlau. Woran erkennt man da üblicherweise, was ausgehender und was eingehender Traffic ist?
Irgendwie werde ich aus den Ausgaben nicht schlau. Woran erkennt man da üblicherweise, was ausgehender und was eingehender Traffic ist?
ach ... ganz einfach. Die ausgehende Ströme sind in einer Farbe formatiert während die ausgehende Ströme in einer anderen. Da ich jedoch oben als txt eingefügt habe, geht diese Information natürlich verloren.
in meiner Nachricht davor habe ich den Text übrigens ergänzt, während du mir bereits eine neue Nachricht geschickt hast.
Zitat von @LordGurke:
Kannst du das erneut provozieren, diesmal aber in eine PCAP-Datei aufzeichnen und das in Wireshark gießen? Oder gleich direkt mit Wireshark aufzeichnen?
Es könnte auch sein, dass die ICMP-Pakete von dir kommen, *WEIL* das System nicht reagiert und der Gegenstelle einer offenen TCP-Verbindungen von dir Nachrichten geschickt werden, dass du gerade nicht mehr mit ihr reden kannst.
Da bin ich sehr gespannt, weil es sich nach so etwas anfühlt. Eine Blockade.Kannst du das erneut provozieren, diesmal aber in eine PCAP-Datei aufzeichnen und das in Wireshark gießen? Oder gleich direkt mit Wireshark aufzeichnen?
Es könnte auch sein, dass die ICMP-Pakete von dir kommen, *WEIL* das System nicht reagiert und der Gegenstelle einer offenen TCP-Verbindungen von dir Nachrichten geschickt werden, dass du gerade nicht mehr mit ihr reden kannst.
Blöd ist nur, dass ich zwar hier Wireshark bereits installiert habe, jedoch noch keine Zeit gefunden habe es einzurichten und mich auseinander zu setzen. Wenn du mich konkret begleiten würdest, so Schritt für Schritt konkret, so werde ich das Problem erneut provozieren und so wie du es dir wünscht aufzeichnen können.
Wenn ich dir das HTML-Bericht 1:1 hier irgendwie anhängen könnte, so würde ich es gleich machen und dann lässt sich die Sache mit Ausgehend und Eingehend erkennen.
Ach übrigens. Es ist alles eingehend außer das hier:
Also dann haben wir zumindest das Rätsel mit Ein- und Ausgehend somit gelöst.
Ach übrigens. Es ist alles eingehend außer das hier:
00000000 11 B6 01 00 00 01 00 00 00 00 00 00 01 69 03 69 .¶...... .....i.i
00000010 62 62 02 63 6F 00 00 01 00 01 bb.co... ..Also dann haben wir zumindest das Rätsel mit Ein- und Ausgehend somit gelöst.
Hallo,
im gezeigten Logfile oben in der letzten Zeile
Die IP-Adresse in Hex (0xD21...") könnte auflösen in
Ping wird ausgeführt für pcve.dringendkommen.com [210.16.101.132] mit 32 Bytes Daten:
Macht das Sinn?
mfg
im gezeigten Logfile oben in der letzten Zeile
<br><br><img alt="" src="http://0xD2106584/op/184486_md/1/11179/1833/300/63015" width="1px" height="1px" style="visibility:hidden"> Die IP-Adresse in Hex (0xD21...") könnte auflösen in
ping -n 1 -a 3524289924Ping wird ausgeführt für pcve.dringendkommen.com [210.16.101.132] mit 32 Bytes Daten:
Macht das Sinn?
mfg
für pcve.dringendkommen.com
Diese Domain gibt es nicht!Die IP Adresse dazu kommt aus Indien.
https://www.serverstadium.com
Zitat von @Fennek11:
Die IP-Adresse in Hex (0xD21...") könnte auflösen in
ping -n 1 -a 3524289924
Ping wird ausgeführt für pcve.dringendkommen.com [210.16.101.132] mit 32 Bytes Daten:
Macht das Sinn?
Die IP-Adresse in Hex (0xD21...") könnte auflösen in
ping -n 1 -a 3524289924
Ping wird ausgeführt für pcve.dringendkommen.com [210.16.101.132] mit 32 Bytes Daten:
Macht das Sinn?
Es mag schon so sein, jedoch wie ich es oben bereits erwähnt habe, handelt es sich ja bei den (oben 1:1 veröffentlichten) Datenströmen ausschließlich um "eingehende" Ströme (zumindest so, wie dies aus der Netzwerkaufzeichnung zu entnehmen ist), sodass dies aus meiner jetzigen Sicht eh irrelevant ist, weil die IP x, y ... eh nicht aufgelöst wird.
Das Einzige, was "offiziell" und für mich sichtbar aufgelöst wird, ist wie gesagt die Domäne i.ibb.co und anbei als Hex 1:1:
00000000 11 B6 01 00 00 01 00 00 00 00 00 00 01 69 03 69 .¶...... .....i.i
00000010 62 62 02 63 6F 00 00 01 00 01 bb.co... ..
Siehe auch den folgenden Beitrag als Ergänzung zu diesem Thema hier
Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
welchen ich soeben veröffentlicht habe.Bestimme Spam-E-Mails führen trotz aktivierten Sicherheitsmerkmalen zu langer Verzögerung von Outlook
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread als erledigt zu markieren!
Hallo @aqui,
wenn ich hier die Lösung übersehen sollte, so gib gerne Bescheid.
Soll ich den Vorgang mit Wireshark aufzeichnen und zur Analyse hier laden?
Das Problem in Outlook besteht immer noch und ich habe es hier weiterhin offen gelassen, weil jemand helfen könnte näher auf die Spur dieser Verzögerung zu kommen.
wenn ich hier die Lösung übersehen sollte, so gib gerne Bescheid.
Soll ich den Vorgang mit Wireshark aufzeichnen und zur Analyse hier laden?
Das Problem in Outlook besteht immer noch und ich habe es hier weiterhin offen gelassen, weil jemand helfen könnte näher auf die Spur dieser Verzögerung zu kommen.
