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 4838 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.
Parents
  • 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

Reply Children
  • 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: 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Toni du hast Recht ich kenne nicht die ganze Historie, es kann sein das einige Stunden davor eine https-Session von der IP zum Mailserver aufgebaut wurde und damals das ATP die IP noch nicht als böse kannte.
    Aber spätestens als die IP im ATP bekannt war (also nach einem Signatur-Update) hätte sie doch wohl blockiert und dann wäre eher kein RST-Flag in einer laufende TCP-Sitzung protokolliert worden.

     Du kannst noch schauen ob zu jedem ATP-Log mit RST ein davor passender Firewall Log mit SYN auftritt (IPs und srcport und dstport müssen zusammenpassen).
    Aber klar, wenn der Mailserver bisher über DNAT von überall erreichbar war kann schon alles mögliche passiert sein.

    bye Josef

    BERGMANN engineering & consulting GmbH, Wien/Austria

Unfiltered HTML