If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete their account (if that doesn't require re-authenticating). Change their email address (if it doesn't require re-authenticating). Upload your own content or access key. Fake-redirect them to the login page, present a clone of the login screen, and try to steal their credentials. Send the exploit payload to other users. Mine BitCoin with their browsers' JS engine (OK, that one is pretty pointless).
Stealing cookies is kiddie-mode XSS. It's easy to do, but also easy to defend against, rarely needed, and sometimes pointless. To technically answer your question, obviously if you have the CSRF token (which is going to be either in a script readable cookie or just in the page's DOM, which you can also read) then you can launch CSRF attacks on the user... but you don't need to because you can make the user's browser do anything that CSRF could do, and much, much more, from script running on the same site.
If you can execute an XSS on the application, you should be able to get the user session cookies if the user is logged in and has clicked the link with the payload. Use a GET request inside your XSS payload to your server to capture those cookies.
CSRF token is definetly not enough to conduct any further meaningful attacks.