Thursday, April 6, 2023

This is the end - and the beginning

This post is just to inform everyone that do not expect any new blog posts here, I am moving everything to Jekyll + Github pages. 

You can find the old posts and all the new posts here:

So long Google.

Thursday, January 16, 2020

The RastaLabs experience


It was 20 November, and I was just starting to wonder what I would do during the next month. I had already left my previous job, and the new one would only start in January. Playing with PS4 all month might sound fun for some people, but I knew I would get bored quickly.

Even though I have some limited red teaming experience, I always felt that I wanted to explore the excitement of getting Domain Admin – again. I got my first DA in ˜2010 using pass-the-hash, but that was a loooong time ago, and things change quickly.
While reading the backlogs of one of the many Slack rooms, I noticed that certain chat rooms were praising RastaLabs. Looking at the lab description, I felt "this is it, this is exactly what I need." How hard could it be, I have a whole month ahead of me, surely I will finish it before Christmas. Boy, was I wrong.

The one-time fee of starting the lab is 90 GBP which includes the first month, then every additional month costs 20 GBP. I felt like I was stealing money from Rastamouse and Hackthebox... How can it be so cheap? Sometimes cheap indicates low quality, but not in this case.

My experience

Regarding my previous experience, I already took OSCP, OSCE, SLAE (Securitytube Linux Assembly Expert), and PSP (Powershell for Pentesters), all of which helped me a lot during the lab. I also had some limited red teaming experience. I had more-than-average experience with AV evasion, and I already had experience with the new post-exploit frameworks like Covenant and Powershell Empire. As for writing exploits, I knew how a buffer overflow or a format string attack worked, but I lacked practice in bypassing ASLR and NX. I basically had zero experience with Mimikatz on Windows 10. I used Mimikatz back in 2012, but probably not since. I also had a lot of knowledge on how to do X and Y, on useful tools and hot techniques, but I lacked recent experience with them. Finally, I am usually the last when it comes to speed in hacking, but I have always balanced my lack of speed with perseverance.

RastaLabs starts in 3,2,1 ...

So I paid the initial entry fee, got the VPN connection pack, connected to the lab, and got my first flag after ... 4 days. And there were 17 of them in total. This was the first time I started to worry. I did everything to keep myself on the wrong track, stupid things like assuming incorrect lab network addresses, scanning too few machines, finding the incorrect breadcrumbs via OSINT, trying to exploit a patched web service (as most OSCPers would do), etc. I was also continually struggling with the tools I was using, as I never knew whether they were buggy, or I was misusing them, or this is just not the way to get the flag. I am sure someone with luck and experience could have done this stage in 2-3 hours, but hey, I was there to gain experience.

During the lab, whenever I got stuck with the same problem for more than 30-40 hours and my frustration was running high, I pinged Rastamouse on the official RastaLabs support channel on I usually approached him like "Hi, I tried X, Y, and Z but no luck", then he replied "yeah, try Y harder". This kind of information was usually all I needed, and 2-3 hours later I was back on track again. His help was always enough, but never too much to spoil the fun. The availability and professionalism of Rastamouse was 10/10. Huge multi-billion dollar companies fail to provide good enough support, this one guy here was always there to help. Amazing. I highly recommend joining the Mattermost channel – it will help you a lot to see that you are not the only one stuck with problems. But please do not DM him or the channel if you have not already tried harder.

What's really lovely in the lab is that you can expect real-world scenarios with "RastaLabs employees" working on their computer, reading emails, browsing the web, etc. I believe it is not a spoiler here that at some point in time you have to deliver malware that evades the MS Defender AV on the machine. Yes, there is a real working Defender on the machines, and although it is a bit out of date, it might catch your default payload very quickly. As I previously mentioned, luckily I had recent experience with AV evasion, so this part was not new to me. I highly recommend setting up your own Win10 with the latest Defender updates and testing your payload on it first. If it works there, it will work in the lab. This part can be especially frustrating, because the only feedback you get from the lab is that nothing is happening, and there is no way to debug it. Test your solution locally first.

Powershell Empire turned out to be an excellent solution for me, the only functionality it lacked was Port Forwarding. But you can drop other tools to do this job efficiently.

A little help: even if you manage to deliver your payload and you have a working C&C, it does not mean your task with AV evasion is over. It is highly probable that Defender will block your post-exploit codes. To bypass this, read all the blog posts from Rastamouse about AMSI bypass. This is important.

Lateral movement

When you finally get your first shell back ...

A whole new world starts. From now on, you will spend significant time on password cracking, lateral movement, persistence, and figuring out how Windows AD works.
In the past, I played a lot of CTF, and from time to time I got the feeling "yeah, even though this challenge was fun, it was not realistic". This never happened during RastaLabs. All the challenges and solutions were 100% realistic, and as the "Ars poetica" of RastaLabs states:

...which is sooooo true. None of the tasks involve any exploit of any CVE. You need a different mindset for this lab. You need to think about misconfigurations, crackable passwords, privilege abuse, and similar issues. But I believe this lab is still harder to own than 90% of the organizations out there. The only help is that there are no blue-teamers killing our shells.

About the architecture of the lab: When connecting to the lab with VPN, you basically found yourself in a network you might label as "Internet", with your target network being behind a firewall, just as a proper corporate network should be.
There are a bunch of workstations – Win10 only, and some servers like fileserver, exchange, DC, SQL server, etc. The majority of servers are Windows Server 2016, and there is one Linux server. The two sites are adequately separated and firewalled.

As time passed, I was getting more and more flags, and I started to feel the power. Then the rollercoaster experience started. I was useless, I knew nothing. Getting the flag, I was god. One hour later, I was useless.

For example, I spent a significant amount of time trying to get GUI access to the workstations. In the end, I managed to get that, just to find out I did not achieve anything with it. For unknown reasons, none of the frameworks I tried had a working VNC, so I set up my own, and it was pain.

On December 18, I finally got Domain Admin privileges. So my estimation to "finish the lab" in one month was not that far off. Except that I was far from finishing it, as I still had to find five other flags I was missing. You might ask "you already have DA, how hard could it be to find the remaining five?". Spoiler alert, it was hard. Or to be more precise, not hard, just challenging, and time-consuming. This was also a time when connections on Mattermost RastaLabs channel helped me a lot. Hints like "flag X is on machine Y" helped me keep motivated, yet it did not spoil the fun. Without hints like this, I would not have written this post but would have been stuck with multiple flags.

About exploitation

And there was the infamous challenge, "ROP the night away." This was totally different from the other 16. I believe this image explains it all:

If you are not friends with GDB, well, you will have a hard time. If you don't have lots of hands-on experience with NX bypass - a.k.a ROP - like me, you will have a hard time with this challenge. The binary exploit challenges during OSCP and OSCE exams are nowhere near as complex as this one. If you have OSEE, you will be fine. For this challenge, I used GDB-Peda and Python pwntools – check them out in case you are not familiar with them. For me, solving this challenge took about 40 hours. Experienced CTF people could probably solve it in 4 hours or less.


I would not recommend taking this lab for total beginners *. I also do not recommend doing the lab if you only have limited time per day, which is especially true if you are working on your home computer. I probably would have saved hours or even days if I had set up a dedicated server in the cloud for this lab. The issue was that the lab workstations were rebooted every day, which meant that I always lost my shells. "Persistence FTW", you might say, but if your C&C is down when the workstation reboots, you are screwed. "Scheduled tasks FTW", you might say, but unless you have a strict schedule on when you start your computer, you will end up with a bunch of scheduled tasks just to get back the shell whenever you start your computer. Day after day I spent the first hour getting back to where I had been the day before. And I just figured out at the end of the lab why some of my scheduled tasks were not working ...

I would be really interested to see how much time I spent connected to the lab. Probably it was around 200–250 hours in total, which I believe is more than I spent on OSCP and OSCE combined. But it was totally worth it. I really feel the power now that I learned so many useful things.

But if you consider that the price of the one-month lab is 20 GBP, it is still a very cheap option to practice your skills. 
* It is totally OK to do the lab in 6 months, in case you start as a beginner. That is still just 190 GBP for the months of lab access, and you will gain a lot of experience during this time. You will probably have a hard time reaching the point when you have a working shell, but it is OK. You can find every information on Google, you just need time, patience and willingness to get there.

Anyway, it is still an option not to aim to "get all the flags". Even just by getting the first two flags, you will gain significant experience in "getting a foothold". But for me, not getting all the flags was never an option.

If you are still unconvinced, check these other blog posts:

Or see what others wrote about RastaLabs.


In case you start the lab, please, pretty please, follow the rules, and do not spoil the fun for others. Do not leave your tools around, do not keep shared drives open, do not leave FLAGs around. Leave the machine as it was. If you have to upload a file, put it in a folder others won't easily find. This is a necessary mindset when it comes to real-world red teaming. Don't forget to drop a party parrot into the chat whenever you or someone else gets a new flag. And don't forget:
OSCP has no power here. Cry harder!

I will probably keep my subscription to the lab and try new things, new post-exploit frameworks. I would like to thank @_rastamouse for this great experience, @superkojiman for the ROP challenge. Hackthebox for hosting the lab with excellent uptime.
As for @gentilkiwi and @harmj0y, these two guys probably advanced red-teaming more than everyone else combined together. pwntools from @gallopsled was also really helpful. And I will be forever grateful to Bradley from finance for his continuous support whenever I lost my shells.

Thursday, September 19, 2019

Hacktivity 2018 badge - quick start guide for beginners

You either landed on this blog post because 
  • you are a huge fan of Hacktivity
  • you bought this badge around a year ago
  • you are just interested in hacker conference badge hacking. 
or maybe all of the above. Whatever the reasons, this guide should be helpful for those who never had any real-life experience with these little gadgets. 
But first things first, here is a list what you need for hacking the badge:
  • a computer with USB port and macOS, Linux or Windows. You can use other OS as well, but this guide covers these
  • USB mini cable to connect the badge to the computer
  • the Hacktivity badge from 2018
By default, this is how your badge looks like.

Let's get started

Luckily, you don't need any soldering skills for the first steps. Just connect the USB mini port to the bottom left connector on the badge, connect the other part of the USB cable to your computer, and within some seconds you will be able to see that the lights on your badge are blinking. So far so good. 

Now, depending on which OS you use, you should choose your destiny here.


The best source of information about a new device being connected is
# dmesg

The tail of the output should look like
[267300.206966] usb 2-2.2: new full-speed USB device number 14 using uhci_hcd
[267300.326484] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001
[267300.326486] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[267300.326487] usb 2-2.2: Product: FT232R USB UART
[267300.326488] usb 2-2.2: Manufacturer: FTDI
[267300.326489] usb 2-2.2: SerialNumber: AC01U4XN
[267300.558684] usbcore: registered new interface driver usbserial_generic
[267300.558692] usbserial: USB Serial support registered for generic
[267300.639673] usbcore: registered new interface driver ftdi_sio
[267300.639684] usbserial: USB Serial support registered for FTDI USB Serial Device
[267300.639713] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected
[267300.639741] usb 2-2.2: Detected FT232RL
[267300.643235] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

Dmesg is pretty kind to us, as it even notifies us that the device is now attached to ttyUSB0. 

From now on, connecting to the device is exactly the same as it is in the macOS section, so please find the "Linux users, read it from here" section below. 


There are multiple commands you can type into Terminal to get an idea about what you are looking at. One command is:
# ioreg -p IOUSB -w0 -l

With this command, you should get output similar to this:

+-o FT232R USB UART@14100000  <class AppleUSBDevice, id 0x100005465, registered, matched, active, busy 0 (712 ms), retain 20>
    |   {
    |     "sessionID" = 71217335583342
    |     "iManufacturer" = 1
    |     "bNumConfigurations" = 1
    |     "idProduct" = 24577
    |     "bcdDevice" = 1536
    |     "Bus Power Available" = 250
    |     "USB Address" = 2
    |     "bMaxPacketSize0" = 8
    |     "iProduct" = 2
    |     "iSerialNumber" = 3
    |     "bDeviceClass" = 0
    |     "Built-In" = No
    |     "locationID" = 336592896
    |     "bDeviceSubClass" = 0
    |     "bcdUSB" = 512
    |     "USB Product Name" = "FT232R USB UART"
    |     "PortNum" = 1
    |     "non-removable" = "no"
    |     "IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
    |     "bDeviceProtocol" = 0
    |     "IOUserClientClass" = "IOUSBDeviceUserClientV2"
    |     "IOPowerManagement" = {"DevicePowerState"=0,"CurrentPowerState"=3,"CapabilityFlags"=65536,"MaxPowerState"=4,"DriverPowerState"=3}
    |     "kUSBCurrentConfiguration" = 1
    |     "Device Speed" = 1
    |     "USB Vendor Name" = "FTDI"
    |     "idVendor" = 1027
    |     "IOGeneralInterest" = "IOCommand is not serializable"
    |     "USB Serial Number" = "AC01U4XN"
    |     "IOClassNameOverride" = "IOUSBDevice"
    |   } 
The most important information you get is the USB serial number - AC01U4XN in my case.
Another way to get this information is
# system_profiler SPUSBDataType

which will give back something similar to:

          Product ID: 0x6001
          Vendor ID: 0x0403  (Future Technology Devices International Limited)
          Version: 6.00
          Serial Number: AC01U4XN
          Speed: Up to 12 Mb/sec
          Manufacturer: FTDI
          Location ID: 0x14100000 / 2
          Current Available (mA): 500
          Current Required (mA): 90
          Extra Operating Current (mA): 0

The serial number you got is the same.

What you are trying to achieve here is to connect to the device, but in order to connect to it, you have to know where the device in the /dev folder is mapped to. A quick and dirty solution is to list all devices under /dev when the device is disconnected, once when it is connected, and diff the outputs. For example, the following should do the job:

ls -lha /dev/tty* > plugged.txt
ls -lha /dev/tty* > np.txt
vimdiff plugged.txt np.txt

The result should be obvious, /dev/tty.usbserial-AC01U4XN is the new device in case macOS. In the case of Linux, it was /dev/ttyUSB0.

Linux users, read it from here. macOS users, please continue reading

Now you can use either the built-in screen command or minicom to get data out from the badge. Usually, you need three information in order to communicate with a badge. Path on /dev (you already got that), speed in baud, and the async config parameters. Either you can guess the speed or you can Google that for the specific device. Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second. I usually found 1200, 9600 and 115200 a common choice, but that is just me.
Regarding the async config parameters, the default is that 8 bits are used, there is no parity bit, and 1 stop bit is used. The short abbreviation for this is 8n1. In the next example, you will use the screen command. By default, it uses 8n1, but it is called cs8 to confuse the beginners.

If you type:
# screen /dev/tty.usbserial-AC01U4XN 9600
# screen /dev/ttyUSB0 9600
and wait for minutes and nothing happens, it is because the badge already tried to communicate via the USB port, but no-one was listening there. Disconnect the badge from the computer, connect again, and type the screen command above to connect. If you are quick enough you can see that the amber LED will stop blinking and your screen command is greeted with some interesting information. By quick enough I mean ˜90 seconds, as it takes the device 1.5 minutes to boot the OS and the CTF app.


When you connect the device to Windows, you will be greeted with a pop-up.

Just click on the popup and you will see the COM port number the device is connected to:

In this case, it is connected to COM3. So let's fire up our favorite putty.exe, select Serial, choose COM3, add speed 9600, and you are ready to go!

You might check the end of the macOS section in case you can't see anything. Timing is everything.


Welcome to the Hacktivity 2018 badge challenge!

This challenge consists of several tasks with one or more levels of
difficulty. They are all connected in some way or another to HW RE
and there's no competition, the whole purpose is to learn things.

Note: we recommend turning on local echo in your terminal!
Also, feel free to ask for hints at the Hackcenter!

Choose your destiny below:

  1. Visual HW debugging
  2. Reverse engineering
  3. RF hacking
  4. Crypto protection

Enter the number of the challenge you're interested in and press [
Excellent, now you are ready to hack this! In case you are lost in controlling the screen command, go to

I will not spoil any fun in giving out the challenge solutions here. It is still your task to find solutions for these.

But here is a catch. You can get a root shell on the device. And it is pretty straightforward. Just carefully remove the Omega shield from the badge. Now you see two jumpers; by default, these are connected together as UART1. As seen below.

But what happens if you move these jumpers to UART0? Guess what, you can get a root shell! This is what I call privilege escalation on the HW level :) But first, let's connect the Omega shield back. Also, for added fun, this new interface speaks on 115200 baud, so you should change your screen parameters to 115200. Also, the new interface has a different ID under /dev, but I am sure you can figure this out from now on.

If you connect to the device during boot time, you can see a lot of exciting debug information about the device. And after it boots, you just get a root prompt. Woohoo! 
But what can you do with this root access? Well, for starters, how about running 
# strings hello | less

From now on, you are on your own to hack this badge. Happy hacking.
Big thanks to Attila Marosi-Bauer and Hackerspace Budapest for developing this badge and the contests.

PS: In case you want to use the radio functionality of the badge, see below how you should solder the parts to it. By default, you can process slow speed radio frequency signals on GPIO19. But for higher transfer speeds, you should wire the RF module DATA OUT pin with the RX1 free together.

Wednesday, August 15, 2018

How to build a "burner device" for DEF CON in one easy step

TL;DR: Don't build a burner device. Probably this is not the risk you are looking for.


Every year before DEF CON people starts to give advice to attendees to bring "burner devices" to DEF CON. Some people also start to create long lists on how to build burner devices, especially laptops. But the deeper we look into the topic, the more confusing it gets. Why are we doing this? Why are we recommending this? Are we focusing on the right things?

What is a "burner device" used for?

For starters, the whole "burner device" concept is totally misunderstood, even within the ITSEC community. A "burner device" is used for non-attribution. You know, for example, you are a spy and you don't want the country where you live to know that you are communicating with someone else. I believe this is not the situation for most attendees at DEF CON. More info about the meaning of "burner"

Burner phone means it has a throwaway SIM card with a throwaway phone, used for one specific operation only. You don't use the "burner device" to log in to your e-mail account or to VPN to your work or home.
But let's forget this word misuse issue for a moment, and focus on the real problem.

The bad advice

The Internet is full of articles focusing on the wrong things, especially when it comes to "burner devices". Like how to build a burner laptop, without explaining why you need it or how to use it.
The problem with this approach is that people end up "burning" (lame wordplay, sorry) significant resources for building a secure "burner device". But people are not educated about how they should use these devices.

The threats

I believe the followings are some real threats which are higher when you travel:
1. The laptop getting lost or stolen.
2. The laptop getting inspected/copied at the border.

These two risks have nothing to do with DEF CON, this is true for every travel.

Some other risks which are usually mentioned when it comes to "burner devices" and DEF CON:
3. Device getting owned via physical access while in a hotel room.
4. Network traffic Man-in-the-middle attacked. Your password displayed on a Wall of Sheep. Or having fun with Shellshock with DHCP. Information leak of NTLM hashes or similar.
5. Pwning the device via some nasty things like WiFi/TCP/Bluetooth/LTE/3G/GSM stack. These are unicorn attacks.

6. Pwning your device by pwning a service on your device. Like leaving your upload.php file in the root folder you use at CTFs and Nginx is set to autostart. The author of this article cannot comment on this incident whether it happened in real life or is just an imaginary example. 

How to mitigate these risks? 

Laptop getting stolen/lost/inspected at the border?
1. Bring a cheap, empty device with you. Or set up a fake OS/fake account to log in if you really need your day-to-day laptop. This dummy account should not decrypt the real files in the real account.

Device getting owned while in a hotel room with physical access

1. Don't bring any device with you.
2. If you bring any, make it tamper-resistant. How to do that depends on your enemy, but you can start by using nail glitter and Full Disk Encryption. Tools like Do Not Disturb help. It also helps if your OS supports suspending DMA devices before the user logs in.
3. If you can't make the device tamper-resistant, use a device that has a good defense against physical attackers, like iOS.
4. Probably you are not that important anyway that anyone will spend time and resources on you. If they do, probably you will only make your life miserable with all the hardening, but still, get pwned.

Network traffic Man-in-the-middle attacked

1. Don't bring any device with you.
2. Use services that are protected against MiTM. Like TLS.
3. Update your OS to the latest and greatest versions. Not everyone at DEF CON has a 0dayz worth of 100K USD, and even the ones who have won't waste it on you. 
4. Use fail-safe VPN. Unfortunately, not many people talk about this or have proper solutions for the most popular operating systems.
5. For specific attacks like Responder, disable LLMNR, NBT-NS, WPAD, and IPv6 and use a non-work account on the machine. If you don't have the privileges to do so on your machine, you probably should not bring this device with you. Or ask your local IT to disable these services and set up a new account for you.

Pwning the device via some nasty thing like WiFi/TCP/Bluetooth/LTE/3G/GSM stack

1. Don't bring any device with you.
2. If you bring any, do not use this device to log in to work, personal email, social media, etc.
3. Don't worry, these things don't happen very often. 

Pwning your device by pwning a service on your device

Just set up a firewall profile where all services are hidden from the outside. You rarely need any service accessible on your device at a hacker conference.


If you are still so afraid to go there, just don't go there. Watch the talks at home. But how is the hotel WiFi at a random place different from a hacker conference? Turns out, it is not much different, so you better spend time and resources on hardening your daily work devices for 365 days, instead of building a "burner device".

You probably need a "burner device" if you are a spy for a foreign government. Or you are the head of a criminal organization. Otherwise, you don't need a burner device. Maybe you need to bring a cheap replacement device.

Saturday, July 21, 2018

Recovering data from an old encrypted Time Machine backup

Recovering data from a backup should be an easy thing to do. At least this is what you expect. Yesterday I had a problem which should have been easy to solve, but it was not. I hope this blog post can help others who face the same problem.

The problem

1. I had an encrypted Time Machine backup which was not used for months
2. This backup was not on an official Apple Time Capsule or on a USB HDD, but on a WD MyCloud NAS
3. I needed files from this backup
4. After running out of time I only had SSH access to the macOS, no GUI

The struggle

By default, Time Machine is one of the best and easiest backup solution I have seen. As long as you stick to the default use case, where you have one active backup disk, life is pink and happy. But this was not my case.

As always, I started to Google what shall I do. One of the first options recommended that I add the backup disk to Time Machine, and it will automagically show the backup snapshots from the old backup. Instead of this, it did not show the old snapshots but started to create a new backup. Panic button has been pressed, backup canceled, back to Google.

Other tutorials recommend to click on the Time Machine icon and pressing alt (Option) key, where I can choose "Browse other backup disks". But this did not list the old Time Machine backup. It did list the backup when selecting disks in Time Machine preferences, but I already tried and failed that way.

YAT (yet another tutorial) recommended to SSH into the NAS, and browse the backup disk, as it is just a simple directory where I can see all the files. But all the files inside where just a bunch of nonsense, no real directory structure.

YAT (yet another tutorial) recommended that I can just easily browse the content of the backup from the Finder by double-clicking on the sparse bundle file. After clicking on it, I can see the disk image on the left part of the Finder, attached as a new disk.
Well, this is true, but because of some bug, when you connect to the Time Capsule, you don't see the sparse bundle file. And I got inconsistent results, for the WD NAS, double-clicking on the sparse bundle did nothing. For the Time Capsule, it did work.
At this point, I had to leave the location where the backup was present, and I only had remote SSH access. You know, if you can't solve a problem, let's complicate things by restrict yourself in solutions.

Finally, I tried to check out some data forensics blogs, and besides some expensive tools, I could find the solution.

The solution

Finally, a blog post provided the real solution - hdiutil.
The best part of hdiutil is that you can provide the read-only flag to it. This can be very awesome when it comes to forensics acquisition.

To mount any NAS via SMB:
mount_smbfs afp://<username>@<NAS_IP>/<Share_for_backup> /<mountpoint>

To mount a Time Capsule share via AFP:
mount_afp afp://any_username:password@<Time_Capsule_IP>/<Share_for_backup> /<mountpoint>

And finally this command should do the job:
hdiutil attach test.sparsebundle -readonly

It is nice that you can provide read-only parameter.

If the backup was encrypted and you don't want to provide the password in a password prompt, use the following:
printf '%s' 'CorrectHorseBatteryStaple' | hdiutil attach test.sparsebundle -stdinpass -readonly

Note: if you receive the error "resource temporarily unavailable", probably another machine is backing up to the device

And now, you can find your backup disk under /Volumes. Happy restoring!

Probably it would have been quicker to either enable the remote GUI, or to physically travel to the system and login locally, but that would spoil the fun.