Umgehung der Erkennung mit Nmap Teil 2 | von Bob van der Staak | November 2023

Diese Untersuchung wurde während meines letzten Blogs über Nmap ausgelöst. Wo ich erwähnt habe, wie ein bestimmter URI an Endpunkte namens nmaplowercheck gesendet wird. Dies könnte für das blaue Team ein klarer Hinweis darauf sein, dass ihr Antrag gescannt wurde, und könnte den Deckmantel für eine Untersuchung des roten Teams auffliegen lassen. In diesem Blog erfahren Sie, wie die Service Probes ein klarer Hinweis darauf sind, dass Ihr System gescannt wird.

Aber zunächst: Wie funktionieren Nmap-Service-Probes? Dies sind wichtige Informationen, um besser zu verstehen, warum und wie Sie in Zukunft selbst nach weiteren Ports und neueren Versionen suchen können.

Im Installationsordner von Nmap gibt es eine Datei namens nmap-service-probes. Dies ist eine wichtige Datei, da sie alle Prüfungen enthält, die von Nmap durchgeführt werden. Basierend auf drei Punkten:

• Welche Ports werden als offen erkannt?
• Wie aggressiv ist Ihr Scan?
• Wenn es basierend auf der zuvor durchgeführten Prüfung am angegebenen Port bereits eine harte oder weiche Übereinstimmung gab.

Schauen wir uns zwei Sonden in der angegebenen Datei an.

Der erste, wie im bereitgestellten Befehl erwähnt, ist der NULL-basierte Prüfpunkt. Dies ist die Sonde, die an alle offenen Ports gesendet wird. Es wartet nur 6 Sekunden und wartet, ob die Anwendung hinter dem Port so nett ist, die Header-Informationen selbst preiszugeben.

Es zeigt die Information Probe ist eine TCP-basierte Verbindung mit dem Namen NULL. Wo es einfach nichts sendet (zu sehen bei q||)

Anschließend versucht es, es anhand der empfangenen Informationen abzugleichen. Dies können Sie an den Zeilen erkennen, die mit match beginnen. gefolgt von der Information, auf welcher Nmap die Ergebnisse übereinstimmen sollen.

Das nächste Beispiel zeigt einige zusätzliche Informationen. Es handelt sich um ein TLSv1.2-Problem. Dabei wird angegeben, dass die Probe erneut über TCP mit dem Namen TLSSessionReq gesendet wird, gefolgt von der Nachricht im Hexadezimalformat. Es ist wichtig zu beachten, dass die Nachricht random1random2random3random4 enthält. Schon ein besonders deutlicher Hinweis darauf, dass Nmap zum Scannen verwendet wird!
Eine neue Immobilie ist ebenfalls enthalten Seltenheit: Dies weist auf die Seltenheit hin, dass diese Nachricht gesendet wird. Dabei ist die Seltenheit eins die höchste. Dies weist darauf hin, dass es sich um die häufigste und um die Seltenheit 9 handelt, dass es ungewöhnlich ist.

Wichtige Site-Informationen: Standardmäßig führt Nmap alle Tests aus, wenn -sV bis zur Seltenheit 7 verwendet wird. Es beginnt mit der Seltenheit 1 und die Seltenheit steigt weiter an, bis eine harte oder weiche Übereinstimmung gefunden wird!

Es gibt auch an, auf welchen Ports es ausgeführt wird: Daher wird diese Sonde an die folgenden offenen Ports gesendet:

ports 443,444,465,636,989,990,992,993,994,995,1241,1311,2252,3388,3389,4433,4444,5061,6679,6697,8443,8883,9001

Nachdem wir nun wissen, wie Nmap bestimmt, welche Sonden gesendet werden sollen, untersuchen wir einen Server, auf dem die Ports 80.443 und 3389 geöffnet sind.

Wir führen zwei Scans durch, indem wir die folgenden Befehle verwenden. Der große Unterschied zwischen beiden ist der Befehl „version-all“. Dies zwingt Nmap dazu, alle Service-Probe-Verbindungen durchzuführen, selbst wenn eine weiche Übereinstimmung gefunden wird und selbst wenn die Seltenheit über 7 liegt (also sind auch die Seltenheit 8 und 9 enthalten).

nmap -sV  -Pn --version-trace

nmap -sV --version-all  -Pn --version-trace

Darüber hinaus verwenden wir die Eigenschaft „version-trace“, die weitere Informationen zu den gesendeten Probes anzeigt. Es zeigt Informationen darüber an, an welche IP/ welchen Port die Sonde gesendet wurde und ob sie erfolgreich war oder nicht.

Es gibt eine drastische Anzahl von Sonden, die bereits mit nur -sV gesendet wurden. Im Fall der offenen Ports 80, 443 und 3389 führte dies dazu, dass 36 Probes gesendet wurden (einschließlich der 3 Null-Probes, die immer gesendet werden, wenn ein Port offen ist). Vergleichen wir das mit der Ausführung aller möglichen Probes, selbst wenn diese mit hoher Seltenheit kombiniert wurden 101 Sonden. Diese Werte können sich natürlich je nach Seltenheit des Diensts, gegen den er ausgeführt wird, ändern. Wie bereits erwähnt, wird die Bewertung abgebrochen, wenn eine harte oder weiche Übereinstimmung gefunden wird. In diesem Fall konnte Nmap den Dienst 443 nicht ermitteln. Das Ergebnis waren 36 Sonden.

Jetzt haben wir die Grundidee, wie wir bestimmen können, welche Service-Probes gesendet werden. Lassen Sie uns untersuchen, wie diese verraten könnten, dass eine Nmap-Anwendung verwendet wurde.

Radom1Zufällig2Zufällig3zufällig4

Wie oben erwähnt gibt es einen TLS-Probe, der eine bestimmte Nachricht sendet. es fügt für die Anfrage random1random2random3random4 hinzu. Das ist etwas, was Sie bei einer normalen Bewerbung wahrscheinlich nie erhalten werden.

Wenn wir uns Whireshark ansehen, können wir tatsächlich erkennen, dass eine Nachricht mit diesen spezifischen Zeichen an die Partei innerhalb eines SSLv3-Clients gesendet wurde. Beim Filtern innerhalb von Whireshark auf der Suche nach random1random2random3random4 in einem Frame erhalten wir einen Treffer.

frame contains random1random2random3random4

Kerberos

Außerdem wird eine Kerberos-Nachricht an das System gesendet. Dies kann mithilfe des folgenden Frames gefunden werden, der eine Nachricht enthält.

frame contains 00:00:71:6a:81:6e:30:81:6b:a1:03:02:01:05:a2:03:02:01:0a:a4:81:5e:30:5c:a0:07:03:05:00:50:80:00:10:a2:04:1b:02:4e:4d:a3:17:30:15:a0:03:02:01:00:a1:0e:30:0c:1b:06:6b:72:62:74:67:74:1b:02:4e:4d:a5:11:18:0f:31:39:37:30:30:31:30:31:30:30:30

Es beschreibt eine Kerberos-Authentifizierungsanforderung (AS_REQ),wobei die Hex-Zeichenfolge der Inhalt des Kerberos-Anforderungspakets ist.

Der Bereich wird als „NM“ identifiziert und der Servername ist „krbtgt/NM“. Der Name des Kunden ist jedoch nicht angegeben. Die Überprüfung dieser Informationen auf Ihren Ports kann Ihnen auch dabei helfen, Scans auf Ihrem System zu erkennen.

GIOP

Außerdem wurde das GIOP-Protokoll gesendet: Das CORBA General Inter-ORB Protocol (GIOP) ist das Standardprotokoll für die Kommunikation zwischen verschiedenen CORBA-Systemen, die unterschiedliche Object Request Broker (ORBs) verwenden.

Es enthält einen Header und einen Body. Wo im Textkörper die Nachricht abcdef gesendet wird. Auch untypisch für ein normales System und wieder ein klarer Hinweis auf einen Nmap-Scan

Dies kann mithilfe von Folgendem ermittelt werden:

giop && frame contains abcdef

SCHLUCK

Die SIP-Anfrage verwendet auch einige spezifische Takes, die ebenfalls ein klarer Hinweis auf eine seltsame Anfrage sind. Der SIP-Anruf hat eine bestimmte Nachricht: SIP:nm@nm und das Tag ist root und branch = foo. Wenn wir uns das ansehen.

SIP (Session Initiation Protocol) ist ein Kommunikationsprotokoll, das zum Einrichten und Verwalten von Sprach- oder Videoanrufen über IP-Netzwerke verwendet wird.

sip:nm@nm ist ein SIP-URI (Uniform Resource Identifier), der das Ziel der SIP-Nachricht angibt. In diesem Fall besteht der URI aus einem Benutzernamen „nm“ und einer Domäne „nm“.

tag=root ist ein Parameter in der SIP-Nachricht, der eine eindeutige Kennung für die SIP-Nachricht identifiziert. Der tag wird verwendet, um Antworten von Servern abzugleichen und den Dialog zwischen SIP-Entitäten anzuzeigen.

call-id 50000 ist ein weiterer Parameter in der SIP-Nachricht, der eine eindeutige Kennung für den SIP-Anruf identifiziert. Der call-id Das Header-Feld wird verwendet, um eine bestimmte SIP-Nachricht einem bestimmten Anruf zuzuordnen.

Also, branch=foo wird normalerweise als Teil eines Via-Header-Felds in einer SIP-Nachricht verwendet, um die spezifische Sitzung zu identifizieren, zu der die Nachricht gehört.

Wieder eine nicht standardmäßige Meldung, die eindeutig darauf hinweisen könnte, dass ein Nmap-Scan stattgefunden hat:

Dies hätte mit folgendem Suchparameter gefunden werden können:

sip && frame contains "branch=foo" && frame contains ";tag=root" && frame contains "To: "

Die Sonde könnte auch aus der Datei nmap-probe-scan entdeckt worden sein

RDP

Seltsamerweise wird auch ein Cookie auf Port 443 gesetzt. Beim Durchführen einer RDP-Anfrage. Dies ist im rdp.lua-Code zu finden. Auch der Cookie-Name mstshash mit dem Wert nmap ist ein eindeutiger Hinweis darauf, dass ein Nmap-Scan durchgeführt wird.

und der Code in der Datei rdp.lua, der den Verweis auf Nmap im Cookie-String enthält:

ConnectionRequest = {
new = function(self, proto)
local o = { proto = proto }
setmetatable(o, self)
self.__index = self
return o
end,
__tostring = function(self)
local cookie = "mstshash=nmap"
local data = string.pack(">I2I2B",
0x0000, -- dst reference
0x0000, -- src reference
0x00) -- class and options
.. ("Cookie: %srn"):format(cookie)
if ( self.proto ) then
data = data .. string.pack("0x01, -- TYPE_RDP_NEG_REQ
0x00, -- flags
0x0008, -- length
self.proto -- protocol
)
end
return tostring(Packet.TPKT:new(Packet.ITUT:new(0xE0, data)))
end
},

Wenn wir uns die Protokolle aus der Versionsverfolgung ansehen, sehen wir, dass das TerminalServerCookie ausgeführt wird und dass es anschließend mit dem ms-wbt-server übereinstimmt. Ich weiß allerdings nicht, warum es auf Port 443 gesendet wird. In den Protokollen steht, dass der Schreibvorgang sowohl auf 443 als auch auf 3389 erfolgreich war.

Trinity.bak

Ich bin auf einen anderen URI gestoßen, der speziell für Nmap gilt. GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0

Wieder ein klarer Hinweis darauf, dass ein Nmap-Scan durchgeführt wurde.

Der Code

Schauen wir uns den Code von Nmap an. Wo wir eine Logik finden können, die Informationen preisgeben könnte. Wenn beispielsweise in versant.lua kein Benutzer angegeben ist, wird der Standard-Nmap-Benutzer verwendet.

Slope.lua

Versant = {  
-- fallback to these constants when version and user are not given
USER = "nmap",
VERSION = "8.0.2",  -- Creates an instance of the Versant class
-- @param host table
-- @param port table
-- @return o new instance of Versant
new = function(self, host, port)
local o = { host = host, port = port, socket = nmap.new_socket() }
setmetatable(o, self)
self.__index = self
return o
end,  -- Connects a socket to the Versant server
-- @return status true on success, false on failure
-- @return err string containing the error message if status is false
connect = function(self)
return self.socket:connect(self.host, self.port)
end,  -- Closes the socket
-- @return status true on success, false on failure
-- @return err string containing the error message if status is false
close = function(self)
return self.socket:close()
end,
-- Sends command to the server
-- @param cmd string containing the command to run
-- @param arg string containing any arguments
-- @param user [optional] string containing the user name
-- @param ver [optional] string containing the version number
-- @return status true on success, false on failure
-- @return data opaque string containing the response
sendCommand = function(self, cmd, arg, user, ver)
user = user or Versant.USER
ver = ver or Versant.VERSION
arg = arg or ""
local data = stdnse.fromhex("000100000000000000020002000000010000000000000000000000000000000000010000")
.. string.pack("zzz",
cmd,
user,
ver
)
-- align to even 4 bytes
data = data .. string.rep("", 4 - ((#data % 4) or 0))

tns.lua

Das Gleiche gilt für den Tns.lua-Code. In der Verbindungszeichenfolge wird auch der Nmap-Benutzer verwendet, wenn kein bestimmter Benutzer angegeben ist.

- Initiates the connection to the listener
Packet.Connect = {
CONN_STR = [[
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=%s)(PORT=%d))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=%s)(CID=
(PROGRAM=sqlplus)(HOST=%s)(USER=nmap))))]],
version = 314,
version_comp = 300,

Ein klarer Hinweis ist auch, dass jede Anfrage immer die folgenden Netzwerkeinstellungen enthält:

• MSS (maximale Segmentgröße): 1460
• TCP-Fenstergröße: 64240
• SACK_perm (Selektive Bestätigung zulässig): 1 (was bedeutet, dass diese Option aktiviert ist und der Empfänger auch mehrere nicht aufeinanderfolgende Segmente bestätigen kann)
• WS (Fensterskalierung): 128 (was bedeutet, dass der Empfänger die Fensterskalierungsoption verwendet und die Fenstergröße mit 2¹²⁸ multipliziert werden sollte)

Dies sind wichtige Informationen, da normalerweise die erste Verbindungsanforderung, die an einen Remote-Host gesendet wird, eine Fenstergröße von 16 KB (16.384 Byte) verwendet.

Wenn es Probleme gibt, wird es viermal hochskaliert, um schließlich 64 KB zu erreichen. Ein Start mit jeweils 64 KB ist daher unüblich und kann insbesondere bei kurzer Abfolge auf verschiedenen Ports ein Hinweis darauf sein, dass jemand Ihre Anwendung scannt.

Der letzte Blog hat mich dazu motiviert, mich eingehend mit diesem Tool zu befassen. Interessant, wie viel Sie lernen können, wenn Sie sitzen und beobachten, was Ihr Werkzeug tut. Nmap verfügt über eine großartige Dokumentation, die eine echte Hilfe war.

Diese Informationen können vom Blue-Team genutzt werden, um bessere Auslöser für Sicherheitsalarme zu entwickeln. Und es zeigt deutlich für Red Teamer, dass Sie -sV wahrscheinlich niemals verwenden sollten. Es gehen einfach zu viele Informationen verloren, oder Sie sollten die Sonden austauschen.

Ich sollte wirklich mehr über YARA oder Snort erfahren und wie dies zur Überprüfung erkannt werden könnte. Meiner Meinung nach würde es mein Wissen über Red Teaming/Malware-Schreiben wirklich verbessern. Im Fall von Nmap würde ich empfehlen, sich die spezifischen Sendeprüfungen anzusehen und ein Erkennungsskript für jede einzelne Nachricht mit einer Seltenheit kleiner oder gleich 7 zu schreiben.

Viel Spaß beim Testen!

Wenn Sie etwas im Zusammenhang mit Infosec besprechen möchten, bin ich auf LinkedIn: https://www.linkedin.com/in/bobvanderstaak/

https://nmap.org/book/man.html

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/description-tcp-features