Proxifier Username And Password Free
Rubie Mccloughan
Proxy auto-configuration files do not support hard-coded usernames and passwords. There's good reasoning behind this too, since providing support for hard-coded credentials would open up significant security holes, as anybody would be able to easily view the required credentials to access the proxy.
Rather configure the proxy as a transparent proxy, that way you won't need a username and password. You mention in one of your comments that the proxy server is located outside your LAN, which is why you require authentication. However, most proxies support rules based on the source IP, in which case it's a simple matter of only allowing requests originating from your corporate network.
The original proxy auto-config specification was originally drafted by Netscape in 1996. The original specification is no longer available directly, but you can still access it using The Wayback Machine's archived copy. The specification hasn't changed much, and is still largely the same as it was originally. You'll see the specification is quite simple, and that there is no provision for hard-coded credentials.
I've been trying to set up a SOCKS proxy on linux with danted. I have the proxy working perfectly without authentication, but when I try adding in authentication with both method: username and method: pam I can't log in with any of the usernames or passwords that I set.
I also tried it with method: username and i get the same issue with a system password userauthentication failed. I am testing these with the proxifier proxy checker and they always return bad username or password.
I fixed the issue eventually by removing the version of dante I had installed via apt and replacing it with one I downloaded from the dante website and compiled from source. There must be a bug in the version in ubuntu's repositories.
ADExplorer is a tool I have always had in my backpack. It can be useful for both offensive and defensive purposes, but in this post, I am going to focus more on its offensive use. The tool itself can be found here: -us/sysinternals/downloads/adexplorer
A typical scenario I often face on engagements is that I have compromised a server or workstation, and I am able to get my hands on the local NTLM hashes as well as the computer account NTLM hash used to authenticate itself against the Active Directory domain. One way I typically end up in this scenario is to proxychain through a beacon on a user's workstation and use a known exploit to gain administrative access.
So, how do we use the Active Directory computer account over SOCKS to look at Active Directory? Well, of course there are many tools out there such as Impacket or LDAPPER, but today I'll be covering ADExplorer.
The C2 server should now have port 4444 open and allow proxy traffic through into the network where you have the beacon. I recommend that you use iptables to only allow SSH into the C2 server (that topic is something I will not cover in this post, so I recommend Googling on how to do that). Do not allow access to port 50050 (Cobalt Strike Team Server Port) or 4444 directly from the Internet. Instead, use SSH and forward those ports. To set up a port that is forwarded to 4444 on the C2 server SSH, I simply run the following SSH command:
Once that is taken care, of you open up Proxification Rules and make sure that both Localhost and Default are set to Direct. Once that is verified, add a new proxification rule by clicking the Add button.
Next, I am going to fire up ADExplorer.exe, but since I am using a machine account hash instead of a username and password, I will need to inject the hash. However, if you know a username and password, you could simply start ADExplorer and fill out the server IP address in the connect to, user, and password fields.
ADExplorer should now launch and all I need to fill in is the IP address for the domain controller in the connect to field. Since I have injected the hash into the process, ADExplorer will use the current authentication inside the process, so you should not need to fill in user or password.
Hit OK, and if you did everything correctly, you should be able to browse Active Directory over SOCKS with ADExplorer using a machine account hash. You can verify that traffic is flowing by looking at Proxifier. If you want to use a port other than the default 389, you can specify it by adding a colon at the end. It is preferred to use LDAPS whenever you can by using 636 as the port.
Looking at Active Directory over a SOCKS proxy can sometimes be very slow, so I often take a snapshot. The snapshot basically takes a copy of everything it can read from Active Directory and stores it to a file on disk over the proxy into the local machine from which you are running ADExplorer, so take bandwidth into consideration before doing it. To do this, highlight the connection (192.168.86.22 [DC1.oddvar.moe] in my case) then click File > Create Snapshot.
Fill in a path to store the dump and press OK. This could, of course, take a while if the Active Directory database is rather big. For a company with around 30,000 users, it is not uncommon for the dump to be over 800 MB in size. Once the dump is finished, I can open up the dump offline at any time using ADExplorer without the need to connect to the environment over the proxy. Instead of filling in connection details, I simply choose 'Enter the path of a previous snapshot to load' when starting ADExplorer.
In the early stages of an engagement, I typically do not know all the subnets or geographical locations of the organization. One (1) place where this is stored (if sysadmins decided to implement it) is inside Active Directory. This is implemented so that Active Directory can set up the best possible replication topology as well as direct the authentication requests to domain controllers residing in the same site as the user or computer authenticating. To find the sites, I browse to the Configuration partition and look at the sites container as shown in the following screenshot.
By highlighting the domain, I can see interesting details about the domain such as the status of the password policy or even the ms-DS-MachineAccountQuota. This password policy can be overwritten if the customer is using fine-grained password policy, so you need to be sure of that if you are planning to start a password spray based on this policy.
By default, all authenticated accounts in Active Directory can add computers to the domain, and the ms-DS-MachineAccountQuota is the attribute that determines how many computers can be added by a given account (10 by default). This can be restricted in other places, such as a Group Policy, but it is worth checking what the value is. If it is 0, it means that normal users cannot add computers to the domain.
If you are curious about whether there are trusts in play, you can search for them by looking for objectClass attributes that are set to trustedDomain, like the screenshot below.
This should list out trusts, and if I double click on any of the results in the lower portion of the GUI, I can jump right to the location in ADExplorer. Once there, I can find additional details about the trust such as trusttype, trustdirection, and more.
When the environment has LAPS implemented, there is a chance that these passwords appear in plaintext, meaning what you see in this field is the actual password. The LAPS password is stored in the ms-msc-admpwd attribute.
Sometimes I just search for 'description not empty' and manually look at the results. There is also a bug that I encounter sometimes using offline ADExplorer snapshots when using the 'contains' search that crashes ADExplorer, but it works when using ADExplorer online, so the problem is not too big.
I also want to mention others who have done some great writeups on ADExplorer before this post. A great post written by Sally Vandeven over at Black Hills shows us how to edit objects using ADExplorer among other things: -goodness-learned-love-ad-explorer/
Another awesome addition is ADEGrab , created by Stuart Morgan at MWR Infosecurity. This is super useful if you ever want to grab the search results from ADExplorer since there are no native ways of doing that.
To obtain an IP address to enter into the PIA application, please `ping` the hostname to receive an IP address for the above domain address (proxy-nl.privateinternetaccess.com) by entering the command into the command prompt (PC) or terminal (Mac & Linux). Once an IP address has been obtained, add it to the VPN application and the port 1080, followed by your SOCKS5 username & password detailed below.
You will require a different username and password to use the SOCKS5 proxy. This username and password are found in the Client Control Panel. The SOCKS5 username will remain the same for the duration of the account and will never change.
Beginning with v1.4.0, the desktop application now supports using a SOCKS5 proxy to connect to the VPN server. For more information about this new feature please review the following article Understanding the Multi-Hop Feature
--proxy-type may be omitted; it defaults to http. If is omitted, it defaults to the well-known port for the chosen proxy type: 1080 for SOCKS and 3128 for HTTP. An exception to this rule is when the proxy host is given by a IPv6 address; in this case the port is required because otherwise it would be ambiguous whether the digits after the last colon are the port number or part of the address.
In listen mode the proxy port number is not automatically set and will be the default of 31337 unless specified. The proxy supports the GET, HEAD, and POST methods used in web browsing, as well as the CONNECT method that allows tunneling arbitrary TCP connections. (When Ncat connects as a client, it uses CONNECT.) Use --proxy-auth to make the server require authentication with a specific username and password.
b1e95dc632