Last Updated: 2019-10-28 07:02:04 UTC
by Didier Stevens (Version: 1)
If you're not familiar reading assembly code or machine language, scdbg can help you understand what shellcode is doing, by emulating it and reporting relevant Win32 API calls.
By default, scdbg assumes that the shellcode's entrypoint is the first instruction, e.g. position 0. That's not always the case, and you can use option -foff to provide a different position (offset). But this assumes that you know where the shellcode's entrypoint is. And determining this can be difficult too when you analyze malware.
To help you locate shellcode's entrypoint, or just find shellcode inside a file, scdbg has an option: -findsc.
As an example, I created a JPEG file that contains shellcode (not an exploit, the shellcode will not execute, it's just hidden inside a JPEG image).
Giving this file as input to scdbg using option -findsc does the following:
scdbg tries all possible entrypoints to the shellcode in this file, and then reports entrypoints (offsets) that lead to emulations that resulted in a Win32 API call or a long execution (many steps).
In the screenshot above, we see that scdbg found 6 offsets (numbered 0 through 5). Entry 0 looks promising (offset 0x7C2), as this lead to the call of MessageBoxA.
scdbg then prompts for the index of the shellcode's offset to emulate. I select 0 and get the following result:
This is indeed shellcode that was found at position 0x7C2: it displays a message box and then terminates the host process.
Last Updated: 2019-10-27 12:59:10 UTC
by Guy Bruneau (Version: 1)
This week I found this traffic in my honeypot, my first impression, it didn't look that unusual since Base64 encoding is used quite a bit to encode traffic to a web server. Using CyberChef, I decoded the Base64 portion to see what it was all about only to find out it was further encoded in Base64. Decoding the second Base64 revealed two IP address in it.
However, the interesting part after decoding it was the IPs were already in the traffic payload. The first IP was the source of the traffic (188.8.131.52)
TmpBdU1Ua3hMalV5TGpJMU5Dd3hNVEl1TVRjdU1USTFMakU0TUE9PQ== → NjAuMTkxLjUyLjI1NCwxMTIuMTcuMTI1LjE4MA== → 184.108.40.206,220.127.116.11
18.104.22.168 → ISC reports shows scanning for 1723 and 3128
22.214.171.124 → No ISC reports
126.96.36.199 → No ISC reports. Hangzhou Alibaba Advertising Co.,Ltd., CN
Another search of my logs revealed this kind of activity had been happening for quite a while and it is always the exact same query down to the IPs and ports. I have logs for this activity since February this year on port 80 and 8088. and the same high port (63435) used in all the traffic. A search in for BS_REAL_IP shows other honeypots.
Here is a copy of the raw log:
tcp-honeypot-20191019-075047.log:20191025-222956: 192.168.25.9:8088-188.8.131.52:49110 data 'HEAD http://184.108.40.206:63435/ HTTP/1.1\r\nAccept-Encoding: gzip\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nBS_REAL_IP: TmpBdU1Ua3hMalV5TGpJMU5Dd3hNVEl1TVRjdU1USTFMakU0TUE9PQ==\r\nHost: 220.127.116.11:63435\r\nAccept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2\r\nProxy-Connection: keep-alive\r\n\r\n'
Generic Code beautify by CyberChef:
HEAD http://18.104.22.168:63435/ HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh
Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Accept: text/html, image/gif, image/jpeg,
Last Updated: 2019-10-27 09:19:23 UTC
by Didier Stevens (Version: 1)
Wireshark version 3.0.6 was released.
It has some updates for macOS (like installation by dropping the app in the Applications folder) and bug fixes.