Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 7 subscribers
  • Views 4210 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Advanced Threat Protection

TomE

Hallo Community,

bei mir hat die Advanced Threat Protection diese Meldung ausgegeben:

  Benutzer/Host Bedrohungsname Ziel Ereignisse Ursprung  
1 xxx.xxx.xxx.xxx C2/Generic-A 185.7.214.104 1 Iptables C2/Generic-A","origin":"Iptables","sum_events_str":"1","cnt_srcip_int":"1","threaturl":""threatname":"C2/Generic-A","cnt_srcip_str":"1","cnt_srcip_per":"100.00","icon_exception":{"icon":"core/img/icons/plus.png","name":"exception","title":"Eine">www.sophos.com/.../plus.png","name":"exception","title":"Eine Ausnahme erstellen"},"first_seen":"2022-08-07 16:22:42","idx":1,"sum_events_per":"100.00"}, update_name: "aptp_exception"});' id="ELEMENT_exception_1">

Dieses Event war einmalig gestern, Sonntag 2022-08-07 16:22:42

Nun bin ich natürlich auf der Suche, was hier passiert ist. Quelle ist unser Mailserver. Der Virenscan läuft noch, hat aber bisher keinen Fund gemeldet.

Jetzt hab ich im Firewall-Log gesehen, dass diese Seite auch vorher schon aufgerufen und blockiert wurde, ohne dass eine Meldung kam.

Im Gegensatz zur Meldung der Advanced Threat Protection steht im Log die 185.7.214.104 als Source:

2022:08:06-03:30:04 mail-2 ulogd[23255]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62002" initf="eth1" srcmac="f8:75:88:8c:bb:7a" dstmac="XX:XX:XX:XX:XX:XX" srcip="185.7.214.104" dstip="xxx.xxx.xxx.xxx" proto="6" length="60" tos="0x00" prec="0x00" ttl="58" srcport="37028" dstport="443" tcpflags="SYN"

Das wiederum würde bedeuten, dass der Angriff von außen kam und blockert wurde.

Wie würdet ihr das deuten?



This thread was automatically locked due to age.
  • 0

    Hallo ,

    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?

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to Vivek Jagad

    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. 

  • 0 in reply to Paul Jurasow

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

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0

    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

    Logging & Reporting -> View Log Files -> Archived Log Files -> Advanced Threat Protection

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • 0

    Schon mal Danke für eure Hilfe.

    Die Eistellung lautet bei mir Verwerfen, also drop.

    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.

  • 0 in reply to TomE

    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.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • 0 in reply to JosefBergmann

    Danke für deine Einschätzung!

    Grüße

    Tom

  • 0 in reply to TomE

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

  • 0 in reply to JosefBergmann

    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: 

    __________________________________________________________________________________________________________________

Unfiltered HTML