The attacker gets the session keys and other state information from memory, but those keys are good only for that single TCP connection. For a new TCP connection, the server will generate new nonces and all the anti-replay features of SSH kick in.
So the attacker needs to hijack the TCP connection, which the server identifies by client IP address, client TCP port, and sequence number information. The attacks can be classified by how far from the original client the seized TCP connection is picked up:
ssh process itself. If the attacker has superuser rights where
ssh is running, he can either replace the
ssh binary with his own compromised copy that the innocent user runs, or change its behavior via code injection (for example, injections don't modify the binary on disk, so digital signatures don't detect the tampering).
In a second process on the same machine. It's easy to continue the TCP connection from here because packets sent by the server are already being routed here.
a. All the TCP connection-related information is kept by the OS sockets layer, and while the details of moving a TCP socket between processes are OS-specific, sockets don't have process affinity in any POSIX OS, because they can be used from multiple processes at once if inherited during spawn or fork.
b. By bypassing the sockets layer used by applications, and capturing/modifying/injecting packets at the network stack or driver -- for example using iptables or libpcap.
In another machine positioned for MITM attacks. The only thing that's absolutely necessary besides getting a copy of the session keys and state itself is to continue using the same IP address so the server thinks the same TCP connection is ongoing. That's the same thing necessary for man-in-the-middle, either sitting really on the path, or at least compromising a router on the path to send packets transmitted from the SSH server to the attacker.