To understand how to approach the problem you need to first understand from your superiors what the ultimate business goal is for having a cross functional Agile/Scrum team. Once you know that and understand the business perspective as well as understand the culture of the company and the goals of the individual members of the team can you begin to address the concern.
Cross functional skill sets among a team is a desired goal however hiring a new team isn't a good option. Even if you could find a number of .NET/Cobol developers who are experts in both technologies then they would be expensive and rare.
The best option is to invest in training your team. Depending on the culture of the business and your region this may also be an unattractive option to the business if typically in your area developers have a short tenure and are constantly hopping jobs. With the stated goal however of a cross functional team with such wildly disparate technology stacks needed for the following project, it is unfortunately the only way given the absolute that the team must be fully Cross Functional Agile.
When estimating user stories, let it be known that any given user story may be assigned to any given technical resource and that if a Cobol developer is given a primarily .NET user story that a .NET developer is obliged to provide guidance and direction to the Cobol developer. It might be a 1 point story for the .NET dev but a 3 point story for the Cobol dev. It is important to keep in mind that there are more Cobol devs than .NET devs so the .NET developer will have less available time for guidance and training making .NET tasks much more expensive. Pair programming is a useful tool while doing this so encourage this.
The advantages are that this investment in your team will result in them being more cross functional to where this is no longer an issue. The big caveat however is that user story estimation possibly being dependent on one or more people it will make various project management metrics meaningless for a while. It will be harder to evaluate an individuals contribution to a project if it seems like they aren't producing much but perhaps they are learning a great deal along the way.
On a side note, you mentioned the team has a Scrum Master but that you are called in to do this? In a typical Scrum team this kind of task is exactly the role of the Scrum Master.