This probably isn't the best idea. The only way that comes to mind to do this is to capture the queries in a profiler or extended events trace and transforming the output to do what you want. That's going to add overhead and ultimately be quite hacky and unreliable.
You'd probably be much better off using something like log shipping, so you can take log backups from your main database, copy them to your off site server, then restore them against the database(s) on that server. Then you get all the changes in a manner you can rely on with minimal overhead.
In answer to follow-up question:
There would be no downtime. Taking transaction log backups (like any other backup) creates some overhead, but it is generally good practice to be doing this regardless of needs to replicate the data.
Log shipping is generally easy to set up:
But you may need to craft your own equivalent if you don't have easy connectivity between the two servers.
Before you start you need to make sure the source database is in FULL recovery model (you can't take transaction log backups otherwise) and restore a copy of it to the destination server using a full backup with the STANDBY option. STANDBY will put the database in the state where it is readable (but not writeable) and transaction log backups can be applied.
Then your log shipping consists of three components:
1) Have a process on the source box (a SQL Agent job usually) that takes log backups on your source database. The more often you take these, the closer to real-time your destination database can be.
2) A process that copies the transaction log backups to your destination server.
3) Another process, this time on the destination box (again usually SQL Agent) your restores the copied logs to your destination server. Again, using the STANDBY option.
Apart from that you just need some housekeeping, e.g. to remove the log backups once they have been restored or after a certain length of time.
When you use the "built-in" version of log shipping you get some extras, such as monitoring and logging of what is going ob, but overall it is a simple process, so not too hard to replicate on your own.