Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,821
An example of why malware testing should include real-world infection vectors.
www.threatdown.com
Attack flow:
Malicious Ad ---> attacker-controlled domain ----> the computer IP stored on server + download the Loader ----> the user executes the Loader -----> Loader checks the computer IP with that stored on server ----> the attack is stopped if the IPs are different ----> ....
The above fragment is crucial. Suppose the malicious sample (EXE dropper) is tested like in many video tests (the red fragment in the attack flow). In such a case, the malware will not try to infect the system to avoid detection in the sandbox or the analyst environment. The proper testing must start from the real-world starting point (Malicious Ad)

New Go loader pushes Rhadamanthys stealer
A malicious ad for the popular admin tool PuTTY leads victims to a fake site that downloads malware.
Attack flow:
Malicious Ad ---> attacker-controlled domain ----> the computer IP stored on server + download the Loader ----> the user executes the Loader -----> Loader checks the computer IP with that stored on server ----> the attack is stopped if the IPs are different ----> ....
Upon executing the dropper, there is an IP check for the victim’s public IP address. This is likely done to only continue with users that have gone through the malicious ad and downloaded the malware from the fake site.
The above fragment is crucial. Suppose the malicious sample (EXE dropper) is tested like in many video tests (the red fragment in the attack flow). In such a case, the malware will not try to infect the system to avoid detection in the sandbox or the analyst environment. The proper testing must start from the real-world starting point (Malicious Ad)