A few days past, a particular Zero-Day vulnerability has been seen on the wild being exploited on pretty much ~ e v e r y t h i n g ~.
This Log4shell or Log4J is being tracked as CVE CVE-2021-44228 and it’s impact is pretty wide.

Why the broad impact?
Let’s try to define this Zero day, this vulnerability is based on the Java Logging library The exploitation ends up on a Remote Code Execution when logging a certain string.

You can imagine the rest when we say logging library and Java. Which is broadly utilized in big enterprise Java software tools.
Not only that but the amount of interdependencies and old tools using this log4j library makes the scope wider than many of the recent vulnerabilities out in the wild. Where definitely the number of vulnerable products will increase as time passes on.

Some Hashes to help search for vulnerable Log4J versions:
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

You can find on the below github repo a Proof of Concept:
https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

and as well a nice Burp Suite extension useful to scan for log4j2rces :D
https://github.com/tangxiaofeng7/BurpLog4j2Scan

Randori has added details on VMware products impacted as well on below link:
https://www.randori.com/blog/cve-2021-44228/

Whereas VMware has released their Advisory with a list of impacted products:
https://www.vmware.com/security/advisories/VMSA-2021-0028.html

Under these all the most common solutions as vCenter Server, Horizon, NSX-T, Tanzu, among others.

A few weeks ago VMware decided to allow the community in general to try out Tanzu.
This by releasing a full deploy’able community edition of Tanzu.

What’s Tanzu Community?
As explained on their landing page;
“VMware Tanzu Community Edition is a full-featured, easy-to-manage Kubernetes platform for learners and users, especially those working in small-scale or preproduction environments”

Remember this is not supported by their product support centre. This edition is community supported.

Also VMware has a All-in Academy for Kubernetes https://kube.academy/.
Be sure to check it out, it does have awesome training material with useful resources, and it’s FREE!

More ransomware variants are seen on the wild targeting more and more ESXI hosts.

Within the few last months some ransomware variants have been found targeting ESXI servers and their virtual machines.
MalwareHunterTeam recently found a linux version of the REvil ransomware that was targeting ESXI servers by using the ESXCLI commands.

Today was detected a Blackmatter’s ransomware x64 linux variant \ ESXCLI Variant.

Firewall disable via ESXCLI:

esxcli network firewall set --enabled false

Forcibly Stop a Virtual Machine with ESXCLI
(query ..->”WorldID,DisplayName”):

esxcli vm process kill --type=force --world-id <ID>

via: Vitali Kremez https://twitter.com/VK_Intel
https://twitter.com/VK_Intel/status/1423188690126266370

Crowdstrike has a really good article as well on ransomware targeting ESXI server:
https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/

Resolute!

A not so old Machine retired just a few days (if you are reading this around 06/02/20).
Another Windows OS based machine, Windows machines are my least favorite ones :(

But here’s my write up for Resolute!

Please note for the sake of keeping the post short I’ve trimmed a lot of stuff from my original experience with the machine.

Starting off with reaching the box which has IP: 10.10.10.169

root@kek:~# ping resolute.htb
PING resolute.htb (10.10.10.169) 56(84) bytes of data.
64 bytes from resolute.htb (10.10.10.169): icmp_seq=1 ttl=127 time=97.10 ms
64 bytes from resolute.htb (10.10.10.169): icmp_seq=2 ttl=127 time=126 ms
64 bytes from resolute.htb (10.10.10.169): icmp_seq=3 ttl=127 time=115 ms

Now off to fire up our nmap scan:

| root@kek:~/htb/resolute# nmap -sV -sC -sC -T4 Resolute.htb 10.10.10.169

All them ports:

Bastion!

A bit old by now but one of my favorites boxes to root; since I had some familiarity with SMB.
We have the basic information for the box, It’s a Windows Machine we got IP and off we go..
Let’s get into it! .

root@kek:/# ping bastion.htb
PING bastion (10.10.10.134) 56(84) bytes of data.
64 bytes from bastion (10.10.10.134): icmp_seq=1 ttl=127 time=184 ms
64 bytes from bastion (10.10.10.134): icmp_seq=2 ttl=127 time=178 ms

Now we scan for ports and interesting stuff:

 | nmap -sV -sC -sC -T4 -oA Bastion 10.10.10.134

Using nmap we got some interesting ports open:

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH for_Windows_7.9 (protocol 2.0)
| ssh-hostkey:
| 2048 3a:56:ae:75:3c:78:0e:c8:56:4d:cb:1c:22:bf:45:8a (RSA)
| 256 cc:2e:56:ab:19:97:d5:bb:03:fb:82:cd:63:da:68:01 (ECDSA)
|_ 256 93:5f:5d:aa:ca:9f:53:e7:f2:82:e6:64:a8:a3:a0:18 (ED25519)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds
Service Info: OSs: Windows, Windows Server 2008 R2–2012; CPE: cpe:/o:microsoft:windows

Soo two interesting ports we are going to check in detail are SMB and SSH; as a noobish guy at first I was trying to brute force SSH but after a while I decided to throw away the idea of an easy brute force ssh connection.
I went for the SMB route; If we take a close look at nmap info;

| smb-os-discovery:
| OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
| Computer name: Bastion
| NetBIOS computer name: BASTION\x00
| Workgroup: WORKGROUP\x00
|_ System time: 2020–05–26T04:39:56+02:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020–05–25 22:39:57
|_ start_date: 2020–05–25 18:03:52>

Welcome to my blog