Archive for September, 2020

Making sense of Azure AD (AAD) activity logs, (Thu, Oct 1st)

Chances are, you are quite familiar with the logs of your on-premises Active Directory (AD) domain controller. The corresponding Event IDs have been well documented over the years (though not thanks to Microsoft), and many blog posts have been written about how to use AD logs to detect Pass-the-Hash, brute force attempts, Kerberoasting, and more.

Increasingly though, we all find our Active Directory slowly (or quickly) migrating into the Cloud, and becoming an Azure Active Directory (AAD). Some of the old on-premises AD body of knowledge in detection and defense still applies, but most is obsolete. And – brave new world – AAD is usually exposed to the Internet in some form or fashion, so it is subject to all the noise that all the miscreants on the planet can fire against the IP address that happens to be yours.

As was the case with Active Directory, Microsoft isn’t really making huge strides in sharing the knowledge needed to keep Azure AD safe, either. The and repositories are sharing some samples, many of which are outdated, but in general, the documentation is still kinda thin.

If you are like many small businesses or institutions who use AAD, but can’t afford the full-fledged Microsoft offering with Sentinel, Azure ATP (now called Microsoft Defender for Identity) and other $$$-gadgets, you are kinda on your own.

You still should look at them logs though, because … as mentioned above … AAD is usually “internet-facing”, and if there is any chink in your armor, the miscreants will find it eventually. 

Rather than to stream your AAD logs back to on-premises into your existing ELK or Splunk or what-have-you, I’d suggest you look into connecting your AAD into a LogAnalytics space in Azure. It isn’t exactly cheap, but if you don’t go overboard with the volume or retention period, you’ll find it useful. More info how to set it up, here:

Once you have this in place, you can use the Kusto Query Language to run quickfire analysis queries like this one, to look for failed logins that originate from the same IP, and hit several user IDs:

| where ResultType != 0                                 // failed logins only
| extend TimeBin=bin(TimeGenerated,2h)                  // in 2h interval buckets
| summarize IDs=make_set(Identity) by IPAddress,TimeBin // attempted usernames per source IP and time bucket
| extend targets=array_length(IDs)                      // count how many
| render columnchart                                    // paint a pretty picture

which in my case, for the community college where I’m watching the AAD, is resulting in something like this for last week:

which in turn provides ample incentive to drill down further, and to also look into how to deploy some kind of automatic responder that bans this kind of nonsense, by pushing a temporary block rule to zap the offending IPs.

If you know of useful resources on how to monitor Azure AD, please let us know, or share in the comments below.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Scans for FPURL.xml: Recognizance or Not?, (Wed, Sep 30th)

A reader has been reporting an increase in scans for “FPURL.xml” against their IIS server. The file did not exist in this case, and the server returned a 404 error. Checking our honeypots, we found little to no requests for this URL. But our honeypots are currently not emulating IIS servers. These scans have been hitting IIS servers for a while, according to some other reports I found.

FPURL.xml is used as part of Microsoft’s federated identity system. It can be used to implement “Windows Hello for Business.” With Windows Hello for business, users can authenticate to Azure AD using two-factor authentication, and you can leverage this authentication for your applications. A client taking advantage of this authentication mechanism will load FPURL.xml to learn the parameters needed to authenticate. Here is a typical FPURL.xml file:

(I abbreviated some of the Base64 encoded strings to make this more readable)




The file describes a “Federation Provider” that can be used to authenticate. In this case, the Federation Provider is, and the file describes algorithms and certificates to use.

This file has some recognizance value. An attacker may now, for example, know that they can phish users for MicrosoftOnline credentials to get access to the resource. It could also be used for simple fingerprinting. There is a possibility that some of the requests you see for this file are just caused by clients that check if you are supporting this authentication method. 

If anybody has additional input on these scans: Please let me know below or via our contact page.

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Managing Remote Access for Partners & Contractors, (Tue, Sep 29th)

Yesterday, I wrote a quick diary about a potential security issue that some Tyler customers faced[1]. Some people reacted to my diary with interesting comments in our forums. Two of them were interesting and deserve some review.

« Sometimes their techs will install the Bomgar jump client on your servers when they are troubleshooting issues. They don’t remove it, it is left to the local entity to remove it or at least disable the service until it is needed again. »


« A lot of vendors, especially in the local government sector expect customers to install these clients and leave them on. They are truly offended when you tell them no, same on the SCADA side of things. »

When you are outsourcing some tasks to a third-party (read: an MSSP, an integrator, …), it’s very important to keep an eye on what they do and how they do it.

The installation of remote access tools (some of them are very close to a malicious backdoor) or specific accounts is a key point to allow them to perform their day-to-day job. But it does not mean that they can do whatever they want. When I read « it is left to the local entity to remove it or, at least, disable it », it means that a process must be implemented to follow this. The main risks are to detect an attacker using the third-party network to pivot into your organization or to detect their credentials used by attackers from unknown locations. That’s why Tyler asked its customers to reset all passwords related to their remote activities.

Here are some tips to increase the operations security when working with third-parties.

  1. Know « who’s behind the keyboard ». Are the third-party employees on the payroll, dedicated to you (read: they know you and your business). Are they also contractors? Are they located in the same country as yours?
  2. When it’s not mandatory, do not keep the remote access open 24×7. All access requests must be approved following a procedure.
  3. Do not grant full access to your infrastructure. Restrict the third-party rights to the minimum resources to perform its job (least privilege). Keep segmentation in mind. Restrict its access to a jump host that will be used to enforce more security controls.
  4. Keep logs of who did what, when, why, and from where. Log everything, all connections, all commands. 
    Example: Detect an unforeseen connection from an unusual location outside the business hours.
  5. Keep an inventory of your partners and installed software. Force them to upgrade them and audit the settings.
  6. Enable security settings available in the deployed tools
    Example: Enable MFA, activate client-side certificates, provide security tokens.

Finally, don’t be afraid to say « No » and explain why you don’t agree with their requirements. They will work on YOUR platform which hosts YOUR data. You’ll be responsible in case of a data breach!

This list is not exhaustive. If you’ve implemented other specific controls when working for third-party organizations, please share!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Party in Ibiza with PowerShell, (Thu, Sep 24th)

Today, I would like to talk about PowerShell ISE or “Integration Scripting Environment”[1]. This tool is installed by default on all Windows computers (besides the classic PowerShell interpreter). From a malware analysis point of view, ISE offers a key feature: an interactive debugger! It provides all the classic features that you can expect from a debugger: breakpoints, step in, step over, step out, … all of these features are available while you keep control of the environment to interact with the script through the help of other PowerShell commands. When you’re facing a strongly obfuscated scripts, you could speed up the analysis with the help of carefully placed breakpoints. Let’s have a look at a practical example.

The malicious script that I’d like to use contains a lot of references to “Ibiza” (hence the title of this diary). The script has a VT score ot 9/60 (SHA256:ead30df7867c2bcb99de71c1686e82d49c6fcc3ba00092a9fc8d878b78c62302).

/! Warning: Do NOT debug malicious scripts on sensitive or corporate computers, setup a lab to avoid mistakes and execute the script without breakpoint! /!

Let’s load the file into PowerShell ISE: (note: the file must have the extension .ps1 to be properly saved and debugged)

You can see that the script has some chunks of Base64 data (some of them based on format strings). This is confirmed via base64dump:

$ docker run -it --rm -v $(pwd):/malware rootshell/dssuite 
ead30df7867c2bcb99de71c1686e82d49c6fcc3ba00092a9fc8d878b78c62302.ps1 -n 100
ID  Size    Encoded          Decoded          MD5 decoded
--  ----    -------          -------          -----------
 1:     172 bU3lzdGVtLk11bHR mM?????5????? a3373aca7480f0fd3063e6f3bd3d3bce
 2:     172 Ww6R2V0LURlbGVnY [.??].Q.[.Y?].U. b9b01945b37903a46b09c46dd27b3d19
 3:     204 kludm9rZSgkaFByb ?[????J....???? 1ee694694f746acda3ebcd9cadf650cc
 4:     136 dG8gdGhlIHJ1bm5p to the running P 1a41aab7dc9e6680fee5de37d0c31243
 5:     156 0sIFtVaW50MzJdLC ??.?V??C3%??.?T? edc0526f5004950bfecf715f71f5217c
 6:   70504 76492d1116743f04 ?=??u????8?~5? a2c38d7f5e380d0111f1b55d90986fa0

You see that the first Base64 payload is based on a concatenation of strings. Let’s decode this from PowerShell ISE.

First, define a breakpoint via the menu “Debug / Toggle a breakpoint” or press F9. Where? By reading the script, you see that a good candidate is line 13 because, at line 12, we see a reference to Base64String. Once the breakpoint set, the line color is switched to red:

Now, launch the script via the menu ‘Debug / Run / Continue” or press F5. Once the debugger reached the breakpoint, it displays a message on the console and the line becomes yellow. We can interact with the script and use more PowerCommand to, by example, display the content of variable or, better, dump it into a file for further analysis:

We now see the decoded Base64 data. It’s a new set of PowerShell instructions! Let’s dump them into a file:

With the help of WriteAllBytes(), we dump the contain of $PARtYINVITEpREtTY into a file ‘payload.ps1’.

Let’s have a look now at line 18. It refers to an object ‘manaGEMeNT.AUtomatiON.pScreDENtial’ which is used to store encrypted data (I wrote a diary about this technique[2]). Let’s decode this! Stop the debugger, remove all breakpoints. At the end of line 18, you see that the extracted code is executed with an ‘IEX’ command (“Invoke-Expression”). Replace ‘iex’ with ‘echo’, put a breakpoint at line 20 (we can’t set a breakpoint on a blank line), and launch the debugger again:

Once again, we see a new bunch of PowerShell instructions (that are normally executed). Copy this code and paste it into a new tab. To be able to debug it, save it as ‘payload2.ps1’. Tthe code is executed by IEX (obfuscated and marked in the red rectangle):

The code is nicely obfuscated but we won’t take too much time on this. Just execute the code without any breakpoint and have a look at the new variables. We have two interesting ones: ‘$Shellcode32’ and ‘$Shellcode64’. We use the same technique to dump the shellcode into a file:

And we have a shellcode! The next step will be to have a look at this shellcode!

The first chunk of Base64 data that we decoded contains a framework used to perform injection of code into another process:

function Create-Party-Invite
 Create-Party-Invite -Shellcode @(0x00,0x00,0x00)

[CmdletBinding( DefaultParameterSetName = 'RunLocal', SupportsShouldProcess = $True , ConfirmImpact = 'High')] Param (
    [Parameter( ParameterSetName = 'RunLocal' )]
    $Force = $False

This code is just a fork of some PowerSpoit code[3]. Note also that the injected process is a ‘colorcpl.exe’ launched by the script.

Conclusion: PowerShell ISE is a great tool to investigate malicious scripts! It could save you a lot of time.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Securing Exchange Online [Guest Diary], (Fri, Sep 25th)

[This is a guest diary by Jason Dance]


Email poses an increasingly attractive vector for criminals to exploit. Most inboxes contain some form of confidential information, whether it is chatter about new products, sensitive information between C-suite members or vendor payment authorization emails from the finance department. Unauthorized access into email servers/inboxes is known as Business Email Compromise and is one of the most financially damaging online crimes.

Microsoft Office 365 usage is accelerating at an ever-increasing pace and adoption shows no signs of slowing. With the impending expiry of Exchange 2010 extended support, the need to provide email to the remote workforce during the COVID-19 pandemic, or the simple allure of no longer needing to manage email servers; more businesses are moving their email services to Exchange Online in the Microsoft Office 365 suite.

The shared security model adopted by most cloud service shifts a portion of securing data to the customer. Microsoft is no different in this respect, and they have published their security support matrix here: In this model, Microsoft will protect the platform by securing access to the physical components, making sure the underlying operating systems and applications have the latest patches and providing the customer the ability to apply additional data and configuration controls. The customer is then responsible for managing identity, defining access to data, and maintaining the configuration of the service to meet the security needs of their organization.

The base configuration of Exchange Online is set to allow quick onboarding of customers with minimal barriers to the smooth migration of email into the service. The configuration does require tweaks to in order to make it more secure. I aim to cover some of the more effective tweaks in this document and point the reader to the right documentation to secure their Exchange tenant.

Targeted readers

The information in this document is for all administrators and engineers that are responsible for securing Exchange Online. While somewhat technical in nature, each headline in this document can be used by non-technical people as a conversation starter with their technology team.

Not Included

Exchange Online has many settings and features. Some are large enough to merit a separate document on their own, and others are accessible only through scripting/coding. With this in mind, the following topics are not addressed in this document: Data Loss Prevention (DLP), Digital Rights Management (DRM), Advanced Threat Protection (ATP) and Advanced Message Encryption.

Securing Identity

Account takeover is one of the most common forms of breach in Office 365. Malicious actors commonly take advantage of reused passwords that are leaked in breaches, and short, easy to guess passwords are easily broken by password spraying attacks. Criminals find this vector one of the easiest to exploit, so here are some ways to make it harder for them to succeed.

Identity source. The following four authentication methods are available:

  • Cloud only
  • Directory sync with password hash
  • Directory sync with pass through authentication
  • Directory sync with Active Directory Federation Services

Most businesses migrate from an on premise Exchange system into Exchange Online and will already have Microsoft Active Directory (AD) in place. Part of the migration process is to synchronize identities from Active Directory into Azure AD for use in Office 365. Note that to use Azure AD connect to synchronize identities, you will need to have an Azure AD premium P1 or P2 license. Microsoft has published this handy guide to help the implementer decide which path is better for their organization

Azure AD has a number of features you can use to detect and block risky login. Many of the premium features require the password hash to be synchronized into Azure AD and work best when business users log in with the Microsoft Azure authentication portal. As Active Directory Federation does not synchronize the hash to Azure AD, many of the protections offered with Azure AD identity are not available with this authentication method.

Multifactor Authentication (MFA). There are two forms of MFA supported in Office 365:

  • Office 365 MFA: this is managed through the Office 365 Admin portal, and is available to any consumer of the service.
  • Azure Active Directory (Azure AD) MFA: this is managed through the Azure AD blade in the Azure Portal, and offers tight integration into other security services.

Both types support application based push notifications (Approve / Deny), text message (SMS) and voice based One-time Passcodes (OTP). While the consensus in the security community is that SMS and voice based OTP are not secure, the use of any MFA will raise security significantly, and having some form of MFA is better than having none at all. Where possible, use application based push notifications as a second factor.

Microsoft outline the pros and cons of each service in this document. They also include links to further documentation on how to enable each type of MFA.

The Azure AD version of MFA offers extra protection when you include the use of Conditional Access (Azure P1 license) or Risk Based Conditional Access (Azure P2 license).

Conditional Access. Configuring conditional access specifies the conditions that must be satisfied before allowing use of the service.

While it can be somewhat tricky to do the initial configuration, it is worth the time as you can require a combination of conditions be present like: Trusted IP addresses, AD domain joined / Intune Compliant, type of app (legacy, browser, compliant app), MFA, Device type (Android, Windows, iOS), users/groups.

To make it easier to implement new policies, Microsoft added a “Report Only” toggle that allows you to test out your policies before enforcing them. There is also a “What if” feature that allows you to validate some combinations of conditions without needing to build the policy first.

More information on how to put together a Conditional Access policy is located here:

Azure AD Identity Protection. Requiring a Premium Azure AD license (P1 or P2), this service adds additional reporting of risky logins, which can help raise awareness of potentially compromised logins.

Here is a guide on how to turn this feature on:

Azure AD Password Protection. You can use this feature to restrict the use of easy to guess passwords along with their common letter substitutions. If you have P1 or P2 premium licensing, you can also extend this protection into your on premise Active Directory domain by installing an agent on your domain controllers. With the additional license, you also gain the ability to upload a custom word list for blocking commonly guessed passwords.

Here is the Microsoft document on this feature:

Limit Global / Exchange Administrators. Criminals that attack Azure AD / Exchange online tenants are themselves very competent Azure Administrators.

Limit the exposure by reducing the number of accounts in privileged roles (like the Global / Exchange Administrator roles) by using Privileged Identity Management (Azure P2), or by moving accounts into lower privileged groups (like Global Reader).

Make sure that any accounts that remain in those roles have MFA enabled. A “break-glass” administrator account should not have MFA enabled, and needs to have a long and complex password stored in a physical safe.

Securing Exchange Online

Exchange Online contains many different vectors of attack. Examples can include group spam, persistent access for email account compromise, all the way to the spoofing of your CEOs email address. Here are some ways to increase security in Exchange Online.

Disable third party app integration. Allowing end users to approve the use of Office 365 apps potentially allows malicious persistent access to their email mailbox.  Use the following document to turn this feature off to mitigate this risk.

If you have had this feature enabled in your tenant for a while, an Administrator should review the list of applications that have already been granted access in Azure AD, and remove any that do not have a valid business justification.

Disable auto-forwarding email.  If a criminal gains access to a user’s mailbox, they can configure auto-forwarding rules to redirect email from the users inbox to a criminally controlled outside email address. Well-meaning employees, who may set up forwarding of company data into personal email services while trying to increase convenience of use. Exploited more often in business email compromise attacks, auto-forwarding allows the criminal to exfiltrate sensitive data, mask their presence, and maintain some level of persistence after credentials are changed.

Three ways to mitigate this attack are outlined in this article:

Enable notifications. Email alerts can be set up to trigger when risky activity is detected. Go to and at minimum, enable the following rules:

  • Creation of forwarding/redirect rule
  • Impossible travel activity
  • Elevation of Exchange admin privilege
  • Users targeted by phish campaigns
  • Phish (High Confidence) Detected during delivery

You can see alerts that were triggered by going to, but note that more detail on each event is actually located in the Cloud App Security portal

Mark external emails with a banner. You can add text to an email if the sender originates from outside of your organization. This is useful to highlight inbound messages from external senders, especially spoofed emails from “the CEO”.

The basic steps to enable this feature are:

  • In the Exchange admin center, navigate to Mail Flow and create a new rule called “External Mail Warning”.
  • Set the rule as follows:
    • Set “Apply this rule if…” > The sender is located…  > Outside the organization
    • Click “More Options…. at the bottom of the rule dialog
    • Set “Do the following…” > Prepend the disclaimer… > Add text (or HTML if you want it to stand out).
    • Set “Choose a mode for this rule” > Enforced.

Disable Legacy Authentication. Basic Authentication (aka Legacy Authentication) is used by older applications like Outlook 2010 and earlier versions of Exchange Online PowerShell, and older protocols like POP3 and IMAP. This type of authentication attracts password spraying and credential stuffing attacks because MFA is not inserted as a further barrier.

First, you need to turn on Modern Authentication, and then monitor Azure AD Sign In blade for legacy “Client Apps”. Once you have migrated the users of those legacy applications to their modern counterparts, you can either use Conditional Access to block access to legacy applications, disable use of specific protocols, or disable basic authentication for Exchange Online altogether.

Enable Modern Authentication:

Monitoring Sign-Ins for Legacy app authentication:

Block Legacy authentication by app with Conditional Access:


Disable Legacy Authentication:


Disable individual protocols on individual mailboxes:

Disable app passwords. App passwords allow a user to create one or more passwords for use with non-browser applications that do not support Modern Authentication. Leaving this setting enabled is risky. Criminals use this feature to maintain persistent connectivity on compromised email accounts, and app passwords are not subject to the expiry policies applied to Azure AD or Active Directory on premise.

The feature can be disabled from either the Azure or Office 365 Admin portal:

Azure Portal:

    • Go to
    • Click on blade Azure Active Directory
    • Navigate to Users > All users
    • Click Multi-Factor Authentication
    • Click “service settings”
    • Under app passwords, select “Do not allow users to create app passwords to sign in to non-browser apps”

Office 365 Portal:

    • Go to
    • Click on Settings > Org settings
    • Locate and click Multi-factor authentication, then Configure multi-factor authentication
    • Click “service settings”
    • Under app passwords, select “Do not allow users to create app passwords to sign in to non-browser apps

Enable Mobile Device quarantine. While Intune and Conditional Access offer a seamless way to control access to email on a mobile device, they are only available for tenants licensed with P1 and P2, or have an enterprise mobility license. Exchange Online has a feature that allows you to quarantine mobile device connections to Exchange.

To enable the feature, open the Exchange admin center, navigate to Mobile, and create a rule to cover the device types you want to control.

Enable Mailbox Level auditing.  Mailbox auditing keeps a 90-day log of connections to mailboxes and the actions performed. Use this document to learn how to turn on auditing:

Enable Sender Policy Framework (SPF). SPF helps email administrators by reducing spoofed emails for their email domains. The key to enabling this feature is knowing about all email sources that could send email for your domain. Examples include internal email servers that send to outside recipients, Office 365, your marketing email provider and antispam solutions.

Once you have collected this information, you can use online SPF generators to create the record, and then you can apply the suggested TXT record change to your public DNS zone.

Note: If you maintain a split DNS zone (same domain name maintained internally and externally on different DNS servers), you will need to make sure both zones are updated with the TXT record.

Enable Domain Keys (DKIM) and DMARC.   DKIM provides a way to verify the sender of the email. The sender does not have to match the From information, it’s more about the server responsible for sending the email.

Like with SPF, you need to find all sources of emails from your domains, make sure they support DKIM, turn on the feature and publish the signature generated by DKIM for that mail source into the relevant DNS TXT record. Each mail source will have its own signature, and you will have one DNS record per mail source. If the mail sources support it, you can import a single signature in the TXT record.

DMARC allows other email systems to validate that the signature matches the one advertised for the originating mail server, and take the action prescribed in the DNS DMARC record.



Limit Calendar Sharing. If anonymous calendar sharing is enabled, your users can share the full details of their calendars with external, unauthenticated users. Calendars contain enough information to help attackers understand organizational relationships, gather information intended for internal parties, and determine when specific users may be travelling or more vulnerable to an attack.

To disable anonymous sharing:

Restrict email from outside senders to sensitive groups. Criminals can distribute malicious emails to your employees via the use email Groups. Your sensitive groups should be set to block mail originating outside of your organization. Pay particular attention to groups that have less characters in the user part of the email address (before the @ symbol). There is a good chance that spam engines already found them by cycling through letter combinations.

  • In the Exchange admin center, navigate to Recipients and then Groups.
  • Open each sensitive group, click on “delivery management” and select “Only senders inside my organization”

Last thoughts

Some features require more work to configure properly, while other features may cause varying amounts of change in end user workflow. With this in mind, here is my list of quick wins to increase Exchange Online security:

  • Enable MFA. Available in some form, regardless of the level you have purchased, it requires initial configuration, needs end user setup and introduces friction into the email login workflow. The security gained from this feature makes it well worth the effort, and end-users will eventually become accustomed to MFA use.
  • Disable third party app integration. No complex configuration required, and most users will not know that the feature exists.
  • Disable auto-forwarding email. This is very easy to do and shuts down a very commonly used method of persistence and data exfiltration.
  • Enable notifications. Configured correctly, you will get alerts when a compromise is detected. You can then follow up with the appropriate incident response.
  • Mark external emails with a banner. Providing visibility to end users will enable them to more easily identify spoofed emails from “their CEO”.
  • Above all, please communicate with your email users and listen to what they have to say! Announcing service adjustments ahead of time will allow them time to wrap their minds around the changes coming at them, and it is better to have them as champions rather than an insider threat. Ultimately, they are your last line of defense, so treat them fairly and keep them up to date with what you are doing to keep them and their email safe!

Implementing the features and controls listed in this document will help your organization raise the bar against criminals seeking access to the sensitive data in your email environment. I hope this document helps you to increase the security of your Microsoft Exchange Online tenant.

I would like to thank Jim, Ryan, Evan, Kenni and the 7MS Slack Blueteam members for all of their valuable contributions to this document.

Finally, you should be able to find an updated copy of this document at the following link:

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»