The same client as above has called you back and believes they have mitigated the risk for what they need until a newly designed version is ready for production use. Until then they have the same internal web application is that you identified another php sanitation input validation failure that left a vulnerability you exploited and obtained access to the username database which was encrypted with MD5 at the time of design, but you noticed it is not the same as the one you cracked above. Maybe they changed their passwords since then which a quick test reveals they did, however your attempt to crack it again failed upon testing. Did they use a different encryption? You determine that this is an MD5 hash still and that it must be salted and were given a copy of the password policies that show changes every 30 days are required and the 13 character alphanumeric with ASCII symbols just like above though the admin did not secure the web app as you have a copy of their encrypted database again, he did up his game with the salted hashes as they have PII stored in the database as well as PCI DSS regulation to follow according to the clients description of the data stored on the client for billing. SSO is not enabled and the system was Apache and only accessed by a handful of employee's your obstacle is that you can't read the users or passwords still due to the salt, furthermore you get lucky and get the salt of a regular user account that was used for testing and just has dummy information as you can tell from the address 123 Main St. yet using this salt you go to test the next user and the login fails... You thought you'd save time and use your prior user list and assume the user was removed and try another user and the same salt to determine the MD5 hash's password, but it too fails... Once more you try, but this is on an employee account and it too fails... You are certain it is MD5 as the document outlines this and conclude they must have individual salts for each user now, which also has a new password from the last time and slightly different usernames as it was their e-mail address, but now it is just the xxxxxx@domain.com or you at least believe so as that is what worked for the 1st account you cracked. The server itself also require Multi Factor Authentication with the same RSA protections and no reverse shell or shell is available, however the clients are not required to use 2FA to login to see their account records and this is how you can verify success or failure still as you have the files.

Assessing a local Web Application used internally only that was developed in house and maintained by in house staff used primarily as a CRM with ERP integration. The local network follows latest NIST framework, 2012 R2 servers, Windows 10 Enterprise Workstations, Multi Factor Authentication with RSA Hardware tokens on SecurID 8.x SPx and has RBA enabled along with the GPO locked down for the workstation and DC and full disk encryption. Tokens are SID800's (both a pin and usb smart card) and the system only accepts TPM authentication to boot to the OS and CIS standard baselines in which you have no access to the network except on the segment the internal web application is that you were able to identify a php vulnerability and obtain access to the username database which was encrypted with MD5 at the time of design. As you were not given access nor was it in the project scope to go after the AD domain, but just the Web App which you now have a copy of their encrypted database in which they do require complex passwords as they have PII stored in the database as well. SSO is not enabled and the system was Apache and only accessed by a handful of employee's your obstacle is that you can't read the users or passwords due to the MD5 encryption, complex password requirements of 13 alphanumeric 2 upper and lower case with 2 different symbols and at least two numbers. CIS apache baseline tool was used on this system and for FreeBSD OS. The server itself also require Multi Factor Authentication with the same RSA protections and no reverse shell or shell is available, however the clients are not required to use 2FA to login to see their account records and this is how you can verify success or failure.

Attacking the SAM file on a 2003 R2 server with XP workstations and the default GPO applied to the domain. You are tasked with gaining access to a privileged account or access to the network from your laptop and without social engineering or physical access being granted to you. Their network is designed well, segmented, using RADIUS or TACACS+ for the switches, they have NAC implemented and policies in place. In these policies you notice that they have a BYOD policy that makes you more distressed as Cisco ISE is enabled as well, but then you notice a portion about guest access and are able to connect this way. You launch an arp attack and ad hoc attack on an employee who appears to be from another office and he/she ends up connecting to the guest network rather then continue being disconnected and having weird name resolution issues and use this to get access to their local file system and find a backup of their registry file and SAM file. Using this you guess they might have the same network account and realize even though Radius, NAC, Cisco ISE are all available to them and in use on the hardwired LAN they resorted to using WPA2-PSK for their wireless access on the corporate side as they really don't use it beyond meetings and for guests, but it gives you an in that you further exploited to obtain the SAM file from an AD server.

You have a pile of Apple iPhone's all running IOS 8 or earlier that you are to provision for the corporate network that were bought, but are encrypted and you do not have the access codes them. They are new HW models 6s, but IOS 8.x was used for whatever reason and now you need to get into all of these devices or waste your budget on 100 new ones. You have mobile forensic tools to connect to it and try brute force if you dare?