Using scdbg to Find Shellcode, (Sun, Oct 27th)

This post was originally published on this site

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Unusual Activity with Double Base64 Encoding, (Sun, Oct 27th)

This post was originally published on this site

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.1rnAccept-Encoding: gziprnUser-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.36rnBS_REAL_IP: TmpBdU1Ua3hMalV5TGpJMU5Dd3hNVEl1TVRjdU1USTFMakU0TUE9PQ==rnHost: 112.124.42.80:63435rnAccept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2rnProxy-Connection: keep-alivernrn’

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Bridging the Gap Between NHS and Public Cloud with VMware Cloud on AWS

This post was originally published on this site

Following on from How VMware is Accelerating NHS Cloud Adoption, this post dives into more detail around how the UK National Health Service (NHS) can use VMware Cloud on AWS to bridge the gap between existing investments and Public Cloud. Part 1: How VMware is Accelerating NHS Cloud Adoption Part 2: Bridging the Gap Between NHS […]

Wireshark 3.0.6 Released, (Sun, Oct 27th)

This post was originally published on this site

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

NSX-T Data Center 2.4 Management and Control Plane agents

This post was originally published on this site


As in the previous article I have illustrated about the NSX-T DC 2.4 management plane and Central control plane which is now conversed into one nsx manager node.



MPA (Management Plane Agent): This agent is located on each transport node which communicate with the NSX manager


NETCPA:  It provides communication between central control plane and the hypervisor.

The management plane and the central control plane (CCP) run on same virtual appliance but they perform different functionality and will cover about they technical aspects below.

The NSX cluster can scale to max of 3 NSX manager nodes run on the management and CCP.


Communication process

The nsx-mpa agent on transport node get communicated with NSX manager over Rabbitmq channel which is on port 5671

Now, the CCP communicate with transport node through nsx-proxy through port 1235

The task of NSX manager is to push the config to the CCP. The CCP configures the dataplane through nsx-proxy, which is one of the component of LCP (Local control plane)



*MPA ( Management Plane Agent)
*NETCPA (Network Control Plane Agent)
*CCP (Central Control Plane)
*LCP (Local Control Plane) 

Happy learning…. 🙂

VMware vCenter Server Appliance – Backup and Restore Vulnerability

This post was originally published on this site

VMware has released a new security advisory VMSA-2019-0018 (VMware vCenter Server Appliance updates address sensitive information disclosure vulnerability in backup and restore functions). This advisory documents the remediation of one issue, rated with a severity of moderate. Sensitive information disclosure vulnerabilities resulting from a lack of certificate validation during the File-Based Backup and Restore operations […]

The post VMware vCenter Server Appliance – Backup and Restore Vulnerability appeared first on CloudHat.eu.

VMware PowerCLI 11.5 Released

This post was originally published on this site

VMware has released PowerCLI 11.5 latest version, with this release more than 20 cmdlets have been added. There are new properties available for the objects we all know and love, one of which has been requested for years. A big update for the VMC module, support for Horizon 7.10.0, and so much more. What’s new with […]

The post VMware PowerCLI 11.5 Released appeared first on VMarena.

Cloud Migration Series: Part 2 – VMware HCX Overview

This post was originally published on this site

In Part 1 of our Cloud Migration series we discussed traditional migration methods – Cold Migration and vMotion – and their requirements. This gives you the ability to migrate virtual machines to the cloud with the same technology you use on-premises every day, sometimes without even thinking about it. In Part 2 we are going

The post Cloud Migration Series: Part 2 – VMware HCX Overview appeared first on VMware vSphere Blog.

VMware Cloud Foundation 3.9

This post was originally published on this site

Reading Time: 3 minutes VMware Cloud Foundation (VCF) is VMware’s unified SDDC platform for the hybrid cloud and it’s based on VMware’s compute, storage, and network virtualization technologies to deliver a native integrated software stack that can be used on-premises for private cloud deployment or run as a service from the public cloud with consistent and simple operations. The core components of VMware Cloud Foundation are VMware vSphere (for the compute part), vSAN (for the storage part), and NSX DataCenter (in version -v or -T, for the network and security part). It’s more than a simple products bundle, because it gives a full validate stack with a fast provisioning, but […]

The post VMware Cloud Foundation 3.9 appeared first on vInfrastructure Blog.