Transcript for "Ask Me Anything: ByBit's attack & the urgent need for nation state level security": Okay. Good morning, good afternoon, good evening, folks. We'll give it, just a few seconds for folks to join, and then we'll go ahead and get started. Definitely seeing folks come in, which is awesome. Alright. Okay. Why don't we go ahead and just, kick things off? So, good morning, good afternoon, good evening, everyone. My name is Chris Jamieson, director of global programs here at Fireblocks. Thank you so much for the time today. We have a really great, session of content here for you with Shahar Madar, who's our VP of security product here at Fireblocks. Obviously, talking through the, the recent Bybit incident and giving our point of view as well as how we think Fireblocks can actually help, prevent and mitigate, incidents like this moving forward. Couple of quick housekeeping items before we, before we officially kinda kick off, and I hand it over to Shahar. Number one, this is being recorded. Everyone that is registered will receive a, copy of the, session itself, hopefully, pretty shortly afterwards. Number two, please, like, we wanna make this pretty interactive. Shahar has some content that he's gonna go through, but then we'd love to, you know, keep you know, make this, like, pretty interactive from a q and a standpoint. There is a q and a, button. Please feel free to drop questions in there. Hopefully, we can get to everything. If not, we'll definitely try to follow-up with you afterwards to answer any other questions that you might have. There's also, some really great documentation and content, related, to this incident as well as some other things that we've published recently, in the docs section. Please feel free to check that out. And, for anyone that's also interested in learning any more about Fireblocks or the platform or how we do things or approach things, please, there's a request demo button up there. Feel free to to click that. I'll also put something in the chat here as well in a minute. But we'd, we'd obviously love to continue the conversation and move things forward. So, with that, Shahar, I will hand it over to you. And, again, thank you everyone for coming. Alright. Thank you, Chris. Thank you, everyone. I'm gonna share my screen real quick, and I'm gonna hit it off. So we've been getting ever since, the, attack, where Bybit lost a billion and a half dollars last week, we've been getting a lot of incoming questions. As a leader security leader in the space, doing digital asset management, People are asking us both, is Firebox safe? But also, what we should be thinking about this incident? How does it impact this the space? And also simply, what the hell happened? So we we've gotta hear everything for you, and I'm gonna dive deeper into that starting with a level set introduction, diving into what happened in the Bybit attack and the flaws that led to it, then what can you do differently in order to avoid it. And we're gonna be allocating roughly half the time, for an ask me anything for an AMA. So, you have time to ask questions, and we, hopefully, can cover, to get to all the questions. Quickly introducing myself, Shahar. I'm leading security at Fireblocks from the product side. Essentially, meaning my job is to make sure our customers are safe against threat actors when they're using a platform. I've been doing tech and security for roughly the the past twenty years. Former director of security research, at the Israeli military intelligence, and, been doing everything from security research, cyber threat intelligence, product and engineering. I'm also a founding board member, for nonprofit organizations across the ecosystem to improve the security of the space, from the CRYP to ISAC, pushing for threat intelligence and sharing, to the Blockchain Security Standards Council. So I'm very active in the space in making sure, we're doing better as, as an industry. Now let's start to dive into, what happened at Bybit. And we're gonna start with the setup. The setup is honestly a pretty common setup, cold wallet, a multisig wallet by Nasi Safe, and combination of ledger devices. So the thought process of setting up something like this is pretty straightforward. You start in saying, how can I secure my keys? I heard this is the most important thing with crypto security. So I'm saying, it's a hardware wallet. I'm gonna have a hardware wallet with me. Now I don't want I don't wanna rely on a single person because I don't wanna have a single point of compromise, a single point of failure. I wanna make sure we have more people involved in the decision making. So we'll have a Moliseq. And what's one of the go to solutions for Moliseq? That's the safe smart contract wallet. Now the reason I'm highlighting like this, it's a common architecture. We're gonna show the flaws in it in a second. And I'm highlighting the commonality of this because, we're gonna be be saying the word Bybit a lot. We do not wanna put the spotlight on Bybit. Obviously, they lost, a lot of money. But the team over there is highly experienced team, and they followed something that's commonly adopted in the market. And they have been managing, by the way, the incident ever since it happened amazingly with amazing transparency, releasing information and forensic data, which we'll cover soon in a second. So going back to the setup, we have three ledgers required, for any transaction to control the cold wallets. Now the standard operating procedure is you you have a billion and a half dollars on the cold wallet. And every now and then, based on on chain analysis here, we can see that it happened roughly every few weeks, load up money, load up funds from the cold wallet to the hot wallet in order to keep it, operation. Now this sets a pattern which we'll touch in a second. Being, a smart contract wallet, every transaction that is powered by Safe Wallet, is a contra call. So you have to invoke this, specific function called exec transaction, execute transaction, even when you're doing a a transfer of native currency like ETH, like happened here. You can see here the declaration of the function with two, and value, who you're transferring the funds to, and how much, how much funds, how much money you're sending to them, and also extra parameters like data and operation in case you're interacting with other contracts, and finally, some, information and data about the gas, you're gonna be paying. So and then the attack happened. Leading up to the attack, there were two flaws, and we're gonna be touching both of them. The first one is a compromise of a developer machine at safe. What happened is a developer machine got compromised, exploited by the Lazarus Group, the North Korean, threat actor. In leveraging that access, they managed to get to the production system of SAFE. They then modified the code that's running in production, controlling the whole SAFE wallet interface. Now you can see here, a screenshot from a forensic report, provided by Signia, and a closed incident response partner of Fireblocks that's been conducting and leading the investigation at the Bybit network. And you can see that one of the things they they they found and highlighted is what this JavaScript code, malicious code, was doing. And what it did is manipulate the transaction behind the scene and doing this in a highly targeted way. So the code was waiting for a transaction from a specific wallet, from Bybit's wallet. And once it saw a transaction that is originating from that wallet, it modified it it modified its content, making it act against Bybit, essentially. And, again, they know it's gonna happen because they know, from on chain investigation, they see the wallet is is act. So, essentially, you see a compromise at safe, modifying the code using the developer access, and then that code propagating to all safe customers at the same time, but the code is looking for one wallet. It's looking for the Bybit wallet. It's waiting for it to create a transaction and then intervene and change it. How did they get the access to that development machine? So while it surprises some people, this is actually something that is pretty common. The bread and butter of how North Korean work and how they get access to companies, crypto companies, and anything else is is by compromising, engineers. The most common factor, which is what we assess also happened here, is via fake recruiting campaigns. Fake recruiting campaigns are when they set up a a malicious entity on LinkedIn or other platforms and reach out proactively to, engineers in crypto companies. They will be offering them a job at a very competitive, rate. And once they get the engagement rolling, they would be saying, okay. Wait. I wanna make sure you are up for the job I'm offering you, and, therefore, I need you to do a home assignment. That home assignment is, malicious code. It looks something like that. It's this is a PDF instructing you, to, to do some exercise. You're gonna be pulling off data from code from either GitHub or using the zip file that the recruiter sent you. And the moment you run the code, ideally, from the Lazarus perspective on a work, computer, you're infected now. And now they have access to your, work, work machine. From then from there, they would move laterally. Now an interesting case here, and they really developed this capability of social engineering, if they see a pushback, which in many cases, if you're you've tried to hire engineers, you know it's hard to hire them, they would fall back to a freelance work. So they would say, hey hey, Chris. I know you are happy at, where you work right now. What about some freelance work I'm gonna be paying you by the hour while you work at your main job? And this is a highly effective way, in order to make engineers engage. It's been working. We've seen this, happen a lot, and we, assume this is the same thing that happened with, the safe engineer. The second flaw, that was required in order to make this attack possible is blind signing. Now as I said earlier, what brings people to this kinda setup of having a safe wallet with a ledger device is that they think they're getting the best of both worlds. But, actually, when you combine it together, you see on the left hand side here, you see a screenshot from a safe wallet approval screen, essentially what you're seeing when you're approving a transaction. On the right hand side, you see, a screenshot, photo of a ledger device, showing you such a transaction. Now while the hardware wallet did its job in protecting the keys, so it had to be physically present. It had to be physically connected to all three computers, and the three signers, executives at Bybit had to be there physically and press it, multiple times in order for the transaction to be signed. It did not provide any assistance in seeing what the transaction is actually about. So when the malicious JavaScript code was running inside and changing inside the web UI of safe and changing the transaction underneath the hood, the ledger device got the malicious transaction. But the users who were looking at it had no way of understanding that this is not a transaction that they wanted to happen because they were looking and consuming the information from the web UI while signing it blindly on the ledger device. Essentially connecting the flow here, so they have their intent is to move funds from the cold wallet to the hot wallet. Again, this is something that was happening every few weeks. The web UI is compromised. They are initiating. So this was Bybit initiating a transaction. The malicious code in in the JavaScript is ambushing, waiting for that transaction to happen, changing it on the fly. And when, the signer is all signed the transaction, what they're actually doing is giving permission for ownership of the account to, the North Korean attackers. Let's dive deep for a second into the malicious transaction itself. And now remember the exact transaction function I mentioned earlier about how you invoke transactions with the safe wallet? So what, North Korea did is change everything here in the red box. They've changed the two value data in operation because what Bybit intended to do is send presumably some amount of millions of dollars worth of ETH, to their hot wallet. And what DPRK wanted them to do is to change the ownership, and the behavior of their smart contract wallet. Now you can see here on the right hand side the parameters that were changed. This is the the address of the DPRK contract. The amount is zero because you are not transferring your funds immediately, and we'll touch this in a second. The call data and the fact it's a delicate call and not a regular call. Without dive diving too much into technicalities, what happened here is that they modified, the implementation contract of the safe wallet and redirecting it from being the standard implementation contract by safe configured by Bybit to a DPRK deployed malicious contract. This is essentially means that now North Korea has control over the entire smart contract wallet, and, all the funds are at their hands. From that moment on, they have all the time in the world to just transfer it, follow on, launder the money, and take it home. So while this sounds like news, obviously, it's a very significant attack as we said at the beginning. It's not news. It's been happening for a decade. And there's a there's a history you can see of the Lazarus Group manipulating transactions in real time starting at least in 2016 against, financial institutions and also at some point in time pivoting at the earliest 2020, to targeting crypto as well. We've had just two reported incident last year, of something that is very similar. And the whole idea here is this is something North Korea has been doing, is doing, and will continue doing because it's highly profitable. It's highly profitable for them. They're managing to find the weak spots of the, the weak spots of the systems, blind them, and manipulate the transactions, making people, blind to the changes, stealing the money. Now it will continue to happen unless we change our approach to operational security. There's a true solution for that. And what you wanna have, obviously, is when you initiate a transaction between two wallets, you want it to get to the destination wallet. You don't want it ended up in North Korea. Our approach of enterprise grade security does exactly that. And before diving into that, I wanna do a quick recap because I acknowledge there's a lot of details in this attack. Again, there are two flaws here. Two things two major things that happened. One, safe production environment was compromised because a single developer was compromised using the access of that engineer machine, from that machine to the production system, and from that production system to all customers targeting Bybit, manipulating the transaction using that access with the malicious JavaScript code. Then Bybit comes, initiate the transaction, and blindly signing it because they were using a setup that made them blind to these changes, and this is the gap, the second gap that, the DPRK has abused here. Bringing this to the Fireblocks perspective, the most important side, part here before I start diving really deep into everything, my team, is bill is building, so it's gonna be really in-depth, is a screenshot. The mock UI here you can see on the right hand side. This is a transaction that no one would approve. No one would approve a transaction transferring 400,000 ETH to an address they've never seen before, which is a widely it's a it's a non widely set address, unknown address, never con conducted any business with. No one would click the approve button. And this is what you wanna get to. So even if something is is compromised on your stack somehow, you're not clicking, you're seeing the consequences, and you're not, falling for the trap. Diving into our implementation, we segment into, like, three different buckets. We have security design, governance, and operational intelligence. The security design starts with the fact that we have sensitive code running inside secure enclaves. This means separation of of highly sensitive and, let's say, standard code. Highly sensitive code being anything that touches transactions, authorizations, policies, and signing. All of these running inside a secure enclave, preventing them from being modified in runtime and making sure that it's running and performing as designed by our team. On top of that, we have our internal processes making sure that anyone who touches this highly sensitive code is going through a very rigorous code audit, code review, internal code review, and there's a separate build process for anything that touches these areas. For anything that we build across the platform, there's a strict code review and multiple people who are looking at this, but we also highlight and put the spotlight on these sensitive areas where we have even more, people and only highly privileged people can actually make any changes. The second item under security design is hardware key management and storage, again, via similar secure enclaves. This is true both on our SaaS platform, the cloud, powering by, powered by SGX And on the mobile phones, which are holding the, MPC key share, on the mobile phones, we have, both the, keys for authorizing transactions and the keys for signing the transactions, which are two separate set of keys to enforce segregation of duties even within, the the operational keys. We leverage as I said, MPC, to make sure there's no single point of failure with a specific entity. Second part is governance. Governance, you wanna make sure that the processes that you've set up to begin with as an organizations are the ones who are enforced automatically and programmatically by the software you're using. So our policy engine, which has parameters like white listing addresses, enforcement of users, permissions, wallets, and actions allows you to set up something. Like, this person can only interact from that wallet to this wallet under a certain amount amount of volume. So it's really focusing and setting the guardrails of your operations. And we also have a multi device approval setup. That means we if you have your laptop with your Fireblocks web UI, you would also have a a mobile phone app by Fireblocks, and you can initiate transactions from the from the web UI but cannot approve them from the web UI and you have to use your mobile phone. Vice versa, you cannot initiate transactions from the mobile phone and you have to use it, but you can only approve them. You can initiate only from web and colonially authorized from mobile. By, the definition of this of the specific policies, you would have determination of how many people involved in set approval. Last but definitely not least is the operational intelligence, which first and foremost giving you native action decoding. So you're seeing, like, on the screen on the right hand side, you're seeing what you are approving, what you're signing. In cases where it's a native transfer, it's relatively straightforward. In case you're talking about contra calls, we would have another level of decoding on this, and we would have control call simulation showing you the impact of that transaction. If you're operating within DeFi, so we have the DeFi threat protection, the threat detection suite, alerting you when you're engaging in highly sensitive or highly dangerous, actions. And, finally, the Fireblocks network. So if you are interacting with other counterparties within the Fireblocks, network, it's you can skip, the white screen. You can skip sending, wallet addresses over emails. You can just find the profile, connect over Fireblocks, and know that this is the right destination. It it was not manipulated in any way. This is what it looks like when it's stacked up. This is what we've built. All these layers talk to each other. In our security, this is the multilayer security that's powering, our platform. But you don't have to trust us. You need to verify everything because this is what we are we are doing. We are verifying ourselves both internally, but also with external vendors, external auditors, both on the private sector and the public sector, regulators and security companies within crypto and outside of it. Who are constantly looking at our code, at our processes, at our design, and they keep us honest even more, than we keep ourselves honest. So they're challenging us. They are constantly reviewing everything we're doing. So this is the another level of guarantee that not only the code is good and the design is solid, but it's it's staying like that because the processes are also solid, and we employ the state of the art, monitoring software and code scanning software and, following the best practices in all of these areas. So you know that everything I've just showed you is gonna remain the same and just gonna have more and more layers as we evolve and as the threats evolve. And on that note, I assume I know we've went through many details. I assume many of you have questions. Obviously, if you're a FireBooks customer, you know also after this how to reach out to us. If you're not, we'll welcome you. And, Chris, let's use the the rest of time for q and a. Awesome. Thank you, Shahar. And we do have a a a number of questions in the chat. I think the first one that comes up is, you know, why did Lazarus decide to target Bybit versus anybody else? So it's a great question. And the quest the answer, obviously, just, North Korea knows this. But, the most likely reason is operational security of the attacker. Now if you think about this, if you are, the attacker, you have this insane access to a wallet provider. And you know that once you do this manipulation, once you inject this malicious piece of code, if you do it in, you know, the spray and pray approach, we're just doing this for anyone who's, who's browsing and using the safe UI, what will happen is we will randomly hit targets. Maybe they'll be big. Maybe they'll be small. Statistically, they will be small, but immediately, people will start talking about it. And SAFE will close the gap, close the bridge like they did, would remediate, and you would lose the access. Now what they probably did, as I said, because the wallet was very, large at a billion and a half dollars, and was fairly active. So if you imagine yourself looking at all the safe, wallets out there, you're sorting them by size, you are then filtering out all the all the wallets who have not done any transaction in the past, like, three months, you would probably have this one at the top three. So they chose not to risk the access and go with the big game hunting targeting at that top wallet. And as you can see, obviously, their profit is, very significant. Awesome. Thank you. Okay. There's been also a just a number of questions just around, some of more of, like, the actual mechanics with how Lazarus actually was able to, you know, take over the developer workspace, at safe and also how they were able to, like, actually manipulate the code into production, etcetera. Do you think you could maybe give more detail or rehash kind of what we what we know, in terms of what that actually looked like and what they were able to do? Absolutely. I do wanna highlight that, obviously, part of this story is still evolving. We have not seen and SAFE has not yet to release, the forensics from that machine. What we do know for for sure is what the malicious code was, when it was deployed, what it did, and the fact that it originated from a safe developer machine. All of these details are confirmed. Our assessment is that they probably got into that machine using social engineering because this is what they usually do, but they also employ supply chain attacks like this one against other targets. Now to dive a bit into the the code and what was done there, so assuming you are now a North Korean hacker, hands on on a developer safe developer engineer, you have access to the production system, to fix bug, to change the UI, and stuff like that. And part of the UI is is barred, with JavaScript code. You edit that JavaScript code, and you insert this malicious snippet, and you hit save. You upload it to the production system. We do not know anything about the the processes that's safe. They wanna don't wanna speculate, but you can see that the code, is pretty obvious and highly targeted. Now once the code is there, it's being served to all customers. Everyone who's going, to the safe web UI, the app, is getting that code. What it did is, basically, they changed the function, the code that's handling transactions, and added a condition saying, if the source of the transaction is this wallet, the Bybit wallet, then enter this piece of malicious code, which completely ignored what the user wanted to do and replaced this with a hard coded predefined transaction that is the one that actually was carried on. As I said earlier, the malicious transaction changed the implementation contract of the safe wallet, and of the safe, smart contract wallet, giving North Korea, complete access and complete control over that wallet. Awesome. Next question is, would white, would using white listing, been enough to help prevent this attack? Yes. If if you look from the safe wallet perspective, they had all the parameters. They're getting a very clear two, and the two, the destination was not the one that the customer intended to. Now there's a caveat to what I said, a very clear yes, because it depends how you implement your policy engine. If the policy engine that's enforcing the white listing is built as part of the same JavaScript that was compromised, it would have been manipulated as well because the attacker would just skip the check and carry off. If it's something that's implemented outside of the approval device, like, you know, what we are doing when we have our policy engine running separately in a separate secure enclave on its own, It's later being verified downstream. So this is something that would completely disrupt this kind of a transaction. Awesome. Okay. Next question. And there are a bunch, so thank you and keep please keep them coming. If we are using SAFE, what can we do in order to ensure that, again, you know, whatever we're signing or, you know, that we're also not interacting with, any malicious contracts or other kind of malicious third parties? So first of all, you know, we are all waiting for SAFE, to release the final, statements and the forensic reports from their network to understand exactly what happened over there. If you are using SAFE or, honestly, if you're using any kind of a smart contract wallet, you need to make sure that you have clear signing of everything you are doing so you know, what you're signing. I think the best tip and the best takeaway from here is sort of to red team yourself. So, like, look at your processes, look at your day to day. If if you are the signer, you know it. If you're not, grab the person who's signing the day to day transactions and also the the most sensitive transactions and just look at what they do. Look at what information they have at hand that would allow them to spot this kind of an attack and other types of attacks. And then, you know, I think it's it's very obvious if someone, you know, critically thinking, looking, knowing that this kind of thing can happen, would look from the side, look at the operations like the setup we've described, would say, wait. Do you actually know what you're signing, or, like, what's the confirmation process? And if there isn't any, you're just relying on on that UI, maybe, maybe you can improve your shape. Awesome. Okay. Next question. There's actually a couple questions just around the blind signing. And maybe what, what would be helpful is if you could go maybe a bit more to the detail around, like, what actually, how the blind signing actually worked and what happened, and then also how Fireblocks can actually help, prevent or mitigate something along these lines. Okay. So the blind signing issue and it's called blind signing because you're signing blindly. Right? You are you don't know what you're signing. In this case so after the malicious code was running inside the WebUI, as I said earlier, buy it went and created the transactions as they do, as they do every few weeks. The transaction was manipulated in a way that's only the malicious transaction was sent to the ledger device to sign it, but not to the UI. So the UI was presenting still the original intent, transferring the funds to the, the right destination. However, the transaction that was created and was being signed on the ledger was not it. Now as I showed in the on the picture earlier, and we can flip all the way back, this is something this is essentially what they saw on the right hand side. So this is something that, like, based on this, you're supposed to know whether or not, it's a transaction you wanted, to to to execute, and it's practically impossible. Awesome. Okay. This one is a bit more, I guess, philosophical in nature, I guess, or more approach based. But, what are some feasible steps for signers to do before they actually sign a transaction? Yeah. It's it's, a bit philosophical because, you know, I would say as an organization and and, you know, we're targeting mainly, large businesses, very high stakes. The question is is actually take a step back even before the signing step. Ask as an organization, what is my policy? Which people should be involved in which operations? Right? You're not just asking what am I as a signer need to do. The company should be saying the stakeholders of the company should be saying, is this the right signer? Is this the right amount of signers? And do I even wanna sign such a transaction? All these questions go directly and input directly, your corporate policies, your security policies, coding into your, in this case, would be Fireblocks, policy engine. Now if based on your organizational security policy, you are the one who are assigned, to sign a transaction, inspect it. See that everything you you are you are about to approve about to sign. See that it makes sense. As presumably, you are an approver or signer because you know what you are doing. You know what the the company is trying to do. And when when you're seeing something that doesn't make sense, like, you're not sure what what is initiated, don't approve and actively cancel it. And call the person or go to the next room and and say, wait. What what's going on? And we've seen cases when when this actually saved the day. We've seen cases where people who were acting, you know, very vigilantly, they saw said, wait wait a second. I'm canceling this. We actually have security, incidents that were prevented at Starbucks customers, and I've had a chance to talking to them and they say, yeah. I knew something was wrong because I was starting getting, weird requests on my mobile. So I canceled it, logged into Fireblocks, and deleted the compromised user and went on. So nothing happened. Everything was was within the the boundaries of the policy, and there was no financial impact. So, again, you need to know what you're doing. You need to know the intent, and then look at the transaction, depends on its site, and inspect all the relevant critical areas. Who is the destination? Who's the counterpart you're engaging with? What is the action? What is the source wallet you're working with? And, again, does it make sense? Awesome. Another question was just why do exchanges typically hold such a large sum in a single wallet? You know, wouldn't it make more sense for them to split it into multiple different wallets, specifically hold wallets? So, there is a way to hold, you know, not hold many, many wallets is is an operational reason. I think one thing that you can change from the setup on top of, obviously, the combination of, vendors, what we call, like, the patchwork of different systems working together and creating this gap of blind signing is you wanna have probably not have your huge wallet talking directly to something that's hot and and presumably, is connected to all your customer withdrawals. Usually, the best practice would be to have some sort of, like, an intermediate wallet. It's a balance between the security of the funds and the operational cost of managing more and more and more wallets. But a lot of our customers do employ, wallet segregation. So having different wallets for different purposes. So in that case, you know that even if someone, mistakenly signed, a malicious transaction or just made a mistake, doesn't have to be North Korea, can be just a mistake, you know, the blast radius is only, you know, the combination on one hand, the policy, what that person is allowed to do, and the other people who are approving that transaction, as well as the funds that were, part of this wallet. So it's a balance of operational efficiency and security of funds. Awesome. Okay. Another question was, would this have been any different had had an an HSM been used versus say, like, you know, multisig or MPC or account abstraction? Would that have changed the outcome of of anything that we've seen here? Probably no. I mean, it do would depend on the HSM, but ledger is essentially an HSM. The the issue there with the blind signing is the blind signing on the, signing device. So you don't have any logic there, and the human who's looking so the only take a step back. The only logic you can have, basically, is a policy engine and then a person looking at the transaction. In this setup, there was no policy. So you only have the people who are looking at it. If instead of a ledger, you connect it to an HSM, still, like in this case, no keys would be stolen. HSM is a is a solid way to secure your keys as a ledger is. But operationally, what extra information would that HSM add you that would prevent the blind signing? I haven't seen yet an HSM that does contract call decoding. So I don't think it would change in any way, the result of this attack. Awesome. Is the current, off exchange, settlement setup, in the, current off exchange settlement setup, would my assets be protected on a similar attack, through, an exchange supported by Fireblocks? Yes. We've designed off exchange exactly in a way where the exchange does not have control direct control, to over the funds, And we are using this as sort of a way to prefund your account, but then the assets are used as a collateral. So they're locked. You cannot access them, but the exchange cannot access them as well. And, then you can trade and work on the exchange. The exchange has trust with the Fireblocks system knowing you're not gonna take the money out, and you know that it's being locked on Fireblocks and the exchange, has it as a different vault. They don't have access to it. And if for some reason they are compromised, they have no way, of, touching it. Awesome. Can you talk a bit more about how MPC is different versus the safe setup, which is essentially multisig? So I think it's it's wider than just MPC versus multisig, the story. Again, it's a story about from our perspective, it's a story about, like, end to end security, which is what you get on the Firebooks platform, versus essentially a patch a patch system where you have a multisig, but that multisig is actually being signed with other wallets, other hardware wallets, making you blind to the actual transaction. So it's not just comparing, you know, the the implementation of how you make sure multiple people are involved in the, in the signing of MPC versus multisig. It's the actual end to end security. MPC does, however, give you a stronger guarantee, to avoid transaction manipulation. There's there's a slight nuance, so I don't wanna dive too deeply. But, essentially, with multisig, if you compromise each party individually over time but not at the same time, it would still work because they just need this person to sign something. You get that part, and then that person to sign something. You get that part. You're busy together over time. MPC, it's one ceremony. Everyone has to see the same data. Everyone has to send, to sign the same ceremony at the same time. Awesome. Okay. Next question. What are your recommendation or what recommendations do you have for crypto exchanges that are using Fireblocks behind the scenes? Well, keep on. I would I would recommend there's something that we that we haven't covered here, which is usage of API users and automation. The most important part here is setting up the policy in a right way. So making sure that your policy is as strict as possible, obviously, with regards to, your required operation, the type of business we're running, and the volume of the business you are running. But you wanna make sure that when you set up that policy, you have the right tiers, both in terms of making sure, for example, from the hot wallet where you withdraw money for in in behalf of, of your end customers, there's probably no reason to have a fully automated process for withdrawals, of, you know, a million dollars. Right? You may wanna have someone looking at it before it's being approved. So you wanna have the tiers of amounts per transactions, and you also wanna have tiers of amounts that's accumulated over time. So daily and hourly, velocity rate controls so, you know, you're not losing, funds if someone does compromise something on your end and then sending malicious requests to Fireblocks. I will also recommend and this is connected to the question that was asked earlier about holding all the funds in one wallet. I would also recommend strong wallet segment segmentation. We've actually had a webinar, a few months ago about best practices for exchange security that touches exactly that, how you leverage the policy engine of Fireblocks to implement proper wallet segregation. And this touches exactly what I mentioned earlier, having the cold storage and middleware and then the hot wallets and making sure, this this line is how it's working and not something indirect and not allowing your cold water to communicate with one time addresses and and streamline the whole process. Awesome. How can we run tests to prove that, TAP, would not allow certain attacks? Would not. Sorry. You were cut off. Sorry. How, what how can we run tests to prove that TAP would not allow certain attacks? You can just do it. I mean, you have a FireBooks platform. You have a if you have a FireBooks workspace, create a transaction, see what happens. We know that in all cases, and unfortunately, we've had cases where customer networks were breached, an attacker was able to get a hold of legitimate Fireblocks credentials of those attack of those customers and then initiate transactions to Firebox. And in all cases, these transactions were limited, sometimes completely blocked by the policy that the customer had set up. So when we say battle tested, it's because we've seen this in action multiple times against real threats. I've mentioned earlier a case where, where someone actually detected an attack because the policy routed, transaction requests through their phone. So we've seen it as battle tested. If you have a Fireworks workspace, you can just create a policy and then act outside of it and see, and see what's going on. Awesome. And I guess as a follow-up to that, what are best practices for protecting updating TAP from attacks like this? When you set up TAP, the first thing you wanna do is not in front of your Firebooks workspace. It's probably on a whiteboard, and that is define your threat modeling, understand draw out your, network of wallets and your operations, see the volumes, the destinations you usually work with, decide who can do what with clear definition of roles, responsibilities for initiation, and for approval, both in terms of the humans involved, the machines involved, and the wallets involved from both sides, the source and the destination. And this also applies across all the different operations that you are doing as a business. Obviously, there's a difference between trading, or sending Bitcoin to counterparties that, you do custody for, and working with decentralized exchanges or on DeFi. So you wanna have threat modeling of what can go wrong, highlight potential gaps, and then update the policy appropriately. As I said, looking at amounts, looking at users, wallets, types of actions, these are the most critical ones. Awesome. I think we probably have time for one more one more question, maybe two. But, for someone that's using Fireblocks embedded wallets as well as infrastructure, are there best practices that you would recommend to prevent a, you know, by bit like scenario potentially? So that's definitely a diff a different setup, and I think we have a lot of resources on, the the on the dynamics of how embedded wallets work. Again, this is something you would that would go through the policy engine of Fireblocks and will leverage the care management of Fireblocks. It's basically the same thing as I said with, setting up TAP and reviewing TAP and updating it. And I think this is my number one tip to everyone if if, you know, if I can do a quick summary of everything we've discussed. Do two things. One, go to the whiteboard. Start with the threat modeling, writing down your operations and what could go wrong. Go red team against yourself. But also spend some time watching the people who are actually, doing the the operations. When you're talking a meta wallets, they will be mainly programmatically and not and not humans involved, but it's the same it's the same concept. Draw it out, the architecture, then look what's actually going on in the transaction, history, transaction requests, and see if it's as tight as possible. And if it's not, you should probably, update it. And if you are already a a customer of Farbisc, you can always reach out, to, our customer success managers and professional services team and security teams, to ask questions specifically on your account. Awesome. Listen. I think that's about all we're gonna have time for. Very much appreciate everyone's time today. Shar, any other closing remarks or questions? I mean, I think that was a pretty great way to to close it out, but any other thoughts or comments? I would say one last thing is, you know, we we really dove into details here, discussed a lot of things, and this is very like, it's significant attack in the space, said the most major one we've ever had in crypto. There's a clear way with what we've been trying to do, and this is why we've had this AMA, is we think we obviously believe in blockchain at Fireblocks. That is the future back end of the entire digital finance, and we think there's a right way and a secure way to do this to be resilient at this against this kind of attacks. We think it's necessary in order for the industry to scale up, and this is why we're here to help. We're here to educate, and we're here to support, the businesses. Awesome. Listen. Thank you all very much. Very much appreciate it. Again, for any questions that we didn't get to, we'll definitely try to reach out individually and make sure that we're getting in touch with you, especially any Fireblocks customers that may have asked any questions. We'll make sure that your, CSM team is gonna be reaching out. Thank you all so much. Really appreciate it. And, we hope you have a great rest of the day. Thank you. Thank you, everyone.