← All talks

BSides SP 2025 - Como Hackear um Banco sem Sair do seu Quarto?

BSides São Paulo38:06456 viewsPublished 2025-06Watch on YouTube ↗
About this talk
Tema: Como Hackear um Banco sem Sair do seu Quarto? Descrição: Hackear um banco é provavelmente o sonho de todo pentester. Durante um projeto com a Elytron security, eu e mais dois pentesters tivemos esse objetivo. Nesta talk temos a intenção de descrever todos os desafios envolvidos no processo, vetor de entrada, quais as medidas implementadas pelo banco para paralisar o ataque e como evadimos e evitamos novas medidas. É uma talk completa, do zero ao alcance do objetivo. Palestrante: Arthur Aires
Show transcript [en]

Good afternoon. Can you hear me? So, good... I'm very happy to be here and to present this test that we did at Elytron. I think it will be a nice experience to show you what we ended up doing. And you're getting my view right, right? Good. So this lecture, its title is "Hacking a Bank Without Leaving Your Room", right? So I think it was a pen test that we ended up doing, which was really cool. It was not conducted only by me, it was conducted by Matheus Wreck, by Gustavo Oliveira too. Here are some slides with this QR code, if you want to download the presentation. But I'll also put it at the end of the presentation,

if you want to download it. I'll give you five seconds, if you want to download the presentation. One, two, three, four. And then, that's it? Okay? That's it. At the end of the presentation I'll put it, for more time. So, writing a little bit about who I am, my name is Arthur Aires, I am a technical leader at Elytron Security, I have more than three years of experience at Elytron, I have experience with vulnerability client-side, server-side, technical leader at Elytron and invited five times by HackerOne for live hacking events, which are events in person, where we will hack several companies like PayPal, AWS, Amazon Zoom, they were also very cool experiences that I participated in by HackerOne. These were the

two colleagues who participated, so this is a honorable mention to these two colleagues, both Gustavo and Matheus, so here is this slide for them, to say that they also participated in this project with me. So the idea of ​​this slide was to divide it into scope, recognition, exploration and post-exploration, in this specific case. The scope definitions, in this case, any target of this financial institution, in the specific case that was valid, so any domain or application that this financial institution executed would be a valid target. We had a Safe Harbor and authorization of this company to be able to execute the shares, so please do not test anything without authorization. We also could not, there were the don'ts, so the service denial test could not be

done, we could not also touch any financial fund of any client, in this specific case, so they They said that, due to compliance issues, it was difficult to explain or return the money to the clients. It was harder. So, for this kind of issue, it was better not to touch the clients' funds. And the top of the top of this engagement would be to be able to return the financial information of one of the executives of the institution. In this case, part of the recognition of this project was nothing very different, nothing very amazing, right? We used several techniques that are part of recognition when you are inside a web pen test, which is this

question of look at certificates, return domains by the domain name that is inside the SSL certificate that is in the domains, so you can, using tools like Shodan, like ZoomAIA, return some domains by the domain name. Use passive enumeration tools like Subfinder or other tools that would return some subdomains that these applications had, and use Wayback Machine, which is very important, interesting and was part of this project. And he was responsible for returning sections of the application, endpoints of this application, that suggested to us, that probably it executed an application called Java Faces. So this was the API, which is very interesting, which I always use, because it works by credits, so occasionally I'm putting credits on it

for the amount of times I end up using it. So the Root XML API is very interesting for this discovery of subdomains. The tools, as I mentioned, the Subfinder, which is also a very interesting tool, when you have it all configured, with all, for example, a passive subdomain numbering tool. So when you have all the keys of all services, such as security trails or other services configured in it, you get good results during this process of recognition. And GAO, in this case, GAO is one of the tools responsible for returning data from Wayback Machine. Through GAO, we managed to return a lot of information from this financial institution. So, notice, for example, through this command

line, this urls.gao is the output of Wayback Machine, and this wc -l would be to count the number of lines that are in this file. So, for example, there were more than 90,000 entries from this financial institution. So, there was a lot of content for us to explore, and content from the past that we could use there. as a form of recognition. Looking specifically for JSF, which is a web page extension related specifically to Faces applications, with Java applications, we found some results and thought, "Wow, starting from this point, which is a large institution, a financial institution, there are JSF points, so there may be points of deserialization in Java, which receive Java objects and then can allow us to have an insecurity deserialization vulnerability."

And, as we said, when we realized RECOM and looked at these domains, looked at these URLs that contained the .jsf input, during this flow we ended up finding an application and one of the core applications of this company. One of the core applications, within one of the post and the requirment parameters, we found this Java object serialized. Who has seen this kind of vulnerability knows that when you find this, the eye shines, because, probably, starting from here, you will get a serialization vulnerability, depending on the scenario and how the core of this application is. And here, for example, this here, as we were in a black box approach, that we had no access to the code of this application, some of the, this here is even

in Hacktricks, which is a very interesting wiki that can have interesting insights for you during the pen tests. is that when you find, for example, during a pen test, this ro0 or h4sia, these points are important because they are points where there is probably a Java object serialized. So, I found within a parameter, like the one I showed earlier, I found within a parameter, this is a screenshot of the object, I found within this parameter, an "r" or "0" within a request or within the HTML that is probably sent by the application, this object will probably be deserialized by the application at some point. So here, talking a little bit specifically about serialization, so you have an idea of ​​what it

is, we have, for example, two objects. In this case, we have on the left, a car, which in theory, this car and this car structure define all the characteristics that all objects have to have, and on the object side we describe objects that belong to this class, for example, both Mercedes, BMW, Audi, belong to the car class, and at the same time are different because they have different characteristics, they are objects that contain, that are cars, but that have different characteristics because, for example, in this case, in this example, they are different brands. and the deserialization flow usually happens this way. And usually in some applications you need to have you need to have serialized objects because you want to take from one point to another point of

the application, you want to take an object and keep its state there. So you, for example, serialize an object Java, put it in your database so that it can be recovered later, for some reason, in another part of the application and you, to be able to recover that same object, that same class, that same state that you had before, you can serialize this object and have this same object that you had before. of this process of serialization. So basically, that's it, serialize, you have the string of bytes, you save it somewhere, this string of bytes you can, at any other time, serialize this string and receive, and have the object you had previously. So the

first thing you do when you find the serialized object is, "I'm going to use YoSoulSerial", YoSoulSerial is a GitHub repository that has several gadgets, several collections of gadgets public versions, which are pieces of code that are already present within the SDK or most of the Java versions, especially the old versions, because the newer versions have protections against the execution of gadgets such as collections or other famous gadgets. So you use Yoast or Serial to test and understand if this object is just a decoration on the HTML page or if this object is really being deserialized in the database. So what did we do here? We used Yoast All Serial, the RRDNS, we put the collaborator

of the Bup Suite, the collaborator of the Bup Suite is responsible, he helps you during a pen test, for example, to know if the application resolved this DNS internally or sent an HTTP request to this DNS, for example. So you use Yoast All Serial, you use the RRDNS, with a URL of a server that you have control, as a collaborator, to generate a gadget, and as the object was in base64 in the application that we were testing, you convert to base64 and send it within the request. So what we did, executed the command to return the object to be realized, put it inside the request, when we sent the object, it did not receive any

interaction. the first thing you think at this moment is: "Is this object really being deserialized?" Because it may not necessarily be being deserialized, but it can there are some protections within this application. For example, the out of band can be blocked within this server, or for example, DNS requisitions are also blocked for specific domains. So there are several scenarios that you can... Or that specific domain, and this was the case, the domain of the collaborator of the Bup Suite, which is this domain right here. was blocked within the internal network of this company. So, someone had probably already passed by here, had already tried to explore this, probably alerted the company's SOC, and, wow, I think the company understood that it was better to block

the domain of the collaborator instead of completely resolving the vulnerability. So, in this case, that we, for example, did not receive and didn't receive any DNS interaction, what can we think? What would be another gadget that we can use to see if the deserialization was really happening? And there is this gadget, which is actually the J Remote Method Invocation, which can be invoked using the J RMP Client. So this protocol is used for communication between Java applications, so it would be a way for Java applications to communicate, because it is not necessary, for example, an API in JSON, which is more legible to humans, it is not necessary an API in JSON if you need the machine to communicate, you can use this J-R-M-I. and the

JRMI can be used by the JRMP Client, which is one of the gadgets of Yoast or Sierra. So, what is this gadget going to do in reality? It will try to connect to a server that you have control, so you will set up inside the server an URL, a door, and trying to connect, you will probably notice if the application will try to connect or not. If it does not try to connect, or if the servers you are trying to connect trying to put it to connect, are blocked, you will notice a timeout in the application. So this is one of the approaches that made us realize that probably deserialization was happening, and as deserialization was happening, and I'll explain that a little later, as deserialization was

happening, because of the response time that the page had during the tests, with the normal gadget, like RLDNS, and with this specific gadget, which is the JRP Client. Here I will give a tip of an extension that I end up using when I find these serialization vulnerabilities in Java. This is a serialization that is present in the Burp Suite store. The name is Java Deserialization Scanner. In fact, I do not use the scanner of this extension because I think it ends up making a lot of noise, so it's not so interesting. I think the coolest thing is to use it because it facilitates the exploration process and sends direct acquisitions through Burp Suite. So here in This is the extension configuration part, so you can use both a Yoast

Serial, you have to set the path, so you can use both a custom Yoast Serial, and a standard Yoast Serial, and in different Java versions, because Yoast Serial doesn't work in newer versions of Java, if you don't make a gambiarra with a specific command on it. So what did we do? We generated the object again, generated it now with jrmpclient, put the puts the collaborator's URL at the time, and a door that in theory the server would try to connect, converts to base 64 and sends the request. In this case here, notice that, for example, the request sent, which is the image from behind, with the jrmpclient, it took 13 seconds to connect, we have tested this several times, to make sure there was no

interruption on the internet or, for example, interruption in connection or server. So the image below is from the RR DNS, which took less than a second for the page to be loaded, and the image behind it is from the JRMP client, taking 13 seconds for the request to be completed. So this, at least in our head, gave an indication that, poxa, the deserialization is happening, because, although we do not receive DNS request, the deserialization is happening because Java is trying to connect to our server, it is not getting it because probably the outbound of that server, of the internal network, is blocked for external servers, right? And, wow, from this point here we understood that

the deserialization was happening and that we could try to find bypass for the possible protections that were implemented there within this vulnerability, right? And here we already enter the scope of vulnerability exploration. The next steps were to try to understand if this block that we were not able to receive any external connection, it was a block only in the domain that we had control, or if other domains, for example, if we went up a collaborator of ours and went up a server in AWS, with the DNS server, we would receive the interactions. But before we went up to the server, we realized that the Interact SH servers, which is another client that you can receive Out-of-Band interactions, they were allowed

and we received the requirements, both when trying to use the JRP client or when using the DL DNS. This also confirmed, at the second moment, that we were achieving the deserialization within this application, within this application, of this company. So, we were able to be sure that it was happening in the serialization, with the proofs we already had. The next step would be, I think an interesting approach would be to use all the gadgets of Yoast or Sierra to know if they are exploitable and if we can somehow get command execution, code execution, and then command execution within this server. This is the repository of Your Soul Theory, and testing all the gadgets, none of

them worked in this case. We have a scenario of deserialization in Java, which is happening, we are sure of it, because of the tests we put together during the process. but none of the standard gadgets that exist in Yoast or Serious are functional, because probably someone has already passed through there, I imagine that, someone has already passed through there and a correction was implemented that may not be enough, because we are can not be enough to totally correct the vulnerability. And one of the ways to correct the vulnerability of deserialization in Java is when you use the locahead object input. Because what happens is that all classes, when they are deserialized, all Java classes, in

this case, especially the deserialization in Java, all classes need to be verified before they are serialized to be sure that the class you are serializing, it matches the class that exists within the server. There is a thing called version_uid that has to match between the classes. And the locahead object input serves to do this validation. For example, we can... What was probably implemented, and what we imagine was implemented as a form of correction for this case, was to check which classes were being deserialized there, and when the classes were classes that in theory allowed the execution of code, or were malicious, or were public gadgets of YoSoulSerial, the attacker ended up, the class was not deserialized correctly. but what we can do, there are some bypasses

for solutions that were created using the lookahead, which is basically what this image is talking about here, the permitted class, and we put a malicious gadget using a permitted class as a proxy, in quotes, to create a lookahead. a proxy, in this case for a malicious gadget that would allow you to execute commands within the server. And this was a gadget, this was a repository that contains several bypasses, which was even presented at the RSA, which is the serial killer bypass gadget collection, which contains, it contains, it is a Yoast Serial, but it contains new features with these specific bypasses, so that we can so we can really explore vulnerability and access gadgets that weren't allowed before. and you

can see here in the image, I think probably not because of the size, but here is running the serial killer and on top we have some additional gadgets, in addition to the standard gadgets in Yoast or Serial, and the bypasses for different scenarios. So here is a bigger image with all the bypasses for different softwares and other classes that would allow you to use, that can be used as a proxy, so that we can call malicious classes. As there were many gadgets and many bypass classes, what we did was We put a ping command, actually created a Python script for it, and here is what we did: ping, gadget class, gadget bypass, and a control domain that we had already

uploaded a domain to receive. We bought a domain, uploaded a WS machine, and configured it in a way that we could receive the DNS interactions of this domain. So every time this domain was resolved by someone, we could receive this resolution because we had a DNS server in our control. Here is the Python script that we created. There is the list of gadgets, the list of bypasses, the command that will call the serial killer, Python has some brackets that can be formatted, that the data can be inserted inside. So, the first two brackets are the gadget and the bypass that we will use, ping, gadget again, bypass and our domain that is in our control. And doing this, we created a huge list of Java objects

to be made, that we took, as we already had the control of the request and the accession, we put in the Burp Suite intruder, And, wow, this answer was wonderful, because with this answer we were sure that the ping command was executed on the server, we received these DNS interactions because the server internally performed these resolutions, and from that point on we had command execution within this critical server of this financial institution. So, from that point on, we were sure to prove that there was command execution within the server, and we were able to use the bypasses, in this case, it would be the killer to get this bypass and get access to this machine

of this financial institution. So this was a server that was hosted on the internet, it was a critical and responsible server there, responsible also for executing financial transactions, communicating internally to execute financial transactions. So here, it was a moment of victory internally, but as this was a proof of concept for this client, for us to demonstrate the value of Eletron and the company, We needed to get a little more, as mentioned at the beginning, the idea was somehow to get information from this executive, from this institution, and what we did was to go to the stages of post-exploration. So we already got the entry point, we got this initial access to the internal network of

this company, as we already got this entry point, the next steps are to continue the post-exploration process. What we realized is that, and as we were executing this pen test, SOC was in constant interaction with us. But the point that, at least the executives of Ayrton commented, was that we would not ask for any kind of permission from SOC. So, what SOC wanted to do as a measure to act and prevent us from continuing this test, SOC could do. And that's what happened, at least the domains of Interact SH, which was the first one that worked, they were blocked, they did not solve internally anymore. That's why we had to go through of Pentest to

buy new domains and upload more machines to AWS, to be able to kind of bypass the SOC protections until we actually get persistence in the application. So the Interact domains were blocked and we got to a problem that is, a ping command is simple to it does not prove much, but it proves the execution of command, but at the same time, what if I want to filter a complex command output? And this can be done with DNS, although it takes time, but you can do it with DNS, how are we going to do that? So the idea was, because the DNS resolutions generated noise internally, so imagine that you will extract a output, I don't

know, a file KB, this will generate several DNS resolutions there, and this will end up generating noise internally. So we tried to find ways to perform as few DNS resolutions as possible, also use the bash binaries that were normally used in attacks, for example, calling directly the bash using the Java application for serialization, is probably an indication for the EDR of this of this company that something is wrong, because, out of nowhere, Java, which is the app that is running, started calling Bash and calling some crazy commands, so this is an indication to EDR that something is not right, that someone is executing commands inside the server. And there was an interesting point, the EDR was configured in this machine, but

because it was a critical service, it was not configured in paranoia mode, because it is common in some cases that you can execute commands that the EDR is in paranoia mode, you send the first, second, third, in the fifth command the machine stops responding because the EDR isolated the machine. So, in this case here, the machine was not isolated because it was a critical service to the bank. And as it was a critical service, this They thought it was better not to configure the EDR in a way that this machine was cut or that this access was cut. I don't know if they changed this configuration after what happened. So the command that we used

in this specific case, just to demonstrate, but it was not only this cat, but this first part of the command before the first pipe, is an example, for example, of file reading, and we made a cat to read a file, or an ls or any other command, we made a cat to read a file, used gzip to compress this file and make it have fewer resolutions, used xd to transform this compressed output into hexadecimal and created a loop in created a loop using while in bash, so it breaks this gigantic hexadecimal generated by xxd and resolves line by line, returning to our domain, this command output. We didn't even use the ping command here, we used

the host command and use -u to perform the DNS resolutions, because imagine that probably We used the client of Interact SH, we went up to DNS resolution servers using the tools of Interact SH, and at the same time, we also modified part of this tool of Interact SH to facilitate data filtering. This profile picture of VREC is funny, so you have to be careful with hackers who have cat pictures on the GitHub profile. Let me move on to the next one. So we modified this part, part of the Interact SH client, part so that it performs all DNS resolution he receives from the DNS server we are running, this resolution will be broken by subdomains. So, notice

that we are breaking the resolution string using the point, and after this string break we will take these parts here and save the file, in this case, There are two parameters there, which will be the name of the file and the back of the content that will be given, the append, within this file of the resolution. The full command using serial killer, was Java, I already have serial killer, the class that we were using to get the gadget that we were using to execute the command, the bypass, and in Java we end up using this gambiarra to be able to call the bash, because if you use very complex commands, the correct thing would be to use those functions that you can call an array of

commands, and call each command argument within this array. But since we couldn't do that, because we didn't have control over the code, we use this gambiarra, calling sh and then bash, so that we can use a complex command like this one we're showing. So part of the command, there is no secret, is an LSLA, what I mentioned, gzip to reduce resolutions, hexadecimal, and then the example there for the domain that we were using, base64, and some URL encode corrections, because depending on the application faces, depending on the scenario you have, depending on how this Java application is receiving this object serialized, you have to configure the URL encode there, because otherwise it will not be

able to serialize the object. And here are the DNS resolutions, for example, here we are using these were screen captures of the moment of execution of the test, there are even dates of 2024, of the month of execution of the test, so there our domain is censored, but the file, for example, is sss.txt that we were adding the information there. So here is an example of how many files and how many commands we executed there, there are several moments there, of this process to get there, to get there return information from the service. So we had a problem, I'll try to speed up because the lecture time is coming, so we had a problem that

the resolutions were very slow, the SOC started to block, we imagined that the SOC was blocking execution trees. So, for example, if Java called bash, probably what was called after that, it could not be executed anymore. So we had to create some, we had to have creativity to deal with SOC. So, for example, instead of calling bash, we called KSH, SH, other bash that exist. One thing we did was, we could execute simple commands, we use the bash, the ksh and the sh to create a complex command, but a command to copy, a chmod command we could do without having to create this complex command, so we copied these executables many times, like the bash,

moved it to the time bar and gave execution, execution permission in the time bar and changed this order of execution. At least we realized that in some cases we avoided the protections that the SOC had put there, for example, Java call the bash or call others of these bashes there. And we also realized the SOC activity time, because these blockages always happened, we spent the day working, the other day the domain was blocked, the execution tree was blocked, we realized that the SOC was operating at the commercial time. So we thought, "When we really do the tests and really do what we need to do, we're doing it at the weekend, because after Friday, at

6:00 p.m., is the moment we will get to get persistence on the server and there's no longer to do these tests. DNS resolutions, because it was already getting expensive to buy a lot of domain and upload machine in AWS. So we had these next steps, which was dealing with SOC, maintaining persistence, and an interesting point, I put OCR, an interesting point was that when we had access to this machine, we realized that this machine was with NFS mounted to an internal server, which I think was used for all because there was everything in that server. There was log of transaction PIX, there was... I think that what most caught attention was the photo of tax

return statement, photo of credit card. The most interesting in this case here, which was related to the objective of this test, was to get the executive data and we found within this path inside this NFS, found a page of output, a page of output where there were the private positions of the clients, who had a lot of money in the bank, and the director was in this middle. So, the next step was to implement the web shell, to find the deployment location, we spent some time finding the deployment location of the Java application, and then we inserted a shell, manipulating some files, this was also our concern, because imagine manipulating an institution's file, which is accessed by millions of people, and you manipulate an archive and break this break

this page. And it also had to be an unauthenticated file, so we had to spend time looking for this file and looking for a file that was not so relevant and that was not so accessed. We manipulated this file, we put some headers that represent these hashes, which would be called for command execution and also another that would be responsible specifically for, if we set the path, it returned as a download of that file. And doing that, here is the bar temp, we were commenting what I said, for example, this first hash, it has an sh, we copied the sh to the barra temp, gave permission to run, and we called, for example, this case that was interesting, we called the python, which would be the

argument that would be placed inside the sh, called the python, for the python to call the bash. So we kind of kept going around like this, because the SOC was blocking us, blocking those execution trees that I commented on. So doing that, doing these gambias, we ended up dealing with the SOC, And after we put the web shell, we already had the command execution not authenticated within the service. We already had it with DNS, but now it was much simpler to get out. We could do anything in this case. As we already had all these relevant information, we already had everything important there, we already had a work point that was much easier than the DNS resolutions, which were slow, we started looking for, in this case,

within the transactions, within the PDF files, the director's data. The point was that there were so many files, so many files that we felt it was unfeasible to download file by file, especially considering the amount of PII we were downloading, and this test was already going too far. So, downloading this amount of files was perhaps offensive to the financial institution, so what we did was Here is an example of some digital captures of documents that we found inside this bank. This was inside the NFS, the image is censored. This is inside the NFS that we found. The position of income tax, these statements were all inside the bank. everything is censored, but there was sensitive information because, at least, these private clients have to send this data to the

income verification, to prove that they have money, to prove that they have an account in Switzerland. So, at least, this kind of data was already accessible, but to really prove the impact, we needed to get the data from this specific director. So we got this solution of We found this PDF solution, which was very small, an OCR solution. We used this one specifically because the solution allowed this type of output. So we could call PDF directly in the path with the solution, put this little line there, and all the content that it could pull from this PDF would come out. So, PDF example. This is important because we could catch it. It made a loop

reading the folder and all the files, put the file inside this place where is example.pdf and gave the "grep" there in the data there in the data that had the PDF, looking specifically for PDFs that had the name of this director. So here is an example of the command line that we used, this here in the case was to insert the binary into the server, so we read the binary, which used hexadecimal, could use gzip, but we converted it to hexadecimal, broke the line, and broke it into several parts, then wrote part by part, giving append inside the server of this object. Here is an example This is an example of the scripts we used to break this PDF into several pieces, to have several pieces of

it and then insert it into the service. and break the lines. Here is the intruder with the requirments, so I don't know if there is the amount of requirments here, but there were many requirments because I think it was a file of 4 megabytes more or less, and this in text, gives a lot of text, so I think there were many requirments, I don't even remember in my head, many requirments inserting part by part of this file, because we couldn't download the file directly from the internet, it was all blocked, blocked inside the server and out. So, for example, I couldn't make a curl to download to download via HTTP request this file. So, it

would be part by part of this file, put it all inside the server, set the pdf inside the BEST that we wrote, read the pdf file by pdf, until we found several clients who had the same name as this director, and also hit the full name of him, and said, "this is the pdf". We downloaded using Shell, extracted the data from this director, and then we went to present with all this complete scenario, a complete report that took us some days to write this report as a whole. I did not bring the director's data because otherwise it can be a problem, but this was the scenario, this was a very interesting scenario that we dealt

with. Here is a QR code with the presentation download, if you want to take a look at the QR code, and if you have any questions, you can bring it.

It took more than two months. It took more than two months. It was very long and very hard work. Because, telling the story, it seems like it was something simple, but no. It was something very long and hard work. And it was three people working on this pen test. Well, I want to thank Arthur here and ask everyone to go down to the floor for the draw and the closing of the website.