Airborne cyber attacks against drones have been conducted by hackers, criminals and state-sponsored actors. Unmanned Aerial Vehicles (UAVs) – also known as “drones” – are gaining popularity in many sectors of society. Pioneered by the military, law enforcement as well as criminals have used them. Hobbyists gather to race while retail stores will soon ship purchases with these. To reach the market quickly, security is often an afterthought. Vendors and operators underestimate the intent and capability of hackers to target their products. Thus researchers took up the challenge of showing their vulnerabilities. Reviewing current security issues and past incidents highlight the issues and their solutions before critical failures in drones causes harm. However before doing so, let’s quickly study the basic inner workings of drones.
Drones: How do they work?
Drones range from the highly complex multi-million dollars military aircraft to the toy models available for a hundred dollars. Despite this disparity, their overall architecture can be divided into 1) the aircraft and 2) the ground station. The aircraft regroups sensors and controllers needed to fly while the ground station includes software and hardware to send commands wirelessly. The ground station includes wireless transceivers, flight planning software, aircraft maintenance applications and the operators. The aircraft hosts the flight controller which processes data from sensors, avionics, communications, autopilot systems and in some cases, weapons.
Operators send navigation commands via a Remote Controller (RC), which relay information via a Line-of-Sight (LOS) communication channel. In low-end drones, standard wireless networking protocols are used while higher-end ones leverage satellite communications. Data from the ground station is transmitted to receivers or the aircraft and processed by the flight controller. The controller manages the outputs from various sensors including the GPS receiver, camera and propellers. Audiovisual data is relayed to the ground station via a second communication channel or stored on removable medias. Predefined routes can be programmed using flight planning software to make the aircraft autonomous.
Cyberattacks against Drones
Communication channels are the obvious attack vector. Unfortunately calls for encryption are often downplayed and proprietary protocols, despite some may believe, are not safe from reverse engineering and hijacking. In 2009, Iraqi militants found out that unencrypted videos feed from U.S. drones were available by pointing a satellite receiver towards the drone, greatly compromising operational effectiveness. While secure channels are critical, weak encryption is as good as no encryption. It was discovered in 2015 that scrambled video feeds between Israeli UAVs and ground stations were easily decrypted using open-source software. An attacker only required knowledge of the proper frequencies. That being said, even good encryption is no remedy when employed with vulnerable key management systems. A fact rarely discussed by security vendors pitching solutions.
Lower end drones have been hacked via known vulnerabilities in wireless networking protocols. SkyJack is an air-to-air network attack drone that detects surrounding wireless connections of vulnerable drones and reroutes them to itself, allowing the remote operator to to hijack the target. This deauthentification technique used is similar to the one seen against home wireless networks. Other attacks included cracking WEP networks between the flight planning software and the remote controller, allowing the intruder to issue commands to the remote controller.
Communicational channels are not the only weak points. Drones require information from their environment in order to navigate. The information is captured by the sensors and transmitted to the flight controller for processing. Therefore providing invalid inputs to the sensors will disrupt the aircraft. Invalid GPS data is one of the explanation for the unexpected landing of a U.S. RQ-170 sentinel in Iran. The Iranian military maintain they spoofed GPS data by broadcasting stronger signals than the ones from valid GPS satellites. By doing so they forced the sentinel to land. Such an attack was proven possible on other models. The second theory is that an internal malfunction forced an emergency landing. In either case, this incident highlighted two issues: implicit trust of sensory data sources and unexpected effects of internal errors.
Security is not only about networks; it’s also about robustness of the internal software. MalDrone is a malware compiled for ARM Linux which allows to spawn a remote shell on the target drone. The attacker intercepts an unencrypted channel between the ground station and a vulnerable aircraft to upload the malware, allowing direct access to the operating system (OS). An alternative tactic could aim to modify the firmware of the flight controller or sensors. Users rarely validate the integrity of the firmware downloaded online, allowing backdoors to be injected via man-in-the-middle attacks. Hackers may leverage social engineering to send malicious updates or exploit a vulnerability to execute arbitrary code and gain remote access to the drone. Like many Internet-of-Things (IoT) devices, drones are seldom updated by their owners and could remain vulnerable for a long period of time.
As drones continue to find increased usage in civil society, they will be subjected to further analysis. Engineers and operators should never underestimate both the capability and intent of malicious actors to target their product either for fun, profit or other malicious goals. Lessons learned by the software industry remain mostly unimplemented:; lack of secure communications, no firmware integrity validation, loose or absent security controls and slow patching of critical vulnerabilities. The success of the Mirai botnet is a result of these failings and drones are not exempt. Unlike the distributed denial of service observed, compromised drones may raise safety concerns and must therefore be secured.
Philip Gabriel Pettersson, best known by the pseudonym of “Stakkato” can be said to have reached legendary status within the computer security community by his numerous successful breaches of high-level targets between 2003 and 2005. Then a 16 year-old hacker from Uppsala, Sweden, he successfully infiltrated systems of large universities, the United States military, NASA and various companies, forming a worldwide network within which he operated for around 2 years before being caught in 2005 and prosecuted by Swedish authorities. This post revisits the story of Stakkato by reviewing his motivation, techniques and exploits and potentially unearth some lessons learned from these events.
Uppsala is the fourth largest city of Sweden and is situated around 70km north of the capital. In 2003, one of its curious and smart teenager went on to challenge himself by exploring – illegally – the digital environment surrounding the city. Some of us might remember the old definition of a “hacker”, as defined by The Mentor’s manifesto. Back in 2003, owning a computer was still not totally commonplace, although it was a lot more than it in 1995. Only teenagers with a certain sense of interest and curiosity about technology would consider spending most of their time on their machines. In my corner of the world, in the 90s, computer science classes were nothing more than learning to type, using word processors and creating spreadsheets. I am sure I was not the only one in the same situation and some readers may remember the frustration of not being able to pursue their hobby in depth while in school. So we spent most the classes programming VBA games or spamming other students using WinPopup to have them call out the teacher, who would struggle to explain the innocuous messages on the screen. Only at night could we connect to the net, login into our favorite BBS, IRC channels or forums to finally learn more. Virtualization was not a thing back in the early 2000s, internet connections were still slow and owning more than 1 computer was a luxury most couldn’t afford. A solution was dumpster diving around computer shops – which were aplenty compared to nowadays – or browsing eBay for scraps. Another one was to poke around systems connected to the internet. Universities were of course perfect targets – opened, poorly secured (in order to be opened) and rich with systems, software and data.
Why am I rambling about the past? Because in many ways, Stakkato may have been the same teenager than many of us were back then, but his cockiness eventually got the better of him and caused his demise. Some even proposed that by 2005, he may have attempted to venture into criminal activities by selling stolen intellectual property. In any case, let’s explore briefly his story, because I believe many who now heads IT security companies, or experts and researchers in the field all shared the same starting point, but fortunately took a different path at some point.
The Stakkato Hacks
The first suspicions of wrongdoing were noticed in 2004. Berkeley researcher Wren Montgomery started receiving email from Stakkato, claiming that not only did he infiltrated her university, but that he also accessed the network of White Sands Missile Range in New Mexico, stole F-18 blueprints from Patuxent River Naval Air Station and infiltrated NASA’s Jet Propulsion Laboratory (JPL) – which to be honest, have been hacked by many in the past decade , almost making it an initial test for debuting hackers. These claims were later confirmed by spokesmen from both organizations. They however downplayed the importance of these breaches, claiming that there were low-level breaches and that only weather information was exfiltrated. Later during the year, several laboratories harboring supercomputers connected via the high-speed network TeraGrid reported breaches. However it was only in 2005, with the intrusion in networking company Cisco Systems, that would trigger alerts from authorities and proved to be a bridge too far. Having established a foothold within Cisco, Stakkato was able to locate and download around 800MB of source code of the Internetwork Operating System (IOS) version 12.3 . IOS runs on every Cisco routers and other networking devices which are often key network component of not only large commercial and governmental organizations, but also of the worldwide telecommunication infrastructure. Samples of the code was released on IRC as proof and reported by a Russian security site. The theft of the code caused a stir, many believing that individuals or groups would comb the code and craft zero-day exploits that could be leveraged on critical systems.
This activity would prove the last Stakkato and his team would be able to brag about as the Federal Bureau of Investigation (FBI) and the Swedish authorities started to investigate the leaks. In 2007, he was convicted for breaching networks Swedish universities and paid 25,000$USD in damages. He was further interviewed by U.S. officials and in May 2009, he was formally inducted in California for intrusions in Cisco Systems, NASA’s Ames Research Center and NASA’s Advanced Supercomputing Division . In 2010 his prosecution was transferred to the Swedish authorities.
The core strategy of Stakkato revolved around a trojanized SSH client he uploaded to systems he compromised. The malicious client would be used to intercept users’ credentials and send them to a third location where Stakkato and his group would retrieve them to access additional systems. Once accessed, Linux kernel exploits were used for privilege escalation on the local system and then repeated their main tactic, creating privileged accounts and eventually building a wide network of proxies to launch their attacks. The attack on the National Supercomputer Centre  provides insight on the tactics and size of the compromises. The methodology used was not innovative by any mean, but was applied effectively and certainly leveraged human errors to its full extend. The process can be summarized as follow:
Infiltrate a system via a kernel vulnerability or stolen credentials;
Disable command history, e.g prevent the system from logging your commands;
Attempt privilege escalation;
Setup trojanized SSH clients, backdoors and rootkits;
Extract known hosts from current machine;
Attempt to infiltrate extracted hosts as per step 1.
The analysts of the NSC documented logins from universities the United States, Israel and Sweden and referenced the SuckIt rootkit as being installed on one of the target machine. Unfortunately for the administrators, the rootkit was discovered only after a new root password was assigned to all machines, allowing the attackers to re-infiltrate the newly cleared systems. However this time the Swedish teenager was a lot less subtle and vandalized the systems by attempting a web defacement and modifying logon messages. This time the IT specialists took down the network, inspected and reconfigured every machine before putting the system back online. Despite the defensive operation, recurring login attempts and smaller-scale compromised originating from more than 50 compromised organizations were noted between 2003 and 2005.
This story follows the same pattern observed throughout the ages, such as sprawling empires from ancient times in which the rulers’ overconfidence led them to bankruptcy, or growing organizations that stretched into markets that proved more difficult than expected. Stakkato’s network of compromised systems grew too large, he became overconfident and tempted the sleeping bears. In other words, patience may have led him to a very different path. Or maybe his arrest was for the best afterall: there is little news about him past 2010, but coincidently there is a security researcher working in Samsun bearing the same name and credited multiple vulnerabilities in the Linuxkernel. While I have no idea if this is the same individual, I would be glad to hear that he now uses his skills fruitfully.
Arguably another lesson is how simple tricks can still work if applied efficiently. All things considered, security hasn’t changed dramatically within the past 10-15 years: it has evolved, but in the end, we still rely on usernames and passwords, users’ awareness and administrators properly maintaining their networks and hosts. Humans using these systems haven’t changed much either; we will take the simplest approach to achieve our goals. Hence we select the easiest password passing the complexity filters in place and reuse it so we don’t have to remember 100 variations of the same password. Large database compromises in the past few years appears to prove this behavior. We could have many passwords and store them in password managers, but then the password managers can still be trojanized or exploited, allowing similar tactics used by Stakkato. Eventually most people would probably not bother to execute an additional program to retrieve their password in order to login in the service they need; it simply adds an additional step.
Studying the past of computer security is sometimes quickly dismissed, often seen as irrelevant given the change in technologies, but one can easily find inspiration in the stories of hackers, malware writers and the analysts that battled to gain and maintain control of systems. Much like studying the battles of Alexander the Great or Patton, there is much to be learned from studying the techniques used and wargaming their applications in modern organizations. Would the current administrators blindly enter their passwords if a windows suddenly popped up requesting their credential for some update? Users still get fooled by fake login web pages  and end up with their bank accounts plundered or their Twitter account spewing nonsense to all their followers. It still works.
This document analyzes the use of the cyber environment in the Syrian civil war by both the population and the government in order to characterize online tactics and strategies developed and used by each belligerent.
This is an article I wrote a while ago and never got published. It’s a bit outdated now, but I still think it can be useful for historical purposes, so I’ll post a link to it below.
This document analyzes the use of the cyber environment in the Syrian civil war by both the population and the government in order to characterize online tactics and strategies developed and used by each belligerent. This overview allows for generalization of online behavior by hacktivists and nation-state sponsored actors on communication networks in the region, which will continue to see online attacks from various parties in the foreseeable future during similar conflict. In Syria, because of poor infrastructure, low rate of Internet penetration and early adoption of control mechanisms by the current government, the authorities had dominance over their information environment early in the conflict, enabling rapid gathering of intelligence on dissidents. While social medias were leveraged by the population as in many other uprisings for coordination, it was also the theater of multiple offensive cyber operations by internal and external groups, mostly for information operations purposes. Despite the high level of activity, none appeared to have a definitive impact on the ground. While events recorded in this space have not reached the level of intensity of other conflicts, it proves a useful model for similar conflicts in the Middle East region.
The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures.
I have not written or contributed to the enclosed research paper. I’m simply reposting it here because it’s interesting and for some reason, appears available only via Google cache. So before it disappear from results, I’m reposting it here.
This paper discusses a technique to conduct buffer overflows on processors using the Harvard architecture. In this architecture, the stack starts at the beginning of the memory and grows up, versus Von Neumann architectures in which it grows down.
Most small embedded devices are built on Harvard class microprocessor architectures
that are tasked with controlling physical events and, subsequently, critical infrastructures. The Harvard architecture separates data and program memory into independent address spaces, as opposed to the von Neumann architecture that uses a unified memory system with a single address space for both data and program code. The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures. In this paper we show that stack-based buffer overflow vulnerabilities exist in embedded control devices based on the Harvard class architecture. We demonstrate how a reversal of stack growth direction can greatly simplify the attack and allow for easier access to critical execution controls. We also examine popular defense techniques employed in server and desktop environments and the applicability of those defenses toward Harvard class machines.
In this post, we continue our data collection and evaluation of files stored on removable medias publicly accessible to the Internet. The collection of filenames from 6,500 hosts is ongoing, therefore we’re going to focus on evaluation of sensitivity of a file based only on its filename. We also present the latest statistics collected in our database.
In this post, we continue our data collection and evaluation of files stored on removable medias publicly accessible to the Internet. The collection of filenames from 6,500 hosts is ongoing, therefore we’re going to focus on evaluation of sensitivity of a file based only on its filename. Based on the current result, 2 to 9% of the 3000 files reviewed were sensitive or potentially sensitive. Most of the sensitive files are concentrated on a few hosts. These files often include financial information or project data from businesses. So far, 773 hosts containing around 4.5 million files have been scanned.
The amount of filenames collected is quite large and we cannot evaluate manually each filename for its probable sensitivity. As such, we need to devise a procedure to automatically assess its sensitivity. We have some definitions and restrictions to list first to clarify what a sensitive file is and limitation to our evaluation criteria.
In this document, sensitive file refers to user-generated or software-generated files based on user input that contains information that should probably not be publicly accessible and which can be leveraged against an individual or organization. This includes:
Personal identification documents; passport, driver’s license, visas, government forms…
Personal finance documents; income tax files, insurance forms, credit card statements, mortgage, pay stubs, banking information
Personal medical documents; prescriptions, medical records
Business finances; customer lists, sales data, project costs, business deals, investments, payrolls
Intellectual property; blueprints, schema, patents, research
Network configuration; passwords files, configurations files, network diagrams, user databases
Large databases of emails, addresses and other personal information.
Some of the files not included in our analysis that includes;
Copyrighted / Illegally downloaded files. However we considered text file containing licensing keys to be sensitive.
Inappropriate contents (nude selfies, personal politics, group affiliations etc…)
Personal pictures, letters.
Addresses and emails were not considered personal, however databases of addresses and emails are considered sensitive
Because of the volume, we cannot download and manually verify each file to confirm its contents, as such our main restriction is that our assessment must be done solely based on the absolute filename recorded. As such, to evaluate the sensitivity, we used three categories; positive, negative and neutral, i.e. either a file is very likely to sensitive, potentially sensitive or clearly not sensitive at all. Of course, there is always a possibility that a file labeled as sensitive may not be. For example, a file called social security numbers.xls may contain only formulas or an empty form. Ideally, files identified as positive or neutral should be manually vetted.
The procedure to automatically assess the sensitivity of a file based on its path and name is first done by assessing a random sample manually. Using the ORDER BY RANDOM (note: there will be a need to review if this function is truly random, which I doubt) function (performance is not an issue in this experiment) of the Postgresql database, multiple random samples of 100 filenames are retrieved from the database. Each file is shown to the evaluator which based on the path, filename and extension assess the sensitivity of the file as ‘positive‘, ‘neutral‘, ‘negative‘. For each run, we log the count of hits for all categories.
Listing 1 : Example of a run in which a script asks an evaluator to assess the sensitivity of files based on its absolute path.
The evaluator is assessing the filename based on keywords that may indicate the contents of the file. As such, a file containing the word, or as we call it in this document, a token such as sales, passport or passwords will be assume to contain information about sales, a passport scan or a list of passwords. In many cases, the filename is too obscure, but the path and extension may indicate the contents of the file. For example, a path containing the tokens project, finances and a Microsoft Excel extension despite a filename of axe189212_c.xls will be considered as neutral, as the file may contents information about a project. Examples of both scenarios are shown in listings 2 and 3:
Listing 3 : Examples of files that were deemed ‘neutral’ (or ‘unknown’) hits based on keywords in their absolute path.
Filenames in foreign languages are roughly translated using Google Translate, as such, many of them are labeled as unsure.
A Python script then divide the filename in tokens, and each token is stored in the database along with the number of times it was found in a positive, neutral and negative hit. Tokens are created slightly differently based if they are located in the path, the filename or in the extension. For the extension, a single token is created which contains the extension itself. If the file does not have an extension or is not an extension usually associated with known software, no token is created. For the filename, tokens are created by splitting each word using characters usually known to separate words such as the underscore, dash, period or spaces. Lastly, for the path, directories are used as token and unlike filenames, are not split further. An example of this process is shown in listing 4:
File:/My_Passport(1)/Name of Company/Owner/ASUSLAPTOP/Data/C/Users/Owner/Documents/Forms/Letter of Understanding forSub-contractors(2015_03_2416_00_01UTC).docx
Path=>/My_Passport(1)/Name of Company/Owner/ASUSLAPTOP/Data/C/Users/Owner/Documents/Forms/
File=>Letter of Understanding forSub-contractors(2015_03_2416_00_01UTC)
Tokens(Path)=["My_Passport(1)","Name of Company","Owner","ASUSLAPTOP","Data","C","Users","Documents","Forms"]
Listing 4 : Example of the tokenization of a filename.
Once the tokens are created, the script will either add the token in the database or update its count based on the evaluator choice. After each update, a score is given to the token, which is simply the ratio between positive hits and the total count of appearances: p / hits). Note that tokens are considered different depending their location in the filename. As such, a filename such as /My_Passport/backup/Outlook emails backup.pst, will generate 2 distinct ‘backup’ tokens; the one from the path and the one from the filename. We explain this decision in the next paragraphs.
Listing 5 : Scores of the tokens extracted from the file in listing 4.
By using this procedure, we believe that tokens appearing often in both positive and negative hits will cancel each other, while the tokens strongly associated with positive and negative hits will remain clearly divided. Some sort of mathematical should follow later one (I hope…need to review discrete maths I guess). Some preliminary results appears to confirm this approach as valid. Extensions strongly associated with sensitive contains higher scores while media files have null scores.
However, there is a need to further refine this process by associating a value, or weight, to the location of the token. Tokens in the path are not as indicative of the sensitivity of the file as much as a token in the filename or extension. Even within the path, the highest level is generally less indicative than the lowest one, i.e. /documents/finances 2012/sales/company sales.xls. Therefore when assessing a new filename, we need to give a score to the path, the filename and the extension. For the path, we will get the score of each token and multiply it with a weight that correspond to its location in the structure. For token that are not found the default value of 0 will be given. Then we will take the average of all token for the score of the path. As for the filename, we will not consider the position. Finally the stored score of the extension will be retrieved from the database. If the extension is not found, then a score of 0 will be used. This will transform a filename into a set of three real values which we can range between 0 and 1. To determine the weights needed for each location, we will used a supervised neural network. More research will be conducted to determine how to use this approach.
As of 16 July 2015, 4,568,738 files have been recorded from 773 hosts.
Table 1. Location of the 773 hosts scanned as of 16 July 2015 order by country.
Mp3 and JPEG image files remains the most common. As such, we focus our statistics on document-type of files for a change, i.e. Office documents. Adobe PDF files and Microsoft Word documents are the most common file types based on our current data as shown in figure 1.
At the moment, around 3000 files have been assessed (30 runs of 100 samples). For each run, we recorded the number of positives, neutral and negative hits and found them overall constant at each run. (see figure 2) However more details about the RANDOM function is needed to insure the randomness of the sample. This part may need to be redone. So far, between 2% and 9% of files scanned are considered sensitive or potentially sensitive (see figure 3). However we need to consider the concentration of these files to put this information into perspective. The 278 files identified as sensitive or potentially sensitive were located on 59 hosts, with one host accounting for 101 of these file. This indicates that files of interests for an attacker are likely to be concentrated on a few hosts.
As for tokens, we will have to consider the entire collection of filenames in order to have sample from multiple sources, as such, we will pursue manually assessing samples of 100 filenames as more data is collected. After which we should have an excellent training set for the neural network. Some high-recurring and high-scoring tokens are shown in tables 2 and 3.
Table 2. Sample of high-scoring tokens sorted on the number of times observed.
Table 3. Sample of high-recurring tokens sorted on the number of times observed.
While these results are preliminary, they nevertheless seems to provide a solid indication of what one can find on publicly-available removable drives. Additional work and fine tuning of both code and processes is required to provide more accurate data and the next step while the scan is still on going it to develop a methodology to assess the sensitivity of all files, likely using a neural network for classification based on the method presented above.
Any operator knows that prior to any penetration testing activity requires a solid recon phase. The more information you collect about your target, the wider your attack surface becomes and thus, increased chances in a successful infiltration. In this post, we browse to the France’s registry, i.e. the “Registre du Commerce et des Societes” to extract information from the company and use this information to expand our attack surface
Any operator knows that prior to any penetration testing activity requires a solid recon phase. The more information you collect about your target, the wider your attack surface becomes and thus, increased chances in a successful infiltration. When your target is a company, you have a wide array of tools to extract information from and pretty much every country has some sort of registry where financials and board information is kept up to date. Sometime, it also include additional information such as incorporation documents, trademark renewals and so one.
In this post, we browse to the France’s registry, i.e. the “Registre du Commerce et des Societes” to extract information from the company and use this information to expand our attack surface. In this post, we used Huawei as an example, only because they are widespread and maintain multiple locations. All information extracted is publicly available and should not be used to conduct fraudulent or illegal activities.
The Système d’Identification du Répertoire des ÉTablissements (SIRET) Number
The SIRET stands for “système d’identification du répertoire des établissements” which is a unique number given to a physical commercial location (building, store, apartment etc…). The SIRET is 14 digits long. The first 9 digits is the SIREN, i.e. the “Système d’Identification du Répertoire des ENtreprises”, which uniquely identify the company owning the unit. The next four digits are the unit number and the last number is a checksum. The checksum is done using the Luhn algorithm. For example, let’s analyze the SIRET for Huawei Technologies France;
As you can see above, the SIRET for the Huawei Technologies France headquarters is 451 063 739 00119. What this number says is that Huawei Technologies France has been assigned SIREN 451 063 739 and that the headquarters is the 11th building Huawei Technologies France occupied in France. By observing the SIRET of each location, you can see the building numbers goes from 3 to 11, meaning the company had 3 buildings prior that they moved out from.
That being said, we could now purchase the KBIS report and get quite a lot of information about the board of Huawei Technologies France. But since we are cheap bastards, we’ll look somewhere else for this information. After all, CEOs and executive usually want to tell the world about their position. A quick search for “SIRET ‘451 063 739 00119′” on Google will yield three results only, but that’s all we need for now. The first one on verif.com will provide the list of the executives.
In all honesty thought, just searching for “Huawei Technologies France” would have return another website with the same information. However, Infogrette, like every other national registry can be a valuable startign point to retrieve additional details and expand your recce.
And actually, this site is even more generous, as it gives the month and year of birth of every executive in the company:
We can validate this information using the advanced search engine of the Infogreffe web site. There is a functionality included to search companies using names of executives including their birth information. For example, let’s make sure Mr. Wang is still on the board of the company. From the front page, click on “Recherche Avancée” (Advanced Search) and then select the second tab: “Recherche par Dirigeant” (Search by Director). Type the name using the “Lastname, Firstname” format and the birth year of the person. Then click the “Rechercher” (Search) button;
Once the results appear, we can see that Mr. Wang is still registered as being the director general of the company. Since any change must be registered to the tribunals, we can be confident that this information is valid.
Conclusion (So What?)
So what you may ask. What can I do with this. We found out the following about Huawei Technologies France:
Physical locations in France
The name of the president and birth information
Names and birth information of most executives
Financial data of the company
You have now 7 addresses you can physically recon, i.e. see if you can dumpster dive, gather information about physical security (HID cards, fences, cameras etc…) or people working at these locations, which can then lead to additional recce on individual targets. Recceing the individuals found will likely lead to information about their relations, employment and responsibilities, possibly even to email addresses.
This simple guide was meant to provide a quick and dirty “howto” guide to one of the many, many tools available online to conducting research on companies or individuals for any law enforcement purposes. The Infogreffe is a drop in the ocean to locate business information for a very specific region. In the upcoming weeks and months, we will develop on other tools for other regions, as well as techniques you can use to track down targets. Don’t forget that the most important part of the operation is the information gathering phase. The more you know about your target, the easier the later phases will become. Keep in mind that other countries also keep similar registries, although the quality of their website may differ greatly.
 Conseil national des greffiers des Tribunaux de commerce. “Registre du commerce et des sociétés.” Infogreffe – Greffe du tribunal de commerce. https://www.infogreffe.fr/ (accessed September 3, 2013).
On 26 and 27 April 15, multiple colleagues from my department received a phishing email from legitimate, but likely compromised emails from Indian-based academic institutions. The objective was likely an attempt at stealing email credentials from the target.
On 26 and 27 April 15, multiple colleagues from my department received a phishing email from legitimate, but likely compromised emails from Indian-based academic institutions. The objective was likely an attempt at stealing email credentials from the target.
The details of the one of the email received are included below:
The email was sent with “Low Importance”, probably as a way to attract additional attention as some people often ignore the “Urgent” flag, since they receive so many of them. Emails with the “Low Importance” flag and icon are more uncommon. Because users don’t see low importance emails often, they tend to open it before the urgent ones.
While the message was caught as SPAM by Symantec, this is clearly more than an attempt at SPAM and attempts to lure the target to a ContactMe page in order to receive an upgrade to their webmail applications. The “Contact Me” page requests information about the user and its credentials. Of note, many of the characters on the page are accentuated for some reason – possibly as to bypass restrictions of the service:
Once the target filled the information and click “Send Message”, a thank you note is displayed. The use of the ContactMe website prevents the operator from having to stand up a web server and buy/register a domain, which leaves a lot of traces but ultimately may look more convincing, as it will not have any content restrictions.
The sender’s email is email@example.com, which based on the suffix, is an email from the Institute of Minerals and Materials Technology, an advanced research institute in the field of mineralogy to materials engineering, established in Bhubaneswar, Odisha. A contact page on the website links the email address to Ms. Pallishree Prusti, from the Mineral Department. Therefore, this is a legitimate email address, which more than likely has been compromised.
Similar emails from a different sender, firstname.lastname@example.org, was reported as well. This time, this email is associated with the Muhimbili University of Health and Allied Sciences (MUHAS)in Tanzania.
In this operation, emails targeted were academic addresses. It appears that the operator may be targeting academic personnel by sending fake email upgrade notifications. It is unclear were the adversarial operator found the target email addresses. While ths operations does not appears advanced or sophisticated in any kind, it is very targeted. The adversary in this case may only be some student phishing for papers he can sell online or use for his own degree.
Indicators (for signatures)
This phishing email may just be another one amongst many others and does not appear to be from a highly skilled operators. While the campaign appears targeted at academic institutions, it does not appear to target a specific field of activity. If you have encounter this email, please leave a comment with some information that would help determine if this specific operation is targeted or just another large campaign from a criminal group or a botnet.
Hopeful that I’ll waste a lot less time than yesterday, I’ve setup a Kali virtual machine. I had one problem while installing: as soon as the actual installation started, I had a “The failing step is ‘Install the System'” error message. This was solved when I created a 15GB Virtual Hard Drive (VHD) rather than a 10GB Virtual Box Drive. I also had to setup Kali so it works with VirtualBox Guest Additions. You’ll first need to update the sources in /etc/apt/sources.list by including the second repositorty(http://http.kali.org);
http://http.kali.org/kali kali main non-free contrib
http://security.kali.org/kali-security kali/updates main contrib non-free
Once done, update the package lists by running apt-get update and then install the the linux-headers for Kali:
Finally, install the guest additions as described in the Kali FAQ ….and realize it doesn’t work. According to the log file, 2 errors occured:
This can be solved by using the latest version of VirtualBox. Once I’ve upgraded to 4.3.8, I was able to compile the Guest additions with no trouble.
The Fun Finally Begins…Exploitin’
Continuing Part 2 of Fuzzy Security exploit tutorial. So now, I can finally use the pattern_create.rb script to find out at which position in the payload I need to put the return address in EIP. In the latest version of Metasploit, pattern_create.rb is in the following directory:
After creating the pattern and putting it in the python script, the EIP registers overflows with value 0x69413269, which correspond to offset 247 of the payload. So far so good.
Once confirmed, then we need to redirect the program’s execution flow to the ESP, the stack pointer, according to tutorial of Fuzzy Security. Good enough, but why ? Well the ESP always points to the top of the stack, which contains an address. If you look at the screenshot above, you’ll notice that the address contained in ESP, 0x00C7FC2C contains our “C”s, i.e. a value we control as well.
So if we replace those “C”s with our shellcode, our objective will be to find a way to jump to the address contained in ESP. To do so, we will find an “jmp esp” instruction in memory, and put the address of the instruction in EIP – the register that contains the address of the next instruction to execute.Use “mona jmp -r esp” to locate the JMP instruction. Once Mona is finished, select View -> Log to see the result.
The results I have differs from the one of the tutorials. Shouldn’t be an issue, so I’ll take the one in “ntdll.dll” (0x7C91FCD8) as it seems to be a stable DLL. In little endian form, it becomes “\xD8\xFC\x91\x7C”. To test if it works, you’ll need a breakpoint at whatever address you are pointing, otherwise the execution flow will just land somewhere in memory. To add a breakpoint, right click in the CPU view, select “Go to” -> “Expression” and in the window, type your address (big endian). After you clicked OK, you should land on your address. Then press F2 to toggle the breakpoint at this location.
So we have verified it worked, we can now move on. I won’t fray to far from the tutorial and just generate a local shell bind payload on port 13373. To do, we’ll need the following Metasploit tool:
Basically what this command does is generate the shellcode for binding a shell on port 13373. It then encodes it in bytes without using bytes 00, 0A and 0C. “\x00” is a terminator value for strings. If included in the shellcode, it will break the code. The same goes with 0A and 0D, which are the “New Line” and “Carriage Return” values (i.e. chr(10), chr(13)). The “-t py” option specifies that the output will be formatted in Python. I thought I could almost conclude this session, but of course, I had to hit one more hiccup. After running the exploit, the debugger throw an “Illegal Instruction” exception at 0x00C7FC28, where the first byte of the shell code is.
I’ve wonder many minutes about this issue. I’ve decided to just plain follow the tutorial and choose the same port, 9988 and regenerate the shell code. To my astonishment, the new shell code worked! The first byte is different, but I’m still not sure why the new code works while the other don’t. More to follow…