First, the pattern of behavior you're seeing is likely because the malware has detected that it's running in a sandboxed environment. CPU count for your honeypot should be greater than two, if it's not already because most new malware auto terminates if there are two or less CPU cores available, and the processes of your honeypot should not be visible to attackers' software because some of the better written malware will check if honeyd or other well known honeypot daemons are running or installed. An easy option for limiting process/fs visibility is to look up "firejail" and how to setup custom profiles. Hint: strace output can be parsed and added to firejail profiles to hide/disable listing of host file system and running processes.
Second, look into running a Snort tap between your honeypot and its network connection to capture and fingerprint the attacks network traffic in near real time. I've had good luck with using Raspberry Pis for network monitoring for low cost.
Third, consider using dedicated hardware for your honeypot to make it look more like a legit victim; search term "system on a chip" (wiki has a list of manufacturer) for available cheap options. The one from Intel is the one I'd suggest for this because the architecture looks very close to a legit victims' desktop.
Fourth, look into Metasploit honeypot detection source code for kippo and others to make your honeypot less detectable because there maybe some other clever ways that attacks are detecting their being observed.
Fifth, checkout detection of metasploit reverse shells article using "carbon black" for after honeypot intrusion detection. Be careful using the tools to hack them back; if you're going to try, do only the minimum investigation needed to identify the criminals. Even if they attacked you first, it is still a crime to hack them back.