Search

vulnerablelife

Vulnerable Life by Vulneraman | Cyber Security Blog

Month

July 2014

Mr. Hack: Googlebot’s Unruly Alter Ego

Dr. Crawlit - A Bot That Cares About the ‘Little Guy’

In the first post of this two-part series, we shared our insights into Googlebot’s activity and behavior patterns.

However, no overview of Googlebot activity would be complete without a mention of Googlebot imposters, who assume Googlebot’s identity to gain privileged access to websites and online information.

Every day millions of these “evil twins” are used for DDoS attacks, hacking, spam, content theft and many other shady activities. The details of these malicious escapades, that paint the event logs of Incapsula’s security services, are what we share with you here today.


Methodology

For purposes of this study, we observed over 400 million search engine visits to 10,000 sites, resulting in over 2.19 billion page crawls over a 30 day period.

Information about Googlebot impostors (a.k.a., Fake Googlebots) comes from inspection of more than 50 million Googlebot impostor visits, as well as findings from our ‘DDoS Threat Landscape’ report, published earlier this year.

One in Twenty Five Is up to No Good

One of the most interesting facts about Fake Googlebots is just how common they really are. Based on our data, we see that over 4% of bots operating with Googlebot’s HTTP(S) user-agent are not who they claim to be. For those who unfamiliar with the term, “user-agent” is an online equivalent of an ID card, used to identify website visitors – browsers or bots.

As demonstrated below, the actual “type” of these impostors may vary, but all of them should be deemed suspicious by default, due to their attempt to assume a false identity.

Why Use Spoofed Googlebots?

To answer that question, just consider the benefits that come with fake Google credentials. For one, “Google ID” is as close as a bot can get to having a VIP backstage pass for every show in town.

After all, most website operators know that to block Googlebot is to disappear from Google. Consequently, to preserve their SEO rankings, these website owners will go out of their way to ensure unhindered Googlebot access to their site, at all times.

In practical terms, this may translate into exceptions to security rules and lenient rate limiting practices. At Incapsula, a month does not go by without our coming across hackers hoping to exploit these loopholes to improve their chances of success.

Extremely Popular DDoS Tools

Drilling down into our security logs, we were able to see just how Fake Googlebots are employed.

By observing recent data, collected from over 50 million Fake Googlebot sessions, we saw that 34.3% of all identified impostors were explicitly malicious, with 23.5% of these bots used for Layer 7 DDoS attacks.

Googlebot is an Extremely Popular DDoS Tools

‘Other purposes’ are suspicious, yet not not downright malicious, activities.

These numbers make all sorts of sense because DDoS is just the situation where Googlebot’s ID can come in handy, particularly in the case of security solutions that still rely on rate limiting instead of case-by-case traffic inspection. Website operators who use such solutions are unable to identify real Googlebots from fakes. As a result, when the attack bells go off, they are presented with a harsh “all or nothing” dilemma: to block all Googlebot agents and risk loss of traffic, or to allow all Googlebots in and suffer downtime.

With DDoS events that can last for days, weeks or even months, each of these alternatives is extremely damaging for the target, making the attack a success – either way.

The good news is that Fake Googlebots can be accurately identified using a combination of security heuristics, including IP and ASN verification – a process which allow you to identify bots based on their point of origin.

Still, even these practices rely on excessive processing power and software capabilities not typically available to the regular website owner.

A few months ago, in our ‘DDoS Threat Landscape’ report, we showed that Fake Googlebots are the 3rd most commonly used bot in DDoS attacks. The reason for this popularity is the very dilemma described above.

Fake Googlebot DDoS attack: 1,446 Requests per Second (RPS) originating from 262 attacking IPs.

Fake Googlebot DDoS attack: 1,446 Requests per Second (RPS) originating from 262 attacking IPs.

Spread Around the Globe

Fake Googlebot visits originate from botnets – clusters of compromised connected devices (e.g., Trojan infected personal computers) exploited for malicious purposes.

Looking at the sources of Fake Googlebot visits, we can identify the locations of some of these botnets. The list consists of many of the usual suspects, with the US, China, Turkey and India still claiming four of the top five spots, just as they were several months ago when we were compiling data for our ‘DDoS Threat Landscape’ report.

Googlebots’ Country of Origin Share of Visits
US 25.16%
China 15.61%
Turkey 14.7%
Brazil 13.49%
India 8.4%
Thailand 4.07%
Other 4.07%

However, we were a bit surprised to find Brazil squeezing into the 4th place, as the origin of 13.49% of all recent Fake Googlebot visits.

Does this have something to do with the World Cup? We can’t honestly say. Still, these numbers may have something to do with the myriad Internet devices brought into the country by 1 million tourists, some of whom probably should pay more attention to what they download.


We will continue to keep an eye on Fake Googlebot escapades. In the meanwhile, you canclick here to learn more about Dr. Crawlit – the original Googlebot .

Mr. Hack: Googlebot’s Unruly Alter Ego

Advertisements

Configuring the ModSecurity Firewall with OWASP Rules

In today’s world, over 70% of all attacks carried out over are done so at the web application level, so we need to implement security at multiple levels, as organizations need all the help they can get in making their systems secure. Web application firewalls are deployed to establish an external security layer that increases security and detects and prevents attacks before they reach the web application. One of the more commonly used application layer firewalls is ModSecurity, which is an open source intrusion detection and prevention system. In order to make ModSecurity more useful, it must be configured with rules. These rules can be created by us according to need, or we can use the Open Web Application Security Project (OWASP) rules.

OWASP is a group of security communities that develops and maintains a free set of application protection rules, which is called the OWASP ModSecurity Core Rules Set (CRS). You can think of OWASP as an enhanced core rule set that the ModSecurity will follow to prevent attacks on the server.

So, in this article we will configure the ModSecurity Firewall with the OWASP Core Rule Set. We will also learn how we can customize the OWASP Core Rule Set according to need or create our own customized rule set in later articles. We are assuming that you have basic knowledge about the Linux commands and the Apache server.

The process of getting started in ModSecurity with OWASP rules might seem like a lot of work, but it’s actually quite simple. Let’s look at the installation and configuration process in a CentOS environment. This can be done through the following steps:

Step 1

Login into your server as a root user. We can use Putty or any other SSH client for the log in. After login, we have to install some dependency packages before the installation of mod security. This package can be installed through the following command:

yum install gcc make libxml2 libxml2-devel httpd-devel pcre-devel curl-devel –y

Step 2

After installing the dependency packages, we will install ModSecurity, which is the main package required for the firewall. We can install it by running the following command in the terminal:

yum install mod_security –y

Now the ModSecurity package has been successfully installed in the system.

Step 3

After installing ModSecurity, we need to restart the Apache server to apply affected changes. For that we will have to restart the HTTPD service, which is the default service for RHEL/CentOS/Fedora, and it is located in the /etc/httpd folder. We can do this by the following command.

Services httpd restart

OR

/etc/init.d/httpd restart

The message [ OK ] is displayed, which means that HTTPD is restarted without having any errors.

Now we have successfully installed ModSecurity in the server, and the next step is to download and configure the OWASP ModSecurity rules. In order to do that, we have to change the current working directory to /etc/httpd. This can be done through the cd command.

cd /etc/httpd.

Step 4

As we mentioned at the top of the article, our ModSecurity installation is good enough, but we will need to enhance our rule set with the help of the OWASP Core Rule Set. This can be done through the Github website. Github is an open source platform where many developers share their projects and applications. To download any content from the Github server, the git command is used with the clone option. So, we will import predefined OWASP ModSecurity rules by SpiderLabs to our server. We can do this through the following command.

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

After executing the command, OWASP ModSecurity rules will be downloaded in the owasp-mod security-src directory. It can be checked by the ls command as follows.

Now, we have to rename owasp-mod security-crs folder to mod security-crs. This can be done by the mv command.

mv owasp-modsecurity-crs modsecurity-crs

We can verify that by running the ls command.

Step 5

We have to change the working directory to mod security-crs. This can be done by the cd command.

cd modsecurity-crs

Modsecurity_crs_10_setup.conf is the main configuration file for ModSecurity to work. By default it comes with .example extension. To initialize ModSecurity, we have to rename this file. We can rename it by the mv command.

mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Affected changes can be seen by the ls command.

Step 6

After that, we have to add the module in the Apache configuration file. The Apache server loads modules on every start-up with it. So, to add ModSecurity to work with the server, we have to add this module in the httpd.conf file, which is defaultly located in the /etc/httpd/conf directory. We will use VI Editor to edit ascii text files on the server.

We need to type the following command in the terminal.

vi /etc/httpd/conf/httpd.conf

Copy/paste the following to the end of the file and save the file.

<IfModule security2_module>
Include modsecurity-crs/modsecurity_crs_10_config.conf
Include modsecurity-crs/base_rules/*.conf
</IfModule>

After saving the file we will have to restart the Apache server.

Step 7

Now ModSecurity has been successfully configured with OWASP rules, but to make it work according to our choices, we will have to make a new configuration file with our own rules, which is called the whitelist file. Through this file we can control the whole Mod- Security firewall as well as create own rules for ModSecurity. We will create this in modsecurity.d directory. Open/Create this file through the following command.

Vi /etc/httpd/modsecuirty.d/whitelist.conf

And copy the following rules in the file and save the file.

#Whitelist file to control ModSec

<IfModule mod_security2.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecDataDir /tmp
</IfModule>

Now, we save the file and restart the Apache server. Each line meaning is described below.

  1. SecRuleEngine is the security rule engine which accepts all the rules from modsecurity-crs directory. So we can set different rules according to requirements. To set the different rules are the following.

    SecRuleEngine On: Will activate the ModSecurity firewall for the server. It will detect and block any malicious attack on the server.

    SecRuleEngine Detection Only: If this rule is set in the whitelist.conf file, it will only detect all the attacks and generate errors according to the attacks, but it will not block anything on the server.

    SecRuleEngine Off: It will deactivate the ModSecurity firewall on the server.

  2. SecRequestBodyAccess: It will tell ModSecurity whether it will check the body of the request or not. It plays a very important role when a web application is configured in way where all data go in POST request. It has only two parameters, ON or OFF. We can set that according to the requirement.
  3. SecResponseBodyAccess: If this parameter is set to be On in the whiltelist.conf file, then ModSecurity will analyse the server response and do the appropriate action accordingly. It also has only two parameters, ON or Off. We can set it according to the requirement.
  4. SetDataDirectory: In this section we will have to define the ModSecurity working directory. This directory will be used by the ModSecurity for temporary purposes.

ModSecurity is now successfully configured with the OWASP rules. Now we will test the ModSecurity firewall against some of the most common web application attacks and will verify weather ModSecurity is blocking the attacks or not.

In order to do that, we will try to launch the reflected Cross Site Scripting (XSS) attack on the website in which we have configured ModSecurity. The most common XSS vulnerable field in a website would be the search box, in which a user could search anything on the website. If a malicious user tries to inject Java Script or HTML script in the search box, it will execute in the browser. We can type <script>alert(123)</script> in the search box. In a normal scenario (when we do not have any kind of application firewall on the server) it will show a popup message on the website if the website is vulnerable for XSS.

If ModSecurity has been configured on the server, it will block the XSS attack and redirect the user in a different place according to the server configuration as well as generate the error logs.

We can check the ModSecurity error logs in the following file.

/var/logs/httpd/error_logs

We can check the last updated lines in the file through the following command.

tail –f /var/logs/httpd/error_logs

The OWASP ModSecurity Core Rule Set (CRS) provide protections against the following category of attacks.

  • HTTP Protection – detectsviolations of the HTTP protocol and a locally defined usage policy.
  • Real-time Blacklist Lookups – utilizes 3rd Party IP Reputation.
  • HTTP Denial of Service Protections – defence against HTTP Flooding and Slow HTTP DoS Attacks.
  • Common Web Attacks Protection – detects common web application security attacks.
  • Automation Detection – detects bots, crawlers, scanners and other surface malicious activity.
  • Integration with AV Scanning for File Uploads – detects malicious files uploaded through the web application.
  • Tracking Sensitive Data – tracks credit card usage and blocks leakages.
  • Trojan Protection – detects access to Trojans.
  • Identification of Application Defects – alerts on application misconfigurations.
  • Error Detection and Hiding – disguises error messages sent by the server.

http://resources.infosecinstitute.com/configuring-modsecurity-firewall-owasp-rules/

References

Intro to DNS Poisoning

DNS poisoning is a technique that tricks a DNS server into believing that is has received authentic inforamtion when, in reality, it has not. It results in substitution of a false Ineternet provider address at the domain name service level where web addresses are converted into numeric internet provider addresses. It allows attacker to replace IP address DNS entries for a target site on a given DNS server with IP addresses of the server he/she controls. Attacker can create fake DNS entries for files with same names as that of target server.

The DNS provides a way for computers to translate the domain names we see to the physical IPs they represent. When you load a webpage, your browser will ask its DNS server for the IP of the host you requested, and the server will respond. Your browser will then request the webpage from the server with the IP address that the DNS server supplied.

To launch a DNS poisoning attack, follow these steps:
+ set up a fake website on your computer
+ Install treewalk and modify the file mentioned in the readme.txt to your IP address. Treewalk will make you the DNS server.
+ Modify the file dns-spoofing.bat and replace the IP address with your IP address.
+ Trojanize the dns-spoofing.bat file and send it
+ When the host clicks the Trojanned file, it will replace DNS-entry in her TCP/IP properties to that of your machine.
+ You will become the DNS server and her DNS requests will go through you

There are four types of DNS poisoning attacks using which you can compromise the target system:

+ Intranet DNS spoofing (local network)
When an attacker performs DNS poisoning on a locl area network (LAN), it is called intranet DNS spoofing. An attacker can perform intranet DNS spoofing attack with the help of the ARP poisoning technique. THis is usually conducted on a swithced LAN. To perform this attack, you must be connected to the LAN and be able to sniff the traffic or packets.
Once the attacker succeds in sniffing the ID of the DNS request from the intranet, he or she can send a malicious reply to the sender before the actual DNS server.

+ Internet DNS spoofing (remote network)
Internet DNS poisoning is also known as remote DNS poisoning. This attack can be performed either on asingle or multiple victims anywhere in the world. In order to perform this attack, you need to set up a rouge DNS server with a static IP address.
Internet DNS spoofing is performed when the victim’s system is connedted to the Internet. It is done with the help of Trojans. It is one of the MITM types of attacks, where the attacker changers the primary DNS entries of the victim’s computer. The attacker replaces the victim’s DNS IP address with the fake IP address that refers t the attacker’s system; thus all traffic will be redirected to the attacker’s machine. Now the aatcker can easily sniff the victim’s confidential information.

+ Proxy server DNS poisoning
In the proxy server DNS posoning technique, tha taattacker changes the proxy server setting of the victim to that of the attacker. This is done with the help of a Trojan. This redirects the victim’s request to the attacker’s fake website where the attacker can sniff the confidential information of the victim.

+ DNS cache poisoning
The DNS system uses cache memory to hold the recently resolved domain names. It is populated with recently used domain names and respective IP address entries. When the user request comes, the DNS resolver first checks the DNS cache; if the domain name that the user requested is found in the cache, then the resolver sends its respective IP address quickly. Thus, it redueces the traffic and time of DNS resolving.
Attacker target this DNS cache and make changes or add entries to the DNS cache. The attacker replaces the user-requested IP address with the fake IP address. Then, after when user requests that domain name, the DNS resolver checks the entry in the DNS cache and picks the matched entry. Thus, the victim is rediirected to the attacker’s fake server instead of the authorized server.

*** How to defend against DNS spoofing:
Resolve all DNS queries to local DNS servers
Block DNS requests from going to external severs
Implement DNSSEC
Configure the DNS resolver to use a new random source prot from its available range for each outgoing query
Configure the firewall to restrict external DNS lookup
Restrict the DNS recuring service, either full or partial, to authorized users
Use DNS Non-Existent Domain rate limitng
Secure your internal machines
Implement IDS and deploy it correctly
Use static ARP and IP table
Use SSH encryption
Use sniffing detection tools
Do not open suspicious files
Always use trusted proxy sites
Audit your DNS server regularly to remove vulnerabilities

Hope you have found this short article useful!

Photo: Intro to DNS Poisoning

DNS poisoning is a technique that tricks a DNS server into believing that is has received authentic inforamtion when, in reality, it has not. It results in substitution of a false Ineternet provider address at the domain name service level where web addresses are converted into numeric internet provider addresses. It allows attacker to replace IP address DNS entries for a target site on a given DNS server with IP addresses of the server he/she controls. Attacker can create fake DNS entries for files with same names as that of target server.

The DNS provides a way for computers to translate the domain names we see to the physical IPs they represent. When you load a webpage, your browser will ask its DNS server for the IP of the host you requested, and the server will respond. Your browser will then request the webpage from the server with the IP address that the DNS server supplied.

To launch a DNS poisoning attack, follow these steps:
+ set up a fake website on your computer
+ Install treewalk and modify the file mentioned in the readme.txt to your IP address. Treewalk will make you the DNS server.
+ Modify the file dns-spoofing.bat and replace the IP address with your IP address.
+ Trojanize the dns-spoofing.bat file and send it
+ When the host clicks the Trojanned file, it will replace DNS-entry in her TCP/IP properties to that of your machine.
+ You will become the DNS server and her DNS requests will go through you

There are four types of DNS poisoning attacks using which you can compromise the target system:

+ Intranet DNS spoofing (local network)
When an attacker performs DNS poisoning on a locl area network (LAN), it is called intranet DNS spoofing. An attacker can perform intranet DNS spoofing attack with the help of the ARP poisoning technique. THis is usually conducted on a swithced LAN. To perform this attack, you must be connected to the LAN and be able to sniff the traffic or packets.
Once the attacker succeds in sniffing the ID of the DNS request from the intranet, he or she can send a malicious reply to the sender before the actual DNS server.

+ Internet DNS spoofing (remote network)
Internet DNS poisoning is also known as remote DNS poisoning. This attack can be performed either on asingle or multiple victims anywhere in the world. In order to perform this attack, you need to set up a rouge DNS server with a static IP address.
Internet DNS spoofing is performed when the victim's system is connedted to the Internet. It is done with the help of Trojans. It is one of the MITM types of attacks, where the attacker changers the primary DNS entries of the victim's computer. The attacker replaces the victim's DNS IP address with the fake IP address that refers t the attacker's system; thus all traffic will be redirected to the attacker's machine. Now the aatcker can easily sniff the victim's confidential information.

+ Proxy server DNS poisoning
In the proxy server DNS posoning technique, tha taattacker changes the proxy server setting of the victim to that of the attacker. This is done with the help of a Trojan. This redirects the victim's request to the attacker's fake website where the attacker can sniff the confidential information of the victim.

+ DNS cache poisoning
The DNS system uses cache memory to hold the recently resolved domain names. It is populated with recently used domain names and respective IP address entries. When the user request comes, the DNS resolver first checks the DNS cache; if the domain name that the user requested is found in the cache, then the resolver sends its respective IP address quickly. Thus, it redueces the traffic and time of DNS resolving.
Attacker target this DNS cache and make changes or add entries to the DNS cache. The attacker replaces the user-requested IP address with the fake IP address. Then, after when user requests that domain name, the DNS resolver checks the entry in the DNS cache and picks the matched entry. Thus, the victim is rediirected to the attacker's fake server instead of the authorized server.

*** How to defend against DNS spoofing:
Resolve all DNS queries to local DNS servers
Block DNS requests from going to external severs
Implement DNSSEC
Configure the DNS resolver to use a new random source prot from its available range for each outgoing query
Configure the firewall to restrict external DNS lookup
Restrict the DNS recuring service, either full or partial, to authorized users
Use DNS Non-Existent Domain rate limitng
Secure your internal machines
Implement IDS and deploy it correctly
Use static ARP and IP table
Use SSH encryption
Use sniffing detection tools
Do not open suspicious files
Always use trusted proxy sites
Audit your DNS server regularly to remove vulnerabilities

Hope you have found this short article useful!

 

 

Dirty Dozen Spampionship – which country is spewing the most spam?

New search engine Indexeus unmasks malicious hackers

Cisco warns of big remote management hole in tiny routers

FBI — Botnets Infecting 18 Computers per Second. But How Many of Them NSA Holds?

Botnet malware tool hacking
 
Botnets – a secretly compromised networks of ordinary home and office computers with rogue software or “malware” that are controlled by an individual criminal or a group – has dramatically increased over the past several years and are considered to pose the biggest threat to the Internet.
 
Cyber criminals have brushed-up their hacking skills and are using Botnets as a cyber weapon to carry out multiple crimes like DDoS attacks (distributed denial of service), mass spamming, page rank and advertising revenue manipulation, mining bitcoins, cyber espionage and surveillance etc.
 
18 BOTNET INFECTIONS PER SECOND
According to the director of FBI’s cyber division, Joseph Demarest, Botnet has become one of the biggest enemies of the Internet today, and therefore its impact has been significant. Yesterday during a hearing before a U.S. Senate committee, he says that every second 18 computers worldwide are part of botnet armies, which amounts to over 500 million compromised computers per year.
 
The network of compromised systems can do a drastic cyber crime activities without the knowledge of their computer’s owner. Botnet allows its operator to steal personal and financial information, get into system owners’ bank accounts, steal millions of credit cards, shut down websites, monitor your every keystroke and can even activate systems’ cameras secretly which can take users’ at great risk.
 

On Tuesday, a U.S. Senate committee assembled to discuss the progress of FBI agency’s current and future anti-cyber crime strategy to disrupt Botnets, with agenda: “Taking Down Botnets: Public and Private Efforts to Disrupt and dismantle Cyber Criminal Networks.
 
BOTNET FETCHED MILLIONS OF DOLLARS
Joseph Demarest said the news is troubling as the botnets’ high infection rate costs the US and global economies billions of dollars. Several successes “But our work is never done,” noted the FBI chief.
The use of botnets is on the rise. Industry experts estimate that botnet attacks have resulted in the overall loss of millions of dollars from financial institutions and other major US businesses,” Demarest said.
As you well know, we face cyber threats from state-sponsored hackers, hackers for hire, organized cyber syndicates, and terrorists. They seek our state secrets, our trade secrets, our technology, and our ideas—things of incredible value to all of us.
TWO FACES OF THE SAME GOVERNMENT – FBI & NSA
FBI trying to take down cyber criminals and putting its all effort to shut down botnet networks – which really sounds cool! But could you answer me that ‘How NSA is conducting its wider spread mass surveillance program..??’ Yes, of course, with the use of similar exploits and botnet malware. It was revealed few months ago from the Edward Snowden leaks that NSA is taking over entire networks of already-hacked machines (Botnets) and using them for their own purposes.
 
Also at the end of last year, Dutch newspaper NRC Handelsblad reported that the document leaked by Snowden also revealed that NSA had established an army of “sleeper cells” – malware-infected, remote-controllable computers – on 50,000 networks by the middle of 2012, which waits for months or longer before it activates by the agency and begins harvesting data.
 
So, when one side of U.S. government is trying every effort to shut down the widely spread botnet networks and at the same time, the other side of government is building up their weapons with the use of similar malwares and botnets, it is difficult to mitigate the problem and, this unbalanced situation of the Internet is the main cause of terror in the digital world.
 
Well, botnets, malware, viruses, worms and other cyber threats are really a big issue for all of us, and also these attacks become more sophisticated and wider when become money motivated.
 
We also appreciate U.S. government efforts to combat cyber crimes. A month ago, FBI and Europol also took down the GameOver Zeus botnet that have stolen more than $100 million from banks, businesses and consumers worldwide.
 

CNET website and 1 million passwords compromised by Russian hacker group

17-year-old Arrested for Massive DDoS Attack on Norway’s Financial Sector

17 year old Anonymous Arrested DDoS Attack
The Norwegian police have arrested and charged a 17-year-old for a massive distributed denial-of-service (DDoS) attack earlier this week that disabled the websites of major financial institutions and other businesses in the country.
 
Distributed Denial of Service (DDoS) attack is designed to sabotage, shut down and overload the targeted website with web traffic more than its capacity in order to make it unavailable to users. The attack targeted five major banks, two telecommunication firms, three airlines and one insurance company, as their websites and online payment systems were disrupted.
 
The unnamed teen claimed to be a part of the hacktivist group Anonymous Norway for what was thought to be the country’s biggest ever cyber-attack on businesses. Although, the Anonymous Norway, via a Twitter message, has dismissed any connection to him or the cyber attack.
 

The youngster was a resident of Bergen, on Norway’s west coast. He was arrested on Thursday morning and questioned by police in Bergen, while he was sitting in front of computer.
 
The teenager sent a letter to the media on the day of the attack, claiming to be part of Anonymous and saying that “the motivation behind the current attacks and the next attacks in the future is to get the community to wake up. The number of major IT security attacks is increasing and there is nothing being done to prevent such events.
 
Despite his claim, the authorities do not suspect him to be a part of the Anonymous Norway neither suspect the group involved in the DDoS incidents, because of the fact that the suspect joined the group’s Facebook page on the same day of the attack, may be in an effort to show himself linked with the group. Furthermore, the hacker provided a Pastebin link via a tweet, pointing to the identity of the perpetrator i.e. “Jamie Y. Isaksen“; they did not create the post, just scooped it up.
 
Police chief, Frode Karlsen, said to the newspaper Bergens Tidende, who reported the news first: “He could have had help, but we don’t think that he is a part of an organized group. We do not have any proof of this right now.
 
At the time, the teen was charged with gross vandalism, which carries a maximum prison sentence of up to six years in Norway and, since the suspect has no past criminal record and is legally still a minor in Norway, his punishment is likely to be much lighter.

[The youth] is charged for causing malicious damage, but the charge could be extended. The maximum penalty for such a crime is six years,” said Karlsen, claiming that the police were taking the case very seriously, “This sort of attack can have huge costs for society,” Karlsen told Norwegian Broadcasting (NRK). “They also, for example, can mean that folks can’t manage to reach emergency services if they need help.

The attack was the ever largest in the country’s history and aimed at disrupting the online services of major financial institutions in Norway, including Norges Bank, Telenor, DNB, Sparebank 1, Storebrand, Gjensidige, Nordea, Danske Bank and IT company Evry, as well as other business such as Scandinavian Airlines (SAS) and Norwegian Air.
 

Up ↑