The business logic should only be in the Model because this logic is technology-agnostic (it doesn't matter you wrote an ASP.NET or a PHP app, the business logic stays the same) and the only part of an MVC app that could (and should) be technology-agnostic is the Model: the View, kinda obvious why it's bound to a technology, controllers are often bound to a view and their structure is often enforced by the technology.
The feeling you are experiencing in your controllers has a name: Fat Controller. It is commonly described as an anti-pattern (see here for its counterpart).
Next, to avoid your model classes to become god classes, I can advice you to have a look at the Clean Architecture which will help you to implement the MVC in a clean, reusable and testable way.
Here's how I see the different layers (note for experienced readers: I've willingly simplified to make it understandable for the OP):
View <==> Controller <==> Business model <==> Data access
Data access layer
Also known as DAL, its only purpose is to do a one-to-one with the database (or whatever storing system you use) and make the data available in an object-oriented application. IN C#, these classes often have the form of a POCO (containing only accessors) and have no logic (methods) inside. This layer is part of the Model (in the MVC sense).
Its purpose is to reflect the business reality. If you are developping a finance app, you will typically have all the computations in this layer (calculate interest, refunds, etc.). This layer should be framework-agnostic, so one shouldn't find any trace of SQl, XML or any storage possibility nor any call to Session, View, Console, etc. This layer is also part of the Model (in the MVC sense).
Its purpose is to declare what will be the outside boundary of your system. Generally it consists of an user interface but it could also be a web API, etc. This layer has no logic but only fires events based on outside triggers. As you probably guested, this correspond to the View (in the MVC sense).
Its sole purpose is to handle view events. It contains all the "routing" rules, i.e. knows that when event X is fired in the view, it should call method Y in the business logic to satisfy the user request. Again, as you probably guested, this correspond to the Controller (in the MVC sense).
I hope things are more clear now.