I would suggest Option #4: Create a class library encapsulating this shared functionality that both sites could add as a Reference in Visual Studio.
This new project would be a Class Library in Visual Studio. It would have Domain Models that enforce the business logic of creating a new lead, and it would have Repository classes doing the actual INSERTs, UPDATEs and DELETEs from the Database, as well as fetching the data.
While people tend to immediately gravitate towards REST services, because your two sites are both using the .NET framework a shared class library will be easier to build, deploy, and maintain over the long run. Additionally, you won't need to incur the additional overhead of making HTTP requests and handling the responses, which will make both applications run faster for these operations.
I like to keep Martin Fowler's advice in mind regarding Microservices (which applies to Service Oriented Architecture in general):
First Law of Distributed Object Design: "don't distribute your objects"
Creating a REST service is just another way of "distributing your objects" since these objects must exist in both applications, and also must be serialized and deserialized for transit over a network.
He goes on to justify this "law":
My objection to the notion of distributed objects was although you can encapsulate many things behind object boundaries, you can't encapsulate the remote/in-process distinction. An in-process function call is fast and always succeeds (in that any exceptions are due to the application, not due to the mere fact of making the call). Remote calls, however, are orders of magnitude slower, and there's always a chance that the call will fail due to a failure in the remote process or the connection.
Why deal with a fickle network connection and web application stack when you can just make in-process calls to the same database? What you are really trying to avoid is duplicated code. Creating a shared class library for your two .NET projects achieves this.
Multiple Applications, Different Technology Stacks
If you had a public facing application written in Java, and your back-office application written in C# then you would have a good case for one of two solutions:
Create stored procedures in the same database that are called by both applications
Create a REST service called by both applications
Even then, I would go with stored procedures first, before creating a web service. If your public and back-office applications need to handle "leads" and you've got an Android and iOS app doing the same thing then I would create a REST or web service. Web services really start to shine in multi platform environments where one or more platforms are "client side" (i.e. in a browser, mobile app, or a third party company needs to use this functionality).
If it's just you and your company's web sites, go with a class library first, then stored procedures, and as a last resort create a web service.