Using scdbg to Find Shellcode
I've written a couple of diary entries about scdbg, a Windows 32-bit shellcode emulator.
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.
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com
Unusual Activity with Double Base64 Encoding
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 (60.191.52.254)
TmpBdU1Ua3hMalV5TGpJMU5Dd3hNVEl1TVRjdU1USTFMakU0TUE9PQ== → NjAuMTkxLjUyLjI1NCwxMTIuMTcuMTI1LjE4MA== → 60.191.52.254,112.17.125.180
60.191.52.254 → ISC reports shows scanning for 1723 and 3128
112.17.125.180 → No ISC reports
112.124.42.80 → 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[2].
Here is a copy of the raw log:
tcp-honeypot-20191019-075047.log:20191025-222956: 192.168.25.9:8088-60.191.52.254:49110 data 'HEAD http://112.124.42.80: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: 112.124.42.80: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://112.124.42.80:63435/ HTTP/1.1
Accept-Encoding: gzip
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
BS_REAL_IP: TmpBdU1Ua3hMalV5TGpJMU5Dd3hNVEl1TVRjdU1USTFMakU0TUE9PQ==
Host: 112.124.42.80:63435
Accept: text/html, image/gif, image/jpeg,
Proxy-Connection: keep-alive
[1] https://isc.sans.edu/ipdetails.html?ip=60.191.52.254
[2] https://www.abuseipdb.com/check/60.191.52.254?page=49
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Wireshark 3.0.6 Released
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.
Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com
Comments