Hacking a companies network (how secure is yours)

Soldato
Joined
30 Sep 2005
Posts
16,825
Well....I wouldn't call it hacking.

Today I was called in to check another companies network. The first thing I usually do is see if I can very easily hack their network. Although I'd hardly call it hacking, it tells me quite a few things straight off the bat.

The steps I use are as follows:

1. Write a very simple piece of code, along the lines of
Create LDAP connection, search for user objects, capture pieces of information into variables, loop. Secondly, take one account and write back a small piece of information. This is good because you'd be surprised how often you can access all this without any credentials.

2. Compile and save as an exe
3. Copy to onedrive, dropbox, google drive
4. Login as a standard user and see if a) you can access those sites b) if you can download exe or zips c) if the exe runs d) if the code works

Well today it did :rolleyes: If someone really wanted to cause damage, they could reset everyones password.

What tends to confuse a lot of IT engineers is that although Microsoft states "access to changing user accounts requires at minimum the account operators permission" that is not always true. The account I used was only a member of domain users. Historical misuse of delegation is what catches most people out....or testing things out and forgetting about them.

Just wondering how often you all try and find problems with your own networks.
 
Last edited:
At a previous large global Enterprise we did fail on a security test, when the PenTester rocked up, told reception that he was an AirCon Engineer and she let him into the server room without question :rolleyes: access rights were soon locked down to just certain members of IT then.

Oh that's quite a basic fail right there. Server rooms should have key fob access.
 
My favourite starting point is simply to run Zenmap/ nmap against a companies public IP range. There's very few times it doesn't turn up interesting results; did a quick audit for a company a couple of weeks back and picked up several RDS servers directly accessible over 3389, and some switches and ESX hosts with SSH open externally. Slack doesn't come into it with things like that... just pure mismanagement and incompetence.

That's really quite shocking
 
What was worse, particularly for the exposed RDS servers, is that they'd turned off password complexity & forced password change in AD across the estate. They'd left an open door with big neon signs around it inviting people in. This was not a small company either.

For me though... great... the audit writes itself very quickly :D

That password change at next logon could have come from the credssp fix back in 2018. We had that, although our RDS is on server 2019, in a DMZ, open only on 443. The workaround for us, was password complexity, and we are trialing Azure MFA for RDS.

I would be 99% sure that's why they disable that tick box on the users account. They do need a lockout policy though lol
 
Back
Top Bottom