> It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
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.
If you have the user's credentials then you can indeed connect to the service as you normally would. The advantages of performing this attack are:
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.
Managed and group managed service account passwords are typically 240 characters long and rotate every 30 days. It is highly unlikely that an attacker can crack these.
This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs, which are used to request access to a registered service in Active Directory), not Ticket Granting Tickets (TGTs, which are used to prove identity to a Domain Controller and request TGSs). However, the general attack described is still correct.
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.
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.
As these tariffs are objectively likely to drive up costs, hurt user demand, and lower revenue for the company, I would argue that they have a duty to their shareholders and other stakeholders to push back against them and not be neutral. It is an action driven by business concerns rather than politics.
Also yes, taxes are listed as a separate line item.
As I understand it, you can only write off a business's expenses against that business's income, not income from other sources. For example, if you have a W2 income source and you have this business generating losses, you can't take your business losses or write offs and apply them to your W2 income, so you wouldn't really be saving any money as there would be no revenue to write off expenses against. You would need to get the business to generate revenue for this to be a viable idea.
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.
I agree, honestly I feel a much better solution to this problem would be to extend the same tax advantages that you allude to when talking about a personal company to W2 employees.
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.