Advanced Threat Protection

Hallo TomE,

Vielen Dank, dass Sie sich an die Community gewandt haben. Basierend auf den freigegebenen Protokollen hat ATP eine „C2/Generic-A“-Erkennung gemeldet: Diese Erkennungswarnungen können auf Sophos Firewall oder UTM angezeigt werden, wenn das Advanced Threat Protection-Modul eine ausgehende Kommunikation mit erkennt ein bekannter C2-Server. In einigen Situationen markiert Sophos Web Protection möglicherweise auch eine C2/Generic-A-Warnung auf dem Endpoint, wenn ein Browser erkennt, der Datenverkehr zu einer URL mit hohem Risiko initiiert. Die Kommunikation wird auf der Firewall blockiert, und die angreifende(n) IP-Adresse(n) muss/müssen nach dem Vorbild einer aktiven Malware-Infektion isoliert und untersucht werden.

Jetzt ist die ATP-Aktion standardmäßig Drop. Und UTM hat den Datenverkehr protokolliert, den wir in der von Ihnen freigegebenen packetfilter.log sehen.


Ich würde Sie bitten, zu prüfen, ob die Aktion nur die Warnung ist oder auf Löschen eingestellt ist?

Hallo, 

bei mir ist das gleiche Problem aufgetreten mit derselben IP Adresse. Geht auch von einem Mailserver aus. Bei uns ist es auf DROP eingestellt. 

Wenn es so eingestellt ist, dass es abfällt, funktioniert es so oder so wie erwartet, nichts zu stören.

Hallo TomE,

die IP ist bei uns auch aufgeschlagen. Ich vermute ihr habt ein DNAT auf den internen Mailserver, das die IP angesprochen hat. Bei der Antwort (SYN-ACK) hat die ATP dann zugeschlagen deshalb scheint als Ziel die IP auf. Am besten du schaust direkt in das Log, dann siehst was der Auslöser war

Schon mal Danke für eure Hilfe.

Vivek Jagad Die Eistellung lautet bei mir Verwerfen, also drop.

JosefBergmann Ja, da ist ein DNAT.

@all

Ich habe in das ATP-Log geschaut und dort steht verkürzt:

"Packet dropped (ATP)" action="drop" srcip="xxx.xxx.xxx.xxx" dstip="185.7.214.104"  srcport="443" dstport="52574" tcpflags="RST"

im Firewall-Log steht, wie oben geschrieben (hier verkürzt):

"packetfilter" name="Packet logged" action="log" initf="eth1"  srcip="185.7.214.104" dstip="xxx.xxx.xxx.xxx"  srcport="37028" dstport="443" tcpflags="SYN"

Jetzt frage ich mich halt, wie ich das interpretieren soll. Ist das nun ein Angriff von aussen gewesen, der erfolgreich abgewehrt wurde oder ist mein Mailserver kompromittiert?

ESET und MALWAREBYTES haben auf dem Mailserver nichts gefunden.

Du kannst das so interpretieren, viel Lärm um nichts.

Die IP 185.7.214.104 hat eurer DNAT-IP auf https (TCP/443) eine TCP-Anfrage gesendet, als Antwort darauf hat der interne Mailserver ein Reset (RST) zurücksenden versucht (weil wahrscheinlich gar kein https-Service am Mailserver läuft) aber das wurde von der ATP blockiert weil als Ziel die IP 185.7.214.104 aufscheint.

Nach meiner Meinung geht das ATP hier sowieso zu weit, die schaut auch offensichtlich in TCP-Verbindungen die bereits established sind und produziert damit in Wahrheit nur unnötig false positives.

Danke für deine Einschätzung!

Grüße

Tom

Oder es ist ProxyLogon (Hafnium), der Mailserver ist ein Exchange Server, der Angriff hier war eine Reverse Shell? 

Diese IP wird mit Autodiscover Vulnerabilities verbunden. 

https://www.virustotal.com/gui/ip-address/185.7.214.104/community

Wenn du den Exchange Server immer up2date gehalten hast? ... Ich würde hier mit Forensik weiterarbeiten und die Exchange Logs überprüfen, ob entsprechende ProxyLogon Angriffe passiert sind. 

Wenn es kein Exchange Server ist, sollte weiterhin nach offenen Lücken im HTTPS Stream geschaut werden. Ein DNAT ist das unsicherste, was du machen kannst. Jeder Service sollte betrachtet werden. Log4J hat uns gezeigt, dass nur ein String bereits eine ReverseShell öffnen kann. Ich hatte deinen weiteren Thread bei Administrator.de gesehen. 

Es hat ein Zugriff stattgefunden. Das Paket zurück wurde blockiert. Auch das war ein RST. Was genau ausgeführt wurde, kann man wahrscheinlich nur in Logs oder ähnliches vom Server ermitteln. 

Ich stimme zu das ein DNAT unsicher ist, vor allem wenn das Ziel wirklich intern steht (und in keiner DMZ). Die Webserver-Protection wäre hier jedenfalls eine bessere Option.

Ich würde prüfen ob am Mailserver überhaupt https gebunden ist, meine Vermutung ist nein (wegen der RST-Antwort). Damit erledigt sich jede weitere Analyse.

Es hängt davon ab. RST kann beides bedeuten. Wenn der Port nicht offen wäre, kommt klassisch keine Verbindung zu Stande, also drop = kein RST. 

RST kann am Ende der Verbindung genutzt werden. Das heißt, Daten können ausgetuascht werden, die Session kann existieren. 

Wenn du ein SYN und direkt ein RST/ATP Drop siehst, war wahrscheinlich der Port blockiert und der Client hat RST zum abbruch gesendet.

Jedoch wenn du ein Syn siehst, und stunden später ein RST, dann wissen wir es nicht.

Leider zeigt die UTM nicht an, wieviele Daten darüber geflossen sind, wie SFOS das macht: