Acknowledge and chart losses
Let's use an example here. If I buy a 1 year membership card from my local supermarket, I get a 5% discount on my purchases. But do I really want to invest the $75 that this membership costs?
For now, let's say that just like how a company doesn't want to spend time tackling technical debt, we've decided not to buy a membership card. After all, I need to be spending my money on groceries.
- Dec 30 - Bought $200 worth of groceries for the NYE party. I paid $10 more than what I would've if I'd had that membership.
- Jan 3 - Weekly groceries $60. $3 could've been saved as a member.
- Jan 10 - Weekly groceries $60. $3 could've been saved as a member.
- Jan 17 - Weekly groceries $60. $3 could've been saved as a member.
- Jan 24 - Weekly groceries $60. $3 could've been saved as a member.
- Jan 31 - Weekly groceries $60. $3 could've been saved as a member.
- ...
It's a simplistic example, but you very quickly notice that in a month's time, you would've saved $25 by being a member. You don't even need to register the next 11 months to know that you'd be better of with a membership.
Counting weekly groceries alone, I would save $180 per year (for a total of $105 if you subtract the cost of the membership), and that's not even counting the occasional extra expenses.
The important thing to take away here is that recording a fraction of the total time (1 month) immediately revealed a reasonable expectation of of the total time frame (i.e. the year long membership, or the project's lifetime)
Weigh the cost of refactoring against the cost of not refactoring
If you document any time losses and extra effort being spent on things that were caused purely by technical debt, you quickly get an idea of how much time you waste on it, which you can contrast to the time you would "waste" on fixing the technical debt.
There is a relevant XKCD for this:

Look at the math. If your entire team combined on average loses 30 minutes a day on technical debt (which is more than reasonable), then you can reasonably spend 200 manhours (5 weeks) on doing nothing but refactoring and you'd still break even over a 5 year period (which is again a reasonable timeframe for a project).
This calculation isn't even accounting for features that will be added in the future, which would only increase the time wastage if you don't address the technical debt.
I'm aware that technical debt isn't as clearly delineated as grocery bills are, and you're going to have to make a judgment call on whether it contributed to a bug (or its fix) or not. This isn't objectively measurable. It's an estimate, and estimates are imprecise, but reasonable estimates tends to average out over a longer period. If your team cannot make reasonable estimates, then you've got bigger fish to fry.
If you document all tickets that were reasonably affected by technical debt, and estimate the time lost on that (some bugs count for 100%, others only partially, new features incure a % time cost due to a needlessly complex codebase, ...), then you quickly start seeing how much time this debt is costing you.
I suggest categorizing particular technical debts and tracking them separately. It's more meaningful to know how a particular debt is affecting you, so the company is able to only fix the debt which is creating an active issue for their bottomline.