[MUSIC]
 Okay, so our next speakers will be Kartorka, Linus and Domitri.
 And they are going to be talking about disclosure, hack and back, how to mess things up in various
 ways.
 Please give a big applause to our speakers.
 [APPLAUSE]
 Yeah, thanks a lot for coming.
 We basically thought we want to talk a little bit about the adventures we've had in the
 past year with a specific focus on the past half year in incident response, in handling
 incidents, causing incidents by disclosure.
 And we basically talk about our disclosure adventures first.
 So many of you may know that the CCC regularly discloses vulnerabilities to companies.
 We also have an email address where we help people doing so.
 That email address will play a role in a bit here.
 So Kartorka, my good friend, reported a lot of incidents in bulk.
 Basically he had like this spreadsheet to keep track of all the disclosures and we had
 to look into it together and make sure that which state is it in and do you have everything.
 And eventually we only made it a small blog post of 6.4 million data records in over 50
 leaks that we disclosed to those companies.
 Now you would think that's a process you could scale, right?
 You build a spreadsheet, say like have we sent the email?
 Have we received the response?
 Is it fixed?
 But once this is at 50 and you're dealing with 50 different organizations, it gets a
 bit more complicated.
 Still disclosure is a simple process in theory, right?
 You find a vulnerability, you tell the people that are responsible for the vulnerability,
 they fix it.
 If you look at this in terms of like a call flow, you do the research, report it to the
 company, just in case they forget to alert the cert or the data protection officer, you
 just do it for them as well, right?
 They usually send you an act, then they perform their duties and notify the DPA, they fix the
 issue and they send you like a little thank you note and they notify the customers.
 You can of course imagine which parts they sometimes like to forget about, so maybe we
 then do a little publication to take care of the customer notification for them on top
 of that.
 So now with 50 of these in the past years or in the past year, Cantorca has a lot of
 little adventures to talk about and please give them a big round of applause.
 So, yeah, let's start with one of the cases that went quite well, I would say.
 So there was this Spanish media company that owns, for example, the daily newspaper, Alpais,
 and they had a problem that many companies had before, they forgot about this .git folder
 which has a config file and here this config file included credentials for the GitLab.
 That was a very simple cause with a large effect because in this account I had access
 to 478 projects, which was, I don't know, probably all GitLab projects of this company,
 including some infrastructure as a code stuff.
 So yeah, we had a vulnerability and then we tried to report it and that was quite hard
 in the beginning.
 I reported an elastic search that leaked a couple of months before to the same company,
 they never replied.
 This time this issue was more severe, so I tried different channels.
 So first of course I wrote this email to the company but I also notified the search but
 still there was no response.
 So I checked for people working at this company in the IT security department on LinkedIn.
 LinkedIn is great.
 Most of my LinkedIn friends had IT security issues.
 But this time we used Facebook to reach out to someone who was in IT security and finally
 we managed to get this leak fixed.
 They thanked me, so until then this process was perfect, more or less, and then they asked
 for a call.
 I sometimes say, yeah, okay, why not?
 Because those people were quite friendly.
 I told them when I would be available and then they were quiet.
 So in the end there was a little drop in the performance but it was okay.
 Something different, the United Nations HCR, they are not responsible and they do not care
 when it comes to data of other people.
 So there is this services advisor for different countries, for example for Iraq, and it tells
 information for refugees that need help in those countries.
 This service advisor leaked accounts of about 900 employees of, I don't know, dozens of
 aid organizations that are active in different parts of this country.
 And this time it was very interesting because the United Nations have a search.
 So there is a place where I can go to report issues.
 As I said, they are not the responsible entity for this because the UNHCR is different, they
 are not covered by the search.
 Later I received a thank you for submitting this issue but the vulnerability was not fixed.
 So I needed to reach out to them again and again until even the last Gmail account, it
 was in fact deleted.
 I don't know.
 They deleted some data and then the vulnerability couldn't be abused anymore.
 Also they did not forget to mention the United Nations Hall of Fame program because as some
 other entities as well they have a Hall of Fame where people are mentioned after successfully
 reporting an IT security issue but here they only mentioned that the UNHCR does not fall
 under the Hall of Fame program.
 Maybe next time.
 Let's switch to IT security made in Germany.
 Let's switch to IT security made in Germany.
 The TÜV Nord, they even certify you when you are secure.
 As other companies before they had this issue with .env and .git folders or files happens.
 But they chose to ignore the report.
 So I needed to reach out to them, I think via phone.
 They ignored the email.
 We had some discussions.
 Then they told me this is not our IP space.
 We do not use the software anymore.
 It's not important to us.
 We cannot do nothing.
 However it's IP space of the TÜV Nord.
 They still decided to not fix this issue and I did this morning and yeah if you like go
 and check for data leaks in the TÜV Nord domain space.
 You will find database credentials and source code.
 You will find Google service account that can still access some services.
 The database is not directly accessible but they made it easy.
 There is Adminer and PHP admin to allow access to databases.
 There you will find hash passwords of TÜV Nord.com accounts.
 I told them about this issue but they said they have changed passwords.
 That's not a problem.
 There was another interesting disclosure in December last year.
 The US military was using those devices that you can see on the slide here.
 They used it to check people in Afghanistan and Iraq against watch lists.
 They wanted to catch terrorists I guess.
 We found those devices on eBay and in one of those devices there was a biometric database
 of about 2.5 thousand people.
 We had up to ten fingerprints per person, iris scans and a photo from the face.
 Then there were details like name, height, sometimes weight, eye color, whatever.
 Now half a year later, a couple of weeks ago, they finally reached out to us.
 Hello, this is agent Smith.
 We would like to have our devices back.
 Also they like to meet.
 They would even come to my hometown.
 And they have questions.
 Hello agent Smith.
 I don't know if you are listening today.
 I received your email about ten days before camp.
 I was quite busy because of camp.
 We will mention to reply soon.
 In the meantime, if you would like to have such a device, they are still on eBay.
 However, it could be that some people will visit you if you do so or the next time you
 travel to the US, it might be challenging to enter the country.
 Small fun fact, I also learned by the US National Archives and Records Administration that I'm
 finally owner of the Chaos Computer Club.
 For every single data leak, this organization has a record and I asked for the record because
 they have freedom of information laws over there as well.
 They did not reply yet, but I'm really looking forward to read those documents that are somewhere.
 That's it about the US Department of Defense.
 We will come to one last very interesting shoe shop on the internet.
 We are introducing the Crypto King, Philipp Plein.
 Crypto King is a name this person shows himself.
 He is the Crypto King and in this shoe shop you can buy shiny shoes.
 They are a bit expensive, but they are shiny.
 You can pay with Dogecoin or 24 different cryptocurrencies.
 They have even Crypto King and Crypto Queen watches.
 The future is now.
 From a technical perspective, this issue was quite boring again.
 We found a leak somewhere and there was this FTP server.
 First mistake, storing customers' data on the FTP server.
 Then they lost credentials to the server, to us and to everyone else on the internet.
 Then they were ignoring all vulnerability reports and this time we were creative.
 We reached out to the SERT in Switzerland because this company is based in Lugano, a very nice
 city.
 We reached out to two DPAs because they have stores in the offline world as well, including
 Berlin Kurfürstendamm.
 Also I reached out to the Berlin DPA as well as to the Swiss DPA.
 I called the hotline.
 I reached out to some people via LinkedIn, including the, I don't know, not the CEO,
 but the CIO possibly.
 They ignored us.
 However, we decided not to travel to Lugano and we also did not send a fax.
 I was checking from time to time if this vulnerability was eventually fixed after, I don't know,
 two years maybe or one and a half year.
 The server vanished from the internet.
 So this FTP server is just not available anymore, at least not under this IP address.
 So if you bought something offline or online at this shop, it might be that someone else
 has this information as well.
 And I...
 To sum up this first part of the presentation, some lessons learned.
 So finding bugs is still easy.
 There are lots of very simple data leaks.
 It's boring to look into those data leaks from a technical perspective, but it becomes
 quite interesting if you check for the different behaviors companies have when you approach
 them about a data leak.
 So reporting bugs is the actually interesting thing here.
 And sometimes you find very motivated people that are very happy that you approach them.
 And that's really nice to work with those people to make them understand what happened,
 why that happened, and how to prevent this mistake in the future.
 For companies that could have such issues, please assume good intentions when people
 approach you.
 They want to help.
 Sometimes by accident they do a MySQL dump and not just a select count of rows or something
 like that.
 Please be prepared.
 So make it easy for us to approach you and have a plan what happens afterwards when we
 approach you.
 And please keep us in the loop and also give some kind of acknowledgement because it happens
 quite often that a company reads your email, fixes the issue, but never says thank you.
 Two or three hours ago there was this talk by Lilith on the same stage here.
 Doing such stuff is very interesting from a direct action activist experience as well
 because companies fail to inform effective people quite often.
 Public disclosure is needed.
 However, when doing IT security research, at least in Germany, there's always this hacker
 paragraph behind you that might hurt you.
 So yeah, they suck.
 Please remove them.
 Sometimes the responsible disclosure way is not the best way if you want to maximise impact,
 but it's not always the most effective way to change things.
 And sometimes shitposting is fun if companies do mistakes.
 There are lots of golden opportunities.
 So that was our short dive into a couple of funny stories from vulnerability reporting
 and disclosure.
 Now the second part of this talk is what we call attacker infrastructure exploration.
 So we got to know a little ransomware gang, initial access broker, and we were actually
 surprised how they mess up.
 And of course, to those guys, you don't disclose, you just hand in a talk at camp.
 So welcome to our talk.
 In Soviet Russia, incident response hacks you.
 So it all started with an email that went like this.
 DCCC, no spam, no joke.
 My employer was hacked.
 I was on the blue team.
 The hacker was mediocre, left a few traces.
 We were able to monitor him a bit.
 No data was stolen from us.
 The attacker attempted cableroasting to take over my beloved domain controller.
 I found an SSH key and IP and looked it up.
 Links to smart cards and labs could be prevented.
 So they not only survived the incident without much compromise, they also had this little
 SSH key that they were so friendly to share with us.
 Now with this SSH key in my hand, I thought, oh, well, let's call Matthias and Dominic
 and see what we can do with this little SSH key.
 And I think Dominic will tell you all about it.
 Yeah, so this was a pretty interesting opportunity, not finding vulnerabilities in the infrastructure
 of like regular organizations, but rather in some special organizations.
 So we asked around and we found our friend HackerMan here who wanted to look into this
 further.
 So HackerMan did a bit of lauter.
 All right, can you turn the volume up?
 HackerMan looked at what happened and we already knew from the first email, okay, the attackers
 compromised the victim.
 And what they did there, they created a scheduled task for persistence.
 They dropped two binaries, Tor and SSH, and they had an SSH private key.
 Now with this scheduled task, which was quite obfuscated, the Tor invocation, the SSH invocation
 was hidden amongst a lot of different commands to make it harder to spot.
 But in the end, we had a reverse shell connecting back to the attacker infrastructure.
 On the attacker infrastructure, you could find data not only from one victim, but from a
 lot of victims.
 There were plenty of SSH keys, and then you find the usual stuff from AD compromises,
 so from Windows environment compromises.
 You find Kerberos tickets, Kerberos information, you find complete Active Directory dumps,
 you find LSST dumps, and you find the tooling that the group uses to do their exploitation.
 Now our friend HackBackMan, of course, first made a backup of all that information just
 so that it doesn't get lost, right?
 Server safe and sorry, so make a backup first, and then see what you can do with it.
 Now interestingly, the first reverse shell worked with a low privilege user, which connects
 to the server A. HackBackMan did a bit of poking around and realized the same SSH key
 could also be used to connect to the server as root.
 So it's not only the victims that fuck up their configurations, also the ransomware
 crews, right?
 They also make mistakes.
 Server hardening is hard, and sometimes mistakes happen.
 So with root access, of course, there was a lot more exploration that could be done,
 but first HackBackMan asked us, hey, don't you want to help me in the notification process
 because that's a lot of work, as you have heard from Gunn Toggle here, so of course
 we stepped in and helped out and notified 30 victims that they've been breached.
 Now if you ever wondered what does a C2 server of some initial access broker ransomware crew
 game look like, it looks like this.
 This is the root folder, so obviously the crew was also working as root, and they dropped
 everything there, right?
 They dropped all the data dumps in there, they had all of their scripts in there, they
 cloned git repositories, they had some automation tools, bash scripts, everything in the root
 folder.
 So this looks like the home folder of a very unorganized penetration tester right there.
 The crew wasn't really sophisticated, right?
 I mean, they used a lot of open source tools.
 You can see a list of tools that was found on the server on the right side.
 Many things if you're working in red teaming or penetration testing you might also have
 used.
 They also used the same tactics that a lot of the red teams use.
 I mean, it makes sense, red teams want to emulate real attackers after all, so apparently that
 seems to be working in this case.
 They tried to stay away from the victim boxes as much as possible, tried to do a lot of
 work over SOX proxies or over VPN connections if they managed to gain VPN access, and then
 did exploration of the victim networks.
 In the bash history, of course we also have a backup of the bash history, you could see
 also not only how they exploit the vulnerabilities but also how they find the victims.
 Of course they use showdown and they have a list of commands they use to find new victims
 to attack.
 Some more side information, so apparently sometimes keyboard layouts are also hard and
 if you forget to switch from Korylick keyboard layout to a US layout then you might type
 in the wrong command, that can be discovered in the bash history as well.
 Also not only victims leak API keys in the bash history, you sometimes also find API
 keys, so we now have a nice showdown API key from this initial access broker.
 Of course we don't use this, we just have it as a backup.
 So one thought we had while looking over this is, okay, they probably not only have one
 C2 server, they probably have multiple, maybe they just clone the machine and reuse the
 same configuration everywhere, maybe we can just scan the internet and find the same SSH
 host key to find more servers, but they did after all use individual keys per server,
 so that didn't work out in the end.
 So back to the disclosure, this is a disclosure talk, we had to notify 30 victims.
 Now what you want, if you have a security, it just happens, ideally you want to detect
 it yourself, you have some infrastructure in place, maybe a SIEM, maybe a SOC, who knows,
 you want to evict the attacker and ideally you want to do it before you need to disclose
 to people that you lost all their data before you need to involve law enforcement or whatever.
 What you don't want to happen is for CCC to call you and tell you, hey, we realise you
 have a breach.
 But that's exactly what happened.
 So we tried to figure out who to contact, which wasn't always easy, I mean, we had a
 lot of AD dumps, but it's not necessarily always straightforward to figure out which
 AD dump belongs to which organisation, and then the next dump, the next step is even
 more hard, figuring out who to contact in that organisation.
 Fortunately, we have someone on our side who has a lot of experience with disclosing stuff
 to people, we could reuse the same tactics, so I'm not going to repeat the flowchart,
 but it's basically the same thing.
 We mostly try to contact security staff or IT staff in general, but sometimes we also
 reach out to the company CEOs.
 We always try to go via email first, we provided information about the breach and a list of
 indicators of compromise so that the companies could take action.
 Overall, we contacted 28 organisations, and in addition, we also gave the data on... did
 we give the data?
 No, we also just informed the BSI and the German authorities and the national search
 groups from the countries where we could figure them out.
 Some of the organisations actually responded really quickly, I think the fastest one wrote
 you an email two hours after we sent out the initial email, they were super grateful, they
 weren't aware of the breach and thanked the CCC, told us how great they find this and
 promised to donate money, I don't know if that happened in the end.
 And we tried to get in a bit of an information exchange for them, so to ask them, hey, if
 you find other stuff in your network, particularly if you find new IP addresses or new SSH keys,
 we would be very interested in that.
 Now if you compare the reaction from this incident response disclosure to the vulnerability
 disclosure, it was pretty similar.
 We had a couple of companies that really had the incident under control, they were already
 aware, they already evicted the attackers themselves, we had a couple of organisations
 which were grateful, which had more questions and wanted our advice, and then we had a lot
 of organisations who didn't respond at all at first.
 So apparently companies are not only not interested in vulnerabilities, they are also not interested
 in them being breached apparently.
 This felt a little bit demotivating at first, but of course we are also persistent, it's
 not only the attackers that are persistent, so we tried to reach out via different means,
 and you already know Mattias Kantorker's favourite way to reach out is via LinkedIn, so Kantorker
 now has a lot more LinkedIn friends and some organisations have more information about
 data they might have lost.
 The organisations that reacted well, one stood out, they already had seen the attacker and
 had already evicted them, Kantorker provided them with a list of accounts where we knew
 that the attackers at least had the cabros hashes of these accounts, they checked it
 and said okay we already have discovered, we changed almost all of them already, and
 unfortunately they also figured out where the scans came from, and they figured out new
 IP addresses that the attackers were using and gave us an additional SSH key which was
 really nice of them and we thank you very much.
 So this is now victim two where we got an additional IP address and an additional SSH
 key, so that's server B, server B was configured in a different manner, Hackbackman unfortunately
 could not log into that server, the lock in shell was set to bin four so Hackbackman couldn't
 get a shell on this server, but what he discovered is he could do port forwarding, and this was
 a way of course he could first try to port scan the server and see what local ports are
 open on that server, and he discovered this way he could have tunnels to the victim's
 networks where there were active connections going on.
 There was also a very handy server running, a service running on that server, on port
 80 of localhost we had a web server which just gave the output of LSOF so we could see
 which ports were open.
 Now if you look carefully, you see some SSH connections which are the reverse shell that
 are still active, you can also see a pattern of the other open ports, they have 11109,
 11102, 11105, and then you have a different set of ports all ending in 0902 and 05.
 That's quite curious, and of course if Hackbackman discovers such a thing he wants to probe this
 further and he wants to do a bit more enumeration.
 Turns out these three ports are always forwarded to the victim networks, it's one RDP port,
 it's one SSH port that's forwarded, and the other one, did we ever figure that out, was
 it SMB, it was SMB, right?
 So three interesting ports, and if you poke at these ports you can figure out who they
 belong to, and that of course helps us in the disclosure process even if we cannot download
 files from this server or get a shell on that server.
 So we could notify more victims, I think overall in the end we notified about 50 organisations
 that they had an issue, not all of them responded to us.
 Some of them asked us what are we supposed to do, in general what you're supposed to
 do is run incident response, and even though incident response always comes unexpected,
 it's something that you can prepare for.
 If I understand correctly, after this talk there will be an incident response talk here,
 so maybe you should stick around and figure out how this stuff works in detail.
 Now we do have enough time for the bonus material which is not related to this, let's say, C2
 fuck up here, but some other cases that we worked in the past.
 Nowadays the ransomware crews have two ways to monetise their access, the first way is
 the classic way, they encrypt your network and then they demand ransom so that you can
 get a decryption key and get back running, and the other way is they start to exfiltrate
 your data and threaten you to publish it if you don't pay up.
 And even though the internet in Germany is quite shitty, they manage to exfiltrate more
 and more data nowadays, so we had some contacts with organisations, the first one lost 40
 GB of data, the second one lost a third terabyte of data, and then we had a third one that
 lost even more.
 So good news, internet speed in Germany is getting better, attackers are now able to
 exfiltrate terabytes of data in a short amount of time.
 But is that really that much of a problem?
 Of course it's a problem if you lose terabytes of your data, but if it gets published, does
 anyone really, is anyone really able to download it all?
 And Torkl spent a week trying to download one of the dumps, of course this was published
 over Tor, and they had their own web server which hosted this stuff, it's one of these
 classic ransomware disclosure blocks, but somehow they messed up their infrastructure
 there as well.
 Their HTTP server didn't support range requests and they gave the wrong HTTP codes.
 And of course also the infrastructure was unstable, so downloads tended to end at some
 point in time.
 We tried to use a tool, a two-onion downloader, which in theory is great to do this stuff,
 but nevertheless with this set up we did not manage to download all of the data and stopped
 after, we only had 20% after one week.
 So this is actually a tactic of the attackers, right?
 They want your money, and this is why they steal your data, they're not really interested
 in your data, they're interested in pressuring you into paying them, and the same of course
 goes into pressuring you to pay them to take it back offline.
 Now what lessons can we learn from this experience?
 Of course real world defenders have a lot of problems in them having to defend a big
 infrastructure which has grown over a long amount of time.
 Mistakes happen and they tend to compound, so over time your security posture typically
 deteriorates.
 But as Korn Togler also pointed out, you often have lonesome heroes in IT who keep it all
 running and who give really all their heart to maintaining it and keeping it as secure
 as best as they can.
 Still it often feels like the cards are stacked against the defenders, but as you can see
 the attackers have similar problems when they maintain their own infrastructure, right?
 They also have a growing C2 infrastructure, maintaining that is difficult, configuration
 mistakes can happen.
 Credential management is hard, right?
 Sometimes you lose the SSH key and then people have access to your set up.
 And there's plenty of rooms for FAPGAP, it's not only C2 infrastructure, it's also the
 way you publish the data and it might also be the way you do encryption if you manage
 to encrypt the data, but that's a story for a different talk, we might tell that at Congress
 maybe.
 Now if you want to be a real world hack back man, you see there's a lot of angles that
 you can attack when you're looking at the C2 infrastructure.
 Ransomware crews obviously also have staffing problems, not all of their staff is competent
 and some of them don't really know what they're doing.
 They tend to be one trick ponies, right?
 You saw the list of tools, none of this is hard to defend against, none of this is custom,
 it is known how to prevent all of these mistakes, so don't despair, it is possible to defend
 against these attackers in many cases.
 Helping ransomware victims of course also is a lot of work, especially when you want
 to get in touch with them, but it can be really rewarding if you manage to help them and if
 you manage to help them actively evict the attackers.
 With that being said, if you want to disclose either vulnerabilities or give SSH keys to
 the CCC, there's an email address here that you can use for that and we encourage you
 all to do so.
 Thanks a lot.
 [Applause]
 [Applause]
 Any questions or SSH keys that you would have for us?
 No questions, great talk.
 Or the talk sucked, I don't know.
 I don't know.
 We'll see that.
 I don't, so you're raising your hand.
 No.
 Oh.
 I thought the microphone was...
 I don't see the microphone.
 So do I get it right to protect against data leaks?
 A good strategy is to just leak more data so you can download it?
 So the question was if the way to defend against data leaks is just to leak more data so that
 it gets lost in the sea of data?
 I mean, have you seen these ransomware blogs?
 There's so much data out there.
 It's hard to download, but there is a ton.
 So if I understand correctly, you have to walk towards the microphone if you want to
 ask a question.
 There are no questions, so we can...
 No, no, there is one.
 So do you think for a company it might be a good idea to DDoS the leak platform instead
 of paying the ransomware?
 I think the Tor network would not appreciate DDoS over Tor, but Katalka can say something
 about that.
 I run Tor exit nodes.
 I would not like that.
 [laughter]
 [music]