Interactsh version:
- interactsh-server: v1.3.1
- interactsh-client: v1.3.1
- interactsh-web: v1.0.1 (self-hosted)
Server flags: -domain example.com -smb -ftp .... (Domain, IPs, usernames and the NTLM hash below are anonymized.)
Current Behavior:
On a self-hosted server with the SMB (-smb) and FTP (-ftp) agents enabled, incoming SMB and FTP interactions are not correlated to the unique subdomain/payload generated for a client: their unique-id and full-id fields are empty.
- DNS and HTTP(S): an interaction to
<unique-id>.example.com is correctly attributed to the client that generated that payload.
- SMB and FTP: the server registers that an interaction happened, but it cannot be traced back to the specific generated payload.
As a result, in the self-hosted web client these interactions do not show up at all (it only shows interactions matching the client's correlation id), and in the CLI client they only appear as generic, server-wide interactions rather than tied to the generated subdomain.
Only SMB and FTP were tested; other non-DNS/HTTP protocols (e.g. SMTP, LDAP) may be affected as well.
Expected Behavior:
For all protocols (including SMB and FTP), an interaction to <unique-id>.example.com should be attributed to the client that generated that specific payload — as it already works for DNS and HTTP(S) — with unique-id/full-id populated accordingly.
Steps To Reproduce:
- Run a self-hosted server with SMB and FTP enabled:
sudo interactsh-server -domain example.com -smb -ftp
- Generate a payload with a client, e.g.
<unique-id>.example.com.
- Trigger an interaction on that exact payload over each protocol:
- HTTPS:
curl https://<unique-id>.example.com/
- DNS:
nslookup <unique-id>.example.com
- SMB:
\\<unique-id>.example.com\share (Windows)
- FTP:
ftp <unique-id>.example.com
- Observe the interactions in the CLI client, the web client, and the server
-debug output.
Anything else:
Server -debug output (anonymized).
DNS — correlated correctly:
[DBG] DNS Interaction:
{"protocol":"dns","unique-id":"<unique-id>","full-id":"<unique-id>","q-type":"AAAA","raw-request":"... QUESTION SECTION: <unique-id>.example.com IN AAAA ...","remote-address":"<resolver-ip>","timestamp":"..."}
FTP — NOT correlated (empty ids; no hostname in the protocol data):
[DBG] FTP Interaction:
{"protocol":"ftp","unique-id":"","full-id":"","raw-request":"USER <user>\n<user> logging in","remote-address":"<client-ip>:<port>","timestamp":"..."}
SMB — NOT correlated (empty unique-id/full-id and empty remote-address), even though the subdomain IS present:
[DBG] SMB Interaction:
{"protocol":"smb","unique-id":"","full-id":"","raw-request":"AUTHENTICATE_MESSAGE (<workstation>\\<user>,<WORKSTATION>)","remote-address":"","timestamp":"..."}
[DBG] SMB Interaction:
{"protocol":"smb","unique-id":"","full-id":"","raw-request":"<user>::<workstation>:<NTLMv2 response redacted>","remote-address":"","timestamp":"..."}
Key point for SMB: decoding the NTLMv2 target info (AV_PAIRs) in the redacted response above, the target-name / SPN field (MsvAvTargetName, AV id 0x0009) contains:
cifs/<unique-id>.example.com
So the full unique subdomain — including the correlation id — is already present in the SMB interaction; the server simply does not parse it.
Possible cause / suggestion:
- DNS / HTTP(S): the correlation id is present in data the server reads directly (DNS query name; HTTP
Host header), so it is extracted and correlated. Works as expected.
- SMB: parse the SPN / target-name from the NTLM
AUTHENTICATE_MESSAGE (cifs/<unique-id>.example.com) and derive the correlation id from its subdomain, the same way it is done for DNS/HTTP. Directly implementable since the data is already captured. (Populating the empty remote-address on SMB interactions may be worth doing too.)
- FTP: the subdomain is not present in the FTP exchange (
USER/PASS only), so it cannot be extracted from the interaction. DNS-based correlation is also unreliable: the DNS query originates from a recursive resolver (<resolver-ip>), not from the FTP client (<client-ip>), so matching by source IP is not dependable.
Impact: without correlation, SMB/FTP interactions cannot be used to confirm an out-of-band interaction against a specific target/payload — especially in the web client, where they are not shown at all. SMB in particular is fixable because the required data is already captured.
Interactsh version:
Server flags:
-domain example.com -smb -ftp .... (Domain, IPs, usernames and the NTLM hash below are anonymized.)Current Behavior:
On a self-hosted server with the SMB (
-smb) and FTP (-ftp) agents enabled, incoming SMB and FTP interactions are not correlated to the unique subdomain/payload generated for a client: theirunique-idandfull-idfields are empty.<unique-id>.example.comis correctly attributed to the client that generated that payload.As a result, in the self-hosted web client these interactions do not show up at all (it only shows interactions matching the client's correlation id), and in the CLI client they only appear as generic, server-wide interactions rather than tied to the generated subdomain.
Only SMB and FTP were tested; other non-DNS/HTTP protocols (e.g. SMTP, LDAP) may be affected as well.
Expected Behavior:
For all protocols (including SMB and FTP), an interaction to
<unique-id>.example.comshould be attributed to the client that generated that specific payload — as it already works for DNS and HTTP(S) — withunique-id/full-idpopulated accordingly.Steps To Reproduce:
sudo interactsh-server -domain example.com -smb -ftp<unique-id>.example.com.curl https://<unique-id>.example.com/nslookup <unique-id>.example.com\\<unique-id>.example.com\share(Windows)ftp <unique-id>.example.com-debugoutput.Anything else:
Server
-debugoutput (anonymized).DNS — correlated correctly:
FTP — NOT correlated (empty ids; no hostname in the protocol data):
SMB — NOT correlated (empty
unique-id/full-idand emptyremote-address), even though the subdomain IS present:Key point for SMB: decoding the NTLMv2 target info (AV_PAIRs) in the redacted response above, the target-name / SPN field (
MsvAvTargetName, AV id0x0009) contains:So the full unique subdomain — including the correlation id — is already present in the SMB interaction; the server simply does not parse it.
Possible cause / suggestion:
Hostheader), so it is extracted and correlated. Works as expected.AUTHENTICATE_MESSAGE(cifs/<unique-id>.example.com) and derive the correlation id from its subdomain, the same way it is done for DNS/HTTP. Directly implementable since the data is already captured. (Populating the emptyremote-addresson SMB interactions may be worth doing too.)USER/PASSonly), so it cannot be extracted from the interaction. DNS-based correlation is also unreliable: the DNS query originates from a recursive resolver (<resolver-ip>), not from the FTP client (<client-ip>), so matching by source IP is not dependable.Impact: without correlation, SMB/FTP interactions cannot be used to confirm an out-of-band interaction against a specific target/payload — especially in the web client, where they are not shown at all. SMB in particular is fixable because the required data is already captured.