HOW THE PNSCAN WORK - FOR MITIGATION REFERENCE OF ABUSED ROUTERS
A sample was spotted by @TechHelpList, I analyzed.
Understanding the initial process detail of an infection that started SSH bruting attack conducted by this malware is inded a very important information for mitigation, due to the ELF malware of this variant is involved in globally hacking routers case that is now helping proxy-distributing well-known "other" windows malware via malicious DNAT proxy setting. This info is not found by Dr.Web explanation.
So here is the short explanation for the purpose:
Upon executed the initial process runs the random() and check its path to then open the "files" directory,
along with writing file "login2".
This malware write string "root;root;\nadmin;admin;\nubnt;ubnt;\n" to the "login2", fork itself and then quit.
Code: Select all
write(3, "root;root;\nadmin;admin;\nubnt;ubnt;\n", 35)
The forked instance process will grab the PID by syscall getpid() and set it up w/setsid() to then -
opening two files, the "daemon.log" for the soon to be executed daemon and the "[malwarefilename].pid" for the malware process main pid data (text).
During the process the workfiles of "good2" and "list2" will be created & filled with the nodes IP addresses data, it reads them and deleted the files.
This forked instance process is the main process of this malware, forked processes by hooking to a child stack (child_stack=0x8778b0) to self-cloned itself to another PID processes.
The first cloned process above is executed the self-daemon hook to INET in 0.0.0.0:9000 as a server.
And together with other cloned processes, all clones are using same method clone() syscall w/child_stack, it opened the (1) INET socket and (2) opens SSH connection to the listed IP and wait for the established ones.
The forked instance reading each clone return call for following up with the password bruting.
These clones is self-terminated upon timeout, idling the connection due to the established state.
Upon established the the first main fork process will execute ssh protocol communication for the login ssh attack.
I didn't write this paragraph until I tested, and it is positive now.. one cloned process by the main process (firstly forked one) opened another port for backdoor bound to 0.0.0.0:1337 with the same binding method on listening to the port 9000. So two ports are opened.
Another amusing fact is.. don't ask me why..it is as/per tested, one cloned process requested https to twitter.com
See it yourself:
In this sample it extracted the 10,000 IP addresses to scan and the login to brute that I extracted from malware, I put together with the sample and its drops.
This malware is not making callbacks and backdooring in port 9000 & 1337 , where the actor is using it to access and fetch scan result written in the files mentioned above, so no actually CNC callback.
Obviously router's resource was drained during the bruting in progress so as long as the router's resource is available it will keep in high load average, no proper resource control in this malware. Some functions doesn't seem to run well too in non x86 arch.
For indication of infection, from outside of the box: the big connection activity or brute login in SSH outbound traffic are a symptoms, so does with the backdoor port opened. In some state may look like the affected router is in DoS state.
In the shell (from the inside the box) the above file activities will be an indicator to the infection.
Infected routers will definitely run the malware as root. Backdoor was opened and can be remotely gained to execute anything remotely, so instead to clean it normally to reset the factory setting and restore the backup settings is recommendable method, change the login credential afterward and then tune the router in more secure state.
Snips of initiated attack in progress:
Code: Select all
IPv4 3408051 0t0 TCP pMMD-KICKS:38066->246.148.1.255:ssh (SYN_SENT)
IPv4 3408052 0t0 TCP pMMD-KICKS:58726->246.148.2.0:ssh (SYN_SENT)
IPv4 3408053 0t0 TCP pMMD-KICKS:39952->246.148.2.1:ssh (SYN_SENT)
IPv4 3408054 0t0 TCP pMMD-KICKS:57184->246.148.2.2:ssh (SYN_SENT)
IPv4 3408055 0t0 TCP pMMD-KICKS:40208->246.148.2.3:ssh (SYN_SENT)
IPv4 3408056 0t0 TCP pMMD-KICKS:38367->246.148.2.4:ssh (SYN_SENT)
IPv4 3408057 0t0 TCP pMMD-KICKS:40710->246.148.2.5:ssh (SYN_SENT)
IPv4 3408058 0t0 TCP pMMD-KICKS:37068->246.148.2.6:ssh (SYN_SENT)
https://www.virustotal.com/en/file/9c28 ... /analysis/
https://www.virustotal.com/en/file/0ffa ... /analysis/
https://www.virustotal.com/en/file/86fb ... /analysis/
https://www.virustotal.com/en/file/5c8c ... /analysis/