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.
> 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.
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... ?
> 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.
Since it's cryptographic signing, wouldn't this require reversing the hash? Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
> 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.
Thanks, I think I get it now. Everything to do with cryptography always seems to struggle to stick in my head, though, even when I understand the math in principle.
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.
An actually useful mitigation would be to use service keytabs instead of service passwords. Because with a keytab, the keytab is a file that just contains an AES128/256/RC4 key instead of a password, which makes it sufficiently hard to guess. The service just uses this file to decrypt its service tickets then.
However, keytab usage is rare in the Windows AD world because people don't seem to comprehend what a keytab is and does, and why it is far better than using passwords for services.
Keytab usage is rare because the service you intend to run under that service account does not support keytabs.
There's also the knock-on effect of Kerberos being mostly hidden in Active Directory and creating keytabs requiring CLI tooling -- from way back when AD was a GUI only (mostly) affair for AD admins.
In my experience next to nobody knows about the CLI tooling for Kerberos in Windows. It's a damn shame, too, because Windows interops well w/ standard Kerberos in my opinion.
The only time that I can remember having to use keytabs is with ISC DHCP.... at home.
No 3rd party AD-integrated software, of which there were plenty of non-MSFT stuff, did I ever have to create a keytab for when playing Domain Admin at work.
I was a little irritated that Prof. Green didn't really discuss that Microsoft has made recommendations to mitigate. Thank you for summarizing.
The mitigations are there but it takes time for Microsoft's Customers to move to the new versions. I don't think that's Microsoft's problem. That's just their market. I don't think Prof. Green has an understanding of that side of it.
I guess one could argue that Microsoft should backport the new code to older products and give it to Customers who aren't actively paying for maintenance or subscription licensing. They made the business decision not to.
So my understanding is that Wyden's staff has been bothering the company about this class of vulnerabilities for a while, and the recent recommendations (a blog post explicitly cited in my post) are one output of that.
But I don't really accept this explanation. I always understand that there are legacy deployments and Microsoft needs to support them, but Kerberos-misconfiguration issues are extremely subtle in their implications, and MS should understand that one blog post (or some knowledge base articles) isn't going to get the message across to the hundreds/thousands of AD admins whose networks are currently at risk.
What I think recent versions of the MS software could do: (1) automatically scan configurations for accounts set up this way, (2) be incredibly annoying about changing the configuration (there are a handful of ways to do this that should be workable for many legacy configurations). If admins want to override the annoying and explicit warnings, that would be on them and not MS. As far as I can tell, Microsoft isn't doing this. But if I'm wrong, please let me know.
I absolutely agree that Microsoft could do better, but they are making progress in removing support entirely for broken (from a security perspective) older protocols such as NTLMv1 (which uses DES as well: more here -- https://bit.ly/crackingntlmv1) and SMB1.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
As an outsider it seems like MS has been much more proactive at moving away from insecure crypto in other places. For example, there was a while where every Windows release would disable some old insecure part of the SMB/CIFS protocol by default while still allowing it to be enabled for backwards compatibility if necessary.
Are they doing the same for AD? From the article it sounds like it falls back to RC4 automatically out of the box. That is something they should have started migrating away from at least a decade ago - gradually, with options for backwards compatibility to support their customers - but the fact that it is enabled by default in 2025 seems insane.
> 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.
I have a vague understanding of Kerberos, and this is where I’m mystified. Why is the KDC or anything else willing to issue a TGS ticket encryption against a service password before the requesting user authorizes themselves? Or is the issue that authentication and authorization are split and the KDC has no idea whether the requesting user is authorized.
The reason that the KDC doesn't decide if the user should get a ticket is that then the power requirements of the DC would be enormous. It should have to know if a user is supposed to have access to every single service in the environment. It would be a massive database. That massive database would also have to sync to all the other DCs.
To alleviate this, Kerberos let's the server decide if the user has access, and if so, how much
Kerberos doesn't concern itself with authorization, just authentication. It's up to the app to accept or reject a ticket, and that process is completely opaque to kerberos. It _could_ be extended since Kerberos allows pretty much any damn thing you want to happen with vendor extensions, but I'm not sure that's a situation you want AD to be handling given its track record in the rest of the security space.
Is this really a useful mitigation here? If someone has suitable presence to make requests to the TGS, then the time window for cracking and exploiting those tickets (if they are exploitable) is surely always going to be small compared to the rotation window. Hackers don't typically have the patience to sit running hashcat on an old GPU for weeks, they just find some way to get ephemeral access to a bunch of faster GPUs.
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.
Fair enough, I guess for some threat actors there is a difference between "uncrackable" and "crackable with more than 30 days effort". But that's a pretty select group of actors.
> This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs...
> TGS are (AES or RC4) encrypted...
What? No. The "TGS" is the "ticket granting service", and it's part of the KDC. A "TGT" is a "ticket granting ticket" -- an object, a blob which is a) a Ticket, b) whose service principal is a TGS principal (meaning of the form krbtgt/TARGET_REALM@ISSUER_REALM).
> TGS-REPs which are colloquially referred to as TGS tickets or TGSs
They are NOT colloquially referred to as such by anyone I know.
A TGS-REP is just a reply from the TGS. A TGS-REP bears a ticket which can be a TGT or not depending on various things.
I have never, ever seen a TGS-REP referred to a you say.
I have heard lots of weird things in the Kerberos space, but not this. E.g., I've see "GSS-API" pronounced as "guhsappi". I've seen people say "give me the Kerberos" (meaning "tell me how to get credentials").
FYI I am a Kerberos implementor/maintainer and have authored several Internet RFCs on Kerberos, and have supported Kerberos deployments at several organizations. Sorry to pull credentials here, but I'm annoyed that you felt the need to correct TFA on something they were not wrong about.
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 am not a lawyer or accountant, but you can fund your business with a loan from your person, and then if the business fails, you can write off the loan against your personal capital gains, and up to $3000 of regular income per year. This is not financial or legal advice.
I do not believe this is correct. If your business is a "pass through" style of entity, you can indeed deduct losses from other income (up to a point and with various limitations.) Doing too much of this can definitely trigger an audit.
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.
Mass surveillance is out of control as you say, and I am a strong proponent of reigning in warrantless wiretaps and governmental overreach. However, as many people have stated, a pen register (which requires a warrant) against a specific individual suspected of a crime where there is a MASSIVE amount of evidence suggesting that the suspect is guilty has nothing to do with mass surveillance. This is targeted, narrowly scoped surveillance of a specific suspect and is precisely what law enforcement should be doing.
So I used to be in a very similar boat as you: I was depressed while working towards a STEM degree in college and ended up almost failing out with a 2.X GPA. I didn't see a path forward, and there was only one entity that was willing to hire me to do "real" work (for basically minimum wage). Like you, I thought I was totally fucked. Turns out, I wasn't. I spent the next 7 years working incredibly hard at that job. I taught myself software development skills in a similar manner as you out of personal interest. Eventually I was skilled enough to make major contributions at work and transitioned into a developer role. I continued studying and also took some remedial courses at a local university to prove that I could get A's if I tried. I then applied to a Master's program with glowing recommendations from my employer, a proven professional track record of success, and the transcripts from the local university. I was sure the admissions people would laugh and toss my application right into the trash. Guess what? I got into a great program! I'm now working in my dream role at a tech company, I got the opportunity to go back and prove to myself that I could succeed academically, and I learned a lot while in the program. You are already at a prestigious company as a full stack dev, so your road could be A LOT shorter than mine. I will give you the following advice based on my experience:
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.
Ultimately if users are satisfied and happy, does it even matter if it is fake? The end goal is not to create a real relationship, it is to create a happy fantasy for the buyer.
If they think they have a real relationship with the real woman behind the camera, they are as delusional as the people who tweet at celebrities and think they have a real relationship with them.
Can’t help but think of the guys writing this behind the scenes:
“It may take me a couple of days to really grasp using this platform and answering all my messages but I will get back to each of you! I will also be taking photos to share on the wall for free with some PPVs over the next couple of days. It is ONLY ME on here, so , I'd love some suggestions! PS; I'd like to also know what time is best to come on and not miss you... also, going to try and do some live streams when I get it all figured out!" Richards wrote.
“You see how there’s a space before the exclamation mark?” he said. “Yeah, that’s how 18-year-olds type.” When it comes to sales, Rosero said, those details make all the difference.
…
“An older lady won’t use emojis; she’ll use, like, a semicolon and parentheses for a winky face, when a younger girl will actually use a winky emoji.”
Is it really even a scam? They are hiring someone to pretend to be interested in them, and they are getting someone pretending to be interested in them. If they can't effectively distinguish between the two, where is the scam? Where is the bait and switch?
> The endless pursuit of growth is usually a byproduct of ego or at the behest of some intangible idea of "creating shareholder value."
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.
The existence of an "active" God as portrayed in most religions would complicate things tremendously though. If an entity can inject energy into the system or can alter system properties at will then the fundamental assumptions about the way the universe works go out the window.
Is it not true that if this entity is not limited by space-time, then they can easily alter the past to affect the present, and no one in the present would be the wiser, since there is a cascading effect of changes?
In my head 100 times out of 100 my "decision" to raise my hand or open my mouth results in said action. Are you suggesting the fact each decision is made at all is due to non-deterministic quantum effects? I thought neural activity had already been demonstrated to operate at a classical level though.
If you are open to another viewpoint, that free will is an illusion, listen to Sam Harris’s take on it (he’s a neurologist). Here’s a summary of his book on the topic as well as mentions from a few other cognitive psychologists and neurologists who came to the same conclusion: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6701738/
Yes, familiar with his take. I honestly don't see any alternative hypothesis that makes sense. But the illusion is too good to allow me to believe that it is one.
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.