Shared posts

29 Nov 10:20

Énorme bug macOS : l'accès root sans mot de passe

Une grosse faille de sécurité frappe macOS High Sierra. Elle permet d'obtenir un accès administrateur à l'ordinateur Mac sans mot de passe. En local, la simplicité d'exploitation laisse sans voix.
20 Nov 12:40

Connaissance du 12/11/2017

La colonne de la place Vendôme, à Paris, fut érigée par Napoléon en 1810. Elle est recouverte d'un parement coulé avec le bronze des canons pris aux armées russes et autrichiennes lors de la bataille d'Austerlitz.
14 Nov 11:48

OnePlus : un accès root direct caché dans ses smartphones

Une application préinstallée dans les smartphones OnePlus fonctionne comme une backdoor donnant un accès root, sans avoir besoin de déverrouiller le bootloader.
01 Nov 17:33

17 avril 1975, les Khmers Rouges entrent à Phnom Penh

durée : 00:52:49 - Affaires sensibles - par : Fabrice DROUELLE - Aujourd’hui dans Affaires Sensibles, le premier volet de notre série sur l’histoire du génocide cambodgien. - invités : Patrice DE BEER - Patrice DE BEER - réalisé par : Fabrice Laigle
23 Oct 12:26

Google to add "DNS over TLS" security feature to Android OS

by (Mohit Kumar)
No doubt your Internet Service Provides (ISPs), or network-level hackers cannot spy on https communications. But do you know — ISPs can still see all of your DNS requests, allowing them to know what websites you visit. Google is working on a new security feature for Android that could prevent your Internet traffic from network spoofing attacks. Almost every Internet activity starts with a
18 Oct 09:09

Peeking into .msg files, (Sun, Oct 15th)

Readers often submit malware samples, and sometimes the complete email with attachment. For example exported from Outlook, as a .msg file.

Did you know that .msg files use the Compound File Binary Format (what I like to call OLE files), and can be analysed with oledump?

Reader Carlos Almeida submitted a .msg file with malicious .rar attachment.

I'm not that familiar with .msg file intricacies, but by looking at the stream names and sizes, I can often find what I'm looing for:

Stream 53 seems to contain the message:

From this hex-ascii dump, you can probably guess that the message is stored in UNICODE format. We can use option -t (translate) of oledump to decode it as UTF-16:

Stream 43 contains the headers. I don't want to disclose private information like our reader's email address, so I grepped for some headers that I can disclose:

The Subject header is encoded according to RFC1342 because the subject contains non-ASCII characters. It decodes to this:

These are chinese characters that seem to mean the same as FW: (forwarding).

Stream 3 contains the attachment:

You can see it's a RAR file.

I use 7zip to look into it, and it should be possible to do this without writing the file to disk, by just piping the data into 7zip (options -si and -so can help with piping). But unfortunately, I got errors trying this and resigned to saving it to disk:

It contains an unusually large .bat file:

It's actually a PE file:

This looks to be a VB6 executable (from the PEiD signature), I should dig up my VB6 decompiler and try to take a closer look.

Of course, it's malware.


Didier Stevens
Microsoft MVP Consumer Security

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
13 Oct 09:31

Palo Alto Networks se prépare à proposer la technologie de LightCyber

by LeMagIT(
A l’occasion des Assises de la Sécurité, René Bonvanie, directeur marketing de Palo Alto Networks, a indiqué que l’équipementier prévoit d’apporter à ses clients cette technologie d’ici la fin de l’année.
13 Oct 09:24

More and more websites are mining crypto-coins in your browser to pay their bills, line pockets (The Register)

09 Oct 12:19

A strange JPEG file, (Sun, Oct 8th)

I had a JPEG file to analyze that would not render properly: image viewers would display an error, but no image.

My new jpegdump tool confirmed that it started with the right JPEG markers, but that the data sizes were wrong:

2576 bytes for an APP0 marker is really large...

Taking a look with a hex editor, I saw that the markers were present, but that the size of the data were wrong.

With re-search, I took a closer look at the markers with their data size:

The size of the data following a marker is encoded with two bytes, big endian notation. And for the first markers in the JPEG file, they all looked too large. Then I noticed that the 3rd byte (e.g. the first byte of the size field) was always 0x0A, were I expected it to be 0x00.

Counting all the bytes reveals that in this file, there were no 0x00 bytes but an unusual large amount of 0x0A bytes:

I formed a hypothesis: somehow, all 0x00 values were replaced by 0x0A values. To test this hypothesis, I replaced all 0x0A values by 0x00 values and parsed the result with jpegdump:

This was indeed a JPEG file. But I could not repair it, as I did not know what 0x0A values were original bytes, and which were replacemnt values for 0x00.

At least I new it was most likely not malicious, but corrupted by some unknown process.


Didier Stevens
Microsoft MVP Consumer Security

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
05 Oct 14:33

Emmanuel Macron : le vote en ligne aux législatives pour les Français de l'étranger

Utilisé en 2012 mais suspendu en 2017, le vote en ligne aux législatives pour les Français de l'étranger reviendra en 2022. Une demande du président de la République.
02 Oct 15:45

VideoLAN a refusé des dizaines de millions de dollars pour placer de la pub dans VLC

by Julien Lausson


Saviez-vous que le président de VideoLAN a refusé des dizaines de millions de dollars en échange de l'ajout de publicités et de bouts de code douteux dans VLC ? Connaissez-vous l'histoire de l'icône du lecteur multimédia ? Ou du risque que font peser la NSA et la CIA sur le projet ? Non ? Alors, il est temps de lire les réponses que le président de VideoLAN a données aux questions des internautes. [Lire la suite]
25 Sep 16:50

The birth of a ninja

25 Sep 15:47

Cacher des objets derrière un "rideau optique"

Là vous le voyez, là vous ne le voyez plus! La cape d'invisibilité se rapproche de la réalité. La photonique est un secteur qui connaît une croissance rapide et qui permet de commencer à envisager...
24 Oct 06:20

Dyn issues affecting joint customers

by Filippo Valsorda

Today there is an ongoing, large scale Denial-of-Service attack directed against Dyn DNS. While Cloudflare services are operating normally, if you are using both Cloudflare and Dyn services, your website may be affected.

Specifically, if you are using CNAME records which point to a zone hosted on Dyn, our DNS queries directed to Dyn might fail making your website unavailable, and presenting a “1001” error message.

Some popular services that might rely on Dyn for part of their operations include GitHub Pages, Heroku, Shopify and AWS.

1001 error

As a possible workaround, you might be able to update your Cloudflare DNS records from CNAMEs (referring to Dyn hosted records) to A/AAAA records specifying the origin IP of your website. This will allow Cloudflare to reach your origin without the need for an external DNS lookup.

Note that if you use different origin IP addresses, for example based on the geographical location, you may lose some of that functionality by using plain A/AAAA records. We recommend that you provide addresses for many of your different locations, so that load will be shared amongst them.

Customers with a CNAME setup (which means Cloudflare is not configured in your domain NS records) where the main zone is hosted on a Dyn service will be affected as well. You might be able to make Cloudflare your authoritative DNS provider by contacting support and asking to be changed to Full mode and then updating your nameservers at your registrar, but the change can take up to 48h to propagate.

Please note that the Cloudflare status page and support system might be affected by the ongoing attack, since they are hosted on third parties, as per industry best practices.

06 Oct 12:02

TCP joke

29 Sep 12:59

SNMP Pwn3ge, (Wed, Sep 28th)

Sometimes getting access to company assets is very complicated. Sometimes it is much easier (read: too easy) than expected. If one of the goals of a pentester is to get juicy information about the target, preventing the IT infrastructure to run efficiently (deny of service) is also a win. Indeed, in some business fields, if the infrastructure is not running, the business is impacted and the company may lose a lot of money. Think about traders.

I was recently involved in a pentest with the goal to test the customers internal network. The scope was easy: to come on site,connect your laptop to a free network port and see what you can find/do. In such scenario, the breaking point is to successfully be connected to the network. If Mr DHCP is kind enough to provide you an IP address, you are in and you may consider the network as already compromised. This was the case for me, no protection against rogue devices, no network access control. I launched my Ettercap and started to sniff some packets playing MitM. I immediately grabbed some nice SNMP packets with interesting communities like public and private. As you probably know, those are the default ones on many systems. public provides usually a read-only access and private is used in read-write mode. Often, I hear this comment: But SNMP is just a monitoring protocol, why should I care?. Wrong! SNMP, as described by RFC 3411[1], meansSimple Network Management Protocol and not Monitoring Protocol. If you have SNMP read access to a device, you can collect interesting information (version, processes, IP information, health) for the reconnaissance phase. But if you have SNMP write access to a device, you can alter his configuration and cause much more damages

During"> # nmap -Pn -sU -p 161 -v -oA snmp grep 161/open/udp snmp.gnmap | awk { print $2 } | while read IPdo snmpwalk -v1 -c private $IP /dev/null 21 if [ $? == 0 then echo $IP accepts private community echo $IP vulnerable_ip.tmp fidone

The next step was to identify the vulnerable devices. This information is discoverable with the OID"> # snmpwalk -v1 -On -c xxxxxxxxx SNMPv2-MIB::sysDescr. = STRING: Cisco IOS Software, C1600 Software (AP1G2-K9W7-M), Version 15.2(2)JB2, RELEASE SOFTWARE (fc1)

Guess what? Most vulnerable devices were UPS management systems configured with default settings or, more precisely, not configured at all. The next step was to browse the vendor MIB (Management Information Base). The vendor ID was534 and is assigned to Eaton Corporation [2]. The MIB reveals someinteresting read/write OIDs like this one: This OID is called xupsControlOutputOffDelay. Here is the description:

Setting this value to other than zero will cause the UPS output to turn off after the number of seconds. Setting it to 0 will cause an attempt to abort a pending shutdown.

We are close to perform a nice DoS against the customers infrastructure. How? A simple snmpset command will help us. Let"> for IP in cat vulnerable_ip.tmpdo snmpset -c private -v1 $IP i 10 echo -n $IP d=10 do echo -n . done echo Tango down!done

Game over! Note that this is a proof of concept. In most pentestengagements, youre not allowed to perform such actions.

It is a pity that such very simple attack is still possible in 2016! If the customer followed the SANS Top-20 controls[3], this attack wouldnt be possible:

  • CSC1 -Inventory of authorized and unauthorized devices
  • CSC4 -Continuous vulnerability scanning, assessment, and remediation
  • CSC9 -Limitation and control of network ports, protocols, and services
  • CSC11 -Secure configuration for network devices such as firewalls, routers, and switches


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
29 Sep 10:02

In the Robot Skies : un film entièrement tourné par des drones autonomes

by Julien Lausson


Le film In the Robot Skies ne se contente pas de raconter une histoire où les drones tiennent une place importante. Il a aussi été tourné en utilisant des drones autonomes. [Lire la suite]
20 Sep 10:37

Watch Chinese Hackers Control Tesla's Brakes From 12 Miles Away

by Thomas Fox-Brewster
First ever remote Tesla hack sees brakes killed and the boot opened mid-drive, Tencent security researchers claim.
19 Sep 11:35

Equation Group était capable d’extraire les clés VPN des pare-feu Cisco PIX

by UnderNews
Les documents de la récente fuite ayant touché le groupe de pirates Equation Group ont pu être rapproché à ceux des révélations d'Edward Snowden. Une faille dans les pare-feu Cisco permettait à la NSA de s'emparer des clés VPN et de déchiffrer jusqu'à un millier de connexion VPN à l'heure.
05 Sep 08:39

Outsourcing en baisse sur fond de percée IaaS/SaaS en EMEA

by Maryse Gros
Pour le 2ème trimestre 2016, l’index ISG portant sur les contrats d’externalisation ayant une valeur annuelle supérieure à (...)
27 Jun 09:56

Les données de 112.000 policiers français et de leurs proches dans la nature

C'est la base de données de la Mutuelle Générale de la Police qui a été compromise. Mais il ne s'agirait pas d'une attaque, plutôt d'une vengeance.
13 Jun 10:26

Symantec rachète Blue Coat pour 4,65 Md$

by Maryse Gros avec IDG News Service
L’éditeur de solutions de sécurité Symantec rachète Blue Coat, spécialisé dans la cybersécurité, (...)
18 May 08:15

Dépitée, la Quadrature du Net ne se battra plus frontalement contre les lois

by Guillaume Champeau

Adrienne Charmet-Alix, directrice des campagnes de la Quadrature du Net.

Signe supplémentaire que les institutions dites « démocratiques » peinent de plus en plus à convaincre de leur efficacité démocratique, la Quadrature du Net explique mardi qu'elle est fatiguée de se battre sur les terrains parlementaires, et préfère réorienter son action au plus près du public. [Lire la suite]
17 May 14:22

Cisco : faille critique dans ses systèmes de téléprésence

La vulnérabilité, corrigée, permet une prise de contrôle à distance des équipements. Cisco annonce également d'autres patchs.
26 Apr 12:57

RuMMS: The Latest Family of Android Malware Attacking Users in Russia Via SMS Phishing

by Wu Zhou

Recently we observed an Android malware family being used to attack users in Russia. The malware samples were mainly distributed through a series of malicious subdomains registered under a legitimate domain belonging to a well-known shared hosting service provider in Russia. Because all the URLs used in this campaign have the form of hxxp://yyyyyyyy[.] (where represents the hosting provider’s domain), we named this malware family RuMMS.

To lure the victims to download the malware, threat actors use SMS phishing – sending a short SMS message containing a malicious URL to the potential victims. Unwary users who click the seemingly innocuous link will have their device infected with RuMMS malware. Figure 1 describes this infection process and the main behaviors of RuMMS.

Figure 1. Overview of the RuMMS campaign and behaviors

On April 3, 2016, we still observed new RuMMS samples emerging in the wild. The earliest identified sample, however, can be traced back to Jan. 18, 2016. Within this time period, we identified close to 300 samples belonging to this family (all sample hashes are listed in the Appendix).

After landing on the victim’s phone, the RuMMS apps will request device administrator privileges, remove their icons to hide themselves from users, and remain running in the background to perform a series of malicious behaviors. So far we have identified the following behaviors:

●      Sending device information to a remote command and control (C2) server.

●      Contacting the C2 server for instructions.

  • Sending SMS messages to financial institutions to query account balances.
  • Uploading any incoming SMS messages (including the balance inquiry results) to the remote C2 server.
  • Sending C2-specified SMS messages to phone numbers in the victim’s contacts.
  • Forward incoming phone calls to intercept voice-based two-factor authentication.

Each of these behaviors is under the control of the remote C2 server. In other words, the C2 server can specify the message contents to be sent, the time period in which to forward the voice call, and the recipients of outgoing messages. As part of our investigation into this malware, we emulated an infected Android device in order to communicate with the RuMMS C2 server. During one session, the C2 server commanded our emulated device to send four different SMS messages to four different phone numbers, all of which were associated with Russian financial institutions. At least three of the messages were intended to check a user’s account balance at the institution (we could not confirm the purpose of the fourth).Through additional research, we identified several forum posts where victims complained of funds (up to 600 rubles) were transferred out of their accounts after RuMMS infected their phones.

We do not know exactly how many people have been infected with RuMMS malware. However, our data suggests that there have been at least 2,729 infections between January 2016 and early April 2016, with a peak in March of more than 1,100 infections.

Smishing: The Major Way To Distribute RuMMS

We have not observed any instances of RuMMS on Google Play or other online app stores. Smishing (SMS phishing) is currently the primary way threat actors are distributing the malware. The process starts when an SMS phishing message arrives at a user’s phone. An example SMS message is shown in Figure 1. The message translates roughly to“ You got a photo in MMS format: hxxp://”

So far we identified seven different URLs being used to spread RuMMS in the wild. All of the URLs reference the file “mms.apk” and all use the domain “”, which belongs to a top five shared hosting platform in Russia (the domain itself has been obfuscated to anonymize the provider).

The threat actors registered at least seven subdomains through the hosting provider, each consisting of eight random-looking characters (asdfgjcr, cacama18, cacamadf, konkonq2, mmsmtsh5, riveroer, and sdfkjhl2.) As of this writing, no files were hosted at any of the links. The threat actors seem to have abandoned these URLs and might be looking into other ways to reach more victims.

Use of a shared hosting service to distribute malware is highly flexible and low cost for the threat actors. It is also much harder for network defenders or researchers to track a campaign where the infrastructure is a moving target. Many top providers in Russia offer cheap prices for their shared hosting services, and some even provide free 30-day trial periods. Threat actors can register subdomains through the hosting provider and use the provider’s services for a short-period campaign. A few days later they can cancel the trial and do not need to pay a penny. In addition, these out-of-the-box hosting services usually provide better infrastructure than the attackers could manage to construct (or compromise) themselves.

RuMMS Code Analysis

All RuMMS samples share the same behaviors, major parts of which are shown in Figure 1. However, the underlying code can be quite different in that various obfuscation mechanisms were adopted to evade detection by anti-virus tools. We used a sample app named “org.starsizew” with an MD5 of d8caad151e07025fdbf5f3c26e3ceaff to analyze RuMMS’s code.

Several of the main components of RuMMS are shown in Figure 2. The activity class “org.starsizew.MainActivity” executes when the app is started. It first starts another activity defined in “org.starsizew.Aa” to request device administrator privileges, and then calls the following API of “” (the Android package manager to remove its own icon on the home screen in order to conceal the existence of RuMMS from the user:

            setComponentEnabledSetting(MainActivity.class, 2, 1)

At the same time, ”org.starsizew.MainActivity” will start the main service as defined in “org.starsizew.Tb”, and use a few mechanisms to keep the main service running continuously in the background. The class “org.starsizew.Ac” is designed for this purpose; its only task is to check if the main service is running, and restart the main service if the answer is no. The class “org.starsizew.Tb” also has a self-monitoring mechanism to restart itself when its own onDestroy API is triggered. Other than that, its major functionality is to collect private device information, upload it to a remote C2 server, and handle any commands as requested by the C2 server. All those functions are implemented in asynchronous tasks by “org.starsizew.i”.

Figure 2. Android Manifest File of RuMMS

The class “org.starsizew.Ma” is registered to intercept incoming SMS messages, the arrival of which will trigger the Android system to call its “onReceive” API. Its major functionality is also implemented through the call of the asynchronous task (“org.starsizew.i”), including uploading the incoming SMS messages to the remote C2 server and executing any commands as instructed by the remote attacker.

C2 Communication

The C2 communication includes two parts: sending information to the remote HTTP server and parsing the server’s response to execute any commands as instructed by the remote attackers. The functionality for these two parts is implemented by doInBackground and onPostExecute respectively, two API methods of “android.os.AsyncTask” as extended by class “org.starsizew.i”.

Figure 3. Method doInBackground: to send information to remote C2 server

As seen from the major code body of method doInBackground shown in Figure 3 (some of the original classes and methods are renamed for easier understanding), there are three calls to HttpPost with different contents as parameters. At line 5, local variable v4 specifies the first parameter url, which can be changed by the remote C2 server later. These URLs are all in the form of “http://$C2.$SERVER.$IP/api/?id=$NUM”. The second parameter is a constant string “POST”, and the third parameter is a series of key-value pairs to be sent, assembled at runtime. The value of the first item, whose key is “method” (line 7), indicates the type of the contents: install, info and sms.

The first type of content, starting with “method=install”, will be sent when the app is started for the first time, including the following device private information:

  • Victim identifier
  • Network operator
  • Device model
  • Device OS version
  • Phone number
  • Device identifier
  • App version
  • Country

Figure 4 is an example of this string as seen by the FireEye Mobile Threat Prevention platform.

Figure 4. Example HTTP post message

The second type of information will be sent periodically to indicate that the device is alive. It only has two parts, the method indicated by word “info” and the victim identifier. The third type of information will be sent when RuMMS intercepts any SMS messages, including the balance inquiry results when it contacts the SMS code of a particular financial service.

Method onPostExecute parses the response from the above HTTP session and executes the commands provided by the remote attacker. As seen from the code in Figure 5, the commands RuMMS supports right now include:

  • install_true: to modify app preference to indicate that the C2 server received the victim device’s status.
  • sms_send: to send C2-specified SMS messages to C2-specified recipients.
  • sms_grab: to upload periodically the SMS messages in the inbox to C2 server.
  • delivery: to deliver specified text to all victim’s contacts (SMS worming).
  • call_number: to forward phone calls to intercept voice based two-factor authentication.
  • new_url: to change the URL of the C2 server in the app preference.
  • ussd: to call a C2-specified phone number.

Figure 5. Method onPostExecute: to handle instructions from remote C2

Figure 6 shows an example response sent back from one C2 server. Note that inside this single response, there is one “install_true” command, one “sms_grab” command and four “sms_send” commands. With the four “sms_send” commands, the messages as specified in the key “text” will be sent immediately to the specified short numbers. Our analysis suggests that the four short numbers are associated with Russian financial institutions, presumably where a victim would be likely to have accounts.

Figure 6. Example Response in JSON format

In particular, short number “+7494” is associated with a payment service provider in Russia. The provider’s website described how the code 7494 can be used to provide a series of payment-related capabilities. For example, sending text “Balance” will trigger a response with the victim’s wallet balance. Sending text “confirm 1” will include proof of payment. Sending text “call on” will activate the USSD payment confirmation service.

During our investigation, we observed the C2 server sending multiple “balance” commands to different institutions, presumably to query the victim’s financial account balances. RuMMS can upload responses to the balance inquiries (received via SMS message) to the remote C2 server, which can send back additional commands to be sent from the victim to the provider’s payment service. These could include resetting the user’s PIN, enabling or disabling various alerts and confirmations, and confirming the user’s identity.

RuMMS Samples, C2, Hosting Sites, Infections and Timeline

In total we captured 297 RuMMS samples, all of which attempt to contact an initial C2 server that we extracted from the app package. Figure 7 lists the IP addresses of these C2 servers, the number of RuMMS apps that connect to each of them, and the example URL used as the first parameter of the HttpPost operation (used in the code of Figure 3). This indicates that multiple C2 servers were used in this campaign, but one ( was the most heavily used.

Figure 7. RuMMS samples and C2 servers

Figure 8 shows how these samples, C2 servers and hosting websites are related to each other, including when they were compiled or observed. In the quadrant, the smaller boxes in blue-gray represent particular apps in the RuMMS family, while the bigger boxes in deep-blue represent C2 servers used by some RuMMS apps. The dotted arrows represent the use of a particular C2 server by a specific app to send information and fetch instructions. In this figure we have 11 RuMMS samples, all of which were hosted on the website as shown in the “y” axis. The dates on the “x” axis show the dates when we first saw these apps in the wild. This figure demonstrates the following interesting information:

The time range when threat actors distributed RuMMS on those shared-hosting websites is from January 2016 to March 2016.

  • Threat actors used different websites to host different payloads at different times. This kind of “moving target” behavior made it harder to track their actions.
  • The same websites have hosted different RuMMS samples at different dates.
  • C2 servers are shared by multiple samples. This matches our observations of C2 servers as shown in Figure 7.

Figure 8. RuMMS samples, hosting sites, C2 servers from Jan. 2016 to Mar. 2016

We do not know exactly how many people have been infected with RuMMS malware; however, our data suggests that there are at least 2,729 infections with RuMMS samples from January 2016 to early April 2016.

Figure 9 shows the number of RuMMS infections recorded in the last four months. When we first observed the malware in January, we recorded 380 infections. In February, we recorded 767 infections. In March, it peaked at 1,169 infections. In April, at the time of writing this post, we recorded 413 RuMMS infections. Although the propagation trend seems to be slowing down a bit, the figure tells us that RuMMS malware is still alive in the wild. We continue to monitor its progress.


Figure 9. RuMMS infections from Jan. 2016 to Apr. 15, 2016


Smishing (SMS phishing) offers a unique vector to infect mobile users. The recent RuMMS campaign shows that Smishing is still a popular means for threat actors to distribute their malware. In addition, the use of shared-hosting providers adds flexibility to the threat actor’s campaign and makes it harder for defending parties to track these moving targets.

Fortunately, FireEye Mobile Threat Prevention platform can recognize the malicious SMS and networking behaviors used by these RuMMS samples, and help us quickly identify the threat. To protect yourself from these threats, FireEye suggests that users:

  • Take caution before clicking any links where you are not sure about the origin.
  • Don’t install apps outside the official app store.

To detect and defend against such attacks, we advise our customers to deploy our mobile security solution, FireEye MTP/MSM. This helps our clients gain visibility into threats in their user base, and also enables them to proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that Wi-Fi traffic is scanned by NX appliances to extend coverage to mobile devices.

Appendix: RuMMS Sample Hashes












































































































































































































































































































22 Mar 10:03

Connaissance du 19/03/2016

La "parabole des talents" est un chapitre de l'Evangile selon Saint Matthieu. Celui-ci incite à faire des placements financiers et explique les bases du capitalisme actuel (on prend aux pauvres pour donner à celui qui a déjà beaucoup).
26 Nov 09:40

GhostSec pirate l'État islamique avec du prozac

GhostsSec, un groupe souvent associé à Anonymous, vient de frapper fort en piratant un des sites de l’État islamique sur le réseau Tor et en remplaçant la page d’accueil par une publicité pour une pharmacie en ligne...

24 Nov 13:50

ProtonMail, le Webmail anti-NSA, s'est relevé de la "plus grande cyber-attaque de Suisse"

Le service d'e-mail hyper-sécurisé suisse ProtonMail a subi une attaque DDoS d'une ampleur inégalée en Suisse. Indisponible 5 jours, il est parvenu à se relever mais l'attaque continue. Prot [...]

24 Nov 11:36

Connaissance du 07/11/2015

Lors des Jeux Olympiques d'été de Paris en 1900, les épreuves de natation se déroulaient dans la Seine.
24 Nov 11:36

Connaissance du 08/11/2015

L'actuel drapeau américain a été créé en 1958 par un étudiant de 17 ans dans le cadre d'un projet scolaire; il obtenu un B-. Le drapeau fut accepté par le Congrès Américain, son professeur changea sa note en A.