Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:
- The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active when you hijack it?
- The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would make your attack fail.
- You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change a cookie so that the site cannot re-add them immediately.
Regarding the last point I would try to reproduce it as simply as possible using command-line tools. For example you could use curl to issue a request (using -b to set the cookie), similar to this:
$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/
The response would indicate if the setting the cookie is enough to log you in.
On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?
Yes, that's precisely what the HttpOnly flag is for, it prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but invisible via document.cookie.