TechTip: Configuring Google Blogger custom domain on Squarespace

Here are the settings you need to use if you want to get your Squarespace domain to work as a custom domain on your Google Blogger blog. 

1. In Blogger, navigate to your blog settings and enter your domain name in the "Custom Domain" option under "Publishing" (you have to use a subdomain, so use the "www." prefix if you want this to be your "top level" domain, or use "blog." or whatever you desire):
   
   
   
   
   
2. If you're using the top level "www." prefix for your blog, don't forget to select the "Redirect domain" option as well:
   
   
   
   
   
   
3. Google now offers free SSL certificates for Blogger blogs, so go ahead an enable this as well (you will need to make sure to disable the Squarespace SSL support or your blog won't be available, we'll cover this in later steps):
   
   

   

   
   
4. Now, move on to the Squarespace dashboard, click on your domain and select "Manage Domain Settings".
   
   
5. Under "Advanced Settings", click on "Edit" next to "Nameservers Settings" and make sure that "Use Squarespace nameservers" is selected
   
   

   

   
   
6. Now, click on "Edit DNS" in the top-right corner, and make sure you set your custom DNS records as follows (you may need to delete the default DNS settings that are already in there from Squarespace):
   
   

   

   
   I am not including the IP addresses above as text, in case they change in the future, instead I'll point you to the Google Help article that contains the current IP addresses to use: Set up a custom domain. The only important bit is to make sure that you enter "@" in the "Host" field (and you do actually have to enter this, if you just leave it with the "@" that gets displayed by Squarespace by default, it errors out when trying to save the record).
   
   
7. Now, as mentioned before, let's turn off the Squarespace SSL/HSTS setting, to let Blogger handle this for your blog - go back to the Domain Dashboard for this domain, and click "SSL" in the left-hand navigation menu, then select "Insecure" under the options that come up:
   
   

   
8. One more thing, which I don't think is "required" but is a good practice and shouldn't have any adverse impact on functionality of your blog - on the Domain Dashboard for this domain, under "Advanced Settings", click on "Edit" next to "DNSSEC Settings" and toggle "DNS Security Extensions" to on:
   
   

   

That should be it. Give DNS records a few minutes to propagate and try accessing your domain, it should open your blog and automatically redirect to the secure https:// version of the URL (and if you're using the "www." prefix for your domain, it should automatically redirect to it).

TechTip: Stop WhatsApp from showing up when making calls through Android Auto (on Samsung devices)

This pet peeve took a while to figure out, and I couldn't find any answers or workarounds online or even through contacting WhatsApp support, so I am posting this here in case it helps someone. The annoyance is WhatsApp showing up when dialing numbers in your car via Android Auto. This adds an extra tap on the car screen, after having to read the display to see which entry to tap on (which can be distracting while driving, I don't know whose idea it was to implement this) in order to select the non-WhatsApp number after selecting the contact's name. WhatsApp support confirmed for me that there is no way to disable this, without getting rid of the app on your phone. I wanted to keep using WhatsApp but not have it show up on/route calls through Android Auto, so here is the workaround I found:

1. Back-up your WhatsApp chats and files
2. Uninstall WhatsApp on your phone
3. Setup "Secure Folder" (this is a Samsung Specific capability, but on other devices you can likely use "Shelter" to create a "Work Profile" for the same functionality)
4. Install WhatsApp in "Secure Folder" and restore it from backup

This will result in WhatsApp continuing to function on your phone, but no longer being accessible to Android Auto and thus showing up when trying to place phone calls from your car. You may need to fiddle with notification settings on the Secure Folder to get WhatsApp notifications to not be concealed when you receive messages. Hope this helps.

InfoSec: Threat Hunting Opsec

(This material was presented as a talk during the 2019 BSides Vancouver)

Operational security (or “OpSec”) is not a novel concept in the field of cybersecurity. Like the "DMZ" it is yet another term borrowed by infosec from the military terminology. OpSec refers to the practice of conducting operations in a manner that does not make the adversary’s job easier. Offensive operators tend to pay close attention to their OpSec when conducting their campaigns. Historically, poor OpSec has been one of the most common ways for attackers to get caught or have their identity unmasked. However, practicing good OpSec is just as important for defenders. Security Operations Centers, Incident Responders and Cyber Threat Hunting teams should always consider whether their conduct may help the attacker further their objective.

Experienced Incident Responders could likely recite several OpSec mantras if you woke them up in the middle of the night. "Don’t use a domain admin account for responsive actions," "don’t upload payloads to VirusTotal," and so on. Threat Hunting is often referenced as "Incident Response without an incident." As such, its OpSec goals are the same. However, the challenges in achieving them are rather unique.

If we are performing Incident Response, we already know that an incident has occurred. We are even likely to have at least a general idea of where the attacker is in the environment. Something happened to alert us to the activity. An alert was triggered, a report was received from an end-user, or a degradation of system performance has been observed, which pointed us to the suspected location of the attacker. From there, we can start to pull on the thread and follow the breadcrumbs. We can profile, scope out and, eventually, contain the intrusion. Knowing where the attacker may be, inherently helps us reduce the risk of them being tipped off to being discovered. 

Random Acts of Incident Response

When Threat Hunting, we do not have that luxury. We do not know where the attacker is. In fact, we do not even know if the attacker is in our environment at all. We formulate a hypothesis that if an attacker were in our environment, we would be able to observe indicators of certain techniques on certain systems. We then go out and check every system in scope of the hunt for the presence of said indicators. Now, what happens if the attacker is on one of said systems? What happens if they notice that you have just ran a check intended to identify them? That in a matter of minutes, as you review the results, you will be onto them? If the attacker realizes that you are about to disrupt their campaign, they may do something terrible.

Best-case scenario, if they are not yet close enough to their action on objective, they may decide to go covert. They will take the scorched earth approach and clean their artifacts from the environment. They will set up a low-and-slow C2 channel, or a scheduled reverse shell. And a few months out, when we are no longer looking for them, they will be back. That is a best-case scenario and, yet, we have failed our objective of eradicating them from our environment. Worst case scenario is the attacker deciding to expedite their action on objective. This can range from exfiltrating our crown jewels, to pushing a ransomware payload to every system in your network.

I think we can all agree that, depending on the severity of the resulting incident, this may lead to what we often refer to as a “resume generating event.” We will go from being the “good guys” - threat hunters trying to help our company reduce the attacker dwell time - to being what the industry refers to as a “root cause”. And a "root cause" is not a good thing to be. A "root cause" gets written up in incident reports. A "root cause" gets brought up in "nameless and rankless" post-mortems. A "root cause" is talked about in attorney-client communications. We do not want to be the “root cause.”

Enter Passive Data Sources

How can we minimize the chance of an OpSec failure turning us into a “root cause” while we are threat hunting? One of the most effective measures is the use of passive data sources. This is likely something that most are already doing out of convenience anyways. I am referring to tools that abstract the logs, metadata, and telemetry information away from the endpoints where the attackers might be present. There, we can analyze the data without the risk of attackers realizing we are looking at it. Data sources like SIEMS and EDRs fall into the passive category. They enable us to stack, pivot and analyze indicators without any chance of attackers being tipped off to us doing it*. I have added an asterisk to the last statement so that we can get back to it later.

Here are some examples of the passive data sources that we can use for Threat Hunting:

• EDR: Tanium, Carbon Black, CrowdStrike, SentinelOne, Sysmon, PowerShell (Oriana)
• SIEM: Splunk, ArcSight, Qradar, LogRythm, ELK, Greylog
• NTA: NetWitness, StealthWatch, Vectra, Awake, Snort, ExtraHop, Zeek, Moloch, Security Onion, RITA
• OSINT: VirusTotal, Hybrid Analysis, URLscan, Mnemonic PDNS, PassiveTotal

One could argue that the “OSINT” sources listed above are not in the same category. They tend to not make our environment telemetry available for offline hunting. However, they can be very helpful for indicator and finding validation, so I will still cover them in this section.

Are They Passive?

Before hunting within passive data sources, it is important to understand how they work and if they are indeed passive. For example, a well-known EDR solution, Tanium, does not abstract the data away from the endpoints in its base implementation. It queries the data on demand, whenever a question is issued. This can be observed on the endpoint, alerting the adversary to the hunting activity. Another common example of a data source that can turn from passive to active is VirusTotal. Searching for a file hash in VirusTotal is perfectly safe from an OpSec standpoint. Uploading that file to VirusTotal for analysis will cause an OpSec failure. If the uploaded payload is unique to your environment, external parties will see a new scan result for that hash the moment it is uploaded. They can then conclude that they have been discovered. This happened to RSA Security in 2011 - someone uploaded the initial phishing email containing the zero-day payload to VirusTotal, allowing the public to perform attribution on the attack. Similar considerations apply to performing public (vs. private) page scans in urlscan.io, and to other OSINT data sources.

Securing the Data Sources

Another important aspect of using passive data sources is making sure that they cannot be accessed by the adversary. *This is where that asterisk from above comes in. This is where we get to “drink our own Kool-Aid”. Where we get to practice all those controls that we have been preaching to our users for decades. Password complexity, role-based access control, multifactor authentication, principles of least privilege, etc. It does not matter if our data sources are passive if an attacker can gain access to them. With access to our SIEM or EDR, attackers will be able to observe our hunting activities and adapt their TTPs to avoid detection. They may also use them to their advantage: identifying our crown jewels and high-value targets, modifying configurations and purging logs to avoid detection, leveraging remote execution capabilities to deploy their payloads. In the wrong hands our data sources become a powerful weapon. And if we end up arming the adversary with our own tools... well, you get it - "root cause."

Beyond the Passive Data Sources

Fast forward some months. We figured out and secured our passive data sources. We can threat hunt in our environment in an OpSec conscious manner. With this being the real world, we eventually come across a system where our SIEM or EDR just do not get us the visibility we need. We find that eventually we must take a measured OpSec risk and connect to the actual endpoint to get the information we need. Here are some things that we can do to improve your OpSec when forced to hunt on actual endpoints.

Attribution is a Two-Way Street

The funny thing about attribution is that it goes both ways. When an adversary enters our environment, they do not create new accounts with identifiable names (e.g., APT37). Instead, they “live off the land,” using existing accounts that they managed to take over. Or, if they must create one, they will observe and follow our account naming conventions. They do this to blend in and avoid detection by masquerading as common activity in our environment. We can borrow a page from their playbook. We can also use accounts and systems that cannot be attributed back to us when we do Threat Hunting. We already know the accounts whose activities most closely resemble Threat Hunting activities in our environment. In most environments these are vulnerability scanning or asset management discovery accounts. We can work with the corresponding teams to create accounts that, for all intents and purposes, appear to be owned and operated by them. Create some source systems that appear to be owned by them while you are at it. This way should the attackers observe our hunting activity, they will most likely assume that it was just another recurring asset inventory scan. Of course, they will still try to steal those credentials for their purposes (see the beginning of this paragraph), so let us address this next. 

Accounts are Free, Compromises are Not

When an adversary observes accounts connecting to systems under their control, they will absolutely attempt to steal those credentials. As the adage goes - “two is one, one is none.” An attacker with only one privileged account is one password change away from being locked out from the environment. They will attempt to gather additional credentials, including those unattributable accounts that we created for hunting. And that presents another opportunity for becoming the “root cause.” We should always limit the level of privilege that we grant to the accounts used for hunting. If all we need is to be able to pull running processes from workstations, we should set the account permissions for our environment accordingly. If all we need is the “badPwdCount” attribute in Active Directory (for statistical password spray detections) - we should have an account just for that. Accounts are free, compromises are not. Another option for limiting privileged credential exposure is to use unique per-system local admin accounts. While slightly more complicated to implement, solutions such as Microsoft LAPS, CyberArk or Hitachi ID make it possible. Unique local accounts can be used for hunting, with no risk of giving attacker access to additional systems in our environment. And we should never ever hunt using a full-fledged Domain Admin account! 

Another way to reduce the likelihood of attackers stealing our Threat Hunting credentials used for hunting, is choosing how we execute commands on remote systems. For example, PsExec uses local authentication and will most likely expose your credentials to the attacker running Mimikatz or Flamingo on the target endpoint. PowerShell Remoting (without the CredSSP option), uses network authentication and makes it nearly impossible to obtain the credential locally. Some EDR vendors also offer functionality to execute scripts on remote endpoints. This being done in the context of the EDR agent reduces the risk of shared credential exposure during remote command execution. But we need to make sure that we understand how our EDR does this, before choosing this option. SentinelOne on Windows and OS X, for example, creates a new local admin account when remote shell functionality is used. While not giving the adversary access to shared credentials, it will most definitely alert them to the fact that someone is snooping around on the system within their control. Queue the "root cause" conversation…

Summary

Maintaining good operational security is an important aspect of a mature Threat Hunting capability. Use passive data sources as much as possible. EDRs, SIEMs, Netflow and packet capture are your friends. Make sure you understand how your data sources function and how to secure them. Make attribution of your activity to the Threat Hunting difficult for attackers. Hide in the noise, masquerade as non-hunting teams, name your accounts and your source systems accordingly. Control your credentials. Never use a domain admin account for hunting. Consider which services and protocols you use to connect to target systems. Avoid becoming the root cause.

TechTip: Microsoft Outlook rules for auto-forwarded messages

At some point, one of the managers in the organization decided to forward all announcements from a particular vendor to the entire team, as an FYI. This got a bit noisy, so I had to research how to create an Outlook Rule to automatically filter all auto-forwarded messages from this sender into a separate folder.

The answer is to create a rule that looks for the "X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent" message header. Do do this:

1. Start the "Create rule..." wizard in your Outlook.
2. On the first, "Select conditions" step, choose "with specific words in the message header".
   
   
   
3. For the words, add "X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent" and click "Add", then "Ok".
   
   
   
4. Add any other conditions you would like to match before taking the actions (e.g. the "Sender:" address on the message).
5. Select the actions you would like to take on matching messages in the next step.
6. Finish naming and creating your rule.

All future auto-forwarded messages matching your conditions will be filtered by this rule.

InfoSec: RegEx to Match Linux "Cover Your Tracks" Commands

There are a number of commands that may be used to conceal nefarious activity on a Linux system, mostly through removing or overwriting the shell history files and logon activities:

kill -9 $$
history -c 
export HISTFILESIZE=0 
export HISTSIZE=0 
unset HISTFILE
echo "" > /var/log/auth.log
ln /dev/null ~/.bash_history -sf
rm ~/.bash_history -rf
echo "" > ~/.bash_history
shred -zu ~/.bash_history

Here is a quick-and-dirty RegEx to match on these when hunting through your EDR or system logs:

((rm|ln|echo|shred).*\.bash_history.*)|((export|unset) HIST(FILE)?(SIZE=0)?)|(kill -9 \$\$)|(history -c)|(echo.*\/auth\.log)

Enjoy.

TechTip: "afterSentDocuments" folder under "My Documents"

Just a random bit of information that proved to be rather difficult to find online for some reason, so in the spirit of this blog I am sharing it just in case it helps save time for someone else.

"afterSentDocuments" folder under "My Documents"

The "afterSentDocuments" folder under "My Documents" (or just "Documents" for Windows 10 users) is created by the SentinelOne endpoint agent.

The contents of this folder actually come from an archive located in the SentinelOne Agent installation folder under "C:\Program Files\SentinelOne\Sentinel Agent x.x.x.x\afterSentDocuments.zip"

These are not malicious. While undocumented, they are used for some internal SentinelOne scanning/encryption mechanisms. Hope this helps.

InfoSec: Querying the Recorded Future API using PowerShell

Recorded Future has a great Connect API with many options to retrieve, search or download every type of IOCs they offer as part of their subscription. Unfortunately, as most API providers out there, they only publish the instructions for accessing the API using common tools/languages (e.g. cURL, Python).

If you have a need to query their API using PowerShell because, for example, you are looking to add reputation checks to your O365 PowerShell Online script (or if you just prefer PowerShell), this post will hopefully save you a few minutes figuring out how to pass the API key to their API in the Invoke-WebRequest cmdlet.

Unlike most SaaS providers that make their API available for consumption nowadays, Recorded Future is different in that it does not require a username to be provided for API authentication. All you need is the key. Then, add the following property to your Invoke-WebRequest cmdlet:

-Headers @{"X-RFToken" = "api_key_here" }

So, for example, if your API key was "827ccb0eea8a706c4c34a16891f84e7b" (not an actual API key), a command to download the Recorded Future hash risk list would be:

Invoke-WebRequest -Headers @{"X-RFToken" = "827ccb0eea8a706c4c34a16891f84e7b" } -Method GET -ContentType "application/json" -Uri "https://api.recordedfuture.com/v2/hash/risklist?format=csv%2Fsplunk&gzip=false&list=positiveMalwareVerdict" -OutFile "out.csv"

Where to Find the Recorded Future API Key

Once you have your subscription and access to Recorded Future, you can get (or, rather, create) your API key under Menu - User Settings:

Click on "API Access" and use the "Generate New API Token" link to create a key, which will then be displayed in the list below (again, this isn't an actual API key):

Recorded Future API Documentation

Better than documentation, Recorded Future has a fantastic Connect API explorer page where you can, after plugging your API key in the top-right corner of the page, test all available API commands:

This page can be accessed at https://api.recordedfuture.com/v2/

A Note on Licensing

As expected, every API query uses up one usage "credit", but it should be noted that some of the queries (like the hash risk list used in the above examples) use up 5 credits per use. This can add up quickly when you're developing/testing something.

However, the Recorded Future's handy browser extension does not eat up your API credits.

Troubleshooting

If you get the following error, you need to add this to your code, to force the Invoke-WebRequest cmdlet to use TLS1.2:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Error:

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At line:1 char:1
+ Invoke-WebRequest -Headers @{"X-RFToken" = "827ccb0eea8a706c4c34a16891f84e7b...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Enjoy!

InfoSec: Online resources and tools for network forensics and cyber threat hunting

Following is a list of free online resources that I have found to be indispensable in the daily network troubleshooting and information security forensic investigations. I will keep updating this list as I remember of or discover more useful tools, but certainly feel free to contribute in the comments if you have any favorites that are not listed here. Last updated on 1/20/2019.

IP/MAC

IP Address Locator
http://www.geobytes.com/ipLocator.htm

By far the best and most accurate geolocating service - will tell you where the IP address is located geographically, what time zone it is located in and whether or not it is a proxy.

Mass Country of Origin Lookup
https://www.infobyip.com/ipbulklookup.php

Great tool for checking the sources of a DDoS attack - will take a list of IP addresses, one per line and return the IP, domain, location, ISP and ASN for each.

MAC Address Lookup
http://www.coffer.com/mac_find

Utility for searching the IEEE MAC address assignment database - quick way to identify what type of device is located at the MAC address in question.

What's My IP
http://www.whatismyip.com/

As the name implies, shows you what your public IP address (and its geolocation) is.

WolframAlpha Subnet Calculator
http://www.wolframalpha.com/input/?i=address+range

Very flexible IP subnet calculator, lets you calculate IP address ranges based on number of addresses needed, subnet mask bits or numeric subnet masks.

TechZoom IP Calculator
http://www.techzoom.net/tools/network-ip-calculator.en

Another handy multi-purpose IP address calculator, has ability to calculate subnets and convert IP address masks into individual address lists. Also includes IP and domain name checkers.

DNS

Robtex DNS Lookup
https://www.robtex.com/

Extremely comprehensive "DNS Lookup" site that goes way beyond just DNS lookups. Can be used to lookup BGP routing and AS information for IP addresses, for example.

DNS Analyzer
http://www.intodns.com

Amazingly detailed DNS information reporter and status analyzer. Will show a slew of details about a specified domain name, including but not limited to NS, SOA, MX and WWW records, reverse records, duplicate records, et cetera, and warn you of any configuration that does not follow the best practices.

DNSDigger
http://www.dnsdigger.com/

Great tool for finding other hosts/servers on the subnet of the domain name in question. The only drawback is that it does not offer a reverse lookup option (enter the IP address range, get the domain names of all the servers), but this can be partially remediated by doing a reverse search in cached Google results: http://www.google.com/#hl=en&q=site%3Adnsdigger.com+66.102.13.103

URLQuery
http://urlquery.net/

Similar to DNSDigger, another great tool for looking up domain names for the IP addresses that may show up in your IPS logs. Again, you can leverage Google's cache if needed: http://www.google.com/search?&q=66.235.180.91+site%3Aurlquery.net Note: this site can be reported as malicious by reputation services such as WOT, perhaps due to links to malicious domain information contained within. Proceed with caution.

ViewDNS IP/DNS Toolkit
http://viewdns.info/

Handy multi-tool website that can perform a variety of tasks, such as looking up WhoIs information, DNS resolution, host traceroute, etc.

DNSStuff Toolkit
https://tools.dnsstuff.com/

Similar toolset to the one above, but with a much wider range of tools. Kind of like a Swiss-army knife of IP an DNS address tools.

Email

Email Header Analyzer
https://mxtoolbox.com/EmailHeaders.aspx

Convenient tool to quickly analyze email headers. Breaks down all the flags into a convenient, easy to read table and calculates delivery delays (with graph) for each hop. Has a link on the bottom to "forget" the header details when you're done with them.

Reputation Databases

Web Of Trust
http://www.mywot.com/

"Crowd-sourced" web reputation service which works by letting its users rank sites they visit in four categories. May contain false positives but is most likely to have ratings for more obscure sites.

McAfee TrustedSource
https://www.trustedsource.org/

Great tool for checking web reputation of a specific domain name. TrustedSource databases are used by McAfee GTI and many spam filtering vendors, so if your emails stop getting to their destination - good place to check whether your SMTP server has been blacklisted. Will also show any recent increases in outgoing email activity, so it could be handing for spotting first signs of infection.

McAfee Website Reputation Database
http://www.siteadvisor.com

Another site by McAfee, which complements the TrustedSource IP and domain name reputation database. Will show any harmful files and behaviours (such as exposed user email addresses, etc), linked websites and annoyances, along with user-contributed feedback (useful for identifying spammer or phishing websites).

Norton Safe Web
http://safeweb.norton.com/

Similar to McAfee Site Advisor but will contain specific malware names and locations.

BlueCoat WebPulse Site Checker
http://sitereview.bluecoat.com

This one isn't extremely useful as it does not provide much detail, but can be used to verify how BlueCoat categorizes a specific site in their database. This database is also used across all BlueCoat proxy and web-content filtering appliances.

VirusTotal URL Checker
https://www.virustotal.com/#url

The popular multi-antivirus online file scanner, now owned by Google, has added the ability to scan provided URLs against over 50 different URL reputation services. Has ability for users to rank the URL "maliciousness" and provide comments. Great resources for quickly gauging if an address is safe.You can also use their "Search" tab to view Passive DNS history collected in previous lookups of the domain.

ThreatStop
https://www.threatstop.com/checkip

Crowdsourced searchable database of active and historical threats for IP addresses and domain names. A bit annoying in that on the first check, it asks you to receive and click an email link.

Endpoint Forensics

Windows Registry Cheat Sheet
https://www.dfir.training/resources/downloads/windows-registry

Massive crowd-sourced cheat sheet of key Windows Registry locations.

Network Forensics

RiskIQ Community (formerly PassiveTotal)
https://community.riskiq.com

Not to be confused with VirusTotal, PassiveTotal (which has now been acquired by RiskIQ) is a fantastic tool for searching current and historical information on IP addresses and domain names. The free community tier does give you a limited number of lookups per day, but this tool is fantastic for looking up historical WhoIs records, passive DNS records, current DNS records, and other available information.

Mnemonic PassiveDNS
https://passivedns.mnemonic.no/

Another great open PassiveDNS repository. No registration required.

hpHosts
http://hosts-file.net/

Crowdsourced "host file" - community built database of IP address and domain name resolutions and reputations. Can be really, really slow to load for the first time, don't give up.

Port Information Lookup
https://isc.sans.edu/port.html?port=

Invaluable tool for port information lookup, powered by the voluntary contributions to the SANS ISC log database. Will show both legitimate and malicious services (backdoors, trojans) that most often use the port, any CVEs associated with it, as well as any recent statistical increase in port activity worldwide. A must have in the arsenal of any network forensic investigator.

SpeedGuide Port Information Lookup
http://www.speedguide.net/port.php

Another excellent port information look-up tool. Does not have the same trending details as the one above, but often has a lot more details about the possible applications utilizing the port, including user-contributed comments.

Open Port Check Tool
http://canyouseeme.org/

Quick and easy utility for checking whether a port is open on the public IP address you're coming from. Will also show you your public IP address, so it can be used instead of the above tool.

Shodan
https://www.shodan.io/

"Search engine for the internet of things". Basically a huge online database of worldwide Nmap scan results. Lets you search for IP address, ranges, organizations, ports or keywords and returns anything that matches and could be seen connected to the public internet in the past few weeks.

Censys
https://censys.io/

Basically the same thing as Shodan, but also shows a pretty map. In my experience the results are not nearly as complete as Shodan.

ZoomEye
https://www.zoomeye.org/

Another Shodan alternative.

Log Analysis

Windows Security Log Events
http://www.ultimatewindowssecurity.com/securitylog/encyclopedia

A very extensive repository of Windows security log event IDs, failure codes and fields.

Event ID Information
http://www.eventid.net

A searchable event ID database, containing event ID descriptions from various sources and applications.

Avaya/Nortel Trace Analyzer
http://sharontools.com/tools/NortelDiagnostic/NortelDiagnostic.php

Shows the Nortel Passport (Avaya ERS) 8600/8800 trace file as a sortable table, helps to determine what is causing high CPU load and allows you to see a sortable table of MAC addresses, IP addresses and Ports.

Malware Analysis

VirusTotal
https://www.virustotal.com

Perhaps the most well-known multi-antivirus online scanning tool, now owned by Google and offering even a desktop-client for right-click uploading of suspicious files. Scans the files with dozens of various antivirus clients and has a user-contributed rating and comments system.

MetaScan
https://www.metadefender.com/#!/scan-file

Very similar to VirusTotal, with fewer antivirus engines but allows for a larger file size. Does not have the same community feedback mechanisms, but handy for double-checking VirusTotal or those cases where you need to scan a file just bigger than its 64Mb limit.

Payload Security Hybrid Analysis
https://www.hybrid-analysis.com/

Free malware analysis service powered by the VxStream Sandbox, which can be used to detonate executables, Office, PDF and APK files up to 180 Mb in size in a sandbox environment.

Browser Sandbox
https://www.browserling.com/

This isn't exactly a malware analysis sandbox, but it does offer the capability to open a website in a virtual browser. Very handy when a lab environment isn't available and you need to check what a suspicious URL looks like when opened.

Malpedia
https://malpedia.caad.fkie.fraunhofer.de/

Online encyclopedia of malware families.

Sucuri Site Check
https://sitecheck.sucuri.net/

Quick scanner for known website vulnerabilities and embedded malware. Will try to sell you the Sucuri WAF every time you run it, but can be handy in identifying/confirming site compromises and seeing exactly where the injected code is.


JavaScript Deobfuscator
http://deobfuscatejavascript.com/

Very effective JavaScript deobfuscator - saves you time figuring out what the final code looks like in obfuscated JavaScript payloads.

Malware Domain List
https://www.malwaredomainlist.com/mdl.php

Searchable database of known malware/C&C domains and IP addresses.

Cyber Chef
https://gchq.github.io/CyberChef/

A proverbial swiss army knife of parsing, decoding and converting just about anything you can think of.

Miscellaneous

Website Status Checker
http://downforeveryoneorjustme.com/

If you run into a website that will not load from your network, and you're wondering if it's something to be concerned about or the website is really down for everyone - the above site is a very quick and easy way to verify that.

Website Redirect Tracer
http://www.wheregoes.com/retracer.php

Most malicious spam/phishing campaigns nowadays use multiple redirects between the link included in the email, and the final payload page. This will trace and show you all the redirect URLs, without opening the final malicious destination.

Hex to ASCII to HEX Converter
http://www.dolcevie.com/js/converter.html

Very simple and easy to use HEX to ASCII and ASCII to HEX converter.

RegEx Composers
http://www.regexr.com/
https://regex101.com/#javascript

Great tools for composing and testing Regular Expressions (RegEx).

TechTip: How to do DNS lookups in Splunk

Being able to perform DNS lookups, either forward or reverse, within your Splunk searchers can be very helpful for identifying indicators, or correlating different types of logs. There are a number of apps available on Splunk Base (e.g. Forensic Investigator, Network Toolkit) that extend this functionality, but as it turns out - this is also supported natively in the form of an external lookup called "dnslookup":

To use this lookup, all you need to do is pipe your search into the "lookup" command, selecting the field corresponding to either reverse ("clienthost") of forward ("clientip") lookup, and an existing field to run the lookup on.

Forward Lookup

| lookup dnslookup clienthost as hostname

Where "hostname" is the field in your search, containing domain names that you're looking to get the IP addresses for. Resulting IP addresses will be added to each event as the "clientip" field.

Note that in cases where multiple IP addresses are returned by the lookup, the "clientip" field will be a multivalue field and will need to be handled as such.

Reverse Lookup

| lookup dnslookup clientip as ipaddress

Where "ipaddress" is the field in your search, containing domain names or hostnames that you're looking to get the IP addresses for. Resulting domain names will be added to each event as the "clienthost" field.

Tip

If you want to run DNS lookups against a field containing a URL, you need to split the domain name out of it first. This can be accomplished using a couple of eval commands:

| eval temp=split(url_field,"/") | eval domain=mvindex(temp,0)

Then just run the "dnslookup" lookup against the "domain" field.

TechTip: Look-up Active Directory username from SID using PowerShell

Occasionally, you will come across an SID (security identifier) in your DFIR investigation, or threat hunting, that you may want to convert back to to the Active Directory user or group name.

According to this helpful TechNet script, you can do it like this:

$objSID = New-Object System.Security.Principal.SecurityIdentifier (sid_here) 
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount]).Value

There is also an easier way, if you have the Remote Server Administration Tools installed on your machine:

Get-ADUser -Filter {(SID -eq "sid_here")}

Only caveat, is that the SID might be for a group, not a user. So if you run the above command, and you don't get a result, try it with the "Get-ADGroup" command next:

Get-ADGroup Filter {(SID -eq "sid_here")}

Of course, if you don't have your PowerShell updated to version 5, you will also need to manually load the ActiveDirectory module first, using this easy command:

Import-Module Active Directory

Some additional tips:

• If you need to run the query with a different account, you can prompt yourself for the credentials, then use the credentials in the above query:
  
  $credential = Get-Credential
  Get-ADUser -Credential $credential -Filter {(SID -eq "sid_here")}
  
  
  

• You can also get the above query to return all the properties of the user/group that you're looking up by adding -Properties * at the end:
  
  Get-ADUser -Filter {(SID -eq "sid_here")} -Properties *
  Get-ADGroup Filter {(SID -eq "sid_here")} -Properties *

TechTip: Better Printing for Your Pocket Articles (using Firefox and Stylish)

I will be honest, Pocket is hands down my favorite "Read Later" app, mostly because it's natively available on my Kobo eReader. I can save internet articles from Firefox, Mobile or Twitter (using IFTTT) and read them later on a comfortable front-lit eInk screen. In fact, this is how I do most of my catching up on the information security industry happenings, and choose what to later print out into a PDF for long time archiving and sharing.

This is where the pet peeve of mine comes in. In an effort to be more readable, Pocket adjusts the width of the reformatted article in its web interface to something like 700 pixels:

This makes it great to read in the browser, but when you print the page (into PDF, for example), it ends up looking like a printout for ants:

The Fix

Fixing this is surprising easy, especially if you already use Stylish in your Firefox:

1. If you don't already have this useful add-on , go out and install Stylish
2. Go into "Manage Add-Ons" menu (or press Ctrl+Shift+A) in Firefox and click on "User Styles"
   
   
   
   
3. Click "Write New Style" and name it something like "Print Pocket"
   
   
4. In the body of the new style enter (you can copy-paste the code below):

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("getpocket.com") and media print {
  .reader_content
  {
    min-width: 100% !important;
  }
}

5. Click Save and reload the Pocket page/article:
   
   

Now when you print articles out of Pocket web, they will be much more readable, and the best part is - your Pocket reading experience remains completely unaffected:

In closing, since you've already installed Stylish in your browser, try to play around more with the custom styles for other websites. It's great for removing oversized headers, making background and text colors more readable and just generally making the web look the way you want it to look.

TechTip: Receiving a "file type is not supported" error message when trying to share a PDF in Cisco WebEx

Cisco WebEx is one of the most feature-packed web conferencing platforms on the market today. Among its many features, it lets the presenters directly "share" (display on the screen) the contents of various file formats, by uploading them into the WebEx session instead of simply streaming the live view of their screen for that application. This offers multiple benefits, such as giving participants the ability to switch between multiple shared documents on their side, annotate the documents in WebEx, and save those annotations. Multiple file formats are supported for direct sharing, such as Microsoft Word documents, Excel spreadsheets or (Adobe) PDF files.

The Problem

However, you may at some point (typically after a system refresh or reinstallation/upgrade of your PDF viewer program) come across the following error message when attempting to share PDFs through your WebEx client: "We could not share this file because this file type is not supported for file sharing. Either convert the file to a supported format or use application or screen sharing to share this file."

The error message is rather obscure and doesn't point at all at what the root cause could be. If trying the feature for the first time - one might even assume that PDFs are just not supported by WebEx, period, and give up. I was able to share them before, so I went looking for a fix.

The Solution

Turns out that WebEx Document Viewer relies on the native local file format viewer to render and share the file contents. What this means for this particular problem is that, for some reason, your system does not have the default viewer configured for PDF files.

Note: When this was happening on my system, Adobe Reader was set to be the default viewer for PDF files, however, it was done through "Default Programs" setting in the Windows Control Panel, and evidently that was not enough.

The easiest way to fix this is to go into your preferred PDF viewer application, go through it's properties, find and set the native setting selecting it as the default viewer. Do this even if it already has this option selected - it was already on mine, but until I re-selected and applied that option in Acrobat, WebEx was refusing to recognize it as the default application, despite Windows using it to open PDF files.

Adobe Acrobat

In Adobe Acrobat this setting can be accessed using the following steps:

1. Open the Adobe Acrobat application
2. Navigate to the Edit --> Preferences menu (or press Ctrl+K)
3. In the menu on the left, select the "General" category
4. On the very bottom of the right section of the screen, click "Select Default PDF Handler"
5. Pick the desired Adobe product and click OK

If you are using non-Adobe products as your default PDF viewers, search the internet for steps on how to set them as default, but try to find the native setting and not rely on the Windows "Default Programs" or "Open with... --> Always use..." setting. Evidently, it doesn't always work.

InfoSec: McAfee EEPC drive status showing "Partially Encrypted" in ePO

McAfee Endpoint Encryption for PC (formerly SafeBoot) is an enterprise-level solution that allows enterprises to deploy full-disk encryption to managed workstations. One of the many benefits of the solution is the centralized management and reporting capability, which enables asset management teams to report on the encryption status of lost or stolen assets (thus differentiating between a benign asset loss event or a possible full-blown "unencrypted device" data loss incident). Employee reported their laptop stolen? Not a problem, login to ePO, search for their system either by system name or employee's username and check the corresponding tab to see if it is encrypted (see steps 1 through 4 below).

Unfortunately, according to the McAfee KB76098 article, there is a known cosmetic issue with EEPC versions 6.2 Patch 1 and earlier, which results in obscure reporting of the device drive encryption status as "Partially Encrypted", if it has any hidden/system recovery partitions. This may, understandably, send your incident response and risk management teams into a possible "unencrypted device loss" investigation frenzy, despite the primary partition (usually the "C:" drive) being actually encrypted in its entirety. Luckily the solution is available (according to the article, updating to EEPC 7.0 addresses this) and the workaround is fairly straightforward.

How to Check the Volume Encryption Status

1. First, login to your ePO console and locate the system you are investigating in the System Tree.

2. Click the "Drive Encryption" tab under the system view (this may be named something like "SafeBoot" or "Endpoint Encryption" if you have older versions of ePO or corresponding components), confirm that the "State" is "Active" and click the "More" link on the bottom-left of the screen:

If the "State" doesn't say "Active", you may indeed have an unencrypted asset on your hands - proceed accordingly.

3. Once the Drive Encryption details window opens, you want to go to the "Disks" tab, to see the actual HDD drives detected in this particular system:

4. Here is where you would see the worrisome "Partially Encrypted" message, suggesting that not all of your user's data was encrypted:

Don't jump to conclusions yet - go ahead and click on that entire line to load the Disk Details page.

5. On the bottom of the Disk Details page, click on the "Go to related Disk Volumes" link - this will let you see what volumes are detected and what their individual encryption status is:

6. Once the list loads, confirm whether all system and data partitions are encrypted:

As you can see, this particular 115 Gb drive had a 95 Gb system partition (Drive "C:") which was indeed encrypted in its entirety, and it did not have any other unencrypted data partitions, like the "Partially Encrypted" status would lead your incident response team to believe. The remaining 20 Gb was a dedicated "system recovery" partition with the blank image of the laptop's "factory default" operating system, and it was in fact, also encrypted.

What we were seeing, was the manifestation of the KB76098 cosmetic bug affecting EEPC versions 6.2 Patch 1 and older, where hidden partitions caused ePO to falsely report the drive as "Partially Encrypted", when system/data partition size did not match the total drive size. The hidden partitions still got encrypted (we have confirmed this using Encase), but wouldn't get reported to ePO, causing this issue with erroneous partial encryption reporting.

As mentioned above, this is addressed in newer versions of McAfee EEPC/ePO, but in the meantime - you can use the above steps to get your incident response guys off the ledge, whenever a "Partially Encrypted" device gets reported as lost or stolen within your organization.

InfoSec: Check if an email message or a website is malicious

Spam (unsolicited bulk messages) and phishing (obtaining privileged information by masquerading as a trustworthy entity) have become a part of everyday life for anyone who uses email for personal or business communication. Cyber-criminals behind spam and phishing messages have been perfecting their craft for decades and, as a result, it is often difficult to distinguish spam from legitimate emails. Some observational techniques could be helpful and a number of services exist to assist with verifying reputation of various websites and phone numbers, which can be used to gauge the validity of a received email.

While the sender address is a good first indication of whether an email message is legitimate or not (for example, an email that claims to be from AMEX, but was sent from “bob@comcast.net” is almost certainly malicious), but it is worth noting that sender address is very easy to fake (aka “spoofing”). Just like the return address on “snail mail”, the sender information is provided by the sender himself and, in majority of cases, not verified by the email server. Do not rely on the sender address alone for validating the identity and validity of the sender.

The goals of a spam or phishing messages will usually boil down to one of the following:

1. Getting you to click a link in the message
2. Getting you to open the attachment in the message
3. Getting you to call a number and provide information
4. Getting you to reply to the message with requested information

Generally, if you have any doubts about the origin of the message, it is best not to do either of the above. However, if you do think that the request may be legitimate (again, keep in mind that spammers are getting very good and making you think that, that is their 'bread and butter'), here are some tips on how to attempt to verify each of the above before you proceed.



How to check if something is malicious

Links/Websites: following free services will let you copy-paste the link from a suspect email message and check the validity/potential risk rating of that link:

https://www.mywot.com/ - this is a “peer review” site, where site’s ratings are contributed by other site users; so if Bob and Alice say that a site is bad and Jim later goes to check the site’s rating – he will see the previous negative feedback. Anybody can review the site and the service offers a free browser plugin to automatically alert against visiting sites with numerous negative reviews.

http://www.siteadvisor.com/sites/ - this is a service that is very similar to the one above in functionality but is now offered by McAfee. All site reviews are provided by McAfee staff (however, individuals can submit their recommendations on suspect websites). This service also offers a browser plugin for automated website and search validation.

https://www.virustotal.com/#url – free service now owned by Google, which will check the site’s reputation against 51 different reputation services, similar to the ones listed above. It will not show any details on the reputation, but will provide a summary judgment as to whether it could be trusted or not. There is also a section for users to leave comments on each of the URLs but it doesn't seem to be as popular as the MyWOT one. Same service offers antivirus scanning for attachments, but more on that later.

Files/Attachments: following services will let you upload a file to be scanned by an antivirus, other than the one that is already (hopefully) present on your computer. You can save a copy of the file to a folder on your computer and upload it to be scanned from there; do not double-click/open the file and always use your local antivirus to scan the file first. Please note that personal/sensitive data should not be uploaded to third party services, as there is no telling what might happen to that file after it has been scanned.

https://www.virustotal.com – service owned by Google which will let you upload the suspicious file or email attachment, to be scanned by 46 different antivirus programs. Antivirus programs are only as good as their signature definitions and often one or two of them will be able to detect a certain virus variant before everyone else creates a signature for it. This lets you make sure that none of the antivirus vendors think the file you’ve received is malicious.

https://www.metascan-online.com – another service similar to the one above, which will scan an uploaded file with 42 different antivirus programs. All the same limitations apply, but the permitted file size is slightly higher.

Please note that just because an antivirus does not detect a virus in the file, it doesn’t mean that it isn’t there. Antiviruses can generally only detect malware that they are aware of, and a new variant, or a variant encrypted in a password-protected ZIP archive, for example, will not be detected. Be extra vigilant if files are sent to you in password-protected archives, this is a common technique used to bypass antivirus detection.

Phone Numbers: confirming phone numbers can be tricky because a large number of websites offering phone number reputation services are “commercialized” and require you to pay for the information. So far only the following website, using information provided by other users, has been free and consistently accurate with identifying suspicious phone numbers:

http://800notes.com/ - website similar in functionality to MyWOT, where users are able to contribute their experiences with a certain phone number to an overall number review page. Keep in mind, that while this can be used to validate phone numbers included in an email, one should not rely on it for phone numbers on received calls. Similar to the sender address on email messages, caller phone numbers can be easily spoofed to masquerade as any other number and this is a technique often used for social engineering attacks.





In conclusion, you should always avoid clicking links or opening attachments in emails that you did not expect to receive, even if they appear to be sent by someone you know. Even the most legitimate-looking messages may be phishing for your sensitive information, to be used for identity theft or further attacks against you or your organization. If you do believe that a message is legitimate, or you have any doubts about it - double-check using one of the above reputation services before acting on anything requested in said email. Good luck out there!

TechTip: Delete your WhatsApp account (and not just uninstall the app from your phone)

WhatsApp started out as the de facto standard in cross-platform mobile messaging applications. BlackBerry had its BBM, Apple came out with its iMessage and there were the likes of Skype and Google Talk on most devices, but no truly cross-platform application has seen such widespread adoption as the WhatsApp messenger. With popularity, of course, came the public scrutiny and over the years, the application's reputation has been marred by reports of malicious spam, encryption errors and privacy concerns. And as of February 2014 came the announcement that Facebook, the privacy-embattled social networking platform, was acquiring WhatsApp for an unheard of $19 billion US dollars and with it came more privacy concerns stemming from suggestions that Facebook was paying this much to gain access to millions of actual user phone numbers, which WhatsApp has been using in lieu of usernames in their application.

How to delete your WhatsApp account?

If you decided to remove WhatsApp from your devices over possible privacy concerns, please note that simply deleting the WhatsApp mobile application from your smartphone does not delete your account. It leaves your billing information, phone number, contacts and message history on WhatsApp (soon to be Facebook) servers. In order to purge some* of that data first, use the following steps to make sure your account is deleted, before you uninstall the application:

iPhone

Open WhatsApp, go to WhatsApp Settings > Account > Delete My Account.

Android

Open WhatsApp, press the Menu Button > Settings > Account > Delete My Account.

BlackBerry

Open WhatsApp, swipe down from the top and go to Settings > Account Info > Delete My Account.

Windows Phone

Open WhatsApp, tap the three dots on the bottom and go to Settings > Account > Delete Account.

For additional details, refer to the WhatsApp FAQ article on how to delete your account.

Alternatives

If you still want to continue messaging your friends on your mobile devices without paying through the nose for the SMS fees, consider Skype or BBM as free, more privacy conscious, cross-platform messaging alternatives.
_
* WhatsApp does not actually offer any means to purge your data from their servers. Deleting your account is as close as you can get, and according to their FAQ, it only removes you as a contact from your friends' lists, deletes the message history from your phone and deletes your payment information from their servers. I've reached out to WhatsApp support for a way to delete my data from their servers but did not receive an immediate response to my inquiry. Will update the post if I hear back from them.

InfoSec: Avoid using the same password for multiple websites

Abstract: a lot of people use the same password, or a variation of it, for logging into different websites or servers, to avoid having to remember multiple sets of credentials. Unfortunately, this backfires when one of the websites gets hacked and the password data becomes public. This leads to attackers using that same password to gain unauthorized access to every single account the person owns, turning a potentially limited breach into a widespread one.

Additional considerations: many people will designate a reusable password for use with "low risk" sites, sites that require compulsory registration to post a comment, sites that store no sensitive data or sites that they don't particularly care about. While this is a good risk reduction tactic, it might still result in negative consequences if the details from multiple "low risk" sites can be combined and used in social engineering attacks (ie. state of residence from one site, DOB from another, full name from third, phone number from fourth and so on until there is enough data to open a credit card in your name). Another likely risk comes from gradual increase in site's importance to the user over time (ie. original "low risk" registration done to get a free trial version of the product, but then credit card details are added at a later date, with the purchase of the full version of the product). Alternatively, while no sensitive data may be stolen from you, the attacker might use the compromised accounts to impersonate you, to either damage your reputation or attempt to social engineer your friends and relatives into sending them money.

Alternatives: there are many alternatives available for storing and accessing passwords for various websites and services from all of your devices, which would eliminate the need for remembering multiple passwords, while helping you avoid reusing the same one on multiple websites. Apps like 1Password and LastPass let you maintain and access an online repository of all of your credentials, protected by one master password. If you are uncomfortable with storing your credentials online, there are multiple offline options available, such as PasswordSafe for PC, which stores all your credentials in a local, or network shared, encrypted container and offers convenient browser integration features. Various mobile devices will typically have native password management applications for local password management as well. Of course, with offline solutions, there is the drawback of having to sync your passwords manually. Another alternative, which is my personal favorite, is PwdHash - it can run as a Firefox or Chrome plugin and let you enter the same password when logging in to all websites, but actually replacing it with a one-way hash of your password and domain name combination. As a result, what is stored as a password on the website is different for every site and cannot be reverted back to your master password even if the "plain text" password is stolen in a cyber-attack. There are also client applications for PwdHash password generation available on all major mobile platforms, and if all else fails - you can always just do it through their website and copy-paste it to login.

Conclusion: reusing the same password for multiple accounts is a very appealing and convenient option, especially for accounts perceived as low risk. However, many risks of data theft, identity theft and reputation loss through impersonation make this an unsafe practice in this day and age of nearly daily website and service compromises. With many secure alternatives such as PwdHash, PasswordSafe, LastPass and 1Password, moving away from reusing passwords is easy and (mostly) free and might save you and your employer a lot of time and hardship in a next multi-million account service cyber-attack.

TechTip: Install the Microsoft Active Directory Users and Computers tool on Windows 7

"Active Directory Users and Computers" is a great tool for anyone working in or with Microsoft's AD environment, since it allows administrators to search, create and update Active Directory user accounts, groups and even Exchange email distribution lists. In older versions of Windows getting this tool was as easy as installing the "Windows Server 2003 Administration Tools Pack", and you were ready to go. In Windows 7, however, the process is slightly different and requires "activation steps" that are obscure enough to warrant them being well-documented on the web.

Use the following steps to install the Microsoft's Active Directory Users and Computers tool on your Windows 7 system:

1. Download the corresponding "Remote Server Administration Tools" installation package (either 32 or 64 bit) from Microsoft's website: https://www.microsoft.com/en-us/download/details.aspx?id=7887
2. Launch the installer and follow the onscreen instructions, as usual. Next part will be tricky - once installed, the individual tools in the package must be activated using the command line.
3. Run the "Command Prompt" tool with elevated privileges by right-clicking the icon and selecting "Run as administrator" (you may receive the UAC warning pop-up, click "Yes").
4. In the command prompt window that opens, execute the following lines (in order and one at a time) to enable all the per-requisite features and the "Users and Computers" snap-in:
   
   dism /online /enable-feature /featurename:RemoteServerAdministrationTools
   
   dism /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles
   
   dism /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles-AD
   
   dism /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles-AD-DS
   
   dism /online /enable-feature /featurename:RemoteServerAdministrationTools-Roles-AD-DS-SnapIns


5. Each command will take around 30-45 seconds to complete and you should see the progress and confirmation messages displayed on the screen:
   
   

Once all of the activation commands are completed, you should be able to find the "Active Directory Users and Computers" under the "Administrative Tools" folder in your start menu.