Blog

Posts Tagged government

Malicious PHP Script Back on Stage?, (Thu, Jul 18th)

It’s amazing how we can find old scripts coming back to life for some obscure reasons. If today, Powershell or JavaScript (and its derivations) are very common languages used to perform malicious actions, PHP remains also a good candidate. One of my hunting rules is to search for reversed PHP commands using the strrev() function. A few days ago I found a PHP script on pastebin.com that contained the following functions:

$rnfir_zap = strrev('edoced_46esab');$e_nn = strrev('etalfnizg');eval($e_nn($rnfir_zap(implode('',$ro_ie))));

This is a very common technique to obfuscate basic strings-based detection mechanisms. The variable ro_ie’ was an array of concatenated strings:

$ro_ie = array('1TsJc9pI1n+FcaUmZpNJ1DrRe','pjPdgw+YnCwAWNmUhSHjMHiWA','5zZPLf9x3dLQlwEs9U7e6XSYT','U6n731a81qd79/k/382F71hsN',
'G8GyN51N918XjhrHr9PpL+pFC','gf2X/XSX141s0eTSXO1/7r8Ov','Xu9S1efBevzdvl9O4mY1z2j7o','fT4tPrdrxQ+cU34S9Fv6cVrzz',
'nCjf4H2l0sWfqw/2gn5XeD2uM','RwHfx5bVmd9nnMq5yd3+DwvfH','jMvn77um3mB/WqP2uZ1wQbhlo','WrQ5bod/Du7taMawTRp4BlxVM',
'a57RCqON15PR0+UiiwDh7/kq0','4efaAD/wqRLvCyyeM3Se7rD25','JmvoiXPl7qtWPjsrJ8wPvWAK8','dcXfbCa96QFpPCBxpE6OLbv3W’,
...
Easy to decode, rebuild the strings from the array, decode and decompress the data. Guess what you will find? Another obfuscated script. So, I started to work on it and found interesting behaviours.
 
Most of the strings used in the second script are Base64-encoded and placed in an array. They are used via a function which takes an index as parameter. Example:
function decode($i)(
  $array = Array('T' .'W' .'96' .'aWxsYS80LjAgKGNvbXBhdG' .'lib' .'GU7IE1TS' .'UUg'
                 .'OC4w' .'Oy' .'BX' .'aW5' .'kb3dzIE5UIDY' .'uMCk=','c2FmZV9tb2R' .'l',b3’
                 ...);
  return(base64_decode($array[$i]))
}
...
$_56 = decode(1);
The malicious script creates files in ‘/dev/shm//’. That’s clever: /dev/shm is writable by any user on a Linux system and is more stealthy than dumping files to /tmp or /var/tmp!
 
Many integers are replaced by the round() function with mathematical expressions. Example:
return preg_replace(MA_B(243),MA_B(244) .$_69,$_74,round(0+0.33333333333333+0.33333333333333+0.33333333333333));
The round() function above returns 1’.
 
The presence of many ‘wp_xxxx’ strings reveals that the script is targeting WordPress websites. There is indeed a hooking[1] function in place:
@add_action(wp_footer’,’check_wp_load',mt_rand(1,10));
This hook injects malicious code in the WordPress footer.
 
Other interesting techniques are present. The script checks that the WordPress website has a good reputation by querying the Google safebrowing API:
$_34=$_SERVER[HTTP_HOST];
$_0="http://google.com/safebrowsing/diagnostic?site=$_34;
[email protected]($_0); // Perform the HTTP query
if ($_67 != ‘' && strpos($_67,'is listed as suspicious')!== false) {
   ...
There is an anti-bot / anti-analysis control in place. Here are the extracted strings from the array of Base64 strings mentioned above:
66.249.[6-9][0-9].[0-9]+
72.14.[1-2][0-9][0-9].[0-9]+
74.125.[0-9]+.[0-9]+
65.5[2-5].[0-9]+.[0-9]+
74.6.[0-9]+.[0-9]+
67.195.[0-9]+.[0-9]+
72.30.[0-9]+.[0-9]+
38.[0-9]+.[0-9]+.[0-9]+
124.115.6.[0-9]+
93.172.94.227
212.100.250.218
71.165.223.134
209.9.239.101
67.217.160.[0-9]+
70.91.180.25
65.93.62.242
74.193.246.129
213.144.15.38
195.92.229.2
70.50.189.191
218.28.88.99
165.160.2.20
89.122.224.230
66.230.175.124
218.18.174.27
65.33.87.94
67.210.111.241
81.135.175.70
64.69.34.134
89.149.253.169
64.233.1[6-8][1-9].[0-9]+
64.233.19[0-1].[0-9]+
209.185.108.[0-9]+
209.185.253.[0-9]+
209.85.238.[0-9]+
216.239.33.9[6-9]
216.239.37.9[8-9]
216.239.39.9[8-9]
216.239.41.9[6-9]
216.239.45.4
216.239.46.[0-9]+
216.239.51.9[6-9]
216.239.53.9[8-9]
216.239.57.9[6-9]
216.239.59.9[8-9]
216.33.229.163
64.233.173.[0-9]+
64.68.8[0-9].[0-9]+
64.68.9[0-2].[0-9]+
72.14.199.[0-9]+
8.6.48.[0-9]+
207.211.40.82
67.162.158.146
66.255.53.123
24.200.208.112
129.187.148.240
129.187.148.244
199.126.151.229
118.124.32.193
89.149.217.191
122.164.27.42
149.5.168.2
150.70.66.[0-9]+
194.250.116.39
208.80.194.[0-9]+
62.190.39.205
67.198.80.236
85.85.187.243
95.134.141.250
97.107.135.[0-9]+
97.79.239.[0-9]+
173.255.233.[0-9]+
184.168.191.[0-9]+
95.108.157.[0-9]+
209.235.253.17
80.203.168.254
91.121.139.153
65.106.217.107
212.227.136.64
216.27.40.61
125.212.44.207
118.169.43.123
118.169.40.20
http
google
slurp
msnbot
bot
crawl
spider
robot
httpclient
curl
php
indy library
wordpress
charlotte
wwwster
python
urllib
perl
libwww
lynx
twiceler
rambler
yandex
trend
virus
malware
wget
The next step was to find the code used to download another stage. Again, based on the same technique with Base64-encoded strings. The rebuilt URL is:
hxxp://net44net[.]net/net/2.php?u=aHR0cDovLzUyLjIwOS4yNDguMjglMkZ0cm9qYW4ucGhw
As in many cases, the domain does not resolve (and seems for sale according to domaintools.com)… Queries to some passive DNS databases revealed an IP address but it does not reply. Your last hope is often to Google for some strings. I found a blog post from 2012(!) which described exactly the same behaviour [2] but, with some differences in the code:
  1. Files were stored in /tmp instead of /dev/shm/.
  2. The hooked WP function is wp_head() instead of wp_footer().
  3. No call to Google safebrowsing.

But the domain used to download the second stage is the same. Why does the script come back to life?

Some possible scenarios:
  1. The more recent script (posted on the 10th of July) has been revamped?
  2. The script has been found on an old compromised server?
  3. Did somebody find the script somewhere else? The pastie title is “PHP Trojan?” but it not referenced anywhere else according to Google.
Note that both hashes of both scripts are unknown on VT.  If you have more information about this script or the technique used, feel free to share!
 
 
Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

The Other Side of Critical Control 1: 802.1x Wired Network Access Controls, (Thu, Jul 18th)

Today’s story is a short how-to on implementing 802.1x authentication for wired switch ports.  In other words, workstations have to authenticate to be allowed on the wired network (just like your wireless network should be configured).  I was actually surprised to see 802.1x as part of the CIS Critical Control #1, where you’d expect “hardware inventory” stuff to go – it’s actually CC 1.6, 1.7 and 1.8.  But this does make sense, this not only controls where and when your gear can authenticate, but also controls the access that the “not your gear” stuff has (if any) when that stuff tries to connect.

So why do people want this, and why is it part of the Critical Controls?  Because it really is about controlling both your known and unknown inventory.  Known devices authenticate properly, and are given access to the network.  Unknown devices (visitors, or unsanctioned gear of any kind) are either denied access or shuffled off to a jail or guest VLAN.  Either way, the access requests for the “unknown” devices are all logged and can then be investigated if that’s the next step in your organization.  Only known inventory is allowed access to the network.

Infrastructure Components

The diagram below outlines the various systems components used in Network Authentication (802.1x) for both wired and wireless networks.  The assumptions here are:

  • Microsoft Active Directory
  • The “free” Microsoft CA and Network Policy Server (RADIUS) are both used
  • Group Policies and the other MS automation is used to make the various processes and policies work

 

Authentication Sequences – Wired Networking

Domain Member Workstations (also anything that’s been issued a Cert manually)

  • The workstation uses its certificate to authenticate to the RADIUS Server
  • In turn, the RADIUS server also uses its certificate to authenticate to the workstation, to prove that it’s a trusted RADIUS host
  • When authentication is complete, the device is permitted
  • If required, after the user logs in, the user certificate can be used to authenticate the user to the network as well.
  • If the authentication fails, the user is not on the network – they might be in a guest vlan, a “failed authentication” vlan, or simply blocked from network access altogether (read on to the switch config section for more details)
  • And yes, the “purist” 802.1x diagram has about 15 more steps and arrows, but I did say “brief” in my description of this article J

MAC Address Authentication / Bypass

Printers can be issued certificates and work exactly like workstations, but in many cases the printers are outsourced, or if they do own them, a majority of them will be so old (or so cheap) that they won’t support 802.1x authentication.  In those cases, often the client opts to use MAC Address Bypass (MAB) authentication to authenticate the printers.  In this case:

  • The switch acts as a “proxy” sort-of.  The switch collects the MAC address of the device, then uses it to authenticate to the RADIUS host, using the MAC address for both the userid and password
  • The RADIUS server authenticates that to AD.  The RADIUS server then permits the access if that account is found.
  • The switch port permits the device (or denies if the account does not authenticate)

The problem with this is that MAC address spoofing is not a challenge for most attackers.  In fact, you could likely automate something like this with a Raspberry Pi (discover the printer address, and present it out a second Ethernet – or even just act as a transparent bridge).

Wired Telepohones


Cisco wired telephone handsets identify themselves as such using CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discover Protocol).  In many implementations the switch port “trusts” the handsets, and places them on a dedicated voice VLAN.  Telephone handsets do not authenticate in this implementation.

The problem here is obvious, the handsets are simply trusted – and both CDP and LLDP are easily spoofed.

Wired handsets (Cisco in particular, but certainly most other major brands as well) can be issued certificates by their management application – the Cisco implementation uses “LSC” (Locally Significant Certificates).  In some cases the management app can work as a subordinate CA to the enterprise CA (which in our fictitious company is a Microsoft Certificate Server).  In other cases, the voip management app is a CA all on its own, in that design you’d need a separate policy in NPS, or maybe even a separate RADIUS host for the phones.

CERTIFICATE GOTCHAS

Machine Certificates

In the MS Certificate Authority, ensure that the machine certificate template specifies the FQDN of the host in its SAN (Subject Alternative Name) field.  Without this, Windows 10 stations will fail on authentication, as they present their FQDN as their station name (earlier versions of Windows presented their CN – common name).Certificate Authority.  What this normally means is that in the SAN field, you specify the DNS name, UPN and SPN.

User Certificates

Similarly, the fields for the User Certificates are important – use the Fully Distinguished name and (at least) the UPN in the SAN field:

RADIUS Server Certificates

You might think that a standard Server Certificate would work here, but the CA Template for RADIUS servers *must* be based on the “RAS and IAS Servers” template, or it just plain won’t work.

 

Group Policies

User and Computer Certificates

This GPO forces Users and Computers to request Certificates from the Certificate Authority.  This process initiates a “CSR” (Certificate Signing Request).  The CA automatically processes all CSRs from domain member workstations and users, and issues the requested certificate.  Push this certificate out first, and ensure that most or (preferably) all workstations have their certs before you proceed on.

Wired Authentication GPO

This GPO governs authentication of wired workstations, using the 802.1x protocol.

The key points in this GPO are:

  • 802.1x is authenticated
  • Certificates are used for authentication (the selection for “Smart Card or Certificate” is made)
  • Only the Computer Certificate is used
  • The CA is authenticated, and only the enterprise CA can be used
  • The user is never prompted to allow certificates from other CAs
  • Disabling the enforcement of 802.1x at the client allows the use of this workstation on other networks (home Ethernet networks for instance)

This GPO also needs to be pushed out with some “wait time” factored in, before you can configure your switches.  This ensures that when you set the enforcement on the switch policy, the workstations are able to authenticate.  This GPO starts a new service on the workstations, “Wired AutoConfig”.  Checking for this service in a running state is a handy way to ensure that your workstations are “ready to roll” for 802.1x.

The fun part here is that if machines don’t reboot or cycle power after they get this GPO, the service won’t start.  And with Windows 7 and 10, it’s really common now to see machines only reboot for patches – people just seem to lock, sleep or hibernate them anymore.  You may need to enforce a reboot or manually start the service with a script to get this step completed.

RADIUS Server Configuration

Wired Authentication using 802.1x

The radius policy for wired 802.1x is set up with:

Conditions:

Settings:

  • EAP Configuration = Configured
  • Ignore User Dial-in Properties = True
  • Access Permission = Grant Access
  • EAP Method = Microsoft Smart Card or other Certificate
  • NAP Enforcement = Allow Full Network access  (you can set an ACL if you want)
  • Tunnel Medium-Tyupe = 802
  • Tunnel-Pvt-Group-ID =
  • Tunnel Type = VLAN

Not that you can also set a VLAN for non-compliant hosts, normally this is set on the switch port, and is set to some internet-only “guest” VLAN, or else a “jail” VLAN where there are just enough resources for the helpdesk to remediate your computer (see the switch section of this article for those settings)

MAC Address Bypass (MAB) – Printer Authentication

If you choose to implement MAB, you’ll need to define a group that the printer “accounts” will be in.  Using Fine Grained Password Policy (FGPP), you’ll want to relax your password policy enforcement for these accounts.  Also set those accounts so they can’t actually login to the domain.

The printers get the same policy as the workstations in NPS, except:

  • Set the authentication type as unencrypted / PAP instead of EAP
  • The membership should be to your MAB / FGPP group rather than the entire domain
  • This policy will need to be ordered before the Wired NPS Policy

Printer Password Policy

The default domain policy enforces a password policy, which denies accounts the use of their account name as their password – for instance the user “Joe User”, with the userid of  “juser”, cannot use “juser” as their password.

To make things work for MAC address authentication, use a “fine grained password policy” (FGPP) that relaxes this requirement for printer accounts, which use their MAC address for both userid and password in the MAB (MAC Address Bypass) implementation.  This policy is illustrated below, and is applied only to the group “MAB Group for FGPP”, which is also shown:

Apply this policy to the OU or the AD Group that the printers are in.

Switch Configuration

First, the switch configuration is set up to allow 802.1x authentication, and the authentication source is pointed to (at least) 2 RADIUS hosts.

radius server RADIUS01
 address ipv4 auth-port 1812 acct-port 1813
 key

     radius server RADIUS02
       address ipv4 auth-port 1812 acct-port 1813
       key

aaa group server radius RADIUSGROUP
 server name RADIUS01
 server name RADIUS02

dot1x system-auth-control

aaa authentication dot1x default group RADIUSGROUP
aaa accounting dot1x default start-stop group RADIUSGROUP

Next, the individual ports are configured.  A typical workstation / phone / printer port is shown here:

interface GigabitEthernetx/0/y

 

 description some description goes here

 

 switchport access vlan 101

The “native vlan”, also the VLAN assigned for successful 802.1x authentication

 switchport mode access

 

 switchport voice vlan 105

Voice VLAN

 trust device cisco-phone

This tells 802.1x to “trust” phones.  Not recommended, use LSC (Locally Significant Certificates) or equivalent instead.

If LSCs are used, this line should be removed

 authentication event fail action next-method

Fail to successive authentication methods (see below)

 authentication event server dead action authorize voice

Allow voice VLAN access even if RADIUS servers are down

 authentication order dot1x mab

Try 802.1x authentication first, then MAB

 authentication priority dot1x mab

 

 authentication port-control auto

 

 authentication periodic

Re-authenticate periodically

 authentication timer reauthenticate server

 

 mab

Allow MAB (MAC Address Bypass)

 dot1x pae authenticator

Enable 802.1x port authentication

 dot1x timeout server-timeout 30

 

 dot1x timeout tx-period 10

 

 dot1x max-req 3

 

 dot1x max-reauth-req 10

 

 auto qos voip cisco-phone

 

 spanning-tree portfast

abbreviated STP negotiation for workstations

 spanning-tree bpduguard enable

Prevents people from bolting their own switches to this port. 

 

 

OPTIONAL:

 

These two commands cover the two cases of “didn’t authenticate” – either the client isn’t 802.1x capable or it is, but failed the authentication.

 

dot1x guest-vlan

The guest VLAN is where you end up if the client isn’t 802.1x capable (which is the default windows configuration), and if you fail any configured MAC address bypass. 

dot1x auth-fail vlan

If your station is 802.1x capable and fails authentication, then your end up in the “authenticated failed” vlan.

 

Again, I did cover off the configuration for both MAC Address authentication and “trust the phones”.  Neither is recommended if you are truly trying to secure things.  However, in an open office environment with controlled access (visitor signin and locked doors), you can make the case that there are at least some compensating controls to hinder a physical pen-tester or on-premise attacker.

Given how hard the telephony and printer vendors make 802.1x, customers often take these two “shortcuts”.  Just be sure that everyone knows what they’re giving up when they go there!

Do you have any success stories (or “down in flames” stories) of 802.1x authentication projects you’ve seen?  Please, share using our comment form!

===============

Rob VandenBrink
rob coherentsecurity.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Analyzis of DNS TXT Records, (Wed, Jul 17th)

At the Internet Storm Center, we already mentioned so many times that the domain name system is a goldmine for threat hunting or OSINT. A particular type of DNS record is the TXT record (or text record). It’s is a type of resource record used to provide the ability to associate free text with a host or other name. TXT records usually contain:

  • any free text related to the domain like contact information
  • technical data that can’t be stored in other records (SPF and DMARK records)
  • validation records
  • suspicious data (what did you expect?)
  • encoded packets or files (DNS tunnelling of exfiltration of data)

Keep in mind that TXT records are publicly available and should never contain sensitive data. They can be requested by any tool that interacts with DNS servers like dig:

$ dig sans.edu txt

; <> DiG 9.10.6 <> sans.edu txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11178
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sans.edu.            IN    TXT

;; ANSWER SECTION:
sans.edu.        7200    IN    TXT    "MS=ms72131568"
sans.edu.        7200    IN    TXT    "v=spf1 mx ip4:72.55.140.81 ip4:66.35.59.0/24 ip4:66.35.60.0/24 ip4:204.51.94.0/24" " ip4:160.109.234.213 include:stspg-customer.com" " include:cust-spf.exacttarget.com include:spf.clearslide.com" " include:amazonses.com include:spf.protection.outlook.com include:_spf.salesforce.com ~all"
sans.edu.        7200    IN    TXT    "JI6UZuSsLXHEjD7PIBR1rWcPOqRkKRV2VwWAdhXZnLfbjhmfHHOwjMPizS78hfcgbTtjG1TaPTcdVqzgvUbyaw=="

;; AUTHORITY SECTION:
sans.edu.        171976    IN    NS    dns21a.sans.org.
sans.edu.        171976    IN    NS    dns21b.sans.org.
sans.edu.        171976    IN    NS    dns31b.sans.org.
sans.edu.        171976    IN    NS    dns31a.sans.org.

;; Query time: 131 msec
;; SERVER: 192.168.254.8#53(192.168.254.8)
;; WHEN: Tue Jul 16 14:18:20 CEST 2019
;; MSG SIZE  rcvd: 550

The RFC1464[1] discuss TXT records. They must contain printable characters so many TXT records contain Base64-encoded data (see the above example). But what can we find in TXT records? I extracted a long list of domain names from different DNS servers logs and malicious domains lists. Then I queried TXT records for each of them. Results have been loaded into a Splunk instance to search for some juicy stuff. What did I find?

Note: the set of collected domain names is directly related to the business/activity of the organizations’ log sources. I tried to mix different sources but they do not cover the full Internet.

Across 300K+ TXT records, 186K were related to SPF filters[2]. What are the top email providers?

  • Microsoft (Outlook.com) (9.9%)
  • Google (7.8%)
  • OVH (1.5%)

More than 3K domains have the following filter: “v=spf1 -all” which means basically “no hosts are authorized to send emails for those domains”.

Only 389(!) domains had a DKIM TXT record (“v=DKIM1; k=rsa; p=…”)

Another common usage of TXT records is to provide control to prove that you own a specific domain. That’s why many providers ask to create a validation record. The top-20 validation record types are:

google-site-verification 
facebook-domain-verification 
_globalsign-domain-verification 
adobe-idp-site-verification 
atlassian-domain-verification 
globalsign-domain-verification 
ciscocidomainverification 
status-page-domain-verification 
zoho-verification 
keybase-site-verification 
protonmail-verification 
have-i-been-pwned-verification 
dropbox-domain-verification 
workplace-domain-verification 
brave-ledger-verification 
webexdomainverification. 
citrix-verification-code 
adobe-sign-verification 
detectify-verification 
logmein-verification-code 
sophos-domain-verification

34K domains had an Office365 record “MS=msXXXXXXXX”

Domains using CloudFlare have a TXT record like “ca3-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX” (5K+ records)

What about some suspicious/malicious activity?

I found 5 occurrences of:

window.location.replace("hxxp://www[.]28955bfg36abp[.]maintenirfa[.]icu/50968.html”);

Some SQL injection attempts:

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//""; alert(String.fromCharCode(88,83,83))//

Injections:

'"">>""> prompt(1)@gmail.com'-->"">alert(document.cookie)"">"" ""'"">

Finally, I had a look at Base64-encoded strings. I extracted all TXT record in a flat file and used Didier’s base64dump tool (only 16+ bytes data strings)

$ base64dump.py -n 16 txt-records.csv

18K strings have been decoded with mainly unknown data. If you restrict the min size of decoded data, you can find other types of records:

$ base64dump.py -n 128 1563290719_434556 | grep Salted__
433:     172 U2FsdGVkX18ImyXI Salted__.?%?'|j bf4a8022560a0eaa5410421803f3f36a
4836:     172 U2FsdGVkX18UR6BW Salted__.G?V?~?+ 1b6cb31ff37707a5234411b0d2946d92
5020:     128 U2FsdGVkX18LDhF1 Salted__...u??&{ be5a0c41bd9113f59d105fe52b0d600b
10480:     172 U2FsdGVkX18Gx+Qk Salted__.??$??.? 8f3c2fb8cb65bf83deb319040cfa0431
10858:     172 U2FsdGVkX19uUZCc Salted__nQ??E?Q? d1518d4dd745cf21549881477e1f0663
10859:     172 U2FsdGVkX18swQke Salted__,?..?.?j d59604b22066693a2fe1020a9230cee2
10860:     172 U2FsdGVkX18kqxHK Salted__$?.?? ? ad198d777d6535e735e011a1962da767
10863:     172 U2FsdGVkX182vS1/ Salted__6?-/.?? 79b98e60256204b1496672bf534d798f
11111:     192 U2FsdGVkX19gXMHT Salted__`??.R?* 9e3c2eb4248b8a9f19669b95733f6b42
11112:     172 U2FsdGVkX19eP/Xr Salted__^???+?? 62fec6ab31abf469714ed644f874dfe5
11989:     192 U2FsdGVkX19Lx8yU Salted__K??f?P9 bae75f0621aac882fe0d6437148eb6e2
12188:     172 U2FsdGVkX18fgi6U Salted__.?.??=?. d2f075147f0ecfd6dbd5decb5ab539a8
12189:     172 U2FsdGVkX1/bj0+w Salted__?O??J?- 57c4fab20a1d00ae6ab9421adb14db7d
12236:     128 U2FsdGVkX19eQQU7 Salted__^A.;?..? fe5ddee71702e557f2223b5dbf638521
12283:     172 U2FsdGVkX18oCMgi Salted__(.?"W??? 2340a1f6293d5094fbb1bfc7b0477ea9
12284:     172 U2FsdGVkX19TxBC7 Salted__S?.??Q7. 7023090b4b45d80468d73ccf1fd76f75
12292:     192 U2FsdGVkX19LqH/h Salted__K??h.?? f64d90db45cab9227c593fe99ee19ae6
12363:     152 U2FsdGVkX19AaKCa [email protected]??.U0/ a9f3b2548d3a5571b75510c392ceea70
12573:     172 U2FsdGVkX19vmD8m Salted__o??&??./ 94b8e7d4c933bd1fc6c3dd381fea9b95
15550:     128 U2FsdGVkX18YmIhE Salted__.??D?}?7 61421ac7e9463408085cf67ee525c2a0
15551:     152 U2FsdGVkX18N9H+R Salted__.?????o 0eda0cc8c4d2667032ce27d0a389f2a9
16629:     152 U2FsdGVkX194reUj Salted__x??#?J? c098589181b03e2a78f34ef3e08c7b09

The prefix “Salted__” means this either is the output of an “openssl enc” command or something like this.

As you can see, they are plenty of interesting data that can be found in TXT records. I also found an interesting blog article[3] with a set of regex to search for data in TXT records. You should keep in an eye on them.
I’m considering a permanent script to collect them on the fly from my Bro instance and build some kind of “passivetxt” service.

[1] https://www.rfc-editor.org/rfc/rfc1464.txt
[2] https://en.wikipedia.org/wiki/Sender_Policy_Framework
[3] https://www.tide-project.nl/blog/ccr2019/

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Commando VM: The Complete Mandiant Offensive VM, (Tue, Jul 16th)

Commando VM Logo

The good folks at Mandiant have created the Commando VM, a fully customized, Windows-based security distribution for penetration testing and red teaming.
From the project’s About Commando VM content:
“Penetration testers commonly use their own variants of Windows machines when assessing Active Directory environments. Commando VM was designed specifically to be the go-to platform for performing these internal penetration tests. The benefits of using a Windows machine include native support for Windows and Active Directory, using your VM as a staging area for C2 frameworks, browsing shares more easily (and interactively), and using tools such as PowerView and BloodHound without having to worry about placing output files on client assets.”

Many of the expected tools are available on this platform, over 140, including:

  • Nmap
  • Wireshark
  • Covenant
  • Python
  • Go
  • Remote Server Administration Tools
  • Sysinternals
  • Mimikatz
  • Burp-Suite
  • x64dbg
  • Hashcat

The team claims support for blue teams as well. In their own words, “Commando VM provides blue teams with the tools necessary to audit their networks and improve their detection capabilities. With a library of offensive tools, it makes it easy for blue teams to keep up with offensive tooling and attack trends.” While a bit more in spirit than reality with the Commando VM, any aspirations to support the purple team approach are welcome and admirable.

Installation is extremely straightforward, the platform is built out via Boxstarter, Chocolatey, and MyGet packages, and takes a bit of time to complete, more than an hour in multiple test scenarios for me. Full, thorough installation guidelines are here. The fast and furious version is simply this:

  • Create and configure a new Windows Virtual Machine, update it completely, then take a snapshot
  • Download and copy install.ps1 on the newly configured and updated VM
  • Open an elevated PowerShell console
  • Enable script execution: Set-ExecutionPolicy Unrestricted
  • Execute the installer script: .install.ps1

Be patient, let it finish, and keep an eye on the console from time to time as it progresses.
As always, please read the project content in full. You can also download the full Commando VM repository from GitHub as a zip package or clone it accordingly.

Given its Windows-centric focus, Commando VM includes a few tools that have advanced Windows exploitation practices, with particular attention to .NET and WMI.
In the reverse engineering category, there’s ILSpy, the open-source .NET assembly browser and decompiler.
For command and control, there’s Covenant, “a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers.”
From FortyNorth Security, also see WMImplant, “a PowerShell based tool that is designed to act like a RAT. Its interface is that of a shell where any command that is supported is translated into a WMI-equivalent for use on a network/remote machine.” FortyNorth Security and Chris Truncer also offer up WMIOps, “a powershell script which uses WMI for various purposes across a network.”
WMIOps is used to “perform a variety of actions on hosts, local or remote, within a Windows environment and is designed primarily for use on penetration tests or red team engagements.” As such, it includes:

  • Process functions: Get-RunningProcessesWMI (accounts with active processess)
  • User operations: Find-ActiveUsersWMI (whois on target)
  • Host enumeration: Get-ActiveNICSWMI (dump target NICs)
  • System manipulation operations: r Invoke-ServiceManipulation (service buggery)
  • File operations: Invoke-FileTransferOverWMI (exfil)

In the big bucket o’ exploitation tools, a few favorites lurk.
EvilClippy, as part of its role as a cross-platform assistant for creating malicious Microsoft Office documents, includes the likes of VBA stomping (P-code abuse). EvilClippy puts fake VBA code from a text file (VBA) in all modules, while leaving P-code intact, abusing an undocumented feature of module streams. It’s a straightforward as EvilClippy.exe -s fakecode.vba macrofile.doc

A wise and recent red team re-orientation towards C# opportunities is also well represented. FuzzySec’s Sharp-Suite, GhostPack, and SharpSploit are all present and accounted for. Commando VM owes a great debt to the hard work of the SpecterOps team. Ryan Cobb produced Covenant as well as SharpSploit.
Ryan states that there is a “trend developing on the offensive side of the security community in porting existing PowerShell toolsets to C#. With the added security features in PowerShell (ie. ScriptBlock Logging, AMSI, etc.), it makes sense that red teamers are investing in other options, and C# is the logical next step from PowerShell.” Note that SharpSploit is designed as a library, so there is only a SharpSploit.dll.
Ryan’s teammate, Will Schroeder aka harmj0y, created GhostPack, generically referred to as “collection of security related toolsets.” 😉
Therein, you will find the likes of Seatbelt, a “C# project that performs a number of security oriented host-survey safety checks relevant from both offensive and defensive security perspectives.”
Given the spirit of purple team embraced by the Commando VM team, Seatbelt seems like an ideal way to bring us to conclusion for this quick Commando VM overview. In order to make use of Seatbelt you need to compile it yourself, the project team is not releasing binaries.
To do so, simply download Visual Studio Community 2019 on your Commando VM, set it up for Windows development (.NET, desktop, and UWP), and then open Seatbelt.sln, found in C:toolsGhostPackSeatbelt. Be sure to run Visual Studio as administrator for this step. In Solution Explorer, right-click Seatbelt and select Build. You’ll then find Seatbelt.exe in C:toolsGhostPackSeatbeltSeatbeltbinDebug.
Pop a command shell, run Seatbelt.exe all and revel in the results, including the likes of system data (incoming RDP sessions, firewall rules, autoruns, etc), user data (saved RDP connections, 7 days of IE bookmarks and history, saved credential in Windows Vault, etc), and other collection options such as listing Kerberos tickets, Kerberos TGTData (ALL TEH TGTZ!), 4624 events from the security event log, and installed patches via WMI.

Seatbelt

Seatbelt

You can quickly see how Seatbelt can serve both red and blue causes.

Great stuff from the Mandiant team for Commando VM, a complete Mandiant offensive VM indeed. As alway, be cautious in your use, lots of chaos to be created with this platform, ensure you have permission and purview.

Cheers…until next time.

Russ McRee | @holisticinfosec

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

isodump.py and Malicious ISOFiles, (Mon, Jul 15th)

Inspired by my diary entry “Malicious .iso Attachments“, @Evild3ad79 created a tool, isodump.py, to help with the analysis of ISO files.

Without any arguments or options, the tool displays its usage:

When you just provide it an ISO file, it does nothing:

You have to provide a command, like displaying metadata (-M):

Or listing the content (-l):

This ISO file contains a file named PAYMENT.EXE, it’s very likely a PE file (starts with 4D5A, or MZ). With the provided hashes, we can search for it on VirusTotal.

The file can be selected (-s 0) and dumped to stdout (-d). I like this feature, it allows me to pipe the malware into another analysis tool, without writing it to disk:

If you just need to look at the first file, you can omit option -s:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

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