Closed Ivan1905 closed 1 year ago
Vxatz
commented
1 year ago Hi @Ivan1905,
the issue that I notice here is that both the ICE-PHISHING-HIGH-NUM-ERC20-APPROVALS and ICE-PHISHING-HIGH-NUM-APPROVED-TRANSFERS couldn't catch the mentioned interactions, as at least in these examples, they happen after the Approval/1st Transfer. I can add a "first interaction" check to catch interactions happening before the alert is fired.
christian-forta
commented
1 year ago i think this would be a good addition.
christian-forta
commented
1 year ago @Vxatz , do you have status on this one? Seems like its the source for a lot of FPs.
Vxatz
commented
1 year ago @christian-forta For the last two examples (which are about transfers) I'm adding a check that each transfer should concern a unique "victim" address/asset combination (e.g. this alert was created by separate transfers of the same asset from the same victim)
For the first two (Approval alerts), from what I have observed, and if I have not missed anything, there is no other interaction before the Approval, so I believe adding the check that I mentioned before would not be efficient.
What I'm adding is this: Before firing the alert (so after the approval count threshold has been exceeded), for all the ~previous~ approvals ~besides the last one~ (Edit: Thinking about this again, I'm also including the latest approval, as there's still a chance there existed an earlier transfer and it doesn't really affect performance), check that there is no more than one transfer of the same asset from the "victim" initiated by the "attacker". This would still not eliminate the FPs, but would reduce them.
Please let me know your thoughts, especially about the 2nd addition.
christian-forta
commented
1 year ago Sounds good. Let's see how that improves precision and we can revisit.
On Fri, Jun 9, 2023, 4:11 AM Vxatz @.***> wrote:
@christian-forta https://github.com/christian-forta For the last two examples (which are about transfers) I'm adding a check that each transfer should concern a unique "victim" address/asset combination (e.g. this https://explorer.forta.network/alert/0x9e7b59bef7041227d6b939475c97f3a8a8ff787ffc4572279c154cba1c1a5602 alert was created by separate transfers of the same asset from the same victim)
For the first two (Approval alerts), from what I have observed, and if I have not missed anything, there is no other interaction before the Approval, so I believe adding the check that I mentioned before would not be efficient.
What I'm adding is this: Before firing the alert (so after the approval count threshold has been exceeded), for all the previous approvals besides the last one, check that there is no more than one transfer of the same asset from the "victim" initiated by the "attacker". This would still not eliminate the FPs, but would reduce them.
Please let me know your thoughts, especially about the 2nd addition.
— Reply to this email directly, view it on GitHub https://github.com/NethermindEth/forta-starter-kits/issues/44#issuecomment-1584404401, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYF4T47F6CZIUDD4I63TMPDXKMAENANCNFSM6AAAAAAYTF5QTM . You are receiving this because you were mentioned.Message ID: @.***>
Vxatz
commented
1 year ago Checks added on https://github.com/NethermindEth/forta-starter-kits/pull/52
Hi Vasilis,
I have observed that the scam detector triggered many ice phishing alerts which I assessed like False positives. Apparently in many cases the bot is flagging addresses that seem to be stealing USDT but they are not.
Let me give you an example:
As you can see in this example, "targets" seem to be approving the suspected address and then funds are being sent to 0x4baE69a92C1F812Cb2B74fcd2f3E664aEa435c46. What is very strange is that in most of the cases, targets are interacting in many opportunities with the mentioned address which seems like something illogical.
Attaching you some other examples here: