[Discussion] Compromised Safe has allocated airdrop, how to solve?

Hi fellow Guardians,

Unfortunately the airdrop that was assigned to me was assigned to a Safe that had been compromised (without my knowledge). The Safe is eth:0xE306bbd2fD51A435E21449223FB398376c0a37A4. If you look at the history of transactions, #41-44 are where the ‘attacker’ removed all existing owners and added themselves.

How this happened: The Safe was originally used for testing, and one of the third party testing PKs were compromised. I wasn’t aware of this so continued to use the Safe in testing things and did not remove the compromised PK :frowning:

Now the ‘attacker’ has access to the entire airdrop and will most likely just dump the tokens without contributing to the Safe community. I’m not sure what to do…

Some open questions:

  • The contracts don’t allow unilateral transfer or burning of tokens. Is there any other way to ‘invalidate’ the attacker’s tokens? Maybe via governance?
  • Would it be possible to assign the original airdrop amount to a new Safe that I will create?
  • Would governance allow a relatively small inflation of the supply to assign the original airdrop amount to my new Safe?
  • Do others have similar experiences or challenges?
2 Likes

That’s very unfortunate. :frowning:

  1. Did you already start working with law enforcement? Might be worth, as the exploiter’s account has received some ETH initially from another account that has interacted with CEXs, so high chances to identify the exploiter.

  2. We should probably get both accounts (Safe and hacker signer key) marked on Etherscan.

3 Likes

Nice Job , Scammer !
But I hope you listen to what I’m about to tell you. The man claims that he found out that his safe was broken into and wrote this post?) This is a hoax! Its address that was previously connected to the safe ( Safe ) here we can see that it was previously - 0xCA0E8F557ea98f950029A41D74F16DD76648B1F1 a long time ago, this address was hacked a long time ago, this address was hacked a long time ago. Look at the example transaction - https://etherscan.io/tx/0x4f311b1b25518e50001e9b1e3176e8aefee34909f8cc2921c8c860e3b8c0d65a - 63 days ago withdrawal of tokens using the flash bot. The address was hacked a long time ago but the person did not mention it until the time of the airdrop). How can you not know about transactions on your address?

also, you could not use your safe because your address was hacked and all the ether was transferred to intruders, you are just a scammer who wants to get tokens for free!

P.S We must understand that such cases may continue, and my proposal is not to respond to them, the token is something that cannot be withdrawn, we cannot be sure that what every person says is true and we are not a USDS token to ban people. We are a free platform, so don’t talk about development if you haven’t read SEP.

  1. Not yet. The compromised key was leaked via git push and was a QA account. So there wasn’t anything worth pursing when it was compromised… until this happened.
  2. Indeed i’ll look into this

Thanks for your concern. How did you know 0xCA0E… was the compromised PK?

To answer your concerns:

How can you not know about transactions on your address?

This was a testing Safe used while I was developing the original Aave Safe app v.1.0. Later on I left Aave but so did not monitor this Safe. There was also nothing of value, except some dust amounts, so there was no reason to monitor it.

also, you could not use your safe because your address was hacked and all the ether was transferred to intruders, you are just a scammer who wants to get tokens for free!

Firstly my address was not hacked. The PK of the QA engineer accidentally leaked the PK of their testing account to git. Since they were a QA engineer, they also had signing capabilities on the Safe to do their job.

Secondly, I’m not trying to get tokens for free. I want to evaluate the possibility of freezing or burning the attacker’s tokens, or at the very least, stopping the vesting of further SAFE tokens to their address.
I’m also seeking a way to re-assign the tokens (either the original amount or remaining amount to be vested) to my address, instead of the attacker.

P.S. if this was a scam then I would not want to burn/freeze/blacklist the attackers tokens. Hopefully that makes it clearer.

2 Likes

Okay, maybe you’re not a scammer. But if you love DAO, don’t you think about FREEDOM? If every time a scammer or just a person writes with a request to block or burn tokens because he lost them through his / someone else’s fault, will this be a DAO? Or a full-fledged token?

I understand that you may have lost a valuable asset, but first of all, it’s your fault, just like leaving your wallet on the subway. But let’s proceed from our policy and our world, there were a lot of criminals at your address, we don’t know exactly who stole your tokens and whether they were stolen, because the address had an auto-withdrawal system for ether upon receipt. It didn’t matter, you wouldn’t be able to get the airdrop and it would be lost and you still wouldn’t get it. If we block the address of a person and the tokens on it every time, then this will alienate new users because the token cannot be taken away, but here we get a lack of decentralization, we get a theater with puppets, where in which case your assets can be frozen / burned.

But if you are telling the truth, then I am ready to share with you part of my coins if the token is unlocked. I understand this may not return the loss, but it’s better than nothing.

3 Likes

I have a small amount of unrecoverable SAFE tokens from two wallets I set up to test transferring assets into and out of prior to setting up my current set of Safes. As these were test wallets I did not save the seed phrases. Moving forward, even for test wallets, I will save the seed phrases in case these wallets need to be revisited for any reason.

1 Like

Any updates on this thread?
I believe @daveytea as you can verify his/her identity on the Internet.

Unfortunately no updates. There just wasn’t enough concern for the relatively small amount that was compromised to do anything governance related.

I’ve just taken this as a lesson and allowed the attacker to walk away with their slowly vesting SAFE tokens…