Ich bin heute auf einen interessanten Blogpost zum Thema Bypassing Next-Gen AV For Fun and Profit aufmerksam geworden, in dem es um die Umgehung von Next-Gen AV-Lösungen geht. Der Autor hat sich für CylancePROTECT und Symantec SEP 12 entschieden, wobei machine based learning erst in Symantec SEP 14 enthalten ist – das aber nur der Vollständigkeit halber. Der Grund, weshalb der Artikel meine Aufmerksamkeit auf sich gezogen hat, war u.a. die Testmethodik. Da es schon etwas spät für heute ist, werde ich diesen Beitrag ein anderes Mal zusätzlich auf englisch veröffentlichen, bis dahin muss Google Translator ausreichen.
Damit wir uns richtig verstehen: Mir geht es nicht darum, diesen Beitrag von Colby zu kritisieren. Ich fand ihn interessant und aufschlussreich, und auch Next-Gen AV-Lösungen sind nicht unfehlbar und lassen sich mit genügend Zeit, Energie und Ressourcen überwinden, aber ganz so einfach, wie es im Artikel dargestellt wird, ist es nun auch nicht. Da ich mit CylancePROTECT aufgrund eines längeren Proof Of Concepts Erfahrung habe und das Produkt etwas besser kenne, möchte ich auf folgende Punkte hinweisen, die aus dem Blogbeitrag nicht klar hervorgehen:
0. Ich weiß nicht, welche Version Colby getestet hat. Es gibt aber meines Wissens nach keine Version 2.0.1420.11, die mir bekannten Versionen beginnen mit 1.2.xxxx.xx. Das klingt vielleicht pingelig, aber ich lege Wert auf die korrekte Angabe von Versionsinformationen, insbesondere dann, wenn man schon so einen Test veröffentlicht, in dem es um die Umgehung von Next-Gen AV-Lösungen geht. Er macht auch keine Angaben darüber, woher die Version stammt. Das halte ich deshalb für erwähnenswert, weil Cylance sich zumindest aktuell auf Enterprise-Kunden konzentriert und es keine SOHO-Version gibt.
1. Enterprise-Kunden erhalten für einen PoC (Proof of Concept) einen PoC Guide sowie Unterstützung durch Cylance, um genau die von Colby bemängelten False Positives nicht im operativen Betrieb zu erhalten. Das ganze ist ein mehrstufiger Prozess, an dessen Ende keine FPs mehr auftauchen sollten, wenn man es denn richtig macht. Deshalb mutmaße ich an an dieser Stelle, dass er schlicht und ergreifend den Agent installiert hat, ohne sich um die weitere Konfiguration zu kümmern, denn diese erfolgt über eine cloudbasierte Webkonsole, die meines Wissens nach ebenfalls nur für Unternehmen während eines PoC bereitgestellt wird.
2. Damit komme ich zum wichtigsten Punkt, nämlich der Konfiguration. Hier bin ich mir ziemlich sicher, dass Colby aufgrund der vorgenannten Umstände gar keine Möglichkeit hatte, mittels cloud console die Policy für CylancePROTECT so zu konfigurieren, wie sie sein sollte. CylancePROTECT bietet nämlich einige Konfigurationsmöglichkeiten, u.a. Memory Protection und Script Control. Die Memory Protection blockt (sofern konfiguriert) Exploitation, Process Injection und Escalation. Script Control bezieht sich auf Active Script, Powershell und Makros und bietet damit mächtige Kontrollmöglichkeiten, sofern man diese nutzen möchte.
3. Leider ist der Originalbeitrag mittlerweile aus dem Blog verschwunden, deshalb konnte ich nur auf den Google Cache verlinken. Die Screenshots sind ziemlich unleserlich, was ich insofern schade finde, weil man somit die einzelnen Schritte nicht richtig nachvollziehen kann. Das halte ich für extrem wichtig, weil daraus die Testmethodik erkennbar wird.
4. Ich möchte Colby nicht unterstellen, dass sein Test fehlerhaft ist. Etwas mehr Transparenz hätte die Sache aber deutlich aufgewertet; ich vermisse wie gesagt Informationen darüber, wie der Agent konfiguriert wurde, und entsprechende Hinweise dazu wurden in den Kommentaren auch nicht beantwortet. Das gehört für mich einfach dazu, damit so ein Test transparent und reproduzierbar bleibt. Und nein, ich bin kein Cylance-Mitarbeiter, aber nachdem ich mir die teilweise völlig sinnfreien Kommentare durchgelesen hatte, erschien es mir wichtig, auf ein paar Ungereimtheiten hinzuweisen, und deshalb ist dieser Beitrag entstanden.