Operational security professionals work to figure out where their information can be breached. Looking at operations from a malicious third-party’s perspective allows us to spot vulnerabilities we may have otherwise missed so that we can implement proper countermeasures.
Operational security professionals work to figure out where their information can be breached. The most important thing to understand here is the path of the cyber attack — its vector. Let’s take a closer look.
Example №1 — Social EngineeringLet’s take a hypothetical situation in which your computer gets infected with a Remote Access Trojan (RAT) virus. One of two things may happen. If the attack was carried out by a rookie hacker (i.e a lamer) then he likely orchestrated a wide massive attack without a target in mind. He can steal some information on you like your browser cookies and then sell it.
Social Engineering. Example (1).The second option is that this was a direct attack. The hackers made a phishing page on your router, through which you could enter your password (poisoning the DNS server). To prevent this type of attack, you ideally need to separate your machines and networks. You should also check certificates.
Here is an example of a very dangerous cyber attack on your crypto wallet:
Consider checking the entire address of your addressee’s wallet before you click Send!
In short, crypto clipper, address poisoning and «zero-transfer/approve transaction» attacks are just vanity-generated address attack variations! For example, that’s how scammers are using vanity-gen to generate an address similar to the victim’s ones (first 4 and last 5 digits are similar) in a address poisoning attack. This is common at ETH, BSC, even BTC!
While seemingly simple and similar to the Dusting Attack, this is a completely new thing closer to social engineering / vanity attacks/phishing!Examples of address poisoning on Bitcoin:
Bitcoin clipper examples:
Questions began to be raised over the discovery of mysterious outgoing zero transactions with supposed approve signatures…
Check out this example, seen both at Tron and Ethereum Main-net:
This address (Attacker):etherscan.io/address/0xfe3c53086f256219b81a6afbf614cd839c1c5982Is interacting with this smart contract (and other similar ones):etherscan.io/address/0x23dd013da6d35b3271c9199e38d659e763e38463Creating transactions like these: etherscan.io/tx/0x7da7966512de60eef5c494407782bddf569d1cfb42793f0afe77ee9e2edc16bfAnother example (Tron):
The transferFrom function was called, not transfer, which means that the Fromaddress was supposed to give that address who signed the transaction, but since the sum is zero and all new contract memory cells are initialized with zeros, everything runs smoothly (since there is a 0 for any address) (deepl.com)