harmon
Joined 5 years ago
Joined 5 years ago
Yes, it is an unfortunate design decision in the Microsoft implementation of the Kerberos protocol.
To interact with Active Directory and perform privileged actions, a service needs an Active Directory account that it can leverage for authenticated actions. This is colloquially referred to as a "service account", but it is not a special account type, it is just a regular Active Directory user or computer account designated for exclusive use by a service. Sometimes administrators will save time by registering a service under their own Domain Admin user account instead of creating a designated account for a service. This effectively makes their user account the service account. In other cases, extensive privileges may be required by a service (e.g. for network access control services, asset discovery services, vulnerability scanners, etc) and administrators find it easier to just create a Domain Admin (high privilege) account for that service than to do fine grained permissioning. This creates a dangerous situation where if an attacker can kerberoast the account associated with the service, they can immediately take possession of a high privilege account that can be used anywhere within the Active Directory environment.
> Since it's cryptographic signing, wouldn't this require reversing the hash?
Yes, you would need to brute-force it.
> Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
Theoretically yes, any valid inverse of the hash would work, but to my knowledge there aren't any hash collisions for the NT hash algorithm. Practically speaking, this means that only the user's password would yield the correct hash.
1. You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised. This allows for privilege escalation beyond simply accessing the service. For example, perhaps the service account has administrative access on other machines, or it is used for multiple services, or it is a Domain Admin in which case you can completely compromise the domain.
2. TGS tickets used to request access to a service are cryptographically signed with the password hash of the service account. Services use this to confirm ticket validity. In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users. Instead of accessing the service as a low privilege user, you can now access the service as an Enterprise Admin or another high privilege account which could enable access to more resources or administrative access to the machine. This is called a Silver Ticket attack.
TGS are (AES or RC4) encrypted with the NT password hash of the service account they are associated with. If you have a weak service account password, then TGS can be cracked to obtain the service account's password. A lot of times admins will create service accounts that have way more permissions than required (e.g. they make them a DA) which can lead to an immediate privilege escalation. Sometimes they also use regular user accounts for service registration instead of designated service accounts, and user accounts tend to have weaker passwords. To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
Even if the service account is lower privilege, this can enable a silver ticket attack. https://www.crowdstrike.com/en-us/cybersecurity-101/cyberatt...
There are multiple mitigations for this:
1. Use managed or group managed service accounts instead of manually managed ones where possible. This ensures that account passwords are long, strong, and rotated regularly. If you are going to provision service accounts manually, give them very strong passwords.
2. Apply the principle of least privilege and only assign service accounts the privileges they need. Avoid placing them in high privilege groups.
3. Disable RC4 in your environment if possible via Group Policy.
4. Monitor for RC4 ticket requests. AES-encrypted tickets are the default these days. https://adsecurity.org/?p=3458
5. Create a honeypot service account: https://adsecurity.org/?p=3513
There is a somewhat similar attack against TGTs called ASREPRoasting: https://book.hacktricks.wiki/en/windows-hardening/active-dir...
Also yes, taxes are listed as a separate line item.
The only case that I am aware of where you can take business losses / write offs and apply them to other income sources is in real estate, and only under very specific circumstances. This is one reason why high income individuals love things like short term rentals which is one circumstance in which this is possible.
Provision a home office? All of those expenses should be tax deductible.
BYOD? You should be able to expense a portion of the costs.
Pay for internet and power? You should be able to deduct a percentage of costs.
Have a work related meal? Tax deductible.
Drive your car to work? You should be able to deduct your mileage or depreciate your vehicle.
Pay for public transit passes to get to work? Tax deductible.
Etc, etc
1. Realistically you are doing well. You are already in a great role; it sounds like you may just be struggling a bit. You mentioned feeling overwhelmed: have you reached out to your manager or a more senior engineer on your team for help? I bet they would be able to identify any weak points that you have which you could fix with self-directed learning (which it sounds like you are experienced at). Has anyone made a comment on your performance? If not, is it possible that some of your feelings are driven by imposter syndrome? The fact that you were hired despite your academic record suggests that you are certainly a competent dev.
2. No one likes hearing this, but you need to be patient. You only recently began your professional career (whereas I am in my mid 30s), and it will take time to build up the reputation and the track record to offset your past. By "time" I mean probably a few years minimum. Don't be deterred by this though, as these few years will be periods of heavy growth. I should also note that when I say it will take time to offset past performance, I am speaking purely from an academic perspective. From a professional perspective, you left your academic record behind when you got your first job, so I wouldn't spend time dwelling on it.
3. I agree that getting a Master's degree may be helpful, if for no other reason than it sounds like you may have a chip on your shoulder about your academic record. If you are serious about going back to school, take the following actions:
* Work. Fucking. Hard. Build a track record of success in your role.
* Get a portfolio of projects together that you can show off.
* Continue your self-directed learning and fill in gaps in understanding yourself. Work with your manager / seniors to identify these.
* Succeed in some sort of graded endeavor that you can use to display that you are serious and diligent: take courses somewhere and get A's; take coursework on Coursera or something else and get a certificate; get an industry certification or two; do research and put out a paper; etc. Basically you want to show the program that you can succeed academically and that you won't flake out if they admit you.
If you want to chat about your situation further, I'm happy to do so out of band.
If you don't want to grow that's fine, but then don't go public and don't seek VC funding. Investors make money when you grow; they generally don't make much when you don't. Ergo, they will always be pushing you to grow.