Welcome to another in this series of OSINT investigations on Matrix. If you haven’t read it already, or for a quick introduction to the basics of the Matrix platform, please read the first article in this series. After that introduction we took a detailed look at the platform and it’s major components, how they interact, what data they expose, and how to find it – read it now if you want to learn about how data is organized on Matrix.
In this installment we’re going to look at creating accounts, and searching for rooms and homeservers. We’ll share a few tips about messages and other events, and discuss the sort of research you might find useful on this small but growing platform. Then we’ll wrap things up by looking at tools, bots and an introduction to building them. But that’s next time, let’s dive into today’s topic!
So let’s take a look at some of the basics of conducting investigations on Matrix. You probably want to start by creating sock puppets. This is trivially easy because username and password are the only things required by most homeservers. As you might imagine this leads to plenty of anonymous trolling in the larger rooms.
You can provide an email and phone number to an identity server to allow people to search for and find your account. vector.im is the commonly-used identity server. The homeserver itself can always require more to create an account, and homeservers with more cringe-worthy or illegal content will manually approve accounts or require an invitation to join.
The first OPSEC “gotcha” to avoid is letting your session identifiers identify your client and operating system, and if using browser-based client, your browser type. Set this once and avoid logging out when using a desktop or mobile client, otherwise it will create a new session when you log in again. Set it each time and delete the previous sessions when using a browser.
When you have an account on a homeserver, you might get invited to private rooms based on that account. A private room with users from only one homeserver will have a chat that is only visible to that one homeserver. If new account registration on that homeserver is by invite only, then it can be quite hard to know about. This poses quite a challenge for some OSINT researchers who might not be in a situation where they can join shady homeservers under false pretenses even if invites are given out liberally.
Often groups with questionable motives will setup public vetting rooms. invitations will be sent to all users of a large room, or to users in all public rooms on a small homeserver. Needless to say this annoys other homeserver and room administrators, and over time tends to get certain homeservers blocked from major rooms. You can recognize this activity by observing the vetting rooms and noting comments from admins like, “If you’re interested in even more, DM me for a link to join our private room.”
We mentioned a couple of sources (here and here) for finding homeservers earlier but those lists are tailored to users trying to find a homeserver to create an account on. To find homeservers to join for OSINT purposes you might want to use some different techniques.
Some topical rooms will naturally attract both criminal and law enforcement; let’s say for our example a room about darknet markets. In many of these rooms, moderators will actively ban any sort of troublemakers, and are likely to ban users who post offers to sell fake documents, stolen credit cards, etc. to the room. Check the ban list or the server ACL for that room to see homeservers whose administrators are less responsive to complaints about abusive behavior by members.
To find interesting rooms to investigate, start with the room search function built into most or all graphical clients, commonly labeled “explore rooms”. By default this is going to list the public rooms your that your homeserver has an alias for. That means some user account on that server has the permissions in a given room to assign a local alias and make it visible to local searches.
We can easily change the homeserver to search on, by choosing an existing one from our dropdown list of previous chosen search servers, or by adding a new server. So to search for public rooms on evil.com homeserver, click to see the dropdown list and choose “Add a new server…”
The result set is ordered by number of users in each room by default. If the results set is large, use the search field to reduce the number of results returned.
So we found interesting rooms to join, what now? Explore them – some will be dead, with users joining and leaving with no conversation happening. Some will be active, with discussion in progress. Let’s talk briefly about what a message is, how you can search through them, and learn a few tricks in the process.
A user composes a post and sends it to a room to engage with the other room members. As we mentioned earlier, what really happens is that the user’s Matrix client comunicates to their homeserver, which relays the message to other homeservers in the room, which in turn send those messages to the room members on that homeserver. Here is where the nuance comes into play – messages are events in Matrix, just like all other user actions.
Events in Matrix are namespaced from a global root (m for Matrix) so for example
m.room.message indicates that this event type is a message sent to a room, and all events associated with rooms would begin with
m.room.* We saw server ACLs earlier, the event type for this would be
m.room.server_acl, and so on. Users can define custom types as well, but that’s beyond the scope of this post.
Something important to note about messages is that when people make a mistake and post something they regret, or post something to the wrong room, or realize they’ve shared something sensitive they can edit the post to replace the original message with a revised one. Graphical clients like Element are going to receive the new event generated by the edit, and change what is displayed. Here is how the message is displayed in Element, a full-featured graphical client:
Text-based clients are not too popular, but for OSINT purposes they can be valuable because they’ll show the revised message as if it were a second message. You can clearly see this in action on view.matrix.org site also, where revised messages are denoted with a leading asterick::
Deleted messages work the same way. When a user sends a “delete” event, their homeserver relays that to the other homeservers in that room. They then delete the message and do not send it to any connecting clients. However, a client may or may not decide to remove any messages it already received. So, after the “delete” event is received by your client, that message will no longer be available to you. But if your client already received it, you might retain it. Not many clients do this, but the matrix-weechat plugin is one of them. You can use view.matrix.org for this also, with the usual disclaimers – provided the room is public, with previews enabled, and uses one or more aliases on matrix.org.
Messages have some valuable metadata too – timestamps. Collecting the messages sent by a user establishes a pattern of activity that can be used to guess at their timezone.
Finally, let’s discuss searching for old messages in rooms. Remember a room is not something that lives on a central server that can be searched through in its entirety. When you login to a homeserver you can search through as much of a room’s history as that homeserver has persisted in its database. How far back you can search depends on which homeserver you’re using to search. This suggests multiple user accounts may be needed for proper OSINT investigations.
I mentioned earlier that many rooms in Matrix are bridged to IRC, Discord, Telegram and other platforms. If you want to search through room history for a busy room that’s been around a while, you might not be able to using the built-in search function. You might, however, using the bridged platform. Telegram, for example, has a robust search that will allow you to retrieve messages back to when the room was first bridged.
One excellent tip I can give is to point out that AFAIK no client yet sanitizes media files. So if a user uploads photos or videos the original EXIF metadata will remain. You should download all the media files posted by your target and examine at your leisure.
Another protip I can offer is to suggest joining our OSINT room on Matrix at #osint-chat:matrix.org where we have informative discussions about OSINT. We even have an ongoing room challenge to find a non-existent user named Richard Stallman by using your SOCMINT skills.
Hopefully you’re getting some ideas about what types of investigations work best on this platform, and about how to proceed with them. There are few tools available to automate common tasks, but there are some frameworks and Matrix has a nice RESTful API as we mentioned earlier.
Finally, in the next post we discuss OSINT tools for Matrix and how to build more of them. As this platform continues to grow, we’ll need some easy to use utilities for methodically helping us reduce the time and effort needed, so stick around.