How Spamhaus’ attackers turned DNS into a weapon of mass destruction

A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet's Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, "Operation Global Blackout" (later dismissed by some security experts and Anonymous members as a "massive troll"), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.
This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn't brought the Internet itself down, it has caused major slowdowns in the Internet's core networks.
DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or "volunteer" systems within their networks to stage such attacks. But thanks to public cloud services, "bulletproof" hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.

Hello, operator?

The Domain Name Service is the Internet's directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a "root" DNS server keeping a list of each of the "authoritative" DNS servers for each domain registered with them. If you've ever bought a domain through a domain registrar, you've created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.
When you type "arstechnica.com" into your browser's address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you've requested a host name that's in a local "hosts" table for servers within your network, or one that's stored in your computer's local cache of DNS addresses you've already looked up.) But if it's the first time you've tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google's Public DNS.
There are two ways for a resolver to get the authoritative IP address for a domain name that isn't in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain's DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or "zone" within a larger domain—such as www.subdomain.domain.com—it may tell the resolver to go ask that zone's DNS server. The resolver "iterates" the request down through the hierarchy of DNS servers until it gets an answer.
But on some networks, the DNS resolver closest to the requesting application doesn't handle all that work. Instead, it sends a "recursive" request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.

How DNS queries are supposed to work—when they're not being used as weapons.

To save time, DNS requests don't use the "three-way handshake" of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a "connectionless" protocol that lets the server fire and forget requests.

Pump up the volume

That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.
The "amplification" in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers' victim.
DNS amplification attacks wouldn't be nearly as amplified if it weren't for the "open" DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was "as high as 10Gbps and used as many as 140,000 exploited name servers," Vaughan and Evron reported. "A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60."
But even if you can't find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A "root hint" request—sending a request for name servers for the "." domain—results in a response 20 times larger than the packet the request came in. That's in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.

A comparison of a "root hint" query and the response delivered by the DNS server. Not all data shown.

 

 

 

In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider's site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.
But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.

No fix on the horizon

The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that "simple" fix isn't exactly easy—or at least easy to get everyone who needs to participate to do.
There's been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force's BCP 38, an approach to "ingress filtering" of packets. First pitched in 2000  1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even "root hint" responses received from outside their own networks, that would require action by the owners of the network. It's an action that doesn't have a direct monetary or security benefit to them associated with it.
ISPs generally do "egress filtering"—they check outbound traffic to make sure it's coming from IP addresses within their network.  This prevents them from filling up their peering connections with bad traffic.  But "ingress" filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.
Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets.  DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it's unlikely that would ever happen, considering that you can't even convince people to properly configure their DNS servers to begin with.
Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn't seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And maybe pigs will fly.

Bron: Arstechnica

Details on the denial of service attack that targeted Ars Technica

Last week, Security Editor Dan Goodin posted a story about the "swatting" of security reporter Brian Krebs and the denial of service attack on Krebs' site. Soon after, Ars was targeted by at least one of the individuals behind the Krebs attack. On Friday, at about noon Eastern Daylight Time, a denial of service attack struck our site, making connectivity to Ars problematic for a little less than two hours.
The attack continued to run throughout Friday. At 9pm EDT, when our hosting provider brought down one of the filters that had been put in place to thwart it, it quickly became apparent that the attack was still underway, and the filter was restored. The most aggressive filters were finally removed on Saturday.
At least in part, the offensive used the same attack tool and user credentials that were involved in the denial-of-service (DoS) attack on Krebs On Security, as Krebs himself revealed in a blog post. The attackers used multiple accounts on TwBooter, a "booter" site that provides denial of service attacks as a paid service (ostensibly for security testing purposes), to launch an automated, denial of service attack on Ars. And at least one of those logins was also used to attack Krebs' site.
TwBooter masks all of the complexity of launching attacks against sites. Users of the site can, depending on how much they pay, launch up to three simultaneous automated attacks against sites through a simple Web interface. TwBooter users can even set up multiple accounts and fill up the queue of the service's "attack server."

Individual accounts using TwBooter's server can be "licensed" for up to three simultaneous attacks lasting up to two hours, if you can come up with the cash. Free plans can be set up in exchange for filling out a few surveys.

It doesn't cost much to get in on the ground floor with TwBooter—an account with rights to a single automated attack of up to 60 seconds in length is $10 for a month. This means you can launch as many 60 second attacks as you want, one at a time, all month long. The "license" to launch up to three attacks at a time of up to two hours duration is $169 a month—but there's a 20 percent discount if you pay through Liberty Reserve instead of PayPal. There's also a free plan that allows for attacks up to 300 seconds long. That service requires users to pick an attack type from a pull-down menu in a Web form.

The Web form for launching attacks from TwBooter's free attack service.

PayPal payments for the site are routed to Sebastien Lariviere, a former IT technician for the county government (MRC) of Pierre-De Saurel in Quebec (now operating as Lariviere Security). Lariviere did not respond to e-mails from Ars for comment.
Obviously, sites like TwBooter generate a lot of ill will and are ironically the target of DoS attacks themselves. Like many legitimate and "black hat" sites—such as the site exposed.su, a website that recently posted the personal information of many public figures—TwBooter runs behind the CloudFlare content delivery network as a way of shielding itself from attacks.
TwBooter may not have been the only service used to launch the attacks on Ars and Krebs. "There are dozens of these booter services out there, most of them based on the same source code," Krebs told Ars. But Krebs received a tip pointing to a dump of TwBooter's customer database—openly accessible on the services' website. It's clear the TwBooter site was part of the attack. A snippet from the SQL dumps Krebs provided to Ars show that multiple attacks (including Slowloris, TCP amplification, and SYN flood attacks) were queued up by multiple accounts on the site.

Pick your poison

Some of the attacks served up by TwBooter are targeted at Web servers themselves. For example, HTTP Get and Post attacks attempt to overwhelm the ability of the targeted server to respond by filling up buffer memory with requests. But there were a few attacks thrown at Ars that don't require the massive traffic of a million-PC botnet.
Slowloris, for example, takes a less brute-force approach—it's a slow HTTP attack that exploits a misconfiguration of the Apache Web server. It sends partial HTTP requests to its intended victim, which forces the server to keep the connection open while waiting for the rest. Because it relies on very little traffic to do the job, it doesn't have to be distributed to work. But since it's dependent on the target being an Apache server that hasn't been tweaked against the slow HTTP style attack, it's not very effective against high-volume Web servers (especially sites using NGINX Web servers, like Ars).
Another attack used against Ars was the RUDY, or R-U-Dead-Yet attack, which also uses relatively few packets. Instead of sending partial requests, it sends what seems like an unending HTTP POST, sending a very large value for content-length in the POST request header. That keeps the server waiting for the rest of the POST to come until the length is reached... which never happens.
Other attacks in the "booter" arsenal go after the network connections of the targets themselves. SYN Flood attacks, for example, attempt to overwhelm the target's network connection by creating a huge volume of "half-open" network connections, using the nature of the TCP protocol's "three-way handshake" to use up server resources. The attacker sends SYN, or "synchronize," requests to the target; the target responds with a synchronization acknowledgement (SYN-ACK), which would normally prompt a return acknowledgement (ACK) message from a legitimate user connection. Instead, the attacker never sends ACK packets back, and the target is left with unfinished connections filling up its network buffers until it can't handle any more connections. These packets are usually sent with forged headers (since the attacker never has to actually get the SYN-ACK from the server), so they're difficult to trace and can appear to be more distributed than they actually are.
Another attack type flung at Ars was a UDP-LAG attack. It just uses a large stream of UDP packets in an attempt to overwhelm a target's network connection and knock them offline. UDP-LAG attacks on "booter" services are often used by online gamers who want to slow down the network connections of a competitor. This way, they can camp on their location and kill them while they lag, respawn, and lag some more. Because they use UDP packets, UDP-LAG attacks in large volume can look like DNS amplification attacks—attacks that use responses from DNS servers to spoofed requests that give the address of the target.

Shrugging it off

Fortunately, Ars' hosting provider was able to quickly identify the attacks that were causing the most damage to site availability. Our IT team alerted our provider to the problem at 12:09pm EDT on Friday; the problem was mostly in hand by 1:30pm through the application of traffic filters at the provider's router.
But the fact remains that anyone with some spare change, spare time, and an axe to grind can turn to sites like TwBooter and stage DOS attacks at will—with little fear of retribution. The sites come and go, hiding behind the thin veil of a "terms of service" agreement that asks users, pretty please, to not misuse their attack servers. These booters profess that they are for "security professionals only"—yet they do little to track the actual identities of those who use the servers.

Bron: Ars technica

SSHD rootkit in the wild

There are a lot of discussions at the moment about a SSHD rootkit hitting mainly RPM based Linux distributions.

Thanks to our reader unSpawn, we received a bunch of samples of the rootkit. The rootkit is actually a trojanized library that links with SSHD and does *a lot* of nasty things to the system.
At this point in time we still do not know what the initial attack vector is – it is unknown how the attackers get root access on the compromised servers that is needed to change the legitimate libkeyutils library with a trojanized one. We are, of course, keeping an eye on the development and will post a new diary or update this one if we receive more information about the attack vectors.
The trojanized library is very, very nasty. Upon execution it performs a number of actions, as described below.

The code first deobfuscates the text strings needed for it to work. The original text is only XORed so this is very easy to retrieve and the deobfuscated strings have already been posted on a lot of sites.
Once that has been done, the library sets up everything needed for it to work. It resolves symbols for the following functions which are used later: PEM_write_RSAPrivateKey, PEM_write_DSAPrivateKey, MD5_Init, MD5_Update, and MD5_Final. As you can already see, it is definitely messing up with the authentication mechanism.

Besides resolving the symbols, the library also hooks the following functions: pam_authenticate, pam_start and crypt as well as audit_log_user_message and audit_log_acct_message. By hooking these functions, the rootkit can modify the flow of the SSHD – as you can see, this is a user-mode rootkit, as it does not affect the kernel.

The main activity of the rootkit consists in collection of credentials of authenticated users. Notice that the rootkit can steal username and password pairs as well as RSA and DSA private keys, so no matter which authentication mechanism you use, if the target host is infected it will successfully steal your information. The hooking of audit_log* functions was done to allow the attacker to stay as low profile as possible – if the attacker uses the hardcoded backdoor password to issue any commands to the rootkit, no logs will be created.

The current version of the rootkit supports three commands: Xver, Xcat and Xbnd. The first command just prints the rootkit’s version; the Xcat commands print the collected information back in the session for the attacker while the Xbnd command allows the attacker to setup a listener.
Besides this, the rootkit can automatically send collected credentials to the attacker. In order to do this the rootkit has a DGA (Domain Generation Algorithm) implemented that will create random looking domain names in the .biz, .info and .net domains (in that order). It will then send a DNS packet containing collected credentials to the target IP address, if it was able to resolve it (meaning the attacker has registered that day’s domain). If no domains have been resolved, the DNS packet is sent to the hard-coded IP address, which in all samples we received was 78.47.139.110.

The rootkit itself looks very similar to the Ebury trojan which was detected back in 2011. In fact, I’m pretty sure that a lot of the code has been directly copied, however, the Ebury trojan patched the whole SSHD and required the attacker to change it.

This was easier to detect and prone to being overwritten with patching. The libkeyutils library, which comes as part of the keyutils-libs package is not changed that often so the chance of it being overwritten automatically is much lower.

If you run a RPM based system you can check the integrity of the file with the rpm command:
# rpm -Vv keyutils-libs-1.2-1.el5
........    /lib/libkeyutils-1.2.so
S.5.....    /lib/libkeyutils.so.1
........    /usr/share/doc/keyutils-libs-1.2
........  d /usr/share/doc/keyutils-libs-1.2/LICENCE.LGPL

This will check a lot of things, the most important being the MD5 checksum so if you see the output as one above you have a trojanized library. Proper output should have all (and only) dots. Keep in mind that the RPM’s verification, of course, depends on the integrity of its database and the kernel itself.

Bron: ISC

Mandiant Exposes APT1 – One of China’s Cyber Espionage Units & Releases 3,000 Indicators

Today, The Mandiant® Intelligence Center™ released an unprecedented report exposing APT1′s multi-year, enterprise-scale computer espionage campaign.  APT1 is one of dozens of threat groups Mandiant tracks around the world and we consider it to be one of the most prolific in terms of the sheer quantity of information it has stolen.

Highlights of the report include:

• Evidence linking APT1 to China’s 2nd Bureau of the People’s Liberation Army (PLA) General Staff Department’s (GSD) 3rd Department (Military Cover Designator 61398).
• A timeline of APT1 economic espionage conducted since 2006 against 141 victims across multiple industries.
• APT1′s modus operandi (tools, tactics, procedures) including a compilation of videos  showing actual APT1 activity.
• The timeline and details of over 40 APT1 malware families.
• The timeline and details of APT1′s extensive attack infrastructure.

Mandiant is also releasing a digital appendix with more than 3,000 indicators to bolster defenses against APT1 operations. This appendix includes:

• Digital delivery of over 3,000 APT1 indicators, such as domain names, IP addresses, and MD5 hashes of malware.
• Thirteen (13) X.509 encryption certificates used by APT1.
• A set of APT1 Indicators of Compromise (IOCs) and detailed descriptions of over 40 malware families in APT1′s arsenal of digital weapons.
• IOCs that can be used in conjunction with Redline™, Mandiant’s free host-based investigative tool, or with Mandiant Intelligent Response® (MIR), Mandiant’s commercial enterprise investigative tool.

The scale and impact of APT1′s operations compelled us to write this report.  The decision to publish a significant part of our intelligence about Unit 61398 was a painstaking one.  What started as a “what if” discussion about our traditional non-disclosure policy quickly turned into the realization that the positive impact resulting from our decision to expose APT1 outweighed the risk of losing much of our ability to collect intelligence on this particular APT group.  It is time to acknowledge the threat is originating from China, and we wanted to do our part to arm and prepare security professionals to combat the threat effectively.  The issue of attribution has always been a missing link in the public’s understanding of the landscape of APT cyber espionage.  Without establishing a solid connection to China, there will always be room for observers to dismiss APT actions as uncoordinated, solely criminal in nature, or peripheral to larger national security and global economic concerns.  We hope that this report will lead to increased understanding and coordinated action in countering APT network breaches.
We recognize that no one entity can understand the entire complex picture that many years of intense cyber espionage by a single group creates.  We look forward to seeing the surge of data and conversations a report like this will likely generate.
You can download the report, the appendices and view the video showing APT1 attacker activity at http://www.mandiant.com/apt1.

Bron: Mandiant

In Turn, It's PDF Time

We have found IE, Java, and Flash zero-days in a row in the past several months, and now it's PDF’s turn. Today, we identified that a PDF zero-day is being exploited in the wild, and we observed successful exploitation on the latest Adobe PDF Reader 9.5.3, 10.1.5, and 11.0.1.

Upon successful exploitation, it will drop two DLLs. The first DLL shows a fake error message and opens a decoy PDF document, which is usually common in targeted attacks. The second DLL in turn drops the callback component, which talks to a remote domain.



We have already submitted the sample to the Adobe security team. Before we get confirmation from Adobe and a mitigation plan is available, we suggest that you not open any unknown PDF files. We will continue our research and continue to share more information.

[Update: February 13, 2013]
In response to the many requests we’ve received for more detailed information, we would like to let our readers know that we have been working with Adobe and have jointly agreed to refrain from posting the technical details of the zero-day at this time. This post was intended to serve as a warning to the general public. We will update this post with more information at a later time.

Bron: Fireeye

Business Partners Give Hackers Easy Access to Secure Firms

As frequently targeted, high-value companies continue fortifying their defenses, FireEye researchers claim that attackers are increasingly setting their sights on the affiliated but not-as-well-protected third-party organizations that do business with them.

By aiming phishing email campaigns at softer targets, attackers believe they can compromise the networks of more relevant organizations in a roundabout way without having to defeat their sophisticated security systems.

The FireEye Malware and Intelligence Lab illustrated this assertion in their analysis of an attack targeting a Taiwanese tech firm that frequently works with the government and financial services industry in that country. The attackers reportedly wanted to compromise both the Taiwanese Government and financial services organizations. Rather than launch a direct attack, they crafted an email purportedly coming from the Taiwanese Ministry of Finance in an attempt to phish employees at and compromise the unnamed tech firm.

Once an attacker infiltrates the tech firm, he can leverage access given to the tech firm by the higher value targets in order to piggyback his way onto the more valuable Taiwanese Government and financial service networks.

The attack itself evades pattern-based malware detection methods by hiding its payload in an encrypted and password protected word document. In this way, attackers don’t need to develop their own zero-day exploit, but can rely on their victims to execute the malware themselves.
It may seem ineffective for an attacker to password protect his malware payload, but as from Ronghwa Chong, the senior malware and forensic engineer at FireEye explained to Threatpost via email, a password protected, encrypted word document promises to be interesting and the password, in this case, was easily guessable, so a number of users made the mistake of opening the malicious document.

In his analysis, Chong claims a number of tell-tale signs indicate that this particular attack is emanating from China. You can read the more of the technical aspects of the attack in Chong’s write-up on the FireEye Malware and Intelligence Lab blog.

Bron: Threatpost

Inlogs Nu.nl en Telegraaf.nl gestolen via Dorifel

Oost-Europese criminelen die 750 GB aan Nederlandse overheids- en ziekenhuisdata stalen via Dorifel en Citadel, opereerden vanaf Chinese domeinen. Ook inlogs van Nu.nl en Telegraaf.nl zijn gestolen.

Die Chinese link is gelegd door beveiligingsbedrijf Surfright. De domeinen pobelka.com en ipo90.com blijken in het Chinese Xiamen te zijn geregistreerd. Het domein pobelka.com is gelinkt aan het Citadel-botnet dat vorig jaar specifiek Nederlandse computers aanviel. Het tweede domein is verbonden met de uitbraak van Dorifel, dat vorig jaar grote paniek veroorzaakte bij onder meer besmette Nederlandse gemeenten.
Het Pobelka-botnet dat verantwoordelijk is voor de diefstal van 750 GB aan Nederlandse gevoelige data leek vorig jaar platgelegd te zijn door Digital Investigations in samenwerking met Surfright en de High Tech Crime Unit van de KLPD, maar naar nu blijkt zijn de criminelen overgeschakeld naar nieuwe Command & Control-servers. Veel van de 150.000 besmette Nederlandse pc's krijgen hun commando's nu van een nog onbekende server.

Ook ziekenhuizen en multinationals getroffen

Hoe veel van die 150.000 computers nog steeds besmet zijn, is onduidelijk. Veel van die computers staan en stonden bij overheidsinstellingen, ziekenhuizen en bedrijven, waaronder vliegtuigmaatschappijen, een Nederlandse multinational en een Nederlands hightechbedrijf. Van al die overheden en bedrijven is data gestolen.
Daarbij ging het onder meer over complete overzichten van de ict-netwerkinfrastructuur van bedrijven, van productieplannen van een hightechbedrijf, notities van ziekenhuismedewerkers, overheidsmedewerkers die aan antwoorden bezig waren op Kamervragen en login-gegevens van diverse organisaties. Al die gegevens stonden op de door Digital Investigations buitgemaakte Command & Control-server die het botnet aanstuurde.

Loigingegevens van Nu.nl en adservers

Met name de logingegevens hebben voor veel vervolgellende gezorgd. Doordat er tevens inloggegevens van mediabedrijven waren gestolen, kon zonder te hacken toegang worden verkregen tot het content management systeem van Nu.nl en werd schadelijke code in documenten in het cms gezet. Ook de adservers waarvan onder meer De Telegraaf gebruik maakte, zijn zo binnengedrongen.
Volgens Erik Loman van Surfright zijn op de buitgemaakte C&C-server gegevens gevonden "van vrijwel elk Nederlands bedrijf" en zelfs van zo geheten Industrial Control Systems (ICS). Dat zijn systemen, zoals SCADA, die zorgen voor de aansturing van onder meer sluizen, bruggen, dammen en andere belangrijke infrastructurele werken. Ook worden ze gebruikt in kerncentrales.

Surfright hint op cyberspionage

Doordat er op de C&C-server naast de 750 GB aan Nederlandse data geen bankgegevens werden ontdekt, rijst de vraag wat het doel was van de criminelen. Volgens Loman is er een kans dat de data is doorverkocht aan andere overheden, maar kan hij daarvoor geen bewijs overleggen. "Maar het ontbreken van bankdata, waarvoor Citadel (nota bene een Banking Trojan genoemd) over het algemeen wordt gebruikt om die te vergaren, is opvallend."
Een rapport van Fox-IT's onderzoeker Michael Sandee stelt echter dat een dergelijke spionage niet voor de hand ligt. De nu nieuw ontdekte Chinese domeinconnectie is in deze wel verdacht.

Lauwe interesse van Nederlandse overheid

Overigens klaagt Surfright over de lauwe interesse van de Nederlandse overheid in de bevindingen van het bedrijf en dat van Digital Investigations. Hoewel er samengewerkt is met de Nederlandse opsporingsdiensten, was er verder weinig interesse, ondanks dat getroffen gemeenten dagenlang plat lagen en er zelfs servers op ministeries waren getroffen. "Omdat overheidsbeambten de bevindingen niet interessant genoeg vonden en geen reden zagen tot een nationaal onderzoek, is ons uitputtend onderzoek geen nationaal nieuwsitem geworden", schrijft het bedrijf in een blogpost.
Loman zegt dat de aanval van de Pobelkacriminelen niet zo gericht is uitgevoerd als de aanval op Amerikaanse mediabedrijven als New York Times en Washington Journal, maar wijst er wel op dat de Citadelbesmettingen in Nederland liefst acht maanden onder de radar is gebleven.

Bron: Webwereld