Last Updated: 2012-08-09 10:20:41 UTC
by Mark Hofman (Version: 1)
According to some new sources (thanks Alexander) a trojan is doing the rounds in the Netherlands at the moment causing major issues within organisations.
The web sites http://webwereld.nl/nieuws/111424/nieuwe-trojan-grijpt-wild-om-zich-heen-in-nederland.html and http://nos.nl/artikel/404668-computervirus-treft-ook-venlo.html (both in Dutch) report that a trojan is affecting a number of organisations. According to the article the trojan affects already Zeus infected machines. Fox-it has an analysis here http://blog.fox-it.com/2012/08/09/xdoccryptdorifel-document-encrypting-and-network-spreading-virus/ and some of the original information can be found here http://www.damnthoseproblems.com/?lang=en
According to the analysis the malware encrypts files which will be a problem for those without proper backups.
If you have samples feel free to upload them to our contact form (ziped up with a password of infected please).
Last Updated: 2012-08-09 06:33:57 UTC
by Mark Hofman (Version: 1)
Just as a quick follow up on Daniel's diary from last week (https://isc.sans.edu/diary.html?storyid=13813) regarding the liluhophilupop SQL injection run which has started up again as of approximately the 1st of August.
This particular run is very similar to the one back in December 2011 with one minor variation, so far. The platform being attacked is still applications with MSSQL as the backend. The target is to inject a php script which redirects, etc, etc (the usual rabbit hole). The main difference between the two attacks is that this time many different domains are being injected rather than the one main domain as was the case in December. Some of the comments on the previous diary entry provided some of the domains. These are the ones I have found so far.
rr.nu seems to be a nice spot for malicious domains.
The attack is ramping up slightly with search engines reporting approximately 235K pages infected at the moment. BTW previous sites that were affected back in December are being revisited as part of this run. So if that was you, then you may wish to check your log files to make sure you haven't been affected again.
If you look through your logs look for
--snip-- /somedirectory/somepage.asp somevar=38272%27+declare+%40s+varchar% --snip--
(I usually just grep/search for declare, or varchar or char, that usually does the trick)
If that does not find it look for large URL queries (say longer than 1000 chars) or 500 errors
identify the injection variable used, in this case somevar=38272
When you look through your previous logs you will find entries similar to these.
--snip-- /somedirectory/somepage.asp somevar=38272%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40v --snip--
--snip-- /somedirectory/somepage.asp somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%4 --snip--
--snip-- /somedirectory/somepage.asp somevar=38272%27%2F%2A%2A%2For%2F%2A%2A%2F1%3D%40%40 --snip--
These are a initial tests to see if the application has some ready injection points.
Take the IP address from these log lines and check your web logs again for those IP addresses and you will find other activities. The user agent string is also good to use, as often these stay the same even though different IP addresses are being used.
When you are doing remediation make sure the developers understand that any input that results in a SQL query can be used to inject, It does not have to be a form variable, any variable is fair game. All input must be validated prior to being used (and not just at the client end either).
Thanks to those that provided some log records. Happy logging