Hey @AlexisA There is something wrong with the labs when you restored them. None of the instructions match up to what is there.
For example in Lab #2 it states to RDP to 172.16.80.100 but 172.16.80.100 is not configured for RDP (3389). There are lots of IP’s that respond via NMAP open on port 80 and 443 but nothing with RDP.
Are you able to check this → These steps might not be lining up since you restored things.
For this lab, you begin in the Pentester VLAN, however, your customer has provided you with Remote Desktop access (RDP) to one of their machines (workstation01 - 172.16.80.100) to perform an assume-breach assessment. The provided machine is a standard build for their environment, and the credentials provided to you are:
- Username: els\analyst1
- Password: P@ssw0rd123
NOTE: After each scenario, we recommend that the environment is reset back to its original state (Stop button, then Reset button).
Thank you for pointing this out, because of the lab changes a few modifications were made to the environment which consequently affected the IP addresses.
I sincerely apologize for the inconvenience, i am working on updating the documentation as we speak and expect the latest updates to be pushed before Thursday.
Let me know if i can help in any way.
Hi Alexis and INE Team,
Thank you for the great work you’ve invested in this platform. I am experiencing the same issues reported by @MushBrain on 12/13/2022. IPv4 CIDR subnets do not match the instructions. Additionally,
25/TCP SMTP service we’re tasked with Banner Grabbing on Task 1 of Red-teaming Active Directory Lab #1 (ELS.LOCAL) is not available
As of 12/17/2022 the lab titled
**Red-teaming Active Directory Lab #1 (ELS.LOCAL)** part of the
**Advanced Penetration Testing** Learning Path (corresponding to PTX/eCPTX course and certification exam) seems to only allow partial access to at least one of the targets depicted in the Tasks/Solutions section. This partial access prevents the student from successfully completing the tasks in the lab. Details can be found in the screenshot below:
In the task depicted, the request is to perform the following command
*nc -nv 172.16.250.2 25*, a ‘banner grabbing’ technique, on the application running on port 25/TCP of host 172.16.250.2.
The issue is that host 172.16.250.2 does not respond on 25/TCP.
In this lab, a malicious batch file generated via MSFvenom and sent to the mail-server running on port 25/TCP of host 172.16.250.2 is the intended method to obtain Initial Access.
The issue has highlighted by Mushbrain still persist, could you confirm if the latest updates has been pushed and the lab is back to normal.
Still there, all AD labs are unusable