Year2016 & 2017 has witnessed the rise in cyber attacks targeting various sectors like banking, industrial, etc. New variants and types (fileless/in-memory) of malware families are being surfacing each day (wannacry, Petya/NotPetya/Nyetya/Goldeneye, BadRabbit, etc) which a traditional antivirus engine couldn’t detect without a signature.
With advancement in today’s cybercrime, there’s being advancement in detection of such potential threats, which brings me to Machine Learning (ML). According to wiki, Machine Learning (ML) is a field of computer science that gives computers the ability to learn without being explicitly programmed. In other words, computer trained to learn and identify malicious threats on its own.
Blusapphire is being integrated with Machine Learning (ML) engine that is capable of detecting any potential threats the moment they enter the network, making it easy to detect such sophisticated threats.
Last week one of our sensors has collected a file, which was flagged malicious by our Machine Learning (ML) engine. Being a zero-day, at that point in time, it has not triggered any AV flags. This post is an overview of the analysis made by Blusapphire ML engine.
We observed that the file was being downloaded from url “.pigcherrytoky.download”
Machine learning (ML) engine has flagged the file malicious and the file is loaded with some Anti-Debug techniques, making it difficult for debugging.
Being a zero-day, it has not triggered any AV flags, but the code within was matched over 176 known trojan malwares samples.
Malware being multipartite, it has refused to execute in pieces.
Abuse use of APIs:
Right after few hours the same PUP has being flagged malicious by multiple AV’s.
Since the outbreak of Petya/NotPetya which was surfaced in the month of June, again last week a new ransomware attack “aka BadRabbit” is making the headlines effecting machines in Ukraine, Russia, Turkey and Bulgaria.
Initial Attack Vector:
Unlike Petya/NotPetya that use SMB (Eternal Blue) as the initial vector, this variant uses drive-by-download type of attack to deliver the malware (BadRabbit) that spreads via malicious websites.
Diskcryptor to encrypt the files with selected extensions
SCmanager, schtasks and rundll32.exe to invoke other components
For lateral movement, it scans the local networks for SMB shares and spread via SMB
Mimikatz for credential harvesting on compromised machine
Adobe_Flash_Update – Dropper
infpub.dat – Main DLL
cscc.dat – Driver for Encryption
dispci.exe – DiskCryptor Client
Once downloaded, the executable dropper pretending to an Adobe Flash Update convincing the victim to install it
Upon execution it drops the main module DLL “infpub.dat” in “C:\Windows” directory that is further initiated by rundll.exe with arguments.
Executes the command “schtasks /Delete /F /TN rhaegal” to delete any existing tasks with name “rhaegal”.
During the execution of main DLL “infpub.dat” other components (cscc.dat, dispci.exe) responsible for encrypting are being dropped.
To launch the newly dropped components of diskcryptor “dispci.exe” on the startup, a new task is scheduled with name “rhaegal”.
New service named “cscc” is created for DiskCryptor Driver “cscc.dat”.
Schedules a task named “drogon” to forcefully reboot the machine at 04:46hrs, it appears that a reboot is required to install the DiskCryptor drivers.
BadRabbit encrypts only selected file extension as below and display ransom note.
Abuse use of APIs:
To perform credential harvesting, it creates and loads mimikatz to a file with extension “.tmp” (xxxx.tmp) in “C:\Windows\” and initiates a new process from the temp file “495E.tmp” with pipe.
Noticed that the malware scans the local network for ports 139, 445 and spreads via SMB shares with credentials harvested using mimikatz.
Lets assuming that we have created an APK with reverse shell payload and somehow installed it on victim’s phone, which upon execution would establish a direct connection to the victim’s phone.
Since the generated APK only contains the payload that doesn’t do anything when clicked and even the size would be in KB’s which looks very much suspicious and the victim would uninstall it immediately or doesn’t even install it.
In order to make the app look legit, we would inject our meterperter reverse shell payload in genuine android apps like facebook, adobe reader, whatsapp. This way the app appears to be legit which the victim installs and gets what he expected… we get the shell..:-)
In this article, we'd be using 64bit kali linux to build our backdoored APK. Before we start make sure below listed packages are being installed in the machine, if not execute below command from the terminal:
Apktool, this utility does come with kali linux if not check and update it. To install/update "apktool" following the instruction @ibotpeaches
Ways to Inject an Android APK File
Ther are different ways to inject our backdoor into an APK, we'll be using below listed utilities to build our malicious APK allowing an attacker to compromise victim's phone remotely
Injecting Payload with msfveom
Assuming we already have a downloaded android apk, we use it as a template to inject our reverse shell. Below command would allow us to inject the backdoor into original apk, which upon execution connects back to the IP specified within the payload.
Now that we have our APK ready with the injected reverse shell payload, all you have to do is send the file to the victim and trick him to install the app.
On the other hand keep the listener ready for the incoming connection using metasploit exploit/multi/handler. Once the victim installs and opens the app we would get a shell spawned.
Injecting Payload with “Backdoor-APK”
Another utility that can be used in backdooring an android app is “Backdoor-APK”. Behind the scene, this utility uses “msfvenom” and does the same by automating the process making it much easier to inject the payload into android APK and can be downloaded from github repository.
Having the downloaded Original APK and Backdoor-APK in same folder, execute the below command in the terminal which will prompt you to select the payload and details of the connect back IP and Port.
Once the required details are been provided, utility start injecting the reverse shell payload within the APK.
On the other hand start the listener for incoming connection using metasploit multi handler.
As expected we would have our final backdoored APK ready in “backdoor-apk -> original -> dist” folder, which we send to the victim and trick him to install it.
Once the victim installs and opens the app we would receive a meterpreter session.
Its is highly recommended to not to download and install apps from unknown sources and never enable the option “install from unkown sources” under “Setting -> Security”.
Install proper antivirus and make sure you never download or click url’s from unkown sources.
Lets assume, you’re in middle of a penetration test and were trying to gain access to a machine with Anti-Virus installed. Unfortunatuly, on every attempt you made AV was able to identify and block you from excuting the payload making you drive crazy and frustrating…
Besides the fact that most of the well known encoders are been detected by modern AV and IDS products. In such scenario using of custom encoders would be handy.
In this article, I'd be creating a custom encoding scheme based on simple XOR Operations called Rolling XOR. this technique could be helful in evading Anti-Virus and Intrusion Detection Systems(IDS) where necessary.
What is Rolling XOR Encoding Scheme..?
This encoding scheme basically uses a radomly generated key and performs the XOR operation on the first byte in the given array and uses the result as the input(new XOR key) to perform XOR operation with the next consecutive byte and so on.
Rolling XOR Python Encoder
Generates a random byte and use it as the base/key to perform the XOR operations.
Places the generated XOR key as first byte in the new array “xorout_f1/f2”.
Performs XOR between the first byte in array “xorout_f1/f2” and first byte in “code” variable and append result to new array “xorout_f1/f2”
This basically takes the result of previous XOR operation as the input(byte) and performs XOR operation with the next byte and same happens with all other bytes.
Continues the XOR operation till the last byte in “code” variable and final result will be saved in new array “xorout_f1/f2”.
Following is our decoder stub which helps us to decode the encoded shellcode. Here we will be using JMP-CALL-POP technique, to get to our encoded shellcode and thereafter we decode the shellcode back to original at runtime and execute it.
Having the above decoder stub ready, with the help of “nasm” compile the assembly code and generate the corresponding object file. Then use the “Objdump” to extract the decoding stub along with encoded shellcode appended to it. For commands to compile and extract shellcode Check.
Executing the Shellcode on Windows
For POC purpose, I’ve used the encoded message box shellcode which would eventually gets decoded at runtime with our decoded stub and executes the Hello World Message Box Popup. Following is our actual decoder stub in debugger without the encoded shellcode
Encoded shellcode within debugger. As per the decoder stub instruction “POP ESI” will pop the address (0x00446028) of encoded shellcode into “ESI” register, which is where the encoded shellcode begins.
By the time the decoder stub completes its execution we will have our actual shellcode ready to be executed from address (0x00446028) which is the beginning of shellcode and continues to execute our payload popping the “Hello World” message box.